[DBWG] RIPE proposed changes to the routing registry

Daniel Shaw daniel at afrinic.net
Thu May 17 06:13:22 UTC 2018


On 17/05/2018, 09:27, Frank Habicht	typed:

>> 
> You have a point that there was not much activity.
> Let me try to change that.
> 
> Can the AfriNIC DB be changed so that Andrew with his non-AfriNIC ASN
> can freely, quickly [ie without manual intervention by hostmaster]
> create route(6) objects for the AfriNIC IP space.
> Could the addition of an attribute to all inet(6)num delegations enable
> this?
> 

On a technical level, yes. The implementation can be changed in code such that the above would work.

However, the decision is not about technical limitations, but rather more about what is the current understood business rules and processes across the organisation.

I cannot promise anything personally right now, but I believe that if there is a general community consensus that this would be better than the current implementation. (And that is communicated on this list). Then certainly the current chairs would bring that to me and the organisation, and we'd take the suggestion seriously internally.

As has been pointed out recently, regardless of various presentations at various meetings, posting to this list, still some of our community feel we need to do *even* more in terms of communication and engagement!

That is good feedback, and so I think you can understand why I'd be hesitant to implement any change or commit to doing so without a *lot* more community involvement first..

So in that spirit, let's discuss some of the technicalities of how that might work: The simplest implementation to allow IRR objects with AFRINIC IP resources, but a non-AFRINIC ASN would be to simply drop any checks on ASN at all, and only authenticate based on the IP prefixes.

In fact, my understanding is that is actually how the RIPE DB will work in future.

This of course means that any resource holder could then create IRR objects that state their resources are ok to originate from any ASN at all. So the question is then for ASN holders: How does a given ASN feel about route(6) objects existing with their ASN as origin that they have nothing to do with or any control over?

This is an honest question, and not being the operator of a large ASN I truly do not know the answer.

Personally I see little risk in this, but I'd like to hear from large networks, their opinion(s).

Regards,
Daniel





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.afrinic.net/pipermail/dbwg/attachments/20180517/a97bee05/attachment.sig>


More information about the DBWG mailing list