Hi George, 

AS number can be transferred in the RIPE region. 

https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/asn

As 16-bit AS numbers are close to being depleted and to avoid speculations, it was suggested during the discussion to fix the fact that there are no transfer restrictions ( like a 24 month waiting period) in the proposal for at least the 16-bit AS numbers. 

So it is possible to transfer a 16-bit AS number, but for the second transfer, you need to wait 24 months. 

This proposal is introducing that specific part, which will bring it at the same level as IPv4. The other  scarce number resource ... 

The reason why 'scarce resource' was used in the proposal and NOT depleted, comes from the experience that policy makers have in LACNIC, where a transfer policy was writted about a depleted resource ... But as LACNIC is still handing out /22's similar as RIPE is to new LIR's ... Technically, it is not depleted .. As they still have it ...  So there the specific transfer policy couldn't be activated ... 

Regards,
Erik Bais 



Verstuurd vanaf mijn iPad

Op 3 sep. 2015 om 21:22 heeft George Michaelson <ggm@apnic.net> het volgende geschreven:

Right. I mussed up some details. The substance remains: if you are exposed to economics which depends on the use of communities for TE, and cannot influence external agents you do BGP with to support extended communities, then you may decide you need a 16bit ASN, and so they have inherent value to you, distinct from any other resources potentially in transfer. You aren't looking to acquire active IPv4, or IPv6, you are looking to acquire a 16 bit ASN as a thing in itself. 

-G

On 3 September 2015 at 15:49, Nick Hilliard <nick@inex.ie> wrote:
This has come up several times before.  There is support for asn32s in bgp
extended communities: you need the "Transitive Four-Octet AS-Specific
Extended Community" values from here:

http://www.iana.org/assignments/bgp-extended-communities

... and you need to hope that this is supported on your router software.
And everyone else's that you plan to talk to.

This can work in some situations where you have tight control over the
entire management plane of everywhere you plan to export these communities
to, but the internet at large is going to have a lot more difficulty with it.

As you point out, you can only support 16b:32b or 32b:16b style communities
with the current community mechanism, not 32b:32b communities.  The latter
will require implementation of draft-ietf-idr-wide-bgp-communities.

So if you have any requirement for 32b:32b communities, you're out of luck.

Nick

On 03/09/2015 18:59, George Michaelson wrote:
> Purely as a point of information, I think its worth remembering that 32 bit
> ASN cannot be used in currently specified BGP4 in communities, because its
> a 32 bit field defined as two 16 bit halves. I believe there is work afoot
> in IETF to fix this. I don't have concrete details.
>
> Therefore there *is* a quality in 16 bit ASN which may be divorced from its
> association with specific V4 or V6 resources and which makes it a desirable
> thing, in itself, for some people: If you are in the business of doing TE
> in BGP with communities, you can't do it with 32 bit ASN. You have to use
> other mechanisms.
>
> On that basis, Should you permit transfers of ASN, you might wish to permit
> transfers of ASN independently of any associated routable IP address space:
> people who already have space but need a 16 bit ASN may wish to acquire one.
>
> I'm not an asset holder in the RIPE region, and I am staff at another RIR,
> so I stress this is purely informational. I'm not trying to directly
> advocate for or against ASN transfers.
>
> -George
>
> On 3 September 2015 at 14:38, Nick Hilliard <nick@inex.ie
> <mailto:nick@inex.ie>> wrote:
>
>     On 03/09/2015 18:09, Sascha Luck [ml] wrote:
>     > Mind, if yelling loudly is how you get policy made in the RIPE
>     > community, rest assured I can yell VERY loudly. I can, in fact,
>     > even automate the yelling if need be.
>
>     please don't:  rfc7282 works much better.
>
>     Nick
>