Android (lack of) support for DHCPv6

Mailman List Mirror (Read Only)
1

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

2

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.

3

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​

4

        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

5

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

6

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.

7

???

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

Mike

8

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

9

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

10

​In-line.

​

​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

11

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

12

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

13

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.

14

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

15

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

16

I wrote:

17

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?