Subject: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft

From: Fred Baker <[email-masked]>
Date: Tue, 23 Jul 2019 04:29:15 -0400

In yesterday's meeting, the sense of the room and a discussion of charters at the mike suggested that draft-linkova-v6ops-nd-cache-init should become a working group draft. Doing so will require 6man to agree to let v6ops suggest specific changes to RFC 4861 under the rubric of "operational solutions", as discussed in the draft and https://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-neighbor-cache-entries-on-first-hop-routers-operational-considerations-00; the argument for not kicking those out to 6man is that the authors of RFC 4861 are no longer in a position to approve errata to it, which would be the other obvious approach (I'm not sure that's true of Erik Nordmark, but whatever). It would also need to be considered to update RFC 4861.

Do we agree to take draft-linkova-v6ops-nd-cache-init as a working group draft?

Ron and I look through this thread next week and take the necessary action, whatever the outcome might be.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Jul 2019 10:02:55 +0100

Fred,

On 23/7/19 09:29, Fred Baker wrote:
> In yesterday's meeting, the sense of the room and a discussion of
> charters at the mike suggested that draft-linkova-v6ops-nd-cache-init
> should become a working group draft. Doing so will require 6man to
> agree to let v6ops suggest specific changes to RFC 4861 under the
> rubric of "operational solutions", as discussed in the draft and
> https://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-neighbor-cache-entries-on-first-hop-routers-operational-considerations-00;
> the argument for not kicking those out to 6man is that the authors of
> RFC 4861 are no longer in a position to approve errata to it, which
> would be the other obvious approach (I'm not sure that's true of Erik
> Nordmark, but whatever). It would also need to be considered to
> update RFC 4861.

My understanding is that, if anything, it is the relevant working groups
that maintain and accept/reject errata, rather than their authors alone.
(In fact, at the point the corresponding RFCs (at internet-draft stage)
became wg items, they became adopted by the relevant wgs). That's why
draft-ietf documents reflect the opinion of the relevant wg, rather than
that of the authors.

If a protocol needs to be updated, so be it. But that, I understand, is
what 6man is for. I can see myself reasons for wanting to do it in
v6ops. But unless I'm missing something, that's the charter of 6man,
rather than of v6ops.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Jul 2019 07:07:52 -0400

> draft-ietf documents reflect the opinion of the relevant wg, rather than

The assertion from Warren was that an erratum would not be approved because
such an erratum would be clearly changing the intent of the original
document, making it say the opposite of what it used to say.

> v6ops. But unless I'm missing something, that's the charter of 6man,

And it is in the charter of v6ops to suggest those modifications:

======
1. Solicit input from network operators and users to identify
operational issues with IPv6 networks, and determine solutions or
workarounds to those issues.
...
IPv6 operational and deployment issues with specific protocols [...]
are the primary responsibility of
the groups or areas responsible for those protocols [...]
However, the v6ops Working Group may provide input to
those areas/groups, as needed, and cooperate with those areas/groups in
reviewing solutions to IPv6 operational and deployment problems.
======

This is an operational issue in IPv6-only networks, and this draft is about
determining a solution and providing 6man with input on how to resolve it
in the protocol.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jul 2019 23:39:05 +1200

1) Yes, we should *obviously* do this.
2) If the charter prevents that, fix the charter.
3) I'm not convinced it needs to update 4861. If what it does is explain the conditions in which an RFC2119 "SHOULD" should be ignored, that is *not* an update to the standard. To me it sounds exactly like a Best Current Practice.
4) In any case, if the IETF rules are alleged to prevent doing the obvious right thing, the IESG can vary the rules, as allowed by BCP9.

Regards
   Brian Carpenter

On 23-Jul-19 20:29, Fred Baker wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
> .
>

---

From: Timothy Winters <[email-masked]>
Date: Tue, 23 Jul 2019 08:02:30 -0400

I also think this should be working group draft, as I mentioned at the mic
I'm happy to help survey what current implementations are capable of.

I also agree with Lozenzo last statement.

~Tim

On Tue, Jul 23, 2019 at 7:39 AM Brian E Carpenter <
[email-masked]> wrote:

> 3) I'm not convinced it needs to update 4861. If what it does is explain
> the conditions in which an RFC2119 "SHOULD" should be ignored, that is
> *not* an update to the standard. To me it sounds exactly like a Best
> Current Practice.
> 4) In any case, if the IETF rules are alleged to prevent doing the obvious
> right thing, the IESG can vary the rules, as allowed by BCP9.
>
> Regards
>    Brian Carpenter
>
> should become a working group draft. Doing so will require 6man to agree to
> let v6ops suggest specific changes to RFC 4861 under the rubric of
> "operational solutions", as discussed in the draft and
> the argument for not kicking those out to 6man is that the authors of RFC
> 4861 are no longer in a position to approve errata to it, which would be
> the other obvious approach (I'm not sure that's true of Erik Nordmark, but
> whatever). It would also need to be considered to update RFC 4861.
> >

---

From: David Lamparter <[email-masked]>
Date: Tue, 23 Jul 2019 15:03:23 +0200

+1

-David

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Jul 2019 09:13:09 -0400

> Do we agree to take draft-linkova-v6ops-nd-cache-init as a working group

I support adopting this draft as a WG document.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Jul 2019 13:16:29 +0000

I support the idea to adopt the draft and document the general problem that’s behind it.
The attack vectors on the router are part of that general problem.

As I understand Lorenzo ‘s point, the full solution probably belongs to 6man. We are now finding that we need to reconsider the reactive behavior of ND AR. Tricking the current model can improve things but only so far. 

Regards,

Pascal

> Le 23 juil. 2019 à 09:05, David Lamparter <[email-masked]> a écrit :
> 
> +1
> 
> -David
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Jul 2019 09:45:13 -0400

On Tue, Jul 23, 2019 at 9:16 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> As I understand Lorenzo ‘s point, the full solution probably belongs to
> 6man.

For the record, actually no, that is not my position. Protocol changes do
belong in 6man. But as Brian says, we may not need protocol changes. A BCP
seems like a fine place to say "here's a good reason not to implement this
SHOULD in a router".

> We are now finding that we need to reconsider the reactive behavior of ND
> AR. Tricking the current model can improve things but only so far.
>

For the record, I don't agree with this. Changing the reactive behaviour
has far-reaching implications and a number of difficult trade-offs with
regard to scalability, crash recovery, availability of addresses to network
nodes, and so on.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 23 Jul 2019 09:59:37 -0400

+1

Regards,

Jordi

@jordipalet

El 23/7/19 9:14, "v6ops en nombre de Lorenzo Colitti" <[email-masked] en nombre de lorenzo=[email-masked]> escribió:

_______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops 

**********************************************
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: Igor Gashinsky <[email-masked]>
Date: Tue, 23 Jul 2019 10:38:33 -0400

+1 as well. 

-igor

> On Jul 23, 2019, at 09:59, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 
> +1
>  
> Regards,
> Jordi
> 
> @jordipalet
> 
>  
> 
>  
>

---

From: Jen Linkova <[email-masked]>
Date: Wed, 24 Jul 2019 00:50:27 +1000

> 3) I'm not convinced it needs to update 4861. If what it does is explain the conditions in which an RFC2119 "SHOULD" should be ignored, that is *not* an update to the standard. To me it sounds exac…

That's was my impression  as well, glad to see I'm not alone ;)

"SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label."

So I guess as long as we document the case and implications,
recommending routers to have a configuration knob to ignore "SHOULD"
is not violating RFC4861.
Probably getting the document reviewed by 6man WG would make sense as
well to ensure that implications are understood.

-- 
SY, Jen Linkova aka Furry

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Jul 2019 18:36:09 +0100

On 23/7/19 12:07, Lorenzo Colitti wrote:
> On Tue, Jul 23, 2019 at 5:07 AM Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> The assertion from Warren was that an erratum would not be approved
> because such an erratum would be clearly changing the intent of the
> original document, making it say the opposite of what it used to say.

So... is this kind of a polite way of saying that we have to ignore the
charter because 6man would not agree to work on a document that is meant
to address what is deemed as a real world problem?

If so, rather than circumvent the charters, whichever wg is relevant
(6man in this case), should do what must be done.

FWIW, I had a similar feeling with addressing the slaac-renum problem,
which does have an operational workaround (deployment advice and
tweaking protocol knobs), but that would also benefit from protocol
updates (not necessarily all the ones we proposed).

> This is an operational issue in IPv6-only networks, and this draft is
> about determining a solution and providing 6man with input on how to
> resolve it in the protocol.

While skimming the doc, it would seem to me that the document aims at
updating the protocol spec (even when it's "Informational"), rather than
providing input to 6man.

If the problem is seen as a real problem (I'm not taking a position in
that respect), this document should be std track, update the ND spec,
and be done in 6man. (And yes, 6man should address protocol problems,
rather than being guardians that prevent folks from solving them).

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Jul 2019 14:00:02 -0400

> to address what is deemed as a real world problem?

No. It was a way to say that an erratum is not the way to address this
issue.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Jul 2019 18:59:23 +0100

> 2) If the charter prevents that, fix the charter.

I'm all for fixing problems and getting stuff done. And, if there's no
other way than fixing the charter, so be it.

However, it would seem to me that, the "bug" here is that we're
defaulting to "6man wouldn't get this done, so let's do it elsewhere".

IMO, should be willing to maintain its protocols, improve them, and fix
problems where necessary.

If a BCP is to go against the protocol spec recommendation for the
general case, that's an indication that the protocol should be updated.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Jul 2019 19:01:26 +0100

> original document, making it say the opposite of what it used to say.

Indeed, it shouldn't be an erratum, but an ID/RFC that formally updates
the spec. Nobody should be scared of that. In fact, I guess that's why
there is something called "6man".

---

From: Ole Troan <[email-masked]>
Date: Tue, 23 Jul 2019 15:08:23 -0400

> well to ensure that implications are understood.

We have decades of experience with gratuitous ARP in IPv4. Updating IPv6 ND to also support (and make it recommended practice) gratuious ND seems sensible.

I believe this requires an update to RFC4861. And I don't see any reason why that work shouldn't happen in 6man.

Best regards,
Ole (6man co-chair).

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Jul 2019 15:12:53 -0400

> why that work shouldn't happen in 6man.

Yup. I'd recommend we first adopt this draft to actually consider the
operational issues and we come to consensus on what the best approach is.
Once we have a conclusion, the standards change can go to 6man. Clearly
6man should review the operational document before it gets published.

---

From: David Lamparter <[email-masked]>
Date: Tue, 23 Jul 2019 21:19:25 +0200

> defaulting to "6man wouldn't get this done, so let's do it elsewhere".

The discussion I see here is that we've located an operational issue
with the IPv6 neighbor cache on routers, we have several candidates for
fixing it, and each of these may or may not need a protocol change to go
through 6man.

Discussing whether any particular working group "gets things done" seems
tangential to the question at hand.

> general case, that's an indication that the protocol should be updated.

Although I don't write the neighbour management code, I do write code
that operates routers and I have absolutely no concerns in understanding
that a particular "SHOULD" statement has turned out to be a bad choice
for the specific situation of first-hop routers.

Whether this is a specification change, to me, is decided by the intent.
The intent under consideration here is:

   When a valid Neighbor Advertisement is received (either solicited or
   unsolicited), the Neighbor Cache is searched for the target's entry.
   If no entry exists, the advertisement SHOULD be silently discarded.
   There is no need to create an entry if none exists, since the
   recipient has apparently not initiated any communication with the
   target.

The intent I see is that in most cases there's no point in having
devices consume memory, and the "SHOULD" is correct behaviour for hosts.
Routers *DO* "need to create an entry if none exists".  I don't see a
conflict with 4861's intent, which I take as "don't open yourself to DoS
attacks".  The router /will have the neighbor cache entry anyway/, just
with a delay, later, and the resulting annoyance.

4861 just failed to invoke the magic 8-ball correctly to make the
authors omniscient and recognize the specific circumstances under which
this SHOULD is maybe not the best idea.  This is implementation guidance
based on operational experience.  Just write it down and get it out
there.

-David

---

From: Fred Baker <[email-masked]>
Date: Tue, 23 Jul 2019 13:35:43 -0400

That might be an interesting survey, if only to validate the draft. It would also give a heads-up to those developers, though, and give the working group some operational experience in the case(s) of those that already implement something like it.

Sent from my iPad

> On Jul 23, 2019, at 8:02 AM, Timothy Winters <[email-masked]> wrote:
> 
> 
> I also think this should be working group draft, as I mentioned at the mic I'm happy to help survey what current implementations are capable of.
> 
>> On Tue, Jul 23, 2019 at 7:39 AM Brian E Carpenter <[email-masked]> wrote:

---

From: Jen Linkova <[email-masked]>
Date: Wed, 24 Jul 2019 05:51:48 +1000

> defaulting to "6man wouldn't get this done, so let's do it elsewhere".

I'm confused. I'm not sure I understand how you came to the conclusion
that we are trying fix the protocol in v6ops because 6man wouldn't do
this.

First of all, main goal of the draft in question is to describe an
operational problem and discuss potential ways to deal with it.
Based on the analysis the draft currently suggests that there  are
"valid reasons in particular circumstances when the particular
behavior (violate SHOULD NOT and create a STALE entry upon receiving
an unsolicited NA) is acceptable or even useful". It does not change
ND as a protocol because RFC4861 does allow such behaviour (otherwise
it would have said 'MUST NOT') so I'm inclined to say that it's not a
protocol change.
However I see why it might be seen as a protocol change and I'm
willing to either:
- write an additional 1-page draft for 6man updating 4861 based on
analysis provided in this draft;
- get this draft adopted and/or reviewed by 6man
- whatever other ways to make sure all appropriate  reviews are done, " full
   implications should be understood and the case carefully weighed" etc ;)

> general case, that's an indication that the protocol should be updated.

BCP does not go against the specification for the general case. It
seems to me that the protocol discusses a general case and provides
rationale for 'SHOULD NOT'.
Then we have discovered one corner case which is not even in scope for
the rationale provided in the standard. For me it's a typical example
of 'valid reasons in particular circumstances when the
   particular behavior is acceptable'. If we were recommending that
any arbitrary host SHOULD create an entry upon receiving an
unsolicited NA - then yes, it's a clear indication that RFC4861 needs
to be updated.

Anyway, as I've said, I have no problem go to 6man with it - but I
guess we need to look at all proposed solutions, decide which way we
want to go and, if RFC4861 needs to be updated - well, I guess it
SHOULD be easy ;)

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 23 Jul 2019 20:21:46 +0000

+1
I think that starting out by describing the problem and identifying potential solutions is absolutely the place to start, and I agree that this is a problem worth solving.
Barbara

On Tue, Jul 23, 2019 at 4:29 AM Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:
Do we agree to take draft-linkova-v6ops-nd-cache-init as a working group draft?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Jul 2019 20:45:38 +0000

Hello Lorenzo

For the record, actually no, that is not my position. Protocol changes do belong in 6man. But as Brian says, we may not need protocol changes. A BCP seems like a fine place to say "here's a good reason not to implement this SHOULD in a router".

<Pascal>

  *   Sorry for placing words in your mouth, that was my understanding of your last sentence. I hope v6ops finds tricks with the current methods that help the situation. Jen’s draft is useful and uncovers one of more than a half dozen of issues that are related to the reactive nature of ND.
  *   And I read that the proposed approach to solve that is to populate the ND cache in advance. Which is what in my book is called proactive, regardless of the method used to get there. The question is whether we do it well or just scratch the surface.
  *   I’d like the draft to include other problems that relate to the same cause. This includes:

  *   PUNTing packets to software for resolution, an archaic operation. Kills the benefits of 802.11ai. Makes IPv6 looks even worse than IPv4 because of more addresses.
  *   Scanning attacks to DoS the router, trying to either fill the ND cache, saturate the CPU, or deny access to legitimate hosts when the router protects itself.
  *   Broadcast inefficiencies, in particular in wireless and distributed L2 domains
  *   Silent host
  *   Need for a global broadcast domain and always on devices (for DAD and AR) = A bad match with pretty much all modern networks including overlays, IOT, vehicular or wireless
  *   ND abuse / SeND too complex

We are now finding that we need to reconsider the reactive behavior of ND AR. Tricking the current model can improve things but only so far.

For the record, I don't agree with this. Changing the reactive behaviour has far-reaching implications and a number of difficult trade-offs with regard to scalability, crash recovery, availability of addresses to network nodes, and so on.

<Pascal>

Ø    Ain’t that FUD? We all have been using Wi-Fi ESS for a long time and the pro-active model has been delivering quite satisfactorily AFAIK. It is actually a lot more scalable than transparent bridging, which is the analogous to AR relie at the MAC-level. It was designed to protect the wireless medium. The EARO model is a plain adaptation of the model at Layer-3. It was doable at L2 for a while, it is probably doable at L3 today. Actually we’ve done it. We have deployed MLSNs on thousands of nodes operating that way.

Cheers,

Pascal

---

From: David Lamparter <[email-masked]>
Date: Tue, 23 Jul 2019 22:55:49 +0200

On Tue, Jul 23, 2019 at 03:08:23PM -0400, Ole Troan wrote:
> We have decades of experience with gratuitous ARP in IPv4. Updating
> IPv6 ND to also support (and make it recommended practice) gratuious
> ND seems sensible.

I think we're jumping the gun here, let's enumerate solutions first.

> I believe this requires an update to RFC4861. And I don't see any
> reason why that work shouldn't happen in 6man.

Ack.  However, "gratuitous ND" is only one possible fix here, and a
costly one at that since it needs updates on both the host to send this
new "gratuitous ND" as well as the router to understand and process it.

This discussion about the meta of "SHOULD" is based on the router-only
change in behaviour to listen to all DAD that hosts send already - and
one vendor seems to already be doing it.  What's your opinion on where
that would go?

-David

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Jul 2019 13:52:28 +1200

As has been extensively discussed on another thread, we sadly lack a method
of getting operational notes with *rough* consensus out quickly, because
our process for BCP, or worse for standards track, can take years instead
of weeks.

Y'all can prove me wrong by sending this draft to the IESG in a month
or so, and then worry about updating RFC4861 at normal IETF speed.

(After writing that, I am a bit embarassed that RFC6343 took six months.)

Regards
   Brian

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Jul 2019 11:05:38 +0000

Hello Brian

I’ve participated to multiple corridor discussions on that topic and seen agreement that NA(O) to ff02::2 that proactively sets the cache in the routers is better than the current state of affairs which is a NS from the router that is broadcasted to all hosts at L2. 

For one thing it is a lot easier for the proxy infra to cancel on wireless interfaces where there is no router than a NS for which the target is unknown.

Another thing that the draft should do imho is a more comprehensive review of the problems that are associated with reactive. Coming from the router side I’m probably more sensitive to that than others and I’d de happy to contribute.

All that can be done in a round or 2, there is no black magic. I wish to prove you right that it can be done in a matter of months.

Note that it will provide little difference to what we currently do with ND snooping, just will improve the chances to create the state in case the dad was lost. Our biggest problems with snooping are elsewhere and the need for the 6lo -type registration and the unicast lookup does not change a bit. 

All the best,

Pascal

> Le 23 juil. 2019 à 21:53, Brian E Carpenter <[email-masked]> a écrit :
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 24 Jul 2019 13:23:50 +0000

As an individual contributor, I support the adoption of this document as a WG document.

On 23/07/2019, 04:29, "v6ops on behalf of Fred Baker" <[email-masked] on behalf of [email-masked]> wrote:

---

From: David Lamparter <[email-masked]>
Date: Wed, 24 Jul 2019 16:44:29 +0200

On Wed, Jul 24, 2019 at 11:05:38AM +0000, Pascal Thubert (pthubert) wrote:
> I’ve participated to multiple corridor discussions on that topic and
> seen agreement that NA(O) to ff02::2 that proactively sets the cache
> in the routers is better than the current state of affairs which is a
> NS from the router that is broadcasted to all hosts at L2.

I would like to argue that our approach to this issue should be
"additive", and if we can easily run fixes from multiple angles it might
be worth doing so.

In particular:
- DAD gleaning is a router-only fix for this issue that requires no host
  changes
- sending any kind of unicast probe that triggers a response is a
  host-only fix for this issue that requires no router changes
- sending NA(O) to ff02::2 is a router and host change

The fact that any of these may not work in some particular setup (e.g.
wifi controller crapping on ND, shitty multicast snooping) is all the
more reason to do more than one.

>From a privacy perspective I'm fine with sending NA(O) to ff02::2 since
that is theoretically "only routers" in a network that were to limit
multicast propagation.  It's not ff02::1, which is all I ask.

I'm also happy if we document NA(O) to ff02::2 as the "long-term" fix
while doing DAD gleaning and/or unicast probes as "short-term" fixes.

Lastly, NA(O) to ff02::2 should go through 6man IMHO.  Whether either of
the other 2 options I listed above needs that I don't know.

Cheers,

-David

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Jul 2019 10:50:46 -0400

On Wed, Jul 24, 2019 at 7:06 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Another thing that the draft should do imho is a more comprehensive review
> of the problems that are associated with reactive. Coming from the router
> side I’m probably more sensitive to that than others and I’d de happy to
> contribute.
>

I don't think that belongs in this draft though. That's more of a design
question and 6man seems like the right place for it. This draft is
operationally focused on a specific problem and examines operational
solutions within the current standards. It can, and does, mention that
switching to a registration model might fix this problem, and I don't think
it should go deeper than that.

---

From: David Lamparter <[email-masked]>
Date: Wed, 24 Jul 2019 16:58:13 +0200

> it should go deeper than that.

Oh yes, we've completely run off far into solution space here.  I agree
that we should get this draft out to document the problem;  pointing out
possible solutions - nonexhaustively, without detail, and without
actually suggesting - is as far as I think we can take it.  Maybe stop
even shorter than that.

---

From: Ole Troan <[email-masked]>
Date: Wed, 24 Jul 2019 13:05:46 -0400

David,

> new "gratuitous ND" as well as the router to understand and process it.

As a matter of clarification.
By "gratuitous ND" I was referring to the solution where a host would send an NA, and the router would if having no NC entry for it, would create one, as opposed to ignore the ND.

Cheers,
Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Jul 2019 17:24:35 +0000

???

Sorry the response does not match the question. Do I need to reword?

There are a number of operational problems around the same root cause and that problem space needs to be covered in a bit more systemic way.
This way we can assess coverage of the various responses, tactical and strategic, impacting host routers or both, and I’m happy to talk solution later and wherever.

All the best,

Pascal

From: Lorenzo Colitti <[email-masked]>
Sent: mercredi 24 juillet 2019 07:51
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; IPv6 Operations <[email-masked]>; 6man Chairs <[email-masked]>; Fernando Gont <[email-masked]>
Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft

On Wed, Jul 24, 2019 at 7:06 AM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Another thing that the draft should do imho is a more comprehensive review of the problems that are associated with reactive. Coming from the router side I’m probably more sensitive to that than others and I’d de happy to contribute.

I don't think that belongs in this draft though. That's more of a design question and 6man seems like the right place for it. This draft is operationally focused on a specific problem and examines operational solutions within the current standards. It can, and does, mention that switching to a registration model might fix this problem, and I don't think it should go deeper than that.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Jul 2019 16:26:54 -0400

On Wed, Jul 24, 2019 at 1:25 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> There are a number of operational problems around the same root cause and
> that problem space needs to be covered in a bit more systemic way.
>
> This way we can assess coverage of the various responses, tactical and
> strategic, impacting host routers or both, and I’m happy to talk solution
> later and wherever.
>

I fear that if we have a discussion about this it will quickly turn into a
discussion of what is and isn't an "operational problem" as opposed to "a
good trade-off". It seems simpler to focus on this specific problem given
that we already have a draft for it.

---

From: Ole Troan <[email-masked]>
Date: Wed, 24 Jul 2019 17:48:36 -0400

> On 24 Jul 2019, at 16:26, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> On Wed, Jul 24, 2019 at 1:25 PM Pascal Thubert (pthubert) <[email-masked]> wrote:
> I fear that if we have a discussion about this it will quickly turn into a discussion of what is and isn't an "operational problem" as opposed to "a good trade-off". It seems simpler to focus on this specific problem given that we already have a draft for it.

Right.
I would be happy to see a separate discussion in 6man about what from the work in 6lo et al we could benefit from integrating into the IPv6 core protocol suite. It might have been in Pascal's draft's, but I think we as a group would benefit from a summary using our (6man) terms for things.

Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Jul 2019 13:00:07 +0100

> that we are trying fix the protocol in v6ops because 6man wouldn't do

This part of section 3,
   o  Hosts SHOULD send at least one unsolicited NA packet to all-
      routers multicast address (ff02::2) as soon as one of the
      following events happens:

      *  (if Optimistic DAD is used): a new Optimistic GUA is assigned
         to the host interface.

      *  (if Optimistic DAD is not used): a GUA changes the state from
         tentative to preferred.

seems to me a protocol update.

In any case, my comment was meant to say "if there's a problem to be
solved, don't be shy..there's nothing scary about updating the protocol
spec"

> operational problem and discuss potential ways to deal with it.

That's certainly perfectly fine and valuable, per-se.

> an unsolicited NA) is acceptable or even useful".

It would seem to me that when a spec says "SHOULD/SHOULD NOT", there's
leeway for implementations to don't follow that. However, if there is a
case where the default advice actually is the opposite, one should
update the original advice/requirement.

> It does not change
> protocol change..

If one were to pursue this way of solving the problem, wouldn't we want
the default advice to contradict (SHOULD vs SHOULD NOT) what's in RFC4861
>    implications should be understood and the case carefully weighed" etc ;)

I'd say describe the problem and evaluate possible solutions in 6man. If
v6ops sees that the change in RFC4861 is warranted, then the operational
advice from v6ops should make it happen in 6man.

> want to go and, if RFC4861 needs to be updated - well, I guess it

Indeed! ;-)

---

From: Jen Linkova <[email-masked]>
Date: Thu, 25 Jul 2019 21:39:43 +1000

> Another thing that the draft should do imho is a more comprehensive review of the problems that are associated with reactive. Coming from the router side I’m probably more sensitive to that than ot…

Thanks for offering your help, Pascal!
However I have some reservations about turning this particular
document into 'reactive behaviour of ND problem statement'. First of
all it does sound a bit biased towards a particular solution which
makes me think that such analysis should belong to 6man@.  I'm not
saying such document shouldn't exist, I'm just not sure such analysis
belongs to this draft.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 26 Jul 2019 11:38:00 +0200 (CEST)

> Do we agree to take draft-linkova-v6ops-nd-cache-init as a working group draft?

I support making this a working group draft, this is a problem we should 
solve.

I'd just like to check, have the authors checked the proposed solution 
list against https://datatracker.ietf.org/wg/savi/documents/ to make sure 
the solutions we're proposing are not in conflict with behavior SAVI 
prescribes?

-- 
Mikael Abrahamsson    email: [email-masked]