Subject: Re: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 5 Nov 2013 04:30:12 +0100 (CET)

On Mon, 21 Oct 2013, [email-masked] wrote:

>
> A new draft has been posted, at http://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem. Please take a look at it and comment.

My comment just now at the mic:

I would like to see if any implementation actually deprecates the /64 
onlink prefix when A goes from 1 to 0, or ignores the on-link prefix when 
A=0.

Ie the on-link prefix should be used by installing a /64 route towards the 
interface, then the A-flag determines if the host is allowed to create 
addresses within this /64 itself, or not.

But when one reads RFC4862 and (from my interpration) is just in the 
context of creating addresses, not what to do with the on-link prefix.

5.5.3.  Router Advertisement Processing

    For each Prefix-Information option in the Router Advertisement:

     a)  If the Autonomous flag is not set, silently ignore the Prefix
       Information option.

This doesn't say anything regarding the /64 route towards the interface, 
it only talks about creating addresses within this /64. I can imagine 
implementators getting this wrong?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: 神明達哉 <[email-masked]>
Date: Tue, 5 Nov 2013 00:02:10 -0800

At Tue, 5 Nov 2013 04:30:12 +0100 (CET),

> onlink prefix when A goes from 1 to 0, or ignores the on-link prefix when

What do you mean by "deprecate the /64 onlink prefix"?

Are you referring to this part of
draft-liu-bonica-v6ops-dhcpv6-slaac-problem?

   [...] But when
   SLAAC-configured, and A changed from 1 to 0, the behaviors varied,
   some deprecated SLAAC while some ignored the RA messages.

On re-reading it now, the draft text (specifically "deprecated SLAAC")
is not very clear either, but at least it's clear to me that this is
about address configuration, not about on/off link.

--
JINMEI, Tatuya

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 5 Nov 2013 12:53:35 +0100 (CET)

> about address configuration, not about on/off link.

Yes, I know this is about address configuration. I am still curious if all 
OSes keep the /64 interface route when A changes to 0 (or is 0 to begin 
with). If you feel this is out of scope that's fine, then my curiosity 
will stay unanswered.

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Nov 2013 13:22:05 +0100

Mikael,

> Yes, I know this is about address configuration. I am still curious if all OSes keep the /64 interface route when A changes to 0 (or is 0 to begin with). If you feel this is out of scope that's fine, then my curiosity will stay unanswered.

in the nit-picking department, wouldn't that really be the L flag?

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 5 Nov 2013 15:21:48 +0100 (CET)

> in the nit-picking department, wouldn't that really be the L flag?

Well, my question was for L=1, A=1, A=1 -> A=0, and A=0 cases. In case the 
implementor got the addressing generation mixed up with the route stuff.

Are there test suites for all this stuff that implementors can use? What 
should come out of this eventually is a document where all 
states/transitions should be tested and the document should say exactly 
what is the expected behaviour.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Nov 2013 04:35:01 +1300

On 06/11/2013 03:21, Mikael Abrahamsson wrote:
>>> Yes, I know this is about address configuration. I am still curious
>>> if all OSes keep the /64 interface route when A changes to 0 (or is 0
>>> to begin with). If you feel this is out of scope that's fine, then my
>>> curiosity will stay unanswered.
>>
> Well, my question was for L=1, A=1, A=1 -> A=0, and A=0 cases. In case
> the implementor got the addressing generation mixed up with the route
> stuff.
> 

>From yesterday's discussion, the outcomes seem a little more complicated
than that.

1. I think the problem statement as it stands (with the English cleaned
up) is a very useful document with two audiences:

 a) the IETF, including 6man, because it points to ambiguity in our specs;
 b) the operator community, because it warns of some very specific
    operational (mis)behaviours with currently deployed code.

Because of b) I think it needs to become an RFC quite soon.

2. Then (probably as a separate document) we need an analysis of
which problems are a result of

  a) implementation errors, which the IETF can document but not fix;
  b) differing interpretations of MAYs and SHOULDs (Fred's point),
     where the IETF could consider BCP guidance to implementors;
  c) errors or ambiguities in the standards, which 6man should fix.

     Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 5 Nov 2013 17:39:55 +0000

Hi, Mikael

> with). If you feel this is out of scope that's fine, then my curiosity

We did not pay attention to the /64 deprecated or not in the routes. Maybe we'll do it in further tests.

Regards,
Bing

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 5 Nov 2013 18:26:40 +0000

> From: Brian E Carpenter [[email-masked]]

> From yesterday's discussion, the outcomes seem a little more complicated
[Bing] I have the same feeling, especially after off-line talking with Eric, I began to notice that it might involve some network-management-philosophy difference. That might be one of the resons why the specification has ambiguity. It was and will be difficult to get consensus on what is exactly the "right" behavior.

 > operational (mis)behaviours with currently deployed code.
[Bing] Yes, that is why we put the document in v6ops. Regardless of whether 6man would clear the ambiguity or not, the operational problems need to be documented, that is the basic goal of this draft.

> Because of b) I think it needs to become an RFC quite soon.
[Bing] I hope so.

>   c) errors or ambiguities in the standards, which 6man should fix.
[Bing] A separated document would make sense. And it might involve much more discussion/arguments than the problem statement.

Regards,
Bing

---

From: 神明達哉 <[email-masked]>
Date: Wed, 6 Nov 2013 11:24:05 -0800

At Tue, 5 Nov 2013 15:21:48 +0100 (CET),

> implementor got the addressing generation mixed up with the route stuff.

I don't understand exactly what this means: "L=1, A=1, A=1 -> A=0, and
A=0".  If you mean something like this

1. a host first receives a prefix information option for a /64 prefix with
   L=1 and A=1
2. the host then receives a prefix information option of the same /64
   prefix with L=1 and A=0

I believe almost all implementations create a direct route for the /64
as well as an address or more using the prefix at step 1.

According to the draft, Windows 7 "deprecate"s (its precise meaning is
not really clear but doesn't matter much here) the address.  All other
implementations listed in the draft do nothing for the address.

I don't know Windows 7 or other implementations do for the /64 direct
route at step 2, but I believe nothing happens on at least all others
than Windows 7.  Perhaps an interesting question is what happens to
the direct route if we keep receiving the L=1 and A=0 prefix
information option and the corresponding address eventually expires.
Unless it has changed recently, BSD variants should still keep the /64
route.  I don't know about Linux; I don't know if iOS works as other
BSD variants on this regard either.

> Are there test suites for all this stuff that implementors can use? What

I think some of such scenarios are covered in TAHI test suites
(http://www.tahi.org/).

--
JINMEI, Tatuya