Subject: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt

From: [email-masked]
Date: Sun, 03 May 2015 19:29:05 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

        Title           : DHCPv6/SLAAC Interaction Problems on Address Auto-configuration
        Authors         : Bing Liu
                          Sheng Jiang
                          Xiangyang Gong
                          Wendong Wang
	Filename        : draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt
	Pages           : 13
	Date            : 2015-05-03

Abstract:
   The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router
   Advertisement (RA) message.  The RA message contains three flags,
   indicating which auto-configuration mechanisms are available to on-
   link hosts.  These are the M, O and A flags.  The M and O flags are
   advisory, not prescriptive.

   This document describes divergent host behaviors observed in popular
   operating systems.  It also describes operational problems that
   divergent behaviors might cause.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-dhcpv6-slaac-problem-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 4 May 2015 02:30:40 +0000

Observing the posting, let me invite commentary on it.

> On May 3, 2015, at 7:29 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 4 May 2015 11:08:11 +0000

Hi Fred & all,

This draft was launched WGLC when the last version submitted. The main problem raised was that a couple of people didn't think the problems described in the draft were very essential. 
Besides, there were also a couple of people thought the test result part of the document were interesting and valuable, and the whole document should focus on the test report.

We considered these comments carefully, and now we tend to follow this way:
1. This document does NOT intend to invoke 6man to solve the problems in protocol design. We do not judge the problems are essential or just corner cases; this might depend on more IPv6 practices in the future. The document analyzes all the explicit and implicit ambiguities, points out possible divergent behaviors and identifies some divergent behaviors do happen among mainstream operating systems through testing. We believe these are valuable information for administrators caution.
2. The test result of various operating systems are valuable, but we thought maybe it's good to leave it in the appendix. Because the operating systems are updating all the time, the behaviors documented might probably changed in future operating system versions. The documented behaviors are only for proving the analyzed divergence could probably happen in real implementations.

So, we mainly did some editorial revision in this new version:
1. Moved the ambiguity analysis content back to the main text from the appendix (with a bit revision).
2. Changed the title to make it clearer that the document focuses on address auto-configuration aspect of DHCPv6/SLAAC interaction.
3. Adjusted the structure.

So, with the explanation, may I ask the WG, do you think it's a proper way to move forward the draft? Or we need to do some extra work?
Any comments would be appreciated a lot!

Best regards,
Bing

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
> Sent: Monday, May 04, 2015 10:31 AM
> To: [email-masked] WG
> Subject: Re: [v6ops] I-D Action:
> draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt
> 
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >

---

From: 神明達哉 <[email-masked]>
Date: Mon, 4 May 2015 10:27:26 -0700

At Mon, 4 May 2015 02:30:40 +0000,

> Observing the posting, let me invite commentary on it.

It seems that the main points of my previous comments
- http://www.ietf.org/mail-archive/web/v6ops/current/msg20179.html
- http://www.ietf.org/mail-archive/web/v6ops/current/msg20200.html
still apply.

So my conclusion is the same: "I personally don't think it worth
publishing in its current form, although I wouldn't be opposed to it
if the wg thinks it's useful."

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 May 2015 15:29:37 +1200

Hi,

So, one of your comments was this:

>> Actually, I guess there should be more pragmatic examples of
>> operational issues because of the described divergence

That would be fine, but surely the underlying point is that if
you have a heterogeneous network and you repeat certain events
(like a power fail/restart, or a temporary cable cut, or automated
renumbering) the end state may be different in different cases,
because of race conditions and the divergent behaviour of different
devices. Now maybe we accept that as OK, but at least we should
document how it can happen.

Another comment you made:

>>>    The M, O and A
>>>    flags are advisory, not prescriptive.
>> 
>>   In my understanding, the A flag is quite prescriptive.  If a host
>>   implementation doesn't perform SLAAC for a prefix information option
>>   with A flag on, that implementation would be considered
>>   non-compliant.

I agree that this should be clarified. But RFC 4862 does not seem clear,
because it only covers the opposite case:
"a)  If the Autonomous flag is not set, silently ignore the Prefix
     Information option."
Similarly, RFC 4861 is not presecriptive:
" A     1-bit autonomous address-configuration flag.  When
        set indicates that this prefix can be used for
        stateless address configuration as specified in
        [ADDRCONF]."
and RFC 6434 does not mention this issue.

Personally I'd like to see a statement that a host that
receives a PIO with A=1 MUST perform SLAAC, but that really
doesn't seem to be specified anywhere.

> if the wg thinks it's useful."

I think it's useful information for operators.

    Brian

---

From: 神明達哉 <[email-masked]>
Date: Tue, 5 May 2015 11:05:16 -0700

At Tue, 05 May 2015 15:29:37 +1200,

> document how it can happen.

Personally, I'd expect to see some actual and practical troubles in
such a case for a document about it to be sufficiently useful as
something formal like an RFC.  An observation of the divergent
behavior may be somewhat interesting, but IMO not substantial enough.
But, as I (hope) already said I'm not insisting my view is the only
possible position.  I guess you and I just have different expectations
on what's worth documenting in RFCs.  That's fine for me, and if many
others in the wg share your expectation, I have no problem with
publishing it.

> doesn't seem to be specified anywhere.

That would make things super clearer and nicer, but I simply didn't
see the critical need for it.  In fact, from a quick re-read of the
appendices of the draft, all tested implementations in all scenarios
perform SLAAC if they receive a PIO with A=1.  It seems to be an
evidence that this point is already clear enough in practice.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 May 2015 08:46:51 +1200

Comment at the end...

> evidence that this point is already clear enough in practice.

If somebody implements a new stack ten years from now, will it
be clear to them? There's no emergency here, but maybe the next version
of Node Requirements should add this point.

   Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 11 May 2015 00:51:15 +0000 (UTC)

Hi,

<snip>

/ I think there might be value in publishing it, because I think it shows clear misunderstanding of a few IPv6 addressing concepts that are different to or might tightly coupled together in IPv4:

/ - address/IID value generation is separate from

/ - address configuration, which is separate from

/ - address expiry/ageing

/ I think the some of the problems identified are due to coupling/binding together the last two, when I think in IPv6 they're nearly or completely independent.

/ Regards,
Mark.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 11 May 2015 10:59:20 +0900

On Tue, May 5, 2015 at 2:27 AM, 神明達哉 <[email-masked]> wrote:

> So my conclusion is the same:

What he said.
https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt
shows that there are no changes in this document except that the text from
appendix B moved to section 3 and some minor editorial changes. I don't see
why such minor changes should materially change the WG's position on this
document.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 11 May 2015 06:44:12 +0000

Hi Lorenzo,

Thanks for your comment.

I think my another mail right after the draft-posted mail might answer your question (http://www.ietf.org/mail-archive/web/v6ops/current/msg22047.html). Please allow me to iterate our thoughts briefly:

1)      The WG’s position on last WGLC varied. And each of the viewpoint had only few people, so I couldn’t figure out which represented the main voice of the WG.

-        some supported to move forward

-        some thought the problems were not critical

-        some suggested to shape it to a test report

2)      We changed our position to NOT make the draft as a formal Problem Statement to kick off a protocol revision work in 6man. So we re-phrased the title to move the key words “Problem Statement”.

3)      We thought maybe it's good to leave the test results in the appendix rather than making it as the main content. Because the operating systems are updating all the time, the behaviors documented might probably changed in future operating system versions. The documented behaviors are only for proving the analyzed divergence could probably happen in real implementations.

So, this revision was not intend to directly for another WGLC, but to confirm whether our WG agree our thoughts. With the above explanation, does it address your concern?

Best regards,
Bing

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Monday, May 11, 2015 9:59 AM
To: 神明達哉
Cc: [email-masked] WG
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt

What he said. https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt shows that there are no changes in this document except that the text from appendix B moved to section 3 and some minor editorial changes. I don't see why such minor changes should materially change the WG's position on this document.