Subject: Comments on draft-smith-ipv6-link-locals-apps-00 (was: Re: [v6ops] IPv6 link-local traffic questions)

From: Toerless Eckert <[email-masked]>
Date: Thu, 12 Mar 2020 22:56:12 +0100

Quite useful document, mark. Some comments:

The benefits bullet points should mention which of the marketed initial benefits (or
others) they map to (robusness, security).

The benefit bullet vs. ULA seems quite theoretical. Why would i even
consider ULA addressing for link-local communications ?

The point about attacks being limited to link-local should maybe
explaing this is based on the assumption of all routers comply to
RFC4291 2.5.6, which has known not to be always correctly handled,
especially in the face of routers having tunnel endpoints into
links/interface (decapsulation of tunnelled link-local packets).
(such secutiy detail might got into security consideration sections).

Close geographic proximity as claimed in the third benefit point
also assumes a planet without L2-VPN services, so better to caveat
that quite common exception. After all, A lot of L2 VPNs only exist
because most applications can't figure out how to deal with service
discovery if the connectivity service is L3, because they only know
how to do this with link-local multicast. Hence we have quite ubiquitous
wide-area distributed virtual links/subnets.

I am not sure i really understand the private VLAN explanation, maybe
rephrase. In any case it sounds like a limitation or bug of the private
VLAN approach if it would deal differently with link-local vs.
global addresses. in fact, the rfc4007 rule for re-forwarding
link-local packets would likely be whats expected to be done
in a private-vlan case is reachability is supposed to be permitted,
but passed through a control port. I don't see that design option
in rfc5517 even though i remember it was part of the larger VLAN
architecture of cisco switches (upstream vs. downstream VLANs
to pass traffic via control ports.). Forgot terminology..

I am not sure about the validity of the issue text about referrals
and mentioning zone information: "receives both the Link-Local
address and correct zone information". It would be helpfull
to mention that the IPv6 architecture has no concept of zone
identification that has more than node-local relevance. Hence
a node receiving link-local address information needs to tag
it with the local zone identifier of the receiving link
and not communicate it across channels that are not tied to that
same link. Unless of course some other system exists that
introduces unique zone identifiers across a larger scope of links
consistent across nodes, in which case tagging link-local addresses
with such a zone identifier would allow to unambiguously distribute
those "zoned" addresses more widely.

Didn't read the socket info, but very interested to have it as
a reference. 

Text is not mentioning the HC choice recommendations especially in face
of rfc4007.

Would be good to have a distinction, which use of link-local
addresses you would qualify as "not application". Ideally without
referring to sockets. I have my own idea, but i don't think there
is a clear definition, so it would be good to explain it to
set the scope. Everything you say beofre the socket part for
example is true for "application" even if they use a different API.

Cheers
    Toerless