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

[Gyan Mishra <[e-mail]>]

I support advancement of the draft as it fixes a real world Day 1 issue.

Kind Regards

Gyan

On Sun, Jul 19, 2020 at 8:16 PM Gyan Mishra <[e-mail]> wrote:

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

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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