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

[Gyan Mishra <[e-mail]>]

Jen

I have not read through the draft again but from what I remember and from
Marks comment having the S flag set on the RS for both GUA and LL.

The point that Mark made for the LL having S flag set on the NS makes sense
for hosts and also routers so that any ND NS/NA a d RD RS/RA entry gets
built immediately then waiting for NA and DAD of during DAD for optimistic
DAD.  Since OSPF uses LL address to FF02::5 ::6 makes sense to help
optimize routing.

Thanks

Gyan

On Sun, Jul 19, 2020 at 6:48 PM Mark Smith <[e-mail]> wrote:

> 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
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD