Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP

On Wed, 2003-10-08 at 12:39, Erik Guttman wrote:
> In the case of the transition from unconfigured to configured there
> is clear consensus that one should 'give up' (that is: stop advertising,
> stop initiating new connections from and eventually stop accepting
> communication from) a link-local configured address.

[I presume you're using the terms configured and unconfigured to refer
to the routable address. The usage in the v4LL state machine description
is inverted.]

Agreed.

> In the case of the transition from configured to unconfigured there
> is no clear consensus yet.
> 
> Choices are
>    - give up dhcp configuration and configure link-local
>    - hold onto dhcp configuration and don't configure link-local
> 
> These I discussed in the text I suggested.  (Does that text make sense?)
> 
>    - hold onto dhcp configuration and configure link-local
> 
> This is a problematic situation in that the host is now 'multihomed',
> with all the attendant problems we have discussed ad nauseum.  One
> way to address this is to mention that this implementation is in no
> way ruled out, but neither is it specified, and refer anyone
> interested in pursuing this option to section 3.

The really difficult problem here is *when* to transition, a problem
which we have been unable to solve. Having both addresses configured
during the transition period actually makes a lot of sense. While a
reference to section 3 is appropriate, the text should not actively
steer implementors away from what may be the only robust way implement
this thing.

I second Philip's suggestion that the v4LL implementation needs to
determine whether there is a "*working* routable address" or not. This
should be reflected in the state machine and also discussed in the
descriptive text. The state transition from INIT to SELECT is logically
triggered by the signal that the validity of the routable address can no
longer be confirmed.

Similarly, the state transition from CONFIGURED to DEPRECATED is
triggered by the signal that a routable address has been configured and
validated.

> > As for a manually configured addresses, there is absolutely no reason to
> > prevent a manually configured address from coexisting with a LL address,
> > since the admin can also manually disable the LL if it is not desired.
> > If the admin wants to have both why should be care?
> 
> Manual intervention of host configuration is not always possible (to
> deconfigure a link-local address, for example).

That's purely an implementation issue. It can be done.

> The point is, the sensible default policy is that when the host is
> configured manually, link-local addresses do not get configured.

Yes, I agree this is the sensible default policy as long as the policy
is not hardcoded into the state machine. If v4LL is administratively
enabled on the interface, the v4LL state machine should be able to
proceed from INIT to SELECT when the manually configured address stops
working (by whatever criteria the implementation uses to detect such
things).

> If an implementor wishes to venture into multihoming-territory, we
> do not forbid it, but we do list a set of issues of which the
> implementor must consider and address.  The specification and its
> state machine assume the implementor will not go this way.

Sadly, I think this is a false assumption. The reality simply is that
most implementations are multihomed (even if most deployed hosts are
not) and the implementors are faced with having to work out how to
accommodate v4LL in their multihomed code. It will be interesting to see
how people deal with this dilemma.

> ps. please comment on suggested text (from previous message):

I'll refrain until I see how the third option gets worked into the text.

	MikaL