[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] I-D Action:draft-ietf-dna-simple-00.txt
In DNAv4, the reachability test, if completed, enables bi-directional
communications.
It accomplishes this by simultaneously confirming the address (enabling the
host to
send), as well as by enabling an ARP cache entry on the router (enabling the
host
to receive from the router). After confirming the address, DNAv4
implementations
typically also send a broadcast ARP, announcing the address to everyone else
on the LAN.
DAD is not triggered after successful completion of the reachability test,
since
it is assumed that the host had previously completed DAD on the address, and
the lease has not yet expired. However, DAD could be triggered if the host
receives a DHCP NAK and then transitions to the INIT state where it receives
an address on another network.
In DNAv6, I see little reason for this to change, particularly if the
address
was obtained from DHCPv6. Presumably after acquiring the address,
the host did DAD, and the lease is still valid.
In the case where the address was obtained via an RA and the host
did DAD, it is possible that another host could have taken the
same address while the host was away. However, healing from
partition is always possible and if ongoing conflict detection is
supported to detect this, then the issue can be detected after
the fact, rather than requiring DAD to be completed with
each DNA invocation.
Requiring DAD with each invocation is not a good idea,
since there are situations where "link up" can occur at
intervals of the same order as the DAD time. In those
scenarios, the host will lose connectivity a significant
proportion of the time, to no useful effect.
--------------------------------------------------
From: "Premec, Domagoj" <domagoj.premec@siemens.com>
Sent: Friday, April 18, 2008 10:27 AM
To: "Suresh Krishnan" <suresh.krishnan@ericsson.com>
Cc: <dna@eng.monash.edu.au>
Subject: RE: [DNA] I-D Action:draft-ietf-dna-simple-00.txt
> Hi Suresh,
>
> When reading the draft I was not clear if/when the DAD process for the
> candidate address(es) is started:
> a) DAD is always started immediately after link-layer indication is
> received (compliant with rfc 4862)
> b) when the DNA detects that the IP link has changed the DAD is started
> for newly configured address(es) (implying there is no DAD if DNA doesn't
> detect link change)
>
> thanks
> domagoj
>
>
>> -----Original Message-----
>> From: owner-dna@ecselists.eng.monash.edu.au
>> [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of
>> Internet-Drafts@ietf.org
>> Sent: 04. travanj 2008 21:00
>> To: i-d-announce@ietf.org
>> Cc: dna@eng.monash.edu.au
>> Subject: [DNA] I-D Action:draft-ietf-dna-simple-00.txt
>>
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>> This draft is a work item of the Detecting Network Attachment
>> Working Group of the IETF.
>>
>>
>> Title : Simple procedures for Detecting
>> Network Attachment in IPv6
>> Author(s) : S. Krishnan, G. Daley
>> Filename : draft-ietf-dna-simple-00.txt
>> Pages : 13
>> Date : 2008-04-04
>>
>> Detecting Network Attachment allows hosts to assess if its
>> existing addressing or routing configuration is valid for a
>> newly connected network.
>>
>> This document provides simple procedures for detecting
>> network attachment in IPv6 hosts, and procedures for routers
>> to support such services.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-dna-simple-00.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail
>> reader implementation to automatically retrieve the ASCII
>> version of the Internet-Draft.
>>
>