Hi Ole, Op 21 mrt. 2013, om 09:13 heeft Ole Troan <[email protected]> het volgende geschreven:
> Teco, > > [...] > >>> I don't think the homenet should get into the "policy" part of this, but >>> rather just provide some simple tools/infrastructure. >> >> Hmm. >> I also prefer simple tools/infrastructure. But let's try to solve some >> problems, or at least we shall not block solving later on. > > are the problems clearly understood at this point? > written down? We have RFC6418 and RFC4477. Maybe we need to write down the multiple DHCP server problem (homenet with set of CPE devices attach to different provides, each with "incompatible" DHCP info). v6ops-ipv6-multihoming-without-ipv6nat-05 points towards the problem, section 7.3. Policy collision consideration. However, in the abstract it says: ... We conclude that DHCPv6 based solutions are suitable to solve the multihoming issues, described in this document, while NPTv6 may be required as an intermediate solution. May I say I think DHCPv6 and NPTv6 don't fix the problems? Maybe they make live even harder for right shaped MIF hosts. >>>> I agree SADR is a major part of the right solution. Source address >>>> indicates the provision domain, at least for IPv6. Hosts need to be >>>> updated and mif should take the lead here. But mif only can take the job >>>> if the network supports multiple provisioning domains well, e.g. SADR. >>>> Updated hosts need SADR as well. >>> >>> I've always seen SADR as a network function. hosts would do RFC6724. >> >> SADR on hosts is used quite often, where redundant links are in place. > > that's not SADR. SADR is about _forwarding_ of packets. The troan-homenet-sadr is written for routers. It applies to hosts with multiple interfaces or single interface with multiple next-hop routers as well: same problem, can use same solution. For both cases, RFC6724 hosts need a little luck to make best guesses. So for me, Source Address Dependent Routing (SADR) and source address-based routing (out of multihoming-without-ipv6nat-05) are two names for same animal. > [...] > >> Back to the draft-ietf-homenet-arch WGLC: this provisioning domain topic is >> not addresses very well. Question is if we will address it, hand it over to >> mif, or cooperate where we focus on the (plug&play) network part and mif >> takes the hosts. > > I think we have a fair idea of how to deal with the home network being > multi-homed. i.e. two or more connections to the Internet. Yes, we can deal with routing: do something with source address. > we also have a decent idea of how to deal with multi-homing to non-congruent > networks, see draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05 > I'm not quite sure what problem "multiple provisioning domains" is trying to > solve outwith that. I don't think we decided how to deal with disjunct config options (DHCPv6 or learned via other means), on how we can relay this info over a homenet to a MIF host, without losing any functionality. draft-boot-homenet-brdp-00 deals with it. It provides MIF hosts pointers to the border router, where for each provisioning domain there is a prefix and a border router with an address within that prefix. So an aware host can get all it wants to know. Teco _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
