Re: Extending a /64

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Mon, 09 November 2020 11:02 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00A43A0E87 for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 03:02:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 gLhZI8QiTYbI for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 03:02:03 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC15D3A0E83 for <ipv6@ietf.org>; Mon, 9 Nov 2020 03:02:02 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kc4vt-0000KMC; Mon, 9 Nov 2020 12:01:57 +0100
Message-Id: <m1kc4vt-0000KMC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: Extending a /64
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <005ECBB3-088B-4363-BB53-8D4AD25CA3D2@employees.org> <da13ad27-7493-c350-5a0b-38776f5e065e@gmail.com> <634E73FD-5809-4C1E-AE8C-C94D9CDE034E@employees.org> <m1kc4Ri-0000KVC@stereo.hq.phicoh.net> <46496F56-7430-493C-8FF3-D1A0D6D3218A@employees.org>
In-reply-to: Your message of "Mon, 9 Nov 2020 11:38:42 +0100 ." <46496F56-7430-493C-8FF3-D1A0D6D3218A@employees.org>
Date: Mon, 09 Nov 2020 12:01:56 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/JNw0FyiLDqDfE-APHrbXr1ieRn8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2020 11:02:05 -0000

> Right. Take the following solution:
> 
>  - there is no subnet prefix / on-link prefix.  - hosts are assigned
>  single addresses via DHCPv6
> 
> The whole concept of interface-id's then become quite abstract.

Assuming current deployments with shared access links, then in my experience,
a router needs to know the subnet prefix. 

> And you could argue that the concept of interface-id's only exist
> within the constraints of subnet-prefixes and SLAAC.

So I'd argue no, on a shared access link you have, explictly or implictly a
subnet prefix and therefor interface ID's

> Is it a requirement that solutions support SLAAC (or current SLAAC)?
> I would argue no.

In the past some people have argued quite strongly against single addresses
via DHCPv6. 

The lack of addresses problem associated with IA_NA could be solved with IA_PD.

However, if we say that we solve the problem with some combination of IA_NA
and IA_PD, then we have come full circle and solve problem that comes from a
lack of PD with more PD.

That may still work if the lack of PD is at an administrative boundary and
then within the client network we solve the lack of address problem with
IA_PD and IA_NA.