Subject: Final word - ACCEPT [LL23] Don't configure needless LL addresses

From: Erik Guttman <[email-masked]>
Date: Wed, 14 May 2003 09:13:34 +0200 (CEST)

On 13 May 2003 18:37:31 +0300 Mika Liljeberg <[email-masked]>
wrote:
>
> What was the conclusion on revisiting LL23?
>
> The connectivity problems caused by LL23 are still unresolved.

Mika,

The final word on this is that the ACCEPT [LL23] decision stands.
The reasons for this are as follows:

a) The decision has been validated by a parallel decision being made
   for LLMNR.  In this case, once a host has a routable address the
   link-local is no longer advertised.

b) concern (2) below is a matter for implementors to decide, depending
   on their priorities.  We 'violate' only a suggestion (a MAY) in
   RFC 2131 by not requiring that hosts hold onto their leases when
   they restart/attach to a network/etc & instead use LL autoconf.

c) The problems posed by an open-ended scoped address architecture
   posed in the message where LL23 reconsideration was broached were
   not taken up.

d) As stated in that message (attached below) - the bar is high.  No
   new alternatives or additional arguments supporting a change in
   the ACCEPT were presented during the weeks since this message was
   posted.  I realize that the consensus call here is rough, but a 
   call *must* be made, *has* been made, and stands.

Thanks,

Erik Guttman
ZEROCONF WG chair

---------------------------------------------------------------------

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: Mika Liljeberg <[email-masked]>
Date: 15 May 2003 22:22:25 +0300

>    link-local is no longer advertised.

Unfortunately that decision is rather pointless, since two nodes with
global addresses and matching prefixes are likely to have access to a
DNS server and LLMNR will never be invoked.

If one of the two nodes is not on the home link, the nodes will be
unable to communicate because their on-link prefixes will not match.

If one of the two nodes only has a LL address, they will be unable to
communicate because (again) their on-link prefixes will not match.

>    they restart/attach to a network/etc & instead use LL autoconf.

Yes, let's leave it to the implementors to fix the broken specification:

1) Nodes having a valid DHCP lease will not benefit from zero
configuration, unless the user manually releases the configured address.

2) Nodes having a manually configured address will not benefit from zero
configuration, unless the user manually unconfigures the configuerd
address.

3) Nodes having only a LL address will be unable to communicate with
nodes having a global address, unless the user manually adds an
appropriate on-link route for the link.

See anything wrong with this picture?

>    posed in the message where LL23 reconsideration was broached were

This is a minor issue compared to b). Worrying about niche applications
is pointless when point-to-point communication between two nodes on the
same link is not working.

	MikaL

---

From: Erik Guttman <[email-masked]>
Date: Fri, 16 May 2003 12:07:50 +0200

> DNS server and LLMNR will never be invoked.

I disagree.  There are several important cases where the hosts will not
be able to access DNS and for which LLMNR is crucial.  The DNS server
may not be up, the network may be partitioned so that local hosts cannot
reach the DNS server, etc.

> communicate because (again) their on-link prefixes will not match.

Why?  LL23 says 'if you have a routeable address, use it for new
connections and advertise it.'  It does not say that hosts cannot
(a) respond to hosts using a LL prefix
(b) continue to communicate using an LL address (for open
     connections)

A host H using a LL address can
  - use service discovery or name resolution to find the address of
    an on-link host H2 to communicate with (whether this discovered H2
    has a ll or routeable address)
  - establish communication with H2
  - if that communication fails, because the peer H2 has renumbered say,
    the H can initiate service discovery or name resolution to find
    its new address.  The host H2 could have gotten a routable address
    and stopped advertising its ll address, but H can still find it.
  - H can send H2 messages, H2 can respond.

Note that *existing hosts* not yet supporting this protocol will not
be able to respond, since if H is not on the same subnet as H2, H2
will forward the message to the router.  The router will toss the
packet into the bit bucket since the destination address for H is
link-local, if the router has been properly configured.  If it has
not been properly configured, the router will probably forward the
packet along its default path.

However, if H2 supports this protocol specification, it will use
ARP to resolve the address of H (since it is in the link-local
prefix) and send the message directly to H.

If this is not clear in the specification, we need to open a new
issue describing the process.   Here are the scenarios:

                     Host H2

                      has LL         has routable           has
                                     address and knows     routable
                                     how to foward to LL   (legacy)

Host H has LL

+ no routers         H can discover  H can discover H2    H can't dis-
                      H2 and ex-      and exchange         cover H2 as
                      change packets  packets              H2 cannot
                                                           send to H.
                                                           H2 & H are
                                                           not on the
                                                           same subnet.

+ Routers will       as above        as above             H can't dis-
   drop pkts with                                          cover H2 as
   LL src or LL                                            H2 & H are
   dest (as                                                not on the
   specified)                                              same subnet.
                                                           H2 will fwd
                                                           to a router
                                                           which will
                                                           drop the pkt

+ Routers will       as above        as above             H can't dis-
   forward pkts                                            cover H2 as
   with LL src or                                          H2 & H are
   LL dest (not                                            not on the
   compliant with                                          same subnet.
   this spec)                                              H2 will fwd
                                                           to a router
                                                           which will
                                                           do something
                                                           wrong with
                                                           the packet.

Does anyone disagree with the above assessment?  Basicly it says
that if the specification is followed, communication is possible
between a host with LL & LL or LL and routable configuration,
provided that the host with routable configuration knows how to
communicate with a host with LL configuration.

> configuration, unless the user manually releases the configured address.

That is not what LL23 says.  LL23 only says that if you have routable
configuration, use it.  It does not say under which situations you
consider yourself to have routable configuration.  That is up to the
vendor.  For example, when a host wakes up after sleeping or determines
that they have lost and then recovered network connectivity - what do
they do?  They may try their best to find the dhcp server, their router,
whatever, and if they can't they may give up.  We do not have to
specify this here.

> configuration, unless the user manually unconfigures the configuerd

If the nodes know how to communicate with a LL host (see discussion
above) they do gain.  They are able to communicate with any hosts on
the local link who support LL.  This is better than the situation we
are in today, where hosts do not know how to communicate with them,
right?

> appropriate on-link route for the link.

This is only the case for 'legacy hosts' which do not understand this
specification.

> See anything wrong with this picture?

I think that the problem may be that we do not have the picture
sufficiently colored in yet.  We do not sppear to be looking at
the same picture.

Erik

---

From: Mika Liljeberg <[email-masked]>
Date: 16 May 2003 20:56:16 +0300

Erik,

Thanks for the thorough response. In the interest of keeping things
focused on the main problem, I'm only responding to the scenarios table.
I've taken the liberty of filling in the routing tables to illustrate my
point.

>                                      how to foward to LL   (legacy)

Route tables:
                    169.254/16 ->link  a.b.c.d/x ->link      a.b.c.d/x ->link
                                       169.254/16 ->link

> Host H has LL

Route table:
  169.254/16 -> link

>                       change packets  packets              H2 cannot
                       TRUE             FALSE. H2 adver-     The reverse
                                        tizes its global     is true as
                                        address but H        well. H does
                                        only has a route     not have a
                                        for LL destina-      route for H2
                                        tions.

Host H has routable
address and knows
how to send to LL

Route table:
  e.f.g.h/y -> link    BROKEN. H adver  BROKEN. Both H and   As above.
  169.254/16 -> link   tises global     H2 advertise global
                       address but H2   addresses but can't
                       only has a rou-  communicate because
                       te for LL.       they don't have
                                        routes for each
                                        other.

I left out the cases with  default routers, since the problems are
essentially the same. The only real difference is that nodes away from
the home link will have a default gateway route pointing to /dev/null in
addition to having a bogus netmask.

> Does anyone disagree with the above assessment?

I do. As shown by the above table, only the trivial cases work:

 1) LL <-> LL
 2) global <-> global, when the subnet masks are same

In all other cases the nodes have mismatching on-link routes, which
prevent communication, even though the nodes are on the same link.

> sufficiently colored in yet.  We do not sppear to be looking at

I think the table above is a good start. Maybe others have a different
idea about how the routing tables are populated? Let's work on it.

	MikaL