Subject: LL24: Weaken the PRN requirement

From: Bernard Aboba <[email-masked]>
Date: Thu, 27 Feb 2003 04:49:55 -0800 (PST)

I would urge this one be rejected. The issue is not whether a single
address conflict can be detected. The issue is whether two conflicting
hosts could then move to another conflicting address. Weakening the PRN
requirement would make this more likely.

---

From: "Subrata Goswami" <[email-masked]>
Date: Thu, 27 Feb 2003 08:43:15 -0800

Actually I am trying to say that if there is a way for a LL nodes to
determine
the  other LL nodes' LLv4 addresses, then it does not need to use the
PRN. An 
alternative algorithm is provided below - although it is somewhat
extreme it 
would work.

A node can start at 169.254.0.1 and iterate to 169.254.255.254 picking
up 
each LLv4 address and ARP'ing for conflict. The node can pick the first
LLv4 address it does not get an ARP reply back.

Subrata

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Thursday, February 27, 2003 4:50 AM
> To: [email-masked]
> Subject: LL24: Weaken the PRN requirement
> 
> 
> I would urge this one be rejected. The issue is not whether a 
> single address conflict can be detected. The issue is whether 
> two conflicting hosts could then move to another conflicting 
> address. Weakening the PRN requirement would make this more likely.
>

---

From: Thomas Narten <[email-masked]>
Date: Thu, 27 Feb 2003 12:58:04 -0500

Subrata,

What problem are you trying to fix with your issue and suggestion?

Generating PRNs is not hard and works well in practice. The current
wording doesn't seem to be a problem to implement. Why is this not a
reasonable recommendation?

Thomas

---

From: "s. goswami" <[email-masked]>
Date: Thu, 27 Feb 2003 18:36:23 -0500 (EST)

Hi Thomas, I am not saying do not use PRN. I would like
the selection algorithm to be kept open for other ones beside
PRN. The PRN SHOULD be the recommended way to determine the LLv4 address,
but if the LL node chooses so it can use something else. I have given
example of an iterative algorithm in my previous email - I would
like the draft to not preclude such solutions.

Subrata

---

From: Robert Elz <[email-masked]>
Date: Fri, 28 Feb 2003 17:41:34 +0700

Date:        Thu, 27 Feb 2003 08:43:15 -0800
    From:        "Subrata Goswami" <[email-masked]>
    Message-ID:  <004b01c2de7f$537da030$1bc0140a@SGOSWAMIPCL>

  | Actually I am trying to say that if there is a way for a LL nodes to
  | determine the  other LL nodes' LLv4 addresses, then it does not need
  | to use the PRN.

Even given that there was a way, this doesn't work, as we want 20 or 30
(or 200 or 300) nodes all running the algorithm at the same time to start
at (mostly) different values - if they all somehow just knew what LL
addresses were assigned currently, and just picked some unallocated one
algorithmically, then they're all likely to pick the same one (given that
most of them will be running the same code on the same kind of processor).

When that happens, at most one of them can succeed to obtain that address,
after which they all have to start again, now knowing (perhaps) one more
address that has been allocated, and all allocating the next one in their
sequence.

This just doesn't work.

What's more ..

  | An alternative algorithm is provided below - although it is somewhat
  | extreme it would work.

Work in the sense that it would find out what is in use, currently,
perhaps yes.   Work in that the network would survive such an attack
I doubt ...  Up to 64K broadcast packets from every host as it starts
is not something that you'd want to see happening on your net.

Using random numbers avoids these problems (given a big enough range,
which we have here).   It is a common technique, and works well.
What's more, it is enormously cheaper for the node, and the net, than
attempting to find everything that is allocated.   There is no reason
to even allow different methods (except perhaps, for real random numbers
instead of PRNs).

kre