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