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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 15 July 2015 15:07 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4DD1ACD4F for <v6ops@ietfa.amsl.com>; Wed, 15 Jul 2015 08:07:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRYhT4DNhPeB for <v6ops@ietfa.amsl.com>; Wed, 15 Jul 2015 08:07:15 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C401ACD3D for <v6ops@ietf.org>; Wed, 15 Jul 2015 08:07:14 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6FF7CS1019490 for <v6ops@ietf.org>; Wed, 15 Jul 2015 17:07:12 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 733FE203876 for <v6ops@ietf.org>; Wed, 15 Jul 2015 17:10:38 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6B3DA203859 for <v6ops@ietf.org>; Wed, 15 Jul 2015 17:10:38 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6FF7ABV029729 for <v6ops@ietf.org>; Wed, 15 Jul 2015 17:07:12 +0200
To: v6ops@ietf.org
References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com>
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Message-ID: <55A6771E.30805@gmail.com>
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: <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/gyf1ZEYx2wDPyJ5Q3SjdkDpyRSM>
Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=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)

Alex



>
>> On Jul 6, 2015, at 2:39 PM, Andrew Yourtchenko
>> <ayourtch@gmail.com>; 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, fred@cisco.com wrote:
>>>
>>> A new draft has been posted, at
>>> http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability.
>>>
>>>
>>>
>>>
Please take a look at it and comment.
>>>
>>> _______________________________________________ v6ops mailing
>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> _______________________________________________ v6ops mailing list
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>