Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
Coming in late but let's see if I understand this: The problem has to do with the fact that there are requests for a /24 that plan to host only one address (maybe 2, one for a server and one for a router) and that if the requester tells the truth, it does not qualify. Note that from a routing point of view, if you look at an anycasted network from the outside, it is indistinguishable from a multi-homed network so in itself the routing is not the problem, it is the fact that you are asking for a prefix to host only one active IP address but you need it to be routable and today that means a /24. This goal could very well be achieved by keeping the addresses of the servers you are already using and migrating all other active IP's out of the /24 that contains the address you want to "anycast". After all, none of the root servers that are anycasting today have renumbered (one that is not anycasting today will renumber soon because they can't apply what I just described, which was unfortunate). The problem is then with obtaining a /24 for each anycasted site, not for the service IP but for the "management" IP, something that allows you to uniquely identify the different incarnations of the the same IP, geographically distributed and only accessible through networks other than your own (for the operator of the anycast service, anycast is indeed different from multi-homing). Depending on the requirements for independence (in its various aspects), you may use an IP inside someone else's PA block for that, if you buy hosting from them, for instance, or you may need to ask for a separate /24. It is this last part that may pose a problem within current RIPE policies. Note that the IPv6 root server policy has nothing to do with anycast but rather with routability of a prefix containing only one active IPv6 address and that there is no RIPE IPv4 root server anycast policy in spite of there being anycasted instances of root servers hosted by European organisations. Joao On 16 Jan, 2004, at 15:37, Gert Doering wrote:
Hi,
On Fri, Jan 16, 2004 at 11:18:29AM +0100, Andreas Bäß/Denic wrote:
RIPE should be able to allocate a single /24 IPv4 and a /32 IPv6 address block for the operation of anycast DNS servers if: - the operator serves a TLD zone - the number of (planned?) nameservers would lead to a truncation of the authority/additional section in a DNS delegation response containing the NS RRset in [draft-ietf-dnsop-respsize-00.txt 2.9]
I would support that.
Yes, I know that it's a very special case, and it could be done by a "swamp" (or a random PI) /24 just fine. But I'm very much in favour of having official ways to do things that need doing - and I'm convinced that this is a good thing to do.
As for the impact on the routing table: this new policy would not make more or less impact than just announcing a random /24, but it would allow for better documentation what it's all about.
As far as "other" anycast deployments go: there have been some voices on the list that "we must not do a policy that's too narrow minded" - yes, that's true, but we don't want a "permit all" policy either (well, we *could* do that, but there does not seem to be consensus to do that).
*If* other people show up, and say "we want to do this-and-that, and have a specific need that cannot be done in the current framework", we can always adapt the then-existent policies.
(This is speaking as myself, and as APWG co-chair).
Andreas: I would appreciate if you could give a short presentation (5 mins?) in Amsterdam, repeating the reasoning behind this proposal, to stir some discussion.
Then we can have a final call for consensus some time after the meeting.
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57882 (57753)
SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joao, On 2004-01-20, at 16.50, Joao Damas wrote:
This goal could very well be achieved by keeping the addresses of the servers you are already using and migrating all other active IP's out of the /24 that contains the address you want to "anycast". After all, none of the root servers that are anycasting today have renumbered (one that is not anycasting today will renumber soon because they can't apply what I just described, which was unfortunate).
This was actually spelled out as a problem with NEW services (TLDs) moving to anycast. That is people who do not have their own addresses at all at this point. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQA18j6arNKXTPFCVEQKIgQCfdI0l1TMNy2mmCWtP/umLcpr23K0An2FL J7KQTOTKYhprMKX9QV7sutrO =1b17 -----END PGP SIGNATURE-----
On 20 Jan, 2004, at 20:07, Kurt Erik Lindqvist wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Joao,
On 2004-01-20, at 16.50, Joao Damas wrote:
This goal could very well be achieved by keeping the addresses of the servers you are already using and migrating all other active IP's out of the /24 that contains the address you want to "anycast". After all, none of the root servers that are anycasting today have renumbered (one that is not anycasting today will renumber soon because they can't apply what I just described, which was unfortunate).
This was actually spelled out as a problem with NEW services (TLDs) moving to anycast. That is people who do not have their own addresses at all at this point.
No, it was spelt as a new deployment strategy for a running service. In particular the proponent does have address space already though this should not have impact on the discussion. In any case, the point is that the problem is a policy one: obtaining a /24 in which there will be only a few (<5) active IPs. It is not a routing issue. In addition, in some cases, this can be worked around by moving service 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, and as for the service /24, some people may be able to work around this using address space they already have and some will not, so any policy discussion needs to take into account both requirements as they are not independent. Joao
Hi, On Wed, Jan 21, 2004 at 01:48:16PM +0100, Joao Damas wrote:
In addition, in some cases, this can be worked around by moving service 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, as for any other machine round the world that needs remote access. There is nothing special about the administrative IP, so there is *no* need to do *anything* special in the policy here.
and as for the service /24, some people may be able to work around this using address space they already have and some will not, so any policy discussion needs to take into account both requirements as they are not independent.
Strong disagreement. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On 21 Jan, 2004, at 14:03, Gert Doering wrote:
Hi,
On Wed, Jan 21, 2004 at 01:48:16PM +0100, Joao Damas wrote:
In addition, in some cases, this can be worked around by moving service 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.
as for any other machine round the world that needs remote access. There is nothing special about the administrative IP, so there is *no* need to do *anything* special in the policy here.
and as for the service /24, some people may be able to work around this using address space they already have and some will not, so any policy discussion needs to take into account both requirements as they are not independent.
Strong disagreement.
See above Joao
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.
Strong disagreement. See above
Indeed :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
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
Gert and all, 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.
I think this depends on whether or not the local information is of a nature to critical infrastructure, which of course also requires a good definition as to what "critical infrastructure" is and is not.
Strong disagreement. See above
Indeed :-)
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882)
SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801
participants (5)
-
Gert Doering -
Jeff Williams -
Joao Damas -
Joao Damas -
Kurt Erik Lindqvist