Re: [Anima] I-D Action: draft-richardson-anima-ipv6-lldp-02.txt

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 08 January 2020 19:55 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA1812012A for <anima@ietfa.amsl.com>; Wed, 8 Jan 2020 11:55:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 7UnqCP4urXRq for <anima@ietfa.amsl.com>; Wed, 8 Jan 2020 11:55:18 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E5C12003E for <anima@ietf.org>; Wed, 8 Jan 2020 11:55:17 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id DBC783897B; Wed, 8 Jan 2020 14:54:55 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EBC4271D; Wed, 8 Jan 2020 14:55:16 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: anima@ietf.org
In-Reply-To: <fe50561c-eca0-3233-ae25-71ecc2eb60f9@gmail.com>
References: <157668862661.4863.8327071161467721979@ietfa.amsl.com> <fe50561c-eca0-3233-ae25-71ecc2eb60f9@gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Wed, 08 Jan 2020 14:55:16 -0500
Message-ID: <4965.1578513316@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/mkGChyimrDEl6VEQJ3r5VryFaXI>
Subject: Re: [Anima] I-D Action: draft-richardson-anima-ipv6-lldp-02.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2020 19:55:21 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    > 1. As I understand it, LLDP has its own Ethertype (0x88cc). It's
    > probably useful to mention that, since it makes things a bit clearer
    > for the reader.

okay, agreed.

    > 2. Also as I understand it, LLDP packets are "typically" multicast,
    > which is fine since it's a requirement for the GRASP DULL instance to
    > work. Is it expected that IPv6-over-LLDP would also use unicast?
    > There's a chunk of typical "IPv6-over-foo" stuff lacking. OK, some of
    > it presumably says "SLAAC not supported except for LL address
    > formation.", etc., but it needs to be there.

LLDP have a multicast L2 destination.
That means that they travel through any unmanaged L2 devices that do no speak
LLDP.  This allows LLDP to find the next adjacent managed L2 device.

This is akin to always sending all your IPv4 traffic to the broadcast address
rather than using ARP.   I've regularly *SEEN THIS IN THE WILD* with Win95
IPv4 Bump-in-the-Stack VPN/remote-desktop systems in the 1990s.

I wouldn't want to specify unicast L2 addressing for these packets, because I
suspect that might require changes on some platforms, but it is something
that could be discussed.

    > 3. Personally I'd go for the "elided IPv6 packet" option. BTW you don't
    > need all 128 bits in the addresses; even 64 bits is overkill. Or put no
    > addresses at all, and rely on the MAC address plus the LL prefix. Also

I agree, we don't need 128 or even 64.
fe80::<L2addr> is what I want to assume.
Not only does it save bytes, but it also makes it much harder to do anything untoward.

    > you don't need the version number or traffic class. (Of course, there's
    > a draft for that:
    > https://tools.ietf.org/html/draft-jiang-asymmetric-ipv6.)

The placement of the FHE octet on the top-right in Figure 2 made me
completely miss it at first.  Maybe... left-align it?

It seems that RFC8138 does most of this, but as you say, it's hard to route.
Can we map between them easily?

>   address will be transformed to a complete IPv6 address.  To achieve
>   this, the gateway should will maintain a globally routeable prefix
                      ^^^^^^^^^^^^^  double word, pick one :-)

I will happily point at this document, if you think it is going to go
somewhere.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-