Re: [v6ops] Apple and IPv6, a few clarifications - 64share

Mark Andrews <marka@isc.org> Mon, 22 June 2015 23:11 UTC

Return-Path: <marka@isc.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2261B2A5B for <v6ops@ietfa.amsl.com>; Mon, 22 Jun 2015 16:11:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8YEgFXoMWB6 for <v6ops@ietfa.amsl.com>; Mon, 22 Jun 2015 16:11:41 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DD01A8AA5 for <v6ops@ietf.org>; Mon, 22 Jun 2015 16:11:41 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 7142B1FCC83; Mon, 22 Jun 2015 23:11:37 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 5956D160077; Mon, 22 Jun 2015 23:12:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3F534160076; Mon, 22 Jun 2015 23:12:16 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id V-J8Zz3E5Csq; Mon, 22 Jun 2015 23:12:16 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 98677160041; Mon, 22 Jun 2015 23:12:15 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 10A42311C0A3; Tue, 23 Jun 2015 09:11:33 +1000 (EST)
To: Owen DeLong <owen@delong.com>
From: Mark Andrews <marka@isc.org>
References: <E1C235B5-1421-4DAF-A2F3-F963982233DF@apple.com> <5587EFDD.6030807@gmail.com> <7075A962-5B82-4922-B037-AF71D2591C5F@delong.com> <55886B02.80604@gmail.com> <5D096119-447C-4637-BE54-DD759CDA1EFF@delong.com>
In-reply-to: Your message of "Mon, 22 Jun 2015 13:50:26 -0700." <5D096119-447C-4637-BE54-DD759CDA1EFF@delong.com>
Date: Tue, 23 Jun 2015 09:11:33 +1000
Message-Id: <20150622231133.10A42311C0A3@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/FHw_KW-cm7ugMmXuarEYNrlCT9Y>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2015 23:11:43 -0000

In message <5D096119-447C-4637-BE54-DD759CDA1EFF@delong.com>om>, Owen DeLong write
s:
>
> >>> It is better to tell the operator to provide a /63 to smartphones
> >>> (not a /64), with DHCPv6 Prefix Delegation.  That will fix it.
> >>
> >> No...
> >> If you're going to go to PD, a /63 is stupid. Ideally, use a /48,
> >
> > Well, one cellular network operator has a /47 to 'share' with all its
> > customer UEs.  If that operator gave a /48 to an UE it could satisfy
> > only 2 such customers, not millions.
>
> That is a problem that is easy to solve with a simple interaction with
> their RIR.
>
> Give me a break.
>
> We should not be designing around providers that didn't ask for enough
> IPv6 space for their deployments. We should educate those providers.
> IPv6 space is easy to get. A cellular network is an ISP almost by definition.
>
> There isn't a single RIR on the planet that won't grant you at least a /32
> if you walk up and say "I'm an ISP, /32 please" in any credible way.
>
> (modulo payment of fees, etc., but you get the point)
>
> >> but at least provide enough subnets to cover BT, USB, 2.4, and 5Ghz
> >> plus some headroom for future applications.
> >
> > I agree, headroom should be provided.
> >
> >>>> *) Internet Sharing on the Mac Today, regular internet sharing
> >>>> (from your ethernet to Wi-Fi for example) does not support IPv6
> >>>> because of the limited use cases, and the lack of demand for it.
> >>>
> >>> If you get done the above then you get Internet Sharing on the Mac
> >>> Today as well, for free.
> >>
> >> Since iOS and OSX  are separate code bases, I'm not sure why you
> >> think that.
> >
> > Because the DHCPv6 Prefix Delegation is a userspace application
> > implementing a protocol - suffices it to compile on each of these
> > code bases.  It acts the same everywhere.
>
> Yes and no.
>
> > It's not a GUI, or some kernel module, or some AF-dependent software.
>
> Well...
>  It is actually AF-dependent. DHCPv6 will not work on IPv4 very well at
> all.
>
> >>>> *) Internet Sharing on the Mac - NAT64 testing mode The NAT64
> >>>> test mode was designed to help developers ensure that their app
> >>>> can still function with IPv6-only NAT64+DNS64 connectivity and
> >>>> communicate with their IPv4 server, even if the developer does
> >>>> not have access to the IPv6 internet. That NAT64 network does
> >>>> not have IPv6 connectivity to the global IPv6 internet. As such,
> >>>> the current version advertises addresses from 2001::/64 instead
> >>>> of ULAs to simulate real IPv6 connectivity, as all IPv6 packets
> >>>> are terminated at the NAT64 server on the Mac. This
> >>>> implementation detail could change in the future.
> >>>
> >>> Makes sense.
> >>>
> >>
> >> Not really...
> >>  This address is currently in the IANA free pool. It
> >> could be assigned to an RIR and then put on a real network at any
> >> point in the future.
> >>
> >> It would be much better to use a /64 Apple can set aside from their
> >> own space or some other block of addresses registered for this
> >> purpose...
> >>  Heck, worst case, Apple could sign up for a free tunnel
> >> from HE and burn the /64 assigned to that tunnel.
> >>
> >> Ideally, the prefix should be user configurable as well.
> >
> > I think I didnt read the message as you did.
> >
> > I assume by 2001::/64 is meant actually 2001::/3, or some other
> > 2001:X:Y:U:Z::/64 that the operator prodived.  I think it was said
> > 2001::/3 to distiguish from ULA fd00::/something, and so I said it made
> > sense.
>
> I heard 2001::/64 and took them at their word. If 2001::/64 is a mistake
> and they're
> using something legitimate, then no problem. If I misheard, then also no
> problem.
>
> Either is possible.
>
> >
> > And, if what is said is really meaning 2001::/64 then I agree with you -
> > that's at IANA and one wouldn't juggle with 2001::/64 just like that.
> > If one wants to juggle with something then it's with fd00::/64
> > (ULA) and with 2001:db8::/32 (docu prefix).
>
> I have a problem with putting 2001:db8::/32 on actual hardware...
> I think that violates its intended purpose in the vast majority of
> cases, including this one.
>
> It shouldn't be too hard for Apple to come up with a /64 they can
> delegate to this safely.
>
> Beyond that, I still think that having it be user configurable is
> desirable for a wider range of testing scenarios to be supported.
>
> >
> >>>> *) Making IPv4 literals work on NAT64 networks when using
> >>>> high-level APIs Starting with this year's versions, if you use
> >>>> NSURLSession to connect to an IPv4 literal on an IPv6-only
> >>>> NAT64-DNS64 network, the API will bump in a IPv6 literal
> >>>> synthesized using RFC 7050. Note that this will not happen when
> >>>> using sockets directly. We do not support under-the-sockets
> >>>> bump-in-API (RFC 3338) and we do not support 464XLAT.
> >>
> >> They really should support 464XLAT at this point IMHO, though some of
> >> what they are doing may obviate or lessen the need. It will be
> >> interesting to see if this is sufficient for T-Mo to finally turn on
> >> IPv6 for my phone.
> >>
> >> Ideally, T-Mo should pull their head out [...] about dual-stack and
> >> Apple should pull their head out [...] about 464XLAT, but either one
> >> would meet my immediate needs.
> >
> > I wouldnt put it that blunt.  But I would agree that less transitioning
> > be faster transition.
>
> I've tried polite...
>  They haven't listened. Maybe if I'm blunt it will get their attention.
>
> If you have another alternative that might work, I'm open to it.
>
> >
> >> Unfortunately, they're both sitting there playing internet chicken
> >> waiting for the other one to blink.
> >>
> >> Given the number of other cellular networks that are following the
> >> same path as T-Mo, I think mass is on their side, but Apple may be
> >> too stubborn to blink and a head-on may be inevitable.
> >
> > I think I agree with you.  I am very happy one particular operator
> > leads with IPv6 deployment in a successful way.  But I am very unhappy
> > that operation is taken blindly as an example by other operators.  It has
> > drawbacks.
>
> Actually, T-Mo DOES NOT LEAD. Verizon led and was _WAY_ ahead of T-Mo and
> implemented dual-stack.
>
> Owen

464XLAT with DNS64 is a ABOMINATION.  The sooner it is removed the
better.  It only APPEARS to work well at the moment because there
is not a lot of validation happening in the application yet.  It
does not work with a validating recursive nameservers forwarding
queries to a DNS64 recursive server.

MAP and DS-Lite both do a better job and neither of them muck with
packet payload.  They also work with DNSSEC (464XLAT is usually
deployed with DNS64 and DNS64 DOES NOT WORK WITH DNSSEC (CD=1 does
NOT indicate validation is occuring despite what is written in RFC
6147, DO=1 is the ONLY indicatator that validation MAY be occuring.)).

All three have PMTU issues.

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