Re: Upleveling discussion (was Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))

Erik Nordmark <nordmark@acm.org> Tue, 14 November 2017 08:47 UTC

Return-Path: <nordmark@acm.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F280126DCA; Tue, 14 Nov 2017 00:47:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 jRjLvhGBOs8o; Tue, 14 Nov 2017 00:47:12 -0800 (PST)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 CF830124D6C; Tue, 14 Nov 2017 00:47:12 -0800 (PST)
Received: from [IPv6:2001:67c:370:1998:b4a8:fb1b:f5d:8e18] (nat64-52.meeting.ietf.org [31.130.238.82]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id vAE8l6uc017802 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Nov 2017 00:47:08 -0800
Subject: Re: Upleveling discussion (was Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))
To: Suresh Krishnan <suresh.krishnan@gmail.com>, "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" <v6ops@ietf.org>
Cc: Fernando Gont <fgont@si6networks.com>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com> <ea772bfd-4004-7f94-8469-b50e3aff0f29@si6networks.com> <F2330138-6842-4C38-B5A0-FB40BFACD038@employees.org> <e40697ca-8017-c9d2-c25d-89087046c9cf@gmail.com> <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com> <CAKD1Yr26NK2osApYZBm8Yd=0X7xcetrxojp6=JHOEAu9BB0q8A@mail.gmail.com> <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> <E67105A3-396B-403C-B741-E9E01CFB5CE7@employees.org> <862687c9-c107-53a8-288a-29049097b0e1@acm.org> <AM5PR0701MB2836C00EA1AAC73E7E63F583E02B0@AM5PR0701MB2836.eurprd07.prod.outlook.com> <CAO42Z2xacRco7ne7biQ93so0k-x4xSnM2jzoB13-sdVRLshQDQ@mail.gmail.com> <CAKD1Yr0Zz6Jxg_ZuEbBkMhBdEaZKOrtx-eUns7KWi9v-5PDBzg@mail.gmail.com> <CAO42Z2xqwRH94dw=XJf5mt3STdDcTYmB_i1NbXP46shdJQeaPA@mail.gmail.com> <E7F9E3EF-B5AA-4698-8BBC-772228129277@fugue.com> <AM5PR0701MB2836DB6E4A3E3F8FC6CA5FE0E0280@AM5PR0701MB2836.eurprd07.prod.outlook.com> <F762F88F-ABCE-4B91-BA75-66D464420AEE@gmail.com>
From: Erik Nordmark <nordmark@acm.org>
Message-ID: <03e0242b-140b-4da1-89aa-86987358a99d@acm.org>
Date: Tue, 14 Nov 2017 16:47:05 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <F762F88F-ABCE-4B91-BA75-66D464420AEE@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVYYb+1VvEUdzG+3j7Xsw7IjqVfAzn/H4ihuZjvGw/LSx1JVUqgnHVevPjWvaEcfb6IS8/2EwTDxZ7dWdespJs90
X-Sonic-ID: C;UMfCZBjJ5xGo5YlQ3iMJ6w== M;hCTWZRjJ5xGo5YlQ3iMJ6w==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Kp8vQPYZ-gTD5Zsgqn31AsiTsh0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2017 08:47:14 -0000

Suresh,

Thanks for summarizing.

On 11/14/2017 11:22 AM, Suresh Krishnan wrote:
> b) Mechanism does not work
> 
> Given that the mechanism has been implemented and deployed by the 
> authors, I have a hard time taking this claim at face value. Providing 
> an unique prefix per host has been standard practice in 3GPP mobile 
> networks for the past *15 years*. based on recommendations from the IETF 
> back at that time. When a mobile attaches, there is state created on the 
> first hop router that does exactly what this draft wants to do. The only 
> issue I see is a lack of mechanism to clean up stale prefixes if the 
> hosts go away, but depending on the deployment this may or may not be an 
> issue.

The draft is claiming more general applicability that what I understand 
has been implemented and/or specified in the draft, in particular when 
it comes to  being able to reclaim the allocated prefixes when the host 
goes away. The fact that this has been solved in particular contexts 
(such as the 3GPP one) when there is some other mechanisms to detect 
when the host goes away doesn't provide any useful information to the 
Internet community how to make this work in the general case, nor any 
indication that it can be made to work in an interoperable way in the 
general case.

My attempt to find out what has actually been implemented to handle 
hasn't indicated that there is any agreement or any common way to 
implement the reclaim in the general case.

Hence I think the current general applicability is misplaced and if this 
draft is implemented it would be a nice excuse to consume all of the 
IPv6 address space since there is no robust way to reclaim the allocated 
prefixes.

Does the IETF really want to make such a statement?


Note that I would have no issue with publishing what has been 
implemented (in 3GPP and/or Cablelabs specifications) but scoped to 
those environments with their specific reclaim mechanisms.

Regards,
    Erik