Re: Android (lack of) support for DHCPv6
On Wed, Jun 10, 2015 at 11:51 AM, Matthew Huff <mhuff@ox.com> wrote:
+1
One IP per device will almost most likely be the preference and implementation in corporate/enterprise deployments. Too much procedure, regulation and other roadblocks prevent any other solution.
Authentication, Authorization, Accounting, ACLS, NMS, IDS, IP management, custom software, and other roadblocks will certainly stall if not stop IPv6 deployments in enterprises if there isn’t at least the choice of static, single IPv6 addresses per device. SLAAC will probably be a complete non-starter in many corporate environments. It is in ours. The more ideologues preach about restoring peer-to-peer connectivity, dynamic IPs, privacy addresses, etc… the less penetration IPv6 will happen in corporate networks.
So, the critical piece of what you assert above appears to be "static", not "single". If a local address management system is always configured to hand out the same /N to the same device, there doesn't seem to be a requirement in the above that N=1.
Lorenzo has detailed why N=1 doesn't work for devices that need to use xlat or which might want to tether other devices; he's volunteered to work with folks on a document and to write code for the case where a device successfully gets a useful value of N>1. Can you help me understand why that doesn't work for you? On the related topic of privacy addresses, I believe we should all be ready for increasing variability in MAC address emitted by devices, and that if you are intending to use MAC auth to assign that /N, you may now be or will soon be surprised. In addition to the work Apple has done and which can be done with Android, see the IEEE work here: http://www.ieee802.org/PrivRecsg/ regards, Ted
On 6/10/15 2:00 PM, Ted Hardie wrote:
Lorenzo has detailed why N=1 doesn't work for devices that need to use xlat
... and it's been well demonstrated that this is a red herring argument since the provider has to configure xlat for it to have any chance of working.
or which might want to tether other devices;
... and this argument has been refuted by the word "bridging." I'm not a fan of N=1 for IPv6, but none of Lorenzo's arguments hold water. -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks!
On Wed, Jun 10, 2015 at 2:16 PM, Doug Barton <dougb@dougbarton.us> wrote:
On 6/10/15 2:00 PM, Ted Hardie wrote:
Lorenzo has detailed why N=1 doesn't work for devices that need to use xlat
... and it's been well demonstrated that this is a red herring argument since the provider has to configure xlat for it to have any chance of working.
or which might want to tether other devices;
... and this argument has been refuted by the word "bridging."
To repeat Valdis' question: And the router knows to send to the "front" address to reach the "back"
address, how, exactly? Seems like somebody should invent a way to assign a prefix to the front address that it can delegate to things behind it. :)
The other option would, of course, be "bridging" plus IPv6 "NAT", and I assume you see the issues there. Back to the question I asked before: does "static" solve the stated problems without "single"? regards, Ted
On 6/10/15 2:27 PM, Ted Hardie wrote:
On Wed, Jun 10, 2015 at 2:16 PM, Doug Barton <dougb@dougbarton.us <mailto:dougb@dougbarton.us>> wrote:
On 6/10/15 2:00 PM, Ted Hardie wrote:
Lorenzo has detailed why N=1 doesn't work for devices that need to use xlat
... and it's been well demonstrated that this is a red herring argument since the provider has to configure xlat for it to have any chance of working.
or which might want to tether other devices;
... and this argument has been refuted by the word "bridging."
To repeat Valdis' question:
And the router knows to send to the "front" address to reach the "back" address, how, exactly? Seems like somebody should invent a way to assign a prefix to the front address that it can delegate to things behind it. :)
I saw that, he was refuted by others, most notably by the simple fact that bridging works now in IPv4, so obviously there is a way to make it work. I think PD is the right answer here of course, but that doesn't mean that bridging is the wrong answer.
The other option would, of course, be "bridging" plus IPv6 "NAT", and I assume you see the issues there.
No, actually I don't. I realize that you and Lorenzo are part of the rabid NAT-hating crowd, but I'm not. I don't think it's the right answer here, but I don't think it's automatically a problem either.
Back to the question I asked before: does "static" solve the stated problems without "single"?
It *could*, but Lorenzo actually does have a point when he talks about not wanting to cripple future application development. I'd also like to see a rough outline of an implementation before commenting further. Meanwhile, DHCPv6 + PD solves all of Lorenzo's stated problems, but he won't implement it because "DHCP." That's not something you can engineer around. Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks!
On Wed, Jun 10, 2015 at 2:36 PM, Doug Barton <dougb@dougbarton.us> wrote:
The other option would, of course, be "bridging" plus IPv6 "NAT", and I
assume you see the issues there.
No, actually I don't. I realize that you and Lorenzo are part of the rabid NAT-hating crowd, but I'm not. I don't think it's the right answer here, but I don't think it's automatically a problem either.
So, I don't think I'm particularly rabid about this, but I have dealt for a long time on the application side with the side effects. Anyone who has had to engineer a system that requires STUN/TURN/ICE can tell you that it is pretty much a dancing bear. The wonder is how sweetly the bear dances, but that it dances at all. If one of the things I'm tethering wants to do RTCWEB, it's going to be painful if it doesn't have its own address, because it will need to hairpin out to do STUN at the very least.
Back to the question I asked before: does "static" solve the stated
problems without "single"?
It *could*, but Lorenzo actually does have a point when he talks about not wanting to cripple future application development. I'd also like to see a rough outline of an implementation before commenting further.
That's fair enough, and some variability in what N is depending on device is as a well. But understanding whether what we're actually looking for is "static" or "single" is a pretty key piece of the requirements scoping, and it sounds like "static" is it, at least from your perspective. Is that a fair assessment? regards, Ted
-- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks!
On 6/10/15 2:46 PM, Ted Hardie wrote:
That's fair enough, and some variability in what N is depending on device is as a well. But understanding whether what we're actually looking for is "static" or "single" is a pretty key piece of the requirements scoping, and it sounds like "static" is it, at least from your perspective. Is that a fair assessment?
Ted, I honestly can't tell if you're deliberately misrepresenting my argument, or if you're just being dense. You snipped the several places in my previous message where I stated what I think the best way forward is. But just in case it's the latter, not the former: "I think PD is the right answer here of course ..." "Meanwhile, DHCPv6 + PD solves all of Lorenzo's stated problems, but he won't implement it because "DHCP." That's not something you can engineer around." Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks!
In-line. On Wed, Jun 10, 2015 at 3:10 PM, Doug Barton <dougb@dougbarton.us> wrote:
On 6/10/15 2:46 PM, Ted Hardie wrote:
But understanding whether what we're actually looking for is "static" or "single" is a pretty key piece of the requirements scoping, and it sounds like "static" is it, at least from your perspective. Is that a fair assessment?
Ted,
I honestly can't tell if you're deliberately misrepresenting my argument, or if you're just being dense. You snipped the several places in my previous message where I stated what I think the best way forward is. But just in case it's the latter, not the former:
"I think PD is the right answer here of course ..."
"Meanwhile, DHCPv6 + PD solves all of Lorenzo's stated problems, but he won't implement it because "DHCP." That's not something you can engineer around."
Doug
I think we lost context here. I started out asking a question in response to this statement by Matthew Huff: Authentication, Authorization, Accounting, ACLS, NMS, IDS, IP management,
custom software, and other roadblocks will certainly stall if not stop IPv6 deployments in enterprises if there isn’t at least the choice of static, single IPv6 addresses per device
My question was whether a mechanism that could provide a consistent mapping from prefix to user (or device) met the requirements above, whatever size the prefix provided happened to be. I wasn't trying to probe for which mechanism in that part of the question. I understand from your comments that you prefer DHCPv6 +PD. regards, Ted --
I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks!
On 06/10/2015 02:36 PM, Doug Barton wrote:
It *could*, but Lorenzo actually does have a point when he talks about not wanting to cripple future application development. I'd also like to see a rough outline of an implementation before commenting further.
Meanwhile, DHCPv6 + PD solves all of Lorenzo's stated problems, but he won't implement it because "DHCP." That's not something you can engineer around.
??? I thought Lorenzo was fine with DHCPv6 so long as it was with PD? Mike
On 6/10/15, 5:27 PM, "Ted Hardie" <ted.ietf@gmail.com> wrote:
... and this argument has been refuted by the word "bridging."
To repeat Valdis' question:
And the router knows to send to the "front" address to reach the "back"
address, how, exactly? Seems like somebody should invent a way to assign a prefix to the front address that it can delegate to things behind it. :)
WG] I made reference to it in a previous message, but since the question was repeated, I'll assume that was missed and repeat the answer. The hypervisor folks seem to have figured this out so that it "just works" without NAT, using virtual interfaces that have their own unique MAC addresses so that they look like unique hosts to the network/DHCP server. I'm using it on my FreeNAS (BSD) box at home with jails, and KVM supports it, so chances are it wouldn't even be that hard to incorporate into Android. Thanks Wes This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
On Wed, Jun 10, 2015 at 2:56 PM, George, Wes <wesley.george@twcable.com> wrote:
On 6/10/15, 5:27 PM, "Ted Hardie" <ted.ietf@gmail.com> wrote:
... and this argument has been refuted by the word "bridging."
To repeat Valdis' question:
And the router knows to send to the "front" address to reach the "back"
address, how, exactly? Seems like somebody should invent a way to assign a prefix to the front address that it can delegate to things behind it. :)
WG] I made reference to it in a previous message, but since the question was repeated, I'll assume that was missed and repeat the answer. The hypervisor folks seem to have figured this out so that it "just works" without NAT, using virtual interfaces that have their own unique MAC addresses so that they look like unique hosts to the network/DHCP server. I'm using it on my FreeNAS (BSD) box at home with jails, and KVM supports it, so chances are it wouldn't even be that hard to incorporate into Android.
Thanks Wes
Hi Wes,
I saw your response, but creating a hypervisor-equivalent network stack inside Android didn't seem particularly easy to me. This may be, however, because I've mostly dealt with OVS-style approaches in the past few years and my calibration is off. If you have pointers to implementations that are for mobile devices, I'd be happy to be educated. regards, Ted
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
From: Ted Hardie <ted.ietf@gmail.com<mailto:ted.ietf@gmail.com>> Date: Wednesday, June 10, 2015 at 6:09 PM To: "George, Wes" <wesley.george@twcable.com<mailto:wesley.george@twcable.com>> Cc: Doug Barton <dougb@dougbarton.us<mailto:dougb@dougbarton.us>>, "nanog@nanog.org<mailto:nanog@nanog.org>" <nanog@nanog.org<mailto:nanog@nanog.org>> Subject: Re: Android (lack of) support for DHCPv6 I saw your response, but creating a hypervisor-equivalent network stack inside Android didn't seem particularly easy to me. This may be, however, because I've mostly dealt with OVS-style approaches in the past few years and my calibration is off. If you have pointers to implementations that are for mobile devices, I'd be happy to be educated. WG] I was merely observing that bridging so that multiple virtual interfaces/devices can share the same interface and get their own addresses is a solved problem generically. From what I can see with KVM, it involves creating a bridge interface or group, and bridging both the physical interface and any virtual interfaces into it, and then standing back. Doesn't seem obvious to me that it requires an entire hypervisor-equivalent network stack to get this one fairly limited feature, and I'm not aware of any mobile implementations, but it does seem to me that its presence in Linux makes it something we shouldn't dismiss out of hand when exploring solutions to this problem given Android's Linux roots - At it's core, it's still a general–purpose computer with a set of network interfaces. I'm not an expert on either Android's networking stack nor Linux's, nor hypervisors, but I have a hunch if this was allowed to move through the existing Android feature development process, we might find some folks that are and can tell us whether this is doable as an alternative to DHCP–PD or SLAAC on networks that generally adhere to the one address per device rule. Thanks Wes ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
On 06/10/2015 03:32 PM, George, Wes wrote:
From: Ted Hardie <ted.ietf@gmail.com<mailto:ted.ietf@gmail.com>> Date: Wednesday, June 10, 2015 at 6:09 PM To: "George, Wes" <wesley.george@twcable.com<mailto:wesley.george@twcable.com>> Cc: Doug Barton <dougb@dougbarton.us<mailto:dougb@dougbarton.us>>, "nanog@nanog.org<mailto:nanog@nanog.org>" <nanog@nanog.org<mailto:nanog@nanog.org>> Subject: Re: Android (lack of) support for DHCPv6
I saw your response, but creating a hypervisor-equivalent network stack inside Android didn't seem particularly easy to me. This may be, however, because I've mostly dealt with OVS-style approaches in the past few years and my calibration is off. If you have pointers to implementations that are for mobile devices, I'd be happy to be educated.
WG] I was merely observing that bridging so that multiple virtual interfaces/devices can share the same interface and get their own addresses is a solved problem generically. From what I can see with KVM, it involves creating a bridge interface or group, and bridging both the physical interface and any virtual interfaces into it, and then standing back. Doesn't seem obvious to me that it requires an entire hypervisor-equivalent network stack to get this one fairly limited feature, and I'm not aware of any mobile implementations, but it does seem to me that its presence in Linux makes it something we shouldn't dismiss out of hand when exploring solutions to this problem given Android's Linux roots - At it's core, it's still a general–purpose computer with a set of network interfaces. I'm not an expert on either Android's networking stack nor Linux's, nor hypervisors, but I have a hunch if this was allowed to move through the existing Android feature development process, we might find some folks that are and can tell us whether this is doable as an alternative to DHCP–PD or SLAAC on networks that generally adhere to the one address per device rule.
Besides, virtualizing the os environment on a phone would be a very interesting thing in its own right. I thought that was gaining momentum at one point as a way to deal with the friction between corpro-IT demands of control, and end user desire to keep nannyware crap off their phone -- just have two vm's with each environment. Mike
Where is Mr. Protocol? When we need him most?!
On Wed, 10 Jun 2015 17:56:10 -0400, "George, Wes" said:
WG] I made reference to it in a previous message, but since the question was repeated, I'll assume that was missed and repeat the answer. The hypervisor folks seem to have figured this out so that it "just works" without NAT, using virtual interfaces that have their own unique MAC addresses so that they look like unique hosts to the network/DHCP server. I'm using it on my FreeNAS (BSD) box at home with jails, and KVM supports it, so chances are it wouldn't even be that hard to incorporate into Android.
It only "just works" if your upstream device doesn't check/care that you're emitting multiple MAC addresses from the same device. Also, it assumes that some moral equivalent of proxy arp is available.
Valdis.Kletnieks@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
I wrote:
Valdis.Kletnieks@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
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.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University
participants (8)
-
Bruce Curtis -
Doug Barton -
George, Wes -
Lyndon Nerenberg -
Masataka Ohta -
Michael Thomas -
Ted Hardie -
Valdis.Kletnieks＠vt.edu