Subject: Re: New Issue [LL32] Multihoming problems not solved but that is OK

From: Stuart Cheshire <[email-masked]>
Date: Wed, 4 Jun 2003 14:32:38 -0700

>Since the host transitioning to the use of a routable
>address will not advertise scoped address information,
>the scoped address issues described in Section 3.1 will apply

I don't understand that sentence. What does "advertise scoped address 
information" mean? Does it mean "advertise information that includes 
scoped addresses"? If the host "will not advertise scoped addresses", 
then there's no scoped address problem, is there? I think there's a 
missing negation somewhere.

>A host which
>conforms to this specification will know that a Link-Local IPv4
>destination must be reached by forwarding to the destination, not to a
>router, even if the host is sending from a routable address.

"...must be reached by sending directly to the destination..."

(The word "forwarding" implies a middleman who is neither the sender nor 
the recipient. If you say that someone forwarded an email to you, does 
that imply that it's an email they wrote themselves and sent directly to 
you, or one they received from someone else and then forwarded to you?)

>A host with a Link-Local IPv4 address may send to a destination which
>does not have a Link-Local IPv4 address. If the host is not multihomed,
>the procedure is simple and unambiguous: Using ARP and forwarding
>directly to on-link destinations is the default route. If the host is
>multihomed, however, the routing policy is more complex, especially if
>one of the interfaces is configured with a routable address and the
>default route is (sensibly) directed at a router accessible through that
>interface. The following example illustrates this problem and provides
>a common solution to it.

As one of the people who argued for the "ARP for everything" behaviour, 
I'm willing to make a concession here. When a device has a link-local 
address, and only a link-local address, and no other information, then 
"ARP for everything" is the only reasonable thing to do. The moment the 
device has any kind of explicit routing configuration (e.g. manually, or 
from a DHCP server) that supersedes the "ARP for everything" rule (the 
"Always ARP for 169.254/16" rule remains in force).

>Care must be taken if a multihomed host can support more than one
>interface onto the same link, all of which will support Link-Local
>autoconfiguration. If these interfaces attempt to allocate the same
>address, they will defend the host against itself - causing the claiming
>algorithm to fail. The simplest solution to this problem is to run the
>algorithm independently on each interface configured with Link-Local
>IPv4 addresses.

The phrase "run the algorithm independently on each interface" may seem a 
simple thing to say, but when you have Ethernet and wireless, and 
(unknown to you) the wireless base station you're talking to is bridged 
onto the same Ethernet, the interfaces aren't independent any more, even 
if you wish they were. Figure 1 "(Incorrect) Ambiguous Re-Use of Address 
Q" in draft-07 described the difficulty when another host has an IP 
address that's the same as one of your own IP addresses.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

---

From: Robert Elz <[email-masked]>
Date: Thu, 05 Jun 2003 16:50:54 +0700

Date:        Wed, 4 Jun 2003 14:32:38 -0700
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | The phrase "run the algorithm independently on each interface" may seem a 
  | simple thing to say, but when you have Ethernet and wireless, and 
  | (unknown to you) the wireless base station you're talking to is bridged 
  | onto the same Ethernet, the interfaces aren't independent any more, even 
  | if you wish they were.

All that is true, but this describes exactly the case where the "run the
algorithm independently on each interface" is required.   That is, on
the wireless, and on the ethernet, you pick a random address (different
random addresses 99.99% of the times) and probe that one.   Each interface
sees the other probe (because of the bridging) but they're for different
addresses, so ignored.

Maybe there's just a misunderstanding of what the text is attempting to
say there?

Or are you still believing that a host should pick one LL address, and
attempt to use the same one on every inteface?   We discarded that notion
ages ago, as I recall it.

  | Figure 1 "(Incorrect) Ambiguous Re-Use of Address 
  | Q" in draft-07 described the difficulty when another host has an IP 
  | address that's the same as one of your own IP addresses.

It attempted to describe a difficulty, but not one that ever made any
sense to me.

kre