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

[Michael Richardson <[e-mail]>]

Brian E Carpenter <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-