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: <[email protected]>
>>> 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 <[email protected]>, Jen Linkova <[email protected]>,
>>> "Fred Baker" <[email protected]>, "J. Linkova" <[email protected]>
>>>
>>>
>>> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> _______________________________________________
> v6ops mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/v6ops
>
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
