Subject: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02

From: Tim Chown <[email-masked]>
Date: Wed, 29 Mar 2017 18:39:06 +0000

Hi,

Email as promised following up mic comments.

Overall, a very nicely written document. The intro sections are particularly good to read.

I suggest adding sections in the draft on:
a) MLDv2 - personally I’d like to see a MUST for MLDv2 support
b) RFC8106 support - make RDNSS option support in RAs a MUST

And also review the wording on SLAAC in Section 3.3.
a) Change SLAAC being enabled by default from a SHOULD to a MUST
b) Probably good to distinguish SLAAC for LLs and SLAAC for globals; RFC6434 says routers MUST be able to generate LL addresses; the draft currently only says SHOULD; I’d make that a MUST.
c) RFC4862 says DAD is a MUST, in the draft it’s currently only a SHOULD; is there a reason for it not to be a MUST?

The only significant “clash” with RFC6434-bis (which is in 6net tomorrow) is the section 3 text; the rest syncs pretty well as it is, which is good news.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Mar 2017 07:52:04 +1300

I agree with Tim on all points.

   Brian

On 30/03/2017 07:39, Tim Chown wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Russ White" <[email-masked]>
Date: Thu, 30 Mar 2017 10:11:24 -0500

> Overall, a very nicely written document. The intro sections are particularly

Thanks!

> b) RFC8106 support - make RDNSS option support in RAs a MUST

I will take a look at these -- I think they would be good to add, just have to scare up some text around them.

> a) Change SLAAC being enabled by default from a SHOULD to a MUST

This is mostly a result of my not knowing what to do here, so I went with the "gentler" requirement. I'm happier with MUST here if the community agrees.

> b) Probably good to distinguish SLAAC for LLs and SLAAC for globals; RFC6434
> says routers MUST be able to generate LL addresses; the draft currently only
> says SHOULD; I’d make that a MUST.

Okay.

> there a reason for it not to be a MUST?

Nope -- again, I'm just sometimes overcautious. I can change this to a MUST.

> The only significant “clash” with RFC6434-bis (which is in 6net tomorrow) is
> the section 3 text; the rest syncs pretty well as it is, which is good news.

I'll take a look at this to see where we might clash, and try to get those bits worked out.

😊 /r