Subject: Re: [LL12] [LL20] and a possible solution

From: Aidan Williams <[email-masked]>
Date: Wed, 07 May 2003 15:47:47 +1000

Scott Lawrence wrote:
> I think the complexity cost is not justified by the frequency (low)
> and severity (not very) of the problem.
> 

Basically, I agree with your assessment.

Reading the thread another option occurred to me, however I'm
not sure whether it would work.

Configure an LL address quickly, but mark it as tentative.
It remains tentative for some long time (e.g. 60 seconds),
or until we can receive some indication that our packets
can be received.  A non-destructive way of getting this
indication is to perform ARP probes for addresses we would
like to communicate with using LL rather than ARPing for
them directly with our tentative address.

Whilst the LL address is "tentative", we change the way that
we ARP for destinations.  Rather than ARP directly for a
destination using our LL address (thus polluting the ARP
cahce), we probe for every destinations that we are trying
to communicate with.  If we get an ARP probe response we
know our packets are being received, so we can DAD the LL
address and begin communicating and perform normal ARPs.

- aidan

---

From: Scott Lawrence <[email-masked]>
Date: 07 May 2003 07:04:05 -0400

Aidan Williams <[email-masked]> writes:

> cahce)

But that's solving a problem (introducing conflicts into ARP caches),
only when it doesn't exist - if your packets are not being received,
then no one will get them to pollute the cache either.

In some sense, all zeroconf addresses are "tentative" - if we detect a
collision, then we give them up and get a new one anyway.

-- 
Scott Lawrence        
  Actively seeking work 
  http://skrb.org/scott/
  [ <[email-masked]> is deprecated ]

---

From: Mika Liljeberg <[email-masked]>
Date: 07 May 2003 19:54:59 +0300

> Basically, I agree with your assessment.

So do I.

> them directly with our tentative address.

I proposed a similar thing but I abandoned this line of thinking when I
realized that there is a chicken egg problem with LLMNR. You probably
need something like LLMNR to get the first destination address. So the
question is, what do you do if the first packet has  a multicast
destination? You can't probe. You could let the packet go on the link
and hope for a response but then you have to decide if you allow a
tentative address as source address.

Assuming the switches aren't a big issue, I think Christian's proposal
about the listening period is good. Given that, I don't see any reason
to mandate any particular timeout values, though. Just require a random
initial period, suggest the number of retransmissions, and allow
implementations to scale the timeouts as appropriate for that particular
link.

	MikaL

---

From: Aidan Williams <[email-masked]>
Date: Fri, 09 May 2003 11:17:20 +1000

> then no one will get them to pollute the cache either.

The problem that this is trying to solve is where a node
using IPv4-LL is on a switch port that is blocked waiting
for spanning tree timers.  It does DAD on an address and
it thinks it is unique.  Subsequently, the switch port starts
to forward.  When it ARPs for a destination (any destination)
third party hosts will see a conflicting IP address/MAC mapping
in the broadcast ARP message.  Doing a probe (ie setting the
source IP address to 0) prevents the cache pollution.

> collision, then we give them up and get a new one anyway.

Yes, but we might have taken out some other hosts on the
network when we could have avoided doing so.
I also think that it is a common case.

- aidan

---

From: Aidan Williams <[email-masked]>
Date: Fri, 09 May 2003 11:55:52 +1000

> tentative address as source address.

That's a good point.  Using the tentative address just relies
on the low probability of two nodes picking the same address,
hence we don't seem to gain much.

- aidan