Subject: WG Action - 1 week to discuss [LL32] Multihoming problems not solved but that is OK

From: Erik Guttman <[email-masked]>
Date: Mon, 26 May 2003 11:52:59 +0200

Folks,

Please discuss LL32 from now till May 3 (leaving an extra day since May
26 is a holiday in the US and May 29 is a holiday in southern Europe).
Please send any comments to the zeroconf mailing list regarding
replacing section 3 entirely, as described in LL32.

Since I have received support from many WG members for this text
already, if the disposition is to accept the text.  Please speak up and
help us to clarify, improve or if necessary reject this text.  If there
are no comments, this issue will be ACCEPTED.

Thanks,

Erik Guttman.

ps. apologies if this is a duplicate message

---

From: Robert Elz <[email-masked]>
Date: Tue, 27 May 2003 14:50:19 +0700

Date:        Mon, 26 May 2003 11:52:59 +0200
    From:        Erik Guttman <[email-masked]>
    Message-ID:  <[email-masked]>

  | Please discuss LL32 from now till May 3 (leaving an extra day since May
  | 26 is a holiday in the US and May 29 is a holiday in southern Europe).

Don't we also get an extra day because May 30 is a new moon?
(And I suspect that you meant June 3 anyway...)

  | Please send any comments to the zeroconf mailing list regarding
  | replacing section 3 entirely, as described in LL32.

The general thrust seems fine to me, just a few editorial nits ...

	Implementors must think through
	these issues before implementing the protocol specified in this document
	which will have more than one active interface.

Insert "on a system" before "which".   Perhaps change "will" to "might" (or 
"may")  (systems with plug in slots to which new interfaces can be
connected are a problem, even if they won't necessarily have anything
plugged in).

	With sufficient experience, it is hoped that
	specifications will emerge explaining how to overcome scoped address
	multihoming problems.

I'd delete that - by the time this could happen, what is really
hoped is that IPv4 will be obsolete.   IPv6 already has a standardised
API to handle this problem, so applications can cope there.

But even if IPv4 is still around, getting all the necessary experience
will mean multiple (probably) different solutions tried by different
people - at that stage, attempting to pick one of them and converge upon
it really won't be worth the bother.

	Another possibility is to determine routes by expressing destinations
	with a higher layer, unambiguous identifier. That is, if addresses are
	not exposed to applications at all, routing decisions can be made by the
	IPv4 stack without having to resort to routing decisions based on
	ambiguous addresses.

I think I understand the motivation for that (where it comes from), but
actually making anything like that work would be a major undertaking,
and would have major ramifications to the whole IP stack (this is a bigger
change than IPv6...)

The simple "use something else at the app layer" implementation just
translates the something else into addresses for use over the wire,
(whether in the app, in the stack, or somewhere between doesn't matter).
The potentially ambiguous addresses remain - if the same address exists
at multiple places, there's still no way at the routing or packet forwarding
level to know which was intended (without tagging the addresses in some way,
which was the previous possible solution in the supplied text).   Note
here that it is necessary to deal with things like DNS servers (any UDP
application) which is responding to packets received - there is no other
identifier, just the address.   The app may receive packets from the same
address (over different interfaces of course), and then reply to them
in either order.   Handling this all gets very messy (without tagging the
addresses - with address tags, so that in the "I came from here", "here"
isn't just a 32 bit address and 16 bit port, but contains more).

I know there's a desire to express at least two different ways by which
the ambiguous address problem might be overcome, but I don't think
suggesting this one makes sense - and if that means leaving just one
method even mentioned, then so be it.   Delete all this reference to
using higher level names instead of addresses as the application API.

	3.3. Interoperation with Legacy Hosts

I'm not sure that most of this section really belongs in section 3,
it isn't really discussing the same issue is it?   Nevermind.

	HOST1 will route to destinations in 169.252/16 to i2, sending
	directly to the destination.

169.254/16 ??

	One solution to this problem is for a host to attempt to reach any host
	locally (using ARP) for which it receives an unreachable ICMP error

This really has nothing at all to do with LL addresses, does it?
That is, the fact that HOST1 is using LL addresses on i2 is irrelevant
to this problem, isn't it?

It would certainly be nice if all the world's routing problems could
magically be solved by the introduction of LL addresses, but I don't
think that's going to happen.

The problem here is the existence of a legacy host (HOST2) using an
inappropriate address for the link to which it is connected.   There's
nothing new about this, and nothing that LL should necessarily be
doing to fix it.   It is kind of nice that in a few scenarios, hosts
that are LL aware will actually be able to figure out what is probably
going on here, and make it all work.

But we shouldn't be expecting that, nor encouraging anyone to go out of
their way to try and make LL addresses perform more magic than that
which they're intended to perform.   We don't have to fix every problem.

I think I'd just delete the whole of the (proposed new) section 3.3.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 27 May 2003 23:12:50 +0300

Robert,

> 	3.3. Interoperation with Legacy Hosts
[...]
> doing to fix it. 

The section is incorrectly named. The problem, as described, occurs
because HOST2 is LL-compliant and has a routable address.

> I think I'd just delete the whole of the (proposed new) section 3.3.

Disagree.

	MikaL

---

From: Robert Elz <[email-masked]>
Date: Wed, 28 May 2003 18:03:59 +0700

Date:        27 May 2003 23:12:50 +0300
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1054066367.5544.205.camel@devil>

  | The section is incorrectly named. The problem, as described, occurs
  | because HOST2 is LL-compliant and has a routable address.

No, the same problem occurs of HOST2 isn't LL compliant.  It is that
it has a routable address that is the problem.

If HOST2 were LL compliant, then given its routable address is non-functional
it ought to disable it, and give itself a LL address, in which case
everything would work OK (well, HOST2 would be able to contact HOST1 anyway).

This, in combination with the section title ("Legacy Hosts") (which I know
you think is the wrong title, but is what is there) makes me suspect that
this stuff is really intended to be about HOST1 (LL compliant) talking
to HOST2 (not LL compliant).   That's where the real problem for the LL
spec arises in the multi-homed case, as there's nothing that can be done
to change HOST2's behaviour, and no reasonable way that HOST1's forwarding
table can be built so that a route to HOST2's address is out i2.

Without the multi-homing, HOST1 could assume that "everything" is out i2,
and just ARP there.   So, in the single interface case, a solution is
possible - which is why all of this is being dealt with in the "problems
of multi homing" section - but the reason problem here is the legacy
host using an address which can't really work (certainly in the diagram
there's no way HOST2 could ever talk with anything other than HOST1).

That's what I meant about not attempting to make LL solve all the world's
problems - HOST2 (being a legacy host) simply needs to be properly
configured (in this case, that may mean manually configured with a LL
address) for the net to which it is connected.  That's the way it has
always been, and I personally see no problem with not fixing problems for
hosts that haven't implemented the spec.

kre

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 28 May 2003 16:20:23 +0100

> From: "Robert Elz" <[email-masked]>
>
> inappropriate address for the link to which it is connected.

Not necessarily. Link2 could be a routable link which HOST2 is fully and
properly configured for. It could be that HOST1 has just assigned an LL
address there because it received no DHCP response - exactly the sort of
ad-hoc connection which many here have been pressing for - perhaps HOST2 is
the printer which HOST1 just wants to print a quick page on...

I agree with Mika that this problem is not to do with whether HOST2 is
"legacy" or not - just that it has a non-LL address.

Philip

---

From: Erik Guttman <[email-masked]>
Date: Wed, 28 May 2003 19:47:15 +0200

> "legacy" or not - just that it has a non-LL address.

The section title was originally called

   "Interoperation with hosts that support link-local which currently
    don't have a link-local address"

but that was way too long and doesn't really get at what this section is 
about.

   "Interoperation with Legacy Hosts"

is clearly wrong.  How about

   "Reaching link-local savvy routable address configured neighbors"

Erik