Re: Android (lack of) support for DHCPv6

[Baldur Norddahl]

On 13 June 2015 at 09:11, Mikael Abrahamsson  wrote:

> On Fri, 12 Jun 2015, Baldur Norddahl wrote:
>
>  Can someone explain to me how Android uses SLAAC to implement tethering?
>>
>
> https://tools.ietf.org/html/rfc7278
>
> --


I have not read it in detail, but correct me if I am wrong, that stuff will
NOT work while the phone is on wifi.

Quote:

"

As [RFC6459 ] describes, the
3GPP-network-assigned /64 is completely
dedicated to the UE and the gateway does not consume any of the /64
addresses.  The gateway routes the entire /64 to the UE and does not
perform ND or Neighbor Unreachability Detection (NUD) [RFC4861
].
Communication between the UE and the gateway is only done using
link-local addresses and the link is point-to-point.



"

It is like a DHCP-PD of a /64 to the phone.

I fail to see what relevance that has to a phone supporting DHCP on a Wifi
or LAN link.

Except of course that it should make it trivial for Android to support
DHCP-PD. They already have a system that can consume a /64 from a prefix
delegation and use that for both applications on the phone and for
tethering (does tethering while on Wifi make sense? - it is possible using
bluetooth to a laptop).

Regards,

Baldur

Re: Android (lack of) support for DHCPv6

[Mikael Abrahamsson]

On Fri, 12 Jun 2015, Baldur Norddahl wrote:


Can someone explain to me how Android uses SLAAC to implement tethering?


https://tools.ietf.org/html/rfc7278

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Android (lack of) support for DHCPv6

[William Herrin]

On Fri, Jun 12, 2015 at 1:33 PM, Dave Taht  wrote:
> The core bits of what I don't understand about the flamage is how hard
> would it be for an end-user - or corporate client - to just add any of
> these functionalities to this, cyanogenmod, etc.

Hi Dave,

Tough to say. The Feat implementation of OpenVPN claims to work on
android without root. OpenVPN would have to hook in to most of the
same places in the network stack that a DHCPv6 implementation would.
On the other hand, they seem to have trouble with it breaking for each
new version of android, and other implementations of OpenVPN do
require root.

Certainly having to root or flash your android device to get DHCPv6
would reasonably be considered "hard."

Regards,
Bill Herrin





-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: Android (lack of) support for DHCPv6

[Robert McKay]

On 2015-06-12 16:58, Ray Soucy wrote:
Wouldn't the simple play here be for Android to just throw up a 
message
saying "This network does not support tethering" if SLAAC isn't 
enabled,

and to let users complain to local operators if that's something they
want?  Google doesn't get blamed, operators are happy, and ultimately 
users
have a better experience because the expectations of the network are 
clear
rather than trying something that will likely not work consistently 
across

networks.


No.. there's one more step in the arms race.. if it's impossible to get 
more
than one IPv6 address the user doesn't just give up and say 'oh well', 
or
break down and pay the operator for tethering access - they enable NAT. 
If

NAT isn't supported they will find a way to make it happen anyway.

IMO possibly the reason for leaving SLAAC as the only option is to try 
and force
operators to have a configuration that allows some form of tethering.. 
perhaps

not dhcp-pd which might be nicer but at least not NAT.

Operators could combat this by coming up with an implementation of 
SLAAC that
tries to force the client to only use one or perhaps a very limited 
number of IPs.


I'm imagining a sort of timeout system where only one IP is really 
allowed to
work at once.. perhaps you could allow more addrs to continue their 
existing
TCP sessions but everything else gets reset except for the one 
currently
active primary outbound IP. This could be combined with other 
anti-tethering
features such as ttl monitoring and deep packet inspection / user agent 
sniffing.


It's probably inevitable that operators will do this and the users will 
be
forced to implement a NAT and proxy based tethering system to evade the 
anti-
tether features anyway.. but forcing the use of SLAAC might delay it 
for

a little while.

Rob

Re: Android (lack of) support for DHCPv6

[Dave Taht]

On Fri, Jun 12, 2015 at 10:51 AM, Todd Underwood  wrote:
>
> On Fri, Jun 12, 2015 at 1:43 PM,  wrote:
>>
>> On Fri, 12 Jun 2015 10:33:55 -0700, Dave Taht said:
>> > The core bits of what I don't understand about the flamage is how hard
>> > would it be for an end-user - or corporate client - to just add any of
>> > these functionalities to this, cyanogenmod, etc.
>>
>> What percent of Android users have even *heard* of cyanogenmod?
>
>
> a larger percentage than have ever *heard* of IPv6.  :-)
>
> game. set. match.

Change and innovation have to start somewhere, and usually occur on
the edges of the ecosystem. Good ideas (and bad) get filtered up (or
out) that way.

Cyanogen is one of several android derivatives innovating (or at
least, was, last I looked).

> t
>
>



-- 
Dave Täht
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

Re: Android (lack of) support for DHCPv6

[Todd Underwood]

On Fri, Jun 12, 2015 at 1:43 PM,  wrote:

> On Fri, 12 Jun 2015 10:33:55 -0700, Dave Taht said:
> > The core bits of what I don't understand about the flamage is how hard
> > would it be for an end-user - or corporate client - to just add any of
> > these functionalities to this, cyanogenmod, etc.
>
> What percent of Android users have even *heard* of cyanogenmod?
>

a larger percentage than have ever *heard* of IPv6.  :-)

game. set. match.

t

Re: Android (lack of) support for DHCPv6

[Valdis . Kletnieks]

On Fri, 12 Jun 2015 10:33:55 -0700, Dave Taht said:
> The core bits of what I don't understand about the flamage is how hard
> would it be for an end-user - or corporate client - to just add any of
> these functionalities to this, cyanogenmod, etc.

What percent of Android users have even *heard* of cyanogenmod?


pgpHLSRSnS3Gx.pgp
Description: PGP signature

Re: Android (lack of) support for DHCPv6

[Michael Thomas]

The thing about this is that I get the impression that there was violent 
agreement that DHCPv6 with PD would be Good Thing.
I think that the disagreement is about single address assignments being 
a Bad Thing or Good Thing.


For Android, it seems that if operators implemented the ability to fetch 
a prefix that would be great for Android.
For operators, if you do DHCPv6-PD and Android implements it... the 
camel's nose is under the tent...


Mike

On 06/12/2015 09:53 AM, William Herrin wrote:

On Thu, Jun 11, 2015 at 7:42 PM, Laszlo Hanyecz  wrote:

DHCPv6 is a crutch that allows operators to simply implement IPv6
with all the same hacks as IPv4 and continue to do address based
access control, tracking, etc.

Hi Lazlo,

Who are you to tell me how I must or must not use this new technology?
I will use it if I please and as I please. Your (and Lorenzo's)
arguments that I must not do stateful address assignment do not please
me and do not engender me to implement or support your variant of the
new technology.

You are, of course, welcome to tell me I'm not important enough for
you to care. Should you do so, don't expect more than disdain the next
time you express frustration with the technology's rate of uptake.



I think what Lorenzo is trying to do is to use his
influence/position to forcefully prevent people from doing this,
and while that may not be the most diplomatic way, I admire his
courage in posting here and trying to reason with the mob.

Hopefully he learned in this escapade that no one, NO ONE, has
sufficient position nor influence nor, ultimately, sufficient wisdom
to dictate how a technology is to be used. Having offered our
respective suggestions, we can but listen as prospective users tell us
what additional capabilities they require.

Regards,
Bill Herrin

Re: Android (lack of) support for DHCPv6

[Dave Taht]

I have completely lost track of the technical issues on this thread.

I would like DHCP-PD support for acquiring a prefix for tethering,
from both cellular, and from wifi, in android. A mobile (android is
also used in settop boxes and devices like that) and pretty standard
platform that I could put anywhere in the home to "boost the signal"
to devices elsewhere would be a goodness, much like I now use wifi
range extenders, bluetooth, powerline, and one day 802.11ad.

I also would not mind ahcpd, and hnetd support, and support for one or
more sane routing protocols.

Is the debate here conflating dhcpv6 (for getting addresses), and
dhcp-pd (for obtaining prefixes?) It is certainly possible to do one
without the other and vice versa.

The core bits of what I don't understand about the flamage is how hard
would it be for an end-user - or corporate client - to just add any of
these functionalities to this, cyanogenmod, etc.

Re: Android (lack of) support for DHCPv6

[William Herrin]

On Thu, Jun 11, 2015 at 7:42 PM, Laszlo Hanyecz  wrote:
> DHCPv6 is a crutch that allows operators to simply implement IPv6
> with all the same hacks as IPv4 and continue to do address based
> access control, tracking, etc.

Hi Lazlo,

Who are you to tell me how I must or must not use this new technology?
I will use it if I please and as I please. Your (and Lorenzo's)
arguments that I must not do stateful address assignment do not please
me and do not engender me to implement or support your variant of the
new technology.

You are, of course, welcome to tell me I'm not important enough for
you to care. Should you do so, don't expect more than disdain the next
time you express frustration with the technology's rate of uptake.


> I think what Lorenzo is trying to do is to use his
> influence/position to forcefully prevent people from doing this,
> and while that may not be the most diplomatic way, I admire his
> courage in posting here and trying to reason with the mob.

Hopefully he learned in this escapade that no one, NO ONE, has
sufficient position nor influence nor, ultimately, sufficient wisdom
to dictate how a technology is to be used. Having offered our
respective suggestions, we can but listen as prospective users tell us
what additional capabilities they require.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: Android (lack of) support for DHCPv6

[Ray Soucy]

Personally my view is that DHCPv6-PD support would be much better for
tethering, but I don't get to tell Google how to do that just like they
don't get to tell me how to give out addresses.  My only request would be
if you do implement DHCPv6-PD for tethering, please make it only request a
prefix when you actually enable tethering, not as the default.  That would
be bad for different reasons.

Wouldn't the simple play here be for Android to just throw up a message
saying "This network does not support tethering" if SLAAC isn't enabled,
and to let users complain to local operators if that's something they
want?  Google doesn't get blamed, operators are happy, and ultimately users
have a better experience because the expectations of the network are clear
rather than trying something that will likely not work consistently across
networks.

If the concern is that you don't want to carriers to use DHCPv6 then you
could just limit it to 802.11.

The point is that there are several options here to address peoples
concerns and make IPv6 adoption that much easier, but the position of
Google on DHCPv6 support for Android is just another barrier to widespread
adoption of IPv6.  I honestly appreciate the work Google has been doing for
years to promote IPv6 adoption, but they're wrong here.






On Fri, Jun 12, 2015 at 11:30 AM, Todd Underwood 
wrote:

> lorenzo already stated that the cost was in user satisfaction related to
> tethering and the business reason was the desire to not implement NAT in v6
> on android.
>
> many people didn't like those reasons or think that they are less
> important than their own reasons.
>
> shockingly, everyone believes that their own priorities are more important
> than everyone else's priorities.
>
> the 'cranky about the lack of DHCPv6' crowd has already made their points
> and further shut down conversation by demanding that lorenzo speak for
> Google on this thread.  indeed, shouting loudly and shutting down
> conversation was almost certainly the intent of many of the posts here.  so
> mission accomplished.
>
> fists have been pounded.  conversation has been halted.  well done.
>
> can me move on now?
>
> t
>
> On Fri, Jun 12, 2015 at 11:18 AM, James R Cutler <
> james.cut...@consultant.com> wrote:
>
>> Ray Soucy has given us an nice summary. It goes along with “please let me
>> manage my business and don’t take away my tools just to satisfy your
>> prejudices.”
>>
>> Selection of management policies and implementations is ALWAYS a local
>> issue (assuming consideration of legal necessities). Especially in the
>> end-to-end model, the requirements management of end systems has not
>> changed because the IP layer protocol has changed. This is a good reason
>> for not prohibiting continuing use of DHCP-based solutions. “Purity of
>> protocols” is not a reason for increasing management costs such as
>> described by Ray.
>>
>> This debate about DHCPv6 has been going on far too long.  I want to know
>> how much it will cost the “SLAAC-only” faction to quit fighting DHCPv6.
>> My conjecture is that it would be minimal, especially as compared to the
>> costs for the activities described by Ray.
>>
>> Putting it differently: What business purpose is served by fighting
>> full-functioned DHCPv6 deployment. Don’t give me any RFC or protocol
>> arguments - just tell me the business reasons for forcing others to change
>> how they manage their business.
>>
>> James R. Cutler
>> james.cut...@consultant.com
>> PGP keys at http://pgp.mit.edu
>>
>>
>>
>> > On Jun 12, 2015, at 10:07 AM, Ray Soucy  wrote:
>> >
>> > The only thing I would add is that DHCPv6 is not just about "tracking"
>> > clients.  Yes there are ways to do so using SLAAC, but they are not
>> pretty.
>> >
>> > Giving too much weight to tracking being the reason for DHCPv6 is just
>> as
>> > bad as giving too much weight to tethering as the reason against it.  It
>> > skews the conversation.
>> >
>> > For us, DHCPv6 is about *operational consistency*.
>> >
>> > Universities have been running with the end-to-end model everyone is
>> > looking to IPv6 to restore for a very long time.
>> >
>> > When you connect to our network, wired or wireless, you get a public IP
>> > with no filtering in place in most cases.
>> >
>> > We have been living the end-to-end model, and that has given us
>> operational
>> > experience and insight on what it actually takes to support access
>> networks
>> > using this model.
>> >
>> > Almost every peer institution I talk to has implemented custom systems
>> > refined over decades to preserve the end-to-end model in a time of
>> > increasing security incidents and liability.  These include IPAM
>> systems,
>> > which feed into vulnerability scanning, or host filtering for incident
>> > response, etc.
>> >
>> > These systems are in place for IPv4, and modifying them to support IPv6
>> > (which most of us have done) is relatively easy in the case of DHCPv6.
>> >
>> > By maintaining consistency between IPv4 a

Re: Android (lack of) support for DHCPv6

[Baldur Norddahl]

Can someone explain to me how Android uses SLAAC to implement tethering?

SLAAC allows the Android device to have as many addresses it wants. But how
does that allow it to reshare those address to a tethered device? A
tethering device that might itself be running SLAAC or DHCPv6.

If the tethering client device was running DHCPv6 the Android phone could
proxy that. But with SLAAC the Android has no idea which addresses are in
play - unless it implements NAT!

We also have the option that the Android is simply doing a layer 2 bridge.
In that case, the Android would not care what the tethering client device
is doing. Just move the packets.

If Google are truly worried about tethering, they would implement something
like LISP. It is then possible to provision the tethered device with
address space that is totally unrelated to the host network. They gave you
only 1 address? Does not matter, we will use that only for the LISP
endpoint. Put a /64 on a loopback interface inside the device, so
applications can get unlimited addresses as needed.

Regards,

Baldur

Re: Android (lack of) support for DHCPv6

[Chris Adams]

Once upon a time, Todd Underwood  said:
> lorenzo already stated that the cost was in user satisfaction related to
> tethering and the business reason was the desire to not implement NAT in v6
> on android.

So, just to roll back for a second, I hadn't really thought about what
was being discussed exactly.  This is about connecting an Android device
to wifi, right?  I didn't think you could have an Android device connect
to wifi _and_ tether at the same time; when I turn on the hotspot on my
phone, it disables wifi client mode (automatically disconnects from any
wifi AP) to enable AP mode.  I'm pretty sure that's the way all my
Android phones have worked.

Why is this an issue (i.e. what am I missing)?

-- 
Chris Adams 

Re: Android (lack of) support for DHCPv6

[Todd Underwood]

lorenzo already stated that the cost was in user satisfaction related to
tethering and the business reason was the desire to not implement NAT in v6
on android.

many people didn't like those reasons or think that they are less important
than their own reasons.

shockingly, everyone believes that their own priorities are more important
than everyone else's priorities.

the 'cranky about the lack of DHCPv6' crowd has already made their points
and further shut down conversation by demanding that lorenzo speak for
Google on this thread.  indeed, shouting loudly and shutting down
conversation was almost certainly the intent of many of the posts here.  so
mission accomplished.

fists have been pounded.  conversation has been halted.  well done.

can me move on now?

t

On Fri, Jun 12, 2015 at 11:18 AM, James R Cutler <
james.cut...@consultant.com> wrote:

> Ray Soucy has given us an nice summary. It goes along with “please let me
> manage my business and don’t take away my tools just to satisfy your
> prejudices.”
>
> Selection of management policies and implementations is ALWAYS a local
> issue (assuming consideration of legal necessities). Especially in the
> end-to-end model, the requirements management of end systems has not
> changed because the IP layer protocol has changed. This is a good reason
> for not prohibiting continuing use of DHCP-based solutions. “Purity of
> protocols” is not a reason for increasing management costs such as
> described by Ray.
>
> This debate about DHCPv6 has been going on far too long.  I want to know
> how much it will cost the “SLAAC-only” faction to quit fighting DHCPv6.
> My conjecture is that it would be minimal, especially as compared to the
> costs for the activities described by Ray.
>
> Putting it differently: What business purpose is served by fighting
> full-functioned DHCPv6 deployment. Don’t give me any RFC or protocol
> arguments - just tell me the business reasons for forcing others to change
> how they manage their business.
>
> James R. Cutler
> james.cut...@consultant.com
> PGP keys at http://pgp.mit.edu
>
>
>
> > On Jun 12, 2015, at 10:07 AM, Ray Soucy  wrote:
> >
> > The only thing I would add is that DHCPv6 is not just about "tracking"
> > clients.  Yes there are ways to do so using SLAAC, but they are not
> pretty.
> >
> > Giving too much weight to tracking being the reason for DHCPv6 is just as
> > bad as giving too much weight to tethering as the reason against it.  It
> > skews the conversation.
> >
> > For us, DHCPv6 is about *operational consistency*.
> >
> > Universities have been running with the end-to-end model everyone is
> > looking to IPv6 to restore for a very long time.
> >
> > When you connect to our network, wired or wireless, you get a public IP
> > with no filtering in place in most cases.
> >
> > We have been living the end-to-end model, and that has given us
> operational
> > experience and insight on what it actually takes to support access
> networks
> > using this model.
> >
> > Almost every peer institution I talk to has implemented custom systems
> > refined over decades to preserve the end-to-end model in a time of
> > increasing security incidents and liability.  These include IPAM systems,
> > which feed into vulnerability scanning, or host filtering for incident
> > response, etc.
> >
> > These systems are in place for IPv4, and modifying them to support IPv6
> > (which most of us have done) is relatively easy in the case of DHCPv6.
> >
> > By maintaining consistency between IPv4 and IPv6 we avoid having to
> retrain
> > hundreds of IT workers on supporting connectivity.  By saying that you
> > won't support DHCPv6, you effectively force us into a choice between
> > investing considerable effort in redesigning systems and training IT
> > personnel, while introducing confusion in the support process because
> IPv4
> > and IPv6 are delivered using completely different methods.
> >
> > You have just made it cheaper for us to turn to NAT than to support IPv6.
> > That's unacceptable.
> >
> > You might be thinking "well that's just universities and a small percent
> of
> > users", but the point here is that we do these things for a reason; we've
> > been living without NAT and our collective operational experience doing
> so
> > is something that would be wise to take into consideration instead of
> > dismissing it or trying to call us names.
> >
> > Organizations running SLAAC who say everything is fine, think everything
> is
> > fine because IPv6 has received almost no attention from bad actors in
> terms
> > of security incidents or denial of service attacks.  Even well known
> > servers with IPv6 addresses on our network rarely see SSH attempts over
> > IPv6 today.
> >
> > *This will fundamentally change as IPv6 adoption grows*.
> >
> > Are you prepared to be able to deal with abuse reports of hosts on your
> > network participating on denial of service attacks?  Can you associate
> the
> > identity of a system to an individua

Re: Android (lack of) support for DHCPv6

[Jim Popovitch]

On Fri, Jun 12, 2015 at 11:18 AM, James R Cutler
 wrote:
> “please let me manage my business and don’t take away my tools just to 
> satisfy your prejudices.”

There are probably several ways to interpret that in ways you hadn't
considered for this discussion, I can think of a few.

They are:

 - Who is taking away what from who in a University, in order to
save who's $$?  :-)

 - Suppression of hate talk/art/literature has historically been
used to restrict some businesses for the greater good of mankind.

-Jim P.

Re: Android (lack of) support for DHCPv6

[James R Cutler]

Ray Soucy has given us an nice summary. It goes along with “please let me 
manage my business and don’t take away my tools just to satisfy your 
prejudices.”

Selection of management policies and implementations is ALWAYS a local issue 
(assuming consideration of legal necessities). Especially in the end-to-end 
model, the requirements management of end systems has not changed because the 
IP layer protocol has changed. This is a good reason for not prohibiting 
continuing use of DHCP-based solutions. “Purity of protocols” is not a reason 
for increasing management costs such as described by Ray.

This debate about DHCPv6 has been going on far too long.  I want to know how 
much it will cost the “SLAAC-only” faction to quit fighting DHCPv6.
My conjecture is that it would be minimal, especially as compared to the costs 
for the activities described by Ray.

Putting it differently: What business purpose is served by fighting 
full-functioned DHCPv6 deployment. Don’t give me any RFC or protocol arguments 
- just tell me the business reasons for forcing others to change how they 
manage their business.

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu



> On Jun 12, 2015, at 10:07 AM, Ray Soucy  wrote:
> 
> The only thing I would add is that DHCPv6 is not just about "tracking"
> clients.  Yes there are ways to do so using SLAAC, but they are not pretty.
> 
> Giving too much weight to tracking being the reason for DHCPv6 is just as
> bad as giving too much weight to tethering as the reason against it.  It
> skews the conversation.
> 
> For us, DHCPv6 is about *operational consistency*.
> 
> Universities have been running with the end-to-end model everyone is
> looking to IPv6 to restore for a very long time.
> 
> When you connect to our network, wired or wireless, you get a public IP
> with no filtering in place in most cases.
> 
> We have been living the end-to-end model, and that has given us operational
> experience and insight on what it actually takes to support access networks
> using this model.
> 
> Almost every peer institution I talk to has implemented custom systems
> refined over decades to preserve the end-to-end model in a time of
> increasing security incidents and liability.  These include IPAM systems,
> which feed into vulnerability scanning, or host filtering for incident
> response, etc.
> 
> These systems are in place for IPv4, and modifying them to support IPv6
> (which most of us have done) is relatively easy in the case of DHCPv6.
> 
> By maintaining consistency between IPv4 and IPv6 we avoid having to retrain
> hundreds of IT workers on supporting connectivity.  By saying that you
> won't support DHCPv6, you effectively force us into a choice between
> investing considerable effort in redesigning systems and training IT
> personnel, while introducing confusion in the support process because IPv4
> and IPv6 are delivered using completely different methods.
> 
> You have just made it cheaper for us to turn to NAT than to support IPv6.
> That's unacceptable.
> 
> You might be thinking "well that's just universities and a small percent of
> users", but the point here is that we do these things for a reason; we've
> been living without NAT and our collective operational experience doing so
> is something that would be wise to take into consideration instead of
> dismissing it or trying to call us names.
> 
> Organizations running SLAAC who say everything is fine, think everything is
> fine because IPv6 has received almost no attention from bad actors in terms
> of security incidents or denial of service attacks.  Even well known
> servers with IPv6 addresses on our network rarely see SSH attempts over
> IPv6 today.
> 
> *This will fundamentally change as IPv6 adoption grows*.
> 
> Are you prepared to be able to deal with abuse reports of hosts on your
> network participating on denial of service attacks?  Can you associate the
> identity of a system to an individual when law enforcement demands you to
> do so?  How much longer will it take you to track down a host by its IPv6
> address to disable it?  How many other users have degraded service while
> they're waiting for you to do that?
> 
> For most people that are used to the typical IPv4 model (NAT and open pool
> DHCP), these events are very infrequent, so of course they don't get it.
> For those of us running a more liberal network which preserves the
> end-to-end model, free from aggressive filtering on user traffic, these
> incidents are literally daily occurrences.
> 
> The fact is that you never know what service a user might enable on their
> device only to be exploited and degrade service for their peers.
> 
> So yes, we are looking to the future in the case of DHCPv6, because we've
> learned from the past.
> 
> 
> 
> 
> 
> On Fri, Jun 12, 2015 at 3:05 AM,  wrote:
> 
>> On Fri, 12 Jun 2015 02:07:22 -, Laszlo Hanyecz said:
>> 
> university net nazis
 
 Did you really just write that?
 

Re: Android (lack of) support for DHCPv6

[Ray Soucy]

The only thing I would add is that DHCPv6 is not just about "tracking"
clients.  Yes there are ways to do so using SLAAC, but they are not pretty.

Giving too much weight to tracking being the reason for DHCPv6 is just as
bad as giving too much weight to tethering as the reason against it.  It
skews the conversation.

For us, DHCPv6 is about *operational consistency*.

Universities have been running with the end-to-end model everyone is
looking to IPv6 to restore for a very long time.

When you connect to our network, wired or wireless, you get a public IP
with no filtering in place in most cases.

We have been living the end-to-end model, and that has given us operational
experience and insight on what it actually takes to support access networks
using this model.

Almost every peer institution I talk to has implemented custom systems
refined over decades to preserve the end-to-end model in a time of
increasing security incidents and liability.  These include IPAM systems,
which feed into vulnerability scanning, or host filtering for incident
response, etc.

These systems are in place for IPv4, and modifying them to support IPv6
(which most of us have done) is relatively easy in the case of DHCPv6.

By maintaining consistency between IPv4 and IPv6 we avoid having to retrain
hundreds of IT workers on supporting connectivity.  By saying that you
won't support DHCPv6, you effectively force us into a choice between
investing considerable effort in redesigning systems and training IT
personnel, while introducing confusion in the support process because IPv4
and IPv6 are delivered using completely different methods.

You have just made it cheaper for us to turn to NAT than to support IPv6.
That's unacceptable.

You might be thinking "well that's just universities and a small percent of
users", but the point here is that we do these things for a reason; we've
been living without NAT and our collective operational experience doing so
is something that would be wise to take into consideration instead of
dismissing it or trying to call us names.

Organizations running SLAAC who say everything is fine, think everything is
fine because IPv6 has received almost no attention from bad actors in terms
of security incidents or denial of service attacks.  Even well known
servers with IPv6 addresses on our network rarely see SSH attempts over
IPv6 today.

*This will fundamentally change as IPv6 adoption grows*.

Are you prepared to be able to deal with abuse reports of hosts on your
network participating on denial of service attacks?  Can you associate the
identity of a system to an individual when law enforcement demands you to
do so?  How much longer will it take you to track down a host by its IPv6
address to disable it?  How many other users have degraded service while
they're waiting for you to do that?

For most people that are used to the typical IPv4 model (NAT and open pool
DHCP), these events are very infrequent, so of course they don't get it.
For those of us running a more liberal network which preserves the
end-to-end model, free from aggressive filtering on user traffic, these
incidents are literally daily occurrences.

The fact is that you never know what service a user might enable on their
device only to be exploited and degrade service for their peers.

So yes, we are looking to the future in the case of DHCPv6, because we've
learned from the past.





On Fri, Jun 12, 2015 at 3:05 AM,  wrote:

> On Fri, 12 Jun 2015 02:07:22 -, Laszlo Hanyecz said:
>
> > > > university net nazis
> > >
> > > Did you really just write that?
> > >
> >
> > As far as "net nazi", I meant it in the same sense as a BOFH.  Someone
> who is
> > intentionally degrading a user's experience by using technical means to
> block
> > specifically targeted applications or behaviors.
>
> Well, which is more BOFH-ish:
>
> 1) We insist that you connect in a way that allows us to identify and track
> you for DMCA and other legal requirements that, quite frankly, we'd really
> rather not have to do, but it's a cost of doing business.
>
> 2) We don't let you connect at all because we can't do so without exposing
> ourselves to more legal liability than we want.
>
> Besides which, that's a total red herring.
>
> If you actually go back and *read*, I don't think anybody's "intentionally
> degrading by blocking targeted applications" - except those who are
> refusing
> to provide features to allow the applications to work on more network
> configs.
> The vast majority of us would *prefer* that Android got fixed so it can
> ask for
> more addresses and do more stuff. Most of us don't *care* if a user sucks
> up 13
> adresses across 4 devices at the same time - IPv6 addresses are *cheap*.
> On the other hand, covering your ass when a subpoena shows up and you
> realize
> you don't have the data needed to point at the user they're *really*
> looking
> for is incredibly expensive.
>
> OK? Let me say that again:  We're all asking Google to quit being

Re: Android (lack of) support for DHCPv6

[Brandon Butterworth]

> > On the other hand, if it becomes common and acceptable to use DHCPv6 to
> > provide a single address only
> 
> I encourage my competitor universities to design their networks that way. :)

I'd be fine with android doing DHCPv6 plus refusing to use v6 if only
one address is available. Covers the stated objective and lets those
that will do the claimed right thing go ahead with v6 roll out.

brandon

Re: Android (lack of) support for DHCPv6

[Valdis . Kletnieks]

On Fri, 12 Jun 2015 02:07:22 -, Laszlo Hanyecz said:

> > > university net nazis
> >
> > Did you really just write that?
> >
>
> As far as "net nazi", I meant it in the same sense as a BOFH.  Someone who is
> intentionally degrading a user's experience by using technical means to block
> specifically targeted applications or behaviors.

Well, which is more BOFH-ish:

1) We insist that you connect in a way that allows us to identify and track
you for DMCA and other legal requirements that, quite frankly, we'd really
rather not have to do, but it's a cost of doing business.

2) We don't let you connect at all because we can't do so without exposing
ourselves to more legal liability than we want.

Besides which, that's a total red herring.

If you actually go back and *read*, I don't think anybody's "intentionally
degrading by blocking targeted applications" - except those who are refusing
to provide features to allow the applications to work on more network configs.
The vast majority of us would *prefer* that Android got fixed so it can ask for
more addresses and do more stuff. Most of us don't *care* if a user sucks up 13
adresses across 4 devices at the same time - IPv6 addresses are *cheap*.
On the other hand, covering your ass when a subpoena shows up and you realize
you don't have the data needed to point at the user they're *really* looking
for is incredibly expensive.

OK? Let me say that again:  We're all asking Google to quit being stubborn
and add a feature to Android so we can make the user experience *better*.

Now who you calling a BOFH?

> On the other hand, if it becomes common and acceptable to use DHCPv6 to
> provide a single address only

I encourage my competitor universities to design their networks that way. :)


pgpUHyTeN1Vs0.pgp
Description: PGP signature

Re: Android (lack of) support for DHCPv6

[Ricky Beam]

On Thu, 11 Jun 2015 19:42:07 -0400, Laszlo Hanyecz   
wrote:

It looks to me like Lorenzo wants the same thing as most everyone here,


It doesn't look like that from my chair. He doesn't want to implement  
DHCPv6 (and has REFUSED to do so for YEARS now) because he cannot find  
solutions for every possible permutation. In fact, he's hung up on **ONE**  
configuration: a network where DHCPv6 allows exactly one address to an  
endpoint.


Things like privacy extensions, multiple addresses and PD are great  
because they make it harder for people to do address based tracking,  
which is generally regarded as a desirable feature except by the people  
who want to do the tracking.


Addresses are *always* trackable. It's just a matter of who is in the best  
position to do it. My ISPs know what prefixes are assigned to me (both  
static and dynamic.) If I keep track of it, I know everything that's using  
an address in my networks -- by DHCP logs, and in theory, MAC table logs.  
(btw, I don't know of any solutions for MAC level logging.)


DHCPv6 is a crutch that allows operators to simply implement IPv6 with  
all the same hacks as IPv4 and continue to do address based access  
control, tracking, etc.


It allows them to have the level of accountability and control they desire  
and/or REQUIRE.


With DHCPv6, one doesn't have to pin a device to a single, solitary  
address. ISPs already handle that with PD (a single /64, a /60, or  
larger.) And there's nothing in the specs blocking a node from asking for  
multiple addresses. Again, because of the specter of one-address, Lorenzo  
REFUSED to support DHCPv6, IN. ANY. WAY.

Re: Android (lack of) support for DHCPv6

[Lyndon Nerenberg]

On Jun 11, 2015, at 9:06 PM, Karl Auer  wrote:

>> You don't get to just say "I'm not going to implement this because I don't
>> agree with it," which is what Google is doing in the case of Android.
> 
> Actually, you DO get to just say that. Anyone can, but especially
> something as big as Google. And if DHCPv6 turns out to be important
> enough to enough people, Android will lose market share and either fork,
> die or change its mind. It wouldn't be the first mobile platform to
> disappear into the sludge of history.

Sadly, there is another side to this. Witness how the DMARC crew are destroying 
the functionality of email as we have known it for decades. Sometimes the 800 
pound gorillas DO have the ability to fsck things over for everyone.

--lyndon

P.S.  But it is the mindless-sheep-like behaviour that lets them.  So instead I 
should be complaining to the masses who are incapable of thinking for 
themselves?  We know how well *that* works ...


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Android (lack of) support for DHCPv6

[Karl Auer]

On Thu, 2015-06-11 at 20:51 -0400, Ray Soucy wrote:
> DHCPv6 is a tool, just as SLAAC is a tool.  IPv6 was designed to support
> both options because they both have valid use cases.

Yes, a thousand times yes.

> You don't get to just say "I'm not going to implement this because I don't
> agree with it," which is what Google is doing in the case of Android.

Actually, you DO get to just say that. Anyone can, but especially
something as big as Google. And if DHCPv6 turns out to be important
enough to enough people, Android will lose market share and either fork,
die or change its mind. It wouldn't be the first mobile platform to
disappear into the sludge of history.

> I honestly hope he collects himself and takes the time to respond, because
> it really is a problem.

Not for him, and apparently not for Google. It's only a problem for
people that want to do DHCPv6 with Android clients. Whether that becomes
a problem for Google is another matter.

I certainly hope Google sees the light early. Their current stance is
very disappointing. And it's odd to see someone at that level so
comprehensively missing the point. For someone with the breadth of
experience and jacked into the mother lode like Lorenzo - very unusual.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

Re: Android (lack of) support for DHCPv6

[Matthew Petach]

On Thu, Jun 11, 2015 at 4:42 PM, Laszlo Hanyecz  wrote:
> Lorzenzo is probably not going to post anymore because of this.

Oh, I imagine we'll all need to take a time-out after this thread;
I know it's got my back fur all riled up, too.  :(

> It looks to me like Lorenzo wants the same thing as most everyone here, aside 
> from the university net nazis, and he's got some balls to come defend his 
> position against the angry old men of NANOG.  Perhaps the approach of 
> attacking DHCP is not the right one, but it sounds like his goal is to make 
> IPv6 better than how IPv4 turned out.

If we had the choice of waiting to make IPv6 better, that might
be a more laudable position; if we were having this discussion
ten years ago, when v4 addresses were still plentiful, pushing
for the best future of IPv6 would have been great.

Unfortunately, with v4 exhaustion, companies face the
decision of "is v6 easy enough to deploy so that I can
just do that, or do I stick with v4 and more layers of NAT
to stretch my meagre v4 resources out as long as I can."

Dogmatic positions like this swing the pendulum firmly
towards the latter, unfortunately.

He's got balls, I'll definitely say that much.  I just feel
like his balls are coming to the party ten years too late.  :(

> Things like privacy extensions, multiple addresses and PD are great because 
> they make it harder for people to do address based tracking, which is 
> generally regarded as a desirable feature except by the people who want to do 
> the tracking.  DHCPv6 is a crutch that allows operators to simply implement 
> IPv6 with all the same hacks as IPv4 and continue to do address based access 
> control, tracking, etc.  It's like a 'goto' statement - it can be used to do 
> clever things, but it can also be used to hack stuff and create very hard to 
> fix problems down the road.  I think what Lorenzo is trying to do is to use 
> his influence/position to forcefully prevent people from doing this, and 
> while that may not be the most diplomatic way, I admire his courage in 
> posting here and trying to reason with the mob.

Without address tracking, devices aren't going to be
allowed onto corporate networks.  You may hate that,
but legal liability makes that an absolute necessity.
Like it or not, regardless of whatever privacy extensions,
multiple addresses, and PD you push for, in order to
use those devices on corporate networks, there must be
a way to track which devices had those addresses.

> -Laszlo

Matt
PS--any discussion of Lorenzo's balls on my part is purely
my personal opinion, and is not undertaken on behalf of
any employer.  In other words, nobody pays me to talk
about Lorenzo's balls.

Re: Android (lack of) support for DHCPv6

[Laszlo Hanyecz]

"Your phone doesn't work with our network, so you should buy one that does"
vs
"Hey we can't connect, fix your network"

Kind of similar to the streaming video vs eyeball network thing.. blaming the 
bad user experience on the other guy.

-Laszlo



On Jun 12, 2015, at 2:18 AM, Matthew Petach  wrote:

> On Wed, Jun 10, 2015 at 8:26 AM, Lorenzo Colitti  wrote:
>> Ray,
>> 
>> please do not construe my words on this thread as being Google's position
>> on anything. These messages were sent from my personal email address, and I
>> do not speak for my employer.
>> 
>> Regards,
>> Lorenzo
> 
> 
> Ah, Lorenzo, Lorenzo...
> 
> I was going to just let the thread go quietly by until you pulled
> out the "I'm not speaking for my employer" card.  :(
> 
> Can we take what you posted here
> https://code.google.com/p/android/issues/detail?id=32621#c53
> from your google.com account to be official Google
> position, when you closed the issue requesting DHCPv6
> support as "Declined?"
> 
> Again, in comment #109
> https://code.google.com/p/android/issues/detail?id=32621#c109
> you speak from your Google.com account when you repeat
> *twice* the position that you won't support stateful DHCPv6:
> "and not via stateful DHCPv6 address assignment" followed by
> "while continuing not to support DHCPv6 address assignment."
> 
> It's hard to not see _that_ as being Google's position, when you
> post it from your google.com account in response to an issue raised
> about broken functionality on the Android platform.  So perhaps
> you're right, and the words you use on _this_ thread are your
> personal opinion; unfortunately, they seem to be the same
> words and opinions you use from your google.com account when
> denying input from Android users who don't seem to want
> their devices to be crippled by incomplete DHCPv6 support.
> 
> I wonder at what point large enterprises will simply say
> "sorry, without working DHCPv6 support, Android devices
> will not be supported on this network"--at which point this
> will stop being a religious issue, and will shift to being a
> business issue, as Google will have to decide whether
> being stubbornly dogmatic while losing large customers
> is worth it or not.
> 
> Thanks!
> 
> Matt
> 
> PS--just because some poor unfortunate soul found a
> way to scrape neighbor tables to work around the lack
> of DHCPv6 lease logs does *not* make it a practical
> or wise alternative.   A certain network has been trying
> to test out that workaround, and every time they scrape
> the neighbor table, the CPU on the routers pegs at 100%.
> 
> PPS--I am likewise posting this from my personal
> account (which is still running an old enough Cisco
> image that it pre-dates IPv6 support entirely, making
> most of this a moot point for me personally).   The
> opinions expressed here are purely my own, and
> should in no way be construed to apply to anyone
> but myself, and possibly the mice living in the garage.

Re: Android (lack of) support for DHCPv6

[Matthew Petach]

On Wed, Jun 10, 2015 at 8:26 AM, Lorenzo Colitti  wrote:
> Ray,
>
> please do not construe my words on this thread as being Google's position
> on anything. These messages were sent from my personal email address, and I
> do not speak for my employer.
>
> Regards,
> Lorenzo


Ah, Lorenzo, Lorenzo...

I was going to just let the thread go quietly by until you pulled
out the "I'm not speaking for my employer" card.  :(

Can we take what you posted here
https://code.google.com/p/android/issues/detail?id=32621#c53
from your google.com account to be official Google
position, when you closed the issue requesting DHCPv6
support as "Declined?"

Again, in comment #109
https://code.google.com/p/android/issues/detail?id=32621#c109
you speak from your Google.com account when you repeat
*twice* the position that you won't support stateful DHCPv6:
"and not via stateful DHCPv6 address assignment" followed by
"while continuing not to support DHCPv6 address assignment."

It's hard to not see _that_ as being Google's position, when you
post it from your google.com account in response to an issue raised
about broken functionality on the Android platform.  So perhaps
you're right, and the words you use on _this_ thread are your
personal opinion; unfortunately, they seem to be the same
words and opinions you use from your google.com account when
denying input from Android users who don't seem to want
their devices to be crippled by incomplete DHCPv6 support.

I wonder at what point large enterprises will simply say
"sorry, without working DHCPv6 support, Android devices
will not be supported on this network"--at which point this
will stop being a religious issue, and will shift to being a
business issue, as Google will have to decide whether
being stubbornly dogmatic while losing large customers
is worth it or not.

Thanks!

Matt

PS--just because some poor unfortunate soul found a
way to scrape neighbor tables to work around the lack
of DHCPv6 lease logs does *not* make it a practical
or wise alternative.   A certain network has been trying
to test out that workaround, and every time they scrape
the neighbor table, the CPU on the routers pegs at 100%.

PPS--I am likewise posting this from my personal
account (which is still running an old enough Cisco
image that it pre-dates IPv6 support entirely, making
most of this a moot point for me personally).   The
opinions expressed here are purely my own, and
should in no way be construed to apply to anyone
but myself, and possibly the mice living in the garage.

Re: Android (lack of) support for DHCPv6

[Laszlo Hanyecz]

On Jun 12, 2015, at 12:51 AM, Ray Soucy  wrote:

> That's really not the case at all.  
> 
> You're just projecting your own views about not thinking DHCPv6 is valid and 
> making yourself and Lorenzo out to be the some sort of victims of NANOG and 
> the ... 
> 

DHCPv6 and Android are just collateral damage here but I think the argument is 
about steering what the generally accepted form of "end user IPv6 on WiFi" will 
be.  It would be great if we could agree on that so we don't all have to write 
support for many different ways and provide complicated user interfaces for 
configuring it, right?  Plug and play?

> > university net nazis
> 
> Did you really just write that?  
> 

As far as "net nazi", I meant it in the same sense as a BOFH.  Someone who is 
intentionally degrading a user's experience by using technical means to block 
specifically targeted applications or behaviors.  And "angry old men" is also 
not a literal meaning, but an observation of how this has turned into a flame 
war where it's a lot of seemingly angry people mobbing the Android developer.

> What we're arguing for here is choice, the exact opposite of the association 
> you're trying to make here.  It's incredibly poor taste to throw that term 
> around in this context, and adds nothing to the discussion.
> 
> People are not logical.  They adopt a position and then look for information 
> to support it rather than counter it; they even go as far as to ignore or 
> dismiss relevant information in the face of logic.  That's religion.  And 
> this entire discussion continues to be rooted in religion rather than 
> pragmatism.
> 
> DHCPv6 is a tool, just as SLAAC is a tool.  IPv6 was designed to support both 
> options because they both have valid use cases.  Please allow network 
> operators to use the best tool for the job instead of telling us all we're 
> required to do it your way (can you even see how ridiculous this whole "nazi" 
> name calling is given the position you're taking)

Without getting into all the "actually there is edge case X" discussions, when 
you connect to a WiFi network at an office, home or public place today, it's 
pretty 'standard' to find a DHCP server handing out rfc1918 IPv4 addresses, 
recursive name servers, and the network doing some form of NAT or proxying.  
This is pretty much what we expect when we open up a laptop and connect to a 
network, and if it doesn't work we call the help desk and ask why it doesn't do 
what we expect.  Every user application that wants to do peer to peer 
networking has to come up with some complicated workaround to communicate 
through the various forms of NAT and proxies.

What do we expect to happen with regard to IPv6? I think it would be great if 
end to end connectivity was common enough that application developers could 
assume it will be there, and avoid having to do those workarounds.  On the 
other hand, if it becomes common and acceptable to use DHCPv6 to provide a 
single address only, then applications will just circumvent it once again with 
things like NAT, VPNs and reflector servers, which actually makes it worse for 
everyone involved.

> 
> You don't get to just say "I'm not going to implement this because I don't 
> agree with it," which is what Google is doing in the case of Android.
> 
> The reason Lorenzo has triggered such a backlash on NANOG is that is 
> fundamental argument on why he doesn't see DHCPv6 as valid for the Android is 
> quite frankly a very weak argument at best.  If you're going to stand up and 
> say you're not going to do what everyone else has already done, especially 
> when it comes to implementation of fundamental standards that everything 
> depends upon, you need to have a better reason for it than the one Lorenzo 
> provided.
> 

It seems like several people have taken the position that they will use their 
influence to steer others away from Android because it doesn't work with their 
chosen network configuration.  This to me sounds very much like Android taking 
the position that the network should support their chosen address configuration 
protocol instead of that other one.  I think in the end we're going to find 
that both the network side and the client side end up having to support the 
whole matrix of possible configurations, if the end goal is to provide a good 
user experience, but this is not a good OS developer and network operator 
experience because it creates more work for everyone and more trouble for users 
when the complicated workarounds don't work.

-Laszlo

> I honestly hope he collects himself and takes the time to respond, because it 
> really is a problem.
> 
> As much as you may not want DHCPv6 to be a thing, it's already a thing.
> 
> 
> 
> 
> 
> On Thu, Jun 11, 2015 at 7:42 PM, Laszlo Hanyecz  wrote:
> Lorzenzo is probably not going to post anymore because of this.
> 
> It looks to me like Lorenzo wants the same thing as most everyone here, aside 
> from the university net nazis, and he's 

Re: Android (lack of) support for DHCPv6

[Mark Andrews]

In message <2f1701d0a4aa$617b98f0$2472cad0$@acm.org>, "Paul B. Henson" writes:
> > From: Laszlo Hanyecz
> > Sent: Thursday, June 11, 2015 4:42 PM
> >
> > from the university net Nazis
> 
> Wow, it must be nice to live in a fairyland utopia where there is no DMCA,
> no federal laws such as HEOA, and a wide variety of other things you clearly
> know nothing about that require universities to be able to track their users
> and manage their networks.

Both "fairyland utopia" and "net Nazis" are extreme positions.

And DHCPv6 is not the only solution to tracking users.  There are
solutions that work with SLAAC.

Same as 464XLAT is not the only way to provide IPv4 service over IPv6.

Same as withholding a DHCPv6 client is not the only way to encourage
multiple addresses.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Android (lack of) support for DHCPv6

[Ray Soucy]

Well, most systems implemented DHCPv6 support a long time ago.  Despite
other efforts to have Google support DHCPv6 for Android, nothing has
happened.  There is nothing wrong with using NANOG to call out a major
vendor for this, even if they are a significant sponsor.

Just because you don't agree with the direction of the discussion doesn't
mean it has no value.

On Thu, Jun 11, 2015 at 9:03 PM, Ca By  wrote:

> Yeh, we get it.  Repeating yourself is not helpful. The horse is dead 
>
> Please move your android feature request to a forum more fit for your
> request.
>
> On Thursday, June 11, 2015, Paul B. Henson  wrote:
>
> > > From: Laszlo Hanyecz
> > > Sent: Thursday, June 11, 2015 4:42 PM
> > >
> > > from the university net Nazis
> >
> > Wow, it must be nice to live in a fairyland utopia where there is no
> DMCA,
> > no federal laws such as HEOA, and a wide variety of other things you
> > clearly
> > know nothing about that require universities to be able to track their
> > users
> > and manage their networks.
> >
> > > attacking DHCP is not the right one, but it sounds like his goal is to
> > make IPv6
> > > better than how IPv4 turned out.
> >
> > I don't think a single person here has a goal of making IPv6 worse, nor
> > necessarily has any objection to the improvements he has suggested.
> OTOH, I
> > think the number of people who think he is making a good decision in
> > refusing to implement DHCPv6 is practically nil.
> >
> > > diplomatic way, I admire his courage in posting here and trying to
> reason
> > with
> > > the mob.
> >
> > If he really wants to validate his position on not implementing DHCPv6,
> > maybe he should approach all of the other vendors who already did and get
> > them to remove it. Being the one and only holdout on implementing a
> widely
> > deployed Internet standard looks more like lunatic fringe than visionary
> > leader 8-/.
> >
> >
> >
>



-- 
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

Re: Android (lack of) support for DHCPv6

[Ca By]

Yeh, we get it.  Repeating yourself is not helpful. The horse is dead 

Please move your android feature request to a forum more fit for your
request.

On Thursday, June 11, 2015, Paul B. Henson  wrote:

> > From: Laszlo Hanyecz
> > Sent: Thursday, June 11, 2015 4:42 PM
> >
> > from the university net Nazis
>
> Wow, it must be nice to live in a fairyland utopia where there is no DMCA,
> no federal laws such as HEOA, and a wide variety of other things you
> clearly
> know nothing about that require universities to be able to track their
> users
> and manage their networks.
>
> > attacking DHCP is not the right one, but it sounds like his goal is to
> make IPv6
> > better than how IPv4 turned out.
>
> I don't think a single person here has a goal of making IPv6 worse, nor
> necessarily has any objection to the improvements he has suggested. OTOH, I
> think the number of people who think he is making a good decision in
> refusing to implement DHCPv6 is practically nil.
>
> > diplomatic way, I admire his courage in posting here and trying to reason
> with
> > the mob.
>
> If he really wants to validate his position on not implementing DHCPv6,
> maybe he should approach all of the other vendors who already did and get
> them to remove it. Being the one and only holdout on implementing a widely
> deployed Internet standard looks more like lunatic fringe than visionary
> leader 8-/.
>
>
>

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Laszlo Hanyecz
> Sent: Thursday, June 11, 2015 4:42 PM
>
> from the university net Nazis

Wow, it must be nice to live in a fairyland utopia where there is no DMCA,
no federal laws such as HEOA, and a wide variety of other things you clearly
know nothing about that require universities to be able to track their users
and manage their networks.

> attacking DHCP is not the right one, but it sounds like his goal is to
make IPv6
> better than how IPv4 turned out.

I don't think a single person here has a goal of making IPv6 worse, nor
necessarily has any objection to the improvements he has suggested. OTOH, I
think the number of people who think he is making a good decision in
refusing to implement DHCPv6 is practically nil.

> diplomatic way, I admire his courage in posting here and trying to reason
with
> the mob.

If he really wants to validate his position on not implementing DHCPv6,
maybe he should approach all of the other vendors who already did and get
them to remove it. Being the one and only holdout on implementing a widely
deployed Internet standard looks more like lunatic fringe than visionary
leader 8-/.

Re: Android (lack of) support for DHCPv6

[Ray Soucy]

That's really not the case at all.

You're just projecting your own views about not thinking DHCPv6 is valid
and making yourself and Lorenzo out to be the some sort of victims of NANOG
and the ...

> university net nazis

Did you really just write that?

What we're arguing for here is choice, the exact opposite of the
association you're trying to make here.  It's incredibly poor taste to
throw that term around in this context, and adds nothing to the discussion.

People are not logical.  They adopt a position and then look for
information to support it rather than counter it; they even go as far as to
ignore or dismiss relevant information in the face of logic.  That's
religion.  And this entire discussion continues to be rooted in religion
rather than pragmatism.

DHCPv6 is a tool, just as SLAAC is a tool.  IPv6 was designed to support
both options because they both have valid use cases.  Please allow network
operators to use the best tool for the job instead of telling us all we're
required to do it your way (can you even see how ridiculous this whole
"nazi" name calling is given the position you're taking)

You don't get to just say "I'm not going to implement this because I don't
agree with it," which is what Google is doing in the case of Android.

The reason Lorenzo has triggered such a backlash on NANOG is that is
fundamental argument on why he doesn't see DHCPv6 as valid for the Android
is quite frankly a very weak argument at best.  If you're going to stand up
and say you're not going to do what everyone else has already done,
especially when it comes to implementation of fundamental standards that
everything depends upon, you need to have a better reason for it than the
one Lorenzo provided.

I honestly hope he collects himself and takes the time to respond, because
it really is a problem.

As much as you may not want DHCPv6 to be a thing, it's already a thing.





On Thu, Jun 11, 2015 at 7:42 PM, Laszlo Hanyecz  wrote:

> Lorzenzo is probably not going to post anymore because of this.
>
> It looks to me like Lorenzo wants the same thing as most everyone here,
> aside from the university net nazis, and he's got some balls to come defend
> his position against the angry old men of NANOG.  Perhaps the approach of
> attacking DHCP is not the right one, but it sounds like his goal is to make
> IPv6 better than how IPv4 turned out.
>
> Things like privacy extensions, multiple addresses and PD are great
> because they make it harder for people to do address based tracking, which
> is generally regarded as a desirable feature except by the people who want
> to do the tracking.  DHCPv6 is a crutch that allows operators to simply
> implement IPv6 with all the same hacks as IPv4 and continue to do address
> based access control, tracking, etc.  It's like a 'goto' statement - it can
> be used to do clever things, but it can also be used to hack stuff and
> create very hard to fix problems down the road.  I think what Lorenzo is
> trying to do is to use his influence/position to forcefully prevent people
> from doing this, and while that may not be the most diplomatic way, I
> admire his courage in posting here and trying to reason with the mob.
>
> -Laszlo
>
>
> On Jun 10, 2015, at 10:24 PM, Michael Thomas  wrote:
>
> > On 06/10/2015 02:51 PM, Paul B. Henson wrote:
> >>> From: Lorenzo Colitti
> >>> Sent: Wednesday, June 10, 2015 8:27 AM
> >>>
> >>> please do not construe my words on this thread as being Google's
> position
> >>> on anything. These messages were sent from my personal email address,
> and I
> >>> do not speak for my employer.
> >> Can we construe your postings on the issue thread as being Google
> and/or Androids official position? They are posted by lore...@google.com
> with a tag of "Project Member", and I believe you also declined the request
> in the issue under that mantle.
> >>
> >>
> > Oh, stop this. The only thing this will accomplish is a giant black hole
> of silence from anybody at Google and any other $MEGACORP
> > in a similar situation.
> >
> > Mike
>
>


-- 
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

Re: Android (lack of) support for DHCPv6

[Mark Andrews]

In message <9da9c5b8-e60c-4462-873a-ea5052128...@heliacal.net>, Laszlo Hanyecz 
writes:
> Lorzenzo is probably not going to post anymore because of this.
>
> It looks to me like Lorenzo wants the same thing as most everyone here,
> aside from the university net nazis, and he's got some balls to come
> defend his position against the angry old men of NANOG.  Perhaps the
> approach of attacking DHCP is not the right one, but it sounds like his
> goal is to make IPv6 better than how IPv4 turned out.
>
> Things like privacy extensions, multiple addresses and PD are great
> because they make it harder for people to do address based tracking,
> which is generally regarded as a desirable feature except by the people
> who want to do the tracking.  DHCPv6 is a crutch that allows operators to
> simply implement IPv6 with all the same hacks as IPv4 and continue to do
> address based access control, tracking, etc.  It's like a 'goto'
> statement - it can be used to do clever things, but it can also be used
> to hack stuff and create very hard to fix problems down the road.  I
> think what Lorenzo is trying to do is to use his influence/position to
> forcefully prevent people from doing this, and while that may not be the
> most diplomatic way, I admire his courage in posting here and trying to
> reason with the mob.
>
> -Laszlo

There is a difference between arguing that additional addesses
should be supported and saying stuff consensus and stuff what you
want from the product, I am not going to give you DHCPv6 support
because it may be used to only hand out only one address.

The better long term strategy is to support DHCPv6 and then complain
that you can't get a address for 464XLAT and/or a privacy address.

Having a brower come up and say "Unable to obtain privacy address.
Do you still want to post this request" for every request will have
much more impact and is actually solvable with a couple of tweaks
to the DHCPv6 configuration than getting policy changed to support
SLACC.  Recording N addresss against a user (where N is small) is
not any harder than recording 1 address and gives the traceback
needed.

A RFC compliant DHCPv6 server will hand out multiple address by
default.  I haven't checked ISC's DHCPv6 server and if it doesn't
do multiple addresses by default please open a bug ticket
(dhcp-b...@isc.org) as it should.

464XLAT isn't even needed to do IPv4 over a IPv6-only WiFi.  There
are other ways to do it, e.g. DS-Lite, which work better than
464XLAT.

Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Android (lack of) support for DHCPv6

[Laszlo Hanyecz]

Lorzenzo is probably not going to post anymore because of this.

It looks to me like Lorenzo wants the same thing as most everyone here, aside 
from the university net nazis, and he's got some balls to come defend his 
position against the angry old men of NANOG.  Perhaps the approach of attacking 
DHCP is not the right one, but it sounds like his goal is to make IPv6 better 
than how IPv4 turned out.

Things like privacy extensions, multiple addresses and PD are great because 
they make it harder for people to do address based tracking, which is generally 
regarded as a desirable feature except by the people who want to do the 
tracking.  DHCPv6 is a crutch that allows operators to simply implement IPv6 
with all the same hacks as IPv4 and continue to do address based access 
control, tracking, etc.  It's like a 'goto' statement - it can be used to do 
clever things, but it can also be used to hack stuff and create very hard to 
fix problems down the road.  I think what Lorenzo is trying to do is to use his 
influence/position to forcefully prevent people from doing this, and while that 
may not be the most diplomatic way, I admire his courage in posting here and 
trying to reason with the mob.

-Laszlo


On Jun 10, 2015, at 10:24 PM, Michael Thomas  wrote:

> On 06/10/2015 02:51 PM, Paul B. Henson wrote:
>>> From: Lorenzo Colitti
>>> Sent: Wednesday, June 10, 2015 8:27 AM
>>> 
>>> please do not construe my words on this thread as being Google's position
>>> on anything. These messages were sent from my personal email address, and I
>>> do not speak for my employer.
>> Can we construe your postings on the issue thread as being Google and/or 
>> Androids official position? They are posted by lore...@google.com with a tag 
>> of "Project Member", and I believe you also declined the request in the 
>> issue under that mantle.
>> 
>> 
> Oh, stop this. The only thing this will accomplish is a giant black hole of 
> silence from anybody at Google and any other $MEGACORP
> in a similar situation.
> 
> Mike

Re: Android (lack of) support for DHCPv6

[Bruce Curtis]

  We have had IPv6 enabled on our campus network since 2008 (including 
wireless).  We started with SLAAC and did some experimenting with DHCPv6 PD 
over wireless but haven’t implemented DHCPv6 as a production service yet.

  I thought that one thing that might push us towards DHCPv6 was desk VoIP 
phones since current desk IP phones depend on learning lots of special or extra 
info via DHCP.

  Assuming that desk IP phones don’t become extinct (not a certainty) and 
assuming that many desk IP phones will continue to be based on Android it seems 
that my assumption that desk IP phones will want DHCPv6 might not be correct.

  So what do the prognosticators think?  

  Will the desk IP phone vendors just add DHCPv6 to their version of Android or 
will they switch to other means to learn the info they now learn via DHCPv4?

---
Bruce Curtis bruce.cur...@ndsu.edu
Certified NetAnalyst II701-231-8527
North Dakota State University

Re: Android (lack of) support for DHCPv6

[Masataka Ohta]

I wrote:

> valdis.kletni...@vt.edu wrote:
> 
>> It only "just works" if your upstream device doesn't check/care that
>> you're emitting multiple MAC addresses from the same device.
> 
> What if a Wifi router checks that a device authenticated by a
> student's account uses only one IPv4, one IPv6 and one MAC
> addresses?
> 
> Can tethering still work?

I missed another condition. That is, the student's account can be
used to authenticate Wifi access for his/her device (not multiple
devices) but nothing else.

Is it a so unrealistic restriction?

Masataka Ohta

Re: Android (lack of) support for DHCPv6

[Masataka Ohta]

valdis.kletni...@vt.edu wrote:

> It only "just works" if your upstream device doesn't check/care that
> you're emitting multiple MAC addresses from the same device.

What if a Wifi router checks that a device authenticated by a
student's account uses only one IPv4, one IPv6 and one MAC
addresses?

Can tethering still work?

Masataka Ohta

Re: Android (lack of) support for DHCPv6

[Mark Tinka]

On 9/Jun/15 23:56, 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.
>
> Both companies need to pull their heads out of their asses.

Much like the router vendors fought, for years, over whether LDP or BGP
signaling was best for VPLS.

In the end, they came to their senses and support them both (largely
driven by customers voting with their wallets).

Mark.

DHCPv6 route option (was Re: Android (lack of) support for DHCPv6)

[Masataka Ohta]

Doug Barton wrote:

> No, you're not. Some of us have been saying that requiring RA is a bad 
> idea, and that adding features to it is a bad idea, for over 15 years now.

Need a DHCPv6 route option?

> Unfortunately the anti-DHCP crowd hasn't budged, no matter how many 
> operators have told them that they cannot manage an IPv6 network with 
> the current state of the protocol.

FYI, the operators suffering from a lack of feature of some standard
are free to have an agreement on how to use the private use part of
a number range in the standard controlled by someone else.

It is legal, harmless and IETF did so, for example, to map IPv6
multicast addresses to local (that is, not assigned by IEEE and
for private use) Ethernet group MAC addresses in section 7 of
rfc2464.

Thus, interested operators can have an agreement to use some
private use option values (224-254) of DHCPv6 for the route option.

Moreover, the agreement can be published as a NANOG/RIPE/APRICOT/...
recommendation or a some (newly formed) forum standard.

Then, some implementers are happily follow the recommendation/standard
in addition to IETF standards.

At least, ISC has done so, already.

https://www.isc.org/blogs/routing-configuration-over-dhcpv6-2/
The presented examples use values 242 for NEXT_HOP and 243
for RTPREFIX option codes.

Don't you want to increase the number of operators endorsing the
private assignments?

Masataka Ohta

Re: Android (lack of) support for DHCPv6

[Lyndon Nerenberg]

Where is Mr. Protocol?  When we need him most?!



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Android (lack of) support for DHCPv6

[Ray Soucy]

I like to think of it more like the command tent ;-)

On Wed, Jun 10, 2015 at 9:40 PM, Todd Underwood  wrote:

> Anyone who thinks Lorenzo hasn't been on the front lines of pushing for
> IPv6 adoption is pretty late to the party or confused about the state of
> affairs.
>
> T
>
> On Wed, Jun 10, 2015, 21:30 Ray Soucy  wrote:
>
>> I agree that some of the rhetoric should be toned down (go out for a beer
>> or something, guys ... I did).
>>
>> There is a difference between fiery debate with Lorenzo and a witch hunt,
>> and some of this is starting to sound a bit personal.  I shouldn't have
>> worded things the way I did, I went for the cheap shot in one of those
>> last
>> notes and that isn't really constructive.  I'm sorry.
>>
>> I think for many this thread represents years of frustration, though, and
>> LC making the statements in the way he did made him a focal point for that
>> frustration.
>>
>> The problem is there are many of us on the "front lines" trying to push
>> for
>> IPv6 adoption outside the bubble of idealism and when people of great
>> influence like LC take positions like DHCPv6 isn't required it's like a
>> slap in the face to all that effort.
>>
>> We really need to see Google and Android come on board with DHCPv6 support
>> and I'm interested in how we can help make that happen.
>>
>>
>>
>>
>>
>> On Wed, Jun 10, 2015 at 7:00 PM, Jeff McAdams  wrote:
>>
>> > No.
>> >
>> > Given that Lorenzo was posting with absolute statements about Google's
>> > approach, and with what they would do in the future in response to
>> > hypothetical standards developments, these questions are completely
>> valid.
>> >
>> > On Jun 10, 2015 5:24 PM, Michael Thomas  wrote:
>> > >
>> > > On 06/10/2015 02:51 PM, Paul B. Henson wrote:
>> > > >> From: Lorenzo Colitti
>> > > >> Sent: Wednesday, June 10, 2015 8:27 AM
>> > > >>
>> > > >> please do not construe my words on this thread as being Google's
>> > position
>> > > >> on anything. These messages were sent from my personal email
>> address,
>> > and I
>> > > >> do not speak for my employer.
>> > > > Can we construe your postings on the issue thread as being Google
>> > and/or Androids official position? They are posted by
>> lore...@google.com
>> > with a tag of "Project Member", and I believe you also declined the
>> request
>> > in the issue under that mantle.
>> > > >
>> > > >
>> > > Oh, stop this. The only thing this will accomplish is a giant black
>> hole
>> > > of silence from anybody at Google and any other $MEGACORP
>> > > in a similar situation.
>> > >
>> > > Mike
>> >
>>
>>
>>
>> --
>> 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
>>
>


-- 
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

Re: Android (lack of) support for DHCPv6

[Todd Underwood]

Anyone who thinks Lorenzo hasn't been on the front lines of pushing for
IPv6 adoption is pretty late to the party or confused about the state of
affairs.

T

On Wed, Jun 10, 2015, 21:30 Ray Soucy  wrote:

> I agree that some of the rhetoric should be toned down (go out for a beer
> or something, guys ... I did).
>
> There is a difference between fiery debate with Lorenzo and a witch hunt,
> and some of this is starting to sound a bit personal.  I shouldn't have
> worded things the way I did, I went for the cheap shot in one of those last
> notes and that isn't really constructive.  I'm sorry.
>
> I think for many this thread represents years of frustration, though, and
> LC making the statements in the way he did made him a focal point for that
> frustration.
>
> The problem is there are many of us on the "front lines" trying to push for
> IPv6 adoption outside the bubble of idealism and when people of great
> influence like LC take positions like DHCPv6 isn't required it's like a
> slap in the face to all that effort.
>
> We really need to see Google and Android come on board with DHCPv6 support
> and I'm interested in how we can help make that happen.
>
>
>
>
>
> On Wed, Jun 10, 2015 at 7:00 PM, Jeff McAdams  wrote:
>
> > No.
> >
> > Given that Lorenzo was posting with absolute statements about Google's
> > approach, and with what they would do in the future in response to
> > hypothetical standards developments, these questions are completely
> valid.
> >
> > On Jun 10, 2015 5:24 PM, Michael Thomas  wrote:
> > >
> > > On 06/10/2015 02:51 PM, Paul B. Henson wrote:
> > > >> From: Lorenzo Colitti
> > > >> Sent: Wednesday, June 10, 2015 8:27 AM
> > > >>
> > > >> please do not construe my words on this thread as being Google's
> > position
> > > >> on anything. These messages were sent from my personal email
> address,
> > and I
> > > >> do not speak for my employer.
> > > > Can we construe your postings on the issue thread as being Google
> > and/or Androids official position? They are posted by lore...@google.com
> > with a tag of "Project Member", and I believe you also declined the
> request
> > in the issue under that mantle.
> > > >
> > > >
> > > Oh, stop this. The only thing this will accomplish is a giant black
> hole
> > > of silence from anybody at Google and any other $MEGACORP
> > > in a similar situation.
> > >
> > > Mike
> >
>
>
>
> --
> 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
>

Re: Android (lack of) support for DHCPv6

[Ray Soucy]

I agree that some of the rhetoric should be toned down (go out for a beer
or something, guys ... I did).

There is a difference between fiery debate with Lorenzo and a witch hunt,
and some of this is starting to sound a bit personal.  I shouldn't have
worded things the way I did, I went for the cheap shot in one of those last
notes and that isn't really constructive.  I'm sorry.

I think for many this thread represents years of frustration, though, and
LC making the statements in the way he did made him a focal point for that
frustration.

The problem is there are many of us on the "front lines" trying to push for
IPv6 adoption outside the bubble of idealism and when people of great
influence like LC take positions like DHCPv6 isn't required it's like a
slap in the face to all that effort.

We really need to see Google and Android come on board with DHCPv6 support
and I'm interested in how we can help make that happen.





On Wed, Jun 10, 2015 at 7:00 PM, Jeff McAdams  wrote:

> No.
>
> Given that Lorenzo was posting with absolute statements about Google's
> approach, and with what they would do in the future in response to
> hypothetical standards developments, these questions are completely valid.
>
> On Jun 10, 2015 5:24 PM, Michael Thomas  wrote:
> >
> > On 06/10/2015 02:51 PM, Paul B. Henson wrote:
> > >> From: Lorenzo Colitti
> > >> Sent: Wednesday, June 10, 2015 8:27 AM
> > >>
> > >> please do not construe my words on this thread as being Google's
> position
> > >> on anything. These messages were sent from my personal email address,
> and I
> > >> do not speak for my employer.
> > > Can we construe your postings on the issue thread as being Google
> and/or Androids official position? They are posted by lore...@google.com
> with a tag of "Project Member", and I believe you also declined the request
> in the issue under that mantle.
> > >
> > >
> > Oh, stop this. The only thing this will accomplish is a giant black hole
> > of silence from anybody at Google and any other $MEGACORP
> > in a similar situation.
> >
> > Mike
>



-- 
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

Re: Android (lack of) support for DHCPv6

[Jeff McAdams]

No.

Given that Lorenzo was posting with absolute statements about Google's 
approach, and with what they would do in the future in response to hypothetical 
standards developments, these questions are completely valid.

On Jun 10, 2015 5:24 PM, Michael Thomas  wrote:
>
> On 06/10/2015 02:51 PM, Paul B. Henson wrote: 
> >> From: Lorenzo Colitti 
> >> Sent: Wednesday, June 10, 2015 8:27 AM 
> >> 
> >> please do not construe my words on this thread as being Google's position 
> >> on anything. These messages were sent from my personal email address, and 
> >> I 
> >> do not speak for my employer. 
> > Can we construe your postings on the issue thread as being Google and/or 
> > Androids official position? They are posted by lore...@google.com with a 
> > tag of "Project Member", and I believe you also declined the request in the 
> > issue under that mantle. 
> > 
> > 
> Oh, stop this. The only thing this will accomplish is a giant black hole 
> of silence from anybody at Google and any other $MEGACORP 
> in a similar situation. 
>
> Mike 

Re: Android (lack of) support for DHCPv6

[Valdis . Kletnieks]

On Wed, 10 Jun 2015 17:56:10 -0400, "George, Wes" said:

> WG] I made reference to it in a previous message, but since the question
> was repeated, I'll assume that was missed and repeat the answer. The
> hypervisor folks seem to have figured this out so that it "just works"
> without NAT, using virtual interfaces that have their own unique MAC
> addresses so that they look like unique hosts to the network/DHCP server.
> I'm using it on my FreeNAS (BSD) box at home with jails, and KVM supports
> it, so chances are it wouldn't even be that hard to incorporate into
> Android.

It only "just works" if your upstream device doesn't check/care that
you're emitting multiple MAC addresses from the same device.

Also, it assumes that some moral equivalent of proxy arp is available.


pgpRmMSx8yHHZ.pgp
Description: PGP signature

Re: Android (lack of) support for DHCPv6

[Michael Thomas]

On 06/10/2015 03:32 PM, George, Wes wrote:

From: Ted Hardie mailto:ted.i...@gmail.com>>
Date: Wednesday, June 10, 2015 at 6:09 PM
To: "George, Wes" mailto:wesley.geo...@twcable.com>>
Cc: Doug Barton mailto:do...@dougbarton.us>>, 
"nanog@nanog.org<mailto:nanog@nanog.org>" mailto:nanog@nanog.org>>
Subject: Re: Android (lack of) support for DHCPv6


I saw your response, but creating a hypervisor-equivalent network stack inside 
Android didn't seem particularly easy to me.  This may be, however, because 
I've mostly dealt with OVS-style approaches in the past few years and my 
calibration is off. If you have pointers to implementations that are for mobile 
devices, I'd be happy to be educated.

WG] I was merely observing that bridging so that multiple virtual 
interfaces/devices can share the same interface and get their own addresses is 
a solved problem generically. From what I can see with KVM, it involves 
creating a bridge interface or group, and bridging both the physical interface 
and any virtual interfaces into it, and then standing back. Doesn't seem 
obvious to me that it requires an entire hypervisor-equivalent network stack to 
get this one fairly limited feature, and I'm not aware of any mobile 
implementations, but it does seem to me that its presence in Linux makes it 
something we shouldn't dismiss out of hand when exploring solutions to this 
problem given Android's Linux roots - At it's core, it's still a 
general–purpose computer with a set of network interfaces. I'm not an expert on 
either Android's networking stack nor Linux's, nor hypervisors, but I have a 
hunch if this was allowed to move through the existing Android feature 
development process, we might find some folks that are and can tell us whether 
this is doable as an alternative to DHCP–PD or SLAAC on networks that generally 
adhere to the one address per device rule.


Besides, virtualizing the os environment on a phone would be a very 
interesting thing in its own right. I thought that
was gaining momentum at one point as a way to deal with the friction 
between corpro-IT demands of control, and
end user desire to keep nannyware crap off their phone -- just have two 
vm's with each environment.


Mike

Re: Android (lack of) support for DHCPv6

[Ca By]

Let's call off the witch hunt.

Please.

I get it, you want a DHCPv6 client.  "Star" the project or whatever you
think the right intake process is for an Android feature.

On Wed, Jun 10, 2015 at 2:51 PM, Paul B. Henson  wrote:

> > From: Lorenzo Colitti
> > Sent: Wednesday, June 10, 2015 8:27 AM
> >
> > please do not construe my words on this thread as being Google's position
> > on anything. These messages were sent from my personal email address,
> and I
> > do not speak for my employer.
>
> Can we construe your postings on the issue thread as being Google and/or
> Androids official position? They are posted by lore...@google.com with a
> tag of "Project Member", and I believe you also declined the request in the
> issue under that mantle.
>
> If your postings on the issue thread are not authoritative for Google,
> could you possibly put us in contact with who as Google could make an
> official statement as to why they are refusing to implement an accepted
> Internet standard already deployed by their competitors, the lack of which
> will directly harm their users?
>
>
>

Re: Android (lack of) support for DHCPv6

[Ted Hardie]

​In-line.

​
On Wed, Jun 10, 2015 at 3:10 PM, Doug Barton  wrote:

> On 6/10/15 2:46 PM, Ted Hardie wrote:
>
>> ​But understanding whether what we're actually
>> looking for is "static" or "single" is a pretty key piece of the
>> requirements scoping, and it sounds like "static" is it, at least from
>> your perspective.  Is that a fair assessment?
>>
>
> Ted,
>
> I honestly can't tell if you're deliberately misrepresenting my argument,
> or if you're just being dense. You snipped the several places in my
> previous message where I stated what I think the best way forward is. But
> just in case it's the latter, not the former:
>
> "I think PD is the right answer here of course ..."
>
> "Meanwhile, DHCPv6 + PD solves all of Lorenzo's stated problems, but he
> won't implement it because "DHCP." That's not something you can engineer
> around."
>
> Doug
>
>
​I think we lost context here.  I started out asking a question in response
to this statement by Matthew Huff:


Authentication, Authorization, Accounting, ACLS, NMS, IDS, IP management,
> custom software, and other roadblocks will certainly stall if not stop IPv6
> deployments in enterprises if there isn’t at least the choice of static,
> single IPv6 addresses per device​


​My question was whether a mechanism that could provide a consistent
mapping from prefix to user (or device) met the requirements above,
whatever size the prefix provided happened to be.  I wasn't trying to probe
for which mechanism in that part of the question.  I understand from your
comments that you prefer DHCPv6 +PD.

regards,

Ted



-- 
> I am conducting an experiment in the efficacy of PGP/MIME signatures. This
> message should be signed. If it is not, or the signature does not validate,
> please let me know how you received this message (direct, or to a list) and
> the mail software you use. Thanks!
>
>

Re: Android (lack of) support for DHCPv6

[George, Wes]

From: Ted Hardie mailto:ted.i...@gmail.com>>
Date: Wednesday, June 10, 2015 at 6:09 PM
To: "George, Wes" mailto:wesley.geo...@twcable.com>>
Cc: Doug Barton mailto:do...@dougbarton.us>>, 
"nanog@nanog.org<mailto:nanog@nanog.org>" 
mailto:nanog@nanog.org>>
Subject: Re: Android (lack of) support for DHCPv6


I saw your response, but creating a hypervisor-equivalent network stack inside 
Android didn't seem particularly easy to me.  This may be, however, because 
I've mostly dealt with OVS-style approaches in the past few years and my 
calibration is off. If you have pointers to implementations that are for mobile 
devices, I'd be happy to be educated.

WG] I was merely observing that bridging so that multiple virtual 
interfaces/devices can share the same interface and get their own addresses is 
a solved problem generically. From what I can see with KVM, it involves 
creating a bridge interface or group, and bridging both the physical interface 
and any virtual interfaces into it, and then standing back. Doesn't seem 
obvious to me that it requires an entire hypervisor-equivalent network stack to 
get this one fairly limited feature, and I'm not aware of any mobile 
implementations, but it does seem to me that its presence in Linux makes it 
something we shouldn't dismiss out of hand when exploring solutions to this 
problem given Android's Linux roots - At it's core, it's still a 
general–purpose computer with a set of network interfaces. I'm not an expert on 
either Android's networking stack nor Linux's, nor hypervisors, but I have a 
hunch if this was allowed to move through the existing Android feature 
development process, we might find some folks that are and can tell us whether 
this is doable as an alternative to DHCP–PD or SLAAC on networks that generally 
adhere to the one address per device rule.

Thanks
Wes


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Android (lack of) support for DHCPv6

[Michael Thomas]

On 06/10/2015 02:51 PM, Paul B. Henson wrote:

From: Lorenzo Colitti
Sent: Wednesday, June 10, 2015 8:27 AM

please do not construe my words on this thread as being Google's position
on anything. These messages were sent from my personal email address, and I
do not speak for my employer.

Can we construe your postings on the issue thread as being Google and/or Androids 
official position? They are posted by lore...@google.com with a tag of "Project 
Member", and I believe you also declined the request in the issue under that mantle.


Oh, stop this. The only thing this will accomplish is a giant black hole 
of silence from anybody at Google and any other $MEGACORP

in a similar situation.

Mike

Re: Android (lack of) support for DHCPv6

[Doug Barton]

On 6/10/15 2:46 PM, Ted Hardie wrote:

​That's fair enough, and some variability in what N is depending on
device is as a well.  But understanding whether what we're actually
looking for is "static" or "single" is a pretty key piece of the
requirements scoping, and it sounds like "static" is it, at least from
your perspective.  Is that a fair assessment?


Ted,

I honestly can't tell if you're deliberately misrepresenting my 
argument, or if you're just being dense. You snipped the several places 
in my previous message where I stated what I think the best way forward 
is. But just in case it's the latter, not the former:


"I think PD is the right answer here of course ..."

"Meanwhile, DHCPv6 + PD solves all of Lorenzo's stated problems, but he 
won't implement it because "DHCP." That's not something you can engineer 
around."


Doug

--
I am conducting an experiment in the efficacy of PGP/MIME signatures. 
This message should be signed. If it is not, or the signature does not 
validate, please let me know how you received this message (direct, or 
to a list) and the mail software you use. Thanks!




signature.asc
Description: OpenPGP digital signature

Re: Android (lack of) support for DHCPv6

[Ted Hardie]

On Wed, Jun 10, 2015 at 2:56 PM, George, Wes 
wrote:

>
> On 6/10/15, 5:27 PM, "Ted Hardie"  wrote:
>
> >>... and this argument has been refuted by the word "bridging."
> >>
> >>
> >​To repeat Valdis' question:​
> >
> >​And the router knows to send to the "front" address to reach the "back"
> >> address, how, exactly? Seems like somebody should invent a way to
> >>assign a
> >> prefix to the front address that it can delegate to things behind it.
> >>:)​
>
> WG] I made reference to it in a previous message, but since the question
> was repeated, I'll assume that was missed and repeat the answer. The
> hypervisor folks seem to have figured this out so that it "just works"
> without NAT, using virtual interfaces that have their own unique MAC
> addresses so that they look like unique hosts to the network/DHCP server.
> I'm using it on my FreeNAS (BSD) box at home with jails, and KVM supports
> it, so chances are it wouldn't even be that hard to incorporate into
> Android.
>
> Thanks
> Wes
>
>
> ​Hi Wes,

I saw your response, but creating a hypervisor-equivalent network stack
inside Android didn't seem particularly easy to me.  This may be, however,
because I've mostly dealt with OVS-style approaches in the past few years
and my calibration is off. If you have pointers to implementations that are
for mobile devices, I'd be happy to be educated.

regards,

Ted




> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>

Re: Android (lack of) support for DHCPv6

[Michael Thomas]

On 06/10/2015 02:36 PM, Doug Barton wrote:


It *could*, but Lorenzo actually does have a point when he talks about 
not wanting to cripple future application development. I'd also like 
to see a rough outline of an implementation before commenting further.


Meanwhile, DHCPv6 + PD solves all of Lorenzo's stated problems, but he 
won't implement it because "DHCP." That's not something you can 
engineer around.

???

I thought Lorenzo was fine with DHCPv6 so long as it was with PD?

Mike

Re: Android (lack of) support for DHCPv6

[George, Wes]

On 6/10/15, 5:27 PM, "Ted Hardie"  wrote:

>>... and this argument has been refuted by the word "bridging."
>>
>>
>​To repeat Valdis' question:​
>
>​And the router knows to send to the "front" address to reach the "back"
>> address, how, exactly? Seems like somebody should invent a way to
>>assign a
>> prefix to the front address that it can delegate to things behind it.
>>:)​

WG] I made reference to it in a previous message, but since the question
was repeated, I'll assume that was missed and repeat the answer. The
hypervisor folks seem to have figured this out so that it "just works"
without NAT, using virtual interfaces that have their own unique MAC
addresses so that they look like unique hosts to the network/DHCP server.
I'm using it on my FreeNAS (BSD) box at home with jails, and KVM supports
it, so chances are it wouldn't even be that hard to incorporate into
Android.

Thanks
Wes


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Lorenzo Colitti
> Sent: Wednesday, June 10, 2015 8:27 AM
> 
> please do not construe my words on this thread as being Google's position
> on anything. These messages were sent from my personal email address, and I
> do not speak for my employer.

Can we construe your postings on the issue thread as being Google and/or 
Androids official position? They are posted by lore...@google.com with a tag of 
"Project Member", and I believe you also declined the request in the issue 
under that mantle.

If your postings on the issue thread are not authoritative for Google, could 
you possibly put us in contact with who as Google could make an official 
statement as to why they are refusing to implement an accepted Internet 
standard already deployed by their competitors, the lack of which will directly 
harm their users?

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Ray Soucy
> Sent: Wednesday, June 10, 2015 6:06 AM
>
> As for thinking "long term" and "the future", we need devices to work
> within current models of IPv6 to accelerate _adoption_ of IPv6 _today_
> before we can get to that future you're talking about.
> 
> Not supporting DHCPv6 ultimately holds back adoption, which makes people
> see IPv6 as optional for longer, and discourages deployment because vendor
> support is all over the place and seen as "not ready".
> 
> This isn't theory, we've been _living_ with this as a reality for years
> now.  The networks are ready; the clients are not.
> 
> Universities see a constant stream of DMCA violation notices that need to
> be dealt with and not being able to associate a specific IPv6 address to a
> specific user is a big enough liability that the only option is to not use
> IPv6.  As I said, Android becomes a second class citizen on the network
> under your model.

Your ideas are intriguing to me and I wish to subscribe to your newsletter ;).

When someone shows up with a device that only supports WEP, or doesn't support 
WPA2-Enterprise, we tell them they need to replace it with a device supporting 
current standards that provide the minimum level of security we have decided 
upon for our network policy. When someone shows up with an android device that 
can't connect to our IPv6 network, we will tell them to replace it with a 
device that fully supports current standards.

I still find it hard to believe that Google as a corporate entity thinks it is 
more important to try and force network operators to conform to their ideals 
for configuration than it is to make android feature equivalent with its 
competitors.

Re: Android (lack of) support for DHCPv6

[Ted Hardie]

On Wed, Jun 10, 2015 at 2:36 PM, Doug Barton  wrote:

>
>
>>
>
>  ​The other option would, of course, be "bridging" plus IPv6 "NAT", and I
>> assume you see the issues there.​
>>
>
> No, actually I don't. I realize that you and Lorenzo are part of the rabid
> NAT-hating crowd, but I'm not. I don't think it's the right answer here,
> but I don't think it's automatically a problem either.
>

​So, I don't think I'm particularly rabid about this, but I have dealt for
a long time on the application side with the side effects.  Anyone who has
had to engineer a system that requires STUN/TURN/ICE can tell you that it
is pretty much a dancing bear.  The wonder is how sweetly the bear dances,
but that it dances at all.  If one of the things I'm tethering wants to do
RTCWEB, it's going to be painful if it doesn't have its own address,
because it will need to hairpin out to do STUN at the very least.​


>  ​Back to the question I asked before:  does "static" solve the stated
>> problems without "single"?
>>
>
> It *could*, but Lorenzo actually does have a point when he talks about not
> wanting to cripple future application development. I'd also like to see a
> rough outline of an implementation before commenting further.
>

​That's fair enough, and some variability in what N is depending on device
is as a well.  But understanding whether what we're actually looking for is
"static" or "single" is a pretty key piece of the requirements scoping, and
it sounds like "static" is it, at least from your perspective.  Is that a
fair assessment?

regards,

Ted​




>
> --
> I am conducting an experiment in the efficacy of PGP/MIME signatures. This
> message should be signed. If it is not, or the signature does not validate,
> please let me know how you received this message (direct, or to a list) and
> the mail software you use. Thanks!
>
>

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Lorenzo Colitti
> Sent: Wednesday, June 10, 2015 5:22 AM
> 
> It's certainly a possibility for both sides in this debate to say "my way
> or the highway", and wait and see what happens when operators start
> removing support for IPv4.

You are rather confused.

Only one side of this debate is saying "my way or the highway" – yours.

On my side, I am saying that it is my network, and it is not only my right but 
my responsibility to define policies as to how it should be used. That could be 
by blocking port 25 outbound to prevent spam abuse, or by forbidding 
unauthenticated wireless access points, or by requiring WPA2-enterprise 
authentication to connect, or any other technical configuration determined to 
be needed or desired by our policy. Can anyone reasonably say that a provider 
of a network is not allowed to determine the policies by which that network 
must be used 8-/?

On the other hand, *you* are providing infrastructure. You are refusing to 
implement agreed-upon Internet standards that are already widely supported. You 
are trying to determine what policy we should use on our network. It is 
completely different. I'm sorry you cannot see that.

> But even if you're dead set on using DHCPv6, what I don't see is why don't
> you support DHCPv6 PD instead of IA_NA?

Perhaps we will support it in addition to. Or perhaps we will not support it at 
all as that use pattern might not be desirable on our network. However, I am 
quite certain all of the equipment we purchase and recommend to purchase will 
support both standards, as well as SLACC and all other standards that have been 
defined as a base part of IPv6 support. As providers of infrastructure should. 
And then we will choose which of them to deploy. As managers of networks should.

> more than one IPv6 address and cannot be done without that. We know these
> will break today; tomorrow, we can use multiple addresses to do things we
> haven't thought of yet.

Who knows, maybe IPv12 will solve all of these issues? Maybe we shouldn't 
bother trying to deploy IPv6 while we're waiting for somebody to design and 
implement IPv12.

Re: Android (lack of) support for DHCPv6

[Mark Andrews]

In message 
, Ray Soucy writes:
> The whole conversation is around 464XLAT on IPv6-only networks right?
> We're going to be dual-stack for a while IMHO, and by the time we can get
> away with IPv6 only for WiFi, 464 should no longer be relevant because
> we'll have widespread IPv6 adoption by then.

Or just support DS-Lite along with DHCPv6.

DS-Lite does not require its own IPv6 address.
464XLAT and DS-Lite both limit IPv4 packet sizes to less than native.
DS-Lite works with DNSSEC.  DNS64 doesn't.
DS-Lite doesn't require mucking with packet contents.
DS-Lite doesn't result in sites being unreachable just because the IPv6
instance is down which is a side effect of DNS64.
 
> Carriers can do IPv6 only because they tightly control the clients, for
> WiFi clients are and will always be all over the place, so dual stack will
> be pretty much a given for a long time.
> 
> 
> On Wed, Jun 10, 2015 at 9:50 AM, George, Wes 
> wrote:
> 
> >
> > On 6/10/15, 2:32 AM, "Lorenzo Colitti"  wrote:
> >
> > >I'd be happy to work with people on an Internet draft or other
> > >standard to define a minimum value for N, but I fear that it may not
> > >possible to gain consensus on that.
> >
> > WG] No, I think that the document you need to write is the one that
> > explains why a mobile device needs multiple addresses, and make some
> > suggestions about the best way to support that. Your earlier response
> > detailing those vs how they do it in IPv4 today was the first a lot of us
> > have heard of that, because we're not in mobile device development and
> > don't necessarily understand the secret sauce involved. This is especiall=
> y
> > true for your mention of things like WiFi calling, and all of the other
> > things that aren't tethering or 464xlat, since neither of those are as
> > universally agreed-upon as "must have" on things like enterprise networks=
> .
> > I'm sure there are also use cases we haven't thought of yet, so I'm not
> > trying to turn this into a debate about which use cases are valid, just
> > observing that you might get more traction with the others.
> >
> >
> > >Asking for more addresses when the user tries to enable features such as
> > >tethering, waiting for the network to reply, and disabling the features =
> if
> > >the network does not provide the necessary addresses does not seem like =
> it
> > >would provide a good user experience.
> >
> > WG] Nor does not having IPv6 at all, and being stuck behind multiple
> > layers of NAT, but for some reason you seem ok with that, which confuses
> > me greatly. The amount of collective time wasted arguing this is likely
> > more than enough to come up with cool ways to optimize the ask/wait/enabl=
> e
> > function so that it doesn't translate to a bad user experience, and few
> > things on a mobile device are instantaneous anyway, so let's stop acting
> > like it's an unsolvable problem.
> >
> > Thanks,
> >
> > Wes
> >
> >
> > Anything below this line has been added by my company=E2=80=99s mail serv=
> er, I
> > have no control over it.
> > --
> >
> >
> > This E-mail and any of its attachments may contain Time Warner Cable
> > proprietary information, which is privileged, confidential, or subject to
> > copyright belonging to Time Warner Cable. This E-mail is intended solely
> > for the use of the individual or entity to which it is addressed. If you
> > are not the intended recipient of this E-mail, you are hereby notified th=
> at
> > any dissemination, distribution, copying, or action taken in relation to
> > the contents of and attachments to this E-mail is strictly prohibited and
> > may be unlawful. If you have received this E-mail in error, please notify
> > the sender immediately and permanently delete the original and any copy o=
> f
> > this E-mail and any printout.
> >
> 
> 
> 
> --=20
> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Android (lack of) support for DHCPv6

[Doug Barton]

On 6/10/15 2:27 PM, Ted Hardie wrote:



On Wed, Jun 10, 2015 at 2:16 PM, Doug Barton mailto:do...@dougbarton.us>> wrote:

On 6/10/15 2:00 PM, Ted Hardie wrote:

Lorenzo has detailed why N=1 doesn't work for devices that need
to use xlat


... and it's been well demonstrated that this is a red herring
argument since the provider has to configure xlat for it to have any
chance of working.

or which might want to tether other devices;


... and this argument has been refuted by the word "bridging."


​To repeat Valdis' question:​

​And the router knows to send to the "front" address to reach the
"back" address, how, exactly? Seems like somebody should invent a
way to assign a prefix to the front address that it can delegate to
things behind it.  :)​


I saw that, he was refuted by others, most notably by the simple fact 
that bridging works now in IPv4, so obviously there is a way to make it 
work.


I think PD is the right answer here of course, but that doesn't mean 
that bridging is the wrong answer.



​The other option would, of course, be "bridging" plus IPv6 "NAT", and I
assume you see the issues there.​


No, actually I don't. I realize that you and Lorenzo are part of the 
rabid NAT-hating crowd, but I'm not. I don't think it's the right answer 
here, but I don't think it's automatically a problem either.



​Back to the question I asked before:  does "static" solve the stated
problems without "single"?


It *could*, but Lorenzo actually does have a point when he talks about 
not wanting to cripple future application development. I'd also like to 
see a rough outline of an implementation before commenting further.


Meanwhile, DHCPv6 + PD solves all of Lorenzo's stated problems, but he 
won't implement it because "DHCP." That's not something you can engineer 
around.


Doug

--
I am conducting an experiment in the efficacy of PGP/MIME signatures. 
This message should be signed. If it is not, or the signature does not 
validate, please let me know how you received this message (direct, or 
to a list) and the mail software you use. Thanks!




signature.asc
Description: OpenPGP digital signature

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Lorenzo Colitti
> Sent: Wednesday, June 10, 2015 5:07 AM
> 
> getting rid of NAT. Today in IPv4, tethering just works, period.
[...]
> IPv4-only apps always work.

Wow. If your phone just "always works", you certainly lead a charmed life.

> A model where the device has to request resources from the network before
> enabling tethering, or before supporting IPv4-only apps, provides a much
> worse user experience. The user might have to wait a long time, or the
> operation might even fail.

Far better that the user stare at the useless android brick in their hand that 
is incapable of connecting to the network at all.

Maybe you should try taking a poll of actual users? Dear user, would you rather:

A) have a phone that connects to the network and the most part works barring 
some side cases

B) have a phone that is incapable of connecting, but saves you from being 
unable to use certain functionality that otherwise would have been unavailable. 
By preventing you from using any functionality at all.

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Ray Soucy
> Sent: Wednesday, June 10, 2015 4:36 AM
> 
> In practice, your device will just not be supported.
[..]
> If your client is broken because of an incomplete implementation, I just
> won't give it an IPv6 address at all.  I think a lot of others feel the
> same way.
[...]
> already provide ubiquitous wireless coverage.  I don't want users enabling
> a hotspot (rogue AP) on campus because it has a negative impact on service
> for others, so the whole argument is really meaningless in the context of
> higher education and campus networking.

Yes. That. All of that. I think you'll find a lot of higher education 
institutions will agree with this viewpoint.

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Mikael Abrahamsson
> Sent: Wednesday, June 10, 2015 12:05 AM
> 
> You seem to fail to realise that you are not Lorenzos customer, his
> customer is the OEMs that build mobile phones, and their customers who buy
> Android phones.

And he fails to realize that the people who buy android phones actually want
them to work. And the companies manufacturing android phones want their
users to be satisfied. And when every single mobile phone other than an
android phone does seem to work, who do you think they're going to blame? I
can already tell you our helpdesk response "Unfortunately, the android
operating system does not fully implement IPv6 standards and as such is not
capable of interoperating with our network. Consider switching to an iPhone,
or a Windows Phone, or a [every other phone that works]."

> So while you are doing what you think is best for your network, Lorenzo is
> doing what he thinks is best for his platform and the hundreds of millions
> of Android users that are out there.

I am sure all of those millions of users sleep better at night knowing that
omniscient and caring Lorenzo is looking out for their long-term interests
while denying them short-term usability.

> So I happen to agree with Lorenzo that a single IA_NA per device world is
> a crippled world. Lorenzo said he was willing to work on a document that
> creates a recommendation for certain minimum amount of IPv6 addresses per
> device and/or PD, so let's get that happening then?

How about we support existing already widely deployed Internet standards so
they can be used while future standards are being developed?

Re: Android (lack of) support for DHCPv6

[Ted Hardie]

On Wed, Jun 10, 2015 at 2:16 PM, Doug Barton  wrote:

> On 6/10/15 2:00 PM, Ted Hardie wrote:
>
>> Lorenzo has detailed why N=1 doesn't work for devices that need to use
>> xlat
>>
>
> ... and it's been well demonstrated that this is a red herring argument
> since the provider has to configure xlat for it to have any chance of
> working.
>
>  or which might want to tether other devices;
>>
>
> ... and this argument has been refuted by the word "bridging."
>
>
​To repeat Valdis' question:​

​And the router knows to send to the "front" address to reach the "back"
> address, how, exactly? Seems like somebody should invent a way to assign a
> prefix to the front address that it can delegate to things behind it.  :)​
>

​The other option would, of course, be "bridging" plus IPv6 "NAT", and I
assume you see the issues there.​

​Back to the question I asked before:  does "static" solve the stated
problems without "single"?

regards,

Ted​

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Lorenzo Colitti
> Sent: Tuesday, June 09, 2015 11:33 PM
>
> value of N. I'd be happy to work with people on an Internet draft or other
[...]
> It's also possible for Android to support DHCPv6 PD. Again I'd be happy to
> work with people on a document that says that mobile devices should do

It would be nice if you were happy to work with people on actually implementing 
what they are asking for and what their users need as opposed to just methods 
to try and twist the world to your personal viewpoint.

Or maybe even just merging work somebody already did well over a year ago?

https://android-review.googlesource.com/#/c/78857/

> Asking for more addresses when the user tries to enable features such as
> tethering, waiting for the network to reply, and disabling the features if
> the network does not provide the necessary addresses does not seem like it
> would provide a good user experience.

Absolutely; having a device incapable of connecting at all is a *much* better 
user experience. Have you ever met a user 8-/?

Re: Android (lack of) support for DHCPv6

[Doug Barton]

On 6/9/15 1:27 PM, Joel Maslak wrote:

Agreed - apparently the solution is to implement SLAAC + DNS advertisements
*AND* DHCPv6.  Because you need SLAAC + DNS advertisements for Android, and
you need DHCPv6 for Windows.

Am I the only one that thinks this situation is stupid?


No, you're not. Some of us have been saying that requiring RA is a bad 
idea, and that adding features to it is a bad idea, for over 15 years now.


Unfortunately the anti-DHCP crowd hasn't budged, no matter how many 
operators have told them that they cannot manage an IPv6 network with 
the current state of the protocol.


Doug

--
I am conducting an experiment in the efficacy of PGP/MIME signatures. 
This message should be signed. If it is not, or the signature does not 
validate, please let me know how you received this message (direct, or 
to a list) and the mail software you use. Thanks!




signature.asc
Description: OpenPGP digital signature

Re: Android (lack of) support for DHCPv6

[Doug Barton]

On 6/10/15 8:15 AM, Ray Soucy wrote:

The statement that "Android would still not implement DHCPv6 NA, but it
would implement DHCPv6 PD." is troubling because you're not even willing to
entertain the idea for reasons that are rooted in idealism rather
than pragmatism.


I was going to respond on this issue in more depth, but others have 
already gotten there ahead of me. I think Ray's paragraph above sums it 
up best.


Doug

--
I am conducting an experiment in the efficacy of PGP/MIME signatures. 
This message should be signed. If it is not, or the signature does not 
validate, please let me know how you received this message (direct, or 
to a list) and the mail software you use. Thanks!




signature.asc
Description: OpenPGP digital signature

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Lorenzo Colitti
> Sent: Tuesday, June 09, 2015 7:49 PM
> 
> That sounds pretty stupid even for me, so probably something got lost in
> translation.

"Implementing stateful DHCPv6 would break planned use cases such as IPv6 
tethering"

"And it's not possible to enable tethering"

"tethering cannot be made to work well"

"what do you expect Android to do if given only one IPv6 address and the user 
turns on tethering"

'Saying "tethering is not available" is not going to fly'

Yes, while you have mentioned a few other things, based on your postings on the 
issue thread tethering seems to be one of your hot topics.

> I think what I said is that supporting DHCPv6-only networks will eventually 
> force
> OS manufacturers to implement IPv6 NAT.

As opposed to not supporting DHCPv6 operation forcing users to adopt phones 
based on operating systems other than android?
 
> You don't "have to do" SLAAC and RDNSS. For as long as the network provides
> IPv4, there won't be a problem for anyone.

Thank you very much for being the guy in charge of determining what my problems 
are.

As I already mentioned in the issue thread, one of our motivations for moving 
forward with IPv6 deployment is that some grants our faculty want to apply for 
require native IPv6 communication. So an android device that is incapable of 
connecting to our IPv6 network due to deficiencies in its implementation of 
IPv6 standards will not be usable for that grant work. But I will be sure to 
tell the faculty that the android developer responsible for that breakage 
assures them it is not a problem. After which I will encourage them to switch 
to another platform which provides for its users' needs rather than its 
developers' crusades.

Re: Android (lack of) support for DHCPv6

[Doug Barton]

On 6/10/15 2:00 PM, Ted Hardie wrote:

Lorenzo has detailed why N=1 doesn't work for devices that need to use xlat


... and it's been well demonstrated that this is a red herring argument 
since the provider has to configure xlat for it to have any chance of 
working.



or which might want to tether other devices;


... and this argument has been refuted by the word "bridging."

I'm not a fan of N=1 for IPv6, but none of Lorenzo's arguments hold water.


--
I am conducting an experiment in the efficacy of PGP/MIME signatures. 
This message should be signed. If it is not, or the signature does not 
validate, please let me know how you received this message (direct, or 
to a list) and the mail software you use. Thanks!




signature.asc
Description: OpenPGP digital signature

Re: Android (lack of) support for DHCPv6

[Ricky Beam]

On Wed, 10 Jun 2015 00:58:06 -0400, Lorenzo Colitti   
wrote:

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?


We aren't asking you to support BGP, or SNMP. We're DEMANDING you support  
a FUNDAMENTAL COMPONENT of IPv6. DHCPv6 is not *optional*. And every  
reason you've given to date sounds like a whiny I-Don't-Like-It political  
agenda. The fact that others have made it work is proof of your  
asshattery. This has been going around for **YEARS**. You've spent orders  
of magnitude more time defending your "no" position than it would take to  
actually include DHCPv6 support. In *two days* of bitching on NANOG, every  
one of your positions has been shot down, and solutions to every corner  
case has been presented -- sure, the network policy could still render  
things non-workable (no PD, only one address, etc.)


Will IPv4 only apps work with only one v6 address, no. (or "not easily")  
But then, IPv4 isn't IPv6; any kludge to get one to work within the other  
is 100% BS hackery (because no one thought about migration or  
interoperability. dual-stack was declared the answer, and the WG patted  
themselves on the back.)


Given the choice of ZERO network access, or ("legacy" ???) IPv4 only apps  
not working, I'll take the later. The people in charge of those lacking  
apps need to fix their shit.

Re: Android (lack of) support for DHCPv6

[Ted Hardie]

On Wed, Jun 10, 2015 at 11:51 AM, Matthew Huff  wrote:

> +1
>
> One IP per device will almost most likely be the preference and
> implementation in corporate/enterprise deployments. Too much procedure,
> regulation and other roadblocks prevent any other solution.
>
> Authentication, Authorization, Accounting, ACLS, NMS, IDS, IP management,
> custom software, and other roadblocks will certainly stall if not stop IPv6
> deployments in enterprises if there isn’t at least the choice of static,
> single IPv6 addresses per device. SLAAC will probably be a complete
> non-starter in many corporate environments. It is in ours. The more
> ideologues preach about restoring peer-to-peer connectivity, dynamic IPs,
> privacy addresses, etc… the less penetration IPv6 will happen in corporate
> networks.
>
>
> So, the critical piece of what you assert above appears to be "static",
not "single".  If a local address management system is always configured to
hand out the same /N to the same device, there doesn't seem to be a
requirement in the above that N=1.

Lorenzo has detailed why N=1 doesn't work for devices that need to use xlat
or which might want to tether other devices; he's volunteered to work with
folks on a document and to write code for the case where a device
successfully gets a useful value of N>1.

Can you help me understand why that doesn't work for you?

On the related topic of privacy addresses, I believe we should all be ready
for increasing variability in MAC address emitted by devices, and that if
you are intending to use MAC auth to assign that /N, you may now  be or
will soon be surprised.  In addition to the work Apple has done and which
can be done with Android, see the IEEE work here:

http://www.ieee802.org/PrivRecsg/

regards,

Ted

Re: Android (lack of) support for DHCPv6

[Josh Reynolds]

Memory is cheap, ASICs and FPGAs are getting better all the time.

It might be a problem a few years from now for older hardware, but I 
can't see it causing real issues long term.


Josh Reynolds
CIO, SPITwSPOTS
www.spitwspots.com

On 06/10/2015 12:42 PM, Florian Weimer wrote:

* Lorenzo Colitti:


I think what I said is that supporting DHCPv6-only networks will eventually
force OS manufacturers to implement IPv6 NAT. This is because there are
many features inside a mobile OS that require multiple IP addresses.

On many networks, there will be fairly tight limits on the number of
usable addresses per “port” even with SLAAC, similar to the evolution
of Ethernet switching, which led to configurable limits of MAC
addresses per port.  So you'll likely need IPv6 NAT in the future
anyway.

Re: Android (lack of) support for DHCPv6

[Florian Weimer]

* Lorenzo Colitti:

> I think what I said is that supporting DHCPv6-only networks will eventually
> force OS manufacturers to implement IPv6 NAT. This is because there are
> many features inside a mobile OS that require multiple IP addresses.

On many networks, there will be fairly tight limits on the number of
usable addresses per “port” even with SLAAC, similar to the evolution
of Ethernet switching, which led to configurable limits of MAC
addresses per port.  So you'll likely need IPv6 NAT in the future
anyway.

Re: Android (lack of) support for DHCPv6

[Tore Anderson]

* Dave Taht

> I am told that well over 50% of all android development comes from
> volunteer developers so rather than kvetching about this it seems
> plausible for an outside effort to get the needed features for
> tethering and using dhcpv6-pd into it. If someone wanted to do the
> work.

https://android-review.googlesource.com/#/c/78857/

Tore

Re: Android (lack of) support for DHCPv6

[Tore Anderson]

* Lorenzo Colitti

> > On the other hand, there exist applications *today* that do require
> > DHCPv6. One such example would be MAP, which IMHO is superior to
> > 464XLAT both for the network operator (statlessness ftw) as well as
> > for the end user (unsolicited inbound packets work, no NAT traversal
> > required). MAP is provisioned with DHCPv6
> > (I-D.ietf-softwire-map-dhcp), so without DHCPv6 support in Android,
> > MAP support in Android is a non-starter.
> >
> 
> Support for the DHCPv6 protocol, or support for assigning addresses
> from IA_NA?

I'm not 100% certain, but you can possibly run MAP without IA_NA. But I
think you'll need the CE to be configured with a predictable IPv6
address so that the BR knows where to send the IPv6-encapsulated or
-translated IPv4 packets. I don't see how that would work with SLAAC.
But I'm not a MAP expert, so I'm open to be educated otherwise.

Anyway, here's a (hopefully constructive) suggestion on a way forward:

* Implement DHCPv6 client support (IA_NA, IA_TA, IA_PD .. the works)
* Upon network connection, request 2x IA_NA and 1x IA_PD (in addition
  to SLAAC):
** If you get addressing from SLAAC and/or IA_PD, accept the
   configuration and connect to the network.
*** If apps/services require additional addresses, self-assign them
from the on-link/delegated prefix as needed.
** If you get 2x IA_NA, accept the configuration and connect to the
   network.
*** If apps/services requires additional addresses, request additional
IA_NA as needed.
 If additional IA_NAs are declined either warn user or trigger
 Android's already existing «avoided bad network» functionality.
** If you get no SLAAC or IA_PD, and IA_NA <= 1, then refuse to
   connect to the network (or, for a dual-stack network, connect
   IPv4-only). (I.e., same behaviour as on a DHCPv6-only network
   today.)

Why N=2? Because it's >1, and what you seem to be worried about is
operators using N=1 without thought ("because that's what we did in
IPv4"). N=2 will confirm that's not the case for the given network, so
I think confirming N=2 gives a much stronger indication that the
network allows N= than confirming N=1.

That said, I doubt that you can rely on the network accepting
N=, neither for DHCPv6 IA_NA *nor* SLAAC, due to
neighbour table limitations and DAD overhead (both delay and packets).
If the future applications we're imagining needs IPv6 addresses in that
ballpark (which isn't *that* far-fetched - say a new address per
connection, process, app, whatever), IA_PD is the only mechanism we have
today that will work. If you start supporting IA_PD, my bet networks
are going to start offering it - just like when you added 464XLAT.

Tore

Re: Android (lack of) support for DHCPv6

[Matthew Huff]

+1

One IP per device will almost most likely be the preference and implementation 
in corporate/enterprise deployments. Too much procedure, regulation and other 
roadblocks prevent any other solution.

Authentication, Authorization, Accounting, ACLS, NMS, IDS, IP management, 
custom software, and other roadblocks will certainly stall if not stop IPv6 
deployments in enterprises if there isn’t at least the choice of static, single 
IPv6 addresses per device. SLAAC will probably be a complete non-starter in 
many corporate environments. It is in ours. The more ideologues preach about 
restoring peer-to-peer connectivity, dynamic IPs, privacy addresses, etc… the 
less penetration IPv6 will happen in corporate networks.



> On Jun 10, 2015, at 2:11 PM, Ray Soucy  wrote:
> 
> I've already written systems to do this kind of thing, but the logging
> requirements quickly go through the roof for a non-trivial network;
> especially in the case of temporary addressing now default on many
> systems.  That isn't so much the issue as operational consistency and
> supportability.
> 
> The requirement for hosts to be dual stack will exist for some time.
> 
> For the sanity of IT workers and users alike (most of which don't really
> know the details of IPv6 and barely understand address scopes let alone
> multiple addresses) there needs to be some level of consistency between how
> hosts are addressed and communicate between the two protocols.  Saying
> we'll develop one system for IPv4 and one for IPv6 ultimate results in
> "Let's not deploy IPv6 just yet".
> 
> This rings especially true when security concerns come up.  Consistency
> between IPv4 and IPv6 needs to be possible in this transition period, or
> people simply decide to not deploy.  Consistency in addressing and
> maintaining a one host one address model has major implications for policy
> construction, flow analysis and incident response, denial of service
> mitigation, etc.  If the consistency isn't there, you need to "re-invent
> the wheel" for every aspect, then maintain different systems for IPv4 and
> IPv6 along side one another.
> 
> Even worse, if we keep seeing adoption held up by inconsistent client
> implementations I fear we'll start seeing commercial products which NAT or
> proxy IPv4 to IPv6 to avoid using IPv6 internally.  It's very ugly and
> requires some DNS magic to work, but it's not impossible.  We're already
> seeing this in terms of cloud computing and virtualization.  Servers have
> IPv4 addresses and only a load balancer with an external IPv6 address.
> 
> We absolutely need to make it possible for people to adopt IPv6 before we
> can reach a point where IPv4 can go away, and for some organizations the
> answer of "Just use SLAAC" is simply not acceptable.
> 
> They just won't do it.
> 
> Preventing IPv6 adoption hurts us all.  And Android not supporting a MAJOR
> part of IPv6 like DHCPv6 is preventing adoption.
> 
> 
> 
> 
> 
> On Wed, Jun 10, 2015 at 1:42 PM, Sander Steffann  wrote:
> 
>>> 
>>> It's not the *only* option. There are large networks - O(100k) IPv6
>> nodes - that do ND monitoring for accountability, and it does work for
>> them. Many devices support this via syslog, even. As you can imagine, my
>> Android device gets IPv6 at work, even though it doesn't support DHCPv6.
>> Other universities, too. It's obviously  not your chosen or preferred
>> mechanism, but it does work.
>> 
>> /me starts to write that whitepaper that educates people on how to do this
>> 
>> Cheers,
>> Sander
>> 
>> 
> 
> 
> -- 
> 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

RE: Android (lack of) support for DHCPv6

[Tony Hain]

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 
> wrote:
> 
> > 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 scenario," words that came
> > right before the ones you quoted?
> >
> > How does a sentence that says "in that scenario, android would "
> > 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

Re: Android (lack of) support for DHCPv6

[Ray Soucy]

I've already written systems to do this kind of thing, but the logging
requirements quickly go through the roof for a non-trivial network;
especially in the case of temporary addressing now default on many
systems.  That isn't so much the issue as operational consistency and
supportability.

The requirement for hosts to be dual stack will exist for some time.

For the sanity of IT workers and users alike (most of which don't really
know the details of IPv6 and barely understand address scopes let alone
multiple addresses) there needs to be some level of consistency between how
hosts are addressed and communicate between the two protocols.  Saying
we'll develop one system for IPv4 and one for IPv6 ultimate results in
"Let's not deploy IPv6 just yet".

This rings especially true when security concerns come up.  Consistency
between IPv4 and IPv6 needs to be possible in this transition period, or
people simply decide to not deploy.  Consistency in addressing and
maintaining a one host one address model has major implications for policy
construction, flow analysis and incident response, denial of service
mitigation, etc.  If the consistency isn't there, you need to "re-invent
the wheel" for every aspect, then maintain different systems for IPv4 and
IPv6 along side one another.

Even worse, if we keep seeing adoption held up by inconsistent client
implementations I fear we'll start seeing commercial products which NAT or
proxy IPv4 to IPv6 to avoid using IPv6 internally.  It's very ugly and
requires some DNS magic to work, but it's not impossible.  We're already
seeing this in terms of cloud computing and virtualization.  Servers have
IPv4 addresses and only a load balancer with an external IPv6 address.

We absolutely need to make it possible for people to adopt IPv6 before we
can reach a point where IPv4 can go away, and for some organizations the
answer of "Just use SLAAC" is simply not acceptable.

They just won't do it.

Preventing IPv6 adoption hurts us all.  And Android not supporting a MAJOR
part of IPv6 like DHCPv6 is preventing adoption.





On Wed, Jun 10, 2015 at 1:42 PM, Sander Steffann  wrote:

> >
> > It's not the *only* option. There are large networks - O(100k) IPv6
> nodes - that do ND monitoring for accountability, and it does work for
> them. Many devices support this via syslog, even. As you can imagine, my
> Android device gets IPv6 at work, even though it doesn't support DHCPv6.
> Other universities, too. It's obviously  not your chosen or preferred
> mechanism, but it does work.
>
> /me starts to write that whitepaper that educates people on how to do this
>
> Cheers,
> Sander
>
>


-- 
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

Re: Android (lack of) support for DHCPv6

[George, Wes]

From: Lorenzo Colitti mailto:lore...@colitti.com>>
Date: Wednesday, June 10, 2015 at 11:21 AM
To: "George, Wes" mailto:wesley.geo...@twcable.com>>
Cc: NANOG mailto:nanog@nanog.org>>
Subject: Re: Android (lack of) support for DHCPv6

"I don't think it's a good plan to implement stateful DHCPv6 now and postpone 
the solution of the problem until IPv4 goes away many years from now. By then, 
a lot of water will have flowed under the bridge by then, and a lot of 
one-address-only networks will have been deployed and have moulded industry 
thinking.

So, much as it pains me to stand in the way of IPv6 adoption - and you should 
how much I've tried to do on that front - I think that that wide deployment of 
one-address-per-device IPv6 might actually do more harm than good, and I expect 
that many operators who are going to require stateful DHCPv6 addressing are 
going to use it for one-address-per-device IPv6.

I really think it's better if we get this right now, not kick the can down the 
road. That means we as an industry need to find a solution for IPv6 deployment 
in university/enterprise networks that does not devolve into 
one-address-per-device IPv6, *before* one-address-per-device IPv6 becomes 
universally implemented and usable."

WG] I wasn't suggesting kicking the can. I agree that we need a solution, and 
getting started on it now so that the guidance and potential solutions are 
available as soon as possible is the right plan, because it reduces our 
potential reliance on IPv4 as a fallback for those things that need multiple 
addresses today. However, I think you're going to have a lot of trouble 
building consensus for your view that the right response is to try to 
completely block one-address-per-device IPv6 deployment by any means possible, 
and I think you're going to have even less success actually doing it, given 
that most other devices have already built support for it.
Turning off IPv4 on a dual-stack network is a major change, as complex (or 
more) than deploying IPv6 to start with, especially if you haven't been focused 
on getting everything using IPv6 so that it's not dependent on IPv4, not to 
mention those unpredictable users. So I don't think it's unreasonable to expect 
that some changes to the existing IPv6 deployment will be necessary to support 
such a thing, and therefore I disagree with your assertion that allowing 
one-address-per-device in the short term will lead to unsolvable problems 
later, due to inertia or otherwise. It's also not guaranteed that everyone 
doing stateful DHCPv6 will limit devices to one address, so we need to be a bit 
careful with the prognostications of universal doom.

Rhetorical question: given the growing evidence that IPv6 is often lower 
latency than IPv4, and Google's heavy focus on improving performance for user 
experience (page load times, SPDY, etc) especially in the mobile space, how 
long do you think you'll really be able to justify not supporting IPv6 on a 
subset of deployments to avoid the risk of future tragedy before you're 
overruled by the potential to shave off a few more ms of latency?

Thanks,
Wes

Anything below this line has been added by my company’s mail server, I
have no control over it.
--


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Android (lack of) support for DHCPv6

[Sander Steffann]

> 
> It's not the *only* option. There are large networks - O(100k) IPv6 nodes - 
> that do ND monitoring for accountability, and it does work for them. Many 
> devices support this via syslog, even. As you can imagine, my Android device 
> gets IPv6 at work, even though it doesn't support DHCPv6. Other universities, 
> too. It's obviously  not your chosen or preferred mechanism, but it does work.

/me starts to write that whitepaper that educates people on how to do this

Cheers,
Sander

Re: Android (lack of) support for DHCPv6

[Ray Soucy]

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.





On Wed, Jun 10, 2015 at 12:29 PM, Lorenzo Colitti 
wrote:

> 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 scenario," words that came right
> before the ones you quoted?
>
> How does a sentence that says "in that scenario, android would "
> 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

Re: Android (lack of) support for DHCPv6

[Karl Auer]

On Wed, 2015-06-10 at 09:49 -0700, Scott Whyte wrote:
> False dichotomies suck.

There are only two kinds of dichotomy... those that suck and those that
do not. This one sucks.

Regards, K.


-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

Re: Android (lack of) support for DHCPv6

[Jeff McAdams]

Re: Android (lack of) support for DHCPv6

[Jared Mauch]

> On Jun 10, 2015, at 11:36 AM, Jeff McAdams  wrote:
> 
> There is no other rational way to interpret your statement than to be a 
> statement of Google's position.

As someone who posts from a personal email but my management has told me that 
I’m well identifiable as who I work for, I’m sympathetic to the way one can 
suffer a bit of personality split when certain business realities come into 
play.  I’m sure people might mock me for it, but lots of people have mocked me 
for years so why should I care about this one so much?

When a business reality or necessity hits you in the face, sometimes you can’t 
do anything about it.

Would I have preferred if Apple and AT&T let me tether on my grandfathered 
unlimited plan?  Sure.  Could I do this before on my unlimited GPRS/Edge plan 
with my Nokia?  Of course, but the reality is I can just carry another 
device/SIM and use a tablet to tether.

As google is in a business of selling ads on the internet, I can see why they 
might not want to pick a fight with a carrier at every stage in the process.  
The ROI just isn’t there is my guess.

IPv6 is mature enough to be widely deployed, but some of these cases need to 
have some give/take on both sides to work out.  I’m reminded of the adage of if 
both sides are unhappy you cut the baby properly in half.

- jared

Re: Android (lack of) support for DHCPv6

[Scott Whyte]

On 6/10/15 08:36, Jeff McAdams wrote:

There is no
other rational way to interpret your statement than to be a statement
of Google's position.



False dichotomies suck.

Re: Android (lack of) support for DHCPv6

[Dave Taht]

On Wed, Jun 10, 2015 at 8:35 AM, Tore Anderson  wrote:
> * Lorenzo Colitti
>
>> Tethering is just one example that we know about today.

In android's case I am perpetually bemused by the fact they use
dnsmasq for tethered dhcp, and dnsmasq long ago added support for
doing smarter things with slaac, and dhcpv6. Merely upgrading that
package in the android distro would get everything needed except
dhcp-pd support into android (for which openwrt has got some decent
daemons for).

dnsmasq is not used in android for dns (which is too bad as dnssec
support was also added to it and I hope most of the bugs ironed out,
in the last 3 years), as their dns resolver is in java and is
admittedly mildly more secure if less featureful.

I am told that well over 50% of all android development comes from
volunteer developers so rather than kvetching about this it seems
plausible for an outside effort to get the needed features for
tethering and using dhcpv6-pd into it. If someone wanted to do the
work.

>> Another example is
>> 464xlat.
>
> You can't do 464XLAT without the network operator's help anyway (unless
> you/Google is planning on hosting a public NAT64 service?). If the
> network operator actively wants 464XLAT to be used, by providing
> DNS64/NAT64 service, then it seems fairly reasonable to assume that
> they're not going to deploy an IPv6/DHCPv6-only network that limits the
> number of IA_NA per attached node to 1.
>
>> 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-grains-of-sand-but-you-only-get-one-because-that's-how-we-did-it-in-IPv4
>> networks.
>
> Of course. Hard to argue against imaginary things. :-)
>
> On the other hand, there exist applications *today* that do require
> DHCPv6. One such example would be MAP, which IMHO is superior to
> 464XLAT both for the network operator (statlessness ftw) as well as for
> the end user (unsolicited inbound packets work, no NAT traversal
> required). MAP is provisioned with DHCPv6 (I-D.ietf-softwire-map-dhcp),
> so without DHCPv6 support in Android, MAP support in Android is a
> non-starter.
>
> Tore



-- 
Dave Täht
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

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 scenario," words that came right
before the ones you quoted?

How does a sentence that says "in that scenario, android would "
constitute a statement of direction?

Re: Android (lack of) support for DHCPv6

[Jeff McAdams]

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. There is no other rational way to interpret 
your statement than to be a statement of Google's position.

-- 
Jeff

On Jun 10, 2015 10:26 AM, Lorenzo Colitti  wrote:
>
> Ray, 
>
> please do not construe my words on this thread as being Google's position 
> on anything. These messages were sent from my personal email address, and I 
> do not speak for my employer. 
>
> Regards, 
> Lorenzo 
>
> On Thu, Jun 11, 2015 at 12:15 AM, Ray Soucy  wrote: 
>
> > Respectfully disagree on all points. 
> > 
> > The statement that "Android would still not implement DHCPv6 NA, but it 
> > would implement DHCPv6 PD." is troubling because you're not even willing to 
> > entertain the idea for reasons that are rooted in idealism rather 
> > than pragmatism. 
> > 
> > Very disappointing 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 
> >>> 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 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. 
> >> 
> >> What needs to be gauged about that course of action is how much consensus 
> >> would be achieved, whether network operators would actually use it (IPv6 
> >> has a long and distinguished history of people claiming "I can't support 
> >> IPv6 until I get feature X", feature X appearing, and people changing 
> >> their 
> >> claim to "I can't support IPv6 until I get feature Y"), and how much of 
> >> this discussion would be put to bed. 
> >> 
> >> That course of action would seem most feasible if it were accompanied by 
> >> an IETF document that explained the deployment model and clarified what 
> >> "sufficient size" is. 
> >> 
> >> 
> >>> Universities see a constant stream of DMCA violation notices that need 
> >>> to be dealt with and not being able to associate a specific IPv6 address 
> >>> to 
> >>> a specific user is a big enough liability that the only option is to not 
> >>> use IPv6. 
> >>> 
> >> 
> >> It's not the *only* option. There are large networks - O(100k) IPv6 nodes 
> >> - that do ND monitoring for accountability, and it does work for them. 
> >> Many 
> >> devices support this via syslog, even. As you can imagine, my Android 
> >> device gets IPv6 at work, even though it doesn't support DHCPv6. Other 
> >> universities, too. It's obviously  not your chosen or preferred mechanism, 
> >> but it does work. 
> >> 
> > 
> > 
> > 
> > -- 
> > 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 
> > 

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

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-grains-of-sand-but-you-only-get-one-because-that's-how-we-did-it-in-IPv4
> > networks.
>
> Of course. Hard to argue against imaginary things. :-)
>

I think "imaginary" is the wrong word here. There's a difference between
imaginary things and leaving room for for future innovation. Phone network
model vs. Internet model is the usual example that comes to mind.


> On the other hand, there exist applications *today* that do require
> DHCPv6. One such example would be MAP, which IMHO is superior to
> 464XLAT both for the network operator (statlessness ftw) as well as for
> the end user (unsolicited inbound packets work, no NAT traversal
> required). MAP is provisioned with DHCPv6 (I-D.ietf-softwire-map-dhcp),
> so without DHCPv6 support in Android, MAP support in Android is a
> non-starter.
>

Support for the DHCPv6 protocol, or support for assigning addresses from
IA_NA?

RE: Android (lack of) support for DHCPv6

[Tony Hain]

Ray Soucy  wrote:
> 
> Respectfully disagree on all points.
> 
> The statement that "Android would still not implement DHCPv6 NA, but it would
> implement DHCPv6 PD." is troubling because you're not even willing to
> entertain the idea for reasons that are rooted in idealism rather than
> pragmatism.

In Lorenzo's defense, I believe he is taking the long term pragmatic position, 
while you appear to be taking the short term idealistic position. 

For argument's sake... let's assume that a shiny new browser comes along the is 
designed to limit third party cross site correlation and tracking. It does this 
by using a different source address for every destination. This browser works 
fine on any network that allows N>1, but is stuck in the myopic historical 
world of older browsers on networks where N=1. To the pragmatism point, would 
you rather have a device like that do N NA requests (creating N ND state 
entries), or have it do PD (creating 1 ND + 1 Routing entry)?

Tony

> 
> Very disappointing 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
> >> 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 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.
> >
> > What needs to be gauged about that course of action is how much
> > consensus would be achieved, whether network operators would actually
> > use it (IPv6 has a long and distinguished history of people claiming
> > "I can't support
> > IPv6 until I get feature X", feature X appearing, and people changing
> > their claim to "I can't support IPv6 until I get feature Y"), and how
> > much of this discussion would be put to bed.
> >
> > That course of action would seem most feasible if it were accompanied
> > by an IETF document that explained the deployment model and clarified
> > what "sufficient size" is.
> >
> >
> >> Universities see a constant stream of DMCA violation notices that
> >> need to be dealt with and not being able to associate a specific IPv6
> >> address to a specific user is a big enough liability that the only
> >> option is to not use IPv6.
> >>
> >
> > It's not the *only* option. There are large networks - O(100k) IPv6
> > nodes
> > - that do ND monitoring for accountability, and it does work for them.
> > Many devices support this via syslog, even. As you can imagine, my
> > Android device gets IPv6 at work, even though it doesn't support
> > DHCPv6. Other universities, too. It's obviously  not your chosen or
> > preferred mechanism, but it does work.
> >
> 
> 
> 
> --
> 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

Re: Android (lack of) support for DHCPv6

[Baldur Norddahl]

On 10 June 2015 at 15:53, Mikael Abrahamsson  wrote:

>
> Well, then you're not doing what most people do when they do DHCPv6-PD,
> you're using something else. This is the first time I have heard of anyone
> doing what you describe.
>

I mentioned because the Android guy seems to be guilty of knowing how
everyone does or want to run their network. There are always more ways to
do this than you thought of.

Normally it's done by the router acting on DHCPv6 packets and installing a
> route if need be.
>

I would probably do it like that if my equipment had support. But it does
not. And I can not point at any RFCs to tell my vendor that their stuff is
broken, because the requirement simply is not in any RFCs.

Also consider this:

1) The DHCP relay might not be the same router that needs to do the
forwarding.
2) There might be more than one router that can forward.
3) There might not even be a DHCP relay, the DHCP server could be attached
directly.

In our case we have GPON access switches that do DHCP(v6) snooping. These
things can block illegal traffic, but other than that, they are purely
layer 2 devices. There is no relay there and no layer 3 forwarding, so no
routes can be installed by anything.

Upstream from the access switches there are many ways you can structure
your network. You might want to have two routers for redundancy. You may
attach the DHCP server directly here if it is a small network (although we
use relays).

Static routes with a fixed GUA next hop for the /48 prefix delegations
means you can have some pretty dumb (=cheap) stuff in your network. All you
need is an intelligent DHCP server and that is just open source software on
a Linux.

I considered having the DHCP server add the routes via a script that is
triggered by lease handout. But the fixed static routes is much simpler and
robust.


> I do agree that you do not want your equipment sitting in the same
> broadcast domain as all the customers devices, but do use PD. I'm just
> baffled by the way you have implemented "PD".
>
>
We all work with the equipment we got and the quirks in there. Just do not
go around and assume everyone has the same requirements as you. Saying
there is no use case for DHCPv6 except for PD is dumb and that was why I
put forward a use case to illustrate how this is used in the real world. At
least by us.

Regards,

Baldur

Re: Android (lack of) support for DHCPv6

[Tore Anderson]

* Lorenzo Colitti

> Tethering is just one example that we know about today. Another example is
> 464xlat.

You can't do 464XLAT without the network operator's help anyway (unless
you/Google is planning on hosting a public NAT64 service?). If the
network operator actively wants 464XLAT to be used, by providing
DNS64/NAT64 service, then it seems fairly reasonable to assume that
they're not going to deploy an IPv6/DHCPv6-only network that limits the
number of IA_NA per attached node to 1.

> 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-grains-of-sand-but-you-only-get-one-because-that's-how-we-did-it-in-IPv4
> networks.

Of course. Hard to argue against imaginary things. :-)

On the other hand, there exist applications *today* that do require
DHCPv6. One such example would be MAP, which IMHO is superior to
464XLAT both for the network operator (statlessness ftw) as well as for
the end user (unsolicited inbound packets work, no NAT traversal
required). MAP is provisioned with DHCPv6 (I-D.ietf-softwire-map-dhcp),
so without DHCPv6 support in Android, MAP support in Android is a
non-starter.

Tore

Re: Android (lack of) support for DHCPv6

[Masataka Ohta]

Lorenzo Colitti wrote:

> It's not the *only* option. There are large networks - O(100k) IPv6 nodes -
> that do ND monitoring for accountability, and it does work for them. Many
> devices support this via syslog, even. As you can imagine, my Android
> device gets IPv6 at work, even though it doesn't support DHCPv6. Other
> universities, too. It's obviously  not your chosen or preferred mechanism,
> but it does work.

Considering that a DOS attack from a node using a lot of addresses to
effectively disable logging, SLAAC must not be used, unless maximum N,
the maximum number of addresses for a node to have, is standardized (
assuming a node is securely identified through the first hop security,
which is necessary to enforce the number of addresses used by each node).

Masataka Ohta

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

Ray,

please do not construe my words on this thread as being Google's position
on anything. These messages were sent from my personal email address, and I
do not speak for my employer.

Regards,
Lorenzo

On Thu, Jun 11, 2015 at 12:15 AM, Ray Soucy  wrote:

> Respectfully disagree on all points.
>
> The statement that "Android would still not implement DHCPv6 NA, but it
> would implement DHCPv6 PD." is troubling because you're not even willing to
> entertain the idea for reasons that are rooted in idealism rather
> than pragmatism.
>
> Very disappointing 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
>>> 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 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.
>>
>> What needs to be gauged about that course of action is how much consensus
>> would be achieved, whether network operators would actually use it (IPv6
>> has a long and distinguished history of people claiming "I can't support
>> IPv6 until I get feature X", feature X appearing, and people changing their
>> claim to "I can't support IPv6 until I get feature Y"), and how much of
>> this discussion would be put to bed.
>>
>> That course of action would seem most feasible if it were accompanied by
>> an IETF document that explained the deployment model and clarified what
>> "sufficient size" is.
>>
>>
>>> Universities see a constant stream of DMCA violation notices that need
>>> to be dealt with and not being able to associate a specific IPv6 address to
>>> a specific user is a big enough liability that the only option is to not
>>> use IPv6.
>>>
>>
>> It's not the *only* option. There are large networks - O(100k) IPv6 nodes
>> - that do ND monitoring for accountability, and it does work for them. Many
>> devices support this via syslog, even. As you can imagine, my Android
>> device gets IPv6 at work, even though it doesn't support DHCPv6. Other
>> universities, too. It's obviously  not your chosen or preferred mechanism,
>> but it does work.
>>
>
>
>
> --
> 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
>

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

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 into a debate that is equal parts religion and kool-aid
> drinking contest among IPv6 übernerds.
>

Thank you for trying to reword what I tried to express. Your assessment
pretty much matches mine, except for the conclusion (see below).


> So what this means is that there is a draft to be written about the need
> for multiple address support on IPv6 networks for mobile devices,
> enumerating the ways that they use those multiple addresses, and how it
> differs from today's IPv4-only or dual-stack implementations, along with a
> big discussion on the breakage that can happen on IPv6-only networks if a
> device can't get the addresses it needs. It is a fool's errand to assume
> that we can dictate one and only one solution to #5 (regardless of one's
> perceived influence and market power), so the best we can do is to
> document the preferred one(s) and hope that we've made a good enough case
> or made them easy enough to use that the majority of network operators do
> support them.
> Sunset4 is the right place for that draft, so let's discuss it at the next
> IETF.
>

Yep (but perhaps in v6ops instead of sunset4, see below).


> However, the spectre of #4 does NOT mean that DHCPv6 is unusable because
> it would break things today on a dual-stack network, so you need to stop
> trying to imply that, and stop trying to optimize for use cases that you
> yourself admit basically don't exist today by blocking support for
> something that we could use today to have more devices using IPv6, were it
> available.
>

I disagree with this part of the conclusion. I don't think it's a good plan
to implement stateful DHCPv6 now and postpone the solution of the problem
until IPv4 goes away many years from now. By then, a lot of water will have
flowed under the bridge by then, and a lot of one-address-only networks
will have been deployed and have moulded industry thinking.

So, much as it pains me to stand in the way of IPv6 adoption - and you
should how much I've tried to do on that front - I think that that wide
deployment of one-address-per-device IPv6 might actually do more harm than
good, and I expect that many operators who are going to require stateful
DHCPv6 addressing are going to use it for one-address-per-device IPv6.

I really think it's better if we get this right now, not kick the can down
the road. That means we as an industry need to find a solution for IPv6
deployment in university/enterprise networks that does not devolve into
one-address-per-device IPv6, *before* one-address-per-device IPv6 becomes
universally implemented and usable.

Re: Android (lack of) support for DHCPv6

[Ray Soucy]

Respectfully disagree on all points.

The statement that "Android would still not implement DHCPv6 NA, but it
would implement DHCPv6 PD." is troubling because you're not even willing to
entertain the idea for reasons that are rooted in idealism rather
than pragmatism.

Very disappointing 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 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 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.
>
> What needs to be gauged about that course of action is how much consensus
> would be achieved, whether network operators would actually use it (IPv6
> has a long and distinguished history of people claiming "I can't support
> IPv6 until I get feature X", feature X appearing, and people changing their
> claim to "I can't support IPv6 until I get feature Y"), and how much of
> this discussion would be put to bed.
>
> That course of action would seem most feasible if it were accompanied by
> an IETF document that explained the deployment model and clarified what
> "sufficient size" is.
>
>
>> Universities see a constant stream of DMCA violation notices that need to
>> be dealt with and not being able to associate a specific IPv6 address to a
>> specific user is a big enough liability that the only option is to not use
>> IPv6.
>>
>
> It's not the *only* option. There are large networks - O(100k) IPv6 nodes
> - that do ND monitoring for accountability, and it does work for them. Many
> devices support this via syslog, even. As you can imagine, my Android
> device gets IPv6 at work, even though it doesn't support DHCPv6. Other
> universities, too. It's obviously  not your chosen or preferred mechanism,
> but it does work.
>



-- 
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

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

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 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.

What needs to be gauged about that course of action is how much consensus
would be achieved, whether network operators would actually use it (IPv6
has a long and distinguished history of people claiming "I can't support
IPv6 until I get feature X", feature X appearing, and people changing their
claim to "I can't support IPv6 until I get feature Y"), and how much of
this discussion would be put to bed.

That course of action would seem most feasible if it were accompanied by an
IETF document that explained the deployment model and clarified what
"sufficient size" is.


> Universities see a constant stream of DMCA violation notices that need to
> be dealt with and not being able to associate a specific IPv6 address to a
> specific user is a big enough liability that the only option is to not use
> IPv6.
>

It's not the *only* option. There are large networks - O(100k) IPv6 nodes -
that do ND monitoring for accountability, and it does work for them. Many
devices support this via syslog, even. As you can imagine, my Android
device gets IPv6 at work, even though it doesn't support DHCPv6. Other
universities, too. It's obviously  not your chosen or preferred mechanism,
but it does work.

Re: Android (lack of) support for DHCPv6

[Mikael Abrahamsson]

On Wed, 10 Jun 2015, George, Wes wrote:



On 6/10/15, 9:13 AM, "Baldur Norddahl"  wrote:


What standard exactly requires my router to be able to snoop a DHCP-PD to
create routes dynamically? That was left out and one solution is the one
we
use.


WG] We use this in cable-land, so it's definitely documented in the DOCSIS
standards. Not sure it exists anywhere in the IETF standards, and so YMMV
on which platforms do and do not support it.


http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configuration/15-sy/dhcp-15-sy-book/ip6-dhcp-rel-agent.html#GUID-52D23F09-6829-4950-9431-92D9B7A255C0

"DHCPv6 Relay Agent Notification for Prefix Delegation

The DHCPv6 relay agent notification for prefix delegation allows the 
device working as a DHCPv6 relay agent to find prefix delegation options 
by reviewing the contents of a DHCPv6 RELAY-REPLY packet that is relayed 
by the relay agent to the client. When a prefix delegation option is found 
by the relay agent, the relay agent extracts the information about the 
prefix that is being delegated and inserts an IPv6 static route matching 
the prefix delegation information onto the relay agent. Future packets 
destined to that prefix via relay will be forwarded based on the 
information contained in the prefix delegation. The IPv6 static route is 
then left in the routing table until the prefix delegation lease time 
expires or the relay agent receives a release packet from the client 
releasing the prefix delegation."


I can't find IETF standards language apart from this:

"14.  Relay agent behavior

   A relay agent forwards messages containing Prefix Delegation options
   in the same way as described in section 20, "Relay Agent Behavior" of
   RFC 3315.

   If a delegating router communicates with a requesting router through
   a relay agent, the delegating router may need a protocol or other
   out-of-band communication to add routing information for delegated
   prefixes into the provider edge router."

From what I can find, a lot of vendors seem to have functionality 
implemented to look at the relayed messages and install static routes 
without any OOO-communication.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Android (lack of) support for DHCPv6

[George, Wes]

On 6/10/15, 9:13 AM, "Baldur Norddahl"  wrote:

>What standard exactly requires my router to be able to snoop a DHCP-PD to
>create routes dynamically? That was left out and one solution is the one
>we
>use.

WG] We use this in cable-land, so it's definitely documented in the DOCSIS
standards. Not sure it exists anywhere in the IETF standards, and so YMMV
on which platforms do and do not support it.

Thanks,
Wes


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Android (lack of) support for DHCPv6

[Ray Soucy]

The whole conversation is around 464XLAT on IPv6-only networks right?
We're going to be dual-stack for a while IMHO, and by the time we can get
away with IPv6 only for WiFi, 464 should no longer be relevant because
we'll have widespread IPv6 adoption by then.

Carriers can do IPv6 only because they tightly control the clients, for
WiFi clients are and will always be all over the place, so dual stack will
be pretty much a given for a long time.


On Wed, Jun 10, 2015 at 9:50 AM, George, Wes 
wrote:

>
> On 6/10/15, 2:32 AM, "Lorenzo Colitti"  wrote:
>
> >I'd be happy to work with people on an Internet draft or other
> >standard to define a minimum value for N, but I fear that it may not
> >possible to gain consensus on that.
>
> WG] No, I think that the document you need to write is the one that
> explains why a mobile device needs multiple addresses, and make some
> suggestions about the best way to support that. Your earlier response
> detailing those vs how they do it in IPv4 today was the first a lot of us
> have heard of that, because we're not in mobile device development and
> don't necessarily understand the secret sauce involved. This is especially
> true for your mention of things like WiFi calling, and all of the other
> things that aren't tethering or 464xlat, since neither of those are as
> universally agreed-upon as "must have" on things like enterprise networks.
> I'm sure there are also use cases we haven't thought of yet, so I'm not
> trying to turn this into a debate about which use cases are valid, just
> observing that you might get more traction with the others.
>
>
> >Asking for more addresses when the user tries to enable features such as
> >tethering, waiting for the network to reply, and disabling the features if
> >the network does not provide the necessary addresses does not seem like it
> >would provide a good user experience.
>
> WG] Nor does not having IPv6 at all, and being stuck behind multiple
> layers of NAT, but for some reason you seem ok with that, which confuses
> me greatly. The amount of collective time wasted arguing this is likely
> more than enough to come up with cool ways to optimize the ask/wait/enable
> function so that it doesn't translate to a bad user experience, and few
> things on a mobile device are instantaneous anyway, so let's stop acting
> like it's an unsolvable problem.
>
> Thanks,
>
> Wes
>
>
> Anything below this line has been added by my company’s mail server, I
> have no control over it.
> --
>
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>



-- 
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

Re: Android (lack of) support for DHCPv6

[Mikael Abrahamsson]

On Wed, 10 Jun 2015, Baldur Norddahl wrote:


I need the GUA to have a stable and predictable next hop for my static
route of the /48 prefix delegation.

What standard exactly requires my router to be able to snoop a DHCP-PD to
create routes dynamically? That was left out and one solution is the one we
use.

Note that the /48 static routes are configured on the routers well in
advantage of the customer even signing up for the service. It is just there
waiting for a customer to be assigned the corresponding /128.


Well, then you're not doing what most people do when they do DHCPv6-PD, 
you're using something else. This is the first time I have heard of anyone 
doing what you describe.


Normally it's done by the router acting on DHCPv6 packets and installing a 
route if need be.


http://www.cisco.com/c/en/us/support/docs/ip/ip-version-6-ipv6/113141-DHCPv6-00.html

As soon as the PD is handed out, a corresponding route will be installed 
for that PD to the address (potentially LL address) that requested that 
PD.



getting DoS attacks on NDP, extra CPU use etc on my network. Why would I
want that, when I can deliver perfect service to the customer with a fixed
cache of 2 entries?


If you did PD the way it's normally done, you would need 1 entry, not 2.

I do agree that you do not want your equipment sitting in the same 
broadcast domain as all the customers devices, but do use PD. I'm just 
baffled by the way you have implemented "PD".


--
Mikael Abrahamssonemail: swm...@swm.pp.se