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

[神明達哉 <[e-mail]>]

At Tue, 5 Nov 2013 15:21:48 +0100 (CET),
Mikael Abrahamsson <[e-mail]> 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.

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