Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 3 Jul 2007 10:30:32 -0400

Hi Markku,

Sorry for the delay. Please see in line below against "<hs>".

-----Original Message-----
From: Markku Savela [mailto:[email-masked]] 
Sent: Tuesday, June 26, 2007 10:39 AM
To: [email-masked]; [email-masked]; Fred Baker (fred)
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent
changessuggested to 2462bis-08

Related to this topic, long time ago when the choices of

a) DAD only on link local, and not on other addresses derived from the
same id (legal on original RFC)

b) do DAD indivially on each address

were discussed, I preferred (a) (and still do), and proposed an
additional logic on hosts using (a):

- if they see DAD probe on any address using the ID part of the
  assigned link local address, the host would reply as if the probed
  address was configured ("defend ID patch").

That solves the case where one tries to manually configure global
address to some other host using the same ID part. The attempt will fail
as DAD collision. It does not solve merging of two local links into one,
but nothing solves that mess anyway, if there are multiple users of same
ID and addresses.

<hs> Please see Host1 and Host2 in the scenario we described in Section
2, bullet 4 of our I-D. Since this email, we also have a newer -01
version. Please grab that copy.  In our scenario, Host1 comes online
first while Host2 is powered down.  Then, Host2 comes online.  In this
case, your "defend ID patch" doesn't work (since Host2 doesn't see
Host1's DAD using MAC2).  However, our solution of "not skipping DAD for
any acquired unicast address" will work because if Host2 performs DAD
for GUA with MAC2, then Host1 will catch this NS(DAD) and respond with
an NA.

I still question the sanity of "do DAD on all addresses" approach:

- when router advertises a list of global prefixes, *each* and *every*
  node will now send DAD on each address at same time => instant DAD
  storm. And a host can have mulpiple id's in use...

- now, if we talk about rogue hosts, one could do continous stream of
  RA's with 40 random prefixes, and see how the hosts behave...

<hs> Let's appreciate the fact that 2462bis has already changed to say
"newer implementations MUST perform DAD for every acquired unicast
address". We don't have a DAD storm problem (as described above) because
DAD's are initiated with a randomized delay. See section 5.4.2 of
2462bis -08 I-D, third and fourth paragraph.

- Hemant and Wes

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

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 06 Jul 2007 16:19:31 +0900

At Fri, 29 Jun 2007 12:06:21 -0400,
Ralph Droms <[email-masked]> wrote:

> Stig - you wrote "At least as a sysadmin/user I would find it  
> confusing if the prefix length I configured would not be used for on- 
> link determination. I think it's more bad than good to try to  
> separate the two. I'm happy the way it currently is on the systems  
> I've seen."  I can understand that it should be possible to manually  
> configure on-link prefix information.  I question whether that  
> configuration should be conceptually tied with address assignment  
> because of the design of IPv6, or do we mix address assignment with  
> prefix information because that's the way it was done in IPv4?

I believe so.  Even though the concepts of address/prefix are
different for IPv4 and for IPv6 in some points, I'm pretty sure that
an administrator would expect when they execute

# ifconfig ed0 inet6 2001:db8:1234::abcd prefixlen 64

the system treats 2001:db8:1234::/64 as on-link, just like they would
expect when they execute

# ifconfig ed0 inet 192.0.2.1 netmask 0xffffff00

the system treats 192.0.2.0/24 as on-link.

> Looking back to the definition of DHCPv6 - we received a lot of input  
> that DHCPv6 should *not* include information about default routers  
> and on-link prefixes, because that information comes from RAs.  That  
> argument made sense to me at the time; makes sense to me in the case  
> of manual address assignment, too...

IMO the key difference is "automatic" (whether stateless or DHCPv6) vs
"manual".  In the case of RA (for on-link prefix) + DHCPv6, everything
will be set up automatically, so I'd agree that it makes more sense
not to have the redundant information in DHCPv6.  In the case of
manual configuration of addresses, the administrator should be able to
control everything, so I think it's reasonable for the administrator
to allow to specify both the address and on-link prefix information
even when the node is also receiving RAs.

BTW: I personally think this situation (manual address assignment with
RA for on-link info) is very atypical and is not really appropriate to
compare with the common case for DHCPv6(address) + RA(on-link) in the
first place.  But if the administrator really wants to do it, they can
achieve the result by specifying 128 as the prefix length:

# ifconfig ed0 inet6 2001:db8:1234::abcd prefixlen 128

at least on BSDs.

Finally, I'd like to note that prefix information option with L=0 does
not mean the correspondent prefix is off-link.

   [...]  Note, however, that a Prefix Information option
   with the on-link flag set to zero conveys no information concerning
   on-link determination and MUST NOT be interpreted to mean that
   addresses covered by the prefix are off-link.  The only way to cancel
(Section 6.3.4 of RFC2461)

So, by executing

# ifconfig ed0 inet6 2001:db8:1234::abcd prefixlen 64
(while receiving RAs with the prefix information for 2001:db8:1234::/0
and L=0)

the administrator is not "overriding" the information advertised by
the RA; they are simply "specifying" the information which has not
been provided.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]