Subject: Re: [homenet] section 3.2.2.1 of homenet-arch

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Aug 2012 08:40:58 +0100

Excuse front posting, but...

> Today there is no DHCP help in avoiding the "please reboot" messages.

Don't RECONFIGURE (DHCPv6) and FORCERENEW (DHCP) cover this, in theory?
They are unicast, which is a scaling issue in enterprise networks but
presumably not in homenets.

Regards
   Brian

On 01/08/2012 04:33, Curtis Villamizar wrote:
> In message <[email-masked]>
> Brian E Carpenter writes:
>  
>> On 31/07/2012 17:59, Michael Richardson wrote:
>>>>>>>> "Brian" == Brian E Carpenter <Brian> writes:
>>>     >> I'm also surprised that we think we have to cope with flash renumbering
>>>     >> as a regular event, rather than a service-interrupting, ISP truck roll
>>>     >> catastrophy. 
>>>
>>>     Brian> But every time you reboot your antiquated v4-only CPE
>>>     Brian> and/or the antiquated 
>>>     Brian> v4-only PCs behind it, the PCs all get new IP addresses,
>>>     Brian> which may or
>>>     Brian> may not be the same as the previous time. There's nothing
>>>     Brian> new in flash 
>>>     Brian> renumbering for homenets. Not handling this would be a step
>>>     Brian> backwards.
>>>
>>> Well... 
>>>
>>> 1) sure, but the *customer* does this, not the ISP.
>>> 2) the clients do have DHCP leases, and if they ask to renew their
>>>    previous IP, it usually gets honored.
>>  
>> It doesn't matter whether it's the user or the ISP that triggers a
>> change, does it?
>>  
>> The point is, users don't care about this, except if they reach their
>> shiny new wireless printer via its IP static address. There are
>> definitely parts of draft-ietf-6renum-static-problem that apply here.
>>  
>>    Brian
> 
> 
> Brian,
> 
> Enterprise renumbering and homenet renumbering are generally quite
> different.  Most homehets have short uptimes.  Most enterprises have
> very long uptimes.  (insert favorite Microsoft reliability joke here).
> 
> If a renumbering is done right, there is an time when both the old and
> new numbers are in use.  As in "ifconfig <intf> inet6 newaddr
> ... alias" in the *ix world.  During that transition time any use of
> DHCP will hand out the new address.  Then comes a time when the leases
> refuse to be renewed.  Then the old addresses go away.  This can be
> day, weeks, or longer depending on the size of the transition.  During
> that time a lot of "please reboot at least once ..." messages get
> sent.
> 
> Today there is no DHCP help in avoiding the "please reboot" messages.
> It should be possible for a DHCP client (ISC guys, are you out there?)
> to do the following if a lease can't be renew and a new address is
> provided:
> 
>   1.  Add the new address using an "ifconfig <intf> ... alias"
>       equivalent.
> 
>   2.  Check (using netstat -an equivalent) for use of the old address.
>       Don't delete the old address if a socket still exists.
> 
>   3.  Periodically repeat step 2 until there is no connection using
>       the old address.
> 
>   4.  Delete the old address using the equivalent of "ifconfig <intf>
>       ... -alias".
> 
> This would work for all client side connects that either were done
> before the end of the transition period.  For home nets this covers
> 99.something percent of the sites with no user intervention or reboot.
> 
> This requires no protocol change, just better coding in the DHCP
> client software.
> 
> What this does not cover is a service that is listenning on a well
> known port.  This is rare among home nets (except for homes of readers
> of IETF lists) but very common among enterprises.
> 
> Many points made about license servers, etc in
> draft-ietf-6renum-static-problem don't apply to home nets.
> 
> Renumbering an enterprise is doable.  Renumbering my home net has been
> quite easy.  I've done it a few times already and I'm sure will have
> to again.  The procedure suggested above is just done manually.
> 
> One hint is that on BSD and Linux at least a "netstat -an" should
> reveal any listens on old addresses.  An automated scan on an
> enterprise network can identify servers and services needing a
> reconfig and a service restart without any system reboot.  [ Microsoft
> systems may need to reboot or power down and remove the CMOS battery
> from the motherboard or maybe buy new hardware.  :-) ]
> 
>>> In IPv6 space, the host part will generally stay the same (modulo
>>> privacy extensions, which are default on for some clients).  We've said
>>> that the ULA ought to stay the same, so in fact, I agree, the internal
>>> addresses actually all stay the same.
>>>
>>> I'm still surprised that an ISP will need to flash renumber faster than
>>> it can just expire leases.  If it's just repartitioning of network to
>>> deal with growth, that ought to be predictable and prefix lifetimes can
>>> be reduced in advance.  
>>>
>>> If it's actually some equipment failing, resulting in service
>>> interruptions, and then restoration by rewiring the network... then I
>>> understand.  
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 01 Aug 2012 18:20:04 +1000

> very long uptimes.  (insert favorite Microsoft reliability joke here).

Define short?  There are plenty of homes with equipment that isn't
powered down every day and that has been up for months.

I don't know about other but I maintain ssh connections for weeks
from home to the main office at work.

> that time a lot of "please reboot at least once ..." messages get

What's the dhcp stuff in the home?  RA's work fine here.  What is
needed is a way to signal in the DNS to only use a deprecated address
as a last resort measure.  Named to address and address to name
mappings need to exist until after the address has ceased being
used.

>   4.  Delete the old address using the equivalent of "ifconfig <intf>

Actually you should be asking the OS vendors / distro maintainers
to do this and send fixes to ISC.  This is all done in shell scripts
that are highly customised to the client platform.  There isn't one
linux script that works for all linux distros.

This also doesn't work for many udp based services.

> of IETF lists) but very common among enterprises.

At the moment.  There is no good reason to not be listening on
standard ports if you want to provide your own servers within the
home.  DNS will almost certainly be done if only to as hidden
masters.  Just publish your current addresses in the DNS and they
can be reached.  Cable and DSL are always on services.  Homes are
no longer dialup.

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 01 Aug 2012 10:39:01 -0400

In message <[email-masked]>
 
> presumably not in homenets.

These only force a renew before the lease expires.  For the sometimes
very long IPv6 leases, this is essential.  For often relatively
shorter IPv4 leases, it is nice but not quite as essential.

The issue is not forcing the renew to occur earlier, it is the way in
which a renew that changes the address is handled.  Maybe its just
implementations taking a shortcut, but I think in practice changing
the IP address takes the interface down, kills all connections,
including listens, and then brings it back up with a new address.  Its
a bit like a reboot as implemented, except the user doesn't know its
coming and therefore may have open TCP connections that break.

What I've suggested is what to do on a renew that changes the address.
Add an alias.  Until the old address has no more connections or
listens on the old address, keep the old address.  Then remove the old
address.

If someone has an open connection, ssh for example, the old address
could be in use indefinitely, but if the transition is weeks, then its
unlikely to go beyond that.  For example, if someone was using ssh to
do a long compile on another machine, breaking the connection and
killing the compile would be bad.  There are certain to be plenty of
other uses of long duration TCP connections that would have to be
broken in this sort of transition, unless we can also extend TCP to
negotiate a change to one side of the address pair.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 01 Aug 2012 11:18:08 -0400

> powered down every day and that has been up for months.

As long as the equipment is idle, an attempted renew on the DHCP lease
that fails won't hurt unless it causes something to hang.  Microsoft
has trained users to be used to power cycling things for no apparent
reason.

> from home to the main office at work.

I've been know to do that.  For long compiles I've learned to use
"nohup" and keep a log file that I can check on now and then.

> mappings need to exist until after the address has ceased being

Below is what the CPE and host need to do.  The provider also needs to
keep around the old rDNS until the old address is no longer in use.
The provider needs to 1) grant new leases from the new number space,
2) request that users force a renew themselves in case there would be
any disruption, 3) allow time for users to force a renew, 4) force a
renew and refuse torenew the old leases, granting new ones (may be
disruptive to some), 4) allow more time, then completely get rid of
the old address space.

> This also doesn't work for many udp based services.

You are right.  There are other retained IP addresses.  For example, a
DNS secondary might try to renew a lease based on the old address
until the primary name server DNS AAAA entry TTL expires.  Perhaps a
minimum time in which there is no use of the old address is necessary.
Note that netstat -in on *ix reports statistics per alias so it is
possible to detect when a specific address has gone idle for a long
time, but there is no guarentee that it won't ever be used again.

> can be reached.  Cable and DSL are always on services.  Homes are

The CPE router may stay up but the hosts get shut down.  The concern
about changing addresses and breaking something is related more to the
hosts (computers, set top box, etc).  A SIP phone is a concern.

A server can bind to 0/0 and ::/0.  If some interfaces are to be
excluded (or you run BSD jails), then services have to bind to
addresses.  Most of those services read the address from a
configuration file and need a change to the configuration and may need
to be nudged or restarted after the configuration change.

A DNS server for example, may filter on many addresses in its config.
Which nets to allow queries from, which to allow zone transfers to,
where to find forwarders, etc.

It should be easy enough to nudge or restart servers within the CPE
when addresses change.  It is less easy for the CPE to insure that the
hosts have been successful in the address change.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Aug 2012 11:02:21 +0100

On 01/08/2012 15:39, Curtis Villamizar wrote:
> including listens, and then brings it back up with a new address. 

Really? I can't test it in my current native-IPv6-deprived state, but
it seems to me that Windows (at least) runs happily with multiple IPv6
addresses on one interface, and I can't imagine that changing one of them
will kill the others. I have to admit I haven't studied the semantics
of RECONFIGURE closely, though.

The RFC 4192 model would look a bit sick if the interfaces get reset.

    Brian

 Its

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Aug 2012 10:18:24 -0400

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:
    Brian> Really? I can't test it in my current native-IPv6-deprived
    Brian> state, but it seems to me that Windows (at least) runs
    Brian> happily with multiple IPv6 addresses on one interface, and I

Linux too, and sometimes this is a bad thing.
If you suspend/resume between home/work wired, I've had the problem
where I can't reach the other because said address still lingering on
interface makes my laptop think it's still "on the wire" with both.
(you have to suspend-then-unplug, otherwise, disconnecting the cable
works as a clue to flush the addresses)

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 3 Aug 2012 07:44:50 +0200 (CEST)

> works as a clue to flush the addresses)

I complained about this on ubuntu before, and at least the connection 
manager in Ubuntu 12.04 does the right thing now.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 07 Aug 2012 11:39:32 -0400

In message <[email-masked]>

Brian,

Aliases (more than one address on the same interface) has worked on
every OS for a decade at least.

The issue is more what occurs when a lease is withdrawn (force to
renew and won't renew) and another lease is provided with a different
address.  AFAIK most implementations take that interface down and
bring it back up.

They do not keep the old address as an alias for some period of time
but put new connections on the new address.

Curtis

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Aug 2012 19:09:10 +0100

On 07/08/2012 16:39, Curtis Villamizar wrote:
> Aliases (more than one address on the same interface) 

Aliases, as you describe them, sound like a hack. I'd like to
hear from Microsoft (for example) whether their support of multiple
IPv6 addresses per interface is a hack or genuine. I don't care
about IPv4, but the IPv6 model is very clear. You can't read the
ND spec and imagine the arrival of a new address resetting sessions
that use other addresses.

   Brian

> has worked on

---

From: Benjamin Kerensa <[email-masked]>
Date: Tue, 7 Aug 2012 11:20:05 -0700

> linux script that works for all linux distros.

Unfortunately this is true and this hopefully in the future will be more
standardized.

> can be reached.  Cable and DSL are always on services.  Homes are

I disagree with the assertion that "Homes" are no longer on dial-up since a
good portion of Rural America still does not have Broadband which means
millions are still on Dial-Up and I hear parts of Europe still use Dial-Up.

-- 
Benjamin Kerensa
*Team Lead, *Ubuntu Oregon
http://ubuntu-oregon.org
Phone: 503-894-6005 x701
 <http://facebook.com/bkerensa>  <http://twitter.com/bkerensa>
<https://plus.google.com/u/0/115750270177636397262>
  <http://www.stumbleupon.com/stumbler/bkerensa/>  <http://flickr.com/bkerensa>
  <http://benjaminkerensa.com/>  <http://wiki.ubuntu.com/bkerensa>
<http://www.last.fm/user/bkerensa>

*This message may contain information which is privileged or confidential.
If you are not the named addressee of this message please destroy it
without reading, using, copying or disclosing its contents to any other
person.*
*
*

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Aug 2012 14:31:44 -0400

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:
    Brian> Aliases, as you describe them, sound like a hack. I'd like to
    Brian> hear from Microsoft (for example) whether their support of
    Brian> multiple IPv6 addresses per interface is a hack or genuine. I
    Brian> don't care about IPv4, but the IPv6 model is very clear. You
    Brian> can't read the ND spec and imagine the arrival of a new
    Brian> address resetting sessions that use other addresses.

On Linux and *BSD, (possibly including OSX, but I don't know, but I
could do an experiment with my officemate), new addresses get added
without an interface flap.
Old addresses expire as they expire, no interface flap need occur.
Linux does this all in the kernel, *BSD does it in rtsold.
I can't speak of what happens with dhcpv6.

The choice of which one to use for new connections essentially depends
upon the metrics on the route to that destination.  Typically, for
off-link destinations, it's the default route that matters.

Where I think we see interface flaps is as a result of DHCPv4.
If we lose connectivity to the DHCPv4, then the dhclient-daemon will
reset the interface and start again.  With wifi, this is often more
frequent.  I have had IPv6 connections survive such events, but not
always.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 07 Aug 2012 18:35:25 -0400

In message <[email-masked]>
 
> Michael Richardson <[email-masked]>, Sandelman Software Works

When in doubt RTFC.  Digression follows, possibly with something
relevant at the end, but maybe more for DHC WG.

  dhclient.c makes use of dhclient-script

  BOUND|RENEW|REBIND|REBOOT)
        check_hostname
        if [ -n "$old_ip_address" ]; then
                if [ "$old_ip_address" != "$alias_ip_address" ]; then
                        delete_old_alias
                fi
                if [ "$old_ip_address" != "$new_ip_address" ]; then
                        delete_old_address
                        delete_old_routes
                fi
        fi

That look to me like the old address is deleted, *then* the new
address is added whenever the lease that has been selected out of
multiple offers is not the one that had previously been selected.

This is dhclient on freebsd which is a DHCPv4 client.

Looking at the ISC DHCP client (also dhclient, but with DHCPv6
support) I find much different code.

  if [ ${reason} = BOUND6 ] ; then
    # ...
    ifconfig ${interface} inet6 ${new_ip6_address}/${new_ip6_prefixlen} alias
    # ...
    exit_with_hooks 0
  fi

  if [ ${reason} = EXPIRE6 -o ${reason} = RELEASE6
       -o ${reason} = STOP6 ] ; then
    # ...
    ifconfig ${interface} inet6 ${old_ip6_address}/${old_ip6_prefixlen} -alias
    # ...
    exit_with_hooks 0
  fi

In this case, an expire or release is needed to remove an old lease.

It may be that if your DHCP server never had the chance to remove a
lease and you did suspend and plug in somewhere else and get a new
lease, then the old lease will hang around until it expires,
potentially days.  That may be a bug.

Your Linux box is then left free to bind new sockets to the old
address and there is no way to mark it as old and avoid it.

The behaviour I suggested earlier was (briefly):

  1.  Install new address as an alias (ie: ifconfig ... alias)
  2.  Avoid binding sockets to old address (see below)
  3.  Make sure old address is no longer in use (as best as possible),
      then remove old address with a -alias (ie: ifconfig ... -alias).

That is not what is being done in either case.

There is currently no kernel mechanism for step 2 above.  (Note:
prefer_source is close but not quite).  What is needed is something
that modifies an alias such that it is not considered in the selection
but keeps it.  (Possible syntax: "ifconfig ... stale" where stale
replaces the alias or -alias, modifying an existing alias).  A new
interface address flag (as in ifa_flags) might do the trick if used
with the SIOCAIFADDR ioctl, however ifaliasreq doesn't have a place
for a set of flags.  It could be that IFF_DYING could be set on the
ifa_flags in the struct ifaddr contained in either struct in6_ifaddr
or struct in_ifaddr.  IFF_DYING can currently be set on an interface
but not on an address and it is only set internally to the kernel.  It
is only referenced in sys/net/if.c in all of the BSD source and there
only four places.  This would be an appropriate reuse of that flag bit
that would not conflict with the existing use (in the ifnet struct).

In any case, this is more appropriate for DHC (if at all) and even DHC
isn't chartered with patching the kernel, or changing ifconfig and isc
dhcp client, but it could recommend behavior when the lease changes.

Curtis

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Aug 2012 16:23:06 +1000

In message <[email-masked]>
> millions are still on Dial-Up and I hear parts of Europe still use Dial-Up.

The argument being made was that homes don't have long lived connections
and that isn't true anymore.  The majority of homes are always on.  This
percentage will continue to increase.

As of 2006[1] the majority of households in Australia had Internet connections
and the majority of those were classed as broadband.  The 2011 data isn't
available yet but will be before the end of August.

Even in the bush it isn't dialup, it's radio links of one form or another.

Mark

[1] http://www.censusdata.abs.gov.au/ABSNavigation/prenav/ViewData?action=404&documentproductno=0&documenttype=Details&order=1&tabname=Details&areacode=0&issue=2006&producttype=Census%20Tables&javascript=true&textversion=false&navmapdisplayed=true&breadcrumb=LPTD&&collection=Census&period=2006&productlabel=Type%20of%20Internet%20Connection%20by%20Number%20of%20Persons%20Usually%20Resident%20by%20Household%20Composition&producttype=Census%20Tables&method=Place%20of%20Usual%20Residence&topic=Dwellings&
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 08 Aug 2012 11:04:21 -0400

In message <[email-masked]>

Brian,

An alias is a second (or third or fourth) address bound to an
interface.  The name alias comes from the 2+ decades old "ifconfig
... alias" syntax.  Every dual stack host uses aliases - it has an
IPv4 address and more than one IPv6 address.  This is also true of an
IPv6 only interface with interface local, ULA, and GUA addresses.

Every router with a GUA on the loopback (most likely every one
deployed in a major provider) has a ::1 and the GUA as an alias on the
loopback.  Cisco added a loopback over 15 years ago just to support
this.  The purpose is to have a routable address that remains
regardless of which forwarding cards fail or get pulled out.

In modern implementations, once an alias is installed, it is no
different from the original address.  You can remove the original and
keep the alias, which at one point you couldn't do.  That is the most
significant change to aliases in decades and has also been around a
very long time.

Aliases are critical to renumbering so that a transition period can
exist while the renumbering process is in progress with no disruption
at all to hosts as they are renumbered.

> > every OS for a decade at least.

Aliases have been around in BSD for more than two decades and existed
before Microsoft had an IP stack in their product and before Linux
existed.  I would hope that by now *even Microsoft* has got it right.

Curtis

> >>> coming and therefore may have open TCP connections that break.

BTW - "It" in this context is the existing delete old address, then
add new address behavior of DHCP.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 08 Aug 2012 11:23:02 -0400

Benjamin Kerensa writes:
 
> --e89a8f234cc38c7df504c6b10d5c
> Content-Type: text/plain; charset=ISO-8859-1
>  

Can someone, maybe someone from ISC, suggest an OS vendor neutral
mailing list where this thread can be continued.

I've done a little preliminary poking into code, both BSD kernel code
and ISC DHCP and would be willing to help.

Curtis

> --e89a8f234cc38c7df504c6b10d5c
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>  
> <br><br><div class=3D"gmail_quote">On Wed, Aug 1, 2012 at 1:20 AM, Mark And=
> rews <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=
> k">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
>  style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>  
> <div class=3D"HOEnZb"><div class=3D"h5"><br>
> In message &lt;<a href=3D"mailto:[email-masked]=
> ccnc.com">[email-masked]</a>&gt;, Curti=
> s Villamizar writes:<br>
> &gt;<br>
> &gt; In message &lt;<a href=3D"mailto:[email-masked]">50181A1C.=
> [email-masked]</a>&gt;<br>
> &gt; Brian E Carpenter writes:<br>
> &gt;<br>
> &gt; &gt; On 31/07/2012 17:59, Michael Richardson wrote:<br>
> &gt; &gt; &gt;&gt;&gt;&gt;&gt;&gt; &quot;Brian&quot; =3D=3D Brian E Carpent=
> er &lt;Brian&gt; writes:<br>
> &gt; &gt; &gt; =A0 =A0 &gt;&gt; I&#39;m also surprised that we think we hav=
> e to cope with flash renumbering<br>
> &gt; &gt; &gt; =A0 =A0 &gt;&gt; as a regular event, rather than a service-i=
> nterrupting, ISP truck roll<br>
> &gt; &gt; &gt; =A0 =A0 &gt;&gt; catastrophy.<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt; =A0 =A0 Brian&gt; But every time you reboot your antiquated =
> v4-only CPE<br>
> &gt; &gt; &gt; =A0 =A0 Brian&gt; and/or the antiquated<br>
> &gt; &gt; &gt; =A0 =A0 Brian&gt; v4-only PCs behind it, the PCs all get new=
>  IP addresses,<br>
> &gt; &gt; &gt; =A0 =A0 Brian&gt; which may or<br>
> &gt; &gt; &gt; =A0 =A0 Brian&gt; may not be the same as the previous time. =
> There&#39;s nothing<br>
> &gt; &gt; &gt; =A0 =A0 Brian&gt; new in flash<br>
> &gt; &gt; &gt; =A0 =A0 Brian&gt; renumbering for homenets. Not handling thi=
> s would be a step<br>
> &gt; &gt; &gt; =A0 =A0 Brian&gt; backwards.<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt; Well...<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt; 1) sure, but the *customer* does this, not the ISP.<br>
> &gt; &gt; &gt; 2) the clients do have DHCP leases, and if they ask to renew=
>  their<br>
> &gt; &gt; &gt; =A0 =A0previous IP, it usually gets honored.<br>
> &gt; &gt;<br>
> &gt; &gt; It doesn&#39;t matter whether it&#39;s the user or the ISP that t=
> riggers a<br>
> &gt; &gt; change, does it?<br>
> &gt; &gt;<br>
> &gt; &gt; The point is, users don&#39;t care about this, except if they rea=
> ch their<br>
> &gt; &gt; shiny new wireless printer via its IP static address. There are<b=
> r>
> &gt; &gt; definitely parts of draft-ietf-6renum-static-problem that apply h=
> ere.<br>
> &gt; &gt;<br>
> &gt; &gt; =A0 =A0Brian<br>
> &gt;<br>
> &gt;<br>
> &gt; Brian,<br>
> &gt;<br>
> &gt; Enterprise renumbering and homenet renumbering are generally quite<br>
> &gt; different. =A0Most homehets have short uptimes. =A0Most enterprises ha=
> ve<br>
> &gt; very long uptimes. =A0(insert favorite Microsoft reliability joke here=
> ).<br>
> <br>
> </div></div>Define short? =A0There are plenty of homes with equipment that =
> isn&#39;t<br>
> powered down every day and that has been up for months.<br>
> <br>
> I don&#39;t know about other but I maintain ssh connections for weeks<br>
> from home to the main office at work.<br>
> <div class=3D"im"><br>
> &gt; If a renumbering is done right, there is an time when both the old and=
> <br>
> &gt; new numbers are in use. =A0As in &quot;ifconfig &lt;intf&gt; inet6 new=
> addr<br>
> &gt; ... alias&quot; in the *ix world. =A0During that transition time any u=
> se of<br>
> &gt; DHCP will hand out the new address. =A0Then comes a time when the leas=
> es<br>
> &gt; refuse to be renewed. =A0Then the old addresses go away. =A0This can b=
> e<br>
> &gt; day, weeks, or longer depending on the size of the transition. =A0Duri=
> ng<br>
> &gt; that time a lot of &quot;please reboot at least once ...&quot; message=
> s get<br>
> &gt; sent.<br>
> <br>
> </div>What&#39;s the dhcp stuff in the home? =A0RA&#39;s work fine here. =
> =A0What is<br>
> needed is a way to signal in the DNS to only use a deprecated address<br>
> as a last resort measure. =A0Named to address and address to name<br>
> mappings need to exist until after the address has ceased being<br>
> used.<br>
> <div class=3D"im"><br>
> &gt; Today there is no DHCP help in avoiding the &quot;please reboot&quot; =
> messages.<br>
> &gt; It should be possible for a DHCP client (ISC guys, are you out there?)=
> <br>
> &gt; to do the following if a lease can&#39;t be renew and a new address is=
> <br>
> &gt; provided:<br>
> &gt;<br>
> &gt; =A0 1. =A0Add the new address using an &quot;ifconfig &lt;intf&gt; ...=
>  alias&quot;<br>
> &gt; =A0 =A0 =A0 equivalent.<br>
> &gt;<br>
> &gt; =A0 2. =A0Check (using netstat -an equivalent) for use of the old addr=
> ess.<br>
> &gt; =A0 =A0 =A0 Don&#39;t delete the old address if a socket still exists.=
> <br>
> &gt;<br>
> &gt; =A0 3. =A0Periodically repeat step 2 until there is no connection usin=
> g<br>
> &gt; =A0 =A0 =A0 the old address.<br>
> &gt;<br>
> &gt; =A0 4. =A0Delete the old address using the equivalent of &quot;ifconfi=
> g &lt;intf&gt;<br>
> &gt; =A0 =A0 =A0 ... -alias&quot;.<br>
> <br>
> </div>Actually you should be asking the OS vendors / distro maintainers<br>
> to do this and send fixes to ISC. =A0This is all done in shell scripts<br>
> that are highly customised to the client platform. =A0There isn&#39;t one<b=
> r>
> linux script that works for all linux distros.<br></blockquote><div><br></d=
> iv><div>Unfortunately this is true and this hopefully in the future will be=
>  more standardized.</div><div>=A0</div><blockquote class=3D"gmail_quote" st=
> yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>  
>  
> <br>
> This also doesn&#39;t work for many udp based services.<br>
> <div class=3D"im"><br>
> &gt; This would work for all client side connects that either were done<br>
> &gt; before the end of the transition period. =A0For home nets this covers<=
> br>
> &gt; 99.something percent of the sites with no user intervention or reboot.=
> <br>
> &gt;<br>
> &gt; This requires no protocol change, just better coding in the DHCP<br>
> &gt; client software.<br>
> &gt;<br>
> &gt; What this does not cover is a service that is listenning on a well<br>
> &gt; known port. =A0This is rare among home nets (except for homes of reade=
> rs<br>
> &gt; of IETF lists) but very common among enterprises.<br>
> <br>
> </div>At the moment. =A0There is no good reason to not be listening on<br>
> standard ports if you want to provide your own servers within the<br>
> home. =A0DNS will almost certainly be done if only to as hidden<br>
> masters. =A0Just publish your current addresses in the DNS and they<br>
> can be reached. =A0Cable and DSL are always on services. =A0Homes are<br>
> no longer dialup.<br></blockquote><div><br></div><div>I disagree with the a=
> ssertion that &quot;Homes&quot; are no longer on dial-up since a good porti=
> on of Rural America still does not have Broadband which means millions are =
> still on Dial-Up and I hear parts of Europe still use Dial-Up.=A0</div>
>  
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> <div class=3D"HOEnZb"><div class=3D"h5"><br>
> &gt; Many points made about license servers, etc in<br>
> &gt; draft-ietf-6renum-static-problem don&#39;t apply to home nets.<br>
> &gt;<br>
> &gt; Renumbering an enterprise is doable. =A0Renumbering my home net has be=
> en<br>
> &gt; quite easy. =A0I&#39;ve done it a few times already and I&#39;m sure w=
> ill have<br>
> &gt; to again. =A0The procedure suggested above is just done manually.<br>
> &gt;<br>
> &gt; One hint is that on BSD and Linux at least a &quot;netstat -an&quot; s=
> hould<br>
> &gt; reveal any listens on old addresses. =A0An automated scan on an<br>
> &gt; enterprise network can identify servers and services needing a<br>
> &gt; reconfig and a service restart without any system reboot. =A0[ Microso=
> ft<br>
> &gt; systems may need to reboot or power down and remove the CMOS battery<b=
> r>
> &gt; from the motherboard or maybe buy new hardware. =A0:-) ]<br>
> &gt;<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt; In IPv6 space, the host part will generally stay the same (m=
> odulo<br>
> &gt; &gt; &gt; privacy extensions, which are default on for some clients). =
> =A0We&#39;ve said<br>
> &gt; &gt; &gt; that the ULA ought to stay the same, so in fact, I agree, th=
> e internal<br>
> &gt; &gt; &gt; addresses actually all stay the same.<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt; I&#39;m still surprised that an ISP will need to flash renum=
> ber faster than<br>
> &gt; &gt; &gt; it can just expire leases. =A0If it&#39;s just repartitionin=
> g of network to<br>
> &gt; &gt; &gt; deal with growth, that ought to be predictable and prefix li=
> fetimes can<br>
> &gt; &gt; &gt; be reduced in advance.<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt; If it&#39;s actually some equipment failing, resulting in se=
> rvice<br>
> &gt; &gt; &gt; interruptions, and then restoration by rewiring the network.=
> .. then I<br>
> &gt; &gt; &gt; understand.<br>
> &gt; _______________________________________________<br>
> &gt; homenet mailing list<br>
> &gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/homenet" target=3D"_b=
> lank">https://www.ietf.org/mailman/listinfo/homenet</a><br>
> </div></div><span class=3D"HOEnZb"><font color=3D"#888888">--<br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2=
>  9871 4742</a> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: <a href=3D"mailto:=
> [email-masked]">[email-masked]</a><br>
> </font></span><div class=3D"HOEnZb"><div class=3D"h5">_____________________=
> __________________________<br>
> homenet mailing list<br>
> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <a href=3D"https://www.ietf.org/mailman/listinfo/homenet" target=3D"_blank"=
> >https://www.ietf.org/mailman/listinfo/homenet</a><br>
> </div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
> <img src=3D"http://graph.facebook.com/bkerensa/picture" style=3D"float:left=
> "><div style=3D"margin-left:80px"><div style=3D"font-weight:bold;font-famil=
> y:helvetica;font-size:14px">
>  
> Benjamin Kerensa</div><div><font color=3D"#333333" face=3D"&#39;comic sans =
> ms&#39;, sans-serif"><i>Team Lead, </i>Ubuntu Oregon</font></div><div><font=
>  face=3D"&#39;comic sans ms&#39;, sans-serif"><a href=3D"http://ubuntu-oreg=
> on.org" target=3D"_blank">http://ubuntu-oregon.org</a></font></div>
>  
> <div>Phone:=A0<span style=3D"font-family:Arial,Helvetica,sans-serif;text-al=
> ign:left;background-color:rgb(255,255,255)">503-894-6005 x</span><span styl=
> e=3D"font-family:Arial,Helvetica,sans-serif;font-size:11px;text-align:left;=
> background-color:rgb(255,255,255)">701</span></div>
>  
> <div style=3D"margin-top:5px"><a href=3D"http://facebook.com/bkerensa" targ=
> et=3D"_blank"><img src=3D"http://dl.dropbox.com/u/3722777/icon/facebook_16.=
> png"></a>=A0<a href=3D"http://twitter.com/bkerensa" target=3D"_blank"><img =
> src=3D"http://dl.dropbox.com/u/3722777/icon/twitter_16.png"></a>=A0<a href=
> =3D"https://plus.google.com/u/0/115750270177636397262" target=3D"_blank"><i=
> mg src=3D"https://lh4.googleusercontent.com/-4BbshQz4tLk/Tpky13k6lJI/AAAAAA=
> AAB9g/wvrS4GrSnoc/s16/google_plus_16.png"></a>=A0<a href=3D"http://www.stum=
> bleupon.com/stumbler/bkerensa/" target=3D"_blank"><img src=3D"http://dl.dro=
> pbox.com/u/3722777/icon/stumbleupon_16.png"></a>=A0=A0<a href=3D"http://fli=
> ckr.com/bkerensa" target=3D"_blank"><img src=3D"http://dl.dropbox.com/u/372=
> 2777/icon/flickr_16.png"></a>=A0<a href=3D"http://benjaminkerensa.com/" tar=
> get=3D"_blank"><img src=3D"http://dl.dropbox.com/u/3722777/icon/rss_16.png"=
> ></a>=A0<a href=3D"http://wiki.ubuntu.com/bkerensa" target=3D"_blank"><img =
> src=3D"https://lh6.googleusercontent.com/-0XzSMMdPaGo/Tpky1wQBZ7I/AAAAAAAAB=
> 9g/_O-7qTELLxw/s16/cof_orange_hex1.png"></a>=A0<a href=3D"http://www.last.f=
> m/user/bkerensa" target=3D"_blank"><img src=3D"http://dl.dropbox.com/u/3722=
> 777/icon/ilike_16.png"></a></div>
>  
> </div>=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0<div><span style=3D"color:rgb(51,51,51)=
> ;font-family:verdana,arial,&#39;times new roman&#39;,sans,serif;font-size:1=
> 0px"><i>This message may contain information which is privileged or confide=
> ntial.<br>If you are not the named addressee of this message please destroy=
>  it without reading, using, copying or disclosing its contents to any other=
>  person.</i></span></div>
>  
> <div><span style=3D"color:rgb(51,51,51);font-family:verdana,arial,&#39;time=
> s new roman&#39;,sans,serif;font-size:10px"><i><br></i></span></div><br>
>  
> --e89a8f234cc38c7df504c6b10d5c--

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Aug 2012 11:51:32 -0400

> mailing list where this thread can be continued.

It's probably worth noting (and I say this as the author of the DHCPv4 version) that the ISC DHCP client has somewhat fallen out of favor in some circles, and there are other alternatives being used which may behave differently (indeed, perhaps that is why the ISC version has fallen out of favor).

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 08 Aug 2012 12:29:44 -0400

In message <[email-masked]>
Michael Richardson writes:
 
> --=-=-=
> >>>>> "Brian" =3D=3D Brian E Carpenter <[email-masked]> writes:

Thanks.  I just took a look at rtsold and rtadvd.  If Linux kernel has
a similar function (wrong place to put this IMHO, but ...), then
perhaps in both rtsold and the Linux kernel in addition to an
interface down and up event, a suspend and resume event should trigger
a router solicitation.

BTW- In BSD neighbor discovery is in the kernel and router
solicitation and router advertisement are in userland.

Note that in rfc4862 (SLAAC) we have:

  5.5.4.  Address Lifetime Expiry

     A preferred address becomes deprecated when its preferred
     lifetime expires.  A deprecated address SHOULD continue to be
     used as a source address in existing communications, but SHOULD
     NOT be used to initiate new communications if an alternate
     (non-deprecated) address of sufficient scope can easily be used
     instead.

The RFC indicates that an old address should remain preferred.  It
might be better if a newer address was preferred slightly more and
could serve as a tie breaker.

> frequent.  I have had IPv6 connections survive such events, but not

If you have a USB interface and pull it out, dhcpv4 is killed and does
clean up and is restarted.  In bsd the netif script is run with stop
and start.  Otherwise, if you just hop to another channel on the
wireless, or unplug and plug the ethernet, the old address gets
deleted (ifconfig ... -alias) and the new address added (ifconfig
... alias).

> Michael Richardson <[email-masked]>, Sandelman Software Works=20

It would be nice if for both IPv4 and IPv6 hopping to another channel
on the wireless did not break old connections and did the right thing
with new ones.

Routers have a solution to any interface going down, but that solution
is to put a routable address on the loopback.  That works fine because
the provider can carry the IPv4 /32 or IPv6 /128 routes within its
borders, adding only one host route for each router, well worth it for
the reliability gain.

Within an enterprise, roaming around a building is supported by
bridging all the hubs together at layer-2.  This won't work for a home
user roaming outside the home and down the block to a WiFi hotspot (in
my case about 3-4 miles, so I'd have to rely in a lot of neighbors
with open wifi).

This roaming across subnets case could be made workable using a GUA on
the loopback and forcing a tunnel back to the home when roaming
outside the home.  This could also be a feature supported by a
wireless carrier, retaining an address on the loopback given at the
tower where the connection started until that address was no longer
needed.

It would be up to IETF (maybe homenet) to describe how this should
work (as described above is a candidate) and then up to home devices
to include support for it.  Being able to road at will without ever
losing connections would be a valuable feature.

Curtis

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Thu, 9 Aug 2012 05:20:36 +0000 (UTC)

> without an interface flap.

However there are sometimes "uneducated" (to be polite) NIC driver
developers who think that in the 21st centrury they still need to
completely reset their modern NIC on programming certain filter
events, often for multicast, so it's not uncommon that once in a while
you can find a behaviour that configuring addresses on an interface
still causes a full down/up cycle.  But yes, ne shuld consider that a
bug.  In general it should not hapen, I agree.

> Linux does this all in the kernel, *BSD does it in rtsold.

There is no need for rtsold; it's only helping you on ifUp to trigger
the RSes but the moment you learn or "lose" a prefix the kernel handles
autoconfiguration for you (unless you told it not to).  Things might
vary a bit between the different flavours of *BSD.

/bz

-- 
Bjoern A. Zeeb                                 You have to have visions!
          Stop bit received. Insert coin for new address family.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 10 Aug 2012 15:02:06 +0900

> presumably not in homenets.

They don't work when the DHCPv6 server has been unplugged for the network
or has crashed.