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: arif...@nttv6.net
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------