[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SEND and DIID-compatible DAD rule (was [rfc2462bis issue 275] DADtext inconsistencies)



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 which
>>don't match the prefix used to generate the suffix in
>>the CGA is going to cause problems.
> 
> 
> Good point.  However, the MN registering A::X only needs to
> defend the LL::X against DIID-compatible nodes.
> I think we can assume that SEND-CGA nodes will follow the
> _new_ DAD standard. So the unsecured defensive NA should be okay,
> since it won't be needed against SEND-CGA nodes.
> 
> ... I think.  Any SENDites want to comment?

Thanks for bringing this issue up. Actually, it seems that if we want
SEND nodes to be compatible with DIID-only plain ND nodes, there is
indeed a need to defend the link-local address. Doing so is possible,
although in my opinion its a bit awkward:

- SEND specification has to be amended with a new rule.
- SEND nodes have to send plain ND messages (they are unable to
   secure the LL::X probe because X depends on prefix, and
   we are not really trying to create the address LL::X but rather
   A::X). Nevertheless, sending plain ND messages is possible.
- The amount of messages for DAD is duplicated.

So I guess what I'm asking is whether we really need to do
this. Did someone make a poll earlier about how many DIID-only
implementations there are? What where the results, are we likely
to encounter DIID-only hosts? Or perhaps SEND needs to do defend
LL::X only when running in ND-compliant mode?

--Jari




--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------