Re: A Suggestion for Address Selection

[Arifumi Matsumoto <[e-mail]>]

Hi,

just a quick comment.

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

> Hi,
>
> Arifumi Matsumoto wrote:
>> I found this is a very interesting proposal.
>> One question.
>
> 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?
>
>> What happens if you use a routing protocol such as RIPng
>> 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.
>
>> The existing routing protocols and RFC4191 more specific
>> routes deliver routing information bound to the interface,
>> not to the address.
>
> 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.
>
>
>
> 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.
>
> -- 
> 	Aleksi Suhonen
> 	Department of Communications Engineering
> 	Tampere University of Technology


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