Subject: [homenet] HNCP, RA and DHCPv4

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 27 Jul 2015 15:58:01 +0200

During my quick talk on Wednesday, I mentioned that I had been pleasantly
surprised at the very clean interaction between the protocols:

  - HNCP redistributes assigned prefixes into the routing protocol;
  - HNCP redistributes assigned prefixes into the RA and DHCPv4 servers;
  - the routing protocol redistributes the default route into RA and DHCPv4.

That's very elegant -- unless I've missed something, there are no other
cross-protocol interactions in the subset of the Homenet stack that is
implemented in shncpd.

Redistribution into RA happens pretty smoothly (I'm testing against dhcpcd,
the most complete DHCPv4/RA/DHCPv6 client I could find).  The main
desirable feature of RA is that it is possible to switch between being
a default router and not being one dynamically, just by sending a new RA
with a zero/non-zero default router lifetime.

Renumbering is not as smooth -- it appears to be impossible to remove
a set of addresses wholesale, retracting a set of PIOs merely causes the
old addresses to become deprecated.  Since after a renumbering event we're
no longer routing towards the retracted prefix, the client will need to
timeout its TCP connections, and any UDP applications will need to rebind
to the non-deprecated addresses (please check your NTP and BitTorrent clients).

The situation with DHCPv4 is not as satisfactory.  It is not possible to
force the clients to either pick a different default router or to renew
their lease (FORCERENEW is not useful).  This means that DHCPv4 clients
will be stuck with a non-functional address until they choose to renew.
As Markus explained to me, this is mitigated by three factors:

  1. since IPv4 addresses are NATed, IPv4 renumbering is not likely to
     happen;

  2. since DHCPv4 is not a very noisy protocol, we can use very low
     renewal times;

  3. Windows users have already been trained to reboot when something
     doesn't work as expected.

I know there are DHCP and 6man/6ops people on this mailing list, any
opinions on whether we're doing it wrong and whether updates to RA/DHCPv4
are desirable?

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Mon, 27 Jul 2015 16:01:36 +0200

> cross-protocol interactions in the subset of the Homenet stack that is

There is one thing I worry about with this strategy...

if HNCP redistributes assigned prefixes into the RA/DHCPv4 servers,
who makes sure that these are prefixes that are "reasonable good"
measured by the metric of the routing protocol?

Henning Rogge

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 27 Jul 2015 16:15:36 +0200

> measured by the metric of the routing protocol?

Nobody.  From the point of view of the host, all connected routers are
equivalent.

If the host is single-homed, any suboptimal routing will be resolved by
the redirect mechanism.  If the host is multi-homed, there's a realistic
risk of suboptimal routing -- I don't know any good solution to that (but
I haven't looked carefully at the MIF work).

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 27 Jul 2015 17:07:14 +0200

> The situation with DHCPv4 is not as satisfactory
[...]
> (FORCERENEW is not useful).

Roy Marples, the author of dhcpcd, is telling me to look at RFC 6704.

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Mon, 27 Jul 2015 17:33:40 +0200

> I haven't looked carefully at the MIF work).

I wonder if the "data-propagation/router control" part of HNCP and the
"attached host control" part of HNCP should be split into two
entities... this would allow the second one to get hints from the
routing protocol about the metric without generating a dependency
cycle.

Henning Rogge

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 27 Jul 2015 17:42:39 +0200

> routing protocol about the metric without generating a dependency

There's no "attached host control" part in HNCP -- there's just RA and
DHCPv4 (DHCPv6 optional).  HNCP is purely a router-router protocol.

It's a pretty clean design.

In principle, it might be possible to use routing protocol metrics to
influence RFC 4191 preferences, but I'm not sure how that would work.
If you know (and have implementation experience), I'm interested.

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Mon, 27 Jul 2015 17:48:49 +0200

> DHCPv4 (DHCPv6 optional).  HNCP is purely a router-router protocol.

you could say that setting your local prefix on the interface is
"control the local node" and setting up RA/DHCPv4 is "control the
address of the host".

still, at the moment I just see a problem and have no good solution,
just a few guesses.

> If you know (and have implementation experience), I'm interested.

I just got my olsrv2 implementation source-specific routing capable...
I plan to look at your "simple" HNCP implementation to see how routing
metrics could help. But this is still a "todo" for me.

Henning

---

From: Steven Barth <[email-masked]>
Date: Mon, 27 Jul 2015 18:01:11 +0200

> DHCPv4 (DHCPv6 optional).  HNCP is purely a router-router protocol.
(stateless) DHCPv6 is mandatory as per RFC 7084, since not all clients
support getting RDNSS and search-domains from RAs (e.g. Windows-based).

In general, while having something minimal in there is nice, I think
making it optional or at least separating it so it can be easily removed
is a good idea as well.

For some stuff you might not want to have DHCPv4 / IPv4, or you want to
have a better-featured RA-server that actually reacts to default route
changes, or sends out link MTU & HW-address or can unicast replies etc.

All in all, that's some modularity even hnetd has :P

Cheers,

Steven

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 27 Jul 2015 18:05:42 +0200

> not all clients support getting RDNSS and search-domains from RAs
> (e.g. Windows-based).

I can give you a Linux CD ;-)

---

From: Tim Chown <[email-masked]>
Date: Fri, 31 Jul 2015 15:19:20 +0100

Hi,

> On 27 Jul 2015, at 14:58, Juliusz Chroboczek <[email-masked]> wrote:
> 
> <snip>
> 

Much will depend if the ISP is offering their customer a ‘graceful’ renumbering 
event. If they do, then the principle applied in RFC4192 could be applied, and
you will have a period where both prefixes (old and new) co-exist, before the
old prefix is removed. In that case, the older connections can be retained, at
least until that removal.

If the ISP is ‘flash’ renumbering, then yes, this is certainly a challenge. It would
thus be useful to know what types of events customers / homenets might see.

For internal connections, if the homenet is running ULA alongside its ISP
prefix, then the sessions will survive through use of the ULAs. Which is why
it’s useful to be able to provide stable prefixes internally.

> opinions on whether we're doing it wrong and whether updates to RA/DHCPv4

The interesting thing here is that many people (in my view quite rightly) like the 
whole ‘fate sharing’ principle of a prefix, a router and an RA. The ‘problem’
with DHCP is that if the outing information changes, a default gateway learnt
from a DHCP server may well become stale / out of date information.

homenet doesn’t generally design IPv4 solutions, it’s focused on IPv6, but
if HNCP allows dynamic update of DHCP server configuration information,
then that’s potentially useful.

Tim

> 
> -- Juliusz
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 31 Jul 2015 16:39:54 +0200

> Much will depend if the ISP is offering their customer a ‘graceful’
> renumbering event. If they do, then the principle applied in RFC4192
> could be applied, and you will have a period where both prefixes (old
> and new) co-exist, before the old prefix is removed. In that case, the
> older connections can be retained, at least until that removal.

I don't think that HNCP announces the "deprecated" status of a delegated
prefix, so there's no way for an HNCP node to propagate it from the
delegated to the assigned prefix.  Markus, Steven, Pierre?

> The interesting thing here is that many people (in my view quite
> rightly) like the whole ‘fate sharing’ principle of a prefix, a router
> and an RA.

I happen to belong to that group of people, but I don't think that's the
issue here.

> The ‘problem’ with DHCP is that if the outing information changes,
> a default gateway learnt from a DHCP server may well become stale / out
> of date information.

The default gateway should be fine, at least most of the time (every
Homenet router can act as a default gateway as long as the Homenet remains
connected).  The main issue is that once you've given out an IPv4 lease,
there's no easy way to tell the client, "oh, sorry, I just gave you this
nice IPv4 address, but the Homenet's prefix assignment consensus is that
we should renumber, could you please release the address and I'll give you
another one ASAP".

As Markus explained to me, this should not be an issue in practice, since
IPv4 renumbering is rare due to NAT, and the adoption mechanism in the PA
algorithm should avoid renumbering when a router crashes.  FORCERENEW with
Nonce authentication might also be helpful, I'm not sure.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 31 Jul 2015 15:08:20 +0000

> renumbering event. If they do, then the principle applied in RFC4192 could
> be applied, and you will have a period where both prefixes (old and new) co-
> exist, before the old prefix is removed. In that case, the older connections
> can be retained, at least until that removal.
> 
> If the ISP is ‘flash’ renumbering, then yes, this is certainly a challenge. It
> would thus be useful to know what types of events customers / homenets
> might see.

IMO -- for whatever reason, hosts and routers need to be prepared for  "flash renumbering". It will happen. The LAN (hosts and routers) need to deal with it as gracefully as possible. And based on discussion last week now there seems to be an element of this that is causing problems, but should be solvable.

When the old prefix is deprecated, (many?some?) routers apparently are sending that info out just once. Any host that didn't get the one announcement doesn't know and has no way of knowing. Does it make sense for routers to continue sending the deprecated prefix in RA messages for the duration of the prefix's original validity? Is there something HNCP should also do to continue to provide info for the duration of the original valid lifetime?
Barbara

---

From: Steven Barth <[email-masked]>
Date: Fri, 31 Jul 2015 17:12:30 +0200

> delegated to the assigned prefix.  Markus, Steven, Pierre?

For all intents and purposes a "deprecated" prefix is one with a preferred
lifetime of 0 so that is supported (TLV has valid and preferred lifetimes).
If your ISP does a graceful renumbering than that is what happens, your
RA server just has to play ball here though.

In an ungraceful case (flash renumbering) we stop announcing the prefix in
HNCP and the individual routers who have assigned it, MUST deprecate it
according to RFC 7084 (not just stop announcing it in RAs). This deprecation
sets preferred lifetime to 0 and valid lifetime to max (old valid lft, 2h).

> FORCERENEW with

Nobody (I know) implements that, though. Even for DHCPv6 it is rare (haven't
seen a host OS that does) and there its part of the main standard.

---

From: Dave Taht <[email-masked]>
Date: Fri, 31 Jul 2015 08:16:16 -0700

To me a flash renumbering = power failure and recovery or a power cycle.

which is always quite annoying with different upses lasting different times.

Or are we relying on some device, somewhere, reliably keeping all
state on flash?

-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

---

From: Steven Barth <[email-masked]>
Date: Fri, 31 Jul 2015 17:17:53 +0200

Am 31.07.2015 um 17:08 schrieb STARK, BARBARA H:
> When the old prefix is deprecated, (many?some?) routers apparently are sending that info out just once.
> Any host that didn't get the one announcement doesn't know and has no way of knowing.
> Does it make sense for routers to continue sending the deprecated prefix in RA messages
> for the duration of the prefix's original validity? Is there something HNCP should also do to
> continue to provide info for the duration of the original valid lifetime?

Actually RFC 6204 (and its successor 7084) have a requirement that enforces keeping it in the RA
for at least 2h. HNCP makes following 7084 mandatory atm.

Some more details of how HNCP handles graceful and ungraceful currently:
https://mailarchive.ietf.org/arch/msg/homenet/eBt_ANocpvbxsnhBBl-hngKdiVk

---

From: Steven Barth <[email-masked]>
Date: Fri, 31 Jul 2015 17:34:10 +0200

> To me a flash renumbering = power failure and recovery or a power cycle.
It does not matter if its a power failure or something else. If your edge router looses connectivity for any reason, its delegated prefix is removed once its falls out of the HNCP network or once it starts announcing a different set of TLVs. Then RFC 7084 deprecation kicks in for all routers who have assigned a prefix from it.

In addition for WiFi routers (or if your whole home power cycles) there is a good chance your clients get a link change event anyway.

> Or are we relying on some device, somewhere, reliably keeping all
The prefix assignment draft defines a (non-mandatory) stable storage to store your own assignments btw.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 31 Jul 2015 15:35:07 +0000

> Actually RFC 6204 (and its successor 7084) have a requirement that enforces
> keeping it in the RA for at least 2h. HNCP makes following 7084 mandatory
> atm.

If you're referring to RFC 7084's:
   L-13:  If the delegated prefix changes, i.e., the current prefix is
          replaced with a new prefix without any overlapping time
          period, then the IPv6 CE router MUST immediately advertise the
          old prefix with a Preferred Lifetime of zero and a Valid
          Lifetime of either a) zero or b) the lower of the current
          Valid Lifetime and two hours (which must be decremented in
          real time) in a Router Advertisement message as described in
          Section 5.5.3, (e) of [RFC4862].

then this doesn't say to continue advertising for 2 hours. If the immediately-sent RA has valid = preferred = 0 (which is one of the permitted value combinations per the requirement), then I see no requirement for any subsequent RA to be sent that includes this prefix.
Barbara

---

From: Steven Barth <[email-masked]>
Date: Fri, 31 Jul 2015 17:42:10 +0200

> then this doesn't say to continue advertising for 2 hours. If the immediately-sent RA has valid = preferred = 0 (which is one of the permitted value combinations per the requirement), then I see no…
Interesting, it was apparently changed in 7084. 6204 didn't have the 0 option for valid lifetime
but enforced option b). Ok, learned something today. I guess I will add a sentence to HNCP to
enforce the old behavior, so that is clear.

Cheers,

Steven

---

From: Tore Anderson <[email-masked]>
Date: Fri, 31 Jul 2015 19:59:53 +0200

* Steven Barth

> sets preferred lifetime to 0 and valid lifetime to max (old valid lft, 2h).

Hi Steven,

Why don't you set the valid lifetime to 0 as well?

If a new host is connecting to the network while you're advertising the
max(old valid lft, 2h) valid lifetime, it will actually auto-configure
itself with an address from the withdrawn prefix. If you set valid
lifetime to 0, it won't.

This comes to mind:

https://www.rfc-editor.org/errata_search.php?rfc=6204&rec_status=1&presentation=records

Tore

---

From: Steven Barth <[email-masked]>
Date: Fri, 31 Jul 2015 20:15:09 +0200

>itself with an address from the withdrawn prefix. If you set valid

Sounds good, i don't mind. Just have to phrase so that it's sent more than once in any case. We could also say it needs to be sent in 3 successive RAs independent of the time frame. What do you people think?

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 31 Jul 2015 19:26:22 +0000

> Sounds good, i don't mind. Just have to phrase so that it's sent more than
> once in any case. We could also say it needs to be sent in 3 successive RAs
> independent of the time frame. What do you people think?

I agree with the usefulness of setting valid lifetime = 0. And that's what I would prefer to see happen. 
I don't think 3 RAs will solve the problem that was expressed to me regarding renumbering.

The problem was:
A laptop was in "sleep" mode when the RA deprecating the prefix was sent.
When the laptop woke up, it still had the prefix, and no indication the prefix shouldn't be used.
The laptop expected to be able to use the prefix up to the prefix's original validity and with the original preference, in the absence of newer info regarding that prefix.

This is why I think it would be great if the deprecated prefix continued to be sent (in RA and HNCP) until its original valid lifetime expired. But I would prefer for it to be sent with valid lifetime = 0.
Barbara

---

From: Tore Anderson <[email-masked]>
Date: Fri, 31 Jul 2015 21:38:29 +0200

* Steven Barth

> >If a new host is connecting to the network while you're advertising
> >the max(old valid lft, 2h) valid lifetime, it will actually
> >auto-configure itself with an address from the withdrawn prefix. If
> >you set valid lifetime to 0, it won't.
> 
> Sounds good, i don't mind. Just have to phrase so that it's sent more
> than once in any case. We could also say it needs to be sent in 3
> successive RAs independent of the time frame. What do you people
> think? 

Yes, I think retransmitting those RAs for a while is a good idea.
Multicast RAs might get lost, especially on WiFi, and to make matters
worse some devices will rate-limit them in order to conserve energy (cf.
I-D.ietf-v6ops-reducing-ra-energy-consumption). So I'd say firing of a
volley of a few (*at least* 3, IMHO) RAs with a short interval
immediately following the flash renumbering event sounds sensible.

After that you can also include the PIO with PL=VL=0 in the periodic
RAs (that you'll presumably be transmitting anyway) for several hours
(in order to hopefully get through to any RA rate-limiting devices that
might have missed the initial volley). I don't see any damage that
could be caused by doing so - devices that saw the initial volley as
well as newly-connected devices that never had an address in the prefix
to begin with will simply ignore that PIO. Maybe doing that for approx.
two hours would make the most sense here, as that's most likely the time
the addresses will actually start disappearing from the hosts that saw
the initial volley.

Tore