Subject: Next steps: IPv6 core specifications to Internet Standard.

From: [email-masked]
Date: Mon, 23 May 2016 13:17:45 +0200

The 6MAN working group has been working on advancing the core IPv6 specifications to Internet Standard.  The next steps to achieve this goal is described here.

As we’re finishing the edits on the RFC2460bis, RFC1981bis and RFC4291bis, we will initiate working group last calls with the intended status of Internet Standard.
We will do a single last call for the updated documents (RFC2460, RFC4291, RFC1981) and a separate working group last call for the unchanged documents (RFC3596, RFC4443, RFC4941).

The focus of the working group last call is on the RFC6410 requirements and implementation status of the updated text.

When the changed documents are advanced to the IESG, we will also ask the IESG to reclassify RFC3596, RFC4941, RFC4443 in-place as Internet Standards.

The result will be for all six of these documents to be Internet Standards.

As part of the working group last call we are asking for reviewers for each document set.

Best regards,
Ole and Bob

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 May 2016 11:53:57 -0400

Ole,

On 05/23/2016 07:17 AM, [email-masked] wrote:
>
> As we’re finishing the edits on the RFC2460bis, RFC1981bis and
> RFC4291bis, we will initiate working group last calls with the
> intended status of Internet Standard. We will do a single last call
> for the updated documents (RFC2460, RFC4291, RFC1981) and a separate
> working group last call for the unchanged documents (RFC3596,
> RFC4443, RFC4941).

After reading RFC4941, it looks like it really needs to be updated, and
also that if one were to publish RFC4941 in 2016, a fair share of text
would be edited.

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

---

From: [email-masked]
Date: Mon, 23 May 2016 19:58:27 +0200

Fernando,

> also that if one were to publish RFC4941 in 2016, a fair share of text

Yes, but we're not. We're reclassifying it as Internet Standard.

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 May 2016 11:41:38 +1200

> Yes, but we're not. We're reclassifying it as Internet Standard.

And that's a problem, because it directly implies that temporary addresses
are *additional* and that is, from recent discussions, a MAY not a MUST.

I suggest removing 4941 from the list.

   Brian

---

From: [email-masked]
Date: Tue, 24 May 2016 08:59:39 +0200

Brian,

> are *additional* and that is, from recent discussions, a MAY not a MUST.

I don't think 4941 _requires_ public addresses. it specifies the behaviour _if_ you have them.
it is up to applications how the use the available addresses.

(somewhat tangentially, you can also argue that a lot of the benefits and point of doing IPv6 in the first place goes away if you don't have stable addresses, oh well.).

> I suggest removing 4941 from the list.

is there a cultural shift in the IETF? are we trying to make standards much more prescriptive in specifying _how_ we want people to use them? as opposed to containing ourselves to specifying protocols and mechanisms?

are there real problems with 4941? or are we unhappy with how users/implementors are using the resulting addresses? or are we worried about _how_ they might use them or not use them in the future?

what are you trying to achieve by not making 4941 Internet Standard?

cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Tue, 24 May 2016 18:37:39 +1000

On 24 May 2016 4:59 PM, <[email-masked]> wrote:
> (somewhat tangentially, you can also argue that a lot of the benefits and
point of doing IPv6 in the first place goes away if you don't have stable
addresses, oh well.).
> is there a cultural shift in the IETF? are we trying to make standards
much more prescriptive in specifying _how_ we want people to use them?

I think in the security and privacy domains, being prescriptive or close to
it is probably necessary to try to ensure things aren't used incorrectly or
past when they should be.

This RFC is certainly prescriptive.

"Deprecating Secure Sockets Layer Version 3.0"
https://tools.ietf.org/html/rfc7568

>as opposed to containing >ourselves to specifying protocols and
>mechanisms?
>
> are there real problems with 4941? or are we unhappy with how
users/implementors are using the resulting addresses? or are we worried
about _how_ they might use them or not use them in the future?
> what are you trying to achieve by not making 4941 Internet Standard?

Regards,
Mark.

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 May 2016 14:44:08 -0400

[email-masked] wrote:
    > I don't think 4941 _requires_ public addresses. it specifies the
    > behaviour _if_ you have them.  it is up to applications how the use the
    > available addresses.

I think that we need to, after this effort is over, come back and ask if we
have the right APIs for applications to actually do this.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 May 2016 08:43:17 +1200

Ole,
> it is up to applications how the use the available addresses.

It directly states that 4941 addresses are *additional* to "normal" SLAAC
addresses. That's exactly the point that Lorenzo has been, er, going on
about. So I really don't believe we have consensus that this is desirable.

> (somewhat tangentially, you can also argue that a lot of the benefits and point of doing IPv6 in the first place goes away if you don't have stable addresses, oh well.).

Yes, in many scenarios, but not in the coffee shop type of roaming scenario.

> is there a cultural shift in the IETF? are we trying to make standards much more prescriptive in specifying _how_ we want people to use them? as opposed to containing ourselves to specifying protoc…

In this case I'd like 4941 to be *less* prescriptive, by removing the statement
that these are *additional* addresses.

> what are you trying to achieve by not making 4941 Internet Standard?

I would like to see 4941bis as Internet Standard, with the bit that
doesn't have consensus removed.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 25 May 2016 13:21:59 +0900

> I don't think 4941 _requires_ public addresses. it specifies the behaviour

RFC 4941 does require public addresses:

   1. The text explicitly says in several places that privacy addresses are
   "in addition to" public addresses.
   2. If you don't have a public address, critical parts of the
   specification, such as how to extend the lifetime of privacy addresses when
   receiving an RA, are undefined. An example is the text that says, in
   effect, "when an RA would extend the lifetime of a public address, then
   also extend the lifetime of temporary addresses".

If we want to reclassify it as is, we'll have to accept that the resulting
Internet standard document will only a) define the behaviour for privacy
addresses with a public address, b) say that privacy addresses should be
depreferred by default.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 26 May 2016 11:14:53 +0300

Hi,

Based on the discussion regarding advancing RFC4941, we think that the w.g. should not plan to advance RFC4941 in place to Internet Standard.  We can move this RFC to the list of documents that can be advanced later.  The w.g. can decide if an update is needed, or if it should be advanced at all.

Thanks,
Bob & Ole

> On May 25, 2016, at 7:21 AM, Lorenzo Colitti <[email-masked]> wrote:
> 
> 	• The text explicitly says in several places that privacy addresses are "in addition to" public addresses.
> 	• If you don't have a public address, critical parts of the specification, such as how to extend the lifetime of privacy addresses when receiving an RA, are undefined. An example is the text that says, in effect, "when an RA would extend the lifetime of a public address, then also extend the lifetime of temporary addresses".
> If we want to reclassify it as is, we'll have to accept that the resulting Internet standard document will only a) define the behaviour for privacy addresses with a public address, b) say that privacy addresses should be depreferred by default.