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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 14 November 2017 10:08 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 2ADAE126FB3; Tue, 14 Nov 2017 02:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 mNRqrQswXExe; Tue, 14 Nov 2017 02:08:19 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 A44C9126DED; Tue, 14 Nov 2017 02:08:19 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id t69so5084536pfg.4; Tue, 14 Nov 2017 02:08:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=j8ad30FNgbRPlGzEv/o4LIPnCp2ahL1IJabvvn9BaI4=; b=LhN7bkepOxRNdYCG9ofVHxysrGO72H4M3xwg7ZeVH/UrCWrTFK7X0gHnMtApS68kTn dituFEnu9e/A0FF+GQJJQD+iILowxuDu3dir6yLFD3Tguvy2gtIt9tAn4kRL7XoRRFv8 wJ0uhHwNByc5Yt4rUIBAy3CgvS4abQioP53KhuR+7X5w7kJDfL1o6TQg26JKgtJWbkJF 97qfGDUmce4Yqf6Z4jtx1fVBqIcdSWR9+K8l7NXWVzXSPVkUDONc6qVg3/Ho88Y4VaLr Pvq0zmW3to2Ycg64jmK90MKwNBV0X/IiqzKKnZcA15WBnaFjQa1qRk8PqwT7/Hc5vgVe ofsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=j8ad30FNgbRPlGzEv/o4LIPnCp2ahL1IJabvvn9BaI4=; b=Sq2ss2PGw8Zt0G7KRJQ4OtY2AQu8UD0ljCKdxj1njeeTiExJS1dFYNLAQBj75xTUOU OHq8Scg1YOTAwAAN8rNralApIcC0ll/S2PKLk1o7EYdNcW4tr8CJMEAXSNEQ8BC9Exik aSMzbHq5tCpIP+L/Qz22sw/xINpDPOBLNxRSuKfHgm81XJPlNMe5AX/u3XzwpyqdThKt iC6oA7SvsCEY4BitxGODPWI+DwAUsszmdsoFg/oH184NN4utE8f9AJgwK7mWcmfLqYLk Rfqc1xZjApQ8Q0cv2xnsl4nPpRWBl7LYRrBatz8fFUxoaTS94o+Ay/dcsjxi3j5k1LXo bCjg==
X-Gm-Message-State: AJaThX5UK7MQCHN2EaQb7/gk+H9wsD8ER+Uj3V3Z4alVc1M4CtOCxQKe OF5JcZX2pCzwC5TD46WbNXE=
X-Google-Smtp-Source: AGs4zMaQ1JsV92E4lNqigNpml4I/2Hyqr2Ek8eAYtooSbvINbuPJtaC4Y9bZIrX3WN0+KhjIHUfnqg==
X-Received: by 10.99.110.197 with SMTP id j188mr11454932pgc.34.1510654098920; Tue, 14 Nov 2017 02:08:18 -0800 (PST)
Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id b19sm39887338pfd.182.2017.11.14.02.08.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 02:08:17 -0800 (PST)
Subject: Re: [v6ops] Upleveling discussion (was Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))
To: Erik Nordmark <nordmark@acm.org>, "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" <v6ops@ietf.org>
Cc: Suresh Krishnan <suresh.krishnan@gmail.com>, 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> <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> <03e0242b-140b-4da1-89aa-86987358a99d@acm.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <1ee73094-6ae6-fbe1-c9f4-adc4afc2e0c6@gmail.com>
Date: Tue, 14 Nov 2017 23:08:16 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <03e0242b-140b-4da1-89aa-86987358a99d@acm.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZK0-HsZu9Epc-tODHHtqGPIb3ZU>
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 10:08:21 -0000

On 14/11/2017 21:47, Erik Nordmark wrote:
> 
> 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.

That seems a bit alarmist. I don't think the RIRs will be handing out
IPv6 /16 prefixes because operators have lost millions of prefixes
and don't know where they are. Clearly an implementation of this
is going to have a mechanism for recycling these prefixes when
the host has been inactive for X amount of time, or has gone
physically off line, or whatever criterion they prefer to use.
Do we need to specify that? It isn't a wire protocol. 
(Another way to look at it is that the lifetime of the implied
prefix delegation is identical to the advertised router lifetime.
The host doesn't know it's getting a prefix, it just hears about
a router with a certain lifetime. If that isn't refreshed, it
can no longer send packets and the address will also vanish.)

   Brian
 
> 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
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>