Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability

Erik Kline <> Tue, 07 July 2015 02:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BCF5B1A21AD for <>; Mon, 6 Jul 2015 19:09:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Status: No, score=-1.389 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3t8VDKSHTH6i for <>; Mon, 6 Jul 2015 19:09:07 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20D3A1A21A9 for <>; Mon, 6 Jul 2015 19:09:07 -0700 (PDT)
Received: by wibdq8 with SMTP id dq8so169039427wib.1 for <>; Mon, 06 Jul 2015 19:09:05 -0700 (PDT)
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:content-transfer-encoding; bh=fjwXffxL5ZxLLtcjmp8i6G4kq/J4BFZL7NQiGtzxAbc=; b=LvVV7UPke5Omb2h7dyx8ZhndEr4sWPO/7LKrygXUHuOr5vWldpJtFVB4AMMss6eRsy fw7bZv9JbZewnydpiMxCKvvpogB3W0hGt0Jwh9Ak9tvYqV+lvzKur8tDqZYLEYmPzisq nKN8lkxFmYOCbLrlzrb8Csvgq07pAKIaHeORRKIZSvA4byGG73U0wOaNfxH8Kki2QmxV PQLtAV6JJnsfva71zLaO+AITCT4NWxbz0Q8TPWVjQIKLYoD/CG90PL+Et5NT1Vfur4fv PdZXOKAH0ghpuy/5rHSTi9EXrx8eZxQW1H4jchg/RRHAX2nH5tNl9b5mG7a8tMmBRXdg eYcw==
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:content-transfer-encoding; bh=fjwXffxL5ZxLLtcjmp8i6G4kq/J4BFZL7NQiGtzxAbc=; b=ijuoqGkaEhE2/dWzPkRyG5lWWFP8F8pGTv0hhhcm9oIt5ZZbs+LyQ6qWpIgSn2pa4T 7c3zjrzmXUDIBXIOhnzEcmsSiMpQnF4wArklVWGbnES01SVeZ2BvI/Vukzk4MawXFjaF 4aiPbvkptPWKT5hmzabulY+e8KotA1RrdBNtAQFkkQ5V6aPGb7RVtpTGM68LCrIWggEy SasLNBdvDObPM9dchTB232nnoUg+cs8ytKBRZRVHTeA2OoD501pXUo9srY1c0otelg36 eeniFBmwELfn/W4FvFGnaMcWdhQqxDrkMrg6LWCZ/vUxYKqh588hxU5DEdVFRHz8Xje6 mfYw==
X-Gm-Message-State: ALoCoQkNi3xTlMIbBkErkjThW245buSMRCOLFAa3mLeu8D++hWAWmwhczs8kVuWl/QexpqKsoxpd
X-Received: by with SMTP id b8mr56647024wix.89.1436234945838; Mon, 06 Jul 2015 19:09:05 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 6 Jul 2015 19:08:46 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Erik Kline <>
Date: Tue, 7 Jul 2015 11:08:46 +0900
Message-ID: <>
To: "Fred Baker (fred)" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability
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, 07 Jul 2015 02:09:08 -0000

Some of this could also serve as input to motivate a SAVI document
defining a basic logging protocol.

I still believe that if there where a trivially deployable logging
methodology that captured

    {IP address, timestamp, rfc7039#section-3.2 binding context}

tuples, or even the full data structure entry described in
rfc6620#section-3.1, then the auditing objectives could be well and
truly met.

I think this is still one large unmet need.  (not necessarily a v6ops
matter, perhaps)

On 7 July 2015 at 09:02, Fred Baker (fred) <> wrote:
> Thanks. One question. Chair hat off.
> Section 2 identifies the current deployment model - each interface has a link-local address, a SLAAC address, and one or more temporary addresses. I haven't heard anyone complaining about that. Section 3 goes on to discuss virtual machines/containers, which might each have additional addresses, and the model Facebook is reportedly using, which gives individual addresses to processes. It also mentions draft-herbert-nvo3-ila, which is not a stupid model - I still have some comments on it in a multi-administration environment or for running applications in an "inside" and an "outside" address ("NAT has well-known drawbacks"), but it at least gets rid of the random encapsulations predominant in data centers today.
> In other words, we already assign multiple addresses, by some means, to each interface in a network.
> You mention SLAAC. Lorenzo mentions that in section 7. He also mentions DHCP address and prefix allocation.
> The statement that I don't see in the document, which would help me personally, is a problem statement. I would guess that the problem statement is "we think some networks are limiting host interfaces to a single IPv6 address." I'd want a little more detail, but I'll bet that's the crux of it.
> So my question is: "precisely what problem are we solving here?".
>> On Jul 6, 2015, at 2:39 PM, Andrew Yourtchenko <> wrote:
>> I read the draft and absolutely agree with the spirit.
>> Unfortunately, I think it won't work:
>> As soon as the devices work "good enough" with a single address, appealing to increase the amount of work by administrators in the name of humanity is going to fall on deaf ears.
>> The only way I see to solve this is to always use SLAAC on the devices: either 'externally' from the prefix received within the RA, or 'internally' from within the prefix received via DHCP-PD, and provide a mandatory registration mechanism for name-to-IP mapping.
>> If neither of the above works, as a backup effort the device can try getting N addresses via DHCP IA_NA and release those that it does not need immediately - and displaying a big yellow warning "This network may restrict IPv6 functionality and eat your kittens, contact your system administrator". Because ND is not going to happen on these 'extra' addresses, forwarding wise there will be no impact, just some more DHCP traffic after attachment (the "limited functionality" of course would need just one address and can start immediately).
>> Those who want tracking can track the upper 64bits or use IA_NA and filter out the addresses that are shortly lived.
>> Of course to avoid being a religious crusade such an effort need to produce something pragmatic - namely,
>> a userland cross-platform API that would allow getting new addresses on demand by application and if needs to - implementing custom transport protocols on top of those on a per-app-per-address basis.
>> The above conjecture however is even less realistic than politely asking the inconveniences away, so the logical conclusion from that is I fully support this draft.
>> --a
>>> On 06 Jul 2015, at 13:47, wrote:
>>> A new draft has been posted, at Please take a look at it and comment.
>>> _______________________________________________
>>> v6ops mailing list
> _______________________________________________
> v6ops mailing list