- address-policy-wg - mailman.ripe.net

RIPE NCC Reappoints Wilfried Woeber as NRO NC Member
by Axel Pawlik 28 Nov '05

28 Nov '05

Dear Colleagues, The RIPE NCC Executive Board has reappointed Wilfried Woeber to the Number Resource Organization (NRO) Number Council as a representative of the RIPE NCC region. Under the terms of the Memorandum of Understanding (MoU) signed between ICANN and the Regional Internet Registries (RIRs) in October 2004, the NRO Number Council (NRO NC) now performs the role of the Address Supporting Organization Address Council (ASO AC). The term of Mr. Woeber's appointment is from 1 January 2006 to 31 December 2008. Mr. Woeber has previously served on the NRO NC as an interim member during 2005 and on the Address Council under the previous ASO structure, from January 2003 to December 2004. More information about the NRO Number Council is available at: http://www.nro.net/about/number-council.html Regards, Axel Pawlik Managing Director RIPE NCC

1 0

RE: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or so mething else?
by Koepp, Karsten 23 Nov '05

23 Nov '05

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(a)ripe.net; ipv6-wg(a)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. > >

6 7

IPv6 micro allocation or something else?
by Mohacsi Janos 22 Nov '05

22 Nov '05

Dear All, I have a question regarding the IPv6 address assignment to cc level DNS server. If you don't have answer to this question please forward it to an appropriate working group - sorry for cross-posting this mail to two wg. We have here in Hungary a dilemma: - Traditionally, the IPv4 address of the primary cc level DNS server in of belonged to NIIF/HUNGARNET. - The DNS registration service a while ago was delegated to Council of Hungarian Internet Providers (ISZT) who is also operating the biggest Internet Exchange of Hungary (BIX). All big ISPs in Hungary (including NIIF/HUNGARNET) has right to do the registration via a special interface. - The IPv4 address of the primary cc level DNS server announced by NIIF/HUNGARNET. But ISZT is reorganizing its infrastructure to allocate address from a new PI type IPv4 address space to DNS servers. - The primary hu DNS server is connected to BIX - to be well connected. What IPv6 address space should we allocate to hu primary DNS server? 1. Assign IPv6 address from /32 address space of NIIF/HUNGARNET? - not very optimal since the only transit to hu primary will be NIIF/HUNGARNET - not ISP neutral - easy, no problem from point of view of NIIF/HUNGARNET 2. Assign IPv6 address space from /48 allocated to BIX (based on ripe-256 and ripe-310)? - According to the RIPE documents: "Networks assigned under this policy may not be globally routable" - which problematical since primary DNS servers should be globally reachable. 3. Allocate multiple /48 from IPv6 providers in HUNGARY to primary hu DNS server? - This can be problematical since the answers to DNS queries might be quite big. 4. Allocate /48 to primary hu DNS server that is globally routable? Are there similar to /48 from 2001:0500::/30 in RIPE region? - I think this is the cleanest solution. Can we discuss this issue on the working group or mailing lists? I saw a proposal: http://www.ripe.net/ripe/policies/proposals/2005-2.html In my opinion this can solve the problem.... Best Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98

19 59

Re: [address-policy-wg] 200 customer requirements for IPv6
by Thomas Narten 18 Nov '05

18 Nov '05

> To all the nay-sayers and ignorants in the die-hard IPv6 camp I can only > recommend that they put yourself into the shoes of a large coporation > with 10,000 employees for a day. How many 10K employee organizations exist in the world today (or in ten years)? How many routing prefixes would be required in the DFZ to support this? Can the routing infrastructure handle that? If there were consensus that the answer to the above questions was "yes, it's manageable", I'm sure folk would support a modified policy to that effect in a heartbeat. But in the absence of some real data showing the implication of loosening the policy to allow the above, many (myself include) will be very concerned about the consequences of doing this. Thomas

2 1

Re: [ipv6-wg] Re: 200 customer requirements for IPv6
by Thomas Narten 18 Nov '05

18 Nov '05

Daniel Roesen <dr(a)cluenet.de> writes: > The folks all having their own /32 already allocated to them and > trying to limit independent address space to "service providers" (or > those who manage to pretend being it, which seems to be easy) are > still arguing for "not for them!" paradigm - easy position with > having their own dishes already done. With all due respect, these sorts of comments are not helpful. They imply bad motivations on some, that IMO, are simply false. There are (IMO) valid reasons for not giving out /32s to everyone. The original (and still compelling, IMO) rational behind the current policy is to ensure good aggregation for the long term, in order to keep the number of distinct prefixes in the DFZ manageable. Hence, the current policy is oriented not towards _all_ ISPs, but those who will (hopefully) have _many_ customers that they assign addresses too. That is, they aggregate addresses for _many_ customers. That is where the "plan for 200 customers" wording originally came from. The presumption is that an ISP/LIR that realistically expects to have 200 customers will be aggregating _many_ customer addresses. If an ISP will have (say) only 100 customers long term, its not at all clear that they will be aggregating significant amounts of address space. Note, I'm not defending the the "200 customer" rule per se; I understand that it is viewed as problematic. But I think the motivation that led to it is still valid, and when folk say "get rid of this requirement," I object to "forgetting" about the original concern when coming up with a replacement policy. > Until we have a clear full replacement (that means a solution which does > NOT ignore real requirements like shim6 does) there should be a very > simple PI policy which issues a /48 or whatever to end sites at a > nominal small fee, paid directly to the RIR. An initial setup fee and a > yearly renewal fee, paid by credit card or something equally simple. > No payment => assignment withdrawn. The initial fee covering the cost of > evaluation of the request, doing the assignment and setting up the > billing account and DNS reverse. The yearly fee covering the maintenance > of the entries in the database and DNS rev NS RRset and the yearly > recurring fee invoicing/billing. Done. Note that ARIN has been and continues to have discussions about how to give out PI space to end sites, but in a way that doesn't explode the routing tables going forward. I think there is (very strong) support for the idea of giving out more PI space, the difficulty has been in coming up with details that people are comfortable won't explode the routing tables going forward. I.e., that in five years we look back and say "oops, we should not have done that, now what do we do" > Setting aside my disbelieve in the FUD about the scalability problem of > real BGP multihoming (noone yet has shown that the relative amount of > multihomers does or will explode), Um, do the math. How many end sites do you think will want to multihome ten years from now? Can you honestly/realistically say it won't be a million? Can the routing infrastructure handle that? (Enough people say "not sure" that IMO it would be foolish to just assume we can do this). Thomas

3 2

Fwd: 2005-01 One Week to End of Discussion Pe riod: HD Ratio for IPv4
by Erics 18 Nov '05

18 Nov '05

Hi all, i confirm that Deutsche Telekom still supports the FT proposal to establish the IPv4-HD-Ratio, because this is a good instrument for LIRs to manage the demand of address space. Especially in view of their internal topologies. kind regards Eric Schmidt - for LIR de.telekom

1 0

Re: [address-policy-wg] 200 customer requirements for IPv6
by Thomas Narten 18 Nov '05

18 Nov '05

> On Thu, 17 Nov 2005, Tim Streater wrote: > > The other network is one we are *currently* managing, EUMEDCONNECT. > > It is for the Middle-eastern and North African NRENs. The intention > > here is that we expect these NRENs to set up their own entity to > > manage it, and go their own way, in which case we gift them the > > infrastructure, which in this case has to include the address space. > > We can do that for v4 as I got PI space for that. Its v6 that is the > > problem. > Did you actually *try* getting a separate /32 for this? > RIPE NCC is known to be very reasonable towards transit networks, and > I could bet good money you could get an allocation without a hitch. I don't think the Right Answer is always to say "did you try and did you get rejected"? I believe the current IPv6 policies are aimed at LIRs that delegate address space to other users/isps/customers (i.e., that is the group the are the main focus). It is not immediately clear to me what the policies are (or should be) for an ISP doing transit. Clearly, the don't need a full /32, since they aren't really assigning (directly, or via delegation) lots of addresses. But shouldn't they be able to get space? Seems like that is a valid policy discussion to have. Thomas

2 1

FW: [address-policy-wg] Fwd: 2005-01 One Week to End of Discussion Period: HD Ratio for IPv4
by quin.collier＠bt.com 17 Nov '05

17 Nov '05

I can confirm that BT supports the proposal to move to an HD ratio approach for IPv4. Regards, Quin Collier -----Original Message----- From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Hans Petter Holen Sent: 07 November 2005 18:22 To: address-policy-wg(a)ripe.net Subject: [address-policy-wg] Fwd: 2005-01 One Week to End of Discussion Period: HD Ratio for IPv4 Dear WG, At the meeting in Amsterdam I requested participation from the signatories to the ETNO letter. As chair of the wg I would like to understand from the participants of this WG, representing the signatories to the ETNO position - why you have chosen not to participate in the discussion in the Address Policy WG but rather develop this position in another organization. I will not move this proposal to last call before this clarified to the Address Policy working group. Best Regards, Hans Petter Holen Address Policy WG.

1 0

HD Ratio for IPv4
by Kelaidi Christina 11 Nov '05

11 Nov '05

My company believes that the proposal for the calculation of the HD ratio to measure IPv4 usage is a an improvement to the existing one and we would like to support once again this new policy proposal. Christina Kelaidi GD Regulatory Affairs OTE S.A. 99 Kifissias Av. 15124 Maroussi Greece tel: +30 2106117205 e-mail: kelaidi(a)ote.gr

1 0

RE: address-policy-wg digest, Vol 1 #315 - 2 msgs - Checking details of assignments
by Fred Langford 08 Nov '05

08 Nov '05

Hi, More of a general question but will RIPE be authenticating the details (address, abuse etc) of the IP assignments to ensure the integrity of the database? Regards Fred Langford Fred Langford Internet Research Analyst Internet Watch Foundation t +44 (0)1223 237700 www.iwf.org.uk -----Original Message----- From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of address-policy-wg-request(a)ripe.net Sent: 08 November 2005 11:00 To: address-policy-wg(a)ripe.net Subject: address-policy-wg digest, Vol 1 #315 - 2 msgs Send address-policy-wg mailing list submissions to address-policy-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit http://www.ripe.net/mailman/listinfo/address-policy-wg or, via email, send a message with subject or body 'help' to address-policy-wg-request(a)ripe.net You can reach the person managing the list at address-policy-wg-admin(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of address-policy-wg digest..." Today's Topics: 1. Fwd: 2005-01 One Week to End of Discussion Period: HD Ratio for IPv4 (Hans Petter Holen) 2. Re: [ipv6-wg] IPv6 micro allocation or something else? (Pekka Savola) --__--__-- Message: 1 Date: Mon, 07 Nov 2005 19:21:31 +0100 From: Hans Petter Holen <hph(a)oslo.net> To: address-policy-wg(a)ripe.net Subject: [address-policy-wg] Fwd: 2005-01 One Week to End of Discussion Period: HD Ratio for IPv4 This is a multi-part message in MIME format. --------------050809070908030505050308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear WG, At the meeting in Amsterdam I requested participation from the signatories to the ETNO letter. As chair of the wg I would like to understand from the participants of this WG, representing the signatories to the ETNO position - why you have chosen not to participate in the discussion in the Address Policy WG but rather develop this position in another organization. I will not move this proposal to last call before this clarified to the Address Policy working group. Best Regards, Hans Petter Holen Address Policy WG. --------------050809070908030505050308 Content-Type: message/rfc822; name*0="[address-policy-wg] ETNO comments on AD ratio for IPv4 addresses"; name*1=" allocation.eml" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename*0="[address-policy-wg] ETNO comments on AD ratio for IPv4 addre"; filename*1="sses allocation.eml" Return-Path: <address-policy-wg-admin(a)ripe.net> Received: from smtp220.tiscali.dk (smtp220.tiscali.dk [62.79.79.114]) by i.dont.no (8.12.10/8.12.10) with ESMTP id i8GD3O9Z028063 for <hph(a)dont.no>; Thu, 16 Sep 2004 12:03:24 -0100 Received: from cpmail.dk.tiscali.com (mail.tiscali.dk [212.54.64.159]) by smtp220.tiscali.dk (8.12.11/8.12.11) with ESMTP id i8GD3OPS091657 for <hph(a)dont.no>; Thu, 16 Sep 2004 15:03:24 +0200 (CEST) (envelope-from address-policy-wg-admin(a)ripe.net) Delivered-To: hpholen(a)tiscali.no Received: from postboy.ripe.net (193.0.0.201) by cpmail.dk.tiscali.com (6.7.018) id 412F265D0014F272 for hpholen(a)tiscali.no; Thu, 16 Sep 2004 15:03:22 +0200 Received: from postboy.ripe.net (localhost [127.0.0.1]) by postboy.ripe.net (Postfix) with ESMTP id 12CB179C2D; Thu, 16 Sep 2004 14:59:02 +0200 (CEST) Delivered-To: address-policy-wg(a)lists.ripe.net Received: by postboy.ripe.net (Postfix, from userid 8) id 9C0C079D57; Thu, 16 Sep 2004 12:01:21 +0200 (CEST) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by postboy.ripe.net (Postfix) with ESMTP id 8FF5479D56 for <address-policy-wg(a)postboy.ripe.net>; Thu, 16 Sep 2004 12:01:21 +0200 (CEST) Received: by postman.ripe.net (Postfix, from userid 8) id 8A7D34FC46; Thu, 16 Sep 2004 12:01:21 +0200 (CEST) Received: from etno.be (138.206-78-194.adsl-fix.skynet.be [194.78.206.138]) by postman.ripe.net (Postfix) with ESMTP id 8FE554E26F for <address-policy-wg(a)ripe.net>; Thu, 16 Sep 2004 12:01:20 +0200 (CEST) Received: from etnodebecker ([192.168.1.1]) by etno.be (etno.be [192.168.1.253]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 44-md50000000012.tmp for <address-policy-wg(a)ripe.net>; Thu, 16 Sep 2004 12:01:04 +0200 Reply-To: <debecker(a)etno.be> From: "Debecker J.L." <debecker(a)etno.be> To: <address-policy-wg(a)ripe.net> Cc: <gerd.wiedenhaupt(a)t-systems.com>, <alain.bidron(a)francetelecom.com>, "Michael Bartholomew" <bartholomew(a)etno.be> Organization: ETNO Message-ID: <001101c49bd4$126111e0$0101a8c0(a)etno.be> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Processed: etno.be, Thu, 16 Sep 2004 12:01:04 +0200 (not processed: message from valid local sender) X-Lookup-Warning: HELO/EHLO lookup on etnodebecker does not match 192.168.1.1 X-MDRemoteIP: 192.168.1.1 X-Return-Path: debecker(a)etno.be X-MDaemon-Deliver-To: address-policy-wg(a)ripe.net X-RIPE-Spam-Level: ** X-RIPE-Spam-Status: U 0.499986 / 1.8 / 0.0 / disabled X-RIPE-Signature: 80201789b55f74e2c7bf4670a81825e0 Subject: [address-policy-wg] ETNO comments on AD ratio for IPv4 addresses allocation Sender: address-policy-wg-admin(a)ripe.net Errors-To: address-policy-wg-admin(a)ripe.net X-BeenThere: address-policy-wg(a)ripe.net X-Mailman-Version: 2.0.13 Precedence: bulk List-Id: Developing policies relating to the management and registration of Internet addresses and routing identifiers <address-policy-wg.ripe.net> List-Post: <mailto:address-policy-wg@ripe.net> X-RIPE-Lists: Developing policies relating to the management and registration of Internet addresses and routing identifiers <address-policy-wg.ripe.net> List-Subscribe: <http://www.ripe.net/mailman/listinfo/address-policy-wg>, <mailto:address-policy-wg-request@ripe.net?subject=subscribe> List-Unsubscribe: <http://www.ripe.net/mailman/listinfo/address-policy-wg>, <mailto:address-policy-wg-request@ripe.net?subject=unsubscribe> List-Help: <mailto:address-policy-wg-request@ripe.net?subject=help> List-Archive: <http://www.ripe.net/mailman/private/address-policy-wg/> Date: Thu, 16 Sep 2004 12:01:01 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by i.dont.no id i8GD3O9Z028063 RIPE Dear Sir, Madam, ETNO, representing 41 major telecom operators from 34 European countries, has studied the proposal to replace the fixed utilisation criteria of 80% in IPv4 address space allocation, by criteria based on AD (Assignment Density) ratio. Our conclusions are formulated in the attached Expert Contribution EC064. The document is the unanimous opinion of ETNO Members represented in the ETNO Frequency Management Working Group and has been endorsed by the ETNO Board. We are all prepared to discuss these comments in more detail and whenever useful. ETNO will be pleased to contribute to the further development of Europe's views on the issue. Best regards, Michael Bartholomew ETNO Director ------------------------- September 2004 ETNO Expert Contribution on AD ratio for IPv4 addresses allocation Executive Summary ETNO (1) has considered the proposal to replace the fixed utilisation criteria of 80% in IPv4 address space allocation, by a criteria based on AD (Assignment Density) ratio. ETNO strongly support the proposal and suggest selecting an AD ratio of 0.966. ETNO further suggest to the RIRs to monitor the impact of this measure on address consumption and periodically report on it to the addressing community. Background During the RIPE 48 meeting in Amsterdam, a proposal was presented by APNIC to replace the fixed utilisation criteria of 80% to request additional IPv4 addresses blocks, by a criteria based on "AD ratio" value. This ratio value corresponds to a logarithmic scale and corresponds to a percentage utilisation, which decreases as the size of the address space grows. The presentation can be downloaded at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-hd-ratio.p df The decision was made to take the discussion to the RIPE Address-policy working group mailing list and to ask for some feed back from the community. As most European Telecommunications Network Operators' Association 1(ETNO) members are large or extra-large Local Internet Registries in Europe, representing an important part of these categories in the RIPE region, this proposal was considered and analysed with attention. Findings 1- This proposal fairly takes into account addressing hierarchies used in large and extra-large registries and introduces a useful level of flexibility for those registries. 2- The Local Internet Registries using the 80% criteria may continue to do so and will not be impacted by the new policy. 3- Complicated calculation or administrative burden should be easily avoided to registries choosing this method using simple chart or software through LIR portal. 4- As analysed by APNIC, the impact on address consumption is limited to a maximum around 20% and can be easily controlled and monitored using a rather conservative approach (AD ratio of 0.966). 5- This impact can be partly counterbalanced by reducing the number of small and extra-small registries whose existence is only justified by management overhead of large registries with current 80% criteria, and has a positive impact on address aggregation. 6- No additional impact on registrations is seen in RIPE region, as infrastructure assignments are already registered in the database. Conclusion ETNO strongly supports this proposal and suggest selecting a conservative AD ratio value of 0.966. ETNO also suggest to the RIRs to monitor the use of this facility and its impact on address consumption, and periodically report on it to the addressing community. (1) The European Telecommunications Network Operators' Association is representing 41 major companies from 34 European countries, providing electronic communications networks over fixed, mobile or personal communications systems. ETNO's primary purpose is to establish a constructive dialogue between its member companies and actors involved in the development of the European Information Society to the benefit of users. More information on ETNO can be found at: www.etno.be ETNO Expert Contribution EC064 (2004/09) --------------050809070908030505050308-- --__--__-- Message: 2 Date: Tue, 8 Nov 2005 03:43:59 +0200 (EET) From: Pekka Savola <pekkas(a)netcore.fi> To: Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?= <baess(a)denic.de> cc: address-policy-wg(a)ripe.net, ipv6-wg(a)ripe.net, ipv6-wg-admin(a)ripe.net, Mohacsi Janos <mohacsi(a)niif.hu> Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-1824570081-1131332849=:12767 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: <Pine.LNX.4.64.0511070508011.12767(a)netcore.fi> On Tue, 1 Nov 2005, Andreas Bäß/Denic wrote: >>>> 4. Allocate /48 to primary hu DNS server that is globally routable? >>>> Are there similar to /48 from 2001:0500::/30 in RIPE region? >>>> >>>> - I think this is the cleanest solution. >>>> >>>> Can we discuss this issue on the working group or mailing lists? >>>> >>>> I saw a proposal: >>>> http://www.ripe.net/ripe/policies/proposals/2005-2.html >>>> >>>> In my opinion this can solve the problem.... > > I have not seen any discussions that think it is a bad idea to assign > several network resources to TLD administrators which will enable them > to operate their nameservers according to RFC3258. > > When we have reviewed the discussions we felt that your objection > against the proposal was because of the size of the assignment. I'm > planning to submit revised proposal with a reduced prefix length which > better fits with other assignment policies. If you are opposing to the > new proposal I would be glad to know as soon as it is submitted. Yes. Let me clarify my objections: 1) special policy for ccTLDs (if they do not anycast) is not IMHO needed as assignments from (some of the) transits should be enough; 2) special policy for any arbitrary service, if anycast, does not seem justified because it's too open-ended; 3) ccTLD combined with requirement to anycast it appears to be suitably well justified operationally and technically. In addition, a) we have enough address space that allocating a (v6) /32 is not waste. b) I'm strongly opposed to creating any special micro-allocation blocks which is just waiting for getting the worms out hence a). So, I'd say that if the policy proposal is 3) with a (v6) /32, I shouldn't have a problem with it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-1824570081-1131332849=:12767-- End of address-policy-wg Digest -- This message has been scanned for viruses and potentially harmful content by StreamShield Protector.

1 0