>>>>> On Tue, 27 Jul 2004 10:11:02 +1000,
>>>>> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
>> 3. I don't think the advantage for the optimistic node when two nodes
>> simultaneously perform DAD is justified (Section 4.3).
>>
>> This gives the Optimistic Node a slight advantage
>> over Standard nodes, however this is justified since the Optimistic
>> node may have already established connections to Optimistic
>> Addresses.
> Remember, this is for the case where two nodes are configuring the
> same address at the same time. Given the odds of an address collision
> are already vanishingly small, the odds of a simultaneous collision
> of this sort are microscopic.
Sorry, but I don't buy this argument. First, we all know the odds of
collision are very small for addresses with "almost-unique" IFIDs
(like EUI-64). But if we can really rely on the low probability so
much, why have we had a discussion on even omitting DAD and rejected
the idea multiple times. In my understanding, DAD is the mechanism to
minimize the risk of leaving collision as much as possible even if the
base odds are very small. OptiDAD is trying to introduce compromise
against the base of DAD, considering the tradeoff between the
convenience of mobile/nomadic nodes and increasing the risk of
collision. We need to be very careful and should basically be
conservative for further optimization (including the advantage we are
talking about in this thread) unless it's crucial for the compromised
operation.
(As I already said) Since the odds of collision are too small, it
should not matter much even if we do not allow the advantage for the
optimistic node. IMO, the fact that the odds are small should be used
this way (i.e., the reason for not introducing further optimization
that does not have crucial motivation), rather than as the reason for
allowing further optimization.
Besides, I would not call the odds of a simultaneous collision
"microscopic" comparing to the odds of a non-simultaneous collision.
Assuming we have a collision, the simultaneous case can happen when
the colliding nodes start booting at the same time (after a sudden
power-cut, etc). So, the odds of a simultaneous collision are just as
equally small as the odds of a non-simultaneous one, IMO. (In any
event, this does not affect my main point, though).
>> As we discussed in rfc2462bis, address duplication may in some cases
>> indicate hardware address duplication. Since continuing operation
>> under hardware address duplication can cause additional confusing
>> situation (even if one of the colliding node stops using the
>> duplicate IP address), I think no exception can be justified.
> If there's an actual LL address duplication, we've got bigger
> problems than worrying about the exact balance of probabilities
> in DAD.
Sorry, I don't understand this...my point was that if we allow the
advantage for one of the colliding nodes under the situation where the
hardware addresses collide, the result can be more weird and harder to
diagnose (as documented in rfc2462bis, "some things can work and other
things not). So we should rather just disable the use of the address
as originally specified in the autoconf document.
>> Additionally, we should have assumed actual duplication for an
>> optimistic address is very unlikely to happen. If so, giving
>> advantage under a nitch duplicate condition does not seem to provide
>> much actual benefit.
>>
>> So, I'd request to simply remove the special privilege.
> The reason it's there is to tip the balance in favour of the current
> user of an address rather than the newcomer. The behaviour fits in
> with the idea that OptiDAD is promoting the address to non-Tentative ...
> non-Tentative addresses are defended rather than surrendered.
Again, sorry, I don't buy this argument. I think I've already stated
my point on this above, so I won't repeat that here.
>> 10. In section 3.2
>>
>> * (modifies 5.4.3) A node MUST reply to a Neighbour Solicitation for
>> its address from the unspecified address with a Neighbour
>> Advertisement to the All Nodes address. If the solicitation is
>> for an Optimistic Address, the reply MUST have the Override flag
>> cleared (O=0).
>>
>> Does the first sentence apply to all nodes including "Standard" ones,
>> or is it limited to optimistic nodes? (I'd object to this
>> modification in the first place, BTW - see comment 5).
> OptiDAD draft does not prescribe ANY changes to behaviour for
> Standard Nodes. It is designed to interoperate with any nodes
> following the rules of 2461/2462, although it doesn't offer any
> benefit unless the RS includes a SLLAO.
Okay, then it would be nice if the text is clearer on this.
> Which reminds me: any idea what the timetable for 2461bis/2462bis is
> looking like? I guess OptiDAD should be updated one they are finalized.
I believe 2462bis is ready to be submitted to the IESG. I cannot
predict further timetable on it, just like other standardized document
(i.e., I cannot predict when the IESG completes the review of the
document, etc).
I'm not really sure about 2461bis, but in my understanding it's almost
ready for a wg last call.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
