Scott,
>>
>> Ran and I drafted this in reaction to the earlier discussion here
>> about the impracticality of renumbering. We'd like comments and, above
>> all, contributions. For now, this list is suggested for any discussion,
>> but I will also mention the draft on the intarea list.
>
> Hi Brian and Ran. Unfortunately for me you didn't produce a magic
> solution for the site policy change issues (Section 4.3.4). I think
> that's the critical issue area.
Let's consider the configuration of a firewall for example. Assume that
foo's firewall needs to have an access list for one prefix owned by bar.
Today, foo's sysadmin will lookup bar's prefix and will create an access
list containing bar's prefix.
Instead of using IP addresses directly, assume that bar publishes (with
a URL, an XML document or through the DNS) the list of its prefixes with
a unique name assigned to each prefix and a lifetime, e.g.
prefix1.bar = 1.2.3.0/24, ttl=1 day
Then, foo's firewall could be configured with prefix1.bar. foo's
firewall could contain a daemon that checks regularly bar's database to
updates its access lists. When bar needs to renumber, it will first
change its database to contain
prefix1.bar = (1.2.3.0/24, 4.5.6.0/24), ttl=1 hour
foo's daemon will update its configurations by using the mechanism
described in
http://inl.info.ucl.ac.be/publications/preparing-network-configurations-ipv6-renumbering
Later, once renumber is finished, bar will change its database to contain
prefix1.bar = 4.5.6.0/24, ttl=1 day
and foo's dameon will again update its access list
Of course, bar's database needs to be secure and if foo cannot contact
bar's database, it should assume that there are no changes.
I think that a similar approach could be extended for other services
where you need information about prefixes managed by a remote site.
Olivier
--
http://inl.info.ucl.ac.be , UCLouvain, Belgium
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
