Re: [v6ops] RFC7934

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 18 July 2017 18:47 UTC

Return-Path: <alexandre.petrescu@gmail.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 29E5A12EC11 for <v6ops@ietfa.amsl.com>; Tue, 18 Jul 2017 11:47:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 Hu8IEmvieGEP for <v6ops@ietfa.amsl.com>; Tue, 18 Jul 2017 11:47:26 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0961131BCA for <v6ops@ietf.org>; Tue, 18 Jul 2017 11:47:25 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v6IIlNo6009183 for <v6ops@ietf.org>; Tue, 18 Jul 2017 20:47:23 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E229F205A8C for <v6ops@ietf.org>; Tue, 18 Jul 2017 20:47:23 +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 D8B2E201394 for <v6ops@ietf.org>; Tue, 18 Jul 2017 20:47:23 +0200 (CEST)
Received: from [132.166.84.73] ([132.166.84.73]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6IIlN6b001930 for <v6ops@ietf.org>; Tue, 18 Jul 2017 20:47:23 +0200
To: v6ops@ietf.org
References: <596CF817.8040900@foobar.org> <CAFU7BAQ5h5dHKmDbOHo9+JCgo+WZpQmctf8F+_0OfJ0dV=tmww@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <ef9cc89d-8fbc-47c1-6955-0c005149b13c@gmail.com>
Date: Tue, 18 Jul 2017 20:47:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAFU7BAQ5h5dHKmDbOHo9+JCgo+WZpQmctf8F+_0OfJ0dV=tmww@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/DiLvKo6oUEYjdhle4BNp8EgYJ7k>
Subject: Re: [v6ops] RFC7934
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
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, 18 Jul 2017 18:47:29 -0000

I agree that in the past there may have existed a risk of cellular
networks assigning a single IPv6 address (w/o even a plen) to one UE.
So one wanted a recommendation against DHCPv6 single address per End node.

However, I still think this RFC is a mis-written recommendation.

It would have been much simpler to RECOMMEND to allocate multiple
addresses per End node, as many as that End node requires, be them
individual addresses, or addresses aggregated into prefixes, or multiple
prefixes.

But the current recommendation as it stands looks weird.

Le 18/07/2017 à 17:23, Jen Linkova a écrit :
> I have read the draft and re-read rfc7934 and now I'm completely 
> confused. First of all, I can not see where rfc7934 says that DHCPv6 
> is not recommended.

RFC7934:
> In order to avoid the problems described above and preserve the 
> Internet's ability to support new applications that use more than one
> IPv6 address, it is RECOMMENDED that IPv6 network deployments provide
> multiple IPv6 addresses from each prefix to general-purpose hosts.

What makes one think that some network deployment might block the
forming of multiple IPv6 addresses from each prefix?

Or maybe the "from each prefix" is superfluous?

Because I dont think there is any method that provides a prefix yet
restricts the use to just one address in that prefix.

If a Router sends an RA to many Hosts then each of these Hosts may
configure many addresses within it.

If a Router sends an RA unicast to a Host then that Host may configure
many addresses within it.

If an address is delivered by a DHCP Server, then that is an address
without any prefix specified.

If a prefix is delegated by a DHCP Server then a receiving Client may
configure many addresses within that prefix.

> To support future use cases, it is NOT RECOMMENDED to impose a hard 
> limit on the size of the address pool assigned to a host.

What do you mean?  Is that pool a DHCP pool?  What is an example of
someone imposing a hard limit on the size of that pool?

> Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6
>  address per prefix.

I did not see any place where there is such a restriction.  I wonder
what is an example where a Host was limited to only one IPv6 address
formed out of a prefix.

> Due to the drawbacks imposed by requiring explicit requests for 
> address space (see Section 4), it is RECOMMENDED that the network 
> give the host the ability to use new addresses without requiring 
> explicit requests.  This can be achieved either by allowing the host
>  to form new addresses autonomously (e.g., via SLAAC) or by providing
>  the host with a dedicated /64 prefix.

This "either or" sounds like exclusive or.  But on cellular networks the
Host is provided a dedicated prefix _and_ forms new addresses autonomously.

This is confusing.

> Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide 
> multiple addresses when the host connects (e.g., the approximately 30
> addresses that can fit into a single packet)

?  is there such a restriction in the DHCP spec?  Is it that DHCP
Ack/Advertise could carry only 30 addresses?

> would accommodate current clients, but it sets a limit on the number 
> of addresses available to hosts when they attach and therefore limits
> the development of future applications.

Yes, it would set a limit _if_ DHCP had such a limit.  Do you think DHCP
has a limit in the number of addresses it could assign in an Ack or
Advertise?

> The maximum number of IPv6 addresses that can be provided in a single
> DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, is
> approximately 30.

Do we have a packet dump showing this?  I am asking because 30 addresses
make for 480bytes...

Jen said:
> I had to use all my imagination and still not sure how the phrase 'it
> is RECOMMENDED that the network give the host the ability to use new
> addresses without requiring explicit requests.' can be read as 
> 'DHCPv6 is not recommended'.

Because SLAAC does not obtain addresses by using Requests.  That's DHCP
who uses Requests to obtain addresses.

That RECOMMENDation is clearly written by someone who has some deep
disapproval of DHCP.

> Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA 
> cannot use new addresses without requesting them from a DHCPv6 server
> on the network.' does not seem to be accurate.  As this statement
> appears to be the key point of your document, I believe it needs to
> be fixed before we can proceed.

On my side, I can agree.  But that is your discussion.

Alex