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

Owen DeLong <> Mon, 22 June 2015 20:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0B48E1A873B for <>; Mon, 22 Jun 2015 13:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.59
X-Spam-Level: *
X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M7jfXudbczRg for <>; Mon, 22 Jun 2015 13:50:28 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id C5C8A1A6F2D for <>; Mon, 22 Jun 2015 13:50:28 -0700 (PDT)
Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by (8.14.4/8.14.2) with ESMTP id t5MKoQG6003955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 13:50:26 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_FF09F927-ADEE-406B-9481-E67FB8BCEBAE"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Owen DeLong <>
In-Reply-To: <>
Date: Mon, 22 Jun 2015 13:50:26 -0700
Message-Id: <>
References: <> <> <> <>
To: Alexandru Petrescu <>
X-Mailer: Apple Mail (2.2098)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 ( [IPv6:2620:0:930::200:2]); Mon, 22 Jun 2015 13:50:26 -0700 (PDT)
Archived-At: <>
Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Jun 2015 20:50:31 -0000

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

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.