Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Tue, 03 November 2020 11:28 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 7FB2D3A0147 for <ipv6@ietfa.amsl.com>; Tue, 3 Nov 2020 03:28:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.623
X-Spam-Level:
X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 VdVTLUX2S3lM for <ipv6@ietfa.amsl.com>; Tue, 3 Nov 2020 03:28:26 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136923A0140 for <ipv6@ietf.org>; Tue, 3 Nov 2020 03:28:24 -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 m1kZuU7-0000F1C; Tue, 3 Nov 2020 12:28:19 +0100
Message-Id: <m1kZuU7-0000F1C@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <3c1c3ab5-5726-b141-e7ed-618984bbbdb1@gmail.com>
In-reply-to: Your message of "Tue, 3 Nov 2020 10:41:17 +1300 ." <3c1c3ab5-5726-b141-e7ed-618984bbbdb1@gmail.com>
Date: Tue, 03 Nov 2020 12:28:18 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/U5Ou1W6ivwyBLRbkh3MSkqZ16pY>
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: Tue, 03 Nov 2020 11:28:28 -0000

>How does this work if the router expects hosts to use shorter IIDs but
>hosts in fact use standard 64 bit IIDs? As far as I can see, SLAAC,
>DAD and default address selection will only work correctly if all
>nodes on a given link agree about the prefix and IID lengths. For
>all existing devices, the baked-in code assumes that both are 64.
>
>If a 64 bit node wants to send to a destination with the same
>64 bit prefix that is in fact off-link because the on-link prefix
>is actually supposed to be /68, what happens?

I don't expect any problems here. In the past I did advertise a /96 prefix
om my network and nothing bad happened.

What is supposed to happen is that a host only configures a SLAAC address if
the IID length and the prefix length add up to 128. So existing hosts should
just ignore anything that is not a /64. No address, no need to participate in
DAD.

As for an on-link prefix, this is completely separate from SLAAC. Today
you could have an on-link /68 and use that for DHCP IA_NA and all hosts
should be able to use that.

My personal opinion on this draft is that we spend enough discussing this,
The problem statement doesn't seem to contain new information. 

Of course it is worth looking (probably in v6ops) if there are clear gaps
in our exiting solutions for distributing prefixes.