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

From: Erik Guttman <[email-masked]>
Date: Sat, 17 May 2003 16:43:05 +0200

Sorry to reply to myself, but I wanted to clarify one statement
I made.

Erik Guttman wrote:
> Once we rejected LL we all knew that we would have to face the
> transition problem, both ways, eventually.  

I meant once we rejected LL19 and accepted LL23, it opened the
door to the transition problem.  Hosts configure LL, then
configure routable and in some cases, may configure LL again.

LL23 does not state under what conditions one considers that a
host is configured with a global address.  This cannot be stated
generally, since some hosts are mobile, some hosts sleep/wake,
some hosts may be multihomed with one home on a local link, the
other on a routable link (which goes up and down), and many
other possibilities.

Erik

---

From: Mika Liljeberg <[email-masked]>
Date: 17 May 2003 19:13:08 +0300

On Sat, 2003-05-17 at 17:33, Erik Guttman wrote:
> Mika,
> 
> <wg chair hat off>
> 
> On 16 May 2003, Mika Liljeberg wrote:
> > 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.
> > 
> > On Fri, 2003-05-16 at 13:07, Erik Guttman wrote:
> > > 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)
> > 
> > Route tables:
> >                     169.254/16 ->link  a.b.c.d/x ->link      a.b.c.d/x ->link
> >                                        169.254/16 ->link
> 
> Why not:
>                       * -> link 

That's unacceptable. This is not compatible with multihoming. You can't
just add a default on-link route to /dev/null, when you might have a
perfectly good default gateway behind another interface.

> > > Host H has LL
> > 
> > Route table:
> >   169.254/16 -> link
> > 
> > 
> > > + 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.
> > > 
> >                        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.
>              
> If H routes to the link for all destinations then H can reach H2.

That breaks multihoming.

>  
> > 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.
> > 
>                              (A)               (B)
> 
> I do not understand what you mean by (A).  

H2 doesn't have an on-link route for e.f.g.h/y, so it can't send packets
to H's routable address.

> In the case of (B) - we do not purport to fix the problem of
> communication between two hosts which are not using LL, on the same link
> but with different subnets.

We are creating the problem by telling the nodes not to use LL.

>    This is solved by a router.

How? If the router is up and one of the nodes has a valid netmask, while
the other one doesn't, you're out of luck. Use case: "I'll just stick my
laptop into your hub for a moment and transfer this file to you."

>   If the router
> is down, these hosts are no worse off than hosts are today.

If the nodes meet in an ad-hoc situation, both may have manually
configured routable addesses (appropriate for their home location) and
mismatching netmasks. Zeroconf should address this problem. Otherwise,
why are we here?

>   Further,
> these hosts *could determine* that they are *no longer* configured with
> a routable address (since the router is down). In this case they would
> revert to using LL.  

I suggest you try to write an algorithm for this, because I sure can't
come up with one.

Besides, trasitioning to LL doesn't even help in the above case, where
one node is visiting a foreign link. 

> If (B) is a network without a router (ever), then it would be a mistake
> to configure host H and H2 with global addresses on different subnets.

Both configurations may be valid on the home links of those hosts.
Zeroconf should solve the ad-hoc scenario, where the two hosts meet.

> The fact that legacy hosts cannot communicate with LL hosts is true:
> That is the case and has been the case since this protocol was first
> deployed.

That's fine with me, I don't expect them to.

> > 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
> 
> This is not the case if you accept that
> 
> a) LL hosts route 'to the link' for all destinations, not just LL

I don't accept that. This breaks multihoming.

> b) LL-capable hosts will route 'to the link' for LL destinations 
>    even if they have a routable address

This fine. 

> c) hosts with routable addresses but no router may eventually choose
>    to 'transition back' to using LL.

"may eventually" ?

In other words, the user "may eventually" get connectivity if he keeps
trying? Sorry, but I don't call that zero configuration networking.

>   This is no different than a host
>    choosing to configure an LL address after waking up - after it 
>    could not contact a DHCP server or a router.  This is an aggressive
>    strategy which only makes sense if the host continues to try to 
>    get configured (using DHCP, RARP or whatever), so as to not become
>    unavailable off the local link once the router doesn't respond for
>    a moment, etc.
> 

Well, the WG is not facing the transitioning problem. You yourself (with
your wg chair hat on) proposed to leave it as an implementation issue. 

Well, consider this feedback from one of those implementors: I don't
have the foggiest how to implement it in a robust way and still be
compliant with the specification. I'm finding I have to choose between
conformance and interoperability which, I'm sure you'll agree, is a
pretty strange situation.

...

> door to the transition problem.

Which we have done nothing to solve.

>   Hosts configure LL, then

That is exactly the problem. Conversely, there is no way to know under
what conditions a host will have a LL address and there is no way to
know under what conditions communication with another host will be
possible. This means that zeroconf has failed in its purpose.

> > In all other cases the nodes have mismatching on-link routes, which
> > prevent communication, even though the nodes are on the same link.
> 
> I believe assumptions a-c answer your concerns.  No doubt they raise
> others.

a) breaks multihoming
b) is ok
c) is an unsolved problem

False assumptions are a nice way to justify just about any point of
view.

	MikaL

---

From: Erik Guttman <[email-masked]>
Date: Sun, 18 May 2003 15:17:07 +0200

Mika,

I reply to a somewhat trimmed thread accumulation.

<working group chair hat off>

Mika Liljeberg wrote:
> That's unacceptable. This is not compatible with multihoming. 

I agree.  What one adds to H is a host route to H2.

H sends a service discovery or name resolution request using a LL source
address to a link local multicast address.  H2 replies to H, from a
global address, to H.  H now has an arp cache entry for H2->L2 address.
A completely reasonable thing to do at this point would be to add an
entry to the routing table for H for H2/32.

This would in no way interfere with H being multihomed unless H were
multihomed using LL on more than one interface.  In this case H2/32 may
be a collision.  We do not handle LL on multiple interfaces except as
a degenerate case which requires higher level application intervention,
as discussed in section 3.

> H2 doesn't have an on-link route for e.f.g.h/y, so it can't send packets

It can if there is a router present.  As indicated:  If there is not a
router present, eventually H and H2 may choose to use LL configuration.

There are really only two options:  Allow for constant use of LL and
intermittent use of global addresses (as they get configured), or to
transition between their use.  The WG has opted for the latter,
accepting that the transition is neither one-size-fits-all or
completely clean.  In doing so, the WG is accepting as part of the
specification what has been deployed since 1998. Codifying and
standardizing what is there, as long as it is not horribly broken
is really what this standardization effort is attempting to do.

The alternative, requiring a scoped address architecture, has been
rejected by the working group.   Efforts to express how this would
work on this group have failed.  Even with much more concentrated
work and determination, it has been difficult to achieve in the IPv6
WG.

> laptop into your hub for a moment and transfer this file to you."

Why isn't your laptop using LL?  If it were, this would work (assuming
that the laptop adds the host route for H2).

<wg chair hat on>

> mismatching netmasks. Zeroconf should address this problem. Otherwise,

I do not believe we are here to solve the problem of communication
between staticly configured machines.  That is certainly not in our
charter statement.

<wg chair hat off>

> your wg chair hat on) proposed to leave it as an implementation issue. 

Apologies - this was meant to be working group chair hat off.

> pretty strange situation.

Transition has been a discussion item on the list for some time.
Please refer back to Philip Nye's responses to discussion of LL19.

> False assumptions are a nice way to justify just about any point of

:-)

Erik

---

From: Mika Liljeberg <[email-masked]>
Date: 18 May 2003 23:01:48 +0300

Eric,

Trimming some more...

> entry to the routing table for H for H2/32.

No, that's a terrible idea. Firstly, that makes it possible for a
malicious node to completely trash someone elses routing table.
Secondly, how would you know when it is appropriate to remove the host
route? Thirdly, the zeroconf protocol should work correctly as a
standalone specification.

The proper solution, in my opinion, is to keep both LL and routable
addresses configured and use the one that is appropriate. We can still
place limitations on how those addresses are advertised. For instance, a
LLMNR responder would advertise a routable address if the query comes
from a routable address and the responder has a route back to the
sender. Otherwise, the responder would advertise its LL address. This
approach prefers routable addresses but correctly falls back on
link-locals when routables don't work.

> as discussed in section 3.

Incidentally, our "degenerate" implementation does support LLs on
multiple interfaces.

> It can if there is a router present.

This was a routerless case. Two people meet in an ad-hoc situation. They
just happen to have their routable addresses configured (as appropriate
on their home links).

>   As indicated:  If there is not a

I say again: "may eventually" is not good enough. The user will end up
doing it manually (or more likely just give up), which means that
zeroconf has failed.

> is really what this standardization effort is attempting to do.

Let's not go into that rat hole right now or we will get nothing done.
Instead, let's try to fix the connectivity problems that are plainly
there.

> Why isn't your laptop using LL?

It is using LL but it doesn't have a route for the other node's routable
address.

>   If it were, this would work (assuming

Making up new rules as we go on? Adding a host route is not part of the
specification, nor is it a good idea, for the reasons I gave above.

> between staticly configured machines.  That is certainly not in our

Then you and I read the charter differently. I want "...to allow
impromptu networks as between the devices of strangers on a train.". 
That's the use case I'm talking about and it plainly is in the charter.

	MikaL

---

From: Erik Guttman <[email-masked]>
Date: Mon, 19 May 2003 09:03:01 +0200

We need some input from the rest of the WG on this discussion.

Erik

---

From: "Philip Nye" <[email-masked]>
Date: Mon, 19 May 2003 11:06:43 +0100

I hate to come back in to this discussion.

As Eric has pointed out, the options are either to use concurrent addresses
and have a full scoped address architecture or to have a transitioning
mechanism. Both have been shown to be problematic in some cases. The IPv4
architecture was never designed for scoped addressing and while some limited
scoped addressing features (rfc1918 etc.) these have typically been
troublesome and have not caused scoping to be integrated into the IPv4
architecture.

Whichever option is taken, the issue of when to use LL and when to use
Routable addressing needs to be tackled somewhere. The concurrent use option
requires application intervention while the transition mechanism makes it
possible to do all or most of the decision making at a system level and this
is why I prefer it - it is more likely to work with legacy applications and
with applications which will continue to be written by millions of
programmers who will not be aware that IPv4 has suddenly become a scoped
architecture.

The third option is to allow either and to carefully document the pitfalls
and indicate which method is likely to work best in which environments. From
Mika's descriptions of the architecture he is working with, I can see that a
concurrent use mechanism can work well for him. I have not been fully
convinced that the transition mechanism cannot work for him too - some of
his objections appear almost deliberately obtuse - but I can see that making
it work may require some fairly liberal interpretation of terms like
"configured with a routable address" and could be less "elegant".

However, this third option would need careful examination to establish that
it did not introduce it's own interoperability problems between hosts using
different mechanisms. It also needs drafting of some fairly extensive text
changes. I do not have the energy or motivation to do any of this and am not
even sure that it is possible. If somebody offered a proposal I would
consider it. Meanwhile, I agree with Eric's analysis and with his conclusion
of rough consensus - the transitioning mechanism is the least worst option.

Philip

----- Original Message -----
From: "Erik Guttman" <[email-masked]>
To: <[email-masked]>
Cc: "Mika Liljeberg" <[email-masked]>
Sent: Monday, May 19, 2003 8:03 AM
Subject: Re: Final word - ACCEPT [LL23] Don't configure needless LL
addresses

---

From: John Schnizlein <[email-masked]>
Date: Mon, 19 May 2003 06:55:17 -0400

>We need some input from the rest of the WG on this discussion.

Why is more input needed on an issue that was resolved using the
formal process? Does just one person continuing debate after the
rough consensus was done require rehash of the whole thing?

John

---

From: "John C. Welch" <[email-masked]>
Date: Mon, 19 May 2003 07:10:36 -0400

> We need some input from the rest of the WG on this discussion.

I agree with Mika, but quite frankly, got tired of arguing it. I think that
he's right, for the right reasons, and that his point about static addresses
is almost the same as mine.

But anymore, my attitude is, y'all just do what you want, I've no longer the
energy, or the motivation to be the voice of the people who will want to sit
in an airport, or on a train, or <whereever>, and just be able to use this.

I've learned the hard way exactly where they fit in.

john

-- 
John C. Welch
Consultant III
Office Computing Practice (IS)
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Ralph Droms <[email-masked]>
Date: Mon, 19 May 2003 08:39:24 -0400

My input is that we accepted LL23 through the agreed upon process.  The WG should move on and apply its energies to other remaining issues...

- Ralph

---

From: Mika Liljeberg <[email-masked]>
Date: 19 May 2003 23:22:44 +0300

I could live with the third option.

I think we all recognize that both points of view have valid concerns.
We're trying to achieve the best possible user experience but clearly we
are thinking about different use cases, and hence we have different
requirements.

Given that the choice depends on the use case, the rational approach
would be to recommend that vendors put in a configuration switch and
leave the decision up to the user (or the network manager). Only they
can know whether the concurrent use mode or the transition mode suits
the user's needs best.

I have no problem with recommending that the default mode should be the
transition mode, unless it is clear that the primary use cases for the
device benefit from the concurrent mode. I would be glad to propose some
text if people are willing to agree to this.

Can we reach a compromise this way?

	MikaL