Subject: WG Action ACCEPT [LL23] Don't configure needless LL addresses

From: Erik Guttman <[email-masked]>
Date: Thu, 27 Feb 2003 13:55:19 +0100 (CET)

Action: Accept

Dissenting Views (summarized by the WG chair)

    Ted Lemon: He worries about the behavior of nodes which configure
               and then cannot 'unconfigure' to interoperate again.
               He thinks this has to be dealt with here instead of in
               the DHC WG.

    Mika Liljeberg:   
              His basic point is that this is not foolproof.  There will
              be problems of leakage of identifers, scope selection,
              inability to communicate in some cases, etc. and that the
              transition cases have not been fully worked out.

    Stuart Cheshire:
               In order for configuration to enable interoperation, all
               host configuration on a link must agree (subnet, etc).
               If we go with LL23 we lose the ability to get
               interoperation on the link even in the face of
               misconfiguration.

Notes:
 (1) It must be noted that LL23 is very close if not identical to the
     behavior of hosts already supporting IPv4LL configuration today
     (MacOS9, Windows98 and onward, etc).  We have operational
     experience which shows that (a) it is useful, (b) it is not
     horribly broken.

 (2) We have WG consensus that issues can arise when there are hosts
     with more than one scope on the network.  This multi-scoped
     host will have issues with source address selection and may
     forward protocol messages with locators, referrals, redirects
     or addresses in-line off-link.  The host which only supports
     LL will also be effected if (a) it supports a service and
     (b) its location is forwarded off link, where the service
     cannot be reached.  Implication:  Mixed scopes *do* present
     a problem.
 
 (3) The behavior described in LL23 will ensure that there is an
     orderly way of transitioning from LL to configured interface
     operation.  This will respond to problems in (2) in a way 
     known to work (consistent with (1)).

 (4) In response to Ted's concern:  The wording of LL23 does not
     specify when or how a host must consider itself 'configured.'

     LL23 does not preclude an attempt to verify configuration 
     upon awakening from sleep mode, changing of carrier sense, etc.
     A host could determine that it needs to configure with LL in
     the case that it cannot reach the router, the DHCP server, etc
     in a bounded period of time (reasonable both for operational
     stability and for usability).

     The rules for how and when to determine network reattachment
     have not been given.  It is unlikely that this WG can solve
     this problem conclusively.

     Recommendation:  Open a new issue with RECOMMENDED behavior
     for transitioning from configured to unconfigured state
     based on experience from Apple, Microsoft, etc. clients.
     
 (5) In response to Mika's concern:  We realize there are potential
     issues when hosts have multiple address scopes configured.  This
     state with known problems is *bounded* in that hosts will only
     experience these problems during transition.

 (6) In response to Stuart's concern:  Support for networking in 
     misconfigured networks is not a work item on the charter.  It
     is unfortunate that we cannot offer a solution to this problem,
     but to do so would leave the can of worms open for an indefinite
     period of time.

 (7) Accepting LL23 goes a long way toward answering IESG concerns.

Erik
ZEROCONF WG chair