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

Brian E Carpenter <> Tue, 14 November 2017 10:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2ADAE126FB3; Tue, 14 Nov 2017 02:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mNRqrQswXExe; Tue, 14 Nov 2017 02:08:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A44C9126DED; Tue, 14 Nov 2017 02:08:19 -0800 (PST)
Received: by with SMTP id t69so5084536pfg.4; Tue, 14 Nov 2017 02:08:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id j188mr11454932pgc.34.1510654098920; Tue, 14 Nov 2017 02:08:18 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id b19sm39887338pfd.182.2017. (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 <>, "" <>, " WG" <>
Cc: Suresh Krishnan <>, Fernando Gont <>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
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: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.)

> 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