On 21/07/2016 00:54, David Lamparter wrote: > As mentioned on mic during rtgwg, I think the idea of affecting host > source address selection through 6724 rule 5.5 is potentially very > useful and IMHO should be explored.
And please note that draft-ietf-6man-multi-homed-host-07 (in IETF Last Call) recommends hosts to support this, exactly to assist SADR solutions. Brian > Hence, I hacked it up for the Linux (4.5.0) kernel; patches are attached > to this mail. I've been able to gleam a little more detail on the idea: > > - it's a bit unclear how an address/prefix's "source" next-hop is kept > in association. The simplistic approach of adding a "PA source ipv6 > address" for each of a host's configured addresses falls flat when > more than 1 router advertises the same prefix, so I implemented it as > a list -- however, my hack never removes entries off that. It should > possibly have a copy of the PA's valid time? > > (Read as: the "Discussion" note in 6724 is right on the mark - the > details are not quite specified.) > > - in that avenue, I don't think it's possible to store the information > in a route-centric way, because RA lifetimes tend to be shorter. > If a router goes away and comes back, it seems to me that the prefix's > associated origin/nexthop should still be there. > > - rule 5.5 makes RA preference carry into source address selection. I > think this is described in the draft, I just failed to grasp that from > the presentation. Very useful for getting source selection right in > the face of unequal performance uplinks. > > - if you want to manage this in an userspace process on Linux, you can > simply update the route's preferred source attribute. > > The attached patchset also has the following caveats that result from me > just doing a quick hack: > - there is no debugging/user visibility of the value > - as mentioned above, tracked source addresses never go away unless the > entire address dies. It caps at 4 sources (so you can't exhaust > kernel memory by spoofing...) > - I should probably pass Linux's "dst" instead of "rt6_info" > - I didn't check for locking/concurrentness violations > - there's a const warning which I ignored. > > Either way if anyone wants to tinker with it, here it is. > No warranties, YMMV. You touch it, it becomes your responsibility ;) > > Cheers, > > > -David > > On Wed, Jul 06, 2016 at 04:33:18PM +0000, Fred Baker (fred) wrote: >> At IETF 94, this working group advised the routing ADs and Routing Working >> Group that PA multihoming would not work without a source/destination >> routing solution. This draft was developed in response. Routing Working >> Group requests v6ops review. >> >>> Begin forwarded message: >>> >>> From: <internet-dra...@ietf.org> >>> Subject: New Version Notification for >>> draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>> Date: July 5, 2016 at 5:58:25 PM PDT >>> To: Chris Bowers <cbow...@juniper.net>, Jen Linkova <fu...@google.com>, >>> "Fred Baker" <f...@cisco.com>, "J. Linkova" <fu...@google.com> >>> >>> >>> A new version of I-D, draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>> has been successfully submitted by Fred Baker and posted to the >>> IETF repository. >>> >>> Name: draft-bowbakova-rtgwg-enterprise-pa-multihoming >>> Revision: 00 >>> Title: Enterprise Multihoming using Provider-Assigned >>> Addresses without Network Prefix Translation: Requirements and Solution >>> Document date: 2016-07-05 >>> Group: Individual Submission >>> Pages: 44 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-bowbakova-rtgwg-enterprise-pa-multihoming/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00 >>> >>> >>> Abstract: >>> Connecting an enterprise site to multiple ISPs using provider- >>> assigned addresses is difficult without the use of some form of >>> Network Address Translation (NAT). Much has been written on this >>> topic over the last 10 to 15 years, but it still remains a problem >>> without a clearly defined or widely implemented solution. Any >>> multihoming solution without NAT requires hosts at the site to have >>> addresses from each ISP and to select the egress ISP by selecting a >>> source address for outgoing packets. It also requires routers at the >>> site to take into account those source addresses when forwarding >>> packets out towards the ISPs. >>> >>> This document attempts to define a complete solution to this problem. >>> It covers the behavior of routers to forward traffic taking into >>> account source address, and it covers the behavior of host to select >>> appropriate source addresses. It also covers any possible role that >>> routers might play in providing information to hosts to help them >>> select appropriate source addresses. In the process of exploring >>> potential solutions, this documents also makes explicit requirements >>> for how the solution would be expected to behave from the perspective >>> of an enterprise site network administrator . >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >> > > > >> _______________________________________________ >> v6ops mailing list >> v6...@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet