headers
Brian Haberman | 1 Sep 2005 16:38

Re: Call for RFC 3041 Implementation Reports

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 <brian <at> innovationslab.net> 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?
(Continue reading)

Permalink | Reply | 6 comments |
headers
Theodoros Pagtzis | 2 Sep 2005 10:24
Picon
Picon
Favicon

A question for the oDAD draft spec.

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
(Continue reading)

Permalink | Reply | 5 comments |
headers
Nick 'Sharkey' Moore | 2 Sep 2005 12:11
Favicon

Re: A question for the oDAD draft spec.

On 2005-09-02, Theodoros Pagtzis wrote:
> 
> 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)?

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 4 comments |
headers
Theodoros Pagtzis | 3 Sep 2005 10:05
Picon
Picon
Favicon

Re: A question for the oDAD draft spec.

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

Nick 'Sharkey' Moore wrote:
> On 2005-09-02, Theodoros Pagtzis wrote:
> 
>>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)?
> 
> 
> Hi Theo,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Arnaud Ebalard | 3 Sep 2005 00:05
Picon

"Link-Local" clarification in <draft-ietf-ipv6-addr-arch-v4-04.txt> (is Link-Local fe80::/10 or fe80::/64 ?)

Hello, people.

I post here a (probably stupid) question regarding Link-local  
definition in draft-ietf-ipv6-addr-arch-v4-04.txt (and previous  
RFC3513) :

- The information in http://www.iana.org/assignments/ipv6-address- 
space (updated 31 August 2005) is synchronized with 2.4 of 3513 :
   |->  FE80::/10             Link Local Unicast      [RFC3513]
- If I follow 2.4 of 3513, the address fe80:4::211:24ff:fe71:c660 is  
a Link-local address (belonging to fe80::/10).
- If I follow 2.5.6 of 3513, the address fe80:4::211:24ff:fe71:c660  
is not Link-local address (fe80:0000:0000:0000:ifaceid).

The current draft-ietf-ipv6-addr-arch-v4-04.txt is in sync with 3513  
regarding that 2 specific points (even with the split of 2.5.6 in the  
draft) sections, so I don't see the status of addresses from  
fe80::/10 that are not in fe80::/64 (like the previous one starting  
with fe80:4::..) .

Did I miss something in another document ?

ps : for a practical information on the status of implementations :
      - Linux 2.6.12 accepts those addresses as link-local
      - OpenBSD 3.7, FreeBSD 5.4 and Mac OS X.4 don't
pps : keep me on CC, I'm on the list (but can't access my mail this  
way during the WE)

--------------------------------------------------------------------
IETF IPv6 working group mailing list
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rob Austein | 4 Sep 2005 06:00
Favicon

Weekly posting summary for ipv6 <at> ietf.org

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 22.22% |    2 | 40.88% |    22617 | erik.nordmark <at> sun.com
 22.22% |    2 | 15.33% |     8483 | t.pagtzis <at> cs.ucl.ac.uk
 11.11% |    1 | 15.87% |     8780 | brian <at> innovationslab.net
 11.11% |    1 |  8.11% |     4487 | troglocan <at> gmail.com
 11.11% |    1 |  6.98% |     3861 | sharkey <at> zoic.org
 11.11% |    1 |  6.53% |     3613 | mailman-owner <at> ietf.org
 11.11% |    1 |  6.30% |     3487 | sra+ipng <at> hactrn.net
--------+------+--------+----------+------------------------
100.00% |    9 |100.00% |    55328 | Total

Grunchweather Associates provides this automatic summary on an at-whim
basis at the request of the IPv6 WG chairs.  Your mileage may vary.
We decline responsibilities, all shapes, all sizes, all colors.
If this script produces broken output, you get to keep both pieces.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Nick 'Sharkey' Moore | 5 Sep 2005 11:20
Favicon

Re: A question for the oDAD draft spec.

G'day Theo,

> 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)?.

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.

> >	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.

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

> Also can you see a potential denial of service attack if the node 
> 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,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Theodoros Pagtzis | 5 Sep 2005 11:47
Picon
Picon
Favicon

Re: A question for the oDAD draft spec.

Hi Nick

Nick 'Sharkey' Moore wrote:
> G'day Theo,
> 
> 
>>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)?.
> 
> 
> 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.

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??
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nick 'Sharkey' Moore | 5 Sep 2005 12:12
Favicon

Re: A question for the oDAD draft spec.

On 2005-09-05, Theodoros Pagtzis wrote:
> 
> 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??

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julien Laganier | 6 Sep 2005 10:42
Favicon

Fwd: I-D ACTION:draft-laganier-ipv6-khi-00.txt

Hi,

We would appreciate very much feedback from members of the IPv6 WG on 
this internet draft.

Thanks in advance. Regards,

--julien

----------  Forwarded Message  ----------

Subject: I-D ACTION:draft-laganier-ipv6-khi-00.txt
Date: Saturday 03 September 2005 00:50
From: Internet-Drafts <at> ietf.org
To: i-d-announce <at> ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts
 directories.

	Title		: A Non-Routable IPv6 Prefix for Keyed Hash Identifiers (KHI)
	Author(s)	: P. Nikander, et al.
	Filename	: draft-laganier-ipv6-khi-00.txt
	Pages		: 9
	Date		: 2005-9-2

   This document introduces Keyed Hash Identifiers (KHI) as a new,
   experimental class of IPv6-address-lookalike identifiers.  They
 are constructed to be statistically globally unique.  They are
 intended to be used as identifiers only, and not as locators.  They
 should not appear in actual IPv6 headers.  Consequently, they are
(Continue reading)

Permalink | Reply | 0 comments |

Gmane