Re: [homenet] HNCP: avoiding renumbering
On Mon, Aug 17, 2015 at 09:41:24AM +0300, Markus Stenberg wrote: > Just like in some other old workplace, cough, ???if it does not work without > IPsec, do not expect it to work with it???. Should i even try to understand that reference ? ;-) > I do not expect homenet stuff to do much better here, unless we want to make > it crazily complicated. > > Normal, graceful renumberings are a part of IPv6 and should work equally well > given single 7084 router and homenet router network. IPv4 ???renumbering??? > will be bit less graceful no matter what, I am afraid, but that???s outside > the architecture RFC mandate anyway and done just as a public service. I don't know why Juliusz called stable storage bad. I think it's great. Where would i be without stable storage for my routers software, policy configuration, passwords, logs and the like. Why should it be bad to memorize addressing ? I think it's mandatory for IPv4, and for IPv6, i'd love to have some option to either re-number when i click - to weed out bad apps/OS problems - or a switch for persistency of addresses (one to improve reality, one to live with it). Cheers Toerless ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
On 17.8.2015, at 9.22, Toerless Eckert wrote: > On Mon, Aug 17, 2015 at 01:01:04PM +1200, Brian E Carpenter wrote: >> That may be desirable to limit churn, but must not be depended on. The >> architecture is explicit on pp 25-26 that renumbering is an expected event: >> https://tools.ietf.org/html/rfc7368#page-25 >> The addressing, routing and naming architecture has to be ready for >> renumbering at any time. Anything else is broken. > What analysis is there about application and API level problems in supprting > this model today ? My gut feeling is that a lot of applications or > even APIs like bind(::) may have problems, but thats just because i am > paranoid. Just like in some other old workplace, cough, ’if it does not work without IPsec, do not expect it to work with it’. That is, if single-router home experiences power outage, outcome is rather catastrophic renumbering event (and loss of NAT state). I do not expect homenet stuff to do much better here, unless we want to make it crazily complicated. Normal, graceful renumberings are a part of IPv6 and should work equally well given single 7084 router and homenet router network. IPv4 ‘renumbering’ will be bit less graceful no matter what, I am afraid, but that’s outside the architecture RFC mandate anyway and done just as a public service. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
On Mon, Aug 17, 2015 at 01:01:04PM +1200, Brian E Carpenter wrote: > That may be desirable to limit churn, but must not be depended on. The > architecture is explicit on pp 25-26 that renumbering is an expected event: > https://tools.ietf.org/html/rfc7368#page-25 > The addressing, routing and naming architecture has to be ready for > renumbering at any time. Anything else is broken. What analysis is there about application and API level problems in supprting this model today ? My gut feeling is that a lot of applications or even APIs like bind(::) may have problems, but thats just because i am paranoid. Cheers Toerless ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] What to do when we lose DHCPv4 election?
Juliusz Chroboczek wrote: > When a Homenet router was previously acting as DHCPv4 server for a link, > and subsequently loses an election, should it: > 1. remain silent; > 2. remain silent in response to DHCPDISCOVER, but NAK any DHCPREQUEST; or > 3. NAK both DHCPDISCOVER and DHCPREQUEST? I think that #2 is probably correct, but I have two questions. 1) do Homenet-aware DHCPv4 servers pick the same rfc1918 address spaces to give out? 2) if a DHCPv4 server previously had given out leases, and the lease is still valid, then I think that it ought to ACK a DHCP renew. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
On 17/08/2015 11:01, Juliusz Chroboczek wrote: which avoids renumbering. > >> Why do we care? Homenets need to be renumbering-proof anyway, because >> the ISP might change the prefix anytime. > > You're right, that deserves clarifying. We're trying really hard to make > sure that in no circumstances is running a Homenet router worse than > running an ordinary NAT/DHCPv6-PD router. Consider the following trivial > topology: > > ISP Homenet router stub link > > We'd like to ensure that: > > - the NATed IPv4 prefix assigned to the stub link remains stable; > - if the /56 delegated by the ISP is stable, then the global /64 > assigned to the stub link remains stable; > - if the Homenet router is announcing a ULA, then the ULA /64 assigned > - to the stub link remains stable. > > In short, we'd like any prefix assignments performed by the Homenet router > to survive a reboot, even in the absence of either explicit configuration > or stable storage. That may be desirable to limit churn, but must not be depended on. The architecture is explicit on pp 25-26 that renumbering is an expected event: https://tools.ietf.org/html/rfc7368#page-25 The addressing, routing and naming architecture has to be ready for renumbering at any time. Anything else is broken. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
On 17/08/2015 11:01, Juliusz Chroboczek wrote: which avoids renumbering. > >> Why do we care? Homenets need to be renumbering-proof anyway, because >> the ISP might change the prefix anytime. > > You're right, that deserves clarifying. We're trying really hard to make > sure that in no circumstances is running a Homenet router worse than > running an ordinary NAT/DHCPv6-PD router. Consider the following trivial > topology: > > ISP Homenet router stub link > > We'd like to ensure that: > > - the NATed IPv4 prefix assigned to the stub link remains stable; > - if the /56 delegated by the ISP is stable, then the global /64 > assigned to the stub link remains stable; > - if the Homenet router is announcing a ULA, then the ULA /64 assigned > - to the stub link remains stable. > > In short, we'd like any prefix assignments performed by the Homenet router > to survive a reboot, even in the absence of either explicit configuration > or stable storage. That may be desirable, but must not be depended on. The homenet architecture is explicit on pp 25-26 that renumbering is an expected event: https://tools.ietf.org/html/rfc7368#page-26 The addressing, routing and naming architecture has to be ready for renumbering at any time. Anything else is broken. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
>>> which avoids renumbering. > Why do we care? Homenets need to be renumbering-proof anyway, because > the ISP might change the prefix anytime. You're right, that deserves clarifying. We're trying really hard to make sure that in no circumstances is running a Homenet router worse than running an ordinary NAT/DHCPv6-PD router. Consider the following trivial topology: ISP Homenet router stub link We'd like to ensure that: - the NATed IPv4 prefix assigned to the stub link remains stable; - if the /56 delegated by the ISP is stable, then the global /64 assigned to the stub link remains stable; - if the Homenet router is announcing a ULA, then the ULA /64 assigned - to the stub link remains stable. In short, we'd like any prefix assignments performed by the Homenet router to survive a reboot, even in the absence of either explicit configuration or stable storage. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On 16/08/2015 21:31, Steven Barth wrote: > Am 10.08.2015 um 19:28 schrieb Fred Baker (fred): >> In any event, I would urge the HNCP design team to consider the cases, and >> either make an argument that making network routing more complex (BCP 84) >> has a benefit I'm missing and actually works without the rule, or change >> HNCP to not have each RA contain every possible prefix. > > After scanning the discussions here, is there anything in particular that > people feel which we need to add or clarify in HNCP for that matter? > > It seems to me that the current behavior, i.e., potentially "non-optimal" > router sending out the PIO > and then relying on redirection / routing does not really break things. I think Pierre was saying in Prague that it does break things in the case of extra hops on very lossy wireless networks. > Optimizing the PIO sending might in theory be > possible but - as pointed out - is probably very hard to accomplish in > practice. > > In addition, as a personal note from my own reading, I'm not 100% convinced > that hosts even following the next-hop > tracking of 6724 would correctly react to potential "handover" of a PIO from > one router to another since the definition > is relatively vague. That is probably true today but hopefully doesn't have to stay true for the next hundred years. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
n 17/08/2015 01:01, Markus Stenberg wrote: > >> On 16.8.2015, at 14.40, Juliusz Chroboczek >> wrote: >> When an HNCP router is restarted, the prefixes it allocated to a link are >> "adopted" by neighbouring routers; if the router then restarts, it will >> agree to the prefixes advertised by its neighbours, which avoids >> renumbering. Why do we care? Homenets need to be renumbering-proof anyway, because the ISP might change the prefix anytime. (We could contrive to have a stable ULA prefix, of course, but that only affects in-home communications.) Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
> On 16.8.2015, at 14.40, Juliusz Chroboczek > wrote: > When an HNCP router is restarted, the prefixes it allocated to a link are > "adopted" by neighbouring routers; if the router then restarts, it will > agree to the prefixes advertised by its neighbours, which avoids > renumbering. > > Unfortunately, this only applies to link with multiple HNCP routers: on > a stub link, a random prefix will be chosen every time we are restarted, > since there are no neighbours that can maintain the state for us. I can > see the following solutions: > > 1. store the chosen prefix in stable storage (but stable storage sucks); > > 2. make an initial choice that is a hash of the interfaces MAC address > (I believe that this is what hnetd does); hnetd does 1+2 (although not sure if OpenWrt version stores 1 to ramdisk currently or not at all by default, cough). > 3. snoop ND/ARP traffic and intuit a suitable prefix. This may be tricky, at least in case of pure v6, as the ND target will be probably link-local address? I guess given multiple nodes on the link, ND would be enough, but I suspect for this to be generic in case of v6 you would have to snoop ‘everything’ and assume first assigned prefix source address that is not published by anyone else within HNCP is one that actually was on the link. With v4, ARP snooping is probably enough to determine the old prefix. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] HNCP: avoiding renumbering
When an HNCP router is restarted, the prefixes it allocated to a link are "adopted" by neighbouring routers; if the router then restarts, it will agree to the prefixes advertised by its neighbours, which avoids renumbering. Unfortunately, this only applies to link with multiple HNCP routers: on a stub link, a random prefix will be chosen every time we are restarted, since there are no neighbours that can maintain the state for us. I can see the following solutions: 1. store the chosen prefix in stable storage (but stable storage sucks); 2. make an initial choice that is a hash of the interfaces MAC address (I believe that this is what hnetd does); 3. snoop ND/ARP traffic and intuit a suitable prefix. Any better ideas? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] HNCP nits re DHCPv4
I think that I've finished implementing most of the DHCPv4 bits in shncpd,
and it was hard work. Requested changes to the draft are at the end. In
the following, I write RA for Router Advertisement and RP for Routing
Protocol. (I'd write Babel, but then somebody would get annoyed, and
I don't like annoying people. Really.)
Did I mention that I rather like HNCP? The HNCP+RA+RP subset of the
Homenet stack is pleasantly robust:
- HNCP state is replicated, and every HNCP instance can restart without
the clients noticing (see "adoption" in the PA draft);
- there is no hard state in the RA and routing protocols that cannot be
recovered from HNCP, so both the RA and RP can be restarted without
the clients noticing;
- every router can run RA and RP, with no need for election or signalling
(participation in RA or RP is signalled over the protocol itself,
a textbook example of fate sharing).
Unfortunately, DHCPv4 doesn't have these properties. DHCPv4 maintains
hard state (the lease database), and multiple DHCPv4 servers must either
synchronise their lease database or split the address space between them.
HNCP works around this issue by electing a single DHCPv4 server for each
link. This sucks, but it sucks less than the alternatives.
I might experiment with working around some of these issues by using RFC
3203 and RFC 6704 (forcerenew with nonce authentication, which is
reportedly implemented by dhcpcd). If you have experience with this
subprotocol, please drop me a note.
I have the following nits:
1. The election process is described in Section 7.3, and uses an ordering
that is sort-of defined in Section 4 (the bit that maps capabilities to
a single integer). This confused me, I suggest either making an
explicit reference to Section 4 in Section 7.3, or simplifying the
election procedure so that the first tie-breaker is not used.
2. Section 7.3 says that DHCPv4 should only announce a default route if
the RP is announcing one. This means that if the RP's default route is
flapping, clients will randomly get or not get the default route. Since
DHCPv4 has much larger latencies than the RP, I think this should be
changed to always announcing a DHCPv4 default route, and trusting ICMP
to do the right thing with respect to unreachable networks.
3. Related to the above, 7.3 requests that a static route be announced to
each delegated prefix. Again, DHCPv4 latencies are too large to make
this useful, and in any case this is redundant if a default route is
unconditionally announced.
4. Section 7.3 says "DHCPv4 lease times SHOULD be short (i.e., not longer
than 5 minutes) in order to provide reasonable response times to
changes." I'm not sure that's necessary -- wouldn't a longer lease
time but with a low rebind timer (T2 in RFC 2131) be more robust?
5. The election is not stateful: should the elected router be unstable,
the election process will be repeated every time it goes up or down.
Since there is no mechanism for passing around the lease database, this
will cause duplicate address allocations (hopefully worked around by
clients performing duplicate detection, but still). A stateful, sticky
(OSPF-style) election process would be preferable to the stateless,
unstable (IS-IS-style) election process currently mandated, but would
cause republishing of node state at each election (since DNCP has no
link-local signalling).
6. The election state is not signalled -- there is no way to find out
whether a router currently considers itself elected by just looking at
its published node state. This makes debugging tricky, but is perhaps
the right thing to do in order to avoid republishing node state at each
election (since DNCP has no link-local signalling).
I'm not familiar with DHCPv6 (SLAAC ftw!), but I think that many of the
above nits apply to stateful DHCPv6 as well. I believe that the spec
should say that stateful DHCPv6 MUST NOT be provided for prefixes of
length 64 (I know that Steven disagrees, see odhcpd issue #55).
On a related note, I'm not sure the draft is sufficiently clear about when
it is allowed to provide stateless ("O") DHCPv6 -- should a router that
has lost the DHCPv6 election provide stateless DHCPv6 service? How will
clients behave if they get RAs with conflicting "M" values?
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Am 10.08.2015 um 19:28 schrieb Fred Baker (fred): > In any event, I would urge the HNCP design team to consider the cases, and > either make an argument that making network routing more complex (BCP 84) has > a benefit I'm missing and actually works without the rule, or change HNCP to > not have each RA contain every possible prefix. After scanning the discussions here, is there anything in particular that people feel which we need to add or clarify in HNCP for that matter? It seems to me that the current behavior, i.e., potentially "non-optimal" router sending out the PIO and then relying on redirection / routing does not really break things. Optimizing the PIO sending might in theory be possible but - as pointed out - is probably very hard to accomplish in practice. In addition, as a personal note from my own reading, I'm not 100% convinced that hosts even following the next-hop tracking of 6724 would correctly react to potential "handover" of a PIO from one router to another since the definition is relatively vague. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
