This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
- Previous message (by thread): [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
- Next message (by thread): [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Joao Damas
Joao_Damas at isc.org
Fri Jan 23 16:01:58 CET 2004
On 23 Jan, 2004, at 14:20, Gert Doering wrote: > Hi, > > On Fri, Jan 23, 2004 at 02:15:33PM +0100, Joao Damas wrote: >>>> IPs around until you have a clean /24 for this sort of use. >>>> Last, Gert missed the point by reducing the discussion to only the >>>> /24 >>>> that would be used for the service IP, because with anycast you will >>>> always need a different IP address to be able to access each of the >>>> anycast instances, >>> >>> To the contrary. *This* can (and should) be done with PA space, >> >> It may or it may not be possible. When anycasting a service you want >> to >> keep the origin ASN the same, so you need your own routing >> infrastructure, separating your anycasted equipment from that of the >> rest of the net. This means that the management addresses will be >> inside that separate routing infrastructure and so your statement "can >> and should" can not and should not be made a pre-condition. > > This is certainly one way to setup things. > > But even so there is no reason not to use PA space for the management > side of things - announcing the PA block to your host network, if you > feel like having to announce the management IPs somewhere, but no > reason > to pollute the global table with local information. Remember that most people doing this will want to multihome the management part. Returning to the question at hand, it seems that anycast is here to stay. Critical infrastructure or not, this is a legitimate use of available technology to solve a particular problem which meets certain constraints coming from the current filtering BCPs that require the use of a certain minimum block of addresses (currently a /24, preferably from blocks where the minimum assignment is that size) for the service to be implemented independently of the number of active IP addresses in that block. Given these boundary conditions, policy needs to be adjusted to formally take into this legitimate use into account. Joao
- Previous message (by thread): [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
- Next message (by thread): [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]