IETF Logo Mail Archive

Re: 64share v2

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Wed, 11 November 2020 13:33 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 9A1783A0869 for <ipv6@ietfa.amsl.com>; Wed, 11 Nov 2020 05:33:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vPTysA25FZZP for <ipv6@ietfa.amsl.com>; Wed, 11 Nov 2020 05:33:47 -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 AD63F3A0D4D for <ipv6@ietf.org>; Wed, 11 Nov 2020 05:33:46 -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 m1kcqFt-0000FPC; Wed, 11 Nov 2020 14:33:45 +0100
Message-Id: <m1kcqFt-0000FPC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: 64share v2
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <CAD6AjGR-NE_sJ_jp7nAT6OvNkcdE9qoWuGEiiVW7r9YtsQvbbw@mail.gmail.com> <0188AC41-60B0-4BC6-810D-DC59CF9E4FB3@employees.org> <1931a638-64ed-f40e-07a3-67cf1eafb941@joelhalpern.com> <376D6BB0-87E2-42E5-9BC4-F3A2F04FA005@employees.org> <CAD6AjGSr-TPcGo7f9EGgoAahYLQTL68CUSq58LGMgD0=6GmRRg@mail.gmail.com> <8DC674FB-9F90-4C41-A323-62BD62934A12@employees.org> <CAD6AjGTYBs8YbHgCJJG84vgwXK4ZSCm65z6KXvZP9F+LdT_atg@mail.gmail.com> <038A830C-E024-42C6-917E-E6FF57829A1C@employees.or g> <CAD6AjGTQVtJBJ3=aZBsF1WcdSK2k9b1hzeZXM6008w_2vpo6_w@mail.gmail.com> <948ACA2B-E45C-4289-A837-9F2536F20F8F@employees.org> <CAKD1Yr0tDTSH2F4=ZsdMJREy1k6equ9mZV0Au1bJPmKuzxeYVA@mail.gmail.com> <43C449AD-D116-4452-A4F2-79AE5A76539F@employees.org> <m1kcoXQ-0000G1C@stereo.hq.phicoh.net> <alpine.DEB.2.20.2011111248460.15604@uplift.swm.pp.se> <m1kcp60-0000KgC@stereo.hq.phicoh.net> <alpine.DEB.2.20.201111134 1230.15604@uplift.swm.pp.se> <m1kcpyC-0000GfC@stereo.hq.phicoh.net> <alpine.DEB.2.20.2011111417080.15604@up lift.swm.pp.se>
In-reply-to: Your message of "Wed, 11 Nov 2020 14:19:49 +0100 (CET) ." <alpine.DEB.2.20.2011111417080.15604@uplift.swm.pp.se>
Date: Wed, 11 Nov 2020 14:33:44 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ou4YbCzos-1i0DSEonMUl0xBME8>
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: Wed, 11 Nov 2020 13:33:49 -0000

>I don't see how this is a layering violation. Yes, it's a bit fugly but I 
>don't see why it violates layers.

It's a layering violation if you handcraft an IPv6 packet and directly
send it over L2.

The IPv6 protocol is quite specific on how destination caches, neighbor
caches, and neighbor discovery works.

This bypasses all of that and assumes the MAC address of the router is
avaiable outside the neighbor cache.

>I can see equal failure modes here where the upstream router is configured 
>to not respond to such packets.

One option is that we make this mandatory for a new RA option. Another
approach would be to have a flag to specifies if this feature is available.

In any case, I think it important to have a specification on how clients
can detect renumbering events and recover.

v2.23.0 | Report a Bug | By Email