Re: Comments on the analysis in draft-garneij-6man-nd-m2m-issues-00

[Erik Nordmark <[e-mail]>]

On 4/27/15 8:52 PM, Erik Kline wrote:

>> I would like to understand your reasons a bit. Is this because you think
>> multicast RAs are absolutely needed or because sending RAs only when
>> solicited is bad?
> Sending unicast RAs whenever solicited: +1.
>
> Sending opportunistic unicast RAs whenever the router has other
> packets to deliver anyway: +1.  (Yes, this is not currently documented
> anywhere.)
>
> Overall I'm concerned about the propensity for everything to be
> increasingly static.
Erik,

I don't understand how sending a RS to get an RA results in more static 
configuration than what RFC 4861 has.
RFC 4861 allows for prefix lifetimes to be infinite (which FWIW I think 
was a mistake). Whether the information is pushed or pulled has no 
impact on NUD being able to switch from an unreachable router to a 
reachable one.

You've pointed out that in rs-refresh we shouldn't allow an infinite 
refresh time, and I think that would be an improvement over RFC 4861. 
But even without that fix I don't see how rs-refresh would be more 
static than 4861.

What am I missing?

>    Soon we'll hear: a billion clients polling via
> unicast RS is putting too much load on the infrastructure to generate
> the correct RAs.  And then we'll copy'n'paste DHCPv6 Squelch into RS
> Squelch--either that or infinite RAs.
>
> I don't want us to lose the *operational* ability to reconfigure,
> despite the fact the protocol will continue to nominally support it.
>
Can you give an example where rs-refresh would not be able to 
reconfigure the hosts?
Are you assuming that implementations for some reason are more likely to 
have bugs relating to rs-refresh then they do for 4861? Or some other 
unstated assumptions?

Thanks,
    Erik