Subject: reconnecting an interface

From: Richard Draves <[email-masked]>
Date: Thu, 14 Oct 1999 23:40:33 -0700

My driver interface can tell me when an interface is
disconnected/reconnected to its media. For example, I get an event when an
ethernet cable is unplugged and then another event when it's plugged back
in.

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.

My preliminary thoughts are:

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

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.

Does this sound reasonable? Am I missing anything?

Thanks,
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: [email-masked]
Date: Fri, 15 Oct 1999 15:52:51 +0900

>ethernet cable is unplugged and then another event when it's plugged back

	You may want to take a look at KAME nomadic node hack by Tatsuya
	Jinmei, which is described in section 3.4 of the following paper:
	http://www.isoc.org/inet99/proceedings/4s/4s_2.htm
	The code is available in normal KAME distribution and works well.

>- start sending router solicitations

	Hmm, KAME code takes care about neighbor cache, reachability of
	router (mangle default router list/prefix list), and RS/RA.
	It would be a good idea to do something for MLD and DAD as well.

itojun

---

From: Peter Tattam <[email-masked]>
Date: Fri, 15 Oct 1999 18:16:06 +1100 (EST)

Richard,  I already have this issue with multiple profiles in our stack.

I resolved it by completely flushing the ND cache for that interface and doing
a router solicit on all interfaces every time the config changes to get a fresh
view of the universe.

I would consider that pulling the ethernet cable out & plugging back again is
equivalent to a total reconfig, *unless* you still have active interfaces in
another media.

From the upper layers point of view, they continue to operate with the
addresses that they were initiated with.  This potentially allows me to change
config to another profile, do a bit of work, switch back to the original
profile and the TCP connections are still working.  I believe the TCP standard
permits this sequence of events.  Of course if the other end of the connections
decide that they want to terminate the connections, it is their business and
application running my host should be robust enough to deal with that
eventuality.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Francis Dupont <[email-masked]>
Date: Fri, 15 Oct 1999 11:10:30 +0200

In your previous mail you wrote:

=> I have the same concern for mobility then my current point-of-view is:
 - not all interfaces tell us when they are disconnected/reconnected
   (ie. for some interfaces you never receive an event)
 - it is hard to recognize immediately a disconnect then reconnect to
   another media from a glitch (for instance an "auto-drop" of the cable
   connected to an AUI :-)
 - for wireless interfaces the problem is even harder...
In fact the firmware of the interface has the same problem: it should
renegociate speed and halt/full duplex when the interface is reconnected
(of course it never does this). I believe the only correct way to play
this kind of game is to shutdown the interface before disconnect it
and to restart the interface after reconnect... This solves the whole
problem too.

=> it will be hard to convince people the second choice is the reasonnable
one then we'll fall in the first one and we'll know the subnet is not the
same at the first router advertisement, ie. too late for a DAD for instance...

   
=> I agree, we can't be too aggressive here because we should not kill
all the connections by a side effect.

=> why not INCOMPLETE? Until the DAD is finished we can't use our addresses.

=> I do the same thing at the first router advertisement from an unknown
router with new prefixes...

=> 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.

=> it is possible to rely on periodic MLD queries too.

=> this is the first thing to do, fortunately we don't need an address
for sending a router solicitation!

=> what to do for a router ???

=> this is why start sending router solicitations is a key point.

   Does this sound reasonable?

=> yes if the DAD/intrusive part can be disabled.

   Am I missing anything?
   
=> the router case. And propose a 10kV new version of Ethernet to IEEE
in order to discourage unplug/plug of Ethernets (:-)...

Regards

[email-masked]

---

From: [email-masked]
Date: Fri, 15 Oct 1999 19:43:03 +0900

>Has this only recently been added to the Kame distribution? On
>NetBSD-current-Sep-4/Kame and fairly recent FreeBSD-3.2/Kame, I noticed

	No, this has been in in the tree for more than a year.

>that when an interface address is removed it doesn't seem to result
>in removal of the associated `permanent' ND-cache entry and the 
>routing table entry for it. I ahven't looked into it much, I stumbled
>accross it by accident last week and noticed I needed to manually
>remove ND-cache and router entries. Did i miss something? I saw
>this for both removal of addresses by expiration of autoconfig-ed
>addresses (address became depricated) and manual removal with
>`ifconfig ... delete'.

	Please give me more specific information.  What kind of RA
	do you advertise from your router?  Do you advertise infinite
	lifetime on RA?

	The code works like this.

	1. I'm hooked to my home network, 3ffe:501:410::/48. 

sm1: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	address: 00:00:86:05:80:fa
	media: Ethernet 10baseT
	inet 202.232.15.102 netmask 0xfffffff8 broadcast 202.232.15.103
	inet6 fe80:1::200:86ff:fe05:80fa prefixlen 64
	inet6 3ffe:501:410:1:200:86ff:fe05:80fa prefixlen 64

	2. I move to my office, get an RA there.  I get a new prefix.
	   The address from my home will be marked as "detached" as the
	   advertising router becomes unreachable.  Detached address
	   will not be used as source address.

sm1: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	address: 00:00:86:05:80:fa
	media: Ethernet 10baseT
	inet 202.232.15.102 netmask 0xfffffff8 broadcast 202.232.15.103
	inet6 fe80:1::200:86ff:fe05:80fa prefixlen 64
	inet6 3ffe:501:410:1:200:86ff:fe05:80fa prefixlen 64 detached
	inet6 3ffe:507:0:1:200:86ff:fe05:80fa prefixlen 64

	3. If you look at prefix list with ndp -p, you will see "no advertising
	   router" on the list.

itojun

---

From: Steve Deering <[email-masked]>
Date: Fri, 15 Oct 1999 06:46:02 -0700

>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: Feico Dillema <[email-masked]>
Date: Fri, 15 Oct 1999 14:41:27 +0200

> 	do you advertise from your router?  Do you advertise infinite
No.
 
> 	3. If you look at prefix list with ndp -p, you will see "no advertising

1, 2 and 3 worked for me also as you described. Here's my current ndp -p 
on one of the hosts in question:

dillema# ndp -p
3ffe:2a00:100:3002::/64 if=le0
  flags=LA vltime=2592000, pltime=604800, expire=25d7h12m6s
  No advertising router
3ffe:2a00:100:3001::/64 if=le0
  flags=LA vltime=3600000, pltime=3600000, expire=41d15h59m10s
  advertised by
    fe80::280:1cff:fe5d:301c

The router on this link (NetBSD/kame) recently got an hardware
upgrade, and after it was booted again it had its ethernet
interfaces switched. It only advertises a prefix on one of its
interfaces, so due to the switch it sent out a RA on the wrong 
link. The hosts on this link used this RA (prefix
3ffe:2a00:100:3002::/64) to autoconfig a second address for 
their interface (the first prefix 3ffe:2a00:100:3001::/64
is advertised by another router).  I quickly switched the
Ethernet interfaces on this router again, so that the
RA were sent over the correct link once again. 

The `second addresses' soon were marked detached and almost 
everything worked just fine. Almost, because I noticed
that hosts on the 3ffe:2a00:100:3001:: network (with
a 3ffe:2a00:100:3002:: address marked as detached) couldn't
communicate to hosts on the `real' 3ffe:2a00:100:3002:: 
network. A `ndp -a' on these hosts showed there was still
a permanent entry for their detached 3ffe:2a00:100:3002::
address, and a tcpdump showed that these hosts still 
believed 3ffe:2a00:100:3002:: machines could be found on
the local link by sending out neighbour solicitations for
them.

I fixed this manually using `ndp -d' and `route delete' 
on the entries for 3ffe:2a00:100:3002::. I assume these
are removed automatically when the address/prefix actually
expires, but not when its preferred lifetime has passed?

I realize this is a weird situation (a router moved and
was `mobile' for a while, instead of a host) and I'm not
sure whether it can be dealt with automatically within
the IPv6 specs. I'd just like to understand what and why
this happened, and if it can be prevented. I can imagine
that accidents or temporarily misconfiguration of routers
like this might not be entirely rare, and if the consequence
is that fixing such a mistake involves fixes at all 
autoconfig-ed hosts... Well, I guess you get the picture...

Feico.

---

From: Feico Dillema <[email-masked]>
Date: Fri, 15 Oct 1999 12:32:40 +0200

I was wondering about the permanent entries in ND-cache like:

3ffe:2a00:100:3001:260:b0ff:f 0:60:b0:a4:da:73      le0  permanent R      

shouldn't permanent be changed into the lifetime of the interface
address, like in:

# ifconfig -L le0
le0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
...
        inet6 3ffe:2a00:100:3001:260:b0ff:fea4:da73 prefixlen 64 pltime 3599988 vltime 3599988

Feico.