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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
