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

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Jan 2020 14:30:53 +1300

Finally got around to reading this...

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.

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.

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 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.) 

Regards
   Brian

On 19-Dec-19 06:03, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : IPv6 over Link-Local Discovery Protocol
>         Author          : Michael Richardson
> 	Filename        : draft-richardson-anima-ipv6-lldp-02.txt
> 	Pages           : 6
> 	Date            : 2019-12-18
> 
> Abstract:
>    This document describes a mechanism to encapsulate IPv6 packets over
>    the Link-Local Discovery Protocol (LLDP).  The LLDP is a single
>    layer-two protocol and is never forwarded, which is a desireable
>    property when building the IPv6-over-IPsec-over-IPv6-Link-Local
>    tunnels that make up the ANIMA Autonomic Control Plane (ACP).
> 
>    This unorthodox encapsulation avoids unwanted interactions between
>    the ACP packets and native packet forwarding engines, as well as
>    being safe for layer-2 switches which might otherwise have no IPv6
>    capabilities.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-richardson-anima-ipv6-lldp/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-richardson-anima-ipv6-lldp-02
> https://datatracker.ietf.org/doc/html/draft-richardson-anima-ipv6-lldp-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-richardson-anima-ipv6-lldp-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Jan 2020 14:55:16 -0500

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