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

Alexandru Petrescu <> Wed, 15 July 2015 15:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4A4DD1ACD4F for <>; Wed, 15 Jul 2015 08:07:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZRYhT4DNhPeB for <>; Wed, 15 Jul 2015 08:07:15 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A6C401ACD3D for <>; Wed, 15 Jul 2015 08:07:14 -0700 (PDT)
Received: from ( []) by (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6FF7CS1019490 for <>; Wed, 15 Jul 2015 17:07:12 +0200
Received: from (localhost []) by localhost (Postfix) with SMTP id 733FE203876 for <>; Wed, 15 Jul 2015 17:10:38 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 6B3DA203859 for <>; Wed, 15 Jul 2015 17:10:38 +0200 (CEST)
Received: from [] ( []) by (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6FF7ABV029729 for <>; Wed, 15 Jul 2015 17:07:12 +0200
References: <> <> <>
From: Alexandru Petrescu <>
Message-ID: <>
Date: Wed, 15 Jul 2015 17:07:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
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: Wed, 15 Jul 2015 15:07:17 -0000

Le 07/07/2015 02:02, Fred Baker (fred) a écrit :
> 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?".

One problem I see is when operators deliver a single global /64 prefix,
and that /64 is understood as a single IPv6 global address.

Forming multiple IPv6 addresses out of a single /64 is possible for
multiple apps running on that device, so that may not be a problem.
There may be some privacy concerns though, in that an attacker can
identify there is a single device there (the /64 is unique).

But 'sharing' these IPv6 addresses with some other devices (64share) has
more serious drawbacks, typically in the number of subnets - only one
subnet is possible.

(to that, one should add an explanation of why operators deliver a
single /64 to a device - accounting)


>> 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