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

From: Bob Hinden <[email-masked]>
Date: Wed, 15 Jul 2020 10:16:53 -0700

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 15 Jul 2020 14:39:14 -0400

I support advancement of this document as a Proposed Standard for 
consideration by the IESG and IETF as a whole.

The document is clear.  It addresses a real issue in an effective 
fashion.  It provides good discussion of the reasons for the specific 
choices that are made.

Thank you,
Joel

On 7/15/2020 1:16 PM, Bob Hinden wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 15 Jul 2020 22:02:14 +0200

+1

El 15/7/20 20:39, "ipv6 en nombre de Joel M. Halpern" <[email-masked] en nombre de [email-masked]> escribió:

    Thank you,
    Joel

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 Jul 2020 06:47:34 +1000

Hi,

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.

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:

  -  IPv6 routers may need to send ICMPv6 messages to hosts, and can
use and will prefer link-local addresses for that if possible.

  - IPv6 routers can forward packets with link-local addresses as long
as it is back on to the same link, per RFC4007 (I'm not sure of the
use case, perhaps NBMA links? draft-smith-6man-link-locals-off-link
would allow it on multiaccess broadcast links).

  Both of these cases means that using GRAND to proactively load a
router's ND cache with entries for a hosts' link-local address(s)
would be beneficial, and it would be a simpler mechanism to do GRAND
for all types of new addresses regardless.

- Regarding the idea of using link-lay unicasts to send these
messages, another way to identify routers to send them to would be to
use the Router flag that is supplied in ND NAs. Needs a bit more
thought, however this may overcome the limitation of hosts not being
required to keep all routers in their default router list. Possibly
hosts will remember these ND NA cache entries, for the purposes of
NUD, even though they might not remember the corresponding RA router
entries on their Default Router list.

(Actually, thinking about it more right now, RA announced routers
don't have to be default routers i.e. Router Lifetime == 0, they can
supply more specific routes to hosts via the RFC4191 Route Information
Option, not sure if it is mandatory for hosts to remember all RIOs and
their announcing, RL==0 routers. (Senario: All routers' RAs RL=0, RAs
however have RIOs, hosts ignore RIOs so can't reach anything if RIOs
are optional to remember))

Apologies again for the delay.

Regards,
Mark.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 16 Jul 2020 07:59:33 +1000

> struggling to finding time to provide. Apologies for the delay,

Thanks for the ideas!

> use and will prefer link-local addresses for that if possible.

I guess you would provide more details over the weekend but right now
I'm struggling to imagine the scenario...
The host has configured a new link-local address.
The router knows that link-local address and  needs to send the
message to but does not know the MAC?
Do you mean ICMPv6 messages originated by the router?
The only case I can think about is:
- the host sends an RS from an Optimistic link-local (or just did not
include SLLAO into the RS) AND the router is sending the solicited RAs
as unicast. However in that particular scenario there will be no
packet loss as the router would buffer that single packet while
performing the neighbor discovery,

Also keep in mind that even if the host did not include the SLLAO into
the RS when joining the network, the router will populate the NC entry
for the host link-local address *very soon* anyway, as the host would
be sending NSes for the router address. Those NSes would trigger the
cache population without causing packet loss.

> would allow it on multiaccess broadcast links).

Private vlans for peer2peer isolation, for example. All hosts are on
the same /64, L bit set 0 but somehow a host wants to talk to another
host and the router/firewall policy permits this. A bit weird but
possible.
However, again, I'm not sure it would really happen *before* the
router gets its neighbor cache populated for the hist link-local
address automatically due to NUD.

> for all types of new addresses regardless.

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

> entries on their Default Router list.

Could you please elaborate? Why would the host even receive those NAs
- what address would they send NS for?
So when the host sends an RS and get RAs from every router, the host
shall remember that those link-locals are special and perform NUD for
those addresses?
or am I confused?

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.

> are optional to remember))

As the current version of the draft suggests sending it to all
routers, the router lifetime does not really matter.

-- 
SY, Jen Linkova aka Furry

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Jul 2020 20:07:56 -0400

I have read draft-ietf-6man-grand-00 back before it was adopted.
I thought it was a good idea then.
The document has not changed since so it must still be a good idea.

I don't know why the WGLC took so long.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Bob Hinden <[email-masked]>
Date: Thu, 16 Jul 2020 15:15:46 -0700

Michael,

> On Jul 15, 2020, at 5:07 PM, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

It was being coordinated with draft-ietf-v6ops-nd-cache-init in v6ops, and Jen recently told us it was ready for w.g. last call.

Bob

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 17 Jul 2020 09:19:14 +0000

Without any hat

I obviously support this document and I appreciate the discussion about multicast traffic. Some comments/suggestions below

Section 1: "RFC4861 implies" or "RFC4861 assumes" ?
Section 1: missing the final '.' at the end of paragraph 2
Everywhere: ensure to use consistent capitalization for " Link-Layer Address", suggest all lower cases except when introducing acronyms.
Strongly suggest not to use LLA for link-layer address... as it is confusing with Link-Local Address... What about L2A ? Also some typos such as " link-layaer"
Section 2.1, 1st para: why limiting the last sentence to global IPv6 addresses? Need to check but I guess link-local address may also change (albeit rarely)
Section 2.1 mixes normative text and explanations. Suggest to create a subsection for explanations/justifications
Section 2.2 the normative does not specify what to do when an ND entry already exist. A pointer to section 3 is really welcome here (even if it immediately follows)
Section 2.2 suggest to change " This document suggests that" into "This document updates RFC 4861 so that"
Section 3.2, if there is no entry, then how can it be 'updated' ? 
Section 4.1.2 sentence " These advertisements MUST be separated by at least RetransTimer seconds." is repeated unnecessary IMHO

Please run a spell checker: " nessesary", and possibly other typos

Good job: simple modification, easy to deploy and debug

-éric

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of Bob Hinden <[email-masked]>
Date: Wednesday, 15 July 2020 at 19:18
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: 6man w.g. last call for <draft-ietf-6man-grand> 

    Hello,

    as a Proposed Standard.

    Thanks,
    Bob & Ole

---

From: Fernando Gont <[email-masked]>
Date: Sat, 18 Jul 2020 05:38:12 -0300

Folks,

>         https://tools.ietf.org/html/draft-ietf-6man-grand

I will review this document shortly (I think I reviewed some version of 
it already).

That said, I'm curious about the possible implications of the following 
IPR, in particular "Reasonable and Non-Discriminatory License to All 
Implementers with Possible Royalty/Fee"..

Could this potentially mean that eventually some implementations might 
need to pay a Royalty/Fee to be fully compliant with the Neighbor 
Discovery spec?

I don't remember this kind of thing being discussed in 6man before, but 
other wgs I have participated in did consider this tihngs.

Thoughts?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 18 Jul 2020 13:31:33 +0000

Hi Fernando,

<without any hat>

Interesting remark as the IPR from Ericsson (Joel Halpern) on Jen's individual I-D has not (yet?) been transferred to the WG document per:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-6man-grand

But, knowing Ericsson (one big open-standard supporter), and even if I am not a lawyer (!), I would not mind too much. It is probably the usual IPR statement used at IETF by open-standard companies: basically, something such as "feel free to use my IPR as long as I may use yours".

Having said this, you have an acute view __ 

-éric

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of Fernando Gont <[email-masked]>
Date: Saturday, 18 July 2020 at 10:40
To: Bob Hinden <[email-masked]>, IPv6 List <[email-masked]>
Subject: Re: 6man w.g. last call for <draft-ietf-6man-grand>

    Folks,

    Thoughts?

    Thanks,

---

From: Mark Smith <[email-masked]>
Date: Sun, 19 Jul 2020 08:46:23 +1000

Hi,

I don't really understand how there is IPR that applies, GRAND is the same
idea as IPv4 Gratuitous ARP, just sent to the set of routers on link rather
than all nodes i.e. the idea of multicast.

I don't know if this sort of problem had shown up in IPv4, however the
GRAND method could be implemented for IPv4 using GARP and the IPv4 all
routers 224.0.0.2 multicast address.

Regards,
Mark.

On Sat, 18 Jul 2020, 23:32 Eric Vyncke (evyncke), <evyncke=
[email-masked]> wrote:

> Hi Fernando,
>
> <without any hat>
>
> Interesting remark as the IPR from Ericsson (Joel Halpern) on Jen's
> individual I-D has not (yet?) been transferred to the WG document per:
>
> But, knowing Ericsson (one big open-standard supporter), and even if I am
> not a lawyer (!), I would not mind too much. It is probably the usual IPR
> statement used at IETF by open-standard companies: basically, something
> such as "feel free to use my IPR as long as I may use yours".
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 19 Jul 2020 10:22:01 +0100

Hi,

“Obviously” implementers must make their own decisions on IPR applicability and IPR licenses.

Speaking personally, I find it sad that a company that Eric classifies as “one big open standard supporter” chooses to use the license terms that it does, but I am not seeking to influence their corporate IPR policy. Under my personal interpretation of the license terms (I am not a lawyer specialising in IPR), the “feel free to use my IPR as long as I may use yours" condition that Eric mentions will only apply to companies that have a portfolio of their own IPR that can be conceptually traded. An implementer without such a portfolio of IPR or that has open-sourced it’s IPR does not have such a defence and would, under this license, expect to have to come to terms.

That means that the assessment of whether the IPR is applicable or relevant might be more important for some people.

In this case, I do not object to this document being published in the knowledge of this IPR disclosure with its licensing terms.

Best,

Adrian

From: ipv6 <[email-masked]> On Behalf Of Mark Smith
Sent: 18 July 2020 23:46
To: Eric Vyncke (evyncke) <evyncke=[email-masked]>
Cc: Fernando Gont <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: 6man w.g. last call for <draft-ietf-6man-grand>

Hi,

I don't really understand how there is IPR that applies, GRAND is the same idea as IPv4 Gratuitous ARP, just sent to the set of routers on link rather than all nodes i.e. the idea of multicast.

I don't know if this sort of problem had shown up in IPv4, however the GRAND method could be implemented for IPv4 using GARP and the IPv4 all routers 224.0.0.2 multicast address.

Regards,

Mark.

On Sat, 18 Jul 2020, 23:32 Eric Vyncke (evyncke), <evyncke=[email-masked] <mailto:[email-masked]> > wrote:

Hi Fernando,

<without any hat>

Interesting remark as the IPR from Ericsson (Joel Halpern) on Jen's individual I-D has not (yet?) been transferred to the WG document per:
https://datatracker.ietf.org/ipr/search/?submit=draft <https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-6man-grand> &id=draft-ietf-6man-grand

-éric

-----Original Message-----
From: ipv6 <[email-masked] <mailto:[email-masked]> > on behalf of Fernando Gont <[email-masked] <mailto:[email-masked]> >
Date: Saturday, 18 July 2020 at 10:40
To: Bob Hinden <[email-masked] <mailto:[email-masked]> >, IPv6 List <[email-masked] <mailto:[email-masked]> >
Subject: Re: 6man w.g. last call for <draft-ietf-6man-grand>

    Folks,

    Thoughts?

    Thanks,
    -- 
    Fernando Gont
    SI6 Networks
    e-mail: [email-masked] <mailto:[email-masked]> 
    PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [email-masked] <mailto:[email-masked]> 
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked] <mailto:[email-masked]> 
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Mon, 20 Jul 2020 08:47:40 +1000

Hi Jen,

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

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 19 Jul 2020 20:16:11 -0400

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 <[email-masked]> wrote:

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

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 19 Jul 2020 20:57:44 -0400

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 <[email-masked]> wrote:

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

*Gyan Mishra*

---

From: Jen Linkova <[email-masked]>
Date: Mon, 20 Jul 2020 18:35:16 +1000

Hi Eric,

Thanks for your review and comments!
In my response below when I say 'done' I mean 'will be fixed in -03
which I'll submit as soon as datatracker gets unlocked'.

> Section 1: missing the final '.' at the end of paragraph 2

Fixed.

> Strongly suggest not to use LLA for link-layer address... as it is confusing with Link-Local Address... What about L2A ? Also some typos such as " link-layaer"

The Terminology section does define 'LLA' as 'Link-Layer Address'. My
main reason to use it was that it's consistent with such
well-established acronyms as 'SLLA' and 'TLLA'. At the same time I
agree that LLA could be easily confused with 'link-local address'. So
I've replaced 'LLA' with 'Link-Layer Address' everywhere but kept SLLA
and TLLA.

> Section 2.1, 1st para: why limiting the last sentence to global IPv6 addresses? Need to check but I guess link-local address may also change (albeit rarely)

The reason the draft does not include link-local addresses is that I'm
not sure it would solve any real problem.
The issue the draft is trying to address has two distinct properties:
1) it affects the transit (not originated by the router) traffic;
2) It disappears as soon as the discovery process finishes.
Therefore scenarios when traffic to link-local destinations is
affected seem to be mostly theoretical. The only real case is one Mark
has mentioned: two hosts communicating using its link-local addresses
via the router. However it still look rather imaginary:
- host A appears on the network (or configures a new link-local
address) either using Optimistic DAD or not including SLLA into RS for
some reason;
- *before* the host A starts NUD for its default gateway address* host
B sends multiple packets (or multiple hosts are sending packets) to
the host A new link-local address (how would the host B know that
address?

I have no problem expanding the scope for all addresses, just not sure
how useful it would be.
How about
1) saying that the host MAY follow the same procedure for informing
the routers about new link-local address?
2) adding a section to discuss why the proposed mechanism has more
sense for GUA than for link-local addresses?

I'd like to hear the host implementers - I'm not sure if they'd prefer
to send those packets for GUA only or it would be simpler to avoid
additional logic and send NAs for any address.

-
>Need to check but I guess link-local address may also change (albeit rarely)

It may indeed. The question is: can we expect a router to receive
flows for that address *before* the router receives either RS with
SLAA or an NS from that address?

> Section 2.1 mixes normative text and explanations. Suggest to create a subsection for explanations/justifications

OK, I've removed the normative language from that section so now it
discusses the proposed changes while Section 4 contains the exact text
using the normative language.

> Section 2.2 the normative does not specify what to do when an ND entry already exist. A pointer to section 3 is really welcome here (even if it immediately follows)

The following sentence has been added to Section 2.2:

The proposed changes do not modify routers behaviour specified in
RFC4861 for the scenario when the corresponding Neighbor Cache entry
already exists.

> Section 3.2, if there is no entry, then how can it be 'updated' ?

Fixed.

> Section 4.1.2 sentence " These advertisements MUST be separated by at least RetransTimer seconds." is repeated unnecessary IMHO

Existing 'These advertisements MUST be separated by a least
RetransTimer seconds.' statement in the section-7.2.6 seems to be
related to sending unsolicited NAs to announce the link-layer address
change. However after re-reading the section 7.2.6 I've realized that
the proposed change is suboptimal: I was trying to insert the new text
between two paragraphs describing sending unsolicited NAs for
link-layer address change. It would make the following paragraph
(beginning with 'The Target Address field in the unsolicited
advertisement' a bit confusing. It looks like the better place for the
new text is below, right after

 'Also, a node belonging to an anycast address MAY multicast
unsolicited Neighbor Advertisements for the anycast address when the
   node's link-layer address changes.'

> Please run a spell checker: " nessesary", and possibly other typos

Sure, will be done for -03.

---

From: Jen Linkova <[email-masked]>
Date: Mon, 20 Jul 2020 19:18:31 +1000

> all addresses than being selective.

I do not have any problem with that change - it does not hurt but I do
not think it would solve any additional issues (see my response to
Eric - I'm struggling imagining a scenario when the problem described
in draft-ietf-v6ops-nd-cache-init could be applicable to link-local
addresses)...

> addresses, useful for troubleshooting.

It's the case already, GRAND is not required for that.
The routers already have all link-local addresses of hosts on the LAN
in their caches. For hosts not using Optimistic DAD it normally
happens after receiving RS from the host. For hosts using Optimistic
DAD it would happen either before the router responds with RA or after
the first round of NUD.

I've been using it as a very effective indication of global
reachability issues on LAN: if the first-hop routers NC contains
link-local addresses but no global entries - it's very likely that we
are having issues with the return path.

> routers) to all IPv6 nodes, not just hosts.

This is very easy to achieve, actually ;) All we need to do is to
s/host/node/ in the proposed update text (actually it's a good thing
to do because the rest of Section 7.2.6 is talking about a node, not a
host. So no explicit text required - however I think I'll add a
section to describe your examples and clarify why routers might need
to send GRAND NAs as well.

> unicasting of GRAND NAs for the time being.

You are suggesting to remove the last paragraph in the Section 2.1,
right? OK, I'll do it.

---

From: Jen Linkova <[email-masked]>
Date: Mon, 20 Jul 2020 21:26:55 +1000

> need to pay a Royalty/Fee to be fully compliant with the Neighbor

Believe me, I'm very confused as well. I'm not a lawyer but my very
limited understanding  is  (again, it's quite possible I misunderstood
everything so pls take it with a grain of salt):
- the IPR claim does not actually mean that the specification update
in the draft is really patented.  It means that the draft describes
something related or similar to the patented technology.
- implementers, or their lawyers..or some other lawyer...would need to
assess if whatever they are going to implement is covered by the
patent or not, and act accordingly.
- my attempt of deciphering  the patent in question makes me believe
that that common element is creating a NC entry upon receiving an
unsolicited NA - which was never prohibited by RFC4861 in the first
place (it is saying 'SHOULD NOT'). However the patent seems to define
a machinery which is far more complicated than what the draft
describes.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 20 Jul 2020 12:45:48 -0300

> patent or not, and act accordingly.

My take (but, hey, other people on the list certainly know better and 
can probably clarify) is that it's an actual claim that the stated IPR 
covers the document.

> a machinery which is far more complicated than what the draft

I didn't read the patent itself, to be honest. If it's not applicable 
(i.e., related in some way, but not really covered), it would be great 
for Ericsson to clarify (although I believe the claim is that the IPR 
covers the document).

My concern is that having core standards encumbered by IPRs is 
particularly problematic for open source projects.

As such, I'd prefer that, as a general rule, documents updating core 
standards are not ipr-encumbered.

---

From: Bob Hinden <[email-masked]>
Date: Mon, 20 Jul 2020 09:57:26 -0700

Hi,

> On Jul 18, 2020, at 1:38 AM, Fernando Gont <[email-masked]> wrote:
> 
> Folks,
> 
> I will review this document shortly (I think I reviewed some version of it already).
> 
> That said, I'm curious about the possible implications of the following IPR, in particular "Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee"..
> 
> Could this potentially mean that eventually some implementations might need to pay a Royalty/Fee to be fully compliant with the Neighbor Discovery spec?
> 
> I don't remember this kind of thing being discussed in 6man before, but other wgs I have participated in did consider this tihngs.

The IETF requires IPR disclosures to be filed if someone knows of a possible IPR claim that might apply to an IETF document.    An IETF working group can take this into account when making a decision to advance a document.   Documents can be advanced with IPR claims.  The IETF does not develop opinions on the merits or relevance of IPR claims.   That is usually falls to commercial vendors when deciding to include a technology in their products.

There are other 6man documents that have been advanced with IPR claims.

Bob

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Jul 2020 09:01:09 +1000

Hi Jen,

> in draft-ietf-v6ops-nd-cache-init could be applicable to link-local

There are other issues that this method provides benefits to or
solves, more than just the specific problem you're thinking about:

- helping mitigate ND cache exhaustion DoS attack by preloading the
cache with addresses

- Addresses in use on a link, for which it seems many people believe
stateful DHCPv6 solves, but doesn't because DHCPv6 doesn't record
SLAAC and link local addresses.

> in their caches.

I don't understand how.

Hosts aren't limited to a single link-local address on an interface,
and could generate a new one at any time. So if a host generates a new
LLA, it would do GRAND for it so that the routers are informed of the
new LLA.

I think the reason hosts, or at least end-user hosts, should change
LLAs periodically is because with EUI based LLAs, or RFC7217 LLAs,
where the network identifier isn't changed because it is optional in
the algorithm, the IID will be a static and globally unique 64 bit
IID, allowing tracking across co-ordinated networks. In the case of
RFC7217, this occurs because the LLA prefix is always fe80::/64.

Considering how many hosts are IPv6 enabled by default, and have LLAs
because they're mandatory, EUI or RFC7217 LLA 64 bit IIDs could be the
new way to track end-users, replacing MAC addresses that have now been
randomised.

> For hosts not using Optimistic DAD it normally
> host.

Agree, simple text change. More that changing from just hosts to all
nodes may (or may not) have been a significant change worth
considering more.

> So no explicit text required - however I think I'll add a

I think remove both the last 2 paragraphs of section 2.1, as they're
both about unicasting the GRAND ND NAs i.e., anything that talks about
unicasting these GRAND announcements, either at layer 2 or layer 3.

This sentence in the Security Considerations section should go too:

"Should the issue needs to be mitigated on
   the host level, the host can send unsolicited NAs to its routers
   Ethernet unicast addresses as described in Section 2.1."

Thanks very much,
Mark.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 23 Jul 2020 11:15:40 +1000

> - helping mitigate ND cache exhaustion DoS attack by preloading the

I'm not sure I fully understand how it would help...Could you please elaborate?
The attack is trying to create a lot of INCOMPLETE entries by sending
packets to non-existing addresses.
Unless we require that routers rely on GRAND only and never even try
to create a new entry upon receiving a packet to an address never seen
before, the router behaviour would still be the same.

> > The routers already have all link-local addresses of hosts on the LAN

OK, I should have said 'all link-local addresses which hosts have used'.
An address which has not been used (send/receive packets) might not be
in the cache.

> LLA, it would do GRAND for it so that the routers are informed of the

Well, as soon as the host starts using that LLA it would be sending ND
packets from it which would populate the cache entry anyway.
But I agree, GRAND would make it faster.

> > > unicasting of GRAND NAs for the time being.

OK, will do in the next version.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 23 Jul 2020 11:43:53 +1000

> before, the router behaviour would still be the same.

I stand corrected. Yeah, it might help as it makes it more likely that
an address which does not exist in the cache does not exist on the
network either.
So resolving such addresses could be deprioritized even more.
Funny enough the draft does say it already ;))

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 23 Jul 2020 07:47:24 +0000

> Le 23 juil. 2020 à 03:44, Jen Linkova <[email-masked]> a écrit :
> 

I hope it is clear by now that grand does not change the nature of the NCE, that is a cache. We cannot trust the ND cache to defeat a DoS attack. You can only do that when a hard state is proactively maintained for each address.

This means deploying an RFC 8505-only network. This is still allows both centralized (DHCP) and autoconf (SLAAC), address allocation is orthogonal to neighbor state management.

Keep safe,

Pascal

---

From: Mark Smith <[email-masked]>
Date: Fri, 24 Jul 2020 06:07:12 +1000

Hi Jen,

> before, the router behaviour would still be the same.

That's why I said "mitigate" not "solve" ;-)

> packets from it which would populate the cache entry anyway.

It wouldn't be in the router's ND cache though unless the LLA was used to
communicate with the router or through the router per the ability to
forward LLA addressed packets.

> But I agree, GRAND would make it faster.

This would be where GRAND ensures a new LLA is in the router's cache. Some
of the time it's only reason to be there is for the IPv6 addresses in use
on the link purpose.

> OK, will do in the next version.
Great, thanks very much.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Fri, 24 Jul 2020 06:54:41 +1000

Hi Pascal,

> I hope it is clear by now that grand does not change the nature of the NCE, that is a cache. We cannot trust the ND cache to defeat a DoS attack. You can only do that when a hard state is proactive…

I agree, the way to prevent an ND cache resource exhaustion attack
from off-link nodes is to eliminate off-line nodes' ability to create
cache entries.

The fundamental problem with the ND cache (as well as IPv4's ARP
cache, just not to the same extent), is that data/forwarding plane
traffic from hosts that might not be trustworthy is being used to
create control plane state that is trusted.

> This means deploying an RFC 8505-only network. This is still allows both centralized (DHCP) and autoconf (SLAAC), address allocation is orthogonal to neighbor state management.

It seems to me that the harder issue is how to transition to an
address registration protocol like RFC 8505 incrementally, now that we
have billions of ND cache nodes and millions of ND cache routers
deployed. I think both routers and hosts would have to support both
methods concurrently.

Something like GRAND is not a solution to the ND cache DoS attack,
however it does improve the situation, and is a much smaller
incremental change compared to a transition to an address registration
protocol which still would have to co-exist with the ND cache
protocol.

Regards,
Mark.