Subject: revisit protocol constants ??

From: Thomas Narten <[email-masked]>
Date: Wed, 22 Jan 2014 13:55:27 -0500

Here is an excerpt from my review of the stable addresses document. I
wonder if we should rethink some of the protocol constants we are
defining. The world is becoming more diverse and it seems that a "one
size fits all" notion for some protocol constants is making less and
less sense.

> Finally, I want to raise a generic issue that applies to this
> document, but really is a general problem. The document adds a random
> delay between 0 and IDGEN_DELAY in order to avoid lock-step
> behavior. While that is a good thing, Using IDGEN_DELAY of 1 second is
> pretty long for some network technologies (think data center with 10G
> or higher interfaces). I wonder if we should stop using constants that
> are fixed and make them more dependent on actual network
> technology. E.g., 1 second seems OK for WiFi, but not for 10G.

Note that this sort of constant being as long as a second can mean it
will take that much longer to configure an address (in some cases)...

> Likewise, should you ever stop trying to configure an address if you
> keep getting DAD failures? I'm of two minds. Going forward, it becomes
> increasingly painful to require operator intervention to "fix"
> something that isn't working. That argues for never giving up. But
> what should happen then is some sort of exponential backoff should be
> used to ensure that retries happen infrequently, so as not to cause
> network problems. The current text says:

For this, I was partly also thinking about DHCPv6 where the original
spec called for the client  giving up after a certain number of
tries. That saves bandwidth, but it also means that if a client can't
find a DHC server, at some point it quits trying and won't ever try
again. And if the machine stays up and running for  several
weeks... (I'm not sure this ever even got fixed....)

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Wed, 22 Jan 2014 11:10:48 -0800

On Jan 22, 2014, at 10:55 AM 1/22/14, Thomas Narten <[email-masked]> wrote:

>> [...]

It's fixed.  Based on sections 14 and 17.1.2, "the client continues to transmit the message until it receives a response" (in this specific case, a SOLICIT message).

This behavior (the interval between transmissions of the SOLICIT message) was modified with the recent publication of RFC 7083.

- Ralph

> 
> Thomas
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Jan 2014 17:58:57 -0300

Thomas,

>> technology. E.g., 1 second seems OK for WiFi, but not for 10G.

I'd say that I generally agree with your point of view... But the
IDGEN_DELAY is really a bad example.

We're talking about waiting for *at most* 1 second (say, 0.5 seconds in
the general case) and *only* when two 64-bit random numbers collide.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492