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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 23 June 2015 11:28 UTC

Return-Path: <alexandru.petrescu@gmail.com>
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 5F4041ACE6D for <v6ops@ietfa.amsl.com>; Tue, 23 Jun 2015 04:28:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.084
X-Spam-Level:
X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 Py0IDoa8N1Jc for <v6ops@ietfa.amsl.com>; Tue, 23 Jun 2015 04:28:12 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4390E1ACE56 for <v6ops@ietf.org>; Tue, 23 Jun 2015 04:28:12 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5NBS5Wr032762; Tue, 23 Jun 2015 13:28:05 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 01962204B47; Tue, 23 Jun 2015 13:30:59 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EA274201F23; Tue, 23 Jun 2015 13:30:58 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5NBS173005377; Tue, 23 Jun 2015 13:28:04 +0200
Message-ID: <558942C1.8020907@gmail.com>
Date: Tue, 23 Jun 2015 13:28:01 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Owen DeLong <owen@delong.com>
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: <5D096119-447C-4637-BE54-DD759CDA1EFF@delong.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/s5YBnVoPv4KnDtY0prrodQb7sOc>
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: Tue, 23 Jun 2015 11:28:14 -0000


Le 22/06/2015 22:50, Owen DeLong a écrit :
>>>> 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)

So I looked at the RIR database.

The RIR already allocated a /19 to that operator.  But the operator 
fitted all its end users within a /47 (each getting a /64.)

The operator should fit all its end users within a /39 (not a /47), and 
each end user must get a /63.  At least.

Is RIR to be questioned when the operator delivers only /64s to end 
users?  Or the operator?

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

Right.  I meant it's not an app supposed to work on both families.  It 
is pure v6.

[...]

Alex