Subject: Re: LL32 Multihoming

From: Stuart Cheshire <[email-masked]>
Date: Tue, 1 Jul 2003 12:18:13 -0700

>I am fine with adding text to 3.4 to discuss how to avoid auto immune
>problems in this case.   I even drafted up a version of his text to
>send out.  That is, I fully support Stuart's effort to add clarifying
>text for LL32.
>
>But then I looked closer at the preceding text and saw his point 2b.
>We can't suggest that without reopening LL14 and LL15.  That was the 
>concern I brought up.

I think we can declare agreement on this.

The behaviour I described as 2(b) is a private internal implementation 
decision appropriate for a certain project, and no more needs to be said 
about that here.

The important point, on which I think we agree, is that an auto-immune 
packet storm is bad.

Draft-08 already contains text such as the following:

   At any time, if a host receives an ARP packet (request *or*
   reply) where the 'sender IP address' is the host's own IP
   address, but the 'sender hardware address' does not match
   any of the host's own interface addresses, then this is a
   conflicting ARP packet, indicating an address collision.

This is good. There is no need to change any of this.

My specific complaint was about the overly simplistic language in the 
"Unintentional Autoimmunity" section which says, "The simplest solution 
to this problem is to run the algorithm independently on each interface."

There are two problems with this:

1. This new addition contradicts existing text elsewhere in the document, 
such as the section I quoted, where interfaces are not treated 
independently.

2. It is pure unsubstantiated speculation. No *actual* implementer has 
stated that they have implemented IPv4LL independently on multiple 
interfaces, or whether this was indeed "the simplest solution", or 
whether there were any unanticipated problems when those interfaces were 
then connected to the same physical link.

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

---

From: Robert Elz <[email-masked]>
Date: Wed, 02 Jul 2003 05:16:11 +0700

Date:        Tue, 1 Jul 2003 12:18:13 -0700
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | 1. This new addition contradicts existing text elsewhere in the document, 
  | such as the section I quoted, where interfaces are not treated 
  | independently.

No it doesn't.   Running the algorithm independently means just that,
it doesn't change what the algorithm is, and if that means checking all
MAC addresses, then that's part of it (part of each independent execution
of the algorithm).

kre

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 2 Jul 2003 11:47:45 +0100

> From: "Robert Elz" <[email-masked]>
>

   "At any time, if a host receives an ARP packet (request *or*
   reply) where the 'sender IP address' is the host's own IP
   address, but the 'sender hardware address' does not match
   any of the host's own interface addresses, then this is a
   conflicting ARP packet, indicating an address collision."

The use of "any" implies that two interfaces on the same host and connected
to the same link would not recognise each others ARPs as conflicts. This is
not independence. Whether this is resolved in other (internal) ways or
causes trouble is very much implementation dependent.

The use of "host's own IP address" is also ambiguous when the host plainly
has multiple IP addresses. For independence, each interface-IP address pair
needs to be treated independently.

It is already clear that LL addressing will not work on multiple interfaces
on the same host unless traffic is closely coupled with specific interfaces
in ways which common APIs have tried to avoid. This is another manifestation
of that effect.

Philip

---

From: Robert Elz <[email-masked]>
Date: Wed, 02 Jul 2003 18:09:30 +0700

Date:        Wed, 2 Jul 2003 11:47:45 +0100
    From:        "Philip Nye" <[email-masked]>
    Message-ID:  <002f01c34087$60068af0$131010ac@aldebaran>

  | The use of "any" implies that two interfaces on the same host and connected
  | to the same link would not recognise each others ARPs as conflicts. This is
  | not independence.

No, but nor does anything claim that the interfaces are independent.

What it says is to run the algorithm independently on each interface.
That is: the order in which the two happen (including in parallel)
should be irrelevant, and the results of running the algorithm on the two
should in no way depend upon each other.   That's all it means.

It in no way precludes the algorithm (which is to be run twice, or more,
independently) from examining all kinds of information about anything
that happens to be in the system, including all of its interfaces.

  | The use of "host's own IP address" is also ambiguous when the host plainly
  | has multiple IP addresses.

Not really ambiguous, but perhaps that could be extended to say "any of the
host's IP addresses on the interface".    It is OK as it is, it doesn't
actually say that there can only be one - eg: if I own 4 cars, each one
of those cars "my own car", even though it isn't my only car.

  | For independence, each interface-IP address pair
  | needs to be treated independently.

No-one wants independence, all that is wanted is that the algorithm be
run independently.   Read the text...

  | It is already clear that LL addressing will not work on multiple interfaces
  | on the same host unless traffic is closely coupled with specific interfaces
  | in ways which common APIs have tried to avoid. This is another manifestation
  | of that effect.

No, it isn't.   This has nothing whatever to do with the APIs.   Assigning
addresses on multiple interfaces (which is what this is concerned with)
is trivial.   It is only using the things once assigned where difficulties
start to occur, and only because the interface between the stack and the
application provides no easy way to be selective about which link is
intended (the IPv6 API doesn't have such issues).

kre

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 2 Jul 2003 12:47:38 +0100

> should in no way depend upon each other.   That's all it means.

My issue is this:

If I see a claim for an IP address I already have, then I should recognise
it as a conflict if and only if the claim appears on the interface to which
I have assigned that address.

The fact that the hardware address for a conflicting claim matches one of my
other interfaces is spurious. It does however tell me that that other
interface is connected to the same link and allows me to resolve the
conflict internally if I wish (I could also avoid the conflict internally
before it ever occurs) but this is an implementation issue which need not
appear in the document.

On the other hand, if the interfaces happen to be on different links then
seeing a claim for an address I already have on another interface, should
not be seen as a conflict - once again irrespective of hardware address.

---

From: Mark Yang <[email-masked]>
Date: Fri, 11 Jul 2003 17:01:56 -0700

Hi,
    This looks like a very simple question,  but I don't know where do 
ask so I post it here.
I start my Mac, my "network" setting shows I have IP "10.1.1.157" since 
I am using DHCP,
I created a socket, try to connect to a linklocal addr say 
"169.254.80.220". now I find i am using IP "10.1.1.157" to connect 
obviously this is not what I want.

    Question is how do I create a socket on mac  such that the packet i 
send out shows my IP  LL addr?
    Thanks
mark

On Wednesday, July 2, 2003, at 04:47 AM, Philip Nye wrote:

>>   | to the same link would not recognise each others ARPs as 
>> conflicts.
> This is
>>   | not independence.
>>

---

From: Robert Elz <[email-masked]>
Date: Sat, 12 Jul 2003 19:25:33 +0700

Date:        Fri, 11 Jul 2003 17:01:56 -0700
    From:        Mark Yang <[email-masked]>
    Message-ID:  <[email-masked]>

  | I created a socket, try to connect to a linklocal addr say 
  | "169.254.80.220". now I find i am using IP "10.1.1.157" to connect 
  | obviously this is not what I want.

Why not?   This should work just fine.

  |     Question is how do I create a socket on mac  such that the packet i 
  | send out shows my IP  LL addr?

I can't speak to what the mac implementation does, but what makes you
believe that your node actually has a LL addr?   Why do you believe
that you need one?

The current plan for LL addresses is that they should work exactly as
your are describing - you get one only if you don't get some other
kind of address, and never need one (unless no other address is available).

kre