Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion

Lorenzo Colitti <> Tue, 03 November 2015 04:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 602C11B2DA8 for <>; Mon, 2 Nov 2015 20:39:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GEvPZlyWasME for <>; Mon, 2 Nov 2015 20:39:09 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 847AD1B2D9C for <>; Mon, 2 Nov 2015 20:39:09 -0800 (PST)
Received: by ykdr3 with SMTP id r3so5195297ykd.1 for <>; Mon, 02 Nov 2015 20:39:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JIDylqV02fEgu1jJM0G/83BTB/4FrSJUBj2u5KhR85o=; b=h4A7Toy8O1fnNdl5xp2yizvISt4MirMobAMuCtZ6VkJwwz+4l2tQwQS9p+ozZzt4Ia Srl5LQKype2P59NlU3jwgyTTKDvKumwJ56SH6SYGrkPZ7Qr+tvIIIFeKCtFD6HDWhYsJ SxXhzHRHArltAH8byP2XvCKKR7mIFhuxPMCeL+iSjNlE4ZPpBZaFmgL1cOI6MTG6hUOH BFv/mbnZrDFgrATpoSS/jGPMZDEPcUCPu1wRbpFeiZbOFEsR5qhgpX2QOhAIR9A3C2gg 5qX+FvZc6vMTxMCbvoO0ito+CNsUr4uibKl42PSzZOMITt6IjgUXtUvpAeOM2DTidaDp 0zyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JIDylqV02fEgu1jJM0G/83BTB/4FrSJUBj2u5KhR85o=; b=PYPn63sJFIXfLNPGtzVTpolYhEzVDhGhM2SE861EEcCRyncJ4cfq8/65qz4i8eSw6P gUFamr9woxLtVNBMSxmgZUhjX88y4BD9XvE36FJlKQnSKiYVZWJ9w5XbPC9OAdjpLdvL L07RZC4w4pN5U5jkvB23gOx6ajvXkFAT4R1MiRkfO14RKTtdS4N4Bt58E0FI8tcfhgFK C0SXeV8ElvPQzf3EFMIq07GqzH6ylXq+kzqVL5r9B7lBcaQ0iok31vprNYkocFygVBSb T1JuKfUMAexSqzzd7WnwEkqGY7f0ugs5SAxpxgrj6Vl/in+811TEQDzTPwrpBc9xce7U cwYg==
X-Gm-Message-State: ALoCoQlAM/2ZT0BJbLQWLo2EPaVf7DZfWN/yeiyZKk63HPe2AkSmqT6OXjgZZxTZKgdylV+dhnIp
X-Received: by with SMTP id s3mr19176629yws.141.1446525548689; Mon, 02 Nov 2015 20:39:08 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 2 Nov 2015 20:38:49 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Lorenzo Colitti <>
Date: Tue, 3 Nov 2015 13:38:49 +0900
Message-ID: <>
To: David Farmer <>
Content-Type: multipart/alternative; boundary=001a114278de7d710605239b79e8
Archived-At: <>
Cc: "" <>
Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Nov 2015 04:39:11 -0000


that statement makes sense, but I'm worried about scope creep. The document
is focused on recommendations to network operators; if we start adding
recommendations to hosts as well, that might well change the scope of the
draft substantially, and might be the start of a process that results in a
large amount of text being added and takes substantial time to complete.

Example: adding that recommendation to the recommendations section might
result in criticism that that recommendation is not adequately
justified/motivated by the rest of the draft's text. The response to that
criticism might be to add text to the draft to motivate it, but that text
would obviously need to go through the WG, we'd have to gain consensus on
it, etc.

Also, on the text itself: if a host is given an IPv6 prefix via DHCPv6 PD,
I don't know if it's "excessive and unjustified" for it to decide, for
example, to use a different IPv6 address for each server it talks to. The
extra load on the network might well be nil.


On Tue, Nov 3, 2015 at 11:11 AM, David Farmer <> wrote:

> I thought I brought up this issue previously, but I'd like to see
> something addressing excessive use of addresses, maybe adding this as an
> additional paragraph in section 8, recommendations.
>    Conversely, it is RECOMMENDED that hosts and applications not
>    excessively consume IPv6 addresses, such as generating a new address
>    for every connection or with excessive frequency, for instance every
>    few minutes or seconds.  A general-purpose host utilizing several
>    hundreds or thousands of IPv6 addresses seems excessive and
>    unjustified in most situations. This could evoke network operators
>    to deploy DHCPv6 simply to apply sanity limits on the number of
>    IPv6 addresses available per host.
> On 11/1/15 23:15 , Fred Baker (fred) wrote:
>> In the discussion this morning, we wound up in a position that I could
>> not call "consensus", even "rough consensus", but per a hum of those in the
>> room, within shouting distance of achieving that. Several people spoke at
>> the mike asking for a sentence or brief discussion to be added, or a
>> section clarified.
>> In the interest of expediency, let me ask those who spoke (and anyone
>> else that has an issue) to respond to this note (copying the list) with
>> suggested text. It might be best if this is stated as
>> the text that should be replaced goes here
>> the text that should replace it goes here
>> or
>> identify the section the text should go into
>> the text that should be added goes here
>> I'll permit the authors to declare suggested text out of scope; some of
>> the discussion this morning left them commenting on scope and scope creep.
>> However, I do ask them to justify the exclusion to the list, rather than
>> just ignore the email.
>> This comment period ends 15 November.
>> _______________________________________________
>> v6ops mailing list
> --
> ================================================
> David Farmer               Email:
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
> _______________________________________________
> v6ops mailing list