On Tue, 2004-03-02 at 08:25, JINMEI Tatuya / çæéå wrote:
> > Futile though it may be, I would like to register disagreement.
>
> I think it is not necessarily futile, though in my understanding (I
> must admit it may be biased) many people have agreed on the proposed
> change.
Admittedly I am als
> On Mon, 01 Mar 2004 22:34:47 +0200,
> Mika Liljeberg <[EMAIL PROTECTED]> said:
>> Okay, I'm happy to reach the consensus, too.
> Futile though it may be, I would like to register disagreement.
I think it is not necessarily futile, though in my understanding (I
must admit it may be bia
On Mon, 2004-03-01 at 17:25, JINMEI Tatuya / çæéå wrote:
> Okay, I'm happy to reach the consensus, too.
Futile though it may be, I would like to register disagreement.
If the intention truly was to simplify the specification, we would be
going to pure DIID. As it is, removing mention of DIID seem
> On Mon, 1 Mar 2004 22:13:26 +1100,
> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
>> [...] In this particular case, "A" is a
>> CGA identifier, so it cannot equal to a normal EUI-64 identifier.
> I had not thought of this! So
> it is not a problem at all.
> In that case I'm entir
On 2004-03-01, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
> I don't see the need for any change on this in rfc2462bis.
Okay, no worries, I'm happy too:
I had assumed the DIID behaviour
was widespread.
>[...] In this particular case, "A" is a
> CGA identifier, so it cannot equal to a normal E
ROTECTED]>
Sent: Monday, March 01, 2004 1:28 AM
Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275]
DAD text inconsistencies)
> >>>>> On Mon, 1 Mar 2004 00:12:11 -0800,
> >>>>> "James Kempf" <[EMAIL PROTECTED]> said:
>
>
To summarize the points, I'd propose to do nothing on this in
rfc2462bis because:
- the actual odds of the problem in the real world should be very low,
even in the current status.
- if we take the proposed change in rfc2462bis, the odds will be
getting lower and lower.
- if we add something fo
> On Mon, 1 Mar 2004 00:12:11 -0800,
> "James Kempf" <[EMAIL PROTECTED]> said:
>> Putting that aside, a SEND node could well *defend* the address
>> fe80::A for DAD/DIID purposes, but it would never actually use it.
> I think that's the issue. Should a SEND or 3041 node be required to de
> Putting that aside, a SEND node could well *defend* the address
> fe80::A for DAD/DIID purposes, but it would never actually use it.
>
I think that's the issue. Should a SEND or 3041 node be required to defend
LL addresses that use suffixes configured for their global unicast addresses
even thou
Nick,
My assumption is that SEND WG will adapt to the changes that RFC2462bis
will make. So if we tweak 2462 to require configuration of a
link-local
address per suffix, SEND-CGA nodes will do this. This will then
prevent
(well, detect) collision as discussed above.
Well, strictly speaking, a
> My assumption is that SEND WG will adapt to the changes that RFC2462bis
> will make. So if we tweak 2462 to require configuration of a link-local
> address per suffix, SEND-CGA nodes will do this. This will then prevent
> (well, detect) collision as discussed above.
>
SEND doesn't use a common
On 2004-02-29, James Kempf wrote:
>
> No, the SEND node performs DAD for fe80::C, where C is a function of the key
> and some other parameters. The [suffix] on LL addresses is also calculated
> from the key.
Hiya James, correct me if I'm wrong but the suffixes are both
calculated from the same ke
- Original Message -
From: "James Kempf" <[EMAIL PROTECTED]>
Cc: "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]>; "IPV6 WG" <[EMAIL PROTECTED]>
Sent: Sunday, February 29, 2004 8:53 PM
Subject: Re: SEND/DIID interoperabilility (was: Re:
> We have two nodes, a "SEND node" and a "DIID node".
>
> SEND node:
> - (for simplicity) do not implement the DIID-style optimization
> - have an (e.g.,) EUI-64 based interface identifier, I.
> - configure a SEND (CGA) address P:A (where A is the identifier, A != I)
>
> DIID node
> - imple
> On Sun, 29 Feb 2004 16:30:19 -0800,
> "James Kempf" <[EMAIL PROTECTED]> said:
> Conversely, however, there is a problem with a DIID node that just DADs its
> LL address and assumes from there that the IID can be used for a global
> address, since the SEND node will just check against it
Jinmei,
> So we should also consider the CGA case. Realistically, however, does
> this really cause a compatibility issue? The compatibility issue only
> happens when we have a DIID based implementation that supports SEND
> CGA and it is deployed. Is this really the case in the real world so
>
> On Sun, 29 Feb 2004 17:16:30 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> Suppose that a DIID node has an interface identifier (which is
> probably derived from the hardware address) "I". The DIID node first
> tries "DAD" for fe80::I. If the node does not see a duplication, then
> On Fri, 27 Feb 2004 18:59:25 +1100,
> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
>> Honestly speaking, I don't see the need for making DAD "compatible"
>> with DIID in the first place. Recall that DAD is not "compatible"
>> with DIID in this sense, even with the current RFC2462.
> On Fri, 27 Feb 2004 16:15:30 +0900,
> "S. Daniel Park" <[EMAIL PROTECTED]> said:
>> > And even with single id and new prefix this is not good: on
>> > RA with a new global prefix, every node on the link is going to do
>> > DAD based on its ID and new prefix. And, as far as I know,
>>
Nick 'Sharkey' Moore wrote:
- When configuring a global unicast address, the link-local
address with the same suffix as that address MUST be configured
and tested for uniqueness in order to maintain interoperability
with RFC2462 behaviour.
I think that configuring additional addresses wh
On 2004-02-27, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
> >
> > I'm also dubious about relying on votes at IETF meetings for
> > technical issues ... because often an option which seems 'obvious'
> > at the time actually isn't once the drafts
On 2004-02-27, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
> >
> > * DIID offers less signalling. What advantages does DAD offer?
>
> An obvious advantage is less probability of (missing) duplication (as
> was pointed out even in this thread s
> > And even with single id and new prefix this is not good: on
> > RA with a new global prefix, every node on the link is going to do
> > DAD based on its ID and new prefix. And, as far as I know,
> > there is no delay requirement here, so everyone is doing it at
> > same time.
>
> Hmm, this is
> On Fri, 27 Feb 2004 07:09:02 +1100,
> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
> I'm convinced that a change needs to be made to the wording to
> resolve this issue, but I'm not sure which is the better option.
> I'm also dubious about relying on votes at IETF meetings for
> tec
> On Thu, 26 Feb 2004 20:54:32 +1100,
> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
>> If yes, is the requirement of "DAD **MUST** take place" acceptable? I
>> believe this is acceptable in essence, but I'd like to know this does
>> not cause a severe compatibility issue with existi
On 2004-02-26, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
> > On Thu, 26 Feb 2004 20:54:32 +1100,
> > "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
>
> > My only concern would be whether or not there needs to be
> > a requirement to defend LINKLOCAL::SUFFIX when configuring
> > UNI
> On Thu, 26 Feb 2004 11:46:58 +0200,
> Markku Savela <[EMAIL PROTECTED]> said:
>> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[EMAIL PROTECTED]>
>> So, I'd now like to propose a concrete change. The simplest way to
>> implement the option would be to remove the second
> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[EMAIL PROTECTED]>
> basically, you seem to argue for DIID (against) DAD. Though I agree
> that DIID vs DAD is somewhat controversial and there is surely a
> tradeoff between those two, I believe the wg consensus was we should
> hon
On Mon, 2004-02-23 at 15:21, JINMEI Tatuya / çæéå wrote:
> Having considered these points, possible resolutions *for rfc2462bis*
> that I can think of are:
>
> 1. harden the requirement: Each individual unicast address MUST be
>tested for uniqueness. No MAY for omitting the rule (i.e., remove
On 2004-02-26, Markku Savela wrote:
>
> Yes, DIID probably (or something similar). I believe that simplest
> solution is that a specific ID value can be allowed only for single
> node on the link. Any use of same ID part with any prefix by another
> node should be viewed as an address collision.
> > Yes, DIID probably (or something similar). I believe that simplest
> > solution is that a specific ID value can be allowed only for single
> > node on the link. Any use of same ID part with any prefix by another
> > node should be viewed as an address collision.
>
> I can see where you are com
On 2004-02-27, Nick 'Sharkey' Moore wrote:
>
> I'm convinced that a change needs to be made to the wording to
> resolve this issue, but I'm not sure which is the better option.
My suggested text for "DAD but interoperable with DIID":
[5.4. Duplicate Address Detection][...]
- Each individual
Hi itojun,
I think Nick was expressing frustration in this case,
rather than proposing to adopt a bad solution.
Jun-ichiro itojun Hagino wrote:
Yes, DIID probably (or something similar). I believe that simplest
solution is that a specific ID value can be allowed only for single
node on the link. A
On Thu, 26 Feb 2004, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H(B wrote:
>If yes, is the requirement of "DAD **MUST** take place" acceptable? I
>believe this is acceptable in essence, but I'd like to know this does
>not cause a severe compatibility issue with existing implementations
>t
Hi Sharkey,
Nick 'Sharkey' Moore wrote:
On 2004-02-27, Nick 'Sharkey' Moore wrote:
I'm convinced that a change needs to be made to the wording to
resolve this issue, but I'm not sure which is the better option.
My suggested text for "DAD but interoperable with DIID":
[5.4. Duplicate Address De
On 2004-02-27, Greg Daley wrote:
> Nick 'Sharkey' Moore wrote:
> >
> > - When configuring a global unicast address, the link-local
> > address with the same suffix as that address MUST be configured
> > and tested for uniqueness in order to maintain interoperability
> > with RFC2462 b
t;
To: <[EMAIL PROTECTED]>
Cc: "Greg Daley" <[EMAIL PROTECTED]>
Sent: Thursday, February 26, 2004 6:44 PM
Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies
> On 2004-02-27, Greg Daley wrote:
> > Nick 'Sharkey' Moore wrote:
> > >
> >
> On Fri, 27 Feb 2004 13:44:08 +1100,
> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
> NB: Is there a plan for 3041bis? It's rather bound up with
> DIID too.
A quick response. I guess you are talking about the following part of
RFC3041:
Note: because multiple temporary addr
On 2004-02-27, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
> >
> > NB: Is there a plan for 3041bis? It's rather bound up with
> > DIID too.
>
> A quick response. I guess you are talking about the following part of
> RFC3041: [...] (the last
> On Thu, 26 Feb 2004 23:15:08 +1100,
> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
>> Sorry, I don't understand the concern...by which scenario might the
>> latter not be defending the link-local address? (perhaps I don't
>> understand what you meant by "defend"...)
> Sorry, that'
Hi Sharkey,
Nick 'Sharkey' Moore wrote:
On 2004-02-27, Greg Daley wrote:
Nick 'Sharkey' Moore wrote:
- When configuring a global unicast address, the link-local
address with the same suffix as that address MUST be configured
and tested for uniqueness in order to maintain interoperability
> On Fri, 27 Feb 2004 07:09:02 +1100,
> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
>> Yes, DIID probably (or something similar). I believe that simplest
>> solution is that a specific ID value can be allowed only for single
>> node on the link. Any use of same ID part with any prefi
On 2004-02-26, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
>
> So far, I've not seen an objection to Option 1, and two people
> (Francis and Jari) seem to agree on this approach.
[...]
> Can we live with this simple resolution?
I don't object to Option 1 either, and I think the standard has
to
> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[EMAIL PROTECTED]>
> So, I'd now like to propose a concrete change. The simplest way to
> implement the option would be to remove the second exception shown in
> Section 5.4 of RFC2462. That is, the revised text would be:
>
> 5.4 D
> On Mon, 23 Feb 2004 22:21:49 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> Since we have a discussion about optimistic DAD, this is probably a
> good chance to start a related discussion for rfc2462bis.
(...snip...)
> Having considered these points, possible resolutions *for rfc2
> On Tue, 24 Feb 2004 13:16:02 +0200,
> Jari Arkko <[EMAIL PROTECTED]> said:
>> So I really believe in the DAD usefulness and if you'd like to remove
>> or "optimize" DAD on one of my networks my answer will be "NO!".
> I believe the optimistic DAD folks are very keen on keeping the DAD
Hi Francis,
> => this is a half baked solution, i.e., either you don't want duplicates
> on your network and you enforce DAD, or you accept possible problems
> and you makes the live of mobile nodes (and of implementors) far easier.
>
So let me ask a question. If you believe optimized DAD is a ha
While the topic of Optimistic DAD is interesting, I believe we are
getting work items crossed here. The consensus I see is to not make
changes to 2462 wrt Optimistic DAD. Therefore, we can drop this
discussion as it relates to the 2462 update.
There is a slot in Seoul to discuss Optimistic DAD
In your previous mail you wrote:
> => what we need is collision avoidance, no collision detection after
> damage.
Here I have a slightly different opinion. There are two questions:
do we want avoidance or detection, and whether optimistic DAD
implies "possible problems". Rega
Hi Francis,
Francis Dupont wrote:
In your previous mail you wrote:
>Omitting DAD altogether removes the ability to detect and correct
>address collisions, whereas optimizations such as Optimistic DAD
>mean that while there may be a short term disruption the problem
>w
In your previous mail you wrote:
> => usually both the real owner and the offender are dead. Murphy's law
> makes the real owner an important server.
This is not going to happen in Nick's optimistic DAD draft.
=> I disagree: even in Nick's draft the second system has both
a servi
Francis Dupont wrote:
>Sure. But aren't you assuming that they have to go in and manually
>recover?
>
> => it is the case for IPv4 because this kind of event is very rare
> so there is no need to add an automatic recover tool. But IMHO
> the real question is where are these problems for? T
In your previous mail you wrote:
Sorry to respond to my own e-mail.
=> our keyboards have large enter keys, and often more than one (:-).
But I wanted to clarify one thing.
Manual recovery is fixing the problem, like reconfiguring the address.
=> and in some cases (*all* the real c
In your previous mail you wrote:
> => just ask large network managers. Address duplication is a real
> nightmare to fix in the real world.
Sure. But aren't you assuming that they have to go in and manually
recover?
=> it is the case for IPv4 because this kind of event is very rar
Sorry to respond to my own e-mail. But I wanted to clarify one thing.
Manual recovery is fixing the problem, like reconfiguring the address.
The recovery that optimistic DAD provides is however different. It
just corrects a temporary disruption that the optimistic assumption
may have caused. Whethe
Francis Dupont wrote:
In your previous mail you wrote:
> => in the real world this kind of problem cannot be corrected...
> The only thing you can do is to avoid to reproduce the same error again.
Was there a specific non-recoverable scenario you had in mind there?
=> just ask la
Francis Dupont wrote:
So I really believe in the DAD usefulness and if you'd like to remove
or "optimize" DAD on one of my networks my answer will be "NO!".
I believe the optimistic DAD folks are very keen on keeping the DAD
functional. That is, it is a requirement that networks and nodes must
be
In your previous mail you wrote:
> => in the real world this kind of problem cannot be corrected...
> The only thing you can do is to avoid to reproduce the same error again.
Was there a specific non-recoverable scenario you had in mind there?
=> just ask large network managers.
In your previous mail you wrote:
>Omitting DAD altogether removes the ability to detect and correct
>address collisions, whereas optimizations such as Optimistic DAD
>mean that while there may be a short term disruption the problem
>will be detected and corrected.
>
On 2004-02-24, Francis Dupont wrote:
> [Nick 'sharkey' Moore wrote:]
>
> > Omitting DAD altogether removes the ability to detect and correct
> > address collisions, whereas optimizations such as Optimistic DAD
> > mean that while there may be a short term disruption the problem
> > will be dete
Hi Francis,
Francis Dupont wrote:
In your previous mail you wrote:
> >- whether omitting/optimizing DAD is a good idea
>
> => IMHO this is the same thing, i.e., optimizing gives the same result
> than omitting.
Omitting DAD altogether removes the ability to detect and cor
In your previous mail you wrote:
> >- whether omitting/optimizing DAD is a good idea
>
> => IMHO this is the same thing, i.e., optimizing gives the same result
> than omitting.
Omitting DAD altogether removes the ability to detect and correct
address collisions, whereas
On 2004-02-23, Francis Dupont wrote:
> [JINMEI Tatuya wrote:]
> >
> >- whether omitting/optimizing DAD is a good idea
>
> => IMHO this is the same thing, i.e., optimizing gives the same result
> than omitting.
Omitting DAD altogether removes the ability to detect and correct
address colli
In your previous mail you wrote:
As you know, there have been many discussions on DAD, including
- whether omitting/optimizing DAD is a good idea
=> IMHO this is the same thing, i.e., optimizing gives the same result
than omitting.
- (if yes) in which case we can omit DAD
- DAD
Since we have a discussion about optimistic DAD, this is probably a
good chance to start a related discussion for rfc2462bis.
As you know, there have been many discussions on DAD, including
- whether omitting/optimizing DAD is a good idea
- (if yes) in which case we can omit DAD
- DAD vs DIID
- .
65 matches
Mail list logo
