Subject: Re: [homenet] 6renum redux [Routing protocol comparison document]

From: Curtis Villamizar <[email-masked]>
Date: Sun, 01 Mar 2015 10:58:46 -0500

In message <[email-masked]>
Brian E Carpenter writes:
 
> Admittedly 6renum was targetted at enterprise networks, partly because
> of the observation that homenets renumber anyway after every power
> cut. But we have spent a lot of cycles on this issue.
>  
> http://tools.ietf.org/html/rfc4192
> http://tools.ietf.org/html/rfc5887
> http://tools.ietf.org/html/rfc6866
> http://tools.ietf.org/html/rfc6879
> http://tools.ietf.org/html/rfc7010
> and maybe it's time to revive
> https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines
>  
>    Brian

Hi Brian,

I'm sort of vaguely aware of this stuff on renumbering and of course
you are an author of much of it.  Some comments on this.

btw- this thread is almost certainly on the wrong WG mailing list so
if you'd like to redirect it, that would be a good thing for homenet.
It seems to be entirely enterprise renumbering focused.  Therefore
I've dropped the WG from the Cc for now.

The opsarea-ipv6-renumbering-guidelines draft seems like a bad
starting point.

For one thing the advice is change DNS first (break everything) and
then renumber.  No mention of dropping TTL to the minimum first which
would be less bad, but still bad (minimum 15 minute outage).

Oh wait ... that is essentially the topic of RFC 4192.  Just cite RFC
4192.

If it is a provider or enterprise renumber, then two prefixes are
available.  First add aliases allowing everything to be reachable
using either the old or new address.  Test.  Then change DNS.  Retest.
Then long after DNS caches have the new entry, drop the old addresses.
Retest should not be necessary but retest anyway.

Don't bother with ULAs unless there is no way to get a globally
routeable address.

Both routers and hosts with modern operating systems support numbering
the loopback.  These usually also support configuring the IPv6
preference to make binding to the loopback preferred without the
source code changes that used to be required in IPv4 years of old.

Perhaps RFC 2894 is a candidate for historic.

It is much easier to use RA and advertise the old prefix with a
prefered lifetime of zero.  Not that routers today take advantage of
either AFAIK.

RFC 5887 mentions both using RA and using DHCPv6 FORCERENEW or
RECONFIGURE for renumbering.

Is the use of RA M bit with no prefix or O bit with prefix still
considered ambiguous?

nit: Does anything really have a 128 bit DIP switch to set IPv6
address as implied in RFC 5887?  Certainly configured in
flash exists, but DIP switch.

In RFC 5887 section 7.  There is no need for address lifetimes in the
socket API if applications don't use bind to set the source address.

RFC 5887 7.1 :

    FORCERENEW in particular requires DHCP authentication [RFC3118] to
    be deployed.

Really?  I can see why since it could be used in a DoS attack if the
host didn't rate limit renewals.  But if it did rate limit renewal ...

In RFC 5887 7.2 - ISPs have figured out how to renumber.  Most already
generate configurations and push them out automatically even if that
means using a variety of "proprietary methods" (CLI).  And yes,
netconf is a good starting point but there may only be a problem for
small routers and/or smaller deployments that still hand configure.

I'm not sure that RFC 6866 and RFC 6879 add much value.

RFC 7010 does add value but IMHO not much.

Perhaps the emphasis should not be on "network renumbering is hard"
encouraging further whining.  The emphasis should not be on "network
renumbering does not need to be hard but can be very hard if certain
bad network management practices are followed".  First keep track of
everything that is configured, save the configuration, and know how to
reach that device to reconfigure it.  This includes DHCP servers.

<aside type="semi-rabid-rant">  <!-- no reply please :) -->

For example, even for my home net I have a SVN controlled directory
known as system-files.  It has every configuration file
(boot/loader.conf, /etc/fstabs, /etc/rc.conf, /etc/mail/*, dhcpd.conf,
rtadvd.conf, etc).  It also has shell scripts for anything supporting
an automatable access to configs to compare the running config files
on a host to the stored ones or to update the config.  Renumbering was
a breeze - update all configs, mostly with emacs macros, then push out
new configs.  I did not have the luxury of a transition period but I
used the old addresses while updating and making the transition to the
new addresses.

I set this up this way because I had worked for an ISP and know that
if they had 2,000 things and didn't know where they were, what configs
they were running, or how to change them remotely, they would have
never survived.  Not everyone running an enterprise network has the
benefit of that prior experience.  And we certainly can't expect
anyone in a homenet to ever do this which is a big part of why we are
here.  And yes, all my rackmount servers and VMs and jails and desktop
are static configured.  Nothing is dynamic except those things
connecting on WiFi, where configs (where applicable, which just means
my FreeBSD based laptop) are static but use DHCP and SLAAC.

The fact that most enterprises don't even know how many devices out
there have a DHCP configuration just shows that the state of IT
management practices in enterprise is abysmal.  You get what you pay
for.  So if IT is mostly recent grad PC weenies with minimal
understanding of networking and a fill in the dialog box and then
forget about it mentality about configuring things, then you have a
mess if renumbering is needed.  (No general flame of IT intended.
There are some very competent people in IT, but perhaps too few and
in very many case with too little influence).

</aside>

If you'd like to resurrect the issue of enterprise renumbering in a
new draft, please don't use opsarea-ipv6-renumbering-guidelines as a
starting point.  Consider the approach in the paragraph prior to the
aside (aka the rant).

Also consider a "web based configuration consider harmful" draft since
too many consumer and low end enterprise thingies have no means of
fetching or changing configurations that is both secure and can be
automated.  Not an issue for home, but definitely contributes to bad
practices in enterprise.  Remote configuration of PCs using KVM and
filling in the dialog boxes remotely is also a really bad enterprise
IT practice, particularly as the PC count rises.  In addition to being
secure the means of remote configuration should not create hidden
security vulnerabilities (ie: IPMI).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 01 Mar 2015 11:00:19 -0500

> https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines

Oops.  Didn't actually drop the Cc on prior email.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 01 Mar 2015 17:51:34 -0500

In message <[email-masked]>
Brian E Carpenter writes:
 
> of the
> observation that homenets renumber anyway after every power cut. But
> we have spent a lot of cycles on this issue.
>  

Brian,

To summarize my prior inelegantly made point:

  Perhaps the emphasis should not be on "network renumbering is hard"
  encouraging further whining.  The emphasis should not be on "network
  renumbering does not need to be hard but can be very hard if certain
  bad network management practices are followed".

Through some coincidence or bad karma, my colocation provider arranged
for a quick demo.  I was typing through an slogin when I noticed no
response.  To make a long story short the colo provider planned
renumbered into a new IPv6 space, sent a mass email which is probably
in my spam folder (to: undiclosed; bcc: ..the world..), and then did
the renumber.

When I called and heard about this it didn't really bother me partly
since it Sunday.  IPv4 still worked so I could recover.

First fix all of my stored config files in one shot.

  foreach f ( `find * -type f | xargs grep -l 2001:550:3800` )
    sed < $f > $f.tmp -e 's,<old>,<new>,g' && mv $f.tmp $f
  end

Then push these out to one bhyve host and two VM.

  gmake REMOTE_HOST=<host> REMOTE_USER=root SSH_AF_ARG=-4 install

Then slogin to each and compare old and new:

  sh build-02-etc-files.sh -cmp | & less

After that check update it

  sh build-02-etc-files.sh -destdir / -targethost <host>

Then for the VM with jails check first

  foreach j ( <list of jail names> )
    sh build-03-jails.sh -cmp -destdir /j0/$j -targethost $j |& less
  end

then update

  /etc/rc.d/jail stop
  foreach j ( <list of jail names> )
    sh build-03-jails.sh -config-only -destdir /j0/$j -targethost $j
  end

then restart the VMs (old interface was used new one is shown):

  /etc/bhyve/rc.d/<host> restart

Done with everything at the colo site.

Then figure out (very easily, look in a file) who is running a caching
nameserver with DNS secondaries configured to the old addresses.

  if it is not a jail:

    gmake REMOTE_HOST=<host> REMOTE_USER=root SSH_AF_ARG=-4 install

  if it is a jail then on the supporting host:

    sh build-03-jails.sh -config-only -destdir /j0/<host> -targethost <host>

  then

    ssh <host> -l root /usr/local/etc/rc.d/named stop
    ssh <host> -l root rm -f /etc/named/s/*
    ssh <host> -l root /usr/local/etc/rc.d/named start

Done with all hosts

Now just fix DNS glue records at the registrar and done.

The whole thing was under two hours including adding the SSH_AF_ARG
support to a bunch of gmake .mk files.

  2 rackmount servers
  1 destop (DNS only)
  4 VM on the 3 rackmounts
  16 jails on the 4 VMs

  rebuild zone files, named.conf (part of the gmake)
  update sendmail config files
  all system files such as rc.conf and sshd_config
  web server config including virtual host configs

unaffected were kdc and svn server (no fixed addresses).

This was all done remotely (since I still had working IPv4).

Not terribly painful.  But it could have been.  Not planned, but a
quick demo of renummbering something that looks a bit more like an
enterprise network than a homenet (because it is).

Curtis

ps- and no these gmake files and perl and shell stuff is not yet
available anywhere.  Sorry.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 2 Mar 2015 13:23:11 -0800

Would any of those rfc explain to me what the problems with renumbering
in a homenet are that Fave tried to avoid by doing NAT ? And how
those issues can not be mitigated by better workarounds than NAT ?

On Sun, Mar 01, 2015 at 02:24:08PM +1300, Brian E Carpenter wrote:
> On 01/03/2015 12:40, Curtis Villamizar wrote:
> > In message <[email-masked]>
> > Dave Taht writes:
> >  
> >> On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar
> >> <[email-masked]> wrote:
> >>> In message <[email-masked]>
> >>>> On 26/02/2015 05:14, Mikael Abrahamsson wrote:
> >>>>> On Wed, 25 Feb 2015, Ray Hunter wrote:
> >>>>>
> >>>>>> That way the devices can roam at L3, without all of the nasty side effects of re-establishing TPC sessions, or updating
> >>>>>> dynamic naming services, or having to run an L2 overlay network everywhere, or having to support protocols that require a
> >>>>>> specialised partner in crime on the server side (mTCP, shim6 et al).
> >>>>>
> >>>>> It's my firm belief that we need to rid clients of IP address dependence for its sessions. Asking clients to participate in HNCP
> >>>>> only addresses the problem where HNCP is used.
> >>>>>
> >>>>> Fixing this for real would reap benefits for devices moving between any kind of network, multiple providers, mobile/fixed etc.
> >>>>
> >>>> Violent agreement. This is not a homenet problem; it's an IP problem.
> >>>> In fact, it's exactly why IP addresses are considered harmful in
> >>>> some quarters. Trying to fix it just for homenet seems pointless.
> >>>> http://www.sigcomm.org/ccr/papers/2014/April/0000000.0000008
> >>>>
> >>>>    Brian
> >>>
> >>>
> >>> Brian,
> >>>
> >>> Seriously - your paper may be overstating the problem.  At least if we
> >>> discount IPv4 and in doing so eliminate NAT we solve a lot of problems
> >>> that never should have existed in the first place.  If we carry NAT
> >>> over to IPV6, then shame on us.
> >>  
> >> I am sorry, I no longer share this opinion. The pains of renumbering
> >> someones entire home network every time the ISP feels like it, given
> >> the enormous number of devices I have encountered that don't handle it
> >> well, are just too much to bear.
> > 
> > I renumbered 140.222/16 into 147.225/16 in the mid 1990s (T3-NSFNET to
> > ANSNET as part of the NSFNET decommissioning).  Not by myself of
> > course, but there were only a few of us on this.  It wasn't all that
> > bad and we had about 2,000 things to renumber in hundreds of
> > locations, many of them not manned.  Shell scripts and ksh (kerberized
> > rsh, not the Korn shell) made it simpler.  The worst was Cisco routers
> > and various old DSU/CSU and other commercial stuff since you had to
> > use "expect" scripts on their CLI rather than just something of the
> > form "ksh fqdn -l root ifconfig newaddr/mask alias" People with root
> > on their workstation that didn't give us acess were given notice.  We
> > used interface aliases and gradually took down the old aliases and
> > subnet addresses.  Nothing critical was affected.  It took a day or
> > two, then bake time, then less than a day to remove aliases.
> > 
> > OTOH - Most homes can't run two prefixes for a week or two before
> > taking the old prefix down.  And lots of consumer devices don't do
> > aliases.  But now days there is DHCP which didn't exist then (and
> > ICMPv6 RS/RA and SLAAC).
> > 
> > Are you having problems with the provider not giving you a static IPv6
> > prefix, but rather changing it on a whim?
> > 
> > I also renumbered my home net multiple times, but again, not much
> > pain.  Only a few consumer gadgets here have fixed addresses (one
> > because it never renewed DHCP leases and therefore needed a fixed
> > address, but that has since been tossed in e-waste recycling).
> > 
> >> The next version of cerowrt will do translation from the external IPv6
> >> address range to a static internal one (or ones, in the case of
> >> multiple egress gateways), and lacking a standard for such will use
> >> fcxx/8 addressing. I will make it be an option for people to turn off,
> >> but I've had it with being renumbered.
> > 
> > Are you suggesting that we add NAT to IPv6?  [I ask with disbelief.]
> > 
> > I would definitely be turning that off since I have a plenty big and
> > very static IPv6 prefix.  I also have a (tiny) static IPv4 prefix so I
> > have no choice but to IPv4 NAT due to its tiny size.
> > 
> > A better option might be to use something that switches over faster
> > than a DHCP lease times of days.  It seems that ICMPv6 RA can be sent
> > with prefix prefix information TLV with valid lifetime and/or
> > preferred valid lifetime of zero.  This is in RFC 4861 on Page 55:
> > 
> >       - If the prefix is already present in the host's Prefix List as
> >         the result of a previously received advertisement, reset its
> >         invalidation timer to the Valid Lifetime value in the Prefix
> >         Information option.  If the new Lifetime value is zero, time-out
> >         the prefix immediately (see Section 6.3.5).
> > 
> > Would that help?
> > 
> > Also, stateful DHCPv6 can invalidate leases (me thinks)?  Maybe
> > DHCPv4?  Am I mistaken about that?
> > 
> >> I am sure this will break stuff, and I don't know what all it will do,
> >> and I intend to find out.
> > 
> > Just breaks the end-to-end principle and requires rendezvous and all
> > that ugliness.
> > 
> > IMHO it would be better to send an immediate RA with a zero lifetime
> > on the old prefix and a normal lifetime on the new prefix.  If hosts
> > don't do the right thing they are in violation of RFC 4861.
> > 
> > OTOH, invalidating a DHCP lease would not do what we want here.
> > 
> >> Until some far off day where we have stable name to ipv6 address
> >> mapping, and vice versa, it is otherwise impossible to have useful
> >> ipv6 based services inside the home or small business.
> > 
> > Oh yeah.  And then there is DNS.  Maybe it would be better to keep a
> > short non-zero valid lifetime (longer than DNS TTL) and a preferred
> > valid lifetime of zero on that old prefix so it sticks around and is
> > usable locally but not preferred so not used for outgoing
> > connections.  Good reason to not set DNS TTL to days.  That way hosts
> > with cached DNS mapping to the old addresses will still work.
> > 
> >>> If we get rid of NAT a big part of the problem just goes away.  No
> >>> alternate spaces, kludgy rendezvous mechanisms, etc.  Using an address
> >>> on the loopback gets rid of the multiple interface problem and where
> >>> it really matters (ISP router and ISP or DS server reachability) this
> >>> has been done with configuration for two decades.  The multihoming
> >>> failover or roaming are a bit more difficult but things MPTCP is
> >>> supposed to address.
> >>>
> >>> Curtis
> > 
> > You want to keep NAT for IPV6?  Really?
> > 
> > Curtis
> > 
> > _______________________________________________
> > homenet mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/homenet
> > 
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
---
Toerless Eckert, [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Mar 2015 10:35:55 +1300

Hi Toerless,
> those issues can not be mitigated by better workarounds than NAT ?

http://tools.ietf.org/html/rfc7010 is the gap analysis, but for
enterprise networks. I think what Dave is actually saying is that
complex home networks of the future (which is where he already lives)
inherit many of these problems, with difference that renumbering
will be imposed by the ISP, so the element of choice and planning
that an enterprise network has is missing.

Somebody needs to work on RFC7010-for-homenet, I guess.

(Curtis is right, of course: if a network is designed and
managed with renumbering treated as an expected event, life
would be better.)

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Mar 2015 09:52:58 +1100

> that an enterprise network has is missing.

What we really should be telling ISPs is that renumber events should
be make before break.  There is zero reason other plain poor customer
service to not do this.

I can understand why this is done in IPv4 (not enough address space)
but this does not apply to IPv6.

If the equipement / software ISP's are using can't support multiple
prefixes then log fault reports with the suppliers.  Multiple
prefixes have been part of IPv6 from the very beginning.

> >>>>>>>> That way the devices can roam at L3, without all of the nasty side e
> ffects of re-establishing TPC sessions, or updating
> >>>>>>>> dynamic naming services, or having to run an L2 overlay network ever
> ywhere, or having to support protocols that require a
> >>>>>>> It's my firm belief that we need to rid clients of IP address depende
> nce for its sessions. Asking clients to participate in HNCP
> >>>>>>> Fixing this for real would reap benefits for devices moving between a
> ny kind of network, multiple providers, mobile/fixed etc.
> >>>>>>
-- 
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: Mon, 02 Mar 2015 19:26:33 -0500

In message <[email-masked]>
 
> Somebody needs to work on RFC7010-for-homenet, I guess.

Its zero conf.  It just happens.  Seriously.

OTOH, if there are devices with configured addresses then it would be
nice if the person running the network knew what they were, where
they were located, and how to access them to make changes.

> managed with renumbering treated as an expected event, life

Its really not a matter of treated renumbering as an expected event.
Good network planning results in knowing how you've allocated subnets,
which servers were given fixed addresses, and what DHCP pools exist.
Good network management involves also checking to see that hosts you
see for fixed addresses you don't know about including those within
the pools (no DHCP lease in the logs but something there at the top
range of the pool).  Its also nice to know when a rogue host or DHCP
server shows up and have the means to isolate its physical location.
For example, a box that went nuts and started spewing packets.

That type of good planning and good management leads to a simple and
straightforward renumbering as long as there is a grace period for the
transition.  If maintenance of configs is automated, then the renumber
can be done in record time.

Curtis

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 3 Mar 2015 00:52:34 +0000

> I can understand why this is done in IPv4 (not enough address space) but this
> does not apply to IPv6.

Just as one point where it does apply: 6rd deployments experience "fate-sharing" of the IPv6 address prefix with the IPv4 address. In PPPoE-based architectures, the IPv4 address is known to change relatively frequently. 
Barbara

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Mar 2015 14:28:09 +1300

> Its zero conf.  It just happens.  Seriously.

Well, Dave is saying he's tried and it doesn't. Whether that
means he has a printer with a manually configured non-ULA IPv6
address, or something else, I don't know, but we need to
understand.

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 3 Mar 2015 09:24:49 +0100 (CET)

On Tue, 3 Mar 2015, Mark Andrews wrote:

> What we really should be telling ISPs is that renumber events should be 
> make before break.  There is zero reason other plain poor customer 
> service to not do this.

There are some markets in the world, where customers *demand* to be 
frequently renumbered, because they think this is a privacy measure.

My current thinking in this area is to provide about 1 hour of address 
overlap to the home, where the old prefix is not preferred and the new is 
available for new connections. This would mean that most services would 
work just fine as long as they frequently (at least once per hour) 
re-establish their TCP session. Otherwise they have to do like mosh and 
try other connections when the first one breaks.

I still think there needs to be quite a lot of work done on APIs and best 
common practices in order for applications to do the right thing so this 
kind of renumbering event works. Most likely it's going to require a FOSS 
library that will act as a middle layer between the application and the 
network so applications don't have to talk directly to the POSIX 
interfaces (which plain suck and haven't been updated in 15 years or so).

We probably need a 5-10 (wo)man-year effort with a FOSS code outcome in 
order to get this done. I don't know who's interested in doing this. We 
have quite a lot of standards and documentation that can be used, what's 
lacking is actual code that the normal application developer can use, that 
is also multi-platform. Right now Microsoft, Apple and Google are putting 
a lot of effort into these APIs for Windows, OSX/iOS and Android 
respectively. We need this for the mainly Linux-driven FOSS universe (I 
don't know how much of the Android efforts are actually trickling back 
into regular Linux).

I belive MP-TCP has a role to play here as well.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Mar 2015 07:56:42 -0500

On Mar 3, 2015, at 3:24 AM, Mikael Abrahamsson <[email-masked]> wrote:
> I still think there needs to be quite a lot of work done on APIs and best common practices in order for applications to do the right thing so this kind of renumbering event works. Most likely it's going to require a FOSS library that will act as a middle layer between the application and the network so applications don't have to talk directly to the POSIX interfaces (which plain suck and haven't been updated in 15 years or so).

Why?   The only case where it will matter is for long-lived connections that can't restart.   So your overnight ssh, or your very long download.   Any other use will survive the renumbering event because you gave an hour's notice.   Deprecated addresses already shouldn't be selected for new connections by the stack--there's no need to modify the application.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 3 Mar 2015 14:20:47 +0100 (CET)

On Tue, 3 Mar 2015, Ted Lemon wrote:

> Why?  The only case where it will matter is for long-lived connections 
> that can't restart.  So your overnight ssh, or your very long download. 
> Any other use will survive the renumbering event because you gave an 
> hour's notice.  Deprecated addresses already shouldn't be selected for 
> new connections by the stack--there's no need to modify the application.

Yes, but I want to make sure also these long lived connections can survive 
the renumbering event.

I use "mosh" which gives me this for my ssh. I have completely stopped 
using TCP for ssh, because it just sucks. Right now I connect to a wifi 
and before I can basically switch to my terminal application, mosh has 
already reconnected. This is how I want things to work.

I can imagine a stream video application that uses a single TCP session, 
and watching a movie over this can easily take more than an hour. I need 
to check, but I would imagine for instance xbmc accessing a http(s) based 
file server would just use a single TCP session for the entire session. I 
can verify this if it's of interest.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Mar 2015 08:47:35 -0500

On Mar 3, 2015, at 8:20 AM, Mikael Abrahamsson <[email-masked]> wrote:
> I can imagine a stream video application that uses a single TCP session, and watching a movie over this can easily take more than an hour. I need to check, but I would imagine for instance xbmc accessing a http(s) based file server would just use a single TCP session for the entire session. I can verify this if it's of interest.

This is probably the use case we most care about.   I think it's actually a strong argument for going with a longer deprecation period.   E.g., if your deprecation period were three hours, we simply wouldn't have a problem.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 3 Mar 2015 14:57:47 +0100 (CET)

On Tue, 3 Mar 2015, Ted Lemon wrote:

> This is probably the use case we most care about.  I think it's actually 
> a strong argument for going with a longer deprecation period.  E.g., if 
> your deprecation period were three hours, we simply wouldn't have a 
> problem.

I don't agree with this at all.

I can easily come up with an equivalent scenario that would require an 
even longer overlap in time, for instance a long video conferencing 
session, and also there are longer movies than 3 hours.

We need to make applications be able to renumber to new addresses, and it 
doesn't matter if the use-case is that they're moving between APs, going 
from fixed to wifi to mobile, or they're being renumbered within the 
existing access method. Applications need to stop to rely on the address 
being stable over time. We need to give application developers the tools 
they need to not have to care about this, which means they need to have 
some kind of middleware, be it MP-TCP or something else. This needs to be 
easy for the most common use-cases, and it needs to be transparent to the 
application developer.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 03 Mar 2015 10:19:41 -0500

Mikael,

> On Mar 3, 2015, at 8:57 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> I can easily come up with an equivalent scenario that would require an even longer overlap in time, for instance a long video conferencing session, and also there are longer movies than 3 hours.

True, but most video conferencing software and live video feeds handle disconnects gracefully (enough) already, and most streaming video is not done using a single file/URL but with a series of files/URLs, with each file/URL representing a  "chapter" or other divisible unit within the program/movie being watched - there you will either seamlessly transition to the new address when the next chapter is fetched, or the application will detect the lost connection/stalled data and then attempt a reconnect which gets the new address.

So don't assume there will be problems when a network is renumbered - a lot of the work that's been done to deal with unreliable networks is equally useful for network changes, so long as the client application does not assume the network address of a named service won't change.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Mar 2015 10:23:00 -0500

> I can easily come up with an equivalent scenario that would require an even longer overlap in time, for instance a long video conferencing session, and also there are longer movies than 3 hours.

To be clear, I don't mean that we shouldn't try to improve the situation with renumbering, and I am curious to see the results of your survey.   I'm just saying that we also have to accept that change doesn't always happen immediately, and it's worth taking interim steps to avoid breaking existing protocols in obvious ways while also pursuing a long-term strategy of fixing the protocols so that they don't break.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 3 Mar 2015 16:34:55 +0100 (CET)

On Tue, 3 Mar 2015, Michael Sweet wrote:

> True, but most video conferencing software and live video feeds handle 
> disconnects gracefully (enough) already, and most streaming video is not 
> done using a single file/URL but with a series of files/URLs, with each 
> file/URL representing a "chapter" or other divisible unit within the 
> program/movie being watched - there you will either seamlessly 
> transition to the new address when the next chapter is fetched, or the 
> application will detect the lost connection/stalled data and then 
> attempt a reconnect which gets the new address.
>
> So don't assume there will be problems when a network is renumbered - a 
> lot of the work that's been done to deal with unreliable networks is 
> equally useful for network changes, so long as the client application 
> does not assume the network address of a named service won't change.

So where is the sweet spot? 10 minutes? 30 minutes? 1 hour? 3 hour? 6 
hour? 12 hour?

I just tried this. I was on the same subnet on wired ethernet and on wifi 
(etablished the call on wired with disabled wifi, enabled wifi, waited 30 
seconds, then unplugged wired) using my OSX macbook, using Skype voice 
session with another skype user, and it took around 10 seconds to detect 
the outage, and another 20 seconds to re-establish the call.

I tried the same procedure with Facetime audio, and it disconnected the 
call after 10 seconds and didn't try to establish it again until I 
manually did something.

Mosh fixes this with a 1-2 second outage.

I have no reason to believe the above behavior would be different if the 
call was over IPv6 (which I presume it wasn't) and the address went away 
because of a renumbering event.

So I'd say that at least two of the top VoIP clients on the market have no 
functionality to gracefully (30 second customer outage isn't gracefully) 
handling moving between two addresses. So applications need to get a *lot* 
better at being endpoint address independent.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 03 Mar 2015 11:04:04 -0500

Mikael,

> On Mar 3, 2015, at 10:34 AM, Mikael Abrahamsson <[email-masked]> wrote:
> ...
> So where is the sweet spot? 10 minutes? 30 minutes? 1 hour? 3 hour? 6 hour? 12 hour?

My guess is around 1 hour, but clearly that is something that should be tested to verify (and ideally be configurable).

> I just tried this. I was on the same subnet on wired ethernet and on wifi (etablished the call on wired with disabled wifi, enabled wifi, waited 30 seconds, then unplugged wired) using my OSX macbook, using Skype voice session with another skype user, and it took around 10 seconds to detect the outage, and another 20 seconds to re-establish the call.

30 seconds is not a huge amount of time, and certainly that could be improved, but it doesn't point to a need for or that it would be useful to make massive changes to the core networking APIs...

> I tried the same procedure with Facetime audio, and it disconnected the call after 10 seconds and didn't try to establish it again until I manually did something.

I think FaceTime audio doesn't reconnect while FaceTime video does, but I'm not connected to the team that does that software so I'm not 100% sure...  Regardless, that is just a marketing/HI decision, not a technical one.

> Mosh fixes this with a 1-2 second outage.

Good for Mosh.

> I have no reason to believe the above behavior would be different if the call was over IPv6 (which I presume it wasn't) and the address went away because of a renumbering event.

I agree.

> So I'd say that at least two of the top VoIP clients on the market have no functionality to gracefully (30 second customer outage isn't gracefully) handling moving between two addresses. So applications need to get a *lot* better at being endpoint address independent.

Need is a strong word - certainly they do not meet your high expectations, and there is likely room for improvement, but what works for Mosh and the recovery times it has may not be reflective of what other protocols can do.

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 3 Mar 2015 18:14:24 +0200

On 3.3.2015, at 18.04, Michael Sweet <[email-masked]> wrote:
> 30 seconds is not a huge amount of time, and certainly that could be improved, but it doesn’t point to a need for or that it would be useful to make massive changes to the core networking APIs...

If my phone call breaks for 30 seconds, I will cut the call, curse phone operator to deepest pit of hell, try to recall, fail, and perhaps iterate this 2-3 times during the 30 seconds. I am not sure why this would be acceptable on IP based service.

> I think FaceTime audio doesn't reconnect while FaceTime video does, but I'm not connected to the team that does that software so I'm not 100% sure...  Regardless, that is just a marketing/HI decisi…

Sounds very strange if marketing/HI makes technical decisions that should not be visible to the user (except in the negative case like this one). That explains why my Mac Pro behaves so badly though.

>> Mosh fixes this with a 1-2 second outage.

I am even more curious about mp-mosh[1], is there any outage with it at all?

Cheers,

-Markus

[1] https://github.com/boutier/mosh

---

From: Ray Hunter <[email-masked]>
Date: Tue, 03 Mar 2015 17:42:16 +0100

Mikael Abrahamsson wrote:
>> True, but most video conferencing software and live video feeds 
>> handle disconnects gracefully (enough) already, and most streaming 
>> video is not done using a single file/URL but with a series of 
>> files/URLs, with each file/URL representing a "chapter" or other 
>> divisible unit within the program/movie being watched - there you 
>> will either seamlessly transition to the new address when the next 
>> chapter is fetched, or the application will detect the lost 
>> connection/stalled data and then attempt a reconnect which gets the 
>> new address.
>>
>> So don't assume there will be problems when a network is renumbered - 
>> a lot of the work that's been done to deal with unreliable networks 
>> is equally useful for network changes, so long as the client 
>> application does not assume the network address of a named service 
>> won't change.
>
> I just tried this. I was on the same subnet on wired ethernet and on 
> wifi (etablished the call on wired with disabled wifi, enabled wifi, 
> waited 30 seconds, then unplugged wired) using my OSX macbook, using 
> Skype voice session with another skype user, and it took around 10 
> seconds to detect the outage, and another 20 seconds to re-establish 
> the call.
>
> I tried the same procedure with Facetime audio, and it disconnected 
> the call after 10 seconds and didn't try to establish it again until I 
> manually did something.
>
> I have no reason to believe the above behavior would be different if 
> the call was over IPv6 (which I presume it wasn't) and the address 
> went away because of a renumbering event.
>
> So I'd say that at least two of the top VoIP clients on the market 
> have no functionality to gracefully (30 second customer outage isn't 
> gracefully) handling moving between two addresses. So applications 
> need to get a *lot* better at being endpoint address independent.
>
I read your requirements.

I think there are two completely separate mechanisms being discussed 
here: the need for rapid failover to a previously known alternative 
address for your partner device, and discovering the alternative 
addresses of your partner.

The one thing I think that is still missing in the discussion is caching 
in the name space. Whether name resolution of the remote partner address 
be done via mDNS, DNS, or monitoring the currently established channel 
between partner nodes like in shim6, whatever.

I / we know from experience with Appletalk II NBP and ZIP that 100% 
dynamic a la minute server/name - address resolution doesn't scale well, 
and certainly not beyond enterprise level.

So we know we have to have some sort of caching in the name space. Or 
the list of partner addresses at the other end of the channel. Whatever. 
You cannot poll your partner on MOSH every 1mSec to see if it has 
changed its addresses.

I think caching in the name/address space sets a much more relevant 
lower limit on the speed of renumbering/ roaming via L3 on wifi/ 
whatever other event that causes your host's address(es) to change.

Otherwise you're forced into either taking your L3 prefix with you and 
using routing to the end host, or NATting the old address, or using 
rendezvous points, or being able to deprecate cache contents. None of 
which have proven particularly practicable.

So your 1 hour flash renumbering event seems way too small IMHO. 36 
hours would seem more reasonable.

I think that time limit is completely independent of a node's ability to 
fallback/fall forward to previously known alternative addresses (mSec 
range).

And for the wifi roaming example: if a node already knew all of the wifi 
prefixes in use in a Homenet, it could publish AAAA records well in 
advance of any move for all possible interfaces it could attach to.

-- 
Regards,
RayH

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 3 Mar 2015 17:54:59 +0100 (CET)

> addresses of your partner.

Agree.

> The one thing I think that is still missing in the discussion is caching in 
> the name space. Whether name resolution of the remote partner address be done 
> via mDNS, DNS, or monitoring the currently established channel between 
> partner nodes like in shim6, whatever.

I think we need this done via the existing channel, a la MP-TCP and SHIM6.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Mar 2015 14:36:52 -0500

On Mar 3, 2015, at 11:42 AM, Ray Hunter <[email-masked]> wrote:
> I think caching in the name/address space sets a much more relevant lower limit on the speed of renumbering/ roaming via L3 on wifi/ whatever other event that causes your host's address(es) to change.
> 
> Otherwise you're forced into either taking your L3 prefix with you and using routing to the end host, or NATting the old address, or using rendezvous points, or being able to deprecate cache contents. None of which have proven particularly practicable.
> 
> So your 1 hour flash renumbering event seems way too small IMHO. 36 hours would see

Why do you say that?   Is a ~60 minute TTL too short for a home device?   I don't think so.   As soon as the old address is deprecated, you remove the record pointing to it--you don't keep it around.   You install AAAA records only for non-deprecated addresses.   Why is this a problem?   Why the need for a 36 hour timeframe?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Mar 2015 08:55:18 +1300

Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182

On 04/03/2015 05:54, Mikael Abrahamsson wrote:
>> The one thing I think that is still missing in the discussion is
>> caching in the name space. Whether name resolution of the remote
>> partner address be done via mDNS, DNS, or monitoring the currently
>> established channel between partner nodes like in shim6, whatever.
> 

Much as I love shim6, it's currently a broken solution because most
firewalls
drop packets with shim6 extension headers. And it requires both hosts to
be updated to be effective.

Much as I love MPTCP, it only helps TCP sessions. And it requires both
hosts to
be updated to be effective.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 04 Mar 2015 07:49:08 +1100

In message <[email-masked]>, Brian E Carpenter writes:
> firewalls drop packets with shim6 extension headers. And it requires
> both hosts to be updated to be effective.

Which requires the two ends that want to use shim6 to upgrade their
firewalls.  It isn't impossible to use shim6.  If people had stopped
complaining and started developing firewalls that handled options
better we would be able to deploy them at the moment.  It isn't
impossible to do this at wire speed.

> hosts to be updated to be effective.
> 
>    Brian
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 04 Mar 2015 08:01:42 +1100

In message <[email-masked]>, Mikael Abrah
> frequently renumbered, because they think this is a privacy measure.

And their long running TCP sessions break in IPv4.  This doesn't
mean that they can't do better with IPv6.

We could also extend the temporary / permanent address model to PD.
You get two prefixes from the ISP.  One is designed to servers and
other things that need long term stability.  One is designed for
ephemeral use.  The application chooses which to use like they do
today.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 03 Mar 2015 22:33:23 +0100

> network

What are the applications that you think would benefit from that?
UDP-based applications, mind you, since MP-TCP works marvelously for TCP.

> order to get this done. I don't know who's interested in doing this.

I think getting thoroughly acquainted with previous art is necessary.  I'm
sure there are other UDP-based applications than just Mosh and µTP-based
BitTorrent that can deal with changing addresses, and we don't want to
build something that's either too general, not general enough, or even
both at the same time.

-- Juliusz

---

From: Ray Hunter <[email-masked]>
Date: Tue, 03 Mar 2015 22:55:38 +0100

> Ted Lemon <mailto:[email-masked]>
> 3 March 2015 20:36
>
> Why do you say that? Is a ~60 minute TTL too short for a home device? 
> I don't think so. As soon as the old address is deprecated, you remove 
> the record pointing to it--you don't keep it around. You install AAAA 
> records only for non-deprecated addresses. Why is this a problem? Why 
> the need for a 36 hour timeframe?24 ho
36 hours is a number plucked out of thin air by me that is longer than 
24 hours, which is a historic default refresh time for many DNS servers 
e.g. RFC1912 https://www.ripe.net/ripe/docs/ripe-203 .
One hour TTL could mean 24 times the DNS traffic compared to that 
historic norm. It also could mean (re)signing DNSSEC zones more than 24 
times per day as hosts move around the homenet.......

So it's clearly a trade off.

What's the difference in practical terms between 1 second, 1 minute, 1 
hour, and 1 day?

You either have more name resolution traffic (every day), or you have 
more temporary addresses and old prefixes hanging around for longer 
(during a renumbering event, which is presumably not every day).

Any operators got any input on how often they propose to rotate prefixes 
on domestic connections?

-- 
Regards,
RayH

---

From: Mark Andrews <[email-masked]>
Date: Wed, 04 Mar 2015 09:07:10 +1100

> times per day as hosts move around the homenet.......

TTLs and signature validity intervals are independent of each other.
You can have a TTL of zero with a signature validity interval of 30 days.

> So it's clearly a trade off.

The trade off is how often the data being signed changes.  Dynamic
zones only sign the data that is changing.  If you update a A record
that is two sets of signatures.  Those for the A record set and the
SOA record.  You don't re-sign the entire zone unless you are crazy.

Even doing it by hand the tools can work out what needs to be signed,
re-signed and what doesn't.

---

From: Ca By <[email-masked]>
Date: Tue, 3 Mar 2015 15:51:12 -0800

> build something that's either too general, not general enough, or even
I think ILNP covers a lot of this work.

Yes, it is a big step.  But it is a good step.

CB

> [email-masked] <javascript:;>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Mar 2015 21:21:07 -0500

On Mar 3, 2015, at 4:55 PM, Ray Hunter <[email-masked]> wrote:
> One hour TTL could mean 24 times the DNS traffic compared to that historic norm. It also could mean (re)signing DNSSEC zones more than 24 times per day as hosts move around the homenet.......

Caching is really only interesting for query clusters and frequently accessed domains.   I don't think there is any reason to expect that there will be performance issues for homenet names, which I would expect would be infrequently accessed by relatively few resolvers.

> You either have more name resolution traffic (every day), or you have more temporary addresses and old prefixes hanging around for longer (during a renumbering event, which is presumably not every day).

Temporary addresses don't belong in the DNS.   Stale information doesn't belong in the DNS.   This seems like a no-brainer to me.

---

From: Ray Hunter <[email-masked]>
Date: Wed, 04 Mar 2015 07:48:46 +0100

> 4 March 2015 03:21
> On Mar 3, 2015, at 4:55 PM, Ray Hunter<[email-masked]>  wrote:
If I'm following draft-ietf-homenet-front-end-naming-delegation, then 
the hidden master is also located within the Homenet.

Doesn't that mean that the (hidden master) DNS server itself also has to 
be renumbered?

And the new content synched with the slave servers (outside of homenet) 
in a timely manner, before the old prefixes are expired?

Are the values suggested in section 4.2 for SOA appropriate then?

I understood a zone transfer was only triggered when the SOA contents 
changed, and that was only checked once the slave refresh timer had expired.

-- 
Regards,
RayH

---

From: Mark Andrews <[email-masked]>
Date: Wed, 04 Mar 2015 18:04:32 +1100

In message <[email-masked]>, Ray Hunter writes:
> >> One hour TTL could mean 24 times the DNS traffic compared to that historic
>  norm. It also could mean (re)signing DNSSEC zones more than 24 times per day
>  as hosts move around the homenet.......
> >
> > Caching is really only interesting for query clusters and frequently access
> ed domains.   I don't think there is any reason to expect that there will be 
> performance issues for homenet names, which I would expect would be infrequen
> tly accessed by relatively few resolvers.

Zone transfers on SOA timer expiry very rarely happen these days.  NOTIFY
messages are the usual trigger.

> >> You either have more name resolution traffic (every day), or you have more
>  temporary addresses and old prefixes hanging around for longer (during a ren
> umbering event, which is presumably not every day).
> >
> > Temporary addresses don't belong in the DNS.   Stale information doesn't be
> long in the DNS.   This seems like a no-brainer to me.
> >
> 
> -- 
> Regards,
> RayH
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 4 Mar 2015 08:40:44 +0100 (CET)

On Wed, 4 Mar 2015, Mark Andrews wrote:

> We could also extend the temporary / permanent address model to PD. You 
> get two prefixes from the ISP.  One is designed to servers and other 
> things that need long term stability.  One is designed for ephemeral 
> use.  The application chooses which to use like they do today.

Wait, isn't this already supported in PD? I thought it was. A device can 
request multiple PD already, correct? Or you mean you want to explicitly 
signal the difference between the two PDs, basically saying "this PD will 
not get renewed, you should ask for an additional one"?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 4 Mar 2015 08:48:58 +0100 (CET)

> UDP-based applications, mind you, since MP-TCP works marvelously for TCP.

EVERYTHING that is not using TCP. Which is a lot. I don't want sessions 
that last more than a few seconds to rely on the address, anywhere.

> I think getting thoroughly acquainted with previous art is necessary. 
> I'm sure there are other UDP-based applications than just Mosh and 
> µTP-based BitTorrent that can deal with changing addresses, and we don't 
> want to build something that's either too general, not general enough, 
> or even both at the same time.

That's why I said 5-10 man-year effort.

I don't know on what level to solve this best. Since it requires some kind 
of authentication, perhaps it should be done by in a similar fashion to 
IPSEC but be done on a per-session basis, not per-IP.

Also, TCP is hindered by often being included in the operating system and 
not under the application developer control at all. This is fine for most 
applications, but the larger ones with special needs might want to do 
something differently. Looking at for example QUIC, they went down the UDP 
route to fix this problem.

So what I envision is a standardised protocol that could be implemented as 
a library on the host, be cross-plattform, probably run over UDP (at least 
short term), and combine some of the functionality of IPSEC and SHIM6 to 
enable authentication, encryption and address independence.

---

From: Ray Hunter <[email-masked]>
Date: Wed, 04 Mar 2015 09:23:40 +0100

> Mark Andrews <mailto:[email-masked]>
> 4 March 2015 08:04
> In message<[email-masked]>, Ray Hunter writes:
>>> Ted Lemon<mailto:[email-masked]>
>>> 4 March 2015 03:21
Thanks. That rids me of one misconception then.

How does Homenet either update glue records for the domain on the 
Internet TLD servers (if the master isn't hidden), or update the 
configuration of the slave servers to point to the new address of the 
hidden master (if the master is hidden), within an hour or less?

Is that something that can also be automated and e.g. be triggered by an 
existing NOTIFY message?
Or would this mechanism need a new extension?

I'd rather not assume that the ISP was also the DNS provider.

Otherwise the slaves will lose connectivity to the hidden master (if the 
master is hidden) . Or your glue records will be outdated and the name 
resolution won't bootstrap at all (if the master isn't hidden).

-- 
Regards,
RayH

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Mar 2015 10:12:17 +0100

> Op 4 mrt. 2015, om 08:48 heeft Mikael Abrahamsson <[email-masked]> het volgende geschreven:
> 
> EVERYTHING that is not using TCP. Which is a lot. I don't want sessions that last more than a few seconds to rely on the address, anywhere.
> 
>> I think getting thoroughly acquainted with previous art is necessary. I'm sure there are other UDP-based applications than just Mosh and µTP-based BitTorrent that can deal with changing addresses, and we don't want to build something that's either too general, not general enough, or even both at the same time.
> 
> I don't know on what level to solve this best. Since it requires some kind of authentication, perhaps it should be done by in a similar fashion to IPSEC but be done on a per-session basis, not per-IP.
> 
> Also, TCP is hindered by often being included in the operating system and not under the application developer control at all. This is fine for most applications, but the larger ones with special needs might want to do something differently. Looking at for example QUIC, they went down the UDP route to fix this problem.
> 
> So what I envision is a standardised protocol that could be implemented as a library on the host, be cross-plattform, probably run over UDP (at least short term), and combine some of the functionality of IPSEC and SHIM6 to enable authentication, encryption and address independence.

OpenVPN with float comes nearby.
I'm testing pre-2.4 with fix for float in P2MP mode. Works fine.

However, I do not recommend to use OpenVPN for each and every connection on Internet.

Teco

> 
> -- 
> Mikael Abrahamsson    email: [email-masked]
> homenet mailing list
> [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Wed, 4 Mar 2015 10:22:35 +0100

> be updated to be effective.

IPv6 multi-prefix multi-homing requires both hosts to support it. which means transport fixes.

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 4 Mar 2015 10:29:48 +0100 (CET)

> IPv6 multi-prefix multi-homing requires both hosts to support it. which means transport fixes.

Yes, as far as I can see there are only two ways to fix this, either you 
fix one end and this would require tunneling for the client that wants to 
be endpoint address independent (LISP or something else), or if you fix 
both ends, you could use MPTCP, SHIM6 etc.

So one way of doing this would be to use tunneling approach for traffic 
that isn't address-independent, and MPTCP/SHIM6 approach with direct 
routing for things that are (I guess this would require some MIF/PVD kind 
of approach). This of course means you have to have a decent notion about 
what is what, which either means caching results (this DST address seems 
to support address-independence protocol BLAH), or it means explicitly 
telling the client about it (DNS SRV records or something), or both.

---

From: Ole Troan <[email-masked]>
Date: Wed, 4 Mar 2015 11:12:37 +0100

> IPv6 multi-prefix multi-homing requires both hosts to support it. which means transport fixes.

to reply to myself. is anyone aware of any document describing the "expectations for hosts / host gaps" with regards to IPv6 multi-prefix multi-homing? including renumbering, mobility, redundancy, load sharing... essentially the RFC3582 goals.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Mar 2015 10:14:56 -0500

On Mar 4, 2015, at 1:48 AM, Ray Hunter <[email-masked]> wrote:
> Doesn't that mean that the (hidden master) DNS server itself also has to be renumbered?

Yes, but not before the zone transfer happens: the old IP address remains valid even though it's deprecated.

> And the new content synched with the secondary servers (outside of homenet) in a timely manner, before the old prefixes are expired?

Yes, this has to work reliably, and it also has to work if the secondaries are offline for some reason during the period when the old address is still valid but deprecated.  I would say that there's probably some glue required here if it's not already been documented in the homenet dns work that's been done so far.

> Are the values suggested in section 4.2 for SOA appropriate then?

4.2 is not normative.   The values suggested there would not be appropriate for a rapid-turnover environment like the one Mikael is describing.

> I understood a zone transfer was only triggered when the SOA contents changed, and that was only checked once the secondary refresh timer had expired.

That's right, but remember that when _any_ record is changed in the zone, the zone serial number, and hence the SOA, changes.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Mar 2015 10:20:29 -0500

On Mar 4, 2015, at 3:23 AM, Ray Hunter <[email-masked]> wrote:
> How does Homenet either update glue records for the domain on the Internet TLD servers (if the master isn't hidden), or update the configuration of the slave servers to point to the new address of the hidden master (if the master is hidden), within an hour or less?

I think you want an explicit update process for the glue records that is triggered by the DHCP server deprecating the old address.   This would be related to how glue records are set up initially.   The current document doesn't actually say anything about this, and that is a weakness that probably needs to be addressed.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Mar 2015 10:23:04 -0500

> to reply to myself. is anyone aware of any document describing the "expectations for hosts / host gaps" with regards to IPv6 multi-prefix multi-homing? including renumbering, mobility, redundancy,…

No.   This would be a good work item for MIF if nobody's currently working on it.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Mar 2015 11:34:58 +1300

> IPv6 multi-prefix multi-homing requires both hosts to support it. which means transport fixes.

Or fully operational shim6, which was conceived and designed for this
exact problem.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Mar 2015 11:38:22 +1300

> to reply to myself. is anyone aware of any document describing the "expectations for hosts / host gaps" with regards to IPv6 multi-prefix multi-homing? including renumbering, mobility, redundancy,…

The best I've got is the set of MULTI6 deliverables:

Goals for IPv6 Site-Multihoming Architectures (RFC 3582)
IPv4 Multihoming Practices and Limitations (RFC 4116)
Architectural Approaches to Multi-Homing for IPv6 (RFC 4177)
Threats relating to IPv6 Multihoming Solutions (RFC 4218)
Things Multihoming in IPv6 (MULTI6) Developers Should Think About (RFC 4219)

   Brian

---

From: Ole Troan <[email-masked]>
Date: Thu, 5 Mar 2015 10:08:23 +0100

Brian,

> Or fully operational shim6, which was conceived and designed for this

right. I tend to think that the problems of multi-homing, multi-endpoint, mobility, and renumbering are tightly coupled.
you might need to expose some of this to the transport and applications. I have more hope of solving this at L4.5 or even L5 (I suppose talking about a “session layer” would get me banned from the IETF. ;-)), than at L3.5.

to take the digression back to homenet; if we agree this is a problem for transport or above, then at least we can declare victory by claiming it isn’t our problem.

cheers,
Ole

---

From: Ray Hunter <[email-masked]>
Date: Fri, 06 Mar 2015 11:00:22 +0100

> 4 March 2015 16:20
> I think you want an explicit update process for the glue records that 
> is triggered by the DHCP server deprecating the old address. This 
> would be related to how glue records are set up initially. The current 
> document doesn't actually say anything about this, and that is a 
> weakness that probably needs to be addressed.
Exactly.

Can this be handled in the Homenet WG? or DNS?

-- 
Regards,
RayH

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Mar 2015 07:51:41 -0500

> Can this be handled in the Homenet WG? or DNS?

I don't see in principle why homenet couldn't address it.   It appears to be in charter.