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

"Fred Baker (fred)" <> Tue, 07 July 2015 00:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6D8491A1DBE for <>; Mon, 6 Jul 2015 17:02:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -114.511
X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CHcrNRZx4j0v for <>; Mon, 6 Jul 2015 17:02:05 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1DF181A1BE0 for <>; Mon, 6 Jul 2015 17:02:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4974; q=dns/txt; s=iport; t=1436227326; x=1437436926; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=r4rJEzuFWxGdJwT2oPCZolbp5aHxs9TpUlVTNHGcXr0=; b=E+ZEAPFR9P0US2suzDrky+Ls5wMArte62j/UE+3b2ZCkcT/Dfz27+o1s BfPQWx5wWWm8HHfwtlXO/P/i2NwOMI1o7aCJMgSyOMVWSFIFM324+KL5R op9Pq8Xh8Ribxfb8qklyKXiUzXtBdVwbsCI/bqXrMjezGZFn0qtvkLrnK Q=;
X-Files: signature.asc : 833
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.15,418,1432598400"; d="asc'?scan'208";a="165998377"
Received: from ([]) by with ESMTP; 07 Jul 2015 00:02:05 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t670248r021504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Jul 2015 00:02:04 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Mon, 6 Jul 2015 19:02:03 -0500
From: "Fred Baker (fred)" <>
To: Andrew Yourtchenko <>
Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability
Thread-Index: AQHQuEgnsal/sN+flU+Nn0z6zYUySg==
Date: Tue, 7 Jul 2015 00:02:03 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_808DB5DF-D140-46B4-A452-E2E44DD78E11"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
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 00:02:07 -0000

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