Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure
I don't claim that ARIN or ICANN or DENIC are not special, or are not important for the functioning of the Internet as a whole.
ICANN isn't special. They don't offer any infrastructure services. However, ARIN and RIPE maintain resgistry databases which are published in the form of a whois directory. This is part of the Internet infrastructure. DENIC hosts the .de top level domain and provides an authoritative DNS service. That is also part of the infrastructure. If an organization wants special treatment, first they have to show us that they operate a service that is a part of the Internet infrastructure. Then they have to show that this service is special enough to be called "critical". You are right that everyone forwards packets and that is not special enough. But what if someone operates a SIP network to carry VoIP calls for 112 (999) calls? Maybe that would make a part of their network into critical infrastructure. When making policy it is best to think ahead into the future a bit and make sure that they new policy will work for a few years, at least. --Michael Dillon
ICANN isn't special. They don't offer any infrastructure services. However, ARIN and RIPE maintain resgistry databases which are published in the form of a whois directory.
as does icann. face it. everybody thinks what they are doing is special and what others are doing is less special. this is called the grazing of the commons. and, in this case, the grass is the routing table. because denic is so <blank> as to be unable to find an old unused swamp C, does not imply that global allocation policy needs to be changed. randy
Hi, On Wed, Jan 07, 2004 at 11:40:16AM -0800, Randy Bush wrote:
because denic is so <blank> as to be unable to find an old unused swamp C, does not imply that global allocation policy needs to be changed.
I don't think this is the issue. They want to do Anycast, and want to do it in an official and documented way, so people can easily see what's going on, without resorting to "find a swamp C" network. That's why I'm in favour to have a policy that permits allocations for specific, well-defined Anycast services. That allocations would come from a well-known block, so people would know to not filter /24s from there (and so on). 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
|On Wed, Jan 07, 2004 at 11:40:16AM -0800, Randy Bush wrote: |> because denic is so <blank> as to be unable to find an old unused |> swamp C, does not imply that global allocation policy needs to be |> changed. | |I don't think this is the issue. They want to do Anycast, and |want to do it in an official and documented way, so people can |easily see what's going on, without resorting to "find a swamp |C" network. | |That's why I'm in favour to have a policy that permits |allocations for specific, well-defined Anycast services. That |allocations would come from a well-known block, so people |would know to not filter /24s from there (and so on). What should the cirteria to get "Anycast space" be ?
Hi, On Thu, Jan 08, 2004 at 11:08:01PM +0100, Hans Petter Holen wrote:
|That's why I'm in favour to have a policy that permits |allocations for specific, well-defined Anycast services. That |allocations would come from a well-known block, so people |would know to not filter /24s from there (and so on).
What should the cirteria to get "Anycast space" be ?
I had a proposal that nobody commented on :-) - it didn't mention "critical" anywhere, so maybe it wasn't sexy enough. I suggested: -------------------------- - Anycast deployment - multiple distributed servers bring benefits for the whole community - due to protocol limitations this cannot be done using other approaches (like "put up 100 servers at various ISP networks, using PA space from those ISPs") -------------------------- Now it's up to you people out there to come up with something better that a) solves the problem at hand (and not tries to solve everything else while at it - we're not going to save the world today, sorry) b) can be evaluated by a RIPE NCC hostmaster, so there must be clear and *easy* rules - it needs not be easy to get the space, but to say "you go - you don't" should be easy. Of course we could add something like - is accepted in a peer review (following this-and-that procedure) if that's what people want. 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
|That's why I'm in favour to have a policy that permits |allocations for specific, well-defined Anycast services. That |allocations would come from a well-known block, so people |would know to not filter /24s from there (and so on).
What should the cirteria to get "Anycast space" be ?
I had a proposal that nobody commented on :-) - it didn't mention "critical" anywhere, so maybe it wasn't sexy enough.
I suggested: -------------------------- - Anycast deployment - multiple distributed servers bring benefits for the whole community - due to protocol limitations this cannot be done using other approaches (like "put up 100 servers at various ISP networks, using PA space from those ISPs") --------------------------
I think this has the same problem as "critical infrastructure" in that you now need to define "benefits for the whole community". Second, with the definition above, if I am an ISP that decides to anycast my DNS-servers, do I get the "anycast space"? To be honest, I think you need to nail down what we are talking about. Maybe we will need a "Anycasted RIPE NCC Service Region TLD DNS-server space".
b) can be evaluated by a RIPE NCC hostmaster, so there must be clear and *easy* rules - it needs not be easy to get the space, but to say "you go - you don't" should be easy.
I think that anycasting is a problem (been there, done that, waiting for the t-shirt) when it comes to getting address space. I am sure you can find a swamp C-block, as Randy suggested - BUT I do think there is a point in registering a block correctly and getting it in a legitimate way. Now, if what we are trying to solve is anycasting for TLD DNS-servers in the RIPE NCC Service region, why don't we just write that? If it turns out there is a problem of anycasting Goolge-servers in the region that is considered to be painful enough that we all think they should get special treatment, let's write that up then. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBP/5ZdqarNKXTPFCVEQKcewCeMO17WmDzCOXaDARCnknpRLvxROcAoIS8 BYza7ha5BypTwxGGNfdbUDMQ =UZvo -----END PGP SIGNATURE-----
Hi, On Fri, Jan 09, 2004 at 08:34:11AM +0100, Kurt Erik Lindqvist wrote:
I think this has the same problem as "critical infrastructure" in that you now need to define "benefits for the whole community".
I agree.
Second, with the definition above, if I am an ISP that decides to anycast my DNS-servers, do I get the "anycast space"?
That's why there is a protocol limitation. If you're an ISP and already have 10 (!) distinct name servers in different PA blocks and different countries, and want to increase your resiliency further, this might be a viable approach. On the other hand, I've never seen anything delegated to more than 6 DNS servers - which can be done w/o anycast just fine. But I agree: we need to decide whether we *want* to permit that, and formulate the policy in accordance to that.
To be honest, I think you need to nail down what we are talking about. Maybe we will need a "Anycasted RIPE NCC Service Region TLD DNS-server space".
"we" might need, indeed :) [..]
Now, if what we are trying to solve is anycasting for TLD DNS-servers in the RIPE NCC Service region, why don't we just write that?
I would be fine with such a proposal. So it could look like this: Criteria: - Anycast - technical requirements (UDP record full) - ccTLD or gTLD operator Assignment: - /24 "status: ASSIGNED ANYCAST" out of well-known range - all anycast blocks (in RIPE land) come from the same range 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
Hi, On Fri, Jan 09, 2004 at 11:44:45AM +0100, Gert Doering wrote:
So it could look like this:
Criteria: - Anycast - technical requirements (UDP record full) - ccTLD or gTLD operator
Assignment: - /24 "status: ASSIGNED ANYCAST" out of well-known range - all anycast blocks (in RIPE land) come from the same range
People just pointed out to me that it's a "IPv4/IPv6 Policy", so the whole thing should be formulated accordingly. For IPv6, it could be done in analogy to the IPv6 root server policy. 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
Hay, for starters: i must admit, that i didn't read all mails of this thread, because most sub-discussions are - IMHO - way off topic. So apologies if i missed something important. Gert Doering wrote: [...]
Second, with the definition above, if I am an ISP that decides to anycast my DNS-servers, do I get the "anycast space"?
That's why there is a protocol limitation. If you're an ISP and already have 10 (!) distinct name servers in different PA blocks and different countries, and want to increase your resiliency further, this might be a viable approach.
On the other hand, I've never seen anything delegated to more than 6 DNS servers - which can be done w/o anycast just fine.
But I agree: we need to decide whether we *want* to permit that, and formulate the policy in accordance to that.
I don't really see why "we" want to restrict the usage of Address space for Anycast applications to some specific things like "i have too many nameservers, need to convert to anycast or my zone explodes!!" or something like that. My opinion is, that _if_ there's a distinct (IPv4)Anycast Policy, it should be rather open to new ideas. (Note: i don't really see the need for such a policy anyways, everyone was happy without it up to now. But since i do favour correct documentation in the whois database, i still like the idea somehow.) [...]
Now, if what we are trying to solve is anycasting for TLD DNS-servers in the RIPE NCC Service region, why don't we just write that?
I would be fine with such a proposal.
So it could look like this:
Criteria: - Anycast - technical requirements (UDP record full) - ccTLD or gTLD operator
Again, this probably prevents using IPv4 Address blocks for other anycast usage. I mean, what if I come up with a cool idea why i want to use anycast, probably i don't even request a new IPv4 block for that but use one of "my" blocks i already have and want to document it, e.g. with "ASSIGNED ANYCAST" - now i'm not allowed to do this? Will RIPE have to take away my net because i illegally use it for Anycast? What about if I use non-RIR assigned/allocated blocks (EARLY-REGISTRATION)? Or just what about if someone comes up with a new requirement for anycast on the list - do we have to discuss it another two months and again change the policy then? ==> I'd prefer more open "Criteria". We have no real IPv4 shortage, i don't see why we need to restrict this that much once again. RIPE hostmasters should be able to recognize a "good reason", even if there's no keyword in it they can check against a certain policy.
Assignment: - /24 "status: ASSIGNED ANYCAST" out of well-known range - all anycast blocks (in RIPE land) come from the same range
Since i like good documentation, i like this - i.e. i support this :-) Although - what about people using "old" Address space from a different range for Anycast? -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
Hi, On Fri, Jan 09, 2004 at 12:15:20PM +0100, Sascha Lenz wrote:
==> I'd prefer more open "Criteria". We have no real IPv4 shortage, i don't see why we need to restrict this that much once again. RIPE hostmasters should be able to recognize a "good reason", even if there's no keyword in it they can check against a certain policy.
It's not that easy. *If* they start "judging" requests, they also start asking lots of additional questions (to understand the background), and then people will again start complaining "the hostmasters are so annoying with all these questions! why do I need to send in an IPv6 network diagram, I just want addresses!"... This is why I'm aiming for a very specific "checklist". No doubts, no discussions. 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
Hay, Gert Doering wrote:
Hi,
On Fri, Jan 09, 2004 at 12:15:20PM +0100, Sascha Lenz wrote:
==> I'd prefer more open "Criteria". We have no real IPv4 shortage, i don't see why we need to restrict this that much once again. RIPE hostmasters should be able to recognize a "good reason", even if there's no keyword in it they can check against a certain policy.
It's not that easy. *If* they start "judging" requests, they also start asking lots of additional questions (to understand the background), and then people will again start complaining "the hostmasters are so annoying with all these questions! why do I need to send in an IPv6 network diagram, I just want addresses!"...
This is why I'm aiming for a very specific "checklist". No doubts, no discussions.
Maybe, but that might be overregulating things once again. I'd rather say, no nifty criteria at all then. Or probably similar to the Experiemental Allocation/Assignment policy, that people just have to show what they do with Anycast Services somewhere public, so everyone can see what kind of service it is or so. Or just "networks ASSIGNED ANYCAST have to be used as anycast addresses", i.e. they need to be announced from more than one location, similar to the ASN policy ("...you have to have at least two peers..."). The latter will prevent misuage in case people trying to get portable (unicast) addresses by abusing an open anycast policy. Still, why shouldn't I be able to announce my nets from multiple places and start anycast services for whatever reason i personally think i need to do this for? I can do this with my old nets, i also can just fake some PI-request for something different and use that than. A restrictive policy doesn't help much to get things documented here. The intention of the policy should be, that anycast services can be documented properly in first place - if I understood the initial request right. Since as we see out there in real life and some people noted during the discussion - you can _do_ anycast even without a new policy. It's just about "legalizing" it and getting the ability to document it. I don't see a reason, why this should be limited to certain "critical infrastructure" noone can agree upon what this should be in first place anyways. (Note: i'm talking only about IPv4 here for the moment since things in IPv6 are a) different and b) not even settled yet when it comes to IPv6 routing issues) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
Gert and all, Judging requests is not necessarily a bad thing, but doing so can quickly become a very bad thing unless there is a set of procedures and/or policies that are enforceable and will dictate the limitations and specifics of such judgments. Gert Doering wrote:
Hi,
On Fri, Jan 09, 2004 at 12:15:20PM +0100, Sascha Lenz wrote:
==> I'd prefer more open "Criteria". We have no real IPv4 shortage, i don't see why we need to restrict this that much once again. RIPE hostmasters should be able to recognize a "good reason", even if there's no keyword in it they can check against a certain policy.
It's not that easy. *If* they start "judging" requests, they also start asking lots of additional questions (to understand the background), and then people will again start complaining "the hostmasters are so annoying with all these questions! why do I need to send in an IPv6 network diagram, I just want addresses!"...
This is why I'm aiming for a very specific "checklist". No doubts, no discussions.
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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Second, with the definition above, if I am an ISP that decides to anycast my DNS-servers, do I get the "anycast space"?
That's why there is a protocol limitation. If you're an ISP and already have 10 (!) distinct name servers in different PA blocks and different countries, and want to increase your resiliency further, this might be a viable approach.
ok, agreed.
Now, if what we are trying to solve is anycasting for TLD DNS-servers in the RIPE NCC Service region, why don't we just write that?
I would be fine with such a proposal.
So it could look like this:
Criteria: - Anycast - technical requirements (UDP record full) - ccTLD or gTLD operator
Assignment: - /24 "status: ASSIGNED ANYCAST" out of well-known range - all anycast blocks (in RIPE land) come from the same range
fine with me. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQAFdoKarNKXTPFCVEQJ/7wCcD6QXvKQE7y91vn7c1Gb05LzzxEIAnjDb FdIBVIIPHw4ntZjCmaMgL5xk =I+4g -----END PGP SIGNATURE-----
From my observation on this discussion there seem to be no other parties beside TLD operators that are currently so much interested in setting up anycast services. At least, nobody said so on this list.
Now, if what we are trying to solve is anycasting for TLD DNS-servers in the RIPE NCC Service region, why don't we just write that?
Asuming that Curtis is hiding his sympathy to allow TLD operators to get IPv4/v6 address space for the operation of anycast services I second that idea. Lets add anycast TLD nameservice to the list of accepted exceptions.
If it turns out there is a problem of anycasting Goolge-servers in the region that is considered to be painful enough that we all think they should get special treatment, let's write that up then.
It seems to be much easier and practical to add allowances to a list of exceptions than finding an accepted term and criteria that defines an open future path for applications that automatically qualify for this rule. Have a nice weekend Andreas -- DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt
On Jan 10, Andreas Bäß/Denic <baess@denic.de> wrote:
From my observation on this discussion there seem to be no other parties beside TLD operators that are currently so much interested in setting up anycast services. At least, nobody said so on this list. Some DNSBL operators are definitely interested.
-- ciao, | Marco | [4018 ripaTaONbBKuo]
From my observation on this discussion there seem to be no other parties beside TLD operators that are currently so much interested in setting up anycast services. At least, nobody said so on this list.
i have deployed non-dns anycast services a number of times in the last decade. next. randy
Hi, On Sat, Jan 10, 2004 at 07:53:33AM -0800, Randy Bush wrote:
From my observation on this discussion there seem to be no other parties beside TLD operators that are currently so much interested in setting up anycast services. At least, nobody said so on this list.
i have deployed non-dns anycast services a number of times in the last decade. next.
In case you didn't notice, the internet grew somewhat over the last decade. Add to that the addition of v6 glue to some xTLD name server sets and you get a conflict between the number of DNS servers that you want to deploy, and the number of glue records that fit into the packets. 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
Gert and all, Gert Doering wrote:
Hi,
On Sat, Jan 10, 2004 at 07:53:33AM -0800, Randy Bush wrote:
From my observation on this discussion there seem to be no other parties beside TLD operators that are currently so much interested in setting up anycast services. At least, nobody said so on this list.
i have deployed non-dns anycast services a number of times in the last decade. next.
In case you didn't notice, the internet grew somewhat over the last decade.
Many have commented and question in the past if Randy has taken such notice you are refrencing.
Add to that the addition of v6 glue to some xTLD name server sets and you get a conflict between the number of DNS servers that you want to deploy, and the number of glue records that fit into the packets.
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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Randy, On 2004-01-10, at 16.53, Randy Bush wrote:
From my observation on this discussion there seem to be no other parties beside TLD operators that are currently so much interested in setting up anycast services. At least, nobody said so on this list.
i have deployed non-dns anycast services a number of times in the last decade. next.
the problem is that you then apparently had access to routable space. Which not everyone has today. It's been done for other services, and it has been done for DNS for a long time. And yes, we should find a solution for other people wanting to do anycast as well. But in most cases, I suspect that they already have access to other sources of address space. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQAFeJqarNKXTPFCVEQIxvgCeJv/Va6Z4pT2yTRoZ+GiFl/jdDOoAoItg RJkPms5IeZ8f1RjExHP4XyIR =as3W -----END PGP SIGNATURE-----
|I suggested: |-------------------------- | - Anycast deployment OK - I want to do anycast for my server - so I qualify. | - multiple distributed servers bring benefits for the whole community so - I need more than one server to do this, that is slikgltyl limiting ths from beeing available to everybody. How is "bring benefits for the whole community" different from "critical infrastructure" ? I agree the first is a slightly better definition, but how do we measure this criteria ? Or is it a judgemental criteria to be evaluated by the RIPE NCC ? | - due to protocol limitations this cannot be done using other approaches so you will have an argument on wether the mecahnisms in the DNS protocol are good enouugh to create redundancy. | (like "put up 100 servers at various ISP networks, using PA |space from | those ISPs") Is that to be interpreted as a fixed number ? That would make it more difficult to apply this in a smaller country like Norway (where do I find ISP % 95...) that in for instance germany ? -hph
Hi, On Mon, Jan 12, 2004 at 09:10:24AM +0100, Hans Petter Holen wrote:
| (like "put up 100 servers at various ISP networks, using PA |space from those ISPs")
Is that to be interpreted as a fixed number ? That would make it more difficult to apply this in a smaller country like Norway (where do I find ISP % 95...) that in for instance germany ?
You're not supposed to have all servers in the same country...! (But anyway: I agree that it's difficult to specify the criteria. So I'd appreciate if someone else would actually come up with specific suggestions, instead of only discussing why the stuff we already have isn't going to work). 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
| (like "put up 100 servers at various ISP networks, using PA |space from those ISPs")
Is that to be interpreted as a fixed number ? That would make it more difficult to apply this in a smaller country
On Mon, Jan 12, 2004 at 09:10:24AM +0100, Hans Petter Holen wrote: like
Norway (where do I find ISP % 95...) that in for instance germany ?
You're not supposed to have all servers in the same country...!
(But anyway: I agree that it's difficult to specify the criteria.
From my point of view it does not make sense to add any additional
As far as I have followed the discussion there seems to be a favour to grant TLD operators permission to get resources to operate an anycast DNS. threshold like number of instances or worldwide distribution as it is the decision of the registry where it starts the rollout and how fast and how many servers he would like to have totally to fullfill the registries SLAs for their query load.
So I'd appreciate if someone else would actually come up with specific suggestions, instead of only discussing why the stuff we already have isn't going to work).
So my suggestion is to allow the allocation of a single /24 IPv4 and a /32 IPv6 address block to TLD operators who want to operate an anycast DNS service for their TLD. If they don't provide this service within a year or stop the service after starting it, they have to return the allocations. As this allocation will be multihomed be nature with it's own routing policy they also qualify for a distinct AS number to define this routing policy. When the service terminates the reouting policy does no longer exist and naturally they have to return this resource as well. Andreas -- DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt
Hi, uh, sorry, this mail was *NOT* supposed to go to the APWG mailing list. I bounced it (assuming a CC: was lost) but the whole thing "escaped" prematurely. Please *ignore* this e-mail. gert, who will have to buy Andreas a beer in Amsterdam :-o On Tue, Jan 13, 2004 at 08:55:44PM +0100, Andreas Bäß/Denic wrote:
From: Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?= <baess@denic.de> To: Gert Doering <gert@space.net> Subject: Antwort: Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: <OF6AE716E2.AF0C15C0-ONC1256E1A.006B315B-C1256E1A.006D7A4A@denic.de> Resent-From: gert@Space.Net Resent-Date: Tue, 13 Jan 2004 22:11:51 +0100 Resent-To: address-policy-wg@ripe.net
On Mon, Jan 12, 2004 at 09:10:24AM +0100, Hans Petter Holen wrote:
| (like "put up 100 servers at various ISP networks, using PA=20 |space from those ISPs") =20 Is that to be interpreted as a fixed number ? That would make it more difficult to apply this in a smaller country=20 [..]
-- 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
|On Wed, Jan 07, 2004 at 11:40:16AM -0800, Randy Bush wrote: |> because denic is so <blank> as to be unable to find an old unused |> swamp C, does not imply that global allocation policy needs to be |> changed. | |I don't think this is the issue. They want to do Anycast, and |want to do it in an official and documented way, so people can |easily see what's going on, without resorting to "find a swamp |C" network. | |That's why I'm in favour to have a policy that permits |allocations for specific, well-defined Anycast services. That |allocations would come from a well-known block, so people |would know to not filter /24s from there (and so on).
What should the cirteria to get "Anycast space" be ?
well, if they are in a wellknown block (and w/o authenticated routing) then its pretty simple to hijack said prefix for local use. And perhaps more to the point, if everything is in said wkp, then blackholing the entire prefix makes installing local policy -dirt simple- ... as a blackhat, I would prefer to have every "critical infrastructure" component densely packed into a single prefix. YMMV of course. --bill
On Wed, 7 Jan 2004, Randy Bush wrote:
because denic is so <blank> as to be unable to find an old unused swamp C, does not imply that global allocation policy needs to be changed.
mmm.. I wouldn't mind getting the anycast address for my co-lo box. easy provider - independence! :) but seriously .. IANA and the IETF have allocated these C blocks to some services (e.g. 192.88.99.0/24). They could do the same again if the _service_ would be *global* and well-defined enough. "Every ccTLD" is probably not. Which is why maybe just getting a /24 block somewhere if you want to do anycast for service FOO would be just about enough. You know, the administrative hoops you have to jump through to get a "golden" /24 shouldn't be fewer than those you have to jump through to get a regular /24.. else we'll be facing an uprise of "anycast" applications.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Wed, Jan 07, 2004 at 11:40:16AM -0800, Randy Bush <randy@psg.com> wrote a message of 15 lines which said:
because denic is so <blank> as to be unable to find an old unused swamp C,
They should have an old unused swamp C prefix? I thought they were supposed to have been sent back a long time ago :-)
On Wed, 7 Jan 2004 Michael.Dillon@radianz.com wrote:
I don't claim that ARIN or ICANN or DENIC are not special, or are not important for the functioning of the Internet as a whole.
ICANN isn't special. They don't offer any infrastructure services.
However, ARIN and RIPE maintain resgistry databases which are published in the form of a whois directory. This is part of the Internet infrastructure. DENIC hosts the .de top level domain and provides an authoritative DNS service. That is also part of the infrastructure.
Agreed. Forgot to mention APNIC and LACNIC. RIR's databases are crucial for us "Internet wrench-guys"...
If an organization wants special treatment, first they have to show us that they operate a service that is a part of the Internet infrastructure. Then they have to show that this service is special enough to be called "critical".
Globally critical or Regionally critical? I think the scope of the "critical" part is an important issue...
You are right that everyone forwards packets and that is not special enough. But what if someone operates a SIP network to carry VoIP calls for 112 (999) calls? Maybe that would make a part of their network into critical infrastructure. When making policy it is best to think ahead into the future a bit and make sure that they new policy will work for a few years, at least.
--Michael Dillon
Regards, ./Carlos -------------- IPv6 -> http://www.ip6.fccn.pt Wide Area Network Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (131586/456), naming (millions) and... people!"
participants (13)
-
Andreas Bäß/Denic -
bill -
Carlos Friacas -
Gert Doering -
Hans Petter Holen -
Jeff Williams -
Kurt Erik Lindqvist -
Marco d'Itri -
Michael.Dillon＠radianz.com -
Pekka Savola -
Randy Bush -
Sascha Lenz -
Stephane Bortzmeyer