Re: [6lowpan] -nd-15: DAD requirement seems too strict

Hi Colin

>If you had a closed network where you don't have the 'idiot node'
>picking addresses randomly in your space, you could skip DAD. But
>I think if you had such a closed network you wouldn't care enough
>about sticking to the RFCs anyway.

To some extent this ties to the link-layer bootstrapping process.
I know at least one link-layer technology which does guarantee
unique link layer addresses.
Still, I consider the ND doc highly useful and see several reasons
for sticking to it if possible.

And anyway, the document seems to be in conflict with itself on
this issue ...

Cheers,
  Anders

-----Original Message-----
From: Colin O'Flynn [mailto:coflynn@newae.com] 
Sent: 25. februar 2011 14:42
To: Anders Brandt; zach@sensinode.com; '6lowpan'
Subject: RE: [6lowpan] -nd-15: DAD requirement seems too strict

Hi Anders,

I'm still reading through -15 too, so just wanted to add other comments.

I think part of the problem is you can register any address you want,
not
necessarily one based on a MAC address. EUI64-based addresses can be
globally unique, so you can reliably skip DAD on those.

An address generated from a MAC address, if that MAC address is not
globally
unique, could potentially collide with another address.

This is very unlikely, as someone would have to randomly choose an IPv6
address in the same space as your MAC-address-derived space.

If you had a closed network where you don't have the 'idiot node'
picking
addresses randomly in your space, you could skip DAD. But I think if you
had
such a closed network you wouldn't care enough about sticking to the
RFCs
anyway.

Regards,

  -Colin

-----Original Message-----
From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On
Behalf
Of Anders Brandt
Sent: February 25, 2011 11:10 AM
To: zach@sensinode.com; 6lowpan
Subject: [6lowpan] -nd-15: DAD requirement seems too strict

Having read the doc carefully, I have a question:

The doc is somewhat scizophrenic whether it accepts that a link layer
can
guarantee unique short addresses.
Assumption #6 in section 1.3 seems to say "OK"
Section 3.2 says that if I do not use DHCPv6 (M flag = 1) I MUST use
DAD.
I would like this softened to
"MUST use DAD if the LOWPAN cannot guarantee unique short addresses"

Thanks,
  Anders

-----Original Message-----
From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On
Behalf Of Carsten Bormann
Sent: 17. februar 2011 16:58
To: 6lowpan
Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15

In September/October, we had the first WGLC on 6LoWPAN-ND, which
resulted in a number of detailed comments and two resulting
fine-tuning iterations of the draft.

draft-ietf-6lowpan-nd-15.txt has been out for two months now.
I understand it has taken part in several interops with multiple
implementations in this period; no issues came up.

We now start the Working Group Last Call on:

   http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15

The document is planned to be submitted by this Working Group to the
IESG for publication as a Standards-Track Document.

This is a two-week Working-Group Last-Call, ending on Thursday,
2011-03-03 at 2359 UTC.

Please review the changes to the document carefully once more, and
send your comments to the 6lowpan list.  Please also do indicate to
the list if you are all-OK with the document.

Gruesse, Carsten

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan