[ Note that I've changed the "Reply-to:" to rpslng@ripe.net in an effort to move this discussion to the most appropriate list. Further discussion should (hopefully) occur in that forum. ] On 2003-01-15 09:51:02 -0000, adrian.pauling@bt.com wrote:

we have 'inet6num' objects separate to 'inetnum' to distinguish IPv6 address assignments from IPv4.

Is the question should different 'peering-set' 'route' objects etc reflect different peerings for IPv6 from IPv4 that an assigned AS can have? This scenario is real as I can easily give a current (enterprise LIR) example.

Short answer: You should be able to define different peerings for IPv4 and IPv6 networks with RPSLng. Long answer: When extending RPSL to deal with IPv6 (and multicasting) there were two kinds of objects to consider. For most objects, IP information was encoded in attributes. To handle these, new attributes were added to allow IPv6 and multicast information to be defined in existing objects. RPSL specifies that if there is an unknown attribute it should be ignored - this allows backwards compatibility. These basically work like the old definitions, but they allow for IPv6 and multicast information. So with RPSLng there are these new attributes: mp-import: mp-export: mp-default: mp-members: mp-filter: mp-peering: mp-peer: For route definitions, the IPv4 network advertisement is actually in the key of the class, so it could not be changed without breaking compatibility. Therefore the route6 class was introduced. It is very close to the IPv4 route definition: route6: fe80::2b0:d0ff:feed:39e1/128 . . . origin: AS3333 . . . This is all in the draft: http://www.ietf.org/internet-drafts/draft-damas-rpslng-00.txt -- Shane Kerr RIPE NCC