Subject: Re: reconnecting an interface

From: [email-masked]
Date: Fri, 15 Oct 1999 06:22:28 EDT

In a message dated 10/15/99 2:45:43 AM Eastern Daylight Time, 
[email-masked] writes:

> 1. When disconnecting from the media: do nothing. Addresses on the interface
>  survive and continue to age normally, routes on the interface survive, etc.

Why not declare the interface down?  Otherwise packets will be handed
to the interface and held or dropped when there might be a route
to the destination from another interface.  

>  2. When reconnecting to media: 
>  - set REACHABLE neighbor cache entries to the STALE state
>  - set auto-configured unicast address lifetimes down to a small value (the
>  length of time that we'll attempt to get an RA - max number of router
>  solicits * solicit interval)
>  - put all unicast addresses into the tentative state and restart duplicate
>  address detection
>  - set lifetimes of routes learned from autoconfig (default routers, on-link
>  prefixes) down to the same small value
>  - send out MLD reports, rejoining any multicast addresses assigned to the
>  interface
>  - start sending router solicitations
  
>  The idea being that if we did reconnect to the same subnet, then we'll get
>  an RA that will reset all the lifetimes back to their usual values. However
>  if we are connected to a new subnet, then the old addresses and routes will
>  disappear and we'll have acquired new addresses and routes. However any
>  manually configured addresses or routes will not disappear.

If the interface was declared down upon disconnection, reconnection
differs in no way from initial connection.
  
>  Does this sound reasonable? Am I missing anything?

Declaring disconnected interfaces simply to be down as if they
had never been connected is probably a good deal more 
straightforward and less fraught with peril.

Joachim Martillo
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Richard Draves <[email-masked]>
Date: Fri, 15 Oct 1999 14:27:49 -0700

Yes, I am thinking ahead to the day when we will want mobile-node support in
MSR IPv6.

My thoughts so far:

Suppose mobility has been enabled and there was a home agent on the old
link.

Then when reconnecting to a link, do accelerated lifetime expiration for the
old addresses. If an RA arrives and extends the lifetimes, great, mobility
is not needed. However if an accelerated lifetime expires (but not if an
address lifetime expires normally), then the old address is a candidate for
becoming a home address.

At this point I'm not sure if the old address should just become a home
address automatically, or if there should be a UI to let the user confirm
they want this. Maybe there should be a different levels of mobility support
- never act as a mobile node, query the user when visiting a new link, vs
always act as a mobile node.

It can get complicated - what if the mobile node starts at a link A with a
home agent, moves to a link B with a home agent, then moves to a link C?
Does the link B address become a home address, so now it has home addresses
from link A and link B? When does a home address go away?

Of course, people don't always leave their machine turned on (or hibernated
or suspended) while wandering around, sometimes they actually shut them
down. We will have to store addresses in stable storage when shutting down
and then bring them back as home-address candidates when starting up.

I would be very interested in hearing from users & implementors of existing
mobile v6/v4 nodes. I suspect the current solutions involve lots of manual
configuration.

In any case, I think my plan for handling disconnection/reconnection can
evolve to handle mobility.

Rich

> -----Original Message-----
> From: Steve Deering [mailto:[email-masked]]
> Sent: Friday, October 15, 1999 6:46 AM
> To: Richard Draves
> Cc: 'IPng List'
> Subject: Re: reconnecting an interface
> 
> 
> At 11:40 PM -0700 10/14/99, Richard Draves wrote:
> >I'm trying to take advantage of this in MSR IPv6. Of course 
> I don't know if
> >the interface reconnected to the same subnet that it left. If it did
> >reconnect to the same subnet, then it seems reasonable for this to be
> >minimally intrusive to applications. If it reconnected to a different
> >subnet, then it seems reasonable to discard old information 
> learned from
> >auto-configuration and auto-configure anew.
> 
> As I pointed out in my "Plug & Play Architecture" talk at the Tokyo
> meeting, there will also arise the issue of when to treat a 
> "new" link 
> (i.e., the appearance of a new set of routers/prefixes/etc. on an
> interface) as a new "home" (i.e., the case where you should forget
> about your previous addresses) and when to treat it as a link being
> temporarily visited (i.e., the case where you should invoke the
> IPv6 mobility mechanisms to register your new addresses with your
> home agent, etc.).  If you haven't implemented mobile IP yet, then
> this issue won't arise, but you might want to keep that in mind as
> a possible future requirement.
> 
> (I think the normal behavior when a new link appears ought to be to
> treat it as a transient location and invoke the mobile IPv6 
> mechanisms,
> unless the user provides an explicit indication that it should be
> treated as a new home, e.g., by executing some UI command, or pressing
> a recessed button on the side of the IPv6 cell phone, or whatever.
> However, this all gets a lot more complicated when you start thinking
> nodes with multiple physical interfaces -- I wonder if the Mobile IP
> WG has sorted out all the variations and permutations?)
> 
> Steve
>

---

From: Richard Draves <[email-masked]>
Date: Sat, 16 Oct 1999 16:15:29 -0700

>    > => why not INCOMPLETE? Until the DAD is finished we can't use 
>    > our addresses.
>    
>    STALE means you know a link-layer address...
> 
> => but you don't know if you are on the same link... 
> INCOMPLETE is just
> more aggressive than STALE, if you are on the same link 
> you'll get extra
> traffic (no upper-layer reachability confirmation for instance),
> if you aren't on the same link STALE will lost some seconds in
> the DELAY state.

Hmm, let me think this through...

For a global-scope destination address in the neighbor cache: If you
reconnected to a different link, then hopefully the routing for that
destination will not think the address is on-link! (Ie the on-link prefix
list will change.) If routing does still treat the destination as on-link,
then it probably either is present and has the same link-layer address as
before, or it is not present at all. 

So maybe it's OK to leave the ND state of global-scope neighbors unchanged.
The main argument that I can think of for being more cautious is that while
disconnected you might have missed an unsolicited NA. Changing global-scope
REACHABLE neighbors to STALE seems like  a conservative thing to do.

For a link-local destination address: I agree more caution is warranted,
because a neighbor on the new link might be using the same link-local
address as a neighbor on the old link, but have a different link-layer
address. So either delete the neighbor cache entry entirely, or reset to
INCOMPLETE and clear the IsRouter bit, to be safe.

For a site-local destination address: You don't know that you are
reconnecting to the same link, or a link in the same site, so the analysis
for link-local applies.

For an anycast destination address: An anycast address looks like it's
global scope, but it might resolve to a different link-layer address on a
new link. In that situation, setting the neighbor cache entry to STALE would
introduce the latency of going through the DELAY state before connectivity
to the anycast destination address would be restored.

So the bottom line... I agree, deleting all the neighbor cache entries (or
setting to INCOMPLETE and clearing IsRouter) seems like the best thing. The
penalty (vs the alternative of using STALE for global-scope neighbors) is
extra network traffic when reconnecting to the same link. But it will avoid
the latency of the DELAY state in some cases and the extra traffic should be
relatively infrequent.

>    > => this is correct but has a real impact. I believe a flag 
>    > per interface
>    > is needed in order to do or not to do this.
>    
>    The impact (that the addresses are unusable until DAD 
> finishes) concerned me
>    also, until I realized that it's only a second (assuming 
> default values for
>    RetransTimer and DupAddrDetectTransmits).
> 
> => it is a bit more because you should wait a bit before launching
> the DAD because if there is a real problem on a shared device you must
> avoid synchronization (for instance some hubs drop the carrier when
> the uplink is down, a unplug/plug on the uplink of such a hub 
> will give
> simultaneous unplug/plug indications for a possibly large 
> number of nodes).
> (the recommended value is between 0 and MAX_RTR_SOLICITATION_DELAY=1)

Good point, so if the user plugs a cable back in the latency until the
interface addresses become usable again would be between one and two
seconds.
 
>    So the user plugs the cable back
>    in to the same link, and a second later TCP & UDP sockets 
> start working
>    again. I don't think a user will notice that latency.
>    
> => it depends... You should give the choice to the user.

Not another knob... this is not nearly important enough.

> (imagine the host is a dual-interface Web proxy, you should not put
> all the addresses of the interface to the Internet in the 
> tentavive state
> even for one second)

Why not? If I trip over the cable and get it plugged back in ten seconds
later, do I really care that there is a twelve-second outage instead of a
ten-second outage?
 
>    > => what to do for a router ???
>    
>    Send an RA immediately when reconnecting an advertising interface.
>    
> => this is the right thing if you are on the same link and 
> the wrong thing
> if you are on another link... Again!

I disagree, if the admin plugs the router interface into a new link, I would
assume that she knows she's doing. Perhaps while the interface was
unplugged, the admin reconfigured the router so the RA will carry different
information. In any case, best to send an RA quickly so the router becomes
visible on the link, whether it's the same link or a new link.

Thanks,
Rich

---

From: Richard Draves <[email-masked]>
Date: Sat, 16 Oct 1999 16:53:40 -0700

> I think this is a crucial difference -- consider the case where the
> system which got unplugged was a *server*, not a client (think of the
> "someone tripped over the hub's power cord" case).  If it got
> unplugged/replugged while the router was down, nobody on the LAN can
> use its services until the router comes back?  Seems pretty fragile to
> me..

I still think it's silly to expect the network (and in particular
autoconfigured global addresses) to work normally while the only router is
down. A server's manually configured global addresses would not be affected
by the mechanisms under discussion.

However... I have a modification that would do you want in this case and
also help with something that's been bothering me.

So now my plan for handling reconnect of a host interface is:
- delete all neighbor cache entries
- start sending router solicitations
- send out MLD reports, rejoining any multicast addresses assigned to the
interface
- put all unicast addresses into the tentative state and restart duplicate
address detection
- when the first RA is received, before processing it, set lifetimes of
everything learned previously from autoconfig (addresses, default routers,
on-link prefixes) down to a small value, accelerating the expiration of
potentially stale information
- if an address becomes invalid from accelerated lifetime expiration, then
it's a candidate for becoming a home address

So if you reconnect to the same link and the only router is temporily down,
then your autoconfigured addresses will remain valid, at least until their
lifetimes expire normally.

The other reason I like this is that I think the time constants can be such
that stale information will disappear sooner. Before I proposed using an
accelerated lifetime of MAX_RTR_SOLICITATIONS * RTR_SOLICITATION_INTERVAL,
plus I should have accounted for MAX_RTR_SOLICITATION_DELAY - so up to 13
seconds with default values.

When connecting to a new link, until the stale information is gone the
interface will not be very functional - best to get rid of the stale
information quickly.

Once an RA has arrived, the only issue is waiting for additional RAs that
might carry additional prefixes. I think it would be OK to use a smaller
default - say twice MAX_RA_DELAY_TIME, or one second.

Rich