Subject: A Suggestion for Address Selection

From: Aleksi Suhonen <[email-masked]>
Date: Mon, 15 Jun 2009 06:02:54 +0300

Hi,

This is a request for comments on a draft for an internet draft on a new
address selection algorithm that I'm developing as part of the Finnish
Future Internet project. I'm trying to find a home working group for it,
but I'm not finding it easy since it seems to affect so many things.

Instead of sending the whole text on several mailing lists, I put the
rough draft on the web:

http://www.axu.tm/2009/draft-axu-addr-sel-pre00.html

The motivation for this algorithm comes from multi-pathing protocols and
the need for agile address re-selection when forced to reroute.

I've been told (by Jari Arkko among others) that 6man would be the 
correct working group for this work, but the charter doesn't seem to say 
anything about this...

Sincerely awaiting your constructive feedback,

--
	Aleksi Suhonen
	Department of Communications Engineering
	Tampere University of Technology

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 18 Jun 2009 15:12:39 +0900

Hi, Aleksi.

I found this is a very interesting proposal.

One question.

What happens if you use a routing protocol such as RIPng
to deliver some routes to this kind of host ?

The existing routing protocols and RFC4191 more specific
routes deliver routing information bound to the interface,
not to the address.

Kindest regards,

On 2009/06/15, at 12:02, Aleksi Suhonen wrote:

> correct working group for this work, but the charter doesn't seem to  
> say anything about this...
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--
Arifumi Matsumoto
   Secure Communication Project
   NTT Information Sharing Platform Laboratories
   E-mail: [email-masked]

---

From: Aleksi Suhonen <[email-masked]>
Date: Thu, 18 Jun 2009 16:59:52 +0300

Hi,

> I found this is a very interesting proposal.

Thank you. I have one question too:

Should I submit the draft (after I write a bit more of it) for 
discussion in Stockholm for this WG or for some other WG? And could I 
reserve a presentation time slot for this WG in any case, please? How?

> to deliver some routes to this kind of host ?

I haven't really thought those issues through yet. There's plenty of 
room for discussion. Disclaimer: I spent a lot of time thinking while 
writing the answers below, and it might come across a bit incoherent.

> routes deliver routing information bound to the interface,

RFC4191 should be dealt with the same way as routes received from DHCP, 
i.e. they are added only into the routing table associated with the 
address received or formed using the same RA or DHCP transaction.

In other words, those more specific routes should be usable only with 
that source address.

If you want to add some dynamically learned more specific routes to all 
tables instead of only one, the admin has to specifically instruct the 
host to do so. I haven't come up with anything better than that yet. 
Then again, the admin can just add the same dynamic routes to all the 
agents that are being used to teach addresses to the host.

By default, as it now reads, when you enable forwarding or a routing 
protocol on the host, the algorithm starts combining tables of similar 
scope together, and the functionality basically reverts to the same as 
before where routing information is bound to the interface.

If the system/network admin wants to prevent combining the tables of 
certain prefixes (because they are from different operators for example) 
then the admin would need to specifically instruct the kernel or the 
routing protocol daemon running on the host correctly.

The basic idea is that one routing protocol instance modifies one 
routing table. If you want to manage two address spaces and two routing 
tables, you need two routing protocol instances. You can of course run 
two completely different routing protocols too.

There is a problem hidden in here tho: very few routing protocols are 
designed so that you could run several separate instances of the same 
routing protocol on the same interface. Off the top of my mind, only BGP 
and EIGRP come to mind quickly. And BGP requires a bit of hacking to 
manage it too. Many more routing protocols support so called 
multi-topology extensions. Those could perhaps be harnessed to for this 
purpose too: one topology per one table and address space.

I've been trying to come up with a solution that would allow the end 
host to automatically identify the scope of any address with minimal 
admin intervention. My first idea was that if the host receives a 
default router for that address, it can assume that it's usable on the 
Internet. When configuring site local addresses the host would receive 
routes only for site local address space using DHCP or RFC4191.

While writing this email, this idea struck me: why not add a new DHCP 
option which associates a scope tag (free form text or just an integer) 
with the address and routes. When the host receives the same tag on two 
different interfaces or from two different sources, it knows that it's 
possible to combine those tables. And if it receives different tags, it 
knows that those tables should never be combined into one.

The tags themselves would have no other meaning to the machines. Their 
usability for different purposes would be governed by the routes 
associated with them.

To humans those tags would communicate things like VRF name or upstream 
operator name or site scope or global scope.

When thinking about the preferences/precedences issue, I considered 
using prefix length as one preference input. I mean, if there is a valid 
route for a destination address in two different tables, but the 
matching route in one table is more specific than the matching route in 
the other table, then the more specific route would be more preferable.
But as soon as I thought about this, I came up with scenarios where this 
could cause problems or the exact opposite would be preferable.

Uhh ... the message is still a bit incomplete, but I'm pressing send now 
anyway, because it's midsummer holiday here tomorrow and I have to go 
shop for food now, lest I starve over the weekend.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 19 Jun 2009 17:56:41 +0900

Hi,

just a quick comment.

On 2009/06/18, at 22:59, Aleksi Suhonen wrote:

> discussion in Stockholm for this WG or for some other WG? And could  
> I reserve a presentation time slot for this WG in any case, please?  
> How?
>
> room for discussion. Disclaimer: I spent a lot of time thinking  
> while writing the answers below, and it might come across a bit  
> incoherent.
>
> RFC4191 should be dealt with the same way as routes received from  
> DHCP, i.e. they are added only into the routing table associated  
> with the address received or formed using the same RA or DHCP  
> transaction.

RA can include multiple PIO(prefixes).
If I remember correctly, DHCPv6 does not have any means to deliver  
routing information right now. There is a proposal, though.

Of course, as you mentioned, changing routing protocols themselves to  
deliver address-dependent information should solve this issue.

Kindest regards,

> In other words, those more specific routes should be usable only  
> with that source address.
>
> If you want to add some dynamically learned more specific routes to  
> all tables instead of only one, the admin has to specifically  
> instruct the host to do so. I haven't come up with anything better  
> than that yet. Then again, the admin can just add the same dynamic  
> routes to all the agents that are being used to teach addresses to  
> the host.
>
>
>
> protocol on the host, the algorithm starts combining tables of  
> similar scope together, and the functionality basically reverts to  
> the same as before where routing information is bound to the  
> interface.
>
> certain prefixes (because they are from different operators for  
> example) then the admin would need to specifically instruct the  
> kernel or the routing protocol daemon running on the host correctly.
>
> routing table. If you want to manage two address spaces and two  
> routing tables, you need two routing protocol instances. You can of  
> course run two completely different routing protocols too.
>
> There is a problem hidden in here tho: very few routing protocols  
> are designed so that you could run several separate instances of the  
> same routing protocol on the same interface. Off the top of my mind,  
> only BGP and EIGRP come to mind quickly. And BGP requires a bit of  
> hacking to manage it too. Many more routing protocols support so  
> called multi-topology extensions. Those could perhaps be harnessed  
> to for this purpose too: one topology per one table and address space.
>
>
> default router for that address, it can assume that it's usable on  
> the Internet. When configuring site local addresses the host would  
> receive routes only for site local address space using DHCP or  
> RFC4191.
>
> While writing this email, this idea struck me: why not add a new  
> DHCP option which associates a scope tag (free form text or just an  
> integer) with the address and routes. When the host receives the  
> same tag on two different interfaces or from two different sources,  
> it knows that it's possible to combine those tables. And if it  
> receives different tags, it knows that those tables should never be  
> combined into one.
>
> The tags themselves would have no other meaning to the machines.  
> Their usability for different purposes would be governed by the  
> routes associated with them.
>
> To humans those tags would communicate things like VRF name or  
> upstream operator name or site scope or global scope.
>
>
> using prefix length as one preference input. I mean, if there is a  
> valid route for a destination address in two different tables, but  
> the matching route in one table is more specific than the matching  
> route in the other table, then the more specific route would be more  
> preferable.
> But as soon as I thought about this, I came up with scenarios where  
> this could cause problems or the exact opposite would be preferable.
>
>
> Uhh ... the message is still a bit incomplete, but I'm pressing send  
> now anyway, because it's midsummer holiday here tomorrow and I have  
> to go shop for food now, lest I starve over the weekend.
>
> -- 
> 	Aleksi Suhonen