On 15/11/2012 10:19, Mattia Rossi wrote: > On Thu, Nov 15, 2012 at 9:16 AM, Brian E Carpenter < > [email protected]> wrote: > >> On 14/11/2012 22:44, james woodyatt wrote: >>> On Nov 14, 2012, at 13:34 , Mikael Abrahamsson <[email protected]> wrote: >>>> I've always seen it to be solved via some kind of source based routing >> automatically discovered between the ISP routers. >>> >>> My point is that it isn't sufficient to handle this problem at just the >> routers. At a minimum, the *hosts* need to be told which default router to >> use with each source prefix. >> >> Of course. I suggested this when MIF started out, and it's a MIF >> issue still. >> > > The hosts do already select the correct router depending on the prefix. > They're tied together. An RA contains a prefix and router address. That's > what the host keeps in memory.
Where is that specified? And what if the network is using DHCPv6 to provide such information? The strongest statement I can find in RFC 6724 about this is a MAY in section 7, which doesn't make this predictable. > If it's two RA's one router becomes default, the other more specific. The two might be of equal standing and both offer a route to ::/0. > The > host/applications will also only use one prefix at a time, thus always send > the packets down the correct path. I don't believe that is fully specified either. Each new socket might make a new choice. > In my experience it was always the same prefix, the one that got registered > first (if no preference was setup in the advertising router). > If the host is connected via two or more interfaces (so we're in MIF area > now), there will always be one preferred prefix, and interface, and the > outgoing routing will work. Then why is MIF still arguing? > If applications are able to chose a specific prefix (e.g. VPN) they usually > implement some source routing on the host anyways, and send the packets to > the router registered with that prefix. Sure, but we are worried here about zero-conf defaults. > If you have an application listening for incoming connections, then it's > important that the application is smart enough to use the address on which > the incoming connection arrived as source address, and not the default one > which might be on a different prefix to avoid asynchronous communication. > As far as I know this is already common practice. Not good enough - it needs to be specified. > So I don't really see a > problem here, unless you want to do some fancy load sharing and play ping > pong with source addresses. > If there's only one interface which connects to a multihomed router, the > principle is the same, but the multihomed router must be able to perform > source address routing, and forward the packets down the right path. And > this is something I'm not too sure about routers can currently do. Indeed. Again, this needs specifying, as does behaviour when there are multiple routers and one of them receives a packet that should exit via another one. https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat/ Brian > Mat > _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
