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

Andrew 👽 Yourtchenko <> Tue, 07 July 2015 15:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3F2091A88F4 for <>; Tue, 7 Jul 2015 08:33:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VrFRlagnfmZA for <>; Tue, 7 Jul 2015 08:33:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A638C1A88F3 for <>; Tue, 7 Jul 2015 08:33:55 -0700 (PDT)
Received: by igcsj18 with SMTP id sj18so264652339igc.1 for <>; Tue, 07 Jul 2015 08:33:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N8LiLmkNLGHuGILYDEDhO+kysP31uso+XJSQCbCN8gI=; b=VCxKHphBTSX/OUC/x/HfLbKM1kxK+dx6jOtzgSKUYW1pERAURcu82+dCj0qXer3zs8 J5N1+Su/9Ia/9yXPvrzOfNIK6GjKcn1Bx0w/4gfC9LxwJjDIHMMsK8Y2mpBXweWM2lMN 5NZgMuQiEBv+p6N4D0xeMRnTonb7cq2tBxYfVe5BAfnjc4mkKsX+4stdr2kRFUMeOQou k0hNJUjD5i5laOqXjtz501oAohcqW+BzhE30+3uwyti+dRJKjSqertazyEWZ42GXfP62 d2XLuJEQTTbCqvgfXRijulOVXlgfhCsWSMpTwYsxYZMyh2xNQRUJrrMqixQ5esffIEno VcGg==
MIME-Version: 1.0
X-Received: by with SMTP id 192mr7438731ion.70.1436283233588; Tue, 07 Jul 2015 08:33:53 -0700 (PDT)
Received: by with HTTP; Tue, 7 Jul 2015 08:33:53 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Tue, 7 Jul 2015 17:33:53 +0200
Message-ID: <>
From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= <>
To: "Fred Baker (fred)" <>
Content-Type: text/plain; charset=UTF-8
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 15:33:57 -0000

On 7/7/15, 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.

Lorenzo already commented on the "problem definition" so I will reply
just to this part:

Yes, we both mention them - but I'm arguing the usage of them should
be proactively monitored by the devices themselves. Preferably along
with the tangible benefits provided to the apps when the device is on
a network allowing for more than one address. (Though that is outside
of the "ops" domain).


> 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