On Tue, 16 Sep 2003, Curtis Villamizar wrote:
In message <Pine.LNX.4.44.0309160816080.5651-100000@netcore.fi>, Pekka Savola w rites:
Did you even read what I wrote? I certainly didn't see a problem in having different IPv6 and IPv4 records, because, well, they have to be different anyway. I believe I gave a couple of points to consider as well.
If you have no issue with separate IPv6 and IPv4 records then the matter is resolved. There is no transition problem, nor is there any long term problem other than separate IPv6 and IPv4 records which may be a nuisance later at worst.
I recall that RPSLng also supports ipv4.unicast (which is supported by RPSL as well), and ipv4.multicast. The issue is clearly not settled by that, I think,
RIPE uses its database mostly as a Internet address and AS registry. That you can express policy in RPSL for RIPE is just an added benefit for their customers. RIPE has had IPv6 inetnum records for a very long time for the purpose of address registry.
This is irrelevant: the fact stands that at least in the RIPE region (I don't know much of the others, but I guess the situation is pretty much the same), RPSLng has *not* been deployed at all. So, it seems to me that any statements of its wide use are quite questionable.
A lot of RPSL use is explicitly to express routing policy. While RIPE is a major user of RPSL and one of the major contributors to RPSL, their use of it is limited in this way.
Exactly. Operators in the RIPE region have, for some time now, expressed a need for a database supporting expressing IPv6 routing policies (more than anything else!). It only recently got announced (as a test version, I recall). Which seems to strongly say that the RPSLng use has been minimal at best, and there has been no real deployment. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings