Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-00.txt

Mark Smith <markzzzsmith@gmail.com> Sat, 01 August 2015 01:10 UTC

Return-Path: <markzzzsmith@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 E95371A9075; Fri, 31 Jul 2015 18:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 iJc6Olsan6O0; Fri, 31 Jul 2015 18:10:48 -0700 (PDT)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 E6CF61A9034; Fri, 31 Jul 2015 18:10:47 -0700 (PDT)
Received: by iggf3 with SMTP id f3so27210553igg.1; Fri, 31 Jul 2015 18:10:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QGwwnNITpnmLFeVZ/haNLBsjeeWEhX9VPzecUU3EeTQ=; b=cyXYLU0Toy8xJAWYyTdH0AS8A1LDrKfrNLcLdsCKVaNEZq4PxfRNLT9GxxrGGjx2En odXaQfQ4WRmwChH3tzz3Qz8KiRj8FApE/kAjO1MGWw7IxnjPb1Wd6oePTDvg5nlmn+S/ WvPEYMpigYQloGBWqxIGMxK5AAkCDlH4hMxVLmZQrYNg/GY4PHP0XS2FsPuynrv58AdM I5WiWGlsmOwdA53AbhpF93+oRhyvl10GKwEKenYpmwaaTRda6QFqrfT7hsjubjNHhbfL SlZOk8/BY87LRPje5NXTGppqwQ8UnB+6UaggrKyMnMaiAeXDQGF9tu/B08MWH/dMAqN5 HrVw==
X-Received: by 10.50.64.147 with SMTP id o19mr10654331igs.15.1438391447509; Fri, 31 Jul 2015 18:10:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.169.143 with HTTP; Fri, 31 Jul 2015 18:10:18 -0700 (PDT)
In-Reply-To: <20150731203716.9847.57464.idtracker@ietfa.amsl.com>
References: <20150731203716.9847.57464.idtracker@ietfa.amsl.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sat, 01 Aug 2015 11:10:18 +1000
Message-ID: <CAO42Z2wQK0s48mz80yB1t3Ku4BmVu6O64C6VdoWRYNuC4aCFaA@mail.gmail.com>
To: internet-drafts@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/CXBFYZvIgk4OPja5GkxCcxME-PM>
Cc: v6ops list <v6ops@ietf.org>, i-d-announce@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-00.txt
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: Sat, 01 Aug 2015 01:10:49 -0000

Hi,

I'm still concerned that this intended BCP is recommending
Experimental status NDP and Informational status Sharing /64.

NDP was proposed and then rejected for Sharing a /64 because it
couldn't prevent possible loops forming.

Regarding Sharing a /64, it is a work around, because it violates a
number of IPv6 network routing/addressing models and expectations.
This is why DHCPv6-PD is stated as the right solution when 3GPP
supports it.

One example is that the 3GPP GGSN/PDN-GW (i.e., router) considers all
of the addresses in the "link's" /64 to be potentially present on the
3GPP User Equipment (i.e. host), so it universally forwards all
traffic to addresses within the /64 to the UE (so it is really a host
assigned /64, not a link assigned /64). I think this was done to avoid
having to perform Neighbor Discovery. This is the sort of IPv6
forwarding routers do towards other routers, not when routers are
forwarding across the final hop towards a host.

I think this is only possible when there is a literal point-to-point
link between a single router and a single host. I can't see how it
could be supported on a multi-access link, with potentially multiple
hosts, unless the multi-access link has a different /64 to those that
are used by the one or more individual host /64s. Cutting to the
chase, I'm now describing a scenario that is already satisfied by
DHCPv6-PD.

Regards,
Mark.