Subject: concerns about ACCEPT [LL23] Don't configure needless LL addresses

From: Erik Guttman <[email-masked]>
Date: Fri, 4 Apr 2003 14:54:05 +0200 (CEST)

I have received requests from three WG participants who have concerns
both about the decision to accept LL23 and the process by which it was
decided.

Regarding the process - I am doing my best to include all points of view
and discover the consensus, even if it is rough.  If I could do a better
job of this, please let me know and offer concrete suggestions.  We do
not have the luxury of leaving these decisions for a brighter day when
we finally collectively emerge from the cave of ignorance.  Further, we
have to consider the context in which we are making these decisions:  We
must answer IESG issues expressed *LAST OCTOBER* so we can get this
document out as a standards track RFC.

Regarding the decision -

  The following concerns have been expressed to me

  (1) While LL23 instructs a host to use a routable address instead of
      a link-local address as its source address (if it has one), the
      host can keep using link-local addresses for connections underway
      and even accept new communications on the link-local address.
      Thus, the scoped address (source address selection) problem does
      not go away - it is only 'contained' to some extent.

  (2) If we 'give up' our link-local address and cease to advertise it
      (using LLMNR, SLP, etc) as long as we have a valid DHCP lease,
      there are situations where we will roam and not use link-local
      auto-configuration (where we could).  If we eagerly shed our
      DHCP configuration in INIT-REBOOT state and we do not hear
      from the DHCP server (see (3) in Sec 3.2 of RFC 2131), we may 
      lose our legitimate configuration in a network where we should
      keep it.  This problem is exacerbated by the pressure for rapid
      usability of systems.  Waiting 5 minutes is not acceptable.  LL23
      forces vendors to trade off rapid usability and robust operation.

As WG chair I must emphasize that the bar on revisiting a close issue is
very high.  We must show either that the resolution is totally broken or
that a significantly better alternative exists which can achieve WG
consensus.

 - An alternative which leaves open issues of scoped address
   architecture for an indefinite period of time has been shown to
   not achieve WG consensus and leave several issues open which will
   prove very difficult to address without a 'transition' mechanism
   (namely LL1, LL4 and LL5).  

 - Is (1) really a problem, given that only 'open' connections and 
   'accepted' connections are possible with link-local after a routable
   configuration occurred?

 - We should explore (2) more.  Can we give guidance for timers and
   express caveats like - if you eagerly give up DHCP configuration, 
   you MUST regularly attempt to reenter INIT-REBOOT and resume use
   of the configured address if the DHCP server responds.  Or, you
   should attempt to send a ICMP message to your configured router
   and if it responds, continue to use the routable address even if
   DHCP doesn't respond, etc.

Next steps -

Those who are intent on revisiting this point, please post a message to
the list expressing why we must do so, how we can meet existing concerns
(see LL1, LL4 and LL5), and why your proposal is better than LL23.  If
there is rough consensus support for your proposal - we will create an
issue to track it and take it through 1 week last call.  

Remember the bar is high.  We cannot keep cycling over decisions unless
there is an extremely compelling alternative.

I hope that those of you who were not satisfied with the process by
which we arrived at an ACCEPT of LL23 rough consensus call will find
that this manner of revisiting LL23 is fair and appropriate. 

Erik Guttman
Zeroconf WG chair

---

From: Robert Elz <[email-masked]>
Date: Sat, 05 Apr 2003 19:13:00 +0700

Date:        Fri, 4 Apr 2003 14:54:05 +0200 (CEST)
    From:        Erik Guttman <[email-masked]>
    Message-ID:  <Pine.SOL.3.96.1030404141725.8788D-100000@field>

  | Further, we
  | have to consider the context in which we are making these decisions:  We
  | must answer IESG issues expressed *LAST OCTOBER* so we can get this
  | document out as a standards track RFC.

Actually no - you should abandon that line of thinking.   if something could
have been done, quickly, in that direction last November, or perhaps even
December, that would have been a correct approach.

But that isn't what happened, the whole doc has been revised, with a new
look at just about everything.   By this stage, what is essentially being
done is the new submission of a new document.

That should still be done as rapidly as possible, and it is still reasonable
to start from the base of the document as it was submitted last year, but
it is no longer reasonable (nor has it in fact been done) to consider that
all that is happening here is that the WG is looking for answers to a few
questions asked of it by the IESG.   Even if it wasn't obvious that this
is what is happening in fact, there's a new IESG now, even if all the
previous points are answered, nothing says that the new IESG won't have
a whole new set of concerns.

The best way to avoid that, is to make the document as complete and
workable as possible - which means to consider all of the issues raised,
not ignore or avoid any because they weren't on that IESG list.

  | Regarding the decision -
  | 
  |   The following concerns have been expressed to me

Both of those are technical concerns, which were expressed (over and
over again) during the dicussions.   I can't see how raising them again
is going to help anything.   But if that's what we (the WG as a whole)
want to do, I can make the same kinds of points about other decisions
where the "wrong" decision was obviously (IMO) made (like LL2).

  |  - We should explore (2) more.

(2) is just reflecting upon lazy implementations.   Nothing that we can
do can avoid problems from implementors who can't be bothered doing
rational implementations.   It is already quite clear from 2131 what
implementors who want to do a good implementation of a DHCP client should
be doing (though 2131 doesn't require that implementations all be good
ones - that isn't required for interoperability, just user happiness,
that the implementations in the most common platforms happen to have
ignored the users and gone for an easy solution certainly isn't our problem).

This WG should most certainly not be bending its specification in any
way at all based upon the assumption that only lazy DHCP client implementations
will ever exist.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 06 Apr 2003 15:15:11 +0300

Erik,

Any way I look at it, concern (2) is a show stopper for us. Before the
SF meeting I was trying to come up with an alternative solution that
would satisfy both camps but the more I turn it over in my head the more
convinced I become that retracting LL23 completely is the only robust
solution.

At this point in time, I think the onus for finding a workable solution
to (2) now rests on the proponents of LL23. Until such a solution is
forthcoming, I believe we will simply have to ignore these particular
requirements in our implementation. Technically this is allowed, as we
can assign a global address to one interface and a LL address to
another, and connect those interfaces to the same link. We have a
multi-site, multi-homing capable host implementation that has the
necessary APIs to deal with the address ambiguity. So, we should be able
to cope.

As Stuart so aptly stated, "we may just have to accept that this is a
point where industry and the IETF will have to agree to disagree, and
accept that our solutions will be broadly similar but will differ in a
few minor details".

Regards,

	MikaL

---

From: Erik Guttman <[email-masked]>
Date: Fri, 11 Apr 2003 14:54:18 +0200 (CEST)

> accept that our solutions will be broadly similar but will differ in a

Can we come to consensus on LL23 substituting SHOULD for MUST in the
paragraph below:

   Where a link-local address has been configured on an interface, and a
   routable address is later configured on the same interface, the host
   MUST always use the routable address when initiating new 
   communications, and MUST cease advertising the availability of the 
   link-local address through whatever mechanisms that address had been
   made known to others.

****Can we get agreement on this if we also include a list of potential
    risks if we go against recommendations?

*** Who will volunteer to write up this list of potential risks
    and to work diligently till the WG is satisfied the risks are
    well documented?  (I do not volunteer to do this.)

*** Who will volunteer to document applications which will and will
    not have problems with mixed scope hosts (LL4 and LL5 - which need
    text) and to work with the WG and Harald till we reach consensus?

Erik Guttman
Zeroconf WG chair

-------------------------------------
> > that this manner of revisiting LL23 is fair and appropriate. 

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
 E r i k   G u t t m a n                        
 N1 Installation and Provisioning     
 Sun Microsystems                               cell: +49 172 865 5497

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 16 Apr 2003 22:00:46 -0000

I am beginning to think that this issue is a red herring. Whether or not you
maintain two separate addresses or just one, the real problem is to
establish whether an address "works" and particularly to do so at the
stack/OS level. Maintaining both an LL address and a global one, doesn't
really help (or hinder) that process. Simply having a LL address available
does not help the stack know when to use it.

You say that you have the necessary APIs to deal with address ambiguity -
does this mean that you are writing or adapting your own apps to take
advantage of this API? In cases (typical of many embedded systems) where
apps are more or less custom written and are very closely coupled to the
stack/OS, I can't see any abjection to running both LL and global side by
side - but nor can I see an abjection to the LL23 approach either - because
in both cases the app and the stack work together to use the best address
available and the app can be written to be aware of scope limitations when
it is using or communicating with a LL address.

Couldn't an API similar to yours work with LL23, by allowing the app to say
"communications aren't working, please try a different address strategy"? It
is generally far easier for an application to make the decision as to when
an address is working than for the stack/OS. This would be consistent with
Erik's suggestion of changing some MUSTs to SHOULDs. It would also be
consistent with Erik's suggestion a few weeks ago of interpreting
"Configured routable address" as implying that that address works.

Would it help if the text was changed to refer to when to *use* a particular
address rather than when to *obtain* (or relinquish) it? I see no real
problem in continuing to defend an LL address "in the background" even when
a routable address is working so long as that LL address doesn't get used
(it is kept in case the network configuration changes). Similarly I do not
see that a valid DHCP lease or manual configuration needs to be relinquished
because it is not currently working and an LL address is being used in the
interim (perhaps because the host has moved to another network). What does
cause real trouble is using the LL address in a network where the routable
one is valid and working and where applications are not scope aware (that's
most applications for general purpose computers).

Philip

----- Original Message -----
From: "Mika Liljeberg" <[email-masked]>
To: "Erik Guttman" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, April 06, 2003 12:15 PM
Subject: Re: concerns about ACCEPT [LL23] Don't configure needless
LLaddresses

---

From: Mika Liljeberg <[email-masked]>
Date: 17 Apr 2003 23:27:59 +0300

Hi Philip,

On Thu, 2003-04-17 at 01:00, Philip Nye wrote: 
> I am beginning to think that this issue is a red herring.

Well, the words "red haze" seem more appropriate when one tries to
implement it. :-)

>  Whether or not you
> stack/OS level.

This I fully agree with.

>  Maintaining both an LL address and a global one, doesn't
> really help (or hinder) that process.

This I don't. If you have more than one addresses configured, you can
try to choose one that works. If you only have one, there is nothing to
choose from. It either works or it doesn't. For the application at hand,
it's too late to start trying to configure another one.

>  Simply having a LL address available

True. You have to have rules such as those in RFC3484.

> advantage of this API?

No, quite the opposite. We have a fully scoped implementation. We carry
scoping information in address structures and our name resolver APIs
return scoped addresses with zone IDs. We observe default address
selection rules as described in RFC3484 (applied to both IPv4 and IPv6).
Applications don't really have to care about scopes, unless they want
to.

>  In cases (typical of many embedded systems) where

This is exactly what we're trying to avoid. We have an open OS and we
specifically don't require applications to be custom written. If a
specific zone needs to be selected, the user does it, not the
application.

> "communications aren't working, please try a different address strategy"?

We don't have such an API and we don't want one.

>  It
> an address is working than for the stack/OS.

True. But the right way to do this, IMHO, is to offer the application a
choise of destination addresses pre-ordered so that the ones most likely
to work are up first. All a robust application has to do is try them in
order until it find one that works. A less robust application may only
try the first one. That's ok, too. The source address actually has very
little relevance. The OS can easily choose one that works in the reverse
direction.

> This would be consistent with

I suppose either of those suggestions would make our implementation
slightly more legitimate in the eyes of IETF and, as such, I'm in favor.
However, they don't solve the concrete problems we have, and therefore
don't effect a change in our implementation.

> address rather than when to *obtain* (or relinquish) it?

This would definately be a step in the right direction. RFC3484 is all
about when to use a particular address.

However, I also have a problem with the "when to advertise" rules. A
node that advertises its addresses has no way of knowing which of those
addresses are usable to the recipient of the advertisement. Therefore, a
node should be allowed to advertise all the addresses it has, and let
the recipient choose the ones that are likely to work, and to present
them to the application in order of preference.

>  I see no real
> (it is kept in case the network configuration changes).

That's good, and I agree, although it's more complex than that. A
particular address is not categorically usable or unusable. It depends
on context (i.e. the peer). You might have nodes A, B, and C such that A
and B are able to communicate using global addresses. So are B and C.
However, A and C may not be and therefore have to resort to link-local
addresses. It all depends on what on-link routes each of those nodes
have.

>  Similarly I do not
> interim (perhaps because the host has moved to another network).

I agree.

>  What does

I don't mind other vendors opting for an implementation approach where
they only use a single address at a time. That choice may be justified
in light of their customer base. However, we're targeting the mobile
wireless environment where scoping, intermittent reachability, and
changes in topology are facts of life and no amount of wishing otherwise
is going to make them go away. Applications also tend to be smarter
about reachability and also tend be updated fairly frequently, so there
is no significant base of dumb legacy applications to deal with.

I appreciate your effort at trying to find a compromise. However, I
don't think we need a compromise. I think we need to recognize that the
specification is going too far in attempting to guide implementations to
a specific solution and, in so doing, limits the applicability of the
specification itself. The specification should stick to saying how
link-local addresses are supposed to work and not attempt to specify how
they interact with the rest of the world.

	MikaL