Subject: RE: reconnecting an interface

From: Richard Draves <[email-masked]>
Date: Fri, 15 Oct 1999 15:19:07 -0700

>    2. When reconnecting to media: 
>    - set REACHABLE neighbor cache entries to the STALE state
> 
> => why not INCOMPLETE? Until the DAD is finished we can't use 
> our addresses.

INCOMPLETE seems too strong, it means that you don't have a clue about the
link-layer address. STALE means you know a link-layer address but it has not
been validated recently. Seems more appropriate.

>    - 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)
> 
> => I do the same thing at the first router advertisement from 
> an unknown
> router with new prefixes...

In the course of normal operation??? So if I configure a new router to
advertise a new prefix, then it disrupts the old prefix being advertised by
the old router? Seems wrong.

>    - put all unicast addresses into the tentative state and 
> restart duplicate
>    address detection
> 
> => 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). 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.

> => what to do for a router ???

Send an RA immediately when reconnecting an advertising interface.

Rich
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Sat, 16 Oct 1999 14:29:50 +0200

In your previous mail you wrote:

=> to do the best choices something like a layer 2 link identifier
is needed (because it is the right way to know if the link is the
same or another one). Of course there is no such thing for Ethernet
but IEEE 802.11 has an IBSS name.

   > => why not INCOMPLETE? Until the DAD is finished we can't use 
   
   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.
   
   > an unknown router with new prefixes...
   
   In the course of normal operation???

=> only when mobility support and unplug/plug game on the interface
are enabled.

   So if I configure a new router to advertise a new prefix,
   then it disrupts the old prefix being advertised by the old router?

=> if a junk new router is badly configurated in order to announce
junk new prefixes then I'll give short lifetimes to old prefixes, etc.
(see after for the meaning of short here)

   Seems wrong.

=> and of course I send some router solicitations then if the old
router with the old prefixes is still there I'll receive soon (ie.
before expiration) a good router advertisement with the old prefixes
(ie. a confirmation).
 When this kind of movement detection is used for a mobile node
the RS/RA procedure gives to you the good timing, below you can
detect spurious movements, over it takes too much time to detect
a real one.

   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)

   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.
(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)

   
=> this is the right thing if you are on the same link and the wrong thing
if you are on another link... Again!

Regards

[email-masked]