Subject: Re: Call for RFC 3041 Implementation Reports

From: Brian Haberman <[email-masked]>
Date: Thu, 1 Sep 2005 10:38:22 -0400

Sorry for the delay in response...

On Aug 25, 2005, at 0:59, JINMEI Tatuya / 神明達哉 wrote:

>>>>>> On Wed, 3 Aug 2005 05:20:25 -0400,
>>>>>> Brian Haberman <[email-masked]> said:
>
>>       As mentioned during the IPv6 WG meeting, the chairs are 
>> soliciting
>> implementation reports for IPv6 Privacy Addresses in support of moving
>> the spec
>> to Draft Standard.  The following template should be used for 
>> submitting
>> these implementation reports.  The reports can be sent to the chairs
>> and/or
>> the mailing list.
>
> (snip)
>
>>       6. Tested Interoperability by Feature:
>
>>            A. Lifetime Management (Section 3.4)
>
>>            B. DAD Operation (Section 3.2)
>
> I'm not sure what "interoperability" should be reported about
> those...as far as I understand, these are only a matter of the host
> using RFC3041, and I don't see any "interoperability" issue here.
> Could you clarify the required information?

I was envisioning a validation that the node using RFC 3041 addresses
perform DAD for those addresses and peers cannot detect any
differences in messaging/processing.

>
> Regarding DAD, which specification should be the base of the report,
> RFC3041 or draft-ietf-ipv6-privacy-addrs-v2-04.txt?  (The behavior on
> this is very different between these two versions of the spec).

These are implementation reports for 3041, so the basis should be
the RFC.

>
> In either case, I suspect "Section 3.2" should actually be "Section
> 3.3" (more specifically, Step 7 of Section 3.3).  In fact, neither
> RFC3041 or privacy-addrs mentions DAD in Section 3.2 as a part of the
> protocol specification.
>

Correct.  My mistake in typing the message.

Regards,
Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Theodoros Pagtzis <[email-masked]>
Date: Fri, 02 Sep 2005 09:24:59 +0100

Dear all,

Having read the oDAD draft spec and in search of an answer would it be 
possible if somebody can give assist with the following question?

If the MN has not sent its link-layer address (LLA) in the Neighbour 
Solicitation (NS) how does the AR know the LLA of the host to forward 
downstream DURING the DAD resolution period (i.e. 1000ms)?

My question tries to resolve how the forwarding can be effected 
_downstream_ from AR --> host even if optimistically the node's address 
configuration is accepted DURING the DAD resolution period.

If I understand correctly, forwarding in ANY direction requires a 
neighbour resolution (i.e. ARP resolution v6) from an IP address to the 
LLA address of the destined IP address. In my understanding this is 
mandated by NUD to enable frame forwarding to the node's MAC destination.

If I see correctly the upstream link transmission from host --> AR would 
be sorted out by the (oDAD) solicited NeighAdvert received by the host 
which is fine..

Any answers to this would be appreciated.

many thanks
theodoros

-- 
theo
Nets & Mobile Systems Group
UCL-CS

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Fri, 2 Sep 2005 20:11:58 +1000

> downstream DURING the DAD resolution period (i.e. 1000ms)?

Hi Theo,

	the AR simply sends an NS (from its unicast address) to the host,
and the host MUST reply with an NA (O=0).  This NA gives the AR the LLA of
the host, and communication can commence.

	(see 3.3 *5)

-----Nick

---

From: Theodoros Pagtzis <[email-masked]>
Date: Sat, 03 Sep 2005 09:05:21 +0100

Hi Nick,

thanks for your response.

I was wondering though, that assuming in a net where the AR has to deal 
with hundreds or thousands of nodes on the link (i.e. the replenishment 
rate of new nodes - with the total staying roughly the same - (as the 
case may be for mobile nodes under MIPv6), how is the AR supposed to 
deal with 'remembering' the LLA of all the nodes' LLA if the overiding 
flag is set to zero (O=0)?.

The reason I am asking is because if the respective NCE cannot be 
overidden with the NA LLA content (sent from the node), then how will 
the AR 'remember' which LLA to map to when there is traffic destined 
downstream for the node..?

also

> 	the AR simply sends an NS (from its unicast address) to the host,

when you say to the 'host' do you mean the solicited-nodes multicast 
address or the unicast address of the host? This is a bit unclear from 
the spec.

Also can you see a potential denial of service attack if the node 
decides to change optimistically its address continuously?

thanks
t.

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Mon, 5 Sep 2005 19:20:57 +1000

G'day Theo,

> flag is set to zero (O=0)?.

Well, it's not easy being a router.  Yes, if there's a collision with
an address which is already in the AR's NC, OptiDAD will fail ... see
Appendix A for a discussion of the probabilities of that, though.

> address or the unicast address of the host? This is a bit unclear from 

Solicited-nodes ... the AR doesn't know the LLA yet, so it has to 
solicit for it just like normal address resolution.

> decides to change optimistically its address continuously?

There's a heap of DoS opportunities against IPv6 address autoconf,
and this draft doesn't try to fix them ... see SEND for more details.

cheers,

-----Nick

---

From: Theodoros Pagtzis <[email-masked]>
Date: Mon, 05 Sep 2005 10:47:39 +0100

Hi Nick

> Appendix A for a discussion of the probabilities of that, though.

I did not imply a collision probability at all. My question was "how 
does it remember all LLAs if they are not stored in the NC - since the 
NC entries are not overriden each with the respective LLA). Let me show 
an example. Consider:

You have N nodes that try to do OptiDAD. All of them do not send their 
LLA in the NS. Now that implies N unicast NSs, initiated by the AR 
towards these N nodes and a respective N number of NeighAdverts back to 
the AR each with a different LLA.

HOW will the AR "remember" each these LLA if they are _NOT_ stored each 
in a NCE (since the overriding flag is not set) during DAD resolution??

Typically for forwarding purposes the ND must first acquire the LLA from 
the respective NCE of the relevant node in order to do the MAC 
forwarding on the link. How is _this_ forwarding going to be effected 
(i.e. downstream) IF each NCE does not contain each of the N nodes' LLAs.

I would imagine that the LLAs as forwarding state must be stored 
somewhere and used subsequently for forwarding. Where are these LLAs 
stored (other than NC) during the period of DAD resolution?

many thanks
t.

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Mon, 5 Sep 2005 20:12:20 +1000

> in a NCE (since the overriding flag is not set) during DAD resolution??

Ah, I see what you mean now!

They _are_ stored in the NC.  The AR is unmodified, so the
state machine in 2461(bis) applies ...

State           Event                   Action                New state

-               Packet to send.         Create entry.         INCOMPLETE
                                        Send multicast NS.
                                        Start retransmit timer

INCOMPLETE      NA, Solicited=1,        Record link-layer     REACHABLE
                Override=any            address.  Send queued
                                        packets.

So, an entry is created in state INCOMPLETE and an NS is sent,
and when the ON replies with NA(O=0,S=1) the entry is promoted
to REACHABLE and traffic begins.

Hope that helps,

-----N