Ole, Do you think that Neighbor Discovery needs to be extended to support the advertisement of (S,D) routes?
Currently ND Router Advertisements allow the advertisement of source prefixes in PIOs and destination prefixes in RIOs, but I don't see any existing mechanism to associate a particular source prefix with a particular destination prefix. draft-sarikaya-6man-sadr-ra-03 offers one way to associate a source prefix with a destination prefix in Router Advertisements. If not, what mechanism do you think should be used to communicate (S,D) routes to the host? Thanks, Chris -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Tuesday, April 12, 2016 2:02 AM To: Chris Bowers <[email protected]> Cc: David Lamparter <[email protected]>; [email protected] Subject: Re: Implications of default-only SADR (was: Re: multi-homing for provider-assigned IPv6 addresses) Chris, > I think that different participants in this discussion may have different > ideas about how this should be done. The homenet architecture principles > document (RFC 7368) and draft-ietf-6man-multi-homed-host-06 both point to RFC > 6724 as providing a solution for source address selection with multi-homing, > but both documents also seem to acknowledge that RFC 6724 doesn't provide a > complete answer. In the discussion in RTGWG on Thursday, Fred Baker said > that thinks a Happy Eyeballs RFC 6555 should play a roll as well. There was > also a mention of having the host use ICMP to detect failures. > > I think we need to be very explicit about our assumptions about how the host > is going to select the source address, especially if we expect the host to > use dest/source route information. This is also consistent with Alvaro > Retana's more general request in RTGWG that we consider a complete solution > to the PA multi-homing problem, as opposed to just considering individual > pieces of a potential solution in isolation. OK, so you asked for it. ;-) Let me try to quickly outline all the assumptions here. In a multi-prefix multi-homed case a host has one or more IPv6 addresses from more than one IPv6 prefix. - The host assumes that by picking source address it also chooses the exit in the network. In the case where a host is directly connected to two independent exit routers, see below 6man draft for next-hop selection. This assumption implies that the network is capable of SADR. - To achieve the goals set out in RFC3582, the burden of multi-homing is squarely put on the shoulders of the host. It must be capable of picking the best path, load-share across multiple paths, detect failures and switch over to a functioning path etc... That requires either very smart applications, like MOSH. Or it requires improved transport, like MPTCP or perhaps SCTP. Initial path selection, is either use them all (like MPTCP), or throw spaghetti on the wall and pick the ones that stick. It is expected that the host maintains some heuristics over time, so it doesn't necessarily have to try Sn*Dn combinations for each connection. RFC6724 gives you the "cheap" version of this by falling back to 'topologically closest' S,D. - As you can see the assumptions put on the routing layer is pretty trivial compared to what the host has to do. - Plan B is ILNP or resort to 3rd party multi-home proxies like what LISP can do. General considerations: RFC7157 - IPv6 Multihoming without Network Address Translation Host source address selection: RFC6724 - Default Address Selection for Internet Protocol Version 6 (IPv6) RFC7078 - Distributing Address Selection Policy Using DHCPv6 RFC6731 - Improved Recursive DNS Server Selection for Multi-Interfaced Nodes Host next-hop selection: draft-ietf-6man-multi-homed-host-06 - Routing packets from hosts in a multi-prefix network Carrying edge specific meta information with prefixes, aka provisioning domains: RFC7556 - Multiple Provisioning Domain Architecture Best regards, Ole _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
