Re: Android (lack of) support for DHCPv6
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
On 13 June 2015 at 09:11, Mikael Abrahamsson swm...@swm.pp.se 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 https://tools.ietf.org/html/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 https://tools.ietf.org/html/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
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
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
On Fri, Jun 12, 2015 at 1:33 PM, Dave Taht dave.t...@gmail.com 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: http://www.dirtside.com/
Re: Android (lack of) support for DHCPv6
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
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
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 toddun...@gmail.com 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 r...@maine.edu 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
Re: Android (lack of) support for DHCPv6
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, valdis.kletni...@vt.edu 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 stubborn and add a feature to
Re: Android (lack of) support for DHCPv6
On Fri, Jun 12, 2015 at 11:18 AM, James R Cutler james.cut...@consultant.com 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
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 r...@maine.edu 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
Re: Android (lack of) support for DHCPv6
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 r...@maine.edu 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, valdis.kletni...@vt.edu 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.
Re: Android (lack of) support for DHCPv6
Once upon a time, Todd Underwood toddun...@gmail.com 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 c...@cmadams.net
Re: Android (lack of) support for DHCPv6
On Thu, Jun 11, 2015 at 7:42 PM, Laszlo Hanyecz las...@heliacal.net 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: http://www.dirtside.com/
Re: Android (lack of) support for DHCPv6
On Fri, Jun 12, 2015 at 1:43 PM, valdis.kletni...@vt.edu 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
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
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 las...@heliacal.net 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
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
On Fri, Jun 12, 2015 at 10:51 AM, Todd Underwood toddun...@gmail.com wrote: On Fri, Jun 12, 2015 at 1:43 PM, valdis.kletni...@vt.edu 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
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
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 m...@mtcc.com 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
On Thu, 11 Jun 2015 19:42:07 -0400, Laszlo Hanyecz las...@heliacal.net 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
On Jun 11, 2015, at 9:06 PM, Karl Auer ka...@biplane.com.au 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
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
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.
Re: Android (lack of) support for DHCPv6
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
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 hen...@acm.org 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
On Wed, Jun 10, 2015 at 8:26 AM, Lorenzo Colitti lore...@colitti.com 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
On Thu, Jun 11, 2015 at 4:42 PM, Laszlo Hanyecz las...@heliacal.net 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
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
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 las...@heliacal.net 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 m...@mtcc.com 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
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 cb.li...@gmail.com 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 hen...@acm.org 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
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
On Jun 12, 2015, at 12:51 AM, Ray Soucy r...@maine.edu 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 las...@heliacal.net 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
Re: Android (lack of) support for DHCPv6
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 mpet...@netflight.com wrote: On Wed, Jun 10, 2015 at 8:26 AM, Lorenzo Colitti lore...@colitti.com 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
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
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
On Wed, Jun 10, 2015 at 10:31:25AM +0200, Sander Steffann wrote: I don't think it is unreasonable. If the network doesn't support the features you need then let the user know (grey out the feature and add a note that says broken network). It will put pressure on the network department to fix their DHCPv6 implementation. Because that has worked so well in the past, as opposed to the helpdesk person who receives the complaint shrugging their shoulders and saying, I dunno, that's just the way it is. - Matt
Re: Android (lack of) support for DHCPv6
On Wed, 2015-06-10 at 19:49 +0900, Lorenzo Colitti wrote: Question for everyone on this thread that has said that DHCPv6 NA is a requirement: suppose that Android supported stateful DHCPv6 addressing, requested a number of addresses, and did not use any of them if the number of addresses received was less than N. What does N need to be? I think that's a wrong question, or maybe I am completely missing your point. Seems to me that N will vary depending on what you are trying to do. And you could well be trying to do several things at once, each with a different requirement. And these things may happen over time, so that at one time you need N, while later you need ten times that many - or half as many, or none. With DHCP you just ask for more when you need more, or release ones you don't need. You don't have to arrange everything up front and then be stuck with it. You know how many addresses you need to provide a given service; you know how to degrade the service gracefully, or whether a graceful degrade is even possible. In other words, you the requester know how many addresses you want and how many you have to have - which are two possibly quite different numbers. Addresses are just a resource, and like any other resource, if the environment can't supply them, you either degrade the service, fail to provide it, or possibly keep trying and provide it later when the resource becomes available. At their most basic, standard DHCPv4 and DHCPv6 clients do exactly that - they keep trying until they get addresses. Not being able to get enough addresses is pretty much like not being able to get enough RAM or disk space, but you make it sound like running out of power! It is not an all-or-nothing proposition at a platform level, and demanding to know what is N? implies that it is. 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
Hi, Ok, let's see how that goes, even among the few people on this thread. Question for everyone on this thread that has said that DHCPv6 NA is a requirement: suppose that Android supported stateful DHCPv6 addressing, requested a number of addresses, and did not use any of them if the number of addresses received was less than N. What does N need to be? well, from memory and a quick discussion with a colleague, our cisco wireless kit is only happy with devices having 8 IPv6 addresses at most - otherwise the older addresses get removed from the neighbour cache. is that a good starting point? :-) alan
Re: Android (lack of) support for DHCPv6
On Wed, Jun 10, 2015 at 4:13 PM, Karl Auer ka...@biplane.com.au wrote: You need as many as you need. Request them. Worry about it if you don't get them. This is exactly what happens when N=1, BTW. A DHCPv6 server is almost certainly not going to have an upper limit that significantly crimps your style... Ok, let's see how that goes, even among the few people on this thread. Question for everyone on this thread that has said that DHCPv6 NA is a requirement: suppose that Android supported stateful DHCPv6 addressing, requested a number of addresses, and did not use any of them if the number of addresses received was less than N. What does N need to be?
Re: Android (lack of) support for DHCPv6
So here is the thing. You can try to use enhanced functionality which depends on multiple addresses as justification for saying DHCPv6 is not supported. In practice, your device will just not be supported. As you pointed out, there isn't anything that forces adoption of IPv6 right now. 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. At least on our network, the number of Apple devices dwarf Android by several times. With Android being a minority and not implementing DHCPv6 support you force us to make Android a second class citizen. I'm perfectly find NATing Android, and don't see us giving up the operational benefits to DHCPv6 anytime soon. Also, in terms of hotspot functionality being the major driver ... I 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. A phone makes a terrible AP when the laptop supports full 802.11ac. I really don't know anyone who connects through their phone when WiFi is available and the phone is also connected to the same WiFi network. It's not even a use case I think most people would consider common or valid but we're using it a justification to not support something that IS very common and widely deployed. On Wed, Jun 10, 2015 at 7:16 AM, Lorenzo Colitti lore...@colitti.com wrote: On Wed, Jun 10, 2015 at 5:31 PM, Sander Steffann san...@steffann.nl wrote: I can also see more deployment issues (much more state in the routers for all those PDs, needing huge amounts of /64s (or larger) to be able to deal with a few hundred/thousand clients) but it would be very nice if this was possible :) Well, in IPv4 you can do 16M devices in 10/8. You can divide IPv6 space in exactly the same way and give every client a /64. A /24 becomes a /56, and your 10/8 becomes a /40. A /40 is really not hard to get. -- 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
On Wed, Jun 10, 2015 at 5:31 PM, Sander Steffann san...@steffann.nl wrote: I can also see more deployment issues (much more state in the routers for all those PDs, needing huge amounts of /64s (or larger) to be able to deal with a few hundred/thousand clients) but it would be very nice if this was possible :) Well, in IPv4 you can do 16M devices in 10/8. You can divide IPv6 space in exactly the same way and give every client a /64. A /24 becomes a /56, and your 10/8 becomes a /40. A /40 is really not hard to get.
Re: Android (lack of) support for DHCPv6
On Tue, Jun 09, 2015 at 02:56:26PM -0700, Owen DeLong wrote: Further, the cellular companies would do well to be more adaptive to the capabilities that exist in the hardware rather than insisting that they choose the solution and the hardware makers must adapt. Hahahahahaha! Fun fill in the blanks game: We're the phone company, __ ___'_ __ . - Matt -- FreeFrag The most secure computer in the world is one not connected to the internet. Thats why I recommend Telstra ADSL. -- bash.org/?168859
Re: Android (lack of) support for DHCPv6
On Wed, 2015-06-10 at 21:06 +0900, Lorenzo Colitti wrote: On Wed, Jun 10, 2015 at 8:30 PM, Karl Auer ka...@biplane.com.au wrote: Seems to me that N will vary depending on what you are trying to do. 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. I understand. I took issue only with the idea that any value of N could be right. Don't forget though that IPv4 phones also need resources from the network - their public IPv4 addresses. Why isn't that a showstopper too? Hm... The essential difference with IPv6 compared to IPv4 is that (due to address abundance) all addresses are (or at least can be) globally routable. There can be a direct bidirectional relationship between a connected device and the world; of necessity, that relationship brings with it a higher degree of interdependence. It's a pretty simple thing really: You can have all that that IPv6 offers (both now and potentially), or you can cripple it so that the user experience is just like IPv4. I get where you are coming from. It's just a bit sad, is all. 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
On Wed, Jun 10, 2015 at 8:35 PM, Ray Soucy r...@maine.edu wrote: In practice, your device will just not be supported. As you pointed out, there isn't anything that forces adoption of IPv6 right now. It's certainly a possibility for both sides in this debate to say my way or the highway, and wait and see what happens when operators start removing support for IPv4. I'm perfectly find NATing Android, and don't see us giving up the operational benefits to DHCPv6 anytime soon. Oh, I definitely see that DHCPv6 is easier for network operators. 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? It's the same amount of state. Same accountability. Same transaction model. But unlike NA, the device gets as many addresses as it needs. Nothing breaks, and you get future flexibility. Mobile devices don't have to implement NAT, and application developers don't have to work around it. You size your IPv6 pools based on the size of your IPv4 pools, and don't run out of addresses. Technically, that sort of arrangement is superior to IA_NA in basically every way. So... why use IA_NA? Even if the answers are that's what we do in IPv4, and we want to do it the same way, or we're worried that this is strange and will tickle vendor bugs, it's not supported by the IPAM we use today, or this is what we've decided, our network our rules, I would hope that we as an industry can think a little longer term than that. Also, in terms of hotspot functionality being the major driver Don't think about yesterday, think about tomorrow. Tethering and 464xlat are just two examples of what can be done when you have the ability to use 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.
Re: Android (lack of) support for DHCPv6
On Wed, 10 Jun 2015, Baldur Norddahl wrote: We use DHCPv6 to assign just one IP address to the CPE. This is because otherwise our routers do not know where to route the /48 that is also passed along with DHCPv6-PD. If you use DHCPv6-PD you only need a LL address, you do not need a GUA address. Yes, a GUA WAN address is nice for fault finding, shows up in traceroute etc, but it's not needed. If your routers require a GUA WAN address in order for DHCPv6-PD to work, then they're not standards compliant. Apart from operational simplicity, we also do not want our routers to keep track of a million ND cache entries. Our system pushes that down to the CPE. In the network we only have one ND cache entry per customer. Well, if you have a GUA /128, then you have two per customer (because you'll have the LL one as well). If you didn't use the GUA address, you'd only have one. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Android (lack of) support for DHCPv6
On Wed, Jun 10, 2015 at 8:30 PM, Karl Auer ka...@biplane.com.au wrote: Seems to me that N will vary depending on what you are trying to do. Remember, what I'm trying to do is avoid user-visible regressions while getting rid of NAT. Today in IPv4, tethering just works, period. No ifs, no buts, no requests to the network. The user turns it on, and it works. IPv4-only apps always work. 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.
Re: Android (lack of) support for DHCPv6
On Jun 10, 2015, at 8:06 AM, Lorenzo Colitti lore...@colitti.com wrote: On Wed, Jun 10, 2015 at 8:30 PM, Karl Auer ka...@biplane.com.au wrote: Seems to me that N will vary depending on what you are trying to do. Remember, what I'm trying to do is avoid user-visible regressions while getting rid of NAT. Today in IPv4, tethering just works, period. No ifs, no buts, no requests to the network. The user turns it on, and it works. IPv4-only apps always work. 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. Sure, but when you take a NAT and replace it with no-NAT there will be no-NAT regressions as a result. Perhaps doing 66 w/ ULA would provide a comparable experience? IPv4 and IPv6 are enough alike that 99% of things “just work” but it’s in the 1% of ARP v NDP, is what we’re talking about here. - Jared
Re: Android (lack of) support for DHCPv6
On Jun 10, 2015, at 8:48 AM, Chris Adams c...@cmadams.net wrote: Except for the ones that don't. Tethering is far from just works, period. VPNs, VOIP, and games are things that don't always just work (behind any kind of NAT). sarcasm Please don’t bring facts into a discussion about ideologies of IPv6. /sarcasm I think this is the problem that many of us face when dealing with the day-to-date operational challenges of pitching IPv6 at others, many things break for all sorts of reasons. Those of us fighting to enable this technology everywhere face a number of challenges from vendors (8 IPv6 address limits, passive-aggressive bug-fixing, etc) My favorite vendor bug fix for IPv6 up to this point was this one: This is a point fix for a forwarding issue in ipv6 over bundle area. It does not enable/claim support of ipv6 over bundle So you fix a bug but don’t claim support for the bug you just fixed. Hmm. Either way, we need to continue to push on these sensitive areas to make things happen. I’m waiting for folks like Apple to turn on IPv6 on their CDN, or even deliver software updates over IPv6 to mobile devices. I suspect that would be a watershed moment as most people see huge traffic jumps on iOS release day. (Next one is June 30th apparently). Should be exciting. - Jared
Re: Android (lack of) support for DHCPv6
On Wed, Jun 10, 2015 at 2:06 PM, Lorenzo Colitti lore...@colitti.com wrote: On Wed, Jun 10, 2015 at 8:30 PM, Karl Auer ka...@biplane.com.au wrote: Seems to me that N will vary depending on what you are trying to do. Remember, what I'm trying to do is avoid user-visible regressions while getting rid of NAT. Today in IPv4, tethering just works, period. No ifs, no buts, no requests to the network. The user turns it on, and it works. IPv4-only apps always work. 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. Laudible goal. I think with mifi devices typically limiting to 8/16 I have a sense that a /56 (which btw, was the unit we expected to use for mass-customer deployment edge numbering) is going to be ok. Its inevitable that in some other N+ years, we're going to be astonished by how many IPs are needed behind the connecting device, but a /56-/64 gap is going to work for now. So pragmatism drives me to say 'we probably have enough in the model we're working on' I say this, because whilst I personally don't like the HD ratio model, its what we adopted as a global measure of density of use, and I think respecting allocation practice which reflects the HD ratio model is good, and drives us to /56 for mass-customer deployments. (I know there are policy people who may believe /48 is where we're going to go. I can only say thats not how I understand address allocation modelling works in many regions, right now. I also know there are people who think a single customer can be a /128. I don't agree with that either) -G
Re: Android (lack of) support for DHCPv6
Once upon a time, Lorenzo Colitti lore...@colitti.com said: Remember, what I'm trying to do is avoid user-visible regressions while getting rid of NAT. Today in IPv4, tethering just works, period. No ifs, no buts, no requests to the network. The user turns it on, and it works. IPv4-only apps always work. Except for the ones that don't. Tethering is far from just works, period. VPNs, VOIP, and games are things that don't always just work (behind any kind of NAT). -- Chris Adams c...@cmadams.net
Re: Android (lack of) support for DHCPv6
* Lorenzo Colitti Remember, what I'm trying to do is avoid user-visible regressions while getting rid of NAT. Today in IPv4, tethering just works, period. No ifs, no buts, no requests to the network. The user turns it on, and it works. *cough* https://code.google.com/p/android/issues/detail?id=38563 In particular comment 105 is illuminating. Android is apparently fully on-board with mobile carriers' desire to break tethering, even going so far as to implement a feature whose *sole purpose* is to break thethering. Yet, at the same time, you refuse to implement DHCPv6 on WiFi because it *might*, as a *side effect*, break tethering. This does not strike me as very consistent. If Android had instead simply refused to establish a mobile data connection to the mobile carriers that breaks tethering, then the refusal to implement DHCPv6 would make much more sense. Tore
Re: Android (lack of) support for DHCPv6
On Wed, Jun 10, 2015 at 9:31 PM, Tore Anderson t...@fud.no wrote: In particular comment 105 is illuminating. Android is apparently fully on-board with mobile carriers' desire to break tethering, even going so far as to implement a feature whose *sole purpose* is to break thethering. Yet, at the same time, you refuse to implement DHCPv6 on WiFi because it *might*, as a *side effect*, break tethering. This does not strike me as very consistent. Tethering is just one example that we know about today. Another example is 464xlat. 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.
Re: Android (lack of) support for DHCPv6
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? 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. On Wed, Jun 10, 2015 at 8:21 AM, Lorenzo Colitti lore...@colitti.com wrote: On Wed, Jun 10, 2015 at 8:35 PM, Ray Soucy r...@maine.edu wrote: In practice, your device will just not be supported. As you pointed out, there isn't anything that forces adoption of IPv6 right now. It's certainly a possibility for both sides in this debate to say my way or the highway, and wait and see what happens when operators start removing support for IPv4. I'm perfectly find NATing Android, and don't see us giving up the operational benefits to DHCPv6 anytime soon. Oh, I definitely see that DHCPv6 is easier for network operators. 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? It's the same amount of state. Same accountability. Same transaction model. But unlike NA, the device gets as many addresses as it needs. Nothing breaks, and you get future flexibility. Mobile devices don't have to implement NAT, and application developers don't have to work around it. You size your IPv6 pools based on the size of your IPv4 pools, and don't run out of addresses. Technically, that sort of arrangement is superior to IA_NA in basically every way. So... why use IA_NA? Even if the answers are that's what we do in IPv4, and we want to do it the same way, or we're worried that this is strange and will tickle vendor bugs, it's not supported by the IPAM we use today, or this is what we've decided, our network our rules, I would hope that we as an industry can think a little longer term than that. Also, in terms of hotspot functionality being the major driver Don't think about yesterday, think about tomorrow. Tethering and 464xlat are just two examples of what can be done when you have the ability to use 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. -- 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
On 10 June 2015 at 14:03, Mikael Abrahamsson swm...@swm.pp.se wrote: On Wed, 10 Jun 2015, Baldur Norddahl wrote: We use DHCPv6 to assign just one IP address to the CPE. This is because otherwise our routers do not know where to route the /48 that is also passed along with DHCPv6-PD. If you use DHCPv6-PD you only need a LL address, you do not need a GUA address. Yes, a GUA WAN address is nice for fault finding, shows up in traceroute etc, but it's not needed. If your routers require a GUA WAN address in order for DHCPv6-PD to work, then they're not standards compliant. 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. Apart from operational simplicity, we also do not want our routers to keep track of a million ND cache entries. Our system pushes that down to the CPE. In the network we only have one ND cache entry per customer. Well, if you have a GUA /128, then you have two per customer (because you'll have the LL one as well). If you didn't use the GUA address, you'd only have one. Yes my bad, we will have exactly two cache entries per customer. That is still better than SLAAC with unbounded caches and all the possibility of 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? I have nothing against SLAAC it just does not belong in the carrier network. Regards, Baldur
Re: Android (lack of) support for DHCPv6
On 6/9/15, 11:01 PM, Lorenzo Colitti lore...@colitti.com wrote: No, the premise is that from a user's point of view, DHCPv6-only networks cause regressions in functionality compared to IPv4-only or dual-stack networks. For example: IPv4 apps cannot be supported at all due because 464xlat cannot be made to work, and functions such as tethering cannot be implemented because there are no IP addresses to assign to downstream devices. Implementing IPv6 NAT can resolve some but not all of these regressions (for example, IPv4 apps still cannot be supported). Thus, attempting to operate on DHCPv6-only networks a) will create pressure to implement IPv6 NAT, which causes lots of issues like application complexity, battery life issues due to keepalives, etc. b) impose user-visible regressions even if we do implement IPv6 NAT. From a user's point of view, that's just a bad deal, especially since IPv4-only networks, dual-stack networks, and IPv6-only networks using SLAAC do not have any of those issues. Stateless DHCP and stateful DHCPv6 PD have none of those issues, either. If we really need stateful addressing, then we should statefully assign prefixes, not single addresses. WG] ok, I *finally* understand the distinction you're making here, despite the weird way you're making the argument. You're equating DHCPv6-only with single stack IPv6, which is odd, because you're simultaneously waving away concerns about android not working on IPv6-only networks because it won't be able to get addresses by saying that you assume that no one is turning off IPv4 on their network tomorrow since that'll break lots of other things. 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. 1) there are *dual stack* networks out there that happen to support IPv4 and IPv6 via DHCP only (I.e. No SLAAC). This is a fact, and you may not like it, but there's simply no way that you're going to be able to change it in 100% of the situations. Most of the folks involved in this discussion are asserting that Android needs to support those so that the things that can work over IPv6, even with just a single address, will. 2) on a dual stack network, when the device gets fewer IPv6 addresses than it wants/needs, it can continue using the same solution it uses on an IPv4 network, even if it's a sub-optimal NAT-based solution. Having a single IPv6 address is still a net improvement over where we are today, where 100% of the traffic has to be on IPv4 and probably behind multiple layers of NAT. 3) 464xlat being broken is a non-issue on a dual-stack network, since it is expressly designed to act as a shim for IPv4-dependent apps on an IPv6-only network. 4) At some point in the future, there will be IPv6-only networks. At that time, Android will no longer be able to rely on IPv4 as a fallback mechanism, and if it can only get one address, that will break things. Definitely a problem, but not necessarily one that has to be solved immediately, since anyone doing an IPv6-only network today already knows that they need to make a lot of allowances for transition mechanisms and other things to prevent breakage, or are using IPv6-only in tightly controlled situations where there is no breakage because they can ensure 100% IPv6 support among the things using the network. 5) there are multiple possible ways for a device to get multiple IPv6 addresses if it needs them, including DHCPv6 with multiple IA_NA requests, a DCHPv6-PD request, SLAAC, or some sort of bridging that allows multiple virtual interfaces to use the same physical interface, such as the simple type of hypervisor networking that allows multiple VMs to get DHCP addresses assigned from the same network. 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. 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
Re: Android (lack of) support for DHCPv6
Hi Lorenzo, It's certainly possible to make Android request N IPv6 addresses via DHCPv6, and not accept the offer if it is offered fewer than N addresses. But that only really makes sense if there's a generally-agreed upon minimum value of N. 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. I definitely think we should start pushing for N1 because that will really hurt IPv6 in the future. However any fixed N is a potential danger as requirements will change in the future. But maybe we can do something smarter here. 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 DHCPv6 PD and not DHCP NA, and then implement DHCPv6 PD. But I fear similar arguments will be had there. I think this will be more difficult to get consensus on, and I can also see more deployment issues (much more state in the routers for all those PDs, needing huge amounts of /64s (or larger) to be able to deal with a few hundred/thousand clients) but it would be very nice if this was possible :) 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. I don't think it is unreasonable. If the network doesn't support the features you need then let the user know (grey out the feature and add a note that says broken network). It will put pressure on the network department to fix their DHCPv6 implementation. I have read Lorenzo's arguments and while I don't agree with all of them I do see the risk of creating a situation where N=1 is the default. That would be bad. But instead of not supporting DHCPv6 I think we should work on making sure N1. Cheers, Sander
Re: Android (lack of) support for DHCPv6
Hi, No, the premise is that from a user's point of view, DHCPv6-only networks what about DHCPv6 for IPv6 and DHCP for IPv4 - the client should still be able to pick up an IPv6 addressinstead of forcing the only option to be SLAAC ? alan
Re: Android (lack of) support for DHCPv6
Hi, 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. talking of the user experience - any update on when Android will let the user acknowledge a private CA and thus stop the 'your network may be monitored' alert on each restart? :/ alan
Re: Android (lack of) support for DHCPv6
On Wed, 2015-06-10 at 15:32 +0900, Lorenzo Colitti wrote: It's certainly possible to make Android request N IPv6 addresses via DHCPv6, and not accept the offer if it is offered fewer than N addresses. But that only really makes sense if there's a generally-agreed upon minimum value of N. 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. You need as many as you need. Request them. Worry about it if you don't get them. This is exactly what happens when N=1, BTW. A DHCPv6 server is almost certainly not going to have an upper limit that significantly crimps your style... 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
We use DHCPv6 to assign just one IP address to the CPE. This is because otherwise our routers do not know where to route the /48 that is also passed along with DHCPv6-PD. The routers are stupid I know, but it is what we got. So we simply implemented a variant of static routes for 2001:db8:x::/48 to 2001:db8::x/128. The DHCP server knows to give you matching /48 and /128. Apart from operational simplicity, we also do not want our routers to keep track of a million ND cache entries. Our system pushes that down to the CPE. In the network we only have one ND cache entry per customer. The Android tethering guy seems to think that tethering should be a bridge. But it should of course be routed. The phone in tethering mode should be getting exactly what we do - one /128 on the uplink interface and a ton of address space it can use internally and sub delegate to tethering clients. What exactly is the argument against supporting a sane environment like that? As a side note, NAT is not the only solution if someone should try to block tethering. I would propose a VPN tunnel. You can then have as much address space you want from the VPN. This is extra easy if you are not locked into the belief that tethering should be a bridge instead of routed. Regards, Baldur
RE: Android (lack of) support for DHCPv6
From: Lorenzo Colitti [mailto:lore...@colitti.com] Sent: Tuesday, June 09, 2015 11:47 PM To: Tony Hain Cc: Mikael Abrahamsson; Chris Adams; NANOG Subject: Re: Android (lack of) support for DHCPv6 On Wed, Jun 10, 2015 at 3:38 PM, Tony Hain alh-i...@tndh.net wrote:I claim that there is a platform bug, because there is never a reason to ignore the WiFi RA. Use the other flag to set a preference if that is needed, but ignoring the RA just breaks things in unexpected ways. LC has did a hand-wave that the ignore RA flag is needed for battery life, but beyond that we appear to be stuck in a world where Clueless OEMs believe in breaking one network when another might exist. This is not how current Android works. Each network can run IPv4, IPv6 or both independently of any other network. If you can reproduce this on a device running current Android (preferably a Nexus device), please file a bug. There is indeed an issue with OEMs dropping RAs when the screen is off. Because it is the OEM that provides the wifi firmware and not Android, it's not really fair to say it's an Android bug. FWIW, recent Nexus devices do not have that bug. My Nexus tablet does not have a Cell interface, and T-Mobile has stopped releasing updates for my phone, so I can't test that. For the issue I saw in the past, there was no screen-off event. All I had to do was enable the IPv6 APN, and given that I live on the edge of the service area the link would drop at some point shortly after. At that point the expected behavior is that IPv6 would still work via wifi, but no. While it still has an address, and can talk to anything on the wire, it has no router because that was removed and the RA is being ignored. I agree the OEM's are likely the problem here, but the platform should not allow them to create an invalid network state. Doing so only insures that they will pick the wrong options and break the network unnecessarily. Tony
Re: Android (lack of) support for DHCPv6
On 6/10/15, 2:32 AM, Lorenzo Colitti lore...@colitti.com 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.
Re: Android (lack of) support for DHCPv6
On Wed, 10 Jun 2015, George, Wes wrote: On 6/10/15, 9:13 AM, Baldur Norddahl baldur.nordd...@gmail.com 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
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
Re: Android (lack of) support for DHCPv6
On 6/9/15, 11:06 PM, Lorenzo Colitti lore...@colitti.com wrote: Based on the facts, you could could just as well say that Apple is trying to advance the state of the art by refusing to provide suboptimal 464xlat and insisting instead that developers support IPv6-only networks as first-class citizens: https://twitter.com/dteam69/status/608036976990797824 WG] I have suggested before that google needs to do the same thing with their app developers. Since you believe that your market power makes you able to influence the way that people deploy IPv6 (i.e. Not using DHCPv6 because you refuse to support it), perhaps it's time to wield that power to move the needle on IPv6 use in the app community instead of telling network operators that are deploying IPv6 that they're doing it wrong? By the same token, you could argue that not supporting statful DHCPv6 address assignment advances the state of the art by trying to avoid slipping back into a one-address-per-device-NAT-required world. WG] or you could argue that not supporting stateful DHCPv6 blocks IPv6 deployment by preventing it from being used on networks where it is otherwise available on applications that are perfectly happy to have one IPv6 address. That's a lot of traffic that ends up going to the NAT for no good reason. 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
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 wesley.geo...@twcable.com wrote: On 6/10/15, 2:32 AM, Lorenzo Colitti lore...@colitti.com 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
On 6/10/15, 9:13 AM, Baldur Norddahl baldur.nordd...@gmail.com 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
On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy r...@maine.edu 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
On Wed, Jun 10, 2015 at 12:37 PM, Karl Auer ka...@biplane.com.au wrote: RFC 3315 says you just chuck in multiple IA_NA (or IA_TA) options. The server will respond with multiple addresses. And if a device makes a second (, third, fourth, ..) request with a different DUID, it'll get a second (,third, fourth,...) address oo, I guess. It's certainly possible to make Android request N IPv6 addresses via DHCPv6, and not accept the offer if it is offered fewer than N addresses. But that only really makes sense if there's a generally-agreed upon minimum value of N. 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. 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 DHCPv6 PD and not DHCP NA, and then implement DHCPv6 PD. But I fear similar arguments will be had there. 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.
RE: Android (lack of) support for DHCPv6
-Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mikael Abrahamsson Sent: Tuesday, June 09, 2015 10:39 PM To: Chris Adams Cc: nanog@nanog.org Subject: Re: Android (lack of) support for DHCPv6 On Tue, 9 Jun 2015, Chris Adams wrote: Android devices (Samsung and LG) upgraded to Lollipop, I no longer have functioning IPv6 on wifi. They connect and get an address (with privacy extensions even), but do not install an IPv6 default route. They can talk to local IPv6 devices, but not the Internet. My Nexus4 with Android 5.1.1 works just fine with IPv6 on wifi. So talk to your handset manufacturer, they must have broke something. I filed a platform bug on this back in the ICS timeframe, and it still persists. As I recall, there are 2 flags provided by the OS related to RA handling. Rather than using the one that sets a preference between the Cell vs. Wifi interface, at least Samsung (possibly others) have chosen to use the other flag that says to completely ignore the WiFi RA if an RA on the Cell interface has ever occurred. This means devices that have no IPv6 on their Cell interface will appear to work fine on WiFi. I claim that there is a platform bug, because there is never a reason to ignore the WiFi RA. Use the other flag to set a preference if that is needed, but ignoring the RA just breaks things in unexpected ways. LC has did a hand-wave that the ignore RA flag is needed for battery life, but beyond that we appear to be stuck in a world where Clueless OEMs believe in breaking one network when another might exist. As a general comment about this thread; people need to treat the handset as a ROUTER and get over it. Just do a PD and treat it like any other router. Ignore routing protocol announcements from it if when it is run by a customer, but that is no different than any other CPE router. Most handsets now days are more capable than most consumer CPE routers, so moving past the 'it is just a voice endpoint' mindset is appropriate. Tony -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Android (lack of) support for DHCPv6
On Wed, Jun 10, 2015 at 2:36 PM, Hugo Slabbert h...@slabnet.com wrote: Pardon my ignorance as I don't currently have field experience with 464xlat, but my understanding of the technique is that it is (for the most part) dependent on the network cooperating (by providing a DNS64 and NAT64) for it to work properly. My point was not on a SLAAC network, it's possible to implement 464xlat. It was, on a one-address-per-device network, it's impossible to support 464xlat. Here, 464xlat is just an example of a new technology that needs a separate IP address in order to function. There are other current examples, and unless we get stuck in a one-address-per-device word, there will be future examples too. Multiple posters on the bug/request are coming from enterprise/campus networks that have existing AUPs and enforcement techniques prohibiting certain network functions (e.g. content filtering, restricted outbound access, etc.), and would be making an *active choice* as to whether they do or do not want to support functions such as tethering, 464xlat, etc. Sure, but today, it is not common practice for networks to prohibit a device from tethering or from using IPv4-only applications on user-managed devices. From a user's point of view, going to a world where such things are prohibited is a regression. And there it is: SLAAC is better and it isn't that hard; use it instead. It is up to the network operator to make the design choices that best fit their network, including if their design goals are to *restrict* certain network functions. You are saying that you know better. I don't think that's a useful argument to make, since you are also saying that you know better.
Re: Android (lack of) support for DHCPv6
On Wed, Jun 10, 2015 at 3:38 PM, Tony Hain alh-i...@tndh.net wrote:I claim that there is a platform bug, because there is never a reason to ignore the WiFi RA. Use the other flag to set a preference if that is needed, but ignoring the RA just breaks things in unexpected ways. LC has did a hand-wave that the ignore RA flag is needed for battery life, but beyond that we appear to be stuck in a world where Clueless OEMs believe in breaking one network when another might exist. This is not how current Android works. Each network can run IPv4, IPv6 or both independently of any other network. If you can reproduce this on a device running current Android (preferably a Nexus device), please file a bug. There is indeed an issue with OEMs dropping RAs when the screen is off. Because it is the OEM that provides the wifi firmware and not Android, it's not really fair to say it's an Android bug. FWIW, recent Nexus devices do not have that bug.
Re: Android (lack of) support for DHCPv6
On Tue, Jun 9, 2015 at 11:43 PM, Lorenzo Colitti lore...@colitti.com wrote: I don't think that's a useful argument to make, since you are also saying that you know better. Seriously, this is how you are going to respond? You are claiming you know what is best for everyone and I am telling you that I know is best for MY network. Who are you to even begin to understand my requirement or presume to know them better? seriously?
Re: Android (lack of) support for DHCPv6
On Wed, Jun 10, 2015 at 3:49 PM, Jon Bane j...@nnbfn.net wrote: Seriously, this is how you are going to respond? You are claiming you know what is best for everyone and I am telling you that I know is best for MY network. Who are you to even begin to understand my requirement or presume to know them better? Forgive me, I thought you were saying that you know what operating systems need to do. If that's not what you were saying, then please ignore that part of my reply.
RE: Android (lack of) support for DHCPv6
On Tue, 9 Jun 2015, Tony Hain wrote: I filed a platform bug on this back in the ICS timeframe, and it still persists. As I recall, there are 2 flags provided by the OS related to RA handling. Rather than using the one that sets a preference between the Cell vs. Wifi interface, at least Samsung (possibly others) have chosen to use the other flag that says to completely ignore the WiFi RA if an RA on the Cell interface has ever occurred. This means devices that have no IPv6 on their Cell interface will appear to work fine on WiFi. I just re-verified (same Nexus4 using 5.1.1 on swedish mobile provider Tele2): I disable wifi. I have dual stack on my mobile bearer (PDP context). Verified with 10/10 for both ipv4 and ipv6 on test-ipv4.com (no 464xlat though, this is NAT44:ed IPv4 and native IPv6 on the mobile side). I enable wifi. After a few seconds the Nexus4 connects to my home wifi and starts using it, I get 10/10 for IPv4 on test-ipv4.com and 9/10 for IPv6 because my provider DNS resolver doesn't support native IPv6 lookups. I claim that there is a platform bug, because there is never a reason to ignore the WiFi RA. Use the other flag to set a preference if that is needed, but ignoring the RA just breaks things in unexpected ways. LC has did a hand-wave that the ignore RA flag is needed for battery life, but beyond that we appear to be stuck in a world where Clueless OEMs believe in breaking one network when another might exist. Well, it's not present on my Google device anyhow. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Android (lack of) support for DHCPv6
On Tue, 9 Jun 2015, Jon Bane wrote: Seriously, this is how you are going to respond? You are claiming you know what is best for everyone and I am telling you that I know is best for MY network. Who are you to even begin to understand my requirement or presume to know them better? seriously? 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. 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. 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? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Android (lack of) support for DHCPv6
* 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
On Wed, Jun 10, 2015 at 8:35 AM, Tore Anderson t...@fud.no 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 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
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 N1, 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 lore...@colitti.com wrote: On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy r...@maine.edu 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
On Thu, Jun 11, 2015 at 12:35 AM, Tore Anderson t...@fud.no 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
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
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 lore...@colitti.com 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 r...@maine.edu 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 lore...@colitti.com wrote: On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy r...@maine.edu 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
On Thu, Jun 11, 2015 at 12:36 AM, Jeff McAdams je...@iglou.com wrote: Then you need to be far more careful about what you say. When you said Android would still not support... you, very clearly, made a statement of product direction for a Google product. Did you intentionally leave the in that scenario, words that came right before the ones you quoted? How does a sentence that says in that scenario, android would X constitute a statement of direction?
Re: Android (lack of) support for DHCPv6
On 10 June 2015 at 15:53, Mikael Abrahamsson swm...@swm.pp.se 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
* 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
* 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=something reasonable than confirming N=1. That said, I doubt that you can rely on the network accepting N=hundreds or more, 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
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
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 san...@steffann.nl 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
* 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
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
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 lore...@colitti.com wrote: On Thu, Jun 11, 2015 at 12:36 AM, Jeff McAdams je...@iglou.com wrote: Then you need to be far more careful about what you say. When you said Android would still not support... you, very clearly, made a statement of product direction for a Google product. Did you intentionally leave the in that scenario, words that came right before the ones you quoted? How does a sentence that says in that scenario, android would X constitute a statement of direction? -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: Android (lack of) support for DHCPv6
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 lore...@colitti.com wrote: On Thu, Jun 11, 2015 at 12:36 AM, Jeff McAdams je...@iglou.com wrote: Then you need to be far more careful about what you say. When you said Android would still not support... you, very clearly, made a statement of product direction for a Google product. Did you intentionally leave the in that scenario, words that came right before the ones you quoted? How does a sentence that says in that scenario, android would X constitute a statement of direction? -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: Android (lack of) support for DHCPv6
From: Lorenzo Colitti lore...@colitti.commailto:lore...@colitti.com Date: Wednesday, June 10, 2015 at 11:21 AM To: George, Wes wesley.geo...@twcable.commailto:wesley.geo...@twcable.com Cc: NANOG nanog@nanog.orgmailto: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
On Jun 10, 2015, at 11:36 AM, Jeff McAdams je...@iglou.com 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 ATT 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
Re: Android (lack of) support for DHCPv6
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
+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 r...@maine.edu 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 san...@steffann.nl 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
