[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DNA] Considerations for DNA Schemes with multiple Interface andLayer 2 Technologies



Pekka Nikander wrote:

> Taking a slightly wider angle, we can imagine various anomalies
> like someone inadvertedly connecting two (wireline) LAN segments
> together.  That would (temporarily) create a similar situation.
> Hence, I'm afraid that we need to make the DNA scheme(s) robust
> against these kinds of situations.  However, my current opinion
> (subject to change) is that we should not worry too much about
> these kinds of situations, and it would be perfectly OK if it takes
> some more time to system to recover in such a situation.  In other
> words, if some hosts unnecessarily run DNA and autoconfiguration,
> that wouldn't be too bad.

Good point.
It would be good if we can say that DNA doesn't make such a situation 
any worse than it is without DNA, and that the same mechanisms which can 
be used to recover still work when DNA is used.

An example of what would go wrong today is that the hosts would get the 
routers and the prefixes for the other link, where the prefixes would be 
used to both autoconfigure addresses and for on-link determination.
Once the accidental connection is broken, with rfc 2461 it will take 30 
minutes for the routers to time out from the default router list and 30 
days for the prefixes to time out. Thus in the meantime the hosts will
  - try to use unreachable routers until NUD tells it the router isn't
    responding
  - assume hosts are on-link which are not and fail to communicate with
    those hosts
  - use autoconfigured addresses with the bogus prefixes, for which the
    return traffic will not reach them

The administrator might have tools that can help restore this more 
quickly - just sending "spoofed" RAs with zero lifetimes for the bogus 
default routers and the bogus prefixes will quickly repair things except 
that the autoconfigured addresses will remain deprecated for 2 hours 
(due to the 2 hour rule in RFC 2462).

So at a minimum I don't think we should make this any worse and any 
harder to restore than it is today.

    Erik