Re: [homenet] HNCP, RA and DHCPv4
Hi, On 27 Jul 2015, at 14:58, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: snip 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). 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. 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? 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] some IS-IS questions
On 28 Jul 2015, at 21:21, Gert Doering g...@space.net wrote: Hi, On Tue, Jul 28, 2015 at 11:55:16AM -0400, Ted Lemon wrote: This means that the end user can be assumed to plug home routers together in arbitrary topologies, [..] Our goal is for this to work in a multihomed IPv6 environment. Just to repeat myself from yesterday :-) - OpenWRT with HNCP and Babels achieved this nicely enough 15+ months ago. Yes, it had some rough edges, but it *worked*. And maybe a year before that there was working code for OSPF (with multiple implementations based on at least Bird and Quagga) which had working code for homenet routing, including automatic prefix configuration and src/dst routing. Hindsight is a wonderful thing. If homenet had decided to separate out the configuration from the routing at an earlier point, we’d certainly have been where we are now rather sooner. The OSPF implementations allowed us to see quite clearly that the separation of configuration was desirable (as much as Markus was increasingly creative with new TLVs!), so that experience while arguably ‘lost’ time was something we learnt from. Part of the homenet journey. Personally, I like where we are with Babel and HNCP now. Many of the same people, esp. Markus and Dave, who prototyped previous work, have been awesome in repeating their efforts for HNCP Babel, and that’s great. It was a shame to see many open source developers feeling frustrated at Prague. I hope they do continue their efforts. We would not be where we are now in homenet without them. The HNCP work should now be able to be completed independently of the routing protocol chosen, and if the Babel side meeting from Prague leads to wider understanding of Babel, and its standards status being elevated, that would be great. Tim ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
* 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
* Steven Barth 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). 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=6204rec_status=1presentation=records Tore ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
