Subject: LL19

From: "Philip Nye" <[email-masked]>
Date: Mon, 10 Feb 2003 16:44:24 -0000

I oppose LL 19

If we were to mandate that in order to talk to a LL host, you need a LL
address yourself, then we get back to the case where hosts run both
addresses side by side as a matter of course.

Unless we see workable suggestions for how to resolve the consequent issues
of knowing which address to select in this case, I cannot support this.

See previous communications on referrals (among others) for descriptions of
these issues.

Philip

---

From: Mika Liljeberg <[email-masked]>
Date: 10 Feb 2003 22:13:46 +0200

> addresses side by side as a matter of course.

That's exactly what should be required:

1) Nodes participating in a routed network must have a routable address.

> of knowing which address to select in this case, I cannot support this.

2) The scopes of source and destination addresses must match. 

> See previous communications on referrals (among others) for descriptions of

Referral is a second order problem. The current rules don't even
satisfactorily solve the first order problem of connectivity between
v4LL compliant nodes and non-v4LL compliant nodes, as shown by LL19. 

If rule 1) is required, the referral problem shouldn't even come up.

Expecting v4LL-only nodes to function correctly in a routed network is
plainly not realistic. Specifying rules that  *sometimes* make it work
just sends the wrong message.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Feb 2003 15:40:26 -0500

> 2) The scopes of source and destination addresses must match. 

No.  There's no reason for it, and it just serves to hamper
interoperability.

---

From: Mika Liljeberg <[email-masked]>
Date: 10 Feb 2003 22:55:13 +0200

> No.  There's no reason for it, and it just serves to hamper

I don't know about you but I prefer an immediate failure to a lengthy
timeout.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Feb 2003 16:08:43 -0500

> I don't know about you but I prefer an immediate failure to a lengthy

You can't avoid the possibility of a timeout.  If the host you're trying
to reach isn't there you get a timeout no matter whether you use an LL
source addr or a routable source addr.

Keith

---

From: Mika Liljeberg <[email-masked]>
Date: 10 Feb 2003 23:23:59 +0200

> source addr or a routable source addr.

Of course. However, I'm talking about the case where the destination
*is* there. The normal case.

	MikaL

---

From: "Philip Nye" <[email-masked]>
Date: Mon, 10 Feb 2003 21:33:13 -0000

Mika,

> 2) The scopes of source and destination addresses must match.

The current draft (v7) effectively mandates what you are proposing - that
all compliant hosts maintain a LL address alongside any routable one they
might have - but the WG seems to have moved away from that position.

By itself your suggestion causes broken applications because choice of
address is not just a low level choice of the IP stack. Applications use IP
addresses to identify peers, they obtain those addresses by a wide variety
of means and might or might not get hold of either the LL or the routable
address, and worst of all they pass those identifiers to other peers whose
scope may be different.

Once at application level, most IPv4 applications are totally unaware of
scoped addresses and there is no mechanism to establish scope even if they
weren't.

Solve these issues and your suggestions will carry more weight. See:
http://www.merit.edu/mail.archives/zeroconf/2003-02/msg00051.html

> just sends the wrong message.

"function correctly" is rather vague. They will exist on the same networks
and maximising interoperability is the best we can hope for. Making their
use a transitional case seems to help.

Philip

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Feb 2003 16:35:38 -0500

> > You can't avoid the possibility of a timeout.  If the host you're
> > trying to reach isn't there you get a timeout no matter whether you
> > use an LL source addr or a routable source addr.
> 

why would this result in a timeout?

---

From: Mika Liljeberg <[email-masked]>
Date: 10 Feb 2003 23:41:46 +0200

> why would this result in a timeout?

Because a non-v4LL compliant node may not be able to respond. LL19
problem description.

	MikaL

---

From: Mika Liljeberg <[email-masked]>
Date: 11 Feb 2003 00:01:37 +0200

On Mon, 2003-02-10 at 23:33, Philip Nye wrote:
> might have

I like that.

>  - but the WG seems to have moved away from that position.

That worries me.

> address, and worst of all they pass those identifiers to other peers whose

No matter how many times an address is passed between peers via this
variety of means, the origin of the address ultimately boils down to one
of two cases:
1) directly from the user (shoot in the foot case)
2) from a name resolution process (solvable: return routables first)

> "function correctly" is rather vague.

To be less vague, I believe failures are inevitable. That being the
case, I would like the failures to be immediate and obvious, rather than
unpredictable and usually after a lengthy timeout.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Feb 2003 19:31:25 -0500

> 2) from a name resolution process (solvable: return routables first)

you're simply wrong about this. 
for instance, apps can use the source address from a previous transaction.
or they can do referrals which don't involve name resolution at all.

Keith

---

From: Mika Liljeberg <[email-masked]>
Date: 11 Feb 2003 09:24:09 +0200

> you're simply wrong about this. 

I don't think so.

> for instance, apps can use the source address from a previous transaction.

You forget the rule I'm proposing: source and destination address scopes
must match.

Thus, any result from source address selection is LL only if the
destination was LL as well. Now ask yourself where that destination
address originally came from.

> or they can do referrals which don't involve name resolution at all.

Referrals just pass addresses around. The question is, where do these
address originate?

A v4LL address can only be introduced to the application session if

a) v4LL-only nodes are allowed to participate. This is a concious risk
and an occasion failure is to be expected. An immediate one (no route)
is always preferrable to a timeout.

b) Manually configured LL address. That's a human error.

	MikaL

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 11 Feb 2003 09:28:48 -0000

> 2) from a name resolution process (solvable: return routables first)

Or from SLP, or from an HTML link, or from SSDP, or from NetBios, or from
CUPS or from a hundred and one other discovery protocols.

You might class all these as "name resolution processes" but how do you
ensure that they all "return routables first"?

Add that to the fact that routable and LL addresses are not acquired
simultaneously but exist at different (overlapping) times, and that most of
these discovery methods hang on to identifiers for some period and do not
expect to reconfirm addresses before they use them.

What we haven't seen here is a hard proposal for how "return routables
first" really works to resolve these issues without requiring rewrites of
large numbers of applications or intermediate protocols such as those above.
I would love to see such a proposal since it would of great benefit to
IPv4LL whether or not we accept LL19.

Philip

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Feb 2003 08:20:40 -0500

On 11 Feb 2003 09:24:09 +0200

> You forget the rule I'm proposing: source and destination address scopes

nope, the app can use that source address in a referral to another host.
the other host has no idea whether its scope matches that address.

> Referrals just pass addresses around. The question is, where do these

from various places.

> b) Manually configured LL address. That's a human error.

v4LL-only nodes should not be permitted.  however there will be nodes that
for the time being only have v4LL addresses talking to nodes that have
routable addresses - perhaps because the DHCP server was down for a time,
perhaps because the nodes with routable addresses had them manually configured
(correctly), perhaps because some hosts on the network have multiple
interfaces.

---

From: Mika Liljeberg <[email-masked]>
Date: 11 Feb 2003 21:41:14 +0200

Keith, Philip,

> > Referrals just pass addresses around. The question is, where do these

Neither of you is following the logic. Think recursively.

What I'm trying to say is that you should, as a mental exercise, track
the path of a v4LL address through its referral chain, whatever it may
be, back to its place origin. The place of origin can only be the node
that generated that address. This is important: the origin is a node
that is governed by this specification.

Why then, if it is participating in a routed network, did it give out
its v4LL address? If it was forced to do that it must be a v4LL-only
node, otherwise it would have given out its routable address. This
observation is in conflict with my assertion that all nodes
participating in a routed network should acquire a routable address.

What I'm trying to say is that the rules I'm proposing are internally
consistent, unless you choose to relax one them. Of course, you've
already made up your minds to do that, so it doesn't seem likely that I
will convince you otherwise.

As for how to "return routables first", that is an implementation issue
but we can give some guidance, since we've already established that the
place of origin is a node governed by this specification. A system
implementing v4LL addressing should have APIs that consisntently work
this way. One example of this would be to put LLMNR and normal DNS
resolution under a unified API and return routable addresses first.

I'm well aware that the above cannot be done in the general case and
that there are legacy issues that make it unfeasible in some cases.
However, I feel that it can be done in the common case, which is pretty
good. The rules proposed by LL19 ensure that even if a v4LL address is
propagated beyond it's scope, the failure mode is usually such that an
immediate "destination unreachable" error is generated. This is not the
case if direct communication between v4LL addresses and routable is
allowed.

So, I'm not pretending to solve anything in the general case. Neither is
anyone else. I'm simply proposing that these stricter rules would result
in:
- clarity and simplicity of implementation
- more obvious failure modes

	MikaL

P.S.	I'm not going to be expounding this any more. It's obvious
	that I'm beating a dead horse and that the people who got
	to her first had far bigger sticks than I.

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Feb 2003 14:43:48 -0500

> > > Referrals just pass addresses around. The question is, where do
> > > these address originate?
> > 
> > from various places.
> 

no it is not.  the origin is some application that might or might not be
aware of this specification at all.  we cannot retroactively impose
requirements on existing applications, and I would strongly object to
trying to impose such requirements on new applications for the sake of
being able to use LL source addresses when they're not needed.

since your major premise is false, the rest of your argument does not
hold.

isn't this horse dead yet?

Keith

---

From: Mika Liljeberg <[email-masked]>
Date: 11 Feb 2003 22:02:50 +0200

> being able to use LL source addresses when they're not needed.

I addressed this in the part you didn't read.

> isn't this horse dead yet?

Last word.

There, I said it.

	MikaL

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 11 Feb 2003 22:45:01 -0000

> that is governed by this specification.

You are right to this extent: it all starts with some process on the node
which uses a LL address interrogating some other process or structure in the
same node to say "what is my IP address" (I say *probably* because it is
also possible that another local host has inferred the address from ARP
information) - to that extent, the node is in control.

But so what? Host A then communicates with host B which then knows A's
address and vice versa. One of these hosts might implement some sort of
service discovery or name cache, it could be running a collaborative
application or putting links on web pages or something. Sooner or later
(probably sooner) somebody who doesn't understand the special rules will get
hold of the address, or it will get passed off the link or all sorts of
other horrible things will happen. In general this is all highly desirable
and what makes IP so attractive.

The way to minimise the damage is simply to minimise the duration and number
of hosts around which use LL addresses when the link is not isolated. If one
host on a link has only a LL address then under your rule all the others
will need one too. Without LL19 then there is only the one address around to
foul things up.

Coexistence of LL and routable addresses on a routed network is unavoidable,
but the spec should do what it can to make it a transitional case.

Philip