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

[Brian E Carpenter <[e-mail]>]

On 06/11/2013 03:21, Mikael Abrahamsson wrote:
> On Tue, 5 Nov 2013, Ole Troan 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.
>>
>> 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 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