Re: [homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00)

2016-07-27 Thread Dave Taht 
On Wed, Jul 27, 2016 at 8:39 PM, David Lamparter  wrote:
> On Thu, Jul 21, 2016 at 09:49:46AM +0200, Lorenzo Colitti wrote:
>> On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter  wrote:
>> > 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:
>> >
>>
>> David, do you intend to keep working on the patches? Think you could send
>> them to netdev as an RFC patchset, with proper signoff? Once it's on netdev
>> other people can iterate on them, even if you lose interest :-)
>
> I've uploaded the patches (with signoffs) to:
> https://aurora.nox.tf/tmp/rule55/

Thank you for posting the patches. I will try them out the next time I get time.

I think I object to landing IPV6_SADDR_RULE_OIF_RTR in the middle of
the existing enum rather than at the end, but will twiddle further.

> NB: patch 2 of 3 is slightly different from the version I mailed, I
> accidentally lost a NULL check in ipv6_rt_get_saddr().
>
> I do _not_ intend to continue working on these since I now believe the
> functionality should be put on neighbor cache entries.  This requires
> some (minor IMHO) rework to make these neighbor entries stay alive until
> their prefix information times out.  By putting it there, it can support
> addresses that are configured from dhcpv6 or static/admin.

I think I agree, but looking over the existing patches is a goodness.
I was only just made aware that getting source specific routing to
work well in other base ipv6 protocols had entered ietf consideration
in this past ietf, and have some catching up to do.

Has there been any work on improving how the std APIs might work on
choosing a better source address for a given destination? I see some
work has happened in mptcp

> The code
> linked above only works for SLAAC.

One thing that has bothered me of late has been the lack of symmetry
regarding address assignment's sources, vs how routes are handled.

ip -6 route add fd01::1 via fe80::1 dev whatever proto static #
rip/babel/dhcp/etc

vs

ip -6 addr add fd01::2/64 dev whatever # with no means to specify that
it came from slaac/dhcpv6/static/hncp/background radiation.

The existing bits for things like tmpaddr, mgmt_tmpaddr and scope
seems to be breaking down in the representability...

>
> => the patches are intended purely for testing, for example if someone
> hacks on the router side and wants to use Linux VMs to test the full
> picture.
>
> Cheers,
>
>
> -David



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00)

2016-07-27 Thread David Lamparter 
On Thu, Jul 21, 2016 at 09:49:46AM +0200, Lorenzo Colitti wrote:
> On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter  wrote:
> > 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:
> >
> 
> David, do you intend to keep working on the patches? Think you could send
> them to netdev as an RFC patchset, with proper signoff? Once it's on netdev
> other people can iterate on them, even if you lose interest :-)

I've uploaded the patches (with signoffs) to:
https://aurora.nox.tf/tmp/rule55/

NB: patch 2 of 3 is slightly different from the version I mailed, I
accidentally lost a NULL check in ipv6_rt_get_saddr().

I do _not_ intend to continue working on these since I now believe the
functionality should be put on neighbor cache entries.  This requires
some (minor IMHO) rework to make these neighbor entries stay alive until
their prefix information times out.  By putting it there, it can support
addresses that are configured from dhcpv6 or static/admin.  The code
linked above only works for SLAAC.

=> the patches are intended purely for testing, for example if someone
hacks on the router side and wants to use Linux VMs to test the full
picture.

Cheers,


-David

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00)

2016-07-21 Thread Brian E Carpenter 
On 21/07/2016 02:34, David Lamparter wrote:
> On Thu, Jul 21, 2016 at 01:22:15AM +1200, Brian E Carpenter wrote:
>> On 21/07/2016 01:13, Lorenzo Colitti wrote:
>>> On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter  wrote:
>>>
 - 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?

>>>
>>> The way I thought of doing this would be to alternatively/additionally keep
>>> a pointer from the default router that announced a given prefix (which does
>>> have the link-local address of the router) to each address that was
>>> configured from that prefix. That way, when an address goes away you can
>>> scan the FIB and find another router to associate with that prefix.
>>>
>>> As for lifetimes expiring, you would need to have somewhere to keep dummy
>>> zero-lifetime default routes. It might be possible to do this in the FIB
>>> itself by adding a special entry that doesn't ever match anything, or has
>>> an infinite metric, or a different type...
>>
>> Please tell us ASAP if there is anything we should add to
>> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#section-3.2
>> or thereabouts.
> 
> I do see some trouble in use-cases where more than one actual router
> (actual = not counting extra link-local addresses on the same router) is
> present on a link, advertising the same prefix to hosts.  (This is
> reasonably likely in homenet scenarios, maybe less in enterprise.)
> 
> If the host only tracks a maximum of one RA source LL for a
> prefix/address, but the router with that LL happens to not be the one
> actually used (e.g. preference, router gone, more specific route from
> RIO, whatever else) then the functionality is lost.  It's particularly
> bad if the one RA source LL is the one prefix was first seen from (and
> then, worst-case, never updated).
> 
> (The neccessary precondition / assumption being broken there is that the
> test "was prefix X announced by router Y" doesn't report false
> negatives.  I haven't applied brain to false positives yet.)

Is this any worse than if the single default router in a traditional host
goes away, which will break all off-link packets until something happens?

I'm not saying it isn't a problem, but it doesn't sound like it's a new
problem that applies only in the multihomed case.

Brian

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00)

2016-07-20 Thread David Lamparter 
On Thu, Jul 21, 2016 at 01:22:15AM +1200, Brian E Carpenter wrote:
> On 21/07/2016 01:13, Lorenzo Colitti wrote:
> > On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter  wrote:
> > 
> >> - 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?
> >>
> > 
> > The way I thought of doing this would be to alternatively/additionally keep
> > a pointer from the default router that announced a given prefix (which does
> > have the link-local address of the router) to each address that was
> > configured from that prefix. That way, when an address goes away you can
> > scan the FIB and find another router to associate with that prefix.
> > 
> > As for lifetimes expiring, you would need to have somewhere to keep dummy
> > zero-lifetime default routes. It might be possible to do this in the FIB
> > itself by adding a special entry that doesn't ever match anything, or has
> > an infinite metric, or a different type...
> 
> Please tell us ASAP if there is anything we should add to
> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#section-3.2
> or thereabouts.

I do see some trouble in use-cases where more than one actual router
(actual = not counting extra link-local addresses on the same router) is
present on a link, advertising the same prefix to hosts.  (This is
reasonably likely in homenet scenarios, maybe less in enterprise.)

If the host only tracks a maximum of one RA source LL for a
prefix/address, but the router with that LL happens to not be the one
actually used (e.g. preference, router gone, more specific route from
RIO, whatever else) then the functionality is lost.  It's particularly
bad if the one RA source LL is the one prefix was first seen from (and
then, worst-case, never updated).

(The neccessary precondition / assumption being broken there is that the
test "was prefix X announced by router Y" doesn't report false
negatives.  I haven't applied brain to false positives yet.)


-David

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00)

2016-07-20 Thread David Lamparter 
On Wed, Jul 20, 2016 at 03:13:05PM +0200, Lorenzo Colitti wrote:
> On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter  wrote:
> 
> > - 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?
> >
> 
> The way I thought of doing this would be to alternatively/additionally keep
> a pointer from the default router that announced a given prefix (which does
> have the link-local address of the router) to each address that was
> configured from that prefix.

That turns nontrivial as soon as you have 4191 RIOs, especially if the
router is trying to do walled gardens by sending its RAs with lifetime =
0 (as suggested in section 4.2.2 of pa-multihoming).

> That way, when an address goes away you can scan the FIB and find
> another router to associate with that prefix.

[I assume "address goes away" meant "router goes away"]

> As for lifetimes expiring, you would need to have somewhere to keep dummy
> zero-lifetime default routes. It might be possible to do this in the FIB
> itself by adding a special entry that doesn't ever match anything, or has
> an infinite metric, or a different type...

That sounds quite a bit more complicated than address-centric
handling...  we're 1:N for router['s LL address] to routes and also 1:N
for router['s LL address] to prefixes, and then 1:N for prefix to
derived addresses.

I'd rather copy the prefix lifetime (either valid or preferred -
probably former?) onto the same list entry where a configured address's
RA source LL is also stored; that replicates only the last 1:N step...
(So, for each address, in its list of RA sources that the prefix was
seen from, there will be a potentially-distinct lifetime.)


-David

P.S.: Does anyone know the details of how Windows implements this?

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00)

2016-07-20 Thread Brian E Carpenter 
On 21/07/2016 01:13, Lorenzo Colitti wrote:
> On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter  wrote:
> 
>> - 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?
>>
> 
> The way I thought of doing this would be to alternatively/additionally keep
> a pointer from the default router that announced a given prefix (which does
> have the link-local address of the router) to each address that was
> configured from that prefix. That way, when an address goes away you can
> scan the FIB and find another router to associate with that prefix.
> 
> As for lifetimes expiring, you would need to have somewhere to keep dummy
> zero-lifetime default routes. It might be possible to do this in the FIB
> itself by adding a special entry that doesn't ever match anything, or has
> an infinite metric, or a different type...

Please tell us ASAP if there is anything we should add to
https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#section-3.2
or thereabouts.

Brian

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00)

2016-07-20 Thread David Lamparter 
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.

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 +, 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: 
> > 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 , Jen Linkova , 
> > "Fred Baker" , "J. Linkova" 
> > 
> > 
> > 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 .
> > 
>