RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast

["Hemant Singh (shemant)" <[e-mail]>]

Andrew,

I'd be happy to work with you later to work out any text when I have the time.    Thanks to you and Lorenzo for taking up this work.  Please see in line below. 

-----Original Message-----
From: Andrew Yourtchenko (ayourtch) 
Sent: Friday, February 21, 2014 10:53 AM
To: Hemant Singh (shemant)
Cc: Erik Nordmark; IETF IPv6; Lorenzo Colitti
Subject: RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast

>hmm I'd be really interested to see which host implementation behaves this way. I explicitly tested Linux, MacOS X, iOS - none of them do. I glanced over the shoulder at the behavior of the Windows box - and it was >behaving in a similar fashion which does not match what you describe.

Note I pointed out an ambiguity for the host that is still compliant to the specifications but the host forwarding model has ambiguity.   For a side note, RFC 5942 has deprecated the last two bullets of the on-link definition in RFC 4861.  That leaves two bullets and one is the Redirect bullet we can put aside for this discussion.   Then the leftover text for on-link from RFC 4861 is as follows. 

on-link     - an address that is assigned to an interface on a
                 specified link.  A node considers an address to be on-
                 link if:

                    - it is covered by one of the link's prefixes (e.g.,
                      as indicated by the on-link flag in the Prefix
                      Information option), or

The definition starts with "an address that is assigned to an interface on a specified link".  This is it.  Every address assigned to an interface has a prefix length.  Thus the host deems any address within that prefix length to be on-link.  See also, RFC 4862 and search for "on-link" and you will find the text related to prefix lengths.  The first IPv6 implementation of a popular host implementation actually did use this interpretation and actually sent out an address resolution NS for a /64 destination matching its ipv6 address when the host was sent an RA with no PIO.   The host issued the NS for resolving a packet destination which was no in the host Neighbor Cache. 


>If you're not convinced, then you can skip this item for your deployment. I've seen it once, and there were multiple contributing factors, so I don't have a good data to convince you. Equally I don't have a spare lab with >9000 hosts of various operating systems, moving around. I left it because it does seem like a conservatively prudent thing to do.

It's not me.  Each time anyone has contacted the IETF mailers such as the 6man or the v6ops WG for an avalanche problem with IPv6 ND or DHCPv6, folks in the WG's have replied that both ND and the DHCPv6 specifications have randomization and at least ND has an additional jitter that avoids avalanches to cause any major problem in the ipv6 network.  I have personally tested routers with over 40,000 IPv6 clients with a router reload and did not see avalanche issues with ND nor DHCPv6.   Sorry, there was a typo in my email that said "not" when I should have said "lot".    I am interested to know why one client in a 100K client deployment has lot of IPv6 entries in the client Neighbor Cache?  How much is a lot?  10, 100, 1000 and how are these entries populated in the client?

Thanks,

Hemant