Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Owen DeLong <owen@delong.com> Thu, 31 October 2019 03:05 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EB81200D6 for <v6ops@ietfa.amsl.com>; Wed, 30 Oct 2019 20:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com
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 I4OI5hrQzysW for <v6ops@ietfa.amsl.com>; Wed, 30 Oct 2019 20:05:35 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0286A1200B2 for <v6ops@ietf.org>; Wed, 30 Oct 2019 20:05:27 -0700 (PDT)
Received: from [172.20.0.85] (rrcs-97-79-186-2.sw.biz.rr.com [97.79.186.2]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id x9V35HB0028958 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Oct 2019 20:05:18 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com x9V35HB0028958
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572491118; bh=XFH33Ktgy42bGpfhrQdUfFOIw0jcgMiwtxNxAoV1XG4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=pvm3IPpiiWz5kskefcNDNJkP58J7af2Jj9Xjt28GnTXhP/bd8l39dzw6hKOxZLfMV ze3u2yo3MX3MgmumgpLclTKIV3PCgotaINx6AtdCACrZic/o5BO2xBkmBCa08n2GmC /fowoLhKb05afXw8do4pXnhZLi/TkLVqUOOxnv/I=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <f2d0633e-6b99-7d64-d718-b4b24c73b494@gmail.com>
Date: Wed, 30 Oct 2019 20:05:16 -0700
Cc: v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6ABAC3D7-30EA-4ECD-8B5F-A04309C208CE@delong.com>
References: <85b1ef40-f107-0ece-3e71-377f4d22dd46@si6networks.com> <bb750ae0-940c-2477-fc6b-cea38af777e5@gmail.com> <9dfd5e47-c593-4145-b530-74fb0f4155ed@www.fastmail.com> <f2d0633e-6b99-7d64-d718-b4b24c73b494@gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Wed, 30 Oct 2019 20:05:18 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/940w-Z1xxUqg8Ol4Ya98OkGSEHQ>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 31 Oct 2019 03:05:37 -0000

8 /64s is a /61.
16 /64s is a /60.
256 /64s is a /56.
You should be getting 65,536 /64s (a /48) and if I were you, I would complain to any ISP that gave me less.

Owen

> On Oct 30, 2019, at 9:29 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
> 
> 
> 
> Le 30/10/2019 à 15:27, Radu-Adrian Feurdean a écrit :
>> On Thu, Oct 24, 2019, at 11:20, Alexandre Petrescu wrote:
>>> In particular, the home networks scenario is very appropriate.
>>> First, I must say that the home network that I use uses a fixed
>>> /56 allocated by my ISP.  In this, the prefix never changes, and it
>>> is not obtained by DHCPv6-PD - it is guaranteed by contract signed
>>> by hand. Such a case could be mentioned, as not being a problem described in this draft.
>> If you are talking about residential service (not business/enterprise-class), I would like to know who your service provider is.
> 
> (my correction: I am not at all good at bit fiddling, sorry.  What I get
> at home is a /60, I think, not a /56.  Because the CPE GUI proposes me
> to split it into 8 /64s).
> 
> YEs, it is at home, probably you mean it is residential.  The payment is
> a flat 35eur/month.  No special QoS commitments from them, other than a
> 'noise level' of 55dbm due to the length of the line.
> 
> The service provider is Free. ('Free' is its name; it was the first
> callable at gratuitous phone numbers when all others requested a payment
> in exchange; later they were the first to offer flat rates when the
> others were per-connection time; because of that it called itself so).
> 
>>> I must say that this kind of software (request a prefix with DHCPv6-PD, form sub-prefixes, and put them in RAs on the other interfaces) does not exist as open source or some other available package.
>> Dibbler-client does that by default. Once the delegated prefix (shorter than /64) is obtained, a /64 from that prefix is assigned to
>> each interface. With proper radvd.conf configuration (prefix ::/64),
>> RAs will be sent for those prefixes.
> 
> I did not know.  The difficulty I talked about is to maintain what's in
> that radvd.conf in sync with what is dhcpd.conf.  Maybe some software
> packages already do it.
> 
> Also, because you talk about deriving /64s out of /56: I am not sure
> there is a standard way to do it.  Maybe dibbler does it, but I doubt it
> is the best way.
> 
>> A lot (?? most ??) of CPEs implementing DHCPv6-PD client do this in some form or another. Some do this automatically (take prefixes and assign them to interfaces), other need manual configuration (n-th prefix go to interface ZZZ).
> 
> It's good to know.
> 
> But again, I doubt these CPEs derive prefixes in the manner that _I_
> want it.
> 
> For example, I want the /60 to be derived into one /64 and a single
> other set of /64s.  I dont want the /60 to be derived into 8 /64s.
> 
> I do that to help aggregation and speed up the forwarding process.
> 
> Other times I might want to derive that /60 differently.
> 
> I dont think there is a standard way to do it.
> 
>>> Because of that, I am surprised that you call it 'the most common deployment scenario'.  Is this a scenario that is _expected_ to be
>>> 'common'?
>> "Expected enough" to warrant a device to be disqualified as "CPE that
>> supports IPv6" if it doesn't work this way. In an ISP environment.
> 
> Well.
> 
> A CPE that supports IPv6 should run DHCPv6.  A CLient and a Server?
> Both?  Just one?
> 
> How does CPE propagate the prefixes learned with its CLient to its Server?
> 
>>> I would like to request addition of two other scenarios:
>>> - an IoT scenario, in which an IoR Router connects several sensors
>>> to the Internet.  For example, an IoT Router is deployed in a box
>>> at a traffic lights.  The IoT device is the Traffic Lights Controller connected on Ethernet to the IoT Router.  The IoT Router
>>> is connected on 4G.
>>> - a vehicular networks scenario: the On-Board Unit is deployed in a
>>> car. This OBU has a 4G interface and an Ethernet interface. There
>>> are several computers in the car that need IPv6 addresses.
>> Like : you have a mobile phone on a network doing IPv6+NAT64,
> 
> My CPE is not doing NAT64, I think.
> 
> I dont want NAT64.
> 
>> you pout it in tethering/mobile-hotspot mode, and connect several other devices (usually laptops) to that hotspot - they all get IPv6 addresses (in the same single /64 that the phone obtained via SLAAC or something else). It is clear that getting a /56 (even a /60 or /62
>> would do it) via DHCPv6-PD would be a nicer solution, but when your
>> mobile device runs android....
> 
> Well.  Android is good in many places and for many goals.
> 
> I agree that tethering/mobile-hotspot mode is a good solution in certain
> circumstances, like sharing one's smartphone connection to tablets nearby.
> 
> However, tethering in IPv6 ('64share' RFC) has some drawbacks: (1) it
> does not support more than the WiFi tethered to the cellular (doesnt
> support an additional subnet like Ethernet) and (2) the incoming
> interface must be cellular (cant be another wifi).
> 
> In a car, one has a WiFi hotspot but also lots of Ethernets and CANs.
> It's not possible to use 64share to accomodate all that.
> 
> Hence, there DHCPv6-PD is not just a nicer solution - it is a requirement.
> 
> Other than cars, even at home, one may want a DHCPv6-PD Server on the
> CPE for similar reasons.
> 
> If one wants to run tethering on a device at home that has no cellular
> connection (e.g. a WiFi<->USB, or a USB<->Ethernet device) to extend to
> other devices then one cant use tethering ('64share'), must use DHCPv6-PD.
> 
> Alex
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops