RE: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or so mething else?
Hi all, I also followed the discussion, not stepping in here because of no background in TLD operations. Getting a bit frustrated as I see NO movement here. Unlike others, I do see dns being _critical_ to the infrastructure. No other protocol is that much subject of political discussions. As an operator being dependent on TLD operations I want to see a stable operations of the dns tree. Consequently I support giving the TLD operators the tools they need to make it a stable service. I have read an _expressed need_ of the tld community for anycast where I have not seen any constructive proposal against. Hence I have to ACCEPT that large TLDs need it. It brings us no step further towards a stable dns chain if we deny this. What is the impact onto my network if I accept to grant special resources to this need? I can see hardly any besides at most 200 prefixes polluting the DFZ. I can question whether the anycast allocations should be /32 or /48 or something else. It doesn't make a difference in terms of resources stressing my network provided I have a finite number of objects here. Operationally I believe /32 assignments are more stable, so I tend handing out /32 to TLD operators. Current policy does not allow to allocate routeable blocks to TLDs, so we have to change the policy. Before you start flaming I do not regard this opening the flooding gates, as I don't see the flood. TLD operators are being defined as critical infrastructure. It can be decided case by case to allow further infrastructure - by the RIPE members, but I haven't seen such case yet. Let it be xyz.com, have they ever claimed a need for themselves? regards Karsten
-----Original Message----- From: Mohsen Souissi [mailto:Mohsen.Souissi@nic.fr] Sent: Thursday, November 17, 2005 11:51 AM To: Florian Weimer Cc: address-policy-wg@ripe.net; ipv6-wg@ripe.net Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else?
Florian & all,
On 16 Nov, Florian Weimer wrote: [...] | It depends on the PI criteria. If slots in the global routing tables | are kept in short supply *and* you get at most one if you aren't an | ISP *and* you need to do IPv6 anycast, you might have a problem | because you need two globally visible prefixes (one for your | production network, one for anycast). | | But I think you are right that it makes sense to resolve the PI first, | either negatively or positively.
==> This is just amazing! I have been follwing this topic for more than two years and I have the feeling that we are making again and again the history! I remember that when the IPv6 "PI" issue was first raised in the IPv6/LIR wgs ("LIR" was the old name for "AP" at that time), the answer was "PI is out of scope of this wg". Then came the first draft proposel of Andreas in the AP wg asking for a /32 for ccTLDs wishing to deploy anycast. At that time, the wg said "let's not talk about "PI", which is still out of scope of this wg. Let's rather talk about specific needs of TLDs wishing to do anycast and see what we can do for them in termes of (micro-)allocation."
Now, I'm surprised that we are going back to the original issue and asking to first solve the PI problem...
If that's to be done and while we ar at it, we can see again how RIPE is the only RIR not considering TLD networks as "critical infrastructure" while an appropriate policy has been already implemented in all other existing RIRs for a long while (please revisit the comparative matrix of RIR policies at http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html and see how RIPE is lagging behind in this matter. Some of this mailing-list member would say: "that was our choice!"). Isn't it a European speciality to discuss over again and again issues without coming to any solution? Some people on RIPE mailing-lists are now used to coming after a consensus is almost reached and try to break everything just for the sake of building CLEAN solutions...
(cc)TLD need an allocation (whether it is a /32 or whatever "routable prefix") because they need to do anycast, full stop. To recall only a few of the arguments for deploying anycast for a TLD, I would say: Redundance & Resilience against DDoS attacks, better global time response, a greater flexibility in adding and removing name servers without notifying IANA!
Btw, I'd like to remind some of this mailing-list readers that the request of DENIC is not isolated since AFNIC asked even before Adndreas first draft for a constency between all RIRs in the way IPv6 allocation were made for "critical infrastructure". AFNIC has then strongly supported Andreas proposal from the beginning and hoped that the solution would come rapidly because AFNIC is still needing such a solution to start deploying anycast in IPv4 AND in IPv6 in a consistent way!
I still hope this debate will lead to a concrete solution within the coming 3 years!
Good luck :-)
Mohsen.
Unlike others, I do see dns being _critical_ to the infrastructure.
i think most folk think of dns as critical infrastructure
No other protocol is that much subject of political discussions.
and this says what about the dns, other than the need to taks a shower often?
As an operator being dependent on TLD operations I want to see a stable operations of the dns tree.
as am i. as do i.
Consequently I support giving the TLD operators the tools they need to make it a stable service.
yes. and how do you go from here to special address allocations? do we also need special computers? special electricity? special racks? randy
Consequently I support giving the TLD operators the tools they need to make it a stable service.
yes. and how do you go from here to special address allocations? do we also need special computers? special electricity? special racks?
I also agree that DNS is part of the Internet's critical infrastructure and that TLD's are more critical than the average end user domain. That is why I am opposed to DENIC's application to change policy and impose a bureaucratic process around building anycast deployments. There is no barrier preventing DENIC and AFNIC and others from deploying global anycast to serve the domains that they host from their TLD registries. Many, many companies in Europe are happily operating hosting facilities that host all sorts of applications using a wide range of protocols including the DNS protocol that is used in DENIC's hosting service. But DENIC's customers should be asking themselves why DENIC is wasting their time in this political process to change RIPE policy instead of building their anycast infrastructure. If they don't move quickly, then someone else will build that anycast infrastructure and both DENIC and AFNIC will be reduced to being customers instead of network operators. As long as they keep running the critical DNS infrastructure I am happy. Whether they outsource the anycast network entirely or participate in building their own, it doesn't matter much. --Michael Dillon
Michael, Michael.Dillon@btradianz.com wrote:
[...] If they don't move quickly, then someone else will build that anycast infrastructure and both DENIC and AFNIC will be reduced to being customers instead of network operators.
why would that be? Best regards, Carsten
On Fri, Nov 18, 2005 at 04:28:17PM +0100, Carsten Schiefner wrote:
Michael,
Michael.Dillon@btradianz.com wrote:
[...] If they don't move quickly, then someone else will build that anycast infrastructure and both DENIC and AFNIC will be reduced to being customers instead of network operators.
why would that be?
Best regards,
Carsten
because, apparently, customers aka service operators are inferior to network operators aka plumbers. a $DEITY forbid that an TLD operator ego be brused by not being considered in the same class as plumbers. tongue partly in cheek. perhaps there is the consideration that TLD ops are "special" in some unique way that preclueds them from fate-sharing with a plumber when the pipes break. e.g. they have not taken steps to distribute their service or content so that it is available over different carriers, on alternate power grids, in other countries. ... and perhaps ... using a variety of publishers ... instead of trying to run all that infrastructure in addition to operating the TLD. OR... why do tld operators have to have all the servers under infrastructure they run? when did this change? example: DEnic could have CNnic, BRnic, and CAnic run slave servers for them in their areas. Why is this a bad thing? --bill
bmanning writes:
because, apparently, customers aka service operators are inferior to network operators aka plumbers. a $DEITY forbid that an TLD operator ego be brused by not being considered in the same class as plumbers. [...]
tongue partly in cheek.
perhaps there is the consideration that TLD ops are "special" in some unique way that preclueds them from fate-sharing with a plumber when the pipes break. e.g. they have not taken steps to distribute their service or content so that it is available over different carriers, on alternate power grids, in other countries. ... and perhaps ... using a variety of publishers ... instead of trying to run all that infrastructure in addition to operating the TLD. OR... why do tld operators have to have all the servers under infrastructure they run? when did this change?
Well said, Bill.
example: DEnic could have CNnic, BRnic, and CAnic run slave servers for them in their areas. Why is this a bad thing?
As Kurt Jaeger aka pi said in a previous posting (although in a different context):
That's a national security issue for some countries.
So it's all a matter of control. In a similar vein, see http://www.imconf.net/imc-2005/papers/imc05efiles/ramasubramanian/ramasubram... "Perils of Transitive Trust in the Domain Name System", V. Ramasubramanian and E. Gün Sirer, IMC 2005 Personally I don't share the opinion that more centralized control leads to safer systems, but then nobody asks me. -- Simon. Speaking only for himself, but partly getting paid for helping to operate some TLD nameservers.
participants (6)
-
bmanning＠vacation.karoshi.com -
Carsten Schiefner -
Koepp, Karsten -
Michael.Dillon＠btradianz.com -
Randy Bush -
Simon Leinen