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

Andrew 👽 Yourtchenko <ayourtch@gmail.com> Tue, 07 July 2015 15:33 UTC

Return-Path: <ayourtch@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 3F2091A88F4 for <v6ops@ietfa.amsl.com>; Tue, 7 Jul 2015 08:33:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrFRlagnfmZA for <v6ops@ietfa.amsl.com>; Tue, 7 Jul 2015 08:33:55 -0700 (PDT)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A638C1A88F3 for <v6ops@ietf.org>; Tue, 7 Jul 2015 08:33:55 -0700 (PDT)
Received: by igcsj18 with SMTP id sj18so264652339igc.1 for <v6ops@ietf.org>; Tue, 07 Jul 2015 08:33:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.107.13.201 with SMTP id 192mr7438731ion.70.1436283233588; Tue, 07 Jul 2015 08:33:53 -0700 (PDT)
Received: by 10.107.182.7 with HTTP; Tue, 7 Jul 2015 08:33:53 -0700 (PDT)
In-Reply-To: <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com>
References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com>
Date: Tue, 7 Jul 2015 17:33:53 +0200
Message-ID: <CAPi140OgqM-e8x+anzBc6gk7jt4AGqP2xZO4wkhRy88E22tJgg@mail.gmail.com>
From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= <ayourtch@gmail.com>
To: "Fred Baker (fred)" <fred@cisco.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/nqixPZMnGFTtk9t4IGHgxejELWg>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" <draft-colitti-v6ops-host-addr-availability@tools.ietf.org>
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: Tue, 07 Jul 2015 15:33:57 -0000

On 7/7/15, Fred Baker (fred) <fred@cisco.com>; 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).

--a

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