On Nov 14, 2012, at 17:22 , Michael Richardson <mcr+i...@sandelman.ca> wrote: > > james> My point is that it isn't sufficient to handle this problem > james> at just the routers. At a minimum, the *hosts* need to be > james> told which default router to use with each source prefix. > james> Right now the only mechanism that comes close to doing that > james> is ICMPv6 Redirect, which isn't suitable for addressing this > james> problem. > > the edge routers can fix things for the hosts.
If they coordinate. Section 3.2.4 Multihoming of I-D.ietf-homenet-arch-06 goes into some detail about the challenges in the scenario under discussion in this thread, and it mentions two proposals by name: I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat I-D.baker-fun-multi-router Neither of which sufficiently answers my open questions about how multiple provider-provisioned subscriber gateways will coordinate forwarding of packets to the correct egress for their source prefix. Please don't misunderstand: I can imagine a routing protocol that could do what I-D.baker-fun-multi-router describes, more or less-- it would display the local path asymmetry I described previously, but that might not be a deal-killer. What I can't imagine is that operators of provider-provisioned subscriber gateway equipment will have any incentive to deploy such a routing protocol, and I can imagine several ruthless and selfish reasons for them to resist. For starters, imagine this scenario: I'm an unhappy customer of ALFA Broadband, which is the largest incumbent carrier in my region, and I want to add the scrappy local underdog bargain provider, BRAVO Networks, as an egress to my existing HOMENET installation, so I can be multi-homed while I renumber and transition from one service provider to another. When I sign up with BRAVO, they have to ask me: is this a new HOMENET, or do you have an existing HOMENET routing domain we need to join. If I tell BRAVO it's a new HOMENET, then I don't get be to be multihomed with ALFA because their equipment won't forward packets with ALFA's source address either to ALFA's router or to the global Internet. Sadness. Must tell them about the existing HOMENET installation then. If I tell BRAVO it's an existing HOMENET, then I can only be multihomed if I can also get ALFA's router to admit BRAVO's new router to the routing domain it serves, but ALFA provisioned the thing and configured it for me. It's a crude black box as far as I'm concerned, and that's just how both they and I like it. So, to complete this migration, I now have to call up ALFA and say to them, "Hi, I just signed up with your competitor, and I'd like for the router you installed for me, with whatever firmware it's running, to cooperate with their new router, running who knows what, in the HOMENET routing domain you set up for me years ago when I first signed up. Would you please reconfigure? Kthxbai!" Any guesses what their response is likely to be? I'm honestly not sure how we expect this to work. It seems, either A) I have to be a highly technical mediator between ALFA Broadband and BRAVO Networks for the coordination of any HOMENET routing domain for which they're both going to provide access service, or B) they have to communicate directly with one another. Neither alternative seems very practical to me. > this has been discussed on this list extensively. Without apparent resolution or the production of a draft as far as I can see. Hence my ongoing skepticism about this usage scenario. -- james woodyatt <j...@apple.com> core os networking _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
