IETF Logo Mail Archive

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

Andrew Yourtchenko <ayourtch@gmail.com> Mon, 06 July 2015 21:39 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 96D561A0282 for <v6ops@ietfa.amsl.com>; Mon, 6 Jul 2015 14:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level:
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 Tm64W2pYHsPg for <v6ops@ietfa.amsl.com>; Mon, 6 Jul 2015 14:39:40 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (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 A0AAA1A0020 for <v6ops@ietf.org>; Mon, 6 Jul 2015 14:39:39 -0700 (PDT)
Received: by wgck11 with SMTP id k11so151621813wgc.0 for <v6ops@ietf.org>; Mon, 06 Jul 2015 14:39:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pAnubSZgkm+RwbR63w0nQffOEI/iPVWA5TWglYapezg=; b=GfftxBc8JBgE0Ad9wo5hjK3necGkTP0RVhiUMhWdrmXNe40mBTJY8zPP0CzG++N5fy HqBIYAdcg6JytAYUw25jqxRyhRdPwYOV9o7KxdBLTqogMSHWspBwl1kxj5bIGbavuuGS C7Zvh3jVS2c4Oi/a4ncTdzWuE7TALmvjEvQrJ4PKR0D5Mry0cnFNTc8rFchndZv7umZd x3cWfn2HgoDi841DZpcwbvyUhWSjmamAZFmenTvrrGSM762yJjtOLZLBRkTlPI3PyTbA 6XiFwIRZq9AYduK4of0xQd7tfmQOf1Bd+ATe1cdVKNALgogSxY4bFkKFIemVoVzrx5t5 VwUA==
X-Received: by 10.194.2.68 with SMTP id 4mr1871403wjs.82.1436218778403; Mon, 06 Jul 2015 14:39:38 -0700 (PDT)
Received: from [192.168.2.76] (254.56.223.213.rev.sfr.net. [213.223.56.254]) by mx.google.com with ESMTPSA id nb9sm30583253wic.10.2015.07.06.14.39.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jul 2015 14:39:37 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Andrew Yourtchenko <ayourtch@gmail.com>
X-Mailer: iPhone Mail (12H143)
In-Reply-To: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com>
Date: Mon, 06 Jul 2015 23:39:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com>
References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com>
To: "fred@cisco.com" <fred@cisco.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/wCeTv7LpeiG1tH0uOvQEC8m2eFk>
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: Mon, 06 Jul 2015 21:39:41 -0000

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

v2.23.0 | Report a Bug | By Email