Re: 6man w.g. last call for <draft-ietf-6man-grand>

[Mark Smith <[e-mail]>]

Hi Jen,

On Thu, 16 Jul 2020 at 07:59, Jen Linkova <[e-mail]> wrote:
>
> On Thu, Jul 16, 2020 at 6:48 AM Mark Smith <[e-mail]> wrote:
> > Unfortunately I don't support advancement right now, as I've had some
> > further fairly significant suggestions for it which I've been
> > struggling to finding time to provide. Apologies for the delay,
> > started a new job.
>
> Thanks for the ideas!
>
> > In summary, and I'll provide more details and text over the weekend:
> >
> > - I've changed my mind on the idea of an optimisation of not
> > performing this for link-local addresses i.e. only performing it for
> > off-link addresses, for two reasons:
> >


<snip>

> So basically you are suggesting s/GUA/an IPv6 address/g ?
>>

Yes. Do GRAND for all types of addresses the host creates, not just
addresses that might be reached from off link.

It would be marginally simpler for the hosts to do it universally for
all addresses than being selective.

It preloads the routers' neighbor caches with entries for all types of
the host's addresses, so if the router needs to send to a host's
Link-Local Address, the router would already have a neighbor cache
entry for the Link-Local address.

Over time, as GRAND is implemented in hosts, this would also mean that
the routers' neighbor caches become a database of all addresses
present on the link for well behaved hosts, including link-local
addresses, useful for troubleshooting. Also better than DHCPv6 for
address security auditing, as DHCPv6 doesn't record link-local
addresses or SLAAC addresses, although a smart malicious host won't do
any of GRAND, DHCPv6, MLD, DAD or possibly even ND to hide itself. I
think people are realising that scraping a router's ND cache is a
better solution for this.

Thinking about the Link-Local use case, I think routers doing GRAND
towards each other could also be a useful optimisation. As IGPs like
OSPF use Link-Local addresses as neighbor next hop addresses, GRAND
may as well be used to load the neighbor routers' caches with
Link-Local/layer 2 address entries, rather than the remote router
waiting for a packet to trigger ND. BGP using Link-Local addresses
looks to be coming too -
https://www.ietf.org/id/draft-white-linklocalnh-01.txt .

So I think it would be useful to generalise performing GRAND (towards
routers) to all IPv6 nodes, not just hosts.

Thoughts?

(I haven't provided any suggested text, I'll do so if we decide to
have routers perform GRAND too.)

<snip>
>
> Also keep in mind that in some networks only the VRRP master sends
> RAs. So hosts might never know about VRRP backup routers while those
> routers might be in the path for the return traffic flows.
>

Yes, I understand.

I was hoping there might be a way to leverage that Router flag in ND
NAs to somehow detect that situation, so link-layer unicasts could be
used, however I can't think of one.

I think it would be better to remove all the text around link-layer
unicasting of GRAND NAs for the time being.

It would be a useful thing to do if it was possible to easily indicate
to hosts that they're aware of all routers on the link, so they could
link-layer unicast GRAND NAs, however I think that requires developing
a mechanism for that, so should be left to another ID iif we want to
pursue it. ("MLDv2 Procedures for Link-Layer Unicast Delivery of
Multicast IPv6" -
https://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00 - may be
able to be built on.)

Regards,
Mark.

>
> As the current version of the draft suggests sending it to all
> routers, the router lifetime does not really matter.
>
> > On Thu, 16 Jul 2020 at 03:17, Bob Hinden <[e-mail]> wrote:
> > >
> > > Hello,
> > >
> > > This message starts a new two week 6MAN Working Group Last Call on advancing:
> > >
> > >         Title:    Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-
> > >                   Hop Routers
> > >         Author:   Jen Linkova
> > >         Filename: draft-ietf-6man-grand-00
> > >         Pages:    11
> > >         Date:     March 9, 2020
> > >
> > >        https://tools.ietf.org/html/draft-ietf-6man-grand
> > >
> > > as a Proposed Standard.
> > >
> > > Substantive comments and statements of support for publishing this document should be directed to the mailing list.  Editorial suggestions can be sent to the author.  This last call will
> > > end on 29 July 2020.
> > >
> > > Thanks,
> > > Bob & Ole
> > >
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > [e-mail]
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>
>
> --
> SY, Jen Linkova aka Furry