Subject: RFC4941bis implementations

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Apr 2020 14:26:58 -0300

Folks,

FWIW, I produce a patch for Linux kernel (net-next) that implements 
rfc4941bis: 
https://www.gont.com.ar/code/fgont-patch-linux-net-next-rfc4941bis.txt 
(up & running here).

I've submitted it to the netdev list already.

And should have a patch for the FreeBSD kernel today.

Not sure if this might be useful for a "disposable" (to be removed by 
the RFC-Ed section), but I guess might be of use for the shepherd's writeup?

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Apr 2020 15:46:18 -0300

Oh, by the way: OpenBSD already implements rfc4941bis in -current! 
(kudos to Florian Obser)

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Apr 2020 21:09:26 +0200

> https://www.gont.com.ar/code/fgont-patch-linux-net-next-rfc4941bis.txt 

Does it work with a plen 65 in RA?

Alex, LF/HF 1

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 2 Apr 2020 15:32:26 -0400

Hi Fernando,

> On Apr 2, 2020, at 1:26 PM, Fernando Gont <[email-masked]> wrote:
> 
> Folks,
> 
> FWIW, I produce a patch for Linux kernel (net-next) that implements rfc4941bis: https://www.gont.com.ar/code/fgont-patch-linux-net-next-rfc4941bis.txt (up & running here).
> 
> Not sure if this might be useful for a "disposable" (to be removed by the RFC-Ed section), but I guess might be of use for the shepherd's writeup?

I think you can add an Implementation Status section into the draft as described in RFC7942. It serves as documentation of the existing implementations when the draft goes through IETF Last Call as well as IESG Evaluation. It will be removed before the draft is published as an RFC. I have found these sections helpful and informative when I was on the IESG.

Cheers
Suresh

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Apr 2020 16:21:04 -0300

> Does it work with a plen 65 in RA?

No. Why would that matter in this context?

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

---

From: Florian Obser <[email-masked]>
Date: Thu, 2 Apr 2020 22:11:40 +0200

> Does it work with a plen 65 in RA?

I'm happy to report that slaacd(8) in OpenBSD does not care about the plen.
It just forms a 128 bit random number and overwrites the front with
the prefix.[1]
So if you put your whole /29 onlink you can have 99 bits of entropy!

Cheers,
Florian

> Alex, LF/HF 1

1) https://github.com/openbsd/src/blob/master/sbin/slaacd/engine.c#L1415

-- 
I'm not entirely sure you are real.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Apr 2020 22:20:21 +0200

Le 02/04/2020 à 21:21, Fernando Gont a écrit :
>>> https://www.gont.com.ar/code/fgont-patch-linux-net-next-rfc4941bis.txt (up 
>>> & running here).
>>

That is another way to tell me to shut up in this context, which I will.

Not before I tell that this patch is another way to write new software 
propagating further in the future that limit.

Alex, LF/HF 1

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Apr 2020 16:45:21 -0300

Hello, Suresh,

[....]
> I think you can add an Implementation Status section into the draft as described in RFC7942. It serves as documentation of the existing implementations when the draft goes through IETF Last Call as…

Thanks a lot for your input! Will do that, unless the chairs suggest 
otherwise.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Apr 2020 17:50:15 -0300

> propagating further in the future that limit.

1) Typically, you address one issue in each patch. This patch didn't 
remove support for non-64 prefixes. The support wasn't there. Since the 
patch needs to be reviewed, it is better for the patch to do one thing, 
that's clearly defined somewhere (rfc4941bis). One this gets solved, it 
is possible, if deemed appropriate, to improve on this patch and relax 
the requirement on the prefix length.

2) I'm not sure how winning solves problems. You haven't wrote a patch 
to implement rfc4941bis, and you haven't implemented a patch to relax 
the requirement on the prefix length, either. Still, you even have the 
idea of obstructing progress of rfc4941 out of frustration that 
rfc4941bis does not boil the ocean you'd like to boil.

Thanks,

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Thu, 2 Apr 2020 21:19:07 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Florian Obser

Yay! And if it works for any length of prefix, it also works for 64-bit prefixen.

Also want to point out, especially for devices that are assigned a prefix of their own, any argument anyone insists on, for why a long IID is better for security, would result in a shorter prefix. So the security considerations are moot. Is that 72-bit IID wonderful? What about the consequent 56-bit prefix?

But okay, this might be out of scope with today's SLAAC. I continue to thik that implement SLAAC with any old IID length is just as easy as not doing so.

Bert

---

From: Mark Smith <[email-masked]>
Date: Fri, 3 Apr 2020 09:02:46 +1100

> So if you put your whole /29 onlink you can have 99 bits of entropy!

Or 1 bit of entropy if you use a 127.

Might be worth issuing a warning about the privacy properties of an RFC4941
address if the prefix length gets to long.

A false sense of privacy is probably just as bad as a false sense of
security.

Regards,
Mark.

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Apr 2020 18:37:20 -0300

> Also want to point out, especially for devices that are assigned a prefix of their own, any argument anyone insists on, for why a long IID is better for security, would result in a shorter prefix.…

Indeed.

> But okay, this might be out of scope with today's SLAAC. I continue to thik that implement SLAAC with any old IID length is just as easy as not doing so.

Same here.

---

From: [email-masked]
Date: Fri, 3 Apr 2020 00:20:14 +0200

Mark,

> Might be worth issuing a warning about the privacy properties of an RFC4941 address if the prefix length gets to long.
> 
> A false sense of privacy is probably just as bad as a false sense of security.

4941bis is for SLAAC. SLAAC uses 64 bit IIDs.
I don't think we need to get into this discussion. See also 7421.

Note also the title change.
These are temporary addresses. I believe the document does not make any exaggerated claims about privacy.
I.e. it claims very little in that respect...

Best regards,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 3 Apr 2020 11:14:06 +0900

> I've submitted it to the netdev list already.

Do you have a link to the patch on patchwork? I couldn't find it in this
query:

https://patchwork.ozlabs.org/project/netdev/list/?series=&submitter=8623&state=*&q=&archive=both&delegate=

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Apr 2020 23:41:12 -0300

On 2/4/20 23:14, Lorenzo Colitti wrote:
> On Fri, Apr 3, 2020 at 2:28 AM Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Do you have a link to the patch on patchwork?

I've put it online here, just in case: 
https://www.gont.com.ar/code/fgont-patch-linux-net-next-rfc4941bis.txt

And this was my post to netdev: 
https://lore.kernel.org/netdev/[email-masked]/T/#u

(the resulting code is much simpler. MOre lines of code deleted than added).

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Sun, 5 Apr 2020 17:56:59 +1000

Hi Ole,

> 4941bis is for SLAAC. SLAAC uses 64 bit IIDs.

Thoroughly agree. When people want to support other length prefixes,
and ignore the consequences, I'll point out those consequences.

Security/privacy mechanisms should fail safe or closed, not fail
unsafe or open. In this instance, for example, OpenBSD should at least
generate a warning if the IID size is too small for useful privacy,
or, better, actually fail safe and refuse to bring up IPv6 on an
interface that has a too long preifx/too small IID when rfc4291bis is
enabled.

> I don't think we need to get into this discussion. See also 7421.

"An extremely detailed review by Mark Smith was especially helpful." ;-)

I support a default subnet/IID size that accommodates as many use
cases as possible because it is the simplest option. That value is 64
bits (48 bits was the chosen size of IIDs, I'd probably be happy with
that too, it's is the single, universal and large enough size that is
more important than the particular value.)

> Note also the title change.

Does this mean that rfc4941bis doesn't apply to DHCPv6 IA_TAs?

If original RFC4941 is obsoleted by rfc4941bis, then I think that
means that RFC8415 would now have an unresolved RFC4941 reference.
Looking in the current dhc WG drafts, I can't see a DHCPv6 ID that
would be the equivalent of what rfc4941bis is now becoming for SLAAC.

Best regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 5 Apr 2020 06:36:13 -0300

Hi, Mark,

On 5/4/20 04:56, Mark Smith wrote:
[...]
> and ignore the consequences, I'll point out those consequences.

That's certainly fine... just that such discussion doesn't need to be 
part of rfc4941bis ;-)

> Does this mean that rfc4941bis doesn't apply to DHCPv6 IA_TAs?

Neither rfc4941bis nor RFC4941 apply to DHCPv6. -- title being 
"...Extensions for IPv6 SLAAC".

> means that RFC8415 would now have an unresolved RFC4941 reference.

But that's not the way revisions work. -- the obsoleting document takes 
the references. Or, actually, more precisely, the obsoleted document 
remains the reference. But then you realize from the metadata that it 
has been obsoleted by another document, and thus read the obsoleting 
document instead.

(Note that, otherwise, the same would apply to all documents that 
reference e.g. RFC2460, that has now become obsoleted by RFC8200).

> would be the equivalent of what rfc4941bis is now becoming for SLAAC.

Neither you'll find a document that is the equivalent of what RFC7217 
became for SLAAC -- well, strictly speaking, you have RFC7943, but 
somehow (long story) it was published on the independent submissions 
track, rather than standards track.

Thanks,

---

From: Bob Hinden <[email-masked]>
Date: Sun, 5 Apr 2020 12:26:13 -0700

Fernando,

> On Apr 2, 2020, at 12:45 PM, Fernando Gont <[email-masked]> wrote:
> 
> Hello, Suresh,
> 
> [....]
>>> 
> Thanks a lot for your input! Will do that, unless the chairs suggest otherwise.

I think that is fine.

Bob

---

From: Tim Chown <[email-masked]>
Date: Thu, 9 Apr 2020 20:54:52 +0100

> On 5 Apr 2020, at 08:56, Mark Smith <[email-masked]> wrote:
> 
> Hi Ole,
> 

Well, there is an RFC on that topic; at least pointing to the issues (which may or may not be ignored if you choose to do it…)

Tim

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 9 Apr 2020 16:35:11 -0400

Fernando

I thought for the privacy extension VL PL changes as the final changes in
the discussion as we went through so many permutations and many threads
just so I am clear from what I recall.

So what was on the table was VL=2 PL=2.   Then for a balance of issues with
long lived flows using invalid address and trying to reduce the number of
deprecated addresses as far down as possible that can exist to help with
MTTR troubleshooting we decided on finally VL=PL=2.

Reduces the default Valid Lifetime for temporary addresses:
      The default Valid Lifetime for temporary addresses has been
      reduced from 1 week to 2 days, decreasing the typical number of
      concurrent temporary addresses from 7 to 2.  This reduces the
      possible stress on network elements (see Section 4
<https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis-09#section-4>
for further
      details).

Thanks

Gyan

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]