Note: folks may want to reread the thread from last year on this topic
before commenting. I've appended it below for convenience.
Markku Savela <[EMAIL PROTECTED]> writes:
> Last year, in Seattle, I asked that RFC-2462 should be changed so that
> at any specific point of time, the id-part of address should be unique
> for each host on the link.
This is one solution to the problem. But first, is there an
understanding and agreement on what the problem is that needs fixing?
(more below).
> That is, it should not be legal for two hosts on same link to use same
> ID part of the IPv6-address, regardless of the prefix.
Why? Note that this is a solution to the problem, but may be more
restrictive a solution than is necessary to address the actual problem
at hand.
> The main reason for this request is that, if id alone is not required
> to be unique on link, then *EVERY HOST* on the link must do DAD on
> every assigned id on every new prefix it sees from RA. On a link with
> many nodes, this causes a flood of DAD's after RA! [a host may have
> multilple ID's due to privacy drafts, and due other reasons].
Actually, I made a proposal in which one would not need to run DAD on
addresses other than link-local if the ids were globally unique (e.g.,
generated from the EUI-64 identifier). One would still need to run DAD
on other addresses (e.g., temprorary addresses).
It seems to me that your proposal would result in the running of DAD
in exactly the same situations. I.e, it would not eliminate the need
to run DAD on all temporary addresses, for example. Right?
> Apparently my request has been totally forgotten. It's really a minor
> issue, and should just be clarified.
Not totally forgotten, but no concrete action either. :-(
Thomas
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Sat, 02 Jun 2001 01:13:25 +0900
Subject: DAD
at the interim meeting, there was a discussion on DAD (whether
it is mandatory for all address, or we can do it just for link-local
and omit for globals that share the same interface id).
the original text is in the second bullet. i believe it is a bit
confusing at best. the first sentence recommends (SHOULD)
running DAD on every address you have, and then the following sentences
say that you MAY omit it in certain conditions. my suggestion is to
keep the first sentence and remove the exception sentences.
it still leaves me a bit fuzzy feeling as DAD works only if everyone
does it - so MUST sounds necessary to me for DAD to be useful.
DAD does not always work anyways, due to network partition or ethernet
chip initialization delays. so i'm okay with SHOULD on the first line.
in was mentioned that TAHI test files "FAILED" if people omits DAD.
first of all I would like to comment that we cannot take test result
in binary form - when we see "FAILED", we need to diagnose result
carefully. it may be an implementation choice, it may be TAHI's
interpretation, whatever. when TAHI guys run their test on KAME stack,
they give detailed interpretation on why they marked some test "FAIL"
(if they have enough time). i guess the result "FAILED" for the DAD
test is based on the following interpretation on "SHOULD" the first
sentence.
RFC2119
>3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
> may exist valid reasons in particular circumstances to ignore a
> particular item, but the full implications must be understood and
> carefully weighed before choosing a different course.
itojun
5.4. Duplicate Address Detection
Duplicate Address Detection is performed on unicast addresses prior
to assigning them to an interface whose DupAddrDetectTransmits
variable is greater than zero. Duplicate Address Detection MUST take
place on all unicast addresses, regardless of whether they are
obtained through stateful, stateless or manual configuration, with
the exception of the following cases:
- Duplicate Address Detection MUST NOT be performed on anycast
addresses.
- Each individual unicast address SHOULD be tested for uniqueness.
However, when stateless address autoconfiguration is used,
address uniqueness is determined solely by the interface
identifier, assuming that subnet prefixes are assigned correctly
(i.e., if all of an interface's addresses are generated from the
same identifier, either all addresses or none of them will be
duplicates). Thus, for a set of addresses formed from the same
interface identifier, it is sufficient to check that the link-
local address generated from the identifier is unique on the
link. In such cases, the link-local address MUST be tested for
uniqueness, and if no duplicate address is detected, an
implementation MAY choose to skip Duplicate Address Detection
for additional addresses derived from the same interface
identifier.
(snip)
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
From: Thomas Narten <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Date: Fri, 01 Jun 2001 14:46:39 -0400
Subject: Re: DAD
Here is a suggestion for how to plug the main vulnerabilities that
were discussed in the meeting.
Problem (as I understand it): the main issue is that there are some
(non-link local scope) addresses that may be assigned to an interface
(e.g., manually configured, temporary addresses, DHCP assigned, etc.),
but for which there is no corresponding link-local address using the
same interface identifier. The stateless addrconf document (RFC 2462)
says that a node can skip DAD for global (and site local) scope
addresses generated from the same interface ID as the link-local
address. This opens up a potential hole where a node (doing normal
addrconf) has run DAD on the link-local address, but has not yet
configured a global-scope address using the same interface
identifier. Then, some other node (e.g., via DHCP, a temporary address
etc.) chooses the same interface identifier and creates such an
address, runs DAD successfully (since no other node is currently using
that address), and then assigns the address to its interface. Later,
the first node (which is running normal addrconf) also generates the
address, but skips DAD, and now there are two nodes using the same
address. Oops.
Proposal: update specs to require that nodes MUST run DAD on all
addresses for which the interface identifier is NOT globally unique
(per the setting of the 'u' bit in interface identifier). DAD can be
skipped on addresses that contain IEEE EUI-64-derived interface
identifiers (and for which DAD has already been run on the
corresponding link-local address).
This means: still no need to run DAD on global addresses when doing
normal addrconf, provided the interface identifier comes from an IEEE
identifier. But one would have to run DAD for links with randomly
generated identifiers (e.g., some PPP links). One would also still
need to run DAD for temporary addresses. For DHCP addresses, we'd need
to make sure that the server sets the 'u' bit properly, and clients
would need to run DAD if the 'u' bit indicated locally unique only.
Does this solve the underlying problem in an acceptable fashion?
Thomas
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
From: Markku Savela <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Date: Sat, 2 Jun 2001 04:44:38 +0300
Subject: Re: DAD
> Proposal: update specs to require that nodes MUST run DAD on all
> addresses for which the interface identifier is NOT globally unique
> (per the setting of the 'u' bit in interface identifier). DAD can be
> skipped on addresses that contain IEEE EUI-64-derived interface
> identifiers (and for which DAD has already been run on the
> corresponding link-local address).
I would prefer the IPv6 address architecture leaves it open for future
address formats which do not use IEEE EUI-64 ID-format, and still have
all the machinery of Neighbor Discovery and ADDRCONF available.
Designs which force the stack to dig into insides of any id part are
very unappealing to me.
Address is n-bit prefix 128-n bit id, and as far as my current
implementation goes, the link layer may specify *any* n (0..128) to be
used [to prevent obvious replies, I do admit that the kinky values of
n=0 or n=128 may not quite work].
..although, one might consider a point-to-point link without link
layer addresses as "n=128".
--
Markku Savela <[EMAIL PROTECTED]>
From: "Sellers, Julian P" <[EMAIL PROTECTED]>
To: "'Thomas Narten'" <[EMAIL PROTECTED]>
Cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>,
"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2001 16:04:13 -0500
Subject: RE: DAD
Thomas,
Is there a problem with requiring nodes to perform DAD on the link-local
address generated from a given interface identifier, even if they only want
to use the site-local or the global address? That's what I thought the
following sentences from 5.4 of RFC 2462 required:
Thus, for a set of addresses formed from the same
interface identifier, it is sufficient to check that the link-
local address generated from the identifier is unique on the
link. In such cases, the link-local address MUST be tested for
uniqueness, and if no duplicate address is detected, an
implementation MAY choose to skip Duplicate Address Detection
for additional addresses derived from the same interface
identifier.
It's not clear to me what the qualifier "In such cases" refers to. Maybe
this paragraph just needs to state clearly that
- If a node has successfully performed DAD on a link-local address, the
node has the
right to all addresses on the same link that contain the same
interface identifier.
- If a node has not performed DAD on the link-local address, or if the
link-local
address has failed DAD, the node must not use any address on that
link generated with
the same interface identifier.
Julian
> -----Original Message-----
> From: Thomas Narten [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 01, 2001 1:47 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: DAD
>
>
> Here is a suggestion for how to plug the main vulnerabilities that
> were discussed in the meeting.
>
> Problem (as I understand it): the main issue is that there are some
> (non-link local scope) addresses that may be assigned to an interface
> (e.g., manually configured, temporary addresses, DHCP assigned, etc.),
> but for which there is no corresponding link-local address using the
> same interface identifier. The stateless addrconf document (RFC 2462)
> says that a node can skip DAD for global (and site local) scope
> addresses generated from the same interface ID as the link-local
> address. This opens up a potential hole where a node (doing normal
> addrconf) has run DAD on the link-local address, but has not yet
> configured a global-scope address using the same interface
> identifier. Then, some other node (e.g., via DHCP, a temporary address
> etc.) chooses the same interface identifier and creates such an
> address, runs DAD successfully (since no other node is currently using
> that address), and then assigns the address to its interface. Later,
> the first node (which is running normal addrconf) also generates the
> address, but skips DAD, and now there are two nodes using the same
> address. Oops.
>
> Proposal: update specs to require that nodes MUST run DAD on all
> addresses for which the interface identifier is NOT globally unique
> (per the setting of the 'u' bit in interface identifier). DAD can be
> skipped on addresses that contain IEEE EUI-64-derived interface
> identifiers (and for which DAD has already been run on the
> corresponding link-local address).
>
> This means: still no need to run DAD on global addresses when doing
> normal addrconf, provided the interface identifier comes from an IEEE
> identifier. But one would have to run DAD for links with randomly
> generated identifiers (e.g., some PPP links). One would also still
> need to run DAD for temporary addresses. For DHCP addresses, we'd need
> to make sure that the server sets the 'u' bit properly, and clients
> would need to run DAD if the 'u' bit indicated locally unique only.
>
> Does this solve the underlying problem in an acceptable fashion?
>
> Thomas
>
>
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
>
From: "Brian Zill" <[EMAIL PROTECTED]>
To: "Sellers, Julian P" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2001 16:51:53 -0700
Subject: RE: DAD
Thread-Topic: DAD
thread-index: AcDuBCKGkPjmAWCZROiV02r53J3DrQAFXQlA
Julian,
When this idea was suggested at the Interim Meeting, several people
expressed concern about needing to have a link-local address for every
interface identifier you might be using. A node may want to have a
large number of global addresses, for example, and the overhead of
requiring that it keep a corresponding link-local address for each might
be prohibitive. I think I'd prefer to just perfom DAD on all the global
addresses instead. It's the same amount of DADing going on, and you
don't need to keep all those link-local addresses around.
--Brian
> -----Original Message-----
> From: Sellers, Julian P [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 05 June, 2001 14:04
> To: 'Thomas Narten'
> Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
> Subject: RE: DAD
>
>
> Thomas,
>
> Is there a problem with requiring nodes to perform DAD on the
> link-local address generated from a given interface
> identifier, even if they only want to use the site-local or
> the global address? That's what I thought the following
> sentences from 5.4 of RFC 2462 required:
>
> Thus, for a set of addresses formed from the same
> interface identifier, it is sufficient to check that the link-
> local address generated from the identifier is unique on the
> link. In such cases, the link-local address MUST be tested for
> uniqueness, and if no duplicate address is detected, an
> implementation MAY choose to skip Duplicate Address Detection
> for additional addresses derived from the same interface
> identifier.
>
> It's not clear to me what the qualifier "In such cases"
> refers to. Maybe this paragraph just needs to state clearly that
>
> - If a node has successfully performed DAD on a
> link-local address, the node has the
> right to all addresses on the same link that contain
> the same interface identifier.
> - If a node has not performed DAD on the link-local
> address, or if the link-local
> address has failed DAD, the node must not use any
> address on that link generated with
> the same interface identifier.
>
> Julian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
From: Markku Savela <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Date: Wed, 6 Jun 2001 09:14:55 +0300
Subject: Re: DAD
> From: "Brian Zill" <[EMAIL PROTECTED]>
> When this idea was suggested at the Interim Meeting, several people
> expressed concern about needing to have a link-local address for every
> interface identifier you might be using. A node may want to have a
> large number of global addresses, for example, and the overhead of
> requiring that it keep a corresponding link-local address for each might
> be prohibitive. I think I'd prefer to just perfom DAD on all the global
> addresses instead. It's the same amount of DADing going on, and you
> don't need to keep all those link-local addresses around.
My proposal, doing the DAD related comparison only with the ID part,
solves the same problem, but lets you do single DAD / Id, regardless
of the number of prefixes you combine with this id. And, you don't
need to generate link-local address, if you are not using it.
There was some concern about the backwards compatibility, but I
*still* cannot see this introducing any more problems than what
already exists legally by the current specification, where you can
have hosts reserving ID for all combinations by DAD on link local, and
hosts that don't do that.
And, if you change specification, might as well change it to what I
proposed :-).
--
Markku Savela <[EMAIL PROTECTED]>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
