Re: [DNA] Model: how to treat "link down" events

[JinHyeock Choi <jinchoe@gmail.com>]

Dear Thomas

I approach this in view point of how to manage IP configuration
information (such as IP address) upon link down event.

In short, I think that
In case only link down event happens (without subsequent link up
event), it's ok for a host to keep assigning the cached config
information to the interface.

Whereas in case link up event follows link down event, the host needs
to perform DNA to check for link change. If a link change has
happened, the host should discard the cached config information. If
not, it can keep using the existing information.

Kindly see the inline comments.

> In thinking through this, one thing that is not clear to me is what
> the model is for what to do when a "link down" event takes place. This
> is actually important to understand as it plays into how to handle
> "link up" events.
>
> RFC 2461/2462 defines the IPv6 behavior for configuring a link with
> IPv6 information such as addresses, MTU, on-link prefixes, etc.  When
> a link goes down, conceptually one disables the interface and discards
> all associated config info. However, this has the negative side-effect
> of causing upper-layer protocols using those addresses to possibly get
> "hard errors" and terminate connections when sending
> traffic. [Actually, is this true, or are things more nuanced, i.e.,
> does one get errors when sending but here is no route, or when sending
> but using an invalid source address, or???] In the common case where a
> link goes away for a few seconds and then comes back up connected to
> the same link (with the same associated config information) this is
> obviously undesirable.
>
> Q: what is a good model for what to do with the config information
> assocated with an interface that is going down? In some cases (e.g.,
> administrative shutdown of an interface) returning hard errors to
> upper-layer protocols is probably OK. But for wireless hiccups, it may
> not be.  And if I unplug a wired ethernet from the jack, should that
> automatically cause all connections using the address on that
> interface to fail? Not clear. There are certainly times when I wish
> that didn't happen...

I guess we'd better treat this problem in relationship with link up event.

First link down event occurs.
- Upon this event, I see few harm if a host keeps the existing config
information in anticipation of  link recovery till the lifetime
expires. (Link-layer connection is broken, so communication is not
possible anyway.)

Second link up event occurs.
- At this stage, the host can't be sure it still remains at the same
link or not. So it starts DNA procedure.
- It can still maintain the existing config information but keeps from
using it (such as using the existing IP address as a source address).

Third DNA completes
- At this stage, the host can determine what to do with its existing
config information, to discard or to keep using.

* The only problem may be the case that a host is detached from a link
for quite a long while, then reattach itself to the same link.
Because, during the host's absence from the link, none protected the
host's IP address (w.r.t. DAD), the host can't be sure that it's IP
address is still unique. It may need to perform DAD once more.

* Also I had a small experiment. I took the ethernet jack from my
laptop and put it again some time later. It kept using the same IP
address. :-)

> One possible model:
>
>  - some types of "link down" events are absolute (like an
>    administrative shutdown)
>
>  - some "link down" down events should be treated suspiciously (e.g.,
>    wireless) and should not result in (immediate) error to
>    upper-layer protocols.
>
>  - by default, one should not return hard errors immediately (in
>    anticipation of the link coming back up) but one can do so after
>    some timeout. So, should we say after N minutes, an interface is
>    really dead?
>
>  - can we provide guidelines for what to do in general?
>
> Proposal:
>
> There are two types of errors that can be returned upon sending a
> packet:
>
> hard error: means a failure of a type for which retrying is likely to
>            result in the same error, and upper layer protocols are OK
>            giving up.
>
> soft error: a temporary failure occured, but retrying a short time
>            later may result in a different result. I would put "ICMP
>            dest unreachables" into this category.
>
>
> When a link goes down (i.e., via a "link down" event), soft errors
> should be returned when a) sending through the interface, or b) if
> using addresses associated with that interface. Soft errors should be
> returned from some short time. After (say) 2 minutes, hard errors can
> be returned.

I think the above applies when there is no subsequent link up event.
But, for example, if a host is re-attached to a new link within (say)
2 mins (and recognizes a link change), I guess hard error needs to be
returned.

> Does this make sense?
>
> Note: in terms of DNA, when a "link up" event takes place, I would
> imagine that we could distinguish between a "link up" event that
> happens within (say) 2 minutes of a "link down" or after a much longer
> time period, possibly treating the behavior somewhat differently.

'IP address' may be treated differently according to the length of
detachment time. For example, we may make a rule as below.

When a host is detached from a link less than 2 mins and reattaches
itself to the same link, it can immediately use its IP address without
DAD. On the other hand, if a host is detached from a link more than 2
mins, it should perform DAD before using its IP address even when it
reattaches itself to the same link.

Thanks for your kind consideration.

Best Regards

JinHyeock