In message <CALFTrnNyvWssFhEJYW8mRjmkYx6i=4nZO+6r7ns5+OU5UYG8eA@mail.gmail.com> , Ray Soucy writes:
The whole conversation is around 464XLAT on IPv6-only networks right? We're going to be dual-stack for a while IMHO, and by the time we can get away with IPv6 only for WiFi, 464 should no longer be relevant because we'll have widespread IPv6 adoption by then.
Or just support DS-Lite along with DHCPv6. DS-Lite does not require its own IPv6 address. 464XLAT and DS-Lite both limit IPv4 packet sizes to less than native. DS-Lite works with DNSSEC. DNS64 doesn't. DS-Lite doesn't require mucking with packet contents. DS-Lite doesn't result in sites being unreachable just because the IPv6 instance is down which is a side effect of DNS64.
Carriers can do IPv6 only because they tightly control the clients, for WiFi clients are and will always be all over the place, so dual stack will be pretty much a given for a long time.
On Wed, Jun 10, 2015 at 9:50 AM, George, Wes <wesley.george@twcable.com> wrote:
On 6/10/15, 2:32 AM, "Lorenzo Colitti" <lorenzo@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 especiall=
y
true for your mention of things like WiFi calling, and all of the other things that aren't tethering or 464xlat, since neither of those are as universally agreed-upon as "must have" on things like enterprise networks= . I'm sure there are also use cases we haven't thought of yet, so I'm not trying to turn this into a debate about which use cases are valid, just observing that you might get more traction with the others.
Asking for more addresses when the user tries to enable features such as tethering, waiting for the network to reply, and disabling the features = if the network does not provide the necessary addresses does not seem like = it would provide a good user experience.
WG] Nor does not having IPv6 at all, and being stuck behind multiple layers of NAT, but for some reason you seem ok with that, which confuses me greatly. The amount of collective time wasted arguing this is likely more than enough to come up with cool ways to optimize the ask/wait/enabl= e function so that it doesn't translate to a bad user experience, and few things on a mobile device are instantaneous anyway, so let's stop acting like it's an unsolvable problem.
Thanks,
Wes
Anything below this line has been added by my company=E2=80=99s mail serv= er, I have no control over it. ----------
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified th= at any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy o= f this E-mail and any printout.
--=20 Ray Patrick Soucy Network Engineer University of Maine System
T: 207-561-3526 F: 207-561-3531
MaineREN, Maine's Research and Education Network www.maineren.net -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org