[db-wg] RE: [lir-wg] should aut-num object for IPv4 & IPv6 be the same?

[ Note that I've changed the "Reply-to:" to rpslng at 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 at 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