Re: [v6ops] RFC7934

Ted Lemon <mellon@fugue.com> Wed, 19 July 2017 05:19 UTC

Return-Path: <mellon@fugue.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 9B14A12783A for <v6ops@ietfa.amsl.com>; Tue, 18 Jul 2017 22:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 qXeoqUPnlXE0 for <v6ops@ietfa.amsl.com>; Tue, 18 Jul 2017 22:19:20 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000D81274D0 for <v6ops@ietf.org>; Tue, 18 Jul 2017 22:19:19 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id q85so21834481pfq.1 for <v6ops@ietf.org>; Tue, 18 Jul 2017 22:19:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Oj4v8pcOqSi7nrd+s9vs+0E/R56ZZoigJOxR2cjh5P4=; b=WWFvEDFgzPL22qB8Z9vr1ej8nCGou9rZKXrXuXlWODtHmDhlbrOpE/pFjJycFr19Y3 T7W4paOK4p+hWjAVgblipR8pHmkPW39qwoMWTgcwDdo6QwLtCVk7MXGIksxEy0gP0uJh AUdKY/jm1UPjEVQ9IEOeKr0o2usAXUt9cg63w3p4DgBSvxvtBL445Lc60pz0smqTt2gU EnR8gIVKmW9W7NB1Pa/uuEnDVFRvPE38dmli5+1yTLUCFXG35u5zLMpcOQDK0Byf7RYT n4v+EfQX0CTfBrIYY4tvOwqGamu8RKiLlKu/wYRXF2rIF18StfCI9F75VR6hdYZIzRbs cZ7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Oj4v8pcOqSi7nrd+s9vs+0E/R56ZZoigJOxR2cjh5P4=; b=bhsKpoly2mrW4AZH6PbGQVLdMqAJrt1BF12kauneTFF9U4G+U3YDrKA6BJZNxQMpeM wACFNyyWurvinFVUP+hH4L1BUJ4dLCSugYNxfgS1Xv5QHHCDi3geM/BLKYZOvuZLhSl+ 1YejaxnwEqFDfqZsAb+biDnBdukEOZKukZ58E5XVT/zpzP/erueG3h5mmItxwXqNgodQ pHU/41h8hVQgrD3xI8G9kdfKBIJc5hWSWrcbs7gsgFuXY7EGzjJ/pqJG/HCuxCnYk8ZV Tv4MKLQsJoKeCkm/OmN4PMYAq3rgQA0C7lbw9r9oSYik2edChj1CkKVAUkL3H5vYKEoP FMTw==
X-Gm-Message-State: AIVw113nX9qozvhDPA4BcdjEMqehVX0dGf/wNCnvVcMINwMErd5mIb+6 YidEbbZ15pObEUIguzl0F+c7GqzHu1zM
X-Received: by 10.84.231.16 with SMTP id f16mr1265761plk.131.1500441559525; Tue, 18 Jul 2017 22:19:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 22:19:18 -0700 (PDT)
Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 22:19:18 -0700 (PDT)
In-Reply-To: <CAO42Z2w33kT61p1vemaHRGO71pjO2AADXHj2OsiSNWjGAExNtA@mail.gmail.com>
References: <596CF817.8040900@foobar.org> <CAFU7BAQ5h5dHKmDbOHo9+JCgo+WZpQmctf8F+_0OfJ0dV=tmww@mail.gmail.com> <ef9cc89d-8fbc-47c1-6955-0c005149b13c@gmail.com> <CAPt1N1kkqOYGvHAZU8SysX5QkTxy9gTe=o-HsAx1QKaNUNH4Mg@mail.gmail.com> <3d313591-d770-75db-8ce1-973f724d067a@gmail.com> <CAO42Z2w33kT61p1vemaHRGO71pjO2AADXHj2OsiSNWjGAExNtA@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Wed, 19 Jul 2017 07:19:18 +0200
Message-ID: <CAPt1N1kjVnkwbM-PUzXQNOzMj63q_kdkQqOXSKxDyHguz6z-PA@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
Cc: IPv6 Ops WG <v6ops@ietf.org>, Alexandre Petrescu <alexandre.petrescu@gmail.com>
Content-Type: multipart/alternative; boundary="f40304360182297e430554a4c695"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/LMvwKfoN8Ubz36Mcs3k9LIaSCjE>
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: Wed, 19 Jul 2017 05:19:22 -0000

Prefix+iid=address. But iid is really a misnomer.

On Jul 19, 2017 5:37 AM, "Mark Smith" <markzzzsmith@gmail.com> wrote:

> On 19 July 2017 at 06:09, Alexandre Petrescu
> <alexandre.petrescu@gmail.com> wrote:
> >
> >
> > Le 18/07/2017 à 21:28, Ted Lemon a écrit :
> >>
> >> Alexandre, it's a really important recommendation of the document that
> the
> >> host be allowed to allocate /its own/ addresses,
> >
> >
> > I dont understand how a host can allocate its own addresses.  Or do you
> > mean IID?
> >
>
> I'm sure that is what Ted fundamentally means, although it extends a
> bit beyond choosing just an IID. It also involves how many IIDs to
> generate and use with the received prefixes (one for all prefixes, one
> per prefix, or even mulitple IIDs per prefix) to create addresses.
>
> > (we are very far from Host deciding an address, suggesting it to the
> > network, and the network update the routes - but I think you dont mean
> > that either.)
> >
> > Alex
> >
> >> rather than having to rely on the correctness of the DHCP IA_NA
> >> implementation.   So the language you are proposing would completely
> change
> >> that.
> >>
> >> On Tue, Jul 18, 2017 at 8:47 PM, Alexandre Petrescu
> >> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
> wrote:
> >>
> >> 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
> >>
> >> _______________________________________________ v6ops mailing list
> >> v6ops@ietf.org <mailto:v6ops@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >> <https://www.ietf.org/mailman/listinfo/v6ops>
> >>
> >>
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>