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.