January 2004 - address-policy-wg

(no subject)
by Thilo Salmon 15 Feb '04

15 Feb '04

Hello everyone, when RIPE received 82/8 from IANA about a year ago, there has been a discussion on potential routing issues due to ancient filters on this list. That thread went far enough to raise the question whether or not subnets in question should be returned. Getting my daily fix of tech rants I noticed this issue appears to have resurfaced in the mainstream media at http://heise.de/newsticker/data/hob-26.01.04-000/ (German) http://translate.google.com/translate?hl=en&sl=de&u=http://heise.de/newstic… (Google translation) We received a prefix from within this network which we plan to use soon and I am now wondering whether or not we can expect to run into problems. Going through a number of looking glasses I could see my announcement just fine. But then, ISPs who offer lookging glass services are probably more likely to keep their filters up to date. Has anybody used 82/8 subnets and gathered real life experience on how they route? I'd much rather be prepared, if this turns into a teaching assignment. Thilo

3 2

Re: [address-policy-wg] Summary of actions from RIPE 47 address policy meeting
by Jeff Williams 30 Jan '04

30 Jan '04

Hans and all, Are members in the AFNIC region do not support a the proposed minimum allocation of a /22. Hans Petter Holen wrote: > Action Responsible Status > 46.1 Chairs-WG Revise RIPE 152 (not allowed to charge for > domain names), Done > > 46.4 Chairs Summarize and propose updated description of > the policy process Completed > > 47.1 Chair Policy Development Process > Form a task force to write a policy > development process propposal > > 47.2 NCC RIPE 152 to Historical and recomed to the > RIPE NCC to make a clear statement that > they do not charge for IP addresses > > 47.3 Andreas Bäß Anycast for CCTLD complete discussion on > mailinglist to form formal proposal > > 47.4 Chair Afrinic proposal for /22 mimimum allocation > size. Seek final consensus on the list > > Best Regards, > Hans Petter Holen > Chair 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] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1(a)ix.netcom.com Contact Number: 214-244-4827

1 0

Summary of actions from RIPE 47 address policy meeting
by Hans Petter Holen 29 Jan '04

29 Jan '04

Action Responsible Status 46.1 Chairs-WG Revise RIPE 152 (not allowed to charge for domain names), Done 46.4 Chairs Summarize and propose updated description of the policy process Completed 47.1 Chair Policy Development Process Form a task force to write a policy development process propposal 47.2 NCC RIPE 152 to Historical and recomed to the RIPE NCC to make a clear statement that they do not charge for IP addresses 47.3 Andreas Bäß Anycast for CCTLD complete discussion on mailinglist to form formal proposal 47.4 Chair Afrinic proposal for /22 mimimum allocation size. Seek final consensus on the list Best Regards, Hans Petter Holen Chair

1 0

Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Joao Damas 24 Jan '04

24 Jan '04

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(a)Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > >

5 7

Call for Nominations to the ICANN Board of Directors
by Axel Pawlik 22 Jan '04

22 Jan '04

Dear colleagues, We are pleased to announce a Call for Nominations to the ICANN Board of Directors (see below). In our effort to reach as many interested parties as possible you may receive multiple copies of this message. Please accept our apologies for this. The Call for Nominations for ICANN Board of Directors and current appointments to the Board can be found on the ASO website at: http://www.aso.icann.org/ A publicly archived "expressions of support" form will be made available on the ASO website for those that wish to support nominated candidates. Kind regards, Axel Pawlik RIPE NCC ---- ASO General Assembly 2004 and Call for Nominations for ICANN Board of Directors The Address Council of the Address Supporting Organisation is pleased to announce the 5th ASO General Assembly Meeting, to be held on Wednesday, 5 May 2004 in Amsterdam, The Netherlands. This meeting will be hosted by the RIPE NCC alongside the RIPE 47 Meeting and will be open to all parties with an interest in ASO policy matters. A detailed meeting agenda will be published in due course on the ASO web site at: http://www.aso.icann.org. In compliance with the ASO MoU <http://www.aso.icann.org/docs/aso-mou.html>, the Address Council and ICANN hereby call for nominations to the ICANN Board to fill vacant ASO seats on the ICANN Board. The next such seat scheduled to become vacant in May 2004 is currently occupied by Mr Lyman Chapin. However, candidates nominated at this time may also be chosen to fill other seats that may become vacant before or after this time. Note that appointments to the ICANN Board must satisfy the geographic diversity contraints specified in section 3c. of the ASO MoU. Nominees from North America, South America and Europe are eligible this time. Any individual may be nominated within this process, with the exception of any official of a national government or a multinational entity established by treaty or other agreement between national governments (ICANN Bylaws Art. VI., Sec 4). Self-nominations are permitted. Nominations should be sent by e-mail to <secretariat(a)aso.icann.org> and should state the following details : A. Nominee details 1. Full name 2. Organisational affiliation 3. Email address 4. Physical address 5. Country of residence 6. Telephone contact 7. Biography B. Details of nominating individual 1. Full name 2. Organisational affiliation 3. Email address 4. Country of residence Nominations must be submitted in English and must be received by the ASO Secretariat before 0900 UTC, 20 April 2004. All nominees will be contacted via e-mail to confirm their willingness to serve as an ICANN Director. If the nominee is not contactable via email then the nomination will not be confirmed, a nominee must explicitly confirm the nomination to the ASO Secretariat to be considered as a candidate. All confirmed nominations will be listed on the ASO website (see http://www.aso.icann.org) as soon as they are confirmed. Those wishing to express support for any individuals who have been nominated should use the "ICANN Board - Support of Nomination" Form which will be made available on the ASO website. The list of nominated individuals and the supporting comments will be passed to the Address Council after all nominees are confirmed, and prior to the General Assembly meeting on 5 May 2004, 16:00 - 18:30. More information regarding the ASO GA and nominations process will be posted on the ASO website <http://www.aso.icann.org> in due course.

1 0

AfriNIC Transition: IPv4 allocation Policy change
by Adiel A. AKPLOGAN 22 Jan '04

22 Jan '04

IPv4 Allocation Policy for the African Portion of the RIPE NCC service Region: The motivation behind this is that today there are three different policies applied to African LIRs: (ARIN, RIPE NCC, APNIC). To ease the transition to AfriNIC (the registry for Africa) policies need to be harmonized. The ARIN Community has already taken a step by creating a particular policy for its African members. It will be a good step if the RIPE community can do the same for its African Members by making the minimum allocation the same. The proposed policy change below is for those operating in Africa. It is intended as an interim, transitional policy during the period before AfriNIC takes on the RIR function for the African continent. From that time the policies agreed at the AfriNIC-I meeting will be used in Africa. Also we should keep in mind that this will only affect the IP block 196.200/13 used by RIPE NCC to allocate address in Africa. BGP filters then need to be adapted to permit longer prefix (/22) only in this block. Proposed change: * Minimum allocation: The minimum allocation for African members of RIPE NCC should be changed from /21 to /22. _______________________________________________________________________ Adiel A. AKPLOGAN Off. +31 (0)20 535 4444 RIPE NCC - AfriNIC project Manager Fax: +31 (0)20 535 4445 Singel 258 - 1016AB Amsterdam - NL www.ripe.net --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.561 / Virus Database: 353 - Release Date: 13/01/2004

4 5

Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region
by Jeff Williams 21 Jan '04

21 Jan '04

Izumi and all, > Hi German and Anne, > > Thanks for the clarification. > > If the v6 policy is to be "co-ordinated" but not unique, I agree that > it is sufficient to announce the consensus in the global ML, but my > understanding is different. > > I thought that all the RIRs share a single policy document for IPv6 > and may create supplmentary documents/fringe policies to accomodate > minor differences. Based on this context, I assumed that any major > changes in the policy document requires consensus of the global > community, and not only within the region. I agree that your assumption regarding v6 or for that matter v4 regarding major allocation policy requires or should require a measured consensus by all of the participating stakeholders/users. > > > It is my understanding that the extent of regional differences > accomodated in the v6 policy had never been publicly discussed nor > stated. All I want to do is clarify this part, which was why I wished > to confirm whether there had been any agreement among the RIRs. Seems to me from following these ML's that the RIR's staff are making or attempting to make policy without any or adequate verifiable measured consensus of the participating stakeholders/users. I know our members in the different regions feel this way and I have ask for but not yet received any confirmation of a demonstrated measured consensus documentation from all regions.. > > > Let me emphasise once again that I am not against the idea of having a > regional policy. I also understand that the LACNIC community has good > reasons to implement the policy change. The policy change that the STAFF of LACNIC has been proportion is needed and/or desired has to my knowledge not reached a participating stakeholder/user measured consensus. > > > If either all RIRs, or the global community thinks it's fine to have a > regional policy and this has been clearly stated, I don't have any > problem about the LACNIC community implementing its own policy. It should and in our members view, that any or all regions that are seeking a regional policy regarding v6 or v4 allocations, must have the measured consensus of the stakeholder/users in those regions. To date none do that I am aware of or have been shown as legitimately documented. > > > Could I assume that we all agree about having regional policies in > IPv6? (I'd interpret this as not only apply to LACNIC but also to > other RIRs) No we don't all agree that there should be regional policies for v6 in as much as minimum allocations as far as I can tell... > > > Izumi > > From: Anne Lord <anne(a)apnic.net> > Subject: Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region > Date: Tue, 20 Jan 2004 15:04:35 +1000 (EST) > > > > > Hi Izumi, Kosuke, > > > > > Could I confirm once again that this was the concious > > > decision(acknowledgement) made by all RIRs, having considered its > > > implications? > > > > I think German has replied to this question and I think the reply > > from the APNIC Secretariat will be similar. > > > > This was *not* part of a concious decision or acknowledgement made > > by all the RIRs. The decision flowed from the LACNIC community > > proposing and accepting the proposal as meeting a 'need' in their > > region. > > > > It is useful to observe that this policy is globally co-ordinated > > rather than a global policy: there were never any agreements by > > any RIR staff that there would be a single global policy. Actually > > APNIC EC has taken a decision to interpret one aspect of the policy > > in a way that differs from the other regions. See: > > > > http://www.apnic.net/docs/policy/ipv6-policy-clarification.html > > > > I also see this and the LACNIC change as part of the normal globally > > co-ordinated policy development processes. My understanding is that > > the reason that LACNIC announced their consensus on the global-v6 policy > > discussion list, was in order to collect feedback from the other > > regions, and if necessary to re-asses the consensus decision. > > In other words, this was an attempt to look at the global context > > and to co-ordinate. > > > > Also please feel welcome to bring the proposed change, and this > > discussion to the agenda of the Policy SIG at the forthcoming > > APNIC Open Policy Meeting. > > > > Best wishes, > > > > Anne > > -- > > > > > From: Kosuke Ito <kosuke(a)bugest.net> > > > Subject: Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region > > > Date: Sun, 18 Jan 2004 12:08:36 +0900 > > > > > > > > > > > Hi, German and all > > > > > > > > I do understand that LACNIC community like to have their > > > > own "bootstrap" condition for deploying IPv6 in LACNIC > > > > region, but I do NOT like to have it with an open jaw > > > > condition, anyway. > > > > > > > > And, I would like to know other RIRs people's view on > > > > this matter, and how LACNIC consider the possible side > > > > effect to the global community once the LACNIC special > > > > condition is implemented. > > > > I believe that RIRs/NIRs community should have a single > > > > view (even though each region has a different need) on > > > > the global coordinated policy like the IPv6 policy which > > > > was built up on the large amount of efforts balancing many > > > > factors from the global point of view, since the IP address > > > > space is a global resourse shared accross the globe. > > > > And RIRs/NIRs, I personally believe, should set a allowance > > > > of changing the global policy to accomodate a local need. > > > > When it needs to change (locally), possible effects after > > > > the change should be discussed from the global resourse > > > > management point of view at the same time. > > > > > > > > I would not like to see avalanche multiplication on relaxing > > > > the allocation conditions initiating from LACNIC to all other > > > > regions... This is my worry. > > > > > > > > Regards, > > > > > > > > Kosuke > > > > > > > > > > > > Jeff Williams wrote: > > > > > German and all, > > > > > > > > > > I wonder when if ever LACNIC will be seeking advisory input from > > > > > the stakeholders/users in their region? I also wonder if LACNIC > > > > > does seek such input, that the desires and requirements of those > > > > > participating stakeholders/users will be adheared to in a responsible > > > > > and direct way? > > > > > > > > > > German Valdez wrote: > > > > > > > > > > > > > > >>Hi Izumi > > > > >> > > > > >>sorry for delay > > > > >> > > > > >>It is intention of the RIR to work in common policies, like the IPv6 > > > > one, > > > > >>when this is possible. > > > > >> > > > > >>Nevertheless, this IPv6 policy proposal is the result of a regional > > > > need. > > > > >>So far has accomplished all the step of our Policy Development Process. > > > > >> > > > > >>Even though common policies may work well they are not bindig for the > > > > RIR. > > > > >> > > > > >>We are aware that this proposal is broken a common policy. For this > > > > reason > > > > >>we are sharing this criteria with the Global IPv6 community. > > > > >> > > > > >>This 45 days period of comment (which ends at january 23rd) is not > > > > part of > > > > >>the policy development process, however is a faculty of LACNIC's > > > > Board to > > > > >>do this. The reason was to recieve more comments from the global > > > > community > > > > >>before the Board made a decision. > > > > >> > > > > >>Regards > > > > >> > > > > >>German Valdez > > > > >>Policy Liaison > > > > >>LACNIC > > > > >> > > > > >>At 12:07 AM 1/7/2004, Izumi Okutani wrote: > > > > >> > > > > >>>It had been my understanding that IPv6 policy would be co-ordinated > > > > >>>among the RIRs, but this seems to imply a regional policy like IPv4. > > > > >>> > > > > >>>That's also one method of the policy process that's proved to work > > > > >>>well, but it should at least be a concious decision by the RIRs(or its > > > > >>>communities). > > > > >>> > > > > >>>Could someone from the RIRs share the position about this? > > > > >>> > > > > >>>Izumi > > > > >>>JPNIC > > > > >>> > > > > >>>From: German Valdez <german(a)lacnic.net> > > > > >>>Subject: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region > > > > >>>Date: Thu, 11 Dec 2003 08:16:29 -0300 > > > > >>> > > > > >>> > > > > >>>> > > > > >>>>FYI LACNIC is calling for last comments for new policies to be applied > > > > >>> > > > > >>>next > > > > >>> > > > > >>>>year. One of this policies is a new criteria for IPv6 Initial > > > > allocation. > > > > >>>> > > > > >>>>This proposal is the result of the analysis of the LACNIC IPv6 WG > > > > and the > > > > >>>>discussion held during our Open Policy Forum in The Havana, Cuba > > > > >>>> > > > > >>>>You can review this proposal at http://lacnic.net/en/last-call.html > > > > >>>> > > > > >>>>On december 9th we started a 45 days period for comments for these > > > > >>>>policies, including the IPv6 one. Comments will be received > > > > through our > > > > >>>>policy public list politicas(a)lacnic.net, subscription to this list > > > > is open > > > > >>>>at http://lacnic.net/en/lists.html. Any comments are welcomed. > > > > >>>> > > > > >>>>Regards > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>German Valdez > > > > >>>>Policy Liaison > > > > >>>>LACNIC > > > > >>>> > > > > >>>>_______________________________________________ > > > > >>>>global-v6 mailing list > > > > >>>>global-v6(a)lists.apnic.net > > > > >>>>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > >>>> > > > > >>> > > > > >>>_______________________________________________ > > > > >>>global-v6 mailing list > > > > >>>global-v6(a)lists.apnic.net > > > > >>>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > >> > > > > >>_______________________________________________ > > > > >>global-v6 mailing list > > > > >>global-v6(a)lists.apnic.net > > > > >>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > > > > > > 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(a)ix.netcom.com > > > > > Contact Number: 214-244-4827 or 214-244-3801 > > > > > > > > > > > > > > > _______________________________________________ > > > > > global-v6 mailing list > > > > > global-v6(a)lists.apnic.net > > > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > > > > > > > > > > > > -- > > > > **********IPv6 Internet Wonderland!************ > > > > Kosuke Ito, Master Planning and Steering Group > > > > IPv6 Promotion Council of Japan > > > > (Visiting Researcher, SFC Lab. KEIO University) > > > > Tel:+81-3-5209-4588 Fax:+81-3-3255-9955 > > > > Cell:+81-90-4605-4581 > > > > mailto: kosuke(a)v6pc.jp http://www.v6pc.jp/ > > > > Lifetime e-mail: kosuke(a)stanfordalumni.org > > > > > > > > > > > > > > > > _______________________________________________ > > > > global-v6 mailing list > > > > global-v6(a)lists.apnic.net > > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > _______________________________________________ > > > global-v6 mailing list > > > global-v6(a)lists.apnic.net > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > > > > > > > > > > _______________________________________________ > global-v6 mailing list > global-v6(a)lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/global-v6 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(a)ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801

2 4

test
by Jason Sohn 20 Jan '04

20 Jan '04

CONFIDENTIALITY NOTICE: This transmission is only for the intended recipient(s). The information contained in this correspondence is confidential. If you are not the intended recipient, you are hereby kindly notified that any dissemination, distribution, copying, or use of this communication is strictly prohibited. If you have received this transmission in error, please notify me immediately and permanently delete this transmission and any attachments. Thank you. No warranty is made that any attachment is free from viruses or other defects, and no responsibility for the consequences arising therefrom will be accepted.

1 0

Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Gert Doering 20 Jan '04

20 Jan '04

Hi, On Mon, Jan 19, 2004 at 05:45:51PM +0100, 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). For the root servers, this is a viable approach (as you can't easily change their IP address). I'm not sure how useful this approach would be for a typical ccTLD that hosts their existing name servers in the PA address block of some hosting provider. > 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. This specific solution (a separate /24 per anycast *instance*) would indeed *also* be a problem under the current policy, but this can be solved - as you suggested - by going for "local" PA addresses. The problem is really the anycast space - you need a routeable /24 (as far as anybody can promise "routeability") for a single host, and the current PI policy won't give you that. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

1 0

Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region
by Jeff Williams 20 Jan '04

20 Jan '04

Anne and all, Anne Lord wrote: > Hi Izumi, Kosuke, > > > Could I confirm once again that this was the concious > > decision(acknowledgement) made by all RIRs, having considered its > > implications? > > I think German has replied to this question and I think the reply > from the APNIC Secretariat will be similar. I did not see Germans answer to this question nor to mine I ask him below on this thread. I also checked the archives and also cannot find his answer. The APNIC Secretariat's answer was indirect and cryptic in nature as it does not reflect the needs of the stakeholders/users of the regions community that can be demonstrated. I did request some evidence of such demonstrated/measured consensus, of the secretariat, but after two days, none has been forthcoming... > > > This was *not* part of a concious decision or acknowledgement made > by all the RIRs. The decision flowed from the LACNIC community > proposing and accepting the proposal as meeting a 'need' in their > region. > > It is useful to observe that this policy is globally co-ordinated > rather than a global policy: there were never any agreements by > any RIR staff that there would be a single global policy. Actually > APNIC EC has taken a decision to interpret one aspect of the policy > in a way that differs from the other regions. See: > > http://www.apnic.net/docs/policy/ipv6-policy-clarification.html Ah yes well as has already been observed and recently discussed, this "Clarification" has been refuted... > > > I also see this and the LACNIC change as part of the normal globally > co-ordinated policy development processes. My understanding is that > the reason that LACNIC announced their consensus on the global-v6 policy > discussion list, was in order to collect feedback from the other > regions, and if necessary to re-asses the consensus decision. > In other words, this was an attempt to look at the global context > and to co-ordinate. It is almost always a wise idea to co-ordinate between and with any or all regions. However one ML for doing so is not shown to be adequate for accomplishing said co-ordination... > > > Also please feel welcome to bring the proposed change, and this > discussion to the agenda of the Policy SIG at the forthcoming > APNIC Open Policy Meeting. > > Best wishes, > > Anne > -- > > > From: Kosuke Ito <kosuke(a)bugest.net> > > Subject: Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region > > Date: Sun, 18 Jan 2004 12:08:36 +0900 > > > > > > > > Hi, German and all > > > > > > I do understand that LACNIC community like to have their > > > own "bootstrap" condition for deploying IPv6 in LACNIC > > > region, but I do NOT like to have it with an open jaw > > > condition, anyway. > > > > > > And, I would like to know other RIRs people's view on > > > this matter, and how LACNIC consider the possible side > > > effect to the global community once the LACNIC special > > > condition is implemented. > > > I believe that RIRs/NIRs community should have a single > > > view (even though each region has a different need) on > > > the global coordinated policy like the IPv6 policy which > > > was built up on the large amount of efforts balancing many > > > factors from the global point of view, since the IP address > > > space is a global resourse shared accross the globe. > > > And RIRs/NIRs, I personally believe, should set a allowance > > > of changing the global policy to accomodate a local need. > > > When it needs to change (locally), possible effects after > > > the change should be discussed from the global resourse > > > management point of view at the same time. > > > > > > I would not like to see avalanche multiplication on relaxing > > > the allocation conditions initiating from LACNIC to all other > > > regions... This is my worry. > > > > > > Regards, > > > > > > Kosuke > > > > > > > > > Jeff Williams wrote: > > > > German and all, > > > > > > > > I wonder when if ever LACNIC will be seeking advisory input from > > > > the stakeholders/users in their region? I also wonder if LACNIC > > > > does seek such input, that the desires and requirements of those > > > > participating stakeholders/users will be adheared to in a responsible > > > > and direct way? > > > > > > > > German Valdez wrote: > > > > > > > > > > > >>Hi Izumi > > > >> > > > >>sorry for delay > > > >> > > > >>It is intention of the RIR to work in common policies, like the IPv6 > > > one, > > > >>when this is possible. > > > >> > > > >>Nevertheless, this IPv6 policy proposal is the result of a regional > > > need. > > > >>So far has accomplished all the step of our Policy Development Process. > > > >> > > > >>Even though common policies may work well they are not bindig for the > > > RIR. > > > >> > > > >>We are aware that this proposal is broken a common policy. For this > > > reason > > > >>we are sharing this criteria with the Global IPv6 community. > > > >> > > > >>This 45 days period of comment (which ends at january 23rd) is not > > > part of > > > >>the policy development process, however is a faculty of LACNIC's > > > Board to > > > >>do this. The reason was to recieve more comments from the global > > > community > > > >>before the Board made a decision. > > > >> > > > >>Regards > > > >> > > > >>German Valdez > > > >>Policy Liaison > > > >>LACNIC > > > >> > > > >>At 12:07 AM 1/7/2004, Izumi Okutani wrote: > > > >> > > > >>>It had been my understanding that IPv6 policy would be co-ordinated > > > >>>among the RIRs, but this seems to imply a regional policy like IPv4. > > > >>> > > > >>>That's also one method of the policy process that's proved to work > > > >>>well, but it should at least be a concious decision by the RIRs(or its > > > >>>communities). > > > >>> > > > >>>Could someone from the RIRs share the position about this? > > > >>> > > > >>>Izumi > > > >>>JPNIC > > > >>> > > > >>>From: German Valdez <german(a)lacnic.net> > > > >>>Subject: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region > > > >>>Date: Thu, 11 Dec 2003 08:16:29 -0300 > > > >>> > > > >>> > > > >>>> > > > >>>>FYI LACNIC is calling for last comments for new policies to be applied > > > >>> > > > >>>next > > > >>> > > > >>>>year. One of this policies is a new criteria for IPv6 Initial > > > allocation. > > > >>>> > > > >>>>This proposal is the result of the analysis of the LACNIC IPv6 WG > > > and the > > > >>>>discussion held during our Open Policy Forum in The Havana, Cuba > > > >>>> > > > >>>>You can review this proposal at http://lacnic.net/en/last-call.html > > > >>>> > > > >>>>On december 9th we started a 45 days period for comments for these > > > >>>>policies, including the IPv6 one. Comments will be received > > > through our > > > >>>>policy public list politicas(a)lacnic.net, subscription to this list > > > is open > > > >>>>at http://lacnic.net/en/lists.html. Any comments are welcomed. > > > >>>> > > > >>>>Regards > > > >>>> > > > >>>> > > > >>>> > > > >>>>German Valdez > > > >>>>Policy Liaison > > > >>>>LACNIC > > > >>>> > > > >>>>_______________________________________________ > > > >>>>global-v6 mailing list > > > >>>>global-v6(a)lists.apnic.net > > > >>>>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > >>>> > > > >>> > > > >>>_______________________________________________ > > > >>>global-v6 mailing list > > > >>>global-v6(a)lists.apnic.net > > > >>>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > >> > > > >>_______________________________________________ > > > >>global-v6 mailing list > > > >>global-v6(a)lists.apnic.net > > > >>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > > > 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(a)ix.netcom.com > > > > Contact Number: 214-244-4827 or 214-244-3801 > > > > > > > > > > > > _______________________________________________ > > > > global-v6 mailing list > > > > global-v6(a)lists.apnic.net > > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > > > > > > > -- > > > **********IPv6 Internet Wonderland!************ > > > Kosuke Ito, Master Planning and Steering Group > > > IPv6 Promotion Council of Japan > > > (Visiting Researcher, SFC Lab. KEIO University) > > > Tel:+81-3-5209-4588 Fax:+81-3-3255-9955 > > > Cell:+81-90-4605-4581 > > > mailto: kosuke(a)v6pc.jp http://www.v6pc.jp/ > > > Lifetime e-mail: kosuke(a)stanfordalumni.org > > > > > > > > > > > > _______________________________________________ > > > global-v6 mailing list > > > global-v6(a)lists.apnic.net > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > _______________________________________________ > > global-v6 mailing list > > global-v6(a)lists.apnic.net > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > _______________________________________________ > global-v6 mailing list > global-v6(a)lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/global-v6 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(a)ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801

1 0

Re: Joint policy? (was:RE: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region
by Jeff Williams 20 Jan '04

20 Jan '04

Marcelo and all, marcelo bagnulo wrote: > Hi Jeff, > > I guess that your point is not strictly related with this particular IPv6 > policy proposal but in general about if policies should be common or not. > (so i changed the subject) Yes in part, this is the point I was trying to make and support from others comments/remarks. > > > IMHO not taking into account what ather regions are doing is clearly a > mistake (i don't think anyone thinks otherwise) Agreed. > > > OTOH, i am not sure that a joint policy should be the default option. > Different regions have very different realities and policies should be > adapted to this realities. Yes to a very small degree I agree. However in allocation minimums and maximums I and our members in all regions, do not agree. > > > Cooordination is required and so forums like this one to coordinate policies > and where people from other regions can give their opinion on other region's > policies are needed Agreed here strongly. However it again seems that sharing these discussions with other regions seems to be something some participants such as Brian have seemingly been not desiring to do... > > > So i guess that we should try to do joint policies when it is possible and > when a policy is suitable for all the regions, but i am not very confident > that this will be the case always Of course in some instances joint of global policies will not be adequate for some regions. However this should be the rare exception, not the norm. > > > Coming back to the IPv6 case... > > For this particular case of IPv6, i understand that several regions are > having problems whith the policy. > APNIC people have brought lot of issues about this policy to this list and > also a proposal to waive the 200 /48 assignments has been discussed in ARIN, > so perhaps there is possibility here for a joint policy. If we were to do > this, how do think we should continue? First we all should be sharing discussions on issue areas of common consideration. And from their ICANN should set or incorporate any such policy which the RIR's must conform to after of course, stakeholder/user input and considerations is based on a measured consensus... > > > Regards, marcelo > > > -----Mensaje original----- > > De: global-v6-admin(a)lists.apnic.net > > [mailto:global-v6-admin@lists.apnic.net]En nombre de Jeff Williams > > Enviado el: lunes, 19 de enero de 2004 12:16 > > Para: mbagnulo(a)ing.uc3m.es > > CC: Kosuke Ito; German Valdez; Izumi Okutani; global-v6(a)lists.apnic.net; > > icann board address > > Asunto: Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region > > > > > > Marcelo and all, > > > > The issue is not whether Lacnic has a great need now for > > IPv6 addresses or not, or wheater other other RIR's have their > > own minimum allocation policy. Rather the issue is should or should > > not any such allocation policy be uniform across all RIR's and > > how should that policy be determined. > > > > What is seemingly happening is history repeating itself again > > in that each > > region is jumping to a conclusion without consideration enough for > > the future and desiring to be far to restrictive due to special > > interests. We saw allot of this during Jon Postels tenure > > and it lead to a huge mess... > > > > marcelo bagnulo wrote: > > > > > Hi Kosuke, > > > > > > > I would not like to see avalanche multiplication on relaxing > > > > the allocation conditions initiating from LACNIC to all other > > > > regions... This is my worry. > > > > > > While i am not arguing whether or not having common policy is > > the right way > > > to go, I really don't see how this avalanche can be caused by the policy > > > proposed by lacnic. > > > I mean, this policy only applies to the lacnic region where the IPv6 > > > requests so far are measures in tens (a few tens i think), so i > > don't think > > > that an avalanche is likely in the region. Moreover, the proposed policy > > > requests that the LIR has to provide IPv6 services to customers > > physically > > > located _in_ the lacnic region. > > > > > > With respect to all other regions, rirs in these regions still have its > > > policy so, i don't see how this can affect them. > > > > > > the motivation for the lacnic policy proposal is that, as it has been > > > mentioned in this list, the community is not applying for IPv6 > > address space > > > becuase they feel they will not meet the 200 /48 allocations in > > the next 2 > > > years. Moreover, they are not planning to have them, so they > > know they don't > > > qualify for it. > > > > > > AFAIU, the goal of the current policy is to assign address > > space to people > > > that want to actually provide IPv6 services. > > > The proposed policy attempts to do that. The imposed condition does not > > > depends on the adoption of IPv6 in the internet, but in the > > efforts made by > > > the one who obtained the allocation to provide IPv6 services. > > So the policy > > > asks that in order to obtain an allocation, the LIR has to provide IPv6 > > > services to its customers in the region. IMHO this would enable > > obtaining an > > > address block to those who want to provide IPv6 but don't > > really think they > > > will reach the 200 customers in 2 years (which is considered to > > be the most > > > common case in the lacnic region so far) > > > > > > Regards, marcelo > > > > > > > > > > > Regards, > > > > > > > > Kosuke > > > > > > > > > > > > Jeff Williams wrote: > > > > > German and all, > > > > > > > > > > I wonder when if ever LACNIC will be seeking advisory input from > > > > > the stakeholders/users in their region? I also wonder if LACNIC > > > > > does seek such input, that the desires and requirements of those > > > > > participating stakeholders/users will be adheared to in a > > responsible > > > > > and direct way? > > > > > > > > > > German Valdez wrote: > > > > > > > > > > > > > > >>Hi Izumi > > > > >> > > > > >>sorry for delay > > > > >> > > > > >>It is intention of the RIR to work in common policies, > > like the IPv6 > > > > one, > > > > >>when this is possible. > > > > >> > > > > >>Nevertheless, this IPv6 policy proposal is the result of > > a regional > > > > need. > > > > >>So far has accomplished all the step of our Policy > > > > Development Process. > > > > >> > > > > >>Even though common policies may work well they are not > > bindig for the > > > > RIR. > > > > >> > > > > >>We are aware that this proposal is broken a common > > policy. For this > > > > reason > > > > >>we are sharing this criteria with the Global IPv6 community. > > > > >> > > > > >>This 45 days period of comment (which ends at january > > 23rd) is not > > > > part of > > > > >>the policy development process, however is a faculty of LACNIC's > > > > Board to > > > > >>do this. The reason was to recieve more comments from the global > > > > community > > > > >>before the Board made a decision. > > > > >> > > > > >>Regards > > > > >> > > > > >>German Valdez > > > > >>Policy Liaison > > > > >>LACNIC > > > > >> > > > > >>At 12:07 AM 1/7/2004, Izumi Okutani wrote: > > > > >> > > > > >>>It had been my understanding that IPv6 policy would be > > co-ordinated > > > > >>>among the RIRs, but this seems to imply a regional > > policy like IPv4. > > > > >>> > > > > >>>That's also one method of the policy process that's > > proved to work > > > > >>>well, but it should at least be a concious decision by the > > > > RIRs(or its > > > > >>>communities). > > > > >>> > > > > >>>Could someone from the RIRs share the position about this? > > > > >>> > > > > >>>Izumi > > > > >>>JPNIC > > > > >>> > > > > >>>From: German Valdez <german(a)lacnic.net> > > > > >>>Subject: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region > > > > >>>Date: Thu, 11 Dec 2003 08:16:29 -0300 > > > > >>> > > > > >>> > > > > >>>> > > > > >>>>FYI LACNIC is calling for last comments for new policies to > > > > be applied > > > > >>> > > > > >>>next > > > > >>> > > > > >>>>year. One of this policies is a new criteria for IPv6 Initial > > > > allocation. > > > > >>>> > > > > >>>>This proposal is the result of the analysis of the > > LACNIC IPv6 WG > > > > and the > > > > >>>>discussion held during our Open Policy Forum in The Havana, Cuba > > > > >>>> > > > > >>>>You can review this proposal at > > http://lacnic.net/en/last-call.html > > > > >>>> > > > > >>>>On december 9th we started a 45 days period for > > comments for these > > > > >>>>policies, including the IPv6 one. Comments will be received > > > > through our > > > > >>>>policy public list politicas(a)lacnic.net, subscription > > to this list > > > > is open > > > > >>>>at http://lacnic.net/en/lists.html. Any comments are welcomed. > > > > >>>> > > > > >>>>Regards > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>German Valdez > > > > >>>>Policy Liaison > > > > >>>>LACNIC > > > > >>>> > > > > >>>>_______________________________________________ > > > > >>>>global-v6 mailing list > > > > >>>>global-v6(a)lists.apnic.net > > > > >>>>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > >>>> > > > > >>> > > > > >>>_______________________________________________ > > > > >>>global-v6 mailing list > > > > >>>global-v6(a)lists.apnic.net > > > > >>>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > >> > > > > >>_______________________________________________ > > > > >>global-v6 mailing list > > > > >>global-v6(a)lists.apnic.net > > > > >>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > > > > > > 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(a)ix.netcom.com > > > > > Contact Number: 214-244-4827 or 214-244-3801 > > > > > > > > > > > > > > > _______________________________________________ > > > > > global-v6 mailing list > > > > > global-v6(a)lists.apnic.net > > > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > > > > > > > > > > > > -- > > > > **********IPv6 Internet Wonderland!************ > > > > Kosuke Ito, Master Planning and Steering Group > > > > IPv6 Promotion Council of Japan > > > > (Visiting Researcher, SFC Lab. KEIO University) > > > > Tel:+81-3-5209-4588 Fax:+81-3-3255-9955 > > > > Cell:+81-90-4605-4581 > > > > mailto: kosuke(a)v6pc.jp http://www.v6pc.jp/ > > > > Lifetime e-mail: kosuke(a)stanfordalumni.org > > > > > > > > > > > > > > > > _______________________________________________ > > > > global-v6 mailing list > > > > global-v6(a)lists.apnic.net > > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > _______________________________________________ > > > global-v6 mailing list > > > global-v6(a)lists.apnic.net > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > 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(a)ix.netcom.com > > Contact Number: 214-244-4827 or 214-244-3801 > > > > > > _______________________________________________ > > global-v6 mailing list > > global-v6(a)lists.apnic.net > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > 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(a)ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801

1 0

Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 16 Jan '04

16 Jan '04

>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. A "swamp" /24 gets through more legacy filters than a random PI /24. Therefore the policy should specify that these /24s come from the former class C range. --Michael Dillon

1 0

Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Andreas Bäß/Denic 16 Jan '04

16 Jan '04

Hello! In addition to the criteria that leaked out to list a few days ago I have added the technical problem that is solved by deploying anycast for DNS with a lower number of server names to the list of requirements to get an allocation. So the suggested policy would be: 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] As far as DENIC is concerned we would love to see this policy in effect as our additional section is already truncated and we would need to remove names from the authority section to gain more space for V6 glues. But we think it is a good thing to keep the network diversity that we have. See you in Amsterdam Andreas Baess

2 1

Re: [hm-staff] RE: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size
by Michael.Dillon＠radianz.com 16 Jan '04

16 Jan '04

>No-one from the APNIC Secretariat has made any comments about the >proposed policy. The reference to APNIC occurred in a sentence by >Jeff Williams. Things got a bit confused from thereon.. Anyone who is involved in any area of Internet policymaking anywhere in the world, *MUST* be aware who Jeff Williams is and what he does. According to this URL, "Jeff Williams is a fake and an impostor". http://www.dnso.org/clubpublic/ga/Arc03/msg00615.html He seems to like spending his time creating confusion and stirring up trouble for people working on Internet related policy. If you can read German there is a great article about him here http://www.wortfeld.de/2003/08/das_emailphantom Please don't take any of his comments seriously. --Michael Dillon

2 1

ARIN to allocate from 70.0.0.0/8
by Leslie Nobile 16 Jan '04

16 Jan '04

Hello- ARIN received the IPv4 address block 70.0.0.0/8 from the IANA on Jan. 15, 2004. In the near future, ARIN will begin making allocations from this new block. This will include allocations of /20 and shorter prefixes, according to ARIN's minimum allocation policy. You may wish to adjust any filters you have in place accordingly. For informational purposes, a list of ARIN's currently administered IP blocks can be found under "CIDR Blocks" at: http://www.arin.net/statistics/index.html Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN)

1 0

RE: [hm-staff] RE: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size
by Michel Py 15 Jan '04

15 Jan '04

> Michael.Dillon(a)radianz.com wrote: > Anyone who is involved in any area of Internet > policymaking anywhere in the world, *MUST* be aware > who Jeff Williams is and what he does. [snip] > Please don't take any of his comments seriously. Thank you.

1 0

Re: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size
by Jeff Williams 15 Jan '04

15 Jan '04

Hans and all, You are mistaken Hans. It would benefit you and everyone here if you would track Apnic a little closer... Hans Petter Holen wrote: > Dear WG, > As I have seen no proposals to prolong this process, we have consensus on > this matter. > > Seasons Greetings, > Hans Petter Holen > Address Policy WG Chair > > |Dear WG, > |I would like to call for closure on this matter. As this has > |been presented and discussed at the last RIPE meeting and > |proposed to the list as a formal proposal I would like to > |declare consensus on this issue. > | > |There have been discussion on the mainlinglist with some > |critical comments that it is my understanding has been > |clearified. (This proposal does not affect the payment scedule > |or membership structure and it does not affecting the PI policy). > | > |With this I would normaly declare concensus but as no deadline > |was set for the discussion I propose a 1 week last call for > |objections to the process on this matter. If I receive > |objections I propose to set a I month comment period before > |calling for closure on this matter. > | > |Best Regards, > |Hans Petter Holen > |Address Policy WG Chair > | > ||-----Original Message----- > ||From: address-policy-wg-admin(a)ripe.net > ||[mailto:address-policy-wg-admin@ripe.net] On Behalf Of Gert Doering > ||Sent: Friday, October 24, 2003 2:31 PM > ||To: address-policy-wg(a)ripe.net > ||Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA > ||allocation size > || > ||Hi, > || > ||this was discussed on the list before the last RIPE meeting, > |and we had > ||it on the address policy working group meeting (presented by me). > || > ||I think we mostly have consensus on this issue, but I want to present > ||it as a formal proposal, before it's incorporated into the policy. > || > || > ||PROPOSAL: > || > || * the minimum initial allocation size (for new LIRs) is reduced from > || a /20, as of today, to a /21. > || (If a new LIR can demonstrate need for a bigger initial > |allocation, > || they can get a larger address block. This will not be changed). > || > || * the requirement to show an immediate need for 25% of the allocated > || address space is removed for the "minimum initial allocation" > || > || > ||The motivation for that is that under the current policy, > ||startup LIRs that do not already hold address space cannot get > ||an initial PA allocation (which would be a /20 as of today, or > ||bigger), because in many cases, they cannot demonstrate > ||immediate need, or prior utilization of sufficient address space. > || > ||To work around this, many startup LIRs use PI address space as > ||a start, and when they have filled enough of this, apply for > ||their own PA again. > ||The problem with this is that in the end, it's very likely > ||that more than one route will end up in the global BGP table > ||(where one PA route would be sufficient), and also it > ||encourages lying to the RIRs (PI space must not be distributed > ||to third parties, i.e., LIR customers). > || > || > ||The drawback of the changes are that it's potentially wasting > ||address space for "very small LIRs" (that would be happy with > ||a /23 PI space and will now get a "huge" /21). The wastage > ||would only happen for very small LIRs that will never grow to > ||fill the initial /21. > ||A rough calculation shows that "1000 new LIR /21 allocations" > ||would need a /11, which is not an unbearable strain on the > ||conservation side, judging from the total number of LIRs in > ||RIPE land today. > || > ||A second drawback of this is that people may need to adapt > ||their BGP filters to permit /21s from the network block(s) > ||where these allocations are made from. So the RIPE NCC needs > ||to document this accordingly, and ideally, well in advance. > || > ||Gert Doering > || -- NetMaster > ||-- > ||Total number of prefixes smaller than registry allocations: > ||57785 (56883) > || > ||SpaceNet AG Mail: netmaster(a)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(a)ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801

5 11

Re: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size
by Michael.Dillon＠radianz.com 14 Jan '04

14 Jan '04

>> So please: constructive criticism is welcome, but things like >> "all that you do is wrong, because APNIC is doing something!" >> (and no further reason or detail given) are just wasting our >> time. >excuse! where did i say that? please do not put stupid words into >my keyboard, i do that well enough. I suppose Randy has a killfile that discards messages from j-e-f-f w-i-l-l-i-a-m-s so he didn't realize that Gert was replying to one of Jeff's messages to the list. >>> So if we send out a formal proposal to change RIPE things to >>> RIPE lists, and nobody from the RIPE community objects - what's >>> wrong with assuming consensus, then? >i still consider this unwise, and for the reasons i stated. and, >in the face of such statements, i do not consider pointing out that >we are making, or proposing to make, policy that affects the global >internet a waste of time. I agree with Randy here. The regional boundaries are very fuzzy. The Internet routes across these boundaries as if they were not there. Many companies operate networks in more than one region. I was born in the ARIN region, now I live in the RIPE region and I work for a company whose network spans ARIN, RIPE and APNIC regions. Consensus on a RIPE mailing list could be a way to ignore what is happening in other regions and it could be a way to lock out other people in the RIPE region who haven't thought of looking at the mailing list. I know that the IETF uses mailing list consensus very successfully but the IETF is doing a very different job from RIPE. --Michael Dillon

1 0

Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 13 Jan '04

13 Jan '04

>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

13 26

RE: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Daniel Monteith 13 Jan '04

13 Jan '04

/24 if only :) I believe currently its the LIR initial allocation boundary that's the minimum guaranteed not to be filtered. I would welcome a move by the ISP's (mainly a couple of tier 1's) to relax this so that BGP multihoming for the small people becomes easier and more efficient. I am sure we are getting to the stage when route table size is not so much of an issue anymore. Cheers Dan -----Original Message----- From: Andre Chapuis [mailto:chapuis@ip-plus.net] Sent: Monday, January 12, 2004 3:43 PM To: Daniel Karrenberg; address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure Agreed, And what about defining an address-range where every ISP opens its filter up to /29 (as an example) ? This would deal with both anycast and address-space conservation. Let's show that we (as ISPs) are not bound to the /24 forever ! André At 10:23 12.01.2004, Daniel Karrenberg wrote: >This discussion is *not* about address policy, >it really is about ** routing policy! ** >The goal is to get prefixes propagated. >They could live in any odd part of the address space! > >Routing policy is made by ISPs. (period) > >In order to provide hints to ISPs making such policy I have previolusly >proposed a *registry* for "special" prefixes with some general >categories like: > > - root server > - TLD server > - second level name server > - internet search engine > - other important prefix (see remarks section ;-) > - .... > >Such a registry could be provided by the RIRs and used by the ISPs when >defining and implementing their routing policy. The art here is to >design the categories and to decide which ones can be policed. It is >easy to determine and to check regularly if a prefix contains name >servers for instance. Other categories should be "self-declaration". >ISPs can then decide if and how to use such a registry. > >Is this something that provides added value to ISPs? >Is it something that is useful for those using such prefixes? > >Daniel > > >PS: If getting any address space at all is a problem for these applications, >this needs to be addressed. Maybe it is already addressed by adjusting >the "initial" usage requirements back to "nil" or some reasonable low level and >reducing the initial allocation size. > >This is a different discussion which belongs here, but I do not reeally follow >it anymore, so pardon me if I just assume it is moving along. -------------------------------------------------------- Andre Chapuis IP+ Backbone Engineering AS3303 Swisscom Enterprise Solutions Ltd Genfergasse 14, CH-3050 Bern +41 31 893 89 61 chapuis(a)ip-plus.net CCIE #6023 --------------------------------------------------------

6 5

Re: allocations to critical infrastructure
by Michael.Dillon＠radianz.com 13 Jan '04

13 Jan '04

>They are, but they are not even using the amount of redundancy available >by DNS today (read: "as many name servers as fit into a minimum sized >UDP packet full of glue"). So there is hardly an argument for doing >anycast. I think that it is dangerous for a policy to force people to follow an evolutionary path when they implement technology. If it is considered "best practice" for a DNS infrastructure to use anycast then we should not penalize them because they jump there from a more primitive state. >The route servers use TCP, which will not work over anycast (in the >general case - consider load balancing, every other packet going to >a different destination machine. No problem for UDP, big problem >for TCP) It is also dangerous for a policy to punish people for evolving their technology. If it is considered "best practice" to use anycast to publish critical infrastructure databases then people should be able to change their services to enable them to use UDP and anycast. There are many ways in which a service could be adapted to anycast, even a session-based service. There are also non-anycast ways to solve this type of problem, such as peer-2-peer overlay networks, that could still benefit from having a well-known address range as a rendezvous point. I really don't think that the policy needs to be a close fit for a certain technical implementation. Instead it needs to express the basic principle which is a non-technical principle. Then it can provide a checklist which deal with technical questions. In the future if the technical implementations change, it will be easier to add or change checklist items if there is a solid principle underlying the policy. --Michael Dillon

2 1

Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 12 Jan '04

12 Jan '04

>> meets this criteria but I would argue that part of Google's service >> are the ads which are not offered freely, i.e. they cost money. >Google is free for most users... Google is a business. If they want fault tolerance then they can buy it from Akamai or else build their own global infrastructure. If Google disappears, we can get similar service from many of their competitors. They aren't part of the infrastructure of the Internet. >> exist. But if DENIC ceases to exist, it is 100% certain that ICANN >> would find some other organization to continue offering .de nameservice. > What makes you so sure that DNS and/or ICANN will survive? LDAP is a well-proven robust and scalable directory services technology that is deployed at large organizations world-wide. But even though LDAP can do everything that DNS can do, there is no movement at all to replace DNS with LDAP and very few organizations run their DNS on top of backend LDAP servers. So DNS will survive for a long time. But if DNS would be replaced by LDAP, then I think DENIC would provide LDAP hosting for the .DE domain. And if DENIC does not survive, then ICANN would find someone else to provide LDAP services for .DE. But if ICANN does not survive, then its powers of allocating top level domains will pass to another organization, and this organization will make sure that there is somebody to host .DE. --Michael Dillon

8 8

Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Elmar K. Bins 12 Jan '04

12 Jan '04

chapuis(a)ip-plus.net (Andre Chapuis) wrote: > Agreed, > And what about defining an address-range where every ISP opens its filter up to /29 (as an example) ? This would deal with both anycast and address-space conservation. > Let's show that we (as ISPs) are not bound to the /24 forever ! Nice idea. You try convincing the Tier-1s (and -wannabes). I second this thought, but I deem it impractical, since the "big players" will be hard to convince to change their filtering boundaries. I believe, some answers will be in the style of "who's RIPE anyway?". Yours, Elmar. -- Es gibt Luegen, verdammte Luegen und RIPE-141(-219)-Netzantraege. (mlelstv, dcii 2003) -----------------------------------------------------------[ ELMI-RIPE ]---

1 0

New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 12 Jan '04

12 Jan '04

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:1A00::/23 from the IANA in January 2004. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Andreas Bäß/Denic 12 Jan '04

12 Jan '04

Beeing the first on this list in 2004 I can't resist to express my best wishes to everyone :-) During the last year, when we made plans for our further operations of our nameservice (i.e. anycast and introduction of IPv6), we discovered that we are getting into conflict with some of the RIPE allocation policies. I have been encouraged to start a discussion about making a policy change request. So here it comes: Request For An IPv4/IPv6 Policy Allowing Assignments For Network Critical Infrastructure Abstract At the moment, DENIC has eleven nameservers serving the de zone. At the moment they are all IPv4 only. DENIC wants to change the DNS setup with a higher total number of nameservers which not only have IPv4 but also IPv6 connectivity. However DENIC cannot simply increase the number of NS records and add AAAA records as this would quickly occasion truncation in the authority section of the UDP answer. Ignoring this limitation would cause negative effects that are described in http://www.ietf.org/internet-drafts/draft-ietf- dnsop-respsize-00.txt In order to keep at least the current quality of service, improve the resilience against distributed denial of service attacks (DDoS) and easier future scalability, the deployment of anycast technology (RFC3258) has been chosen for the future DENIC DNS operation. DENIC can not simply use addresses out of their current assignment because it is current practice to filter announcements on allocation boundaries. Therefore DENIC requests to establish a policy for ccTLD and gTLD nameservers that allows RIPE NCC to assign IPv4, IPv6 addresses that are not likely to be filtered by common practise for anycast-operation of their DNS services. Technical justification for this policy Pros: 1. Acceptance of DNS to be network critical Studies like http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-eof- rickard.pdf shows clearly that ccTLD and gTLD nameservers are a critical network infrastructure that justify special policies to guarantee operability of Internet applications. Three out of four RIRs (APNIC, ARIN and LACNIC) have policies allowing assignments to network critical infrastructure. All three policies classify ccTLDs as critical infrastructure. Extracts from these policies can be found in Appendices I through III. 2. Usage of DNS By size DENIC has 7 million registered domains with a monthly increase of 1%. The introduction of IDN in 2004 will increase the number of de-domains by roughly 500,000 to 1,000,000 domains in addition to the normal growth rate. Query load on nameservers DENIC currently serves 10,000 queries per second (all nameservers combined). The load is expected to increase exponentially as the acceptance of the Internet as a communication infrastructure is rising. New usage for DNS New integrating services like ENUM rely on DNS as their distributed information database. The adoption of ENUM will contribute to the importance of DNS for normal life of industry operations. 3. Resilience As availability expectation for Internet applications grow, nameservers are part of the critical Internet infrastructures to make these applications work. Anycasting is currently the state-of- the-art solution to lower the impact of DDoS attacks. 4. Allow smooth IPv6 transition As the world starts exploiting IPv6, the critical infrastructures should support them natively. However the limit of 512 bytes UDP responses put a limit on the total number of names and addresses (IPv4 and IPv6) that can be supplied using DNS protocol. Extension mechanisms for DNS (EDNS0) has removed this limitation but is not widely deployed yet. This dilemma, needing more space in the packets than DNS protocol provides, can be overcome by using anycast technology. Cons: 1. Accepting a number of IPv4/24 and IPv6/32 allocations for critical network infrastructures does not align with the traditional address conservation efforts. With anycasting it is very likely that only a few addresses from the entire assignment would be used. 2. RIPE document 233 dated from 24th May 2002 says: "Although it is undesirable to give special status to any IP (IPv4 or IPv6) address block, it was agreed by the community that the particular need defined in this document is the only justifiable exception to that general principle." Consequences of a policy change After allowing special assignments for anycast ccTLD/gTLD nameservers, there is a need to establish consensus in the RIPE region about which criteria will qualify a service to be considered Internet critical infrastructure. There might be other services beside TLD DNS falling into this category. Appendix I APNIC Policy (Following section is taken from http://www.apnic.net/docs/policy/add-manage-policy.html - 11.3) 11.3 Critical infrastructure The following critical infrastructure networks, if operating in the Asia Pacific region, are eligible to receive a portable assignment: * root domain name system (DNS) server; * global top level domain (gTLD) nameservers; * country code TLD (ccTLDs) nameservers; * IANA; * Regional Internet Registry (RIRs); and * National Internet Registry (NIRs). Assignments to critical infrastructure are available only to the actual operators of the network infrastructure performing such functions. Registrar organisations which do not actually host the network housing the registry infrastructure, will not be eligible for an assignment under this policy. The minimum assignment made under these terms is /24. Appendix II ARIN Policy (Following section taken from http://www.arin.net/policy/ipv4.html#microalloc) Micro-allocations (Policy 2001-3) Note: This policy makes obsolete the former micro-allocation policy. ARIN will make micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA. These allocations will be no longer than a /24 using IPv4 or a /48 using IPv6. Multiple allocations may be granted in certain situations. Exchange point allocations MUST be allocated from specific blocks reserved only for this purpose. All other micro-allocations WILL be allocated out of other blocks reserved for micro-allocation purposes. ARIN will make a list of these blocks publicly available. Appendix III LACNIC (Following section is taken from http://lacnic.net/policy-en.pdf) 3.3.3 Micro Allocations Micro allocation is the name given to those allocations that imply blocks smaller than /20 but always larger than or equal to /24. LACNIC can grant this type of allocation in case of projects and infrastructure for networks that are key or critical for the region, such as IXPs (Internet Exchange Points), NAPs (Network Access Points), RIRs, ccTLDs, among others. In the case of IXPs or NAPs, in order to be able to apply for this type of allocation, organizations shall meet the following requirements: 1. Duly document the following aspects: 1. 1Prove by means of their bylaws their capacity of IXP or NAP. The organization shall have at least three members and an open policy in relation to the association of new members. 1. 2Submit a company structure organizational diagram. 1. 3Document the numbering plan to be implemented. 2. Provide a usage plan for the following three and six months. The rest of the applications shall be studied based on the analysis of the documentation justifying the critical and/or key aspects of the project. Organizations receiving micro allocations are not authorized to suballocate these addresses. -- Andreas Baess DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt

14 31

Re: Antwort: Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 12 Jan '04

12 Jan '04

> >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. DNS Black Lists are part of the crtitical email infrastructure. Someday a bogon routeserver service like this one: http://www.cymru.com/BGP/bogon-rs.html might want to use anycast. It is part of the critical routing infrastructure. It would be good for the policy to be based on the principle of supporting fault tolerance for critical infrastructure and then it can have a checklist of indicators like TLD operator, anycast implementation, freely available service and so on. It is a good idea to have a checklist that makes the policy easy to implement by the hostmasters, but it is also a good idea for the policy to have a clear foundation statement to cover anything that was not considered in the checklist. --Michael Dillon

2 1

Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 09 Jan '04

09 Jan '04

>> Google is a business. If they want fault tolerance then they can >Ah, and VeriSign, or VRS, isn't? Or those DNS providers for ORG, INFO, LA, >AG, ...? Most of those registries have signed a Registry Data Escrow Agreement with ICANN and every day they update a copy of the domain registry data that is held by a 3rd party escrow agent. This is because they are operating a service on behalf of ICANN and if they go bakrupt or if they break their ICANN contract then ICANN can take the escrow copy of the data and get someone else to run the TLD registry. Verisign is a business, but the DNS and whois services that they provide are part of the Internet's infrastructure. There is no alternative place to get authoritative mapping of .com domain names to IP addresses or ownership data for a .com domain. In that sense Verisign has no competitors. >> buy it from Akamai or else build their own global infrastructure. >> If Google disappears, we can get similar service from many of their >> competitors. They aren't part of the infrastructure of the Internet. >But part of the economically critical infrastructure. And it's not the RIR's >job to decide whether they better buy the service or provide it themselves. >Sorry, this part of the discussion is heading absolutely nowhere. You're right, I don't know why you headed in that direction. RIPE is concerned with critical Internet infrastructure and not with critical economic infrastructure. --Michael Dillon

2 1

Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 08 Jan '04

08 Jan '04

>The policy needs to balance everyones needs Yes. >(among that: "little extra routes in the DFZ"). DFZ (default free zone) = global routing table. If someone can implement a solution by announcing a shorter prefix from an existing netblock then there is nothing that RIPE can do to change the number of routes in the global routing table. >The policy does also need very clear-cut criteria to *decide* whether >something meets the policy or not. Applying technical criteria is easy >(easier, at least) than a fuzzy term like "critical infrastructure" >that mean something different to whoever reads it. Yes. And a good policy would start by defining the fuzzy term so that everyone understands the scope of the term when it is used in the policy. >Commenting on your first example: for the USA, something might very >well be a "critical infrastructure", like the US power grid, and *still* >the rest of the world might not care much if it breaks down... - so >the definition of "criticial infrastructure" is very much localized and >fuzzy. Yes. The word "critical" is a value judgement. Critical Internet Infrastructure is different from Critical National Infrastructure. In the USA they are focusing on infrastructure that is critical to their nation. We should look at infrastructure that is critical to the Internet, both globally and in the RIPE region. --Michael Dillon

2 1

Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Hank Nussbacher 08 Jan '04

08 Jan '04

At 11:01 AM 08-01-04 +0000, Michael.Dillon(a)radianz.com wrote: >People seem to be confused about the meaning of "critical infrastructure" >so I decided to see what Google has to say. The first thing it comes up >with is an American government organization called the Department for >Homeland Security. On their question and answer page they say this: >http://www.ciao.gov/publicaffairs/qsandas.htm > >1.) What is a critical infrastructure? > >The USA Patriot Act defines critical infrastructures as those >"systems and assets, whether physical or virtual, so vital to the >United States that the incapacity or destruction of such systems >and assets would have a debilitating impact on security, national >economic security, national public health or safety, or any >combination of those matters." Why should Europe and the RIPE region care about what the US defines as critical infrastructure? > > Es gibt Luegen, verdammte Luegen und RIPE-141(-219)-Netzantraege. > >Translated: There are lies, damned lies and RIPE-141 request forms. It is RIPE-219. RIPE-141 is dead. >--Michael Dillon -Hank

2 1

Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 08 Jan '04

08 Jan '04

>I believe that your argumentation holds; "critical infrastructure" is >something very personal, and "public"...what's public? Isn't google >a public service, too? Or Yahoo? Or ebay? Or ... People seem to be confused about the meaning of "critical infrastructure" so I decided to see what Google has to say. The first thing it comes up with is an American government organization called the Department for Homeland Security. On their question and answer page they say this: http://www.ciao.gov/publicaffairs/qsandas.htm 1.) What is a critical infrastructure? The USA Patriot Act defines critical infrastructures as those "systems and assets, whether physical or virtual, so vital to the United States that the incapacity or destruction of such systems and assets would have a debilitating impact on security, national economic security, national public health or safety, or any combination of those matters." That's not something very personal. It is something that is important to a large number of people. Here's another one: http://www.atis.org/tg2k/_critical_infrastructure.html critical infrastructure: 1. Elements of a system that are so vital that disabling any of them would incapacitate the entire system. Disabling .de would make the Internet unusable for millions of people in Germany and would affect millions of German-speaking people around the world. When some part of the infrastructure of the Internet is considered to be critical, the people responsible for it will build it so that it can never fail. They do this by applying fault tolerance techniques. Anycasting DNS is a fault tolerance technique. DENIC is asking for a policy that understands the need for fault tolerance when an organization is managing part of the Internet's critical infrastructure. If this policy focuses on the fault tolerance technique then it is doing the wrong things. Policies are not about technology. RIPE policies are political agreements that balance the needs of everyone in the RIPE community. This policy needs to focus on defining which kinds of "critical infrastructure" are important enough for the whole community to justify special allocations. > Es gibt Luegen, verdammte Luegen und RIPE-141(-219)-Netzantraege. Translated: There are lies, damned lies and RIPE-141 request forms. --Michael Dillon

3 2

Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 08 Jan '04

08 Jan '04

>> Suggestion... RIPE will allocate /24 blocks from the IPv4 address >> range that was once called "Class C" address space >> for use by services that are part of the Internet's >> critical infrastructure. These blocks are for services >> that will exist for the forseeable future, are used >> freely by many organizations, and are likely to outlive >> the lifetime of the organization currently operating the >> service. >That's not helpful, as it centers around "critical infrastructure". How >is the RIPE NCC supposed to evaluate how "criticial" something is? A workable policy would need to have definitions of "infrastructure" and "critical" that RIPE can use to evaluate any requests. >.de reachability is mostly meaningless for the majority of the >Internet users (as are all other ccTLDs). Reachability of .com and .net is also mostly meaningless for the majority of the Internet users. They only care if they can get to .cn sites because they can only read one language. The Internet has never recognized the tyranny of the majority so I don't think we should be worrying about this today. --Michael Dillon

3 2

Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 08 Jan '04

08 Jan '04

>In which case I claim that my PC at home is a highly critical infrastructure >as well. When I posted the following suggestion, it included a definition for critical infrastructure and your PC at home doesn't meet it. Suggestion... RIPE will allocate /24 blocks from the IPv4 address range that was once called "Class C" address space for use by services that are part of the Internet's critical infrastructure. These blocks are for services that will exist for the forseeable future, are used freely by many organizations, and are likely to outlive the lifetime of the organization currently operating the service. Your PC at home is not offering a service that will exist for the foreseeable future. I can forsee a future for the Internet into the 22nd century when you and your home PC will be dead. Your home PC is probably not offering a service that is used freely by many organizations. I think this part of the definition needs some work because some people would argue that Google's service meets this criteria but I would argue that part of Google's service are the ads which are not offered freely, i.e. they cost money. Your home PC is not offering any service that would continue to be offered even if you and your home and your company cease to exist. But if DENIC ceases to exist, it is 100% certain that ICANN would find some other organization to continue offering .de nameservice. Maybe this definition should use a name other than critical infrastructure. And my suggestion is nothing more than a first draft. My main point is that a new policy proposal should begin with a first draft of the policy itself so that people can discuss the draft policy instead of spending all the time discussing why it is impossible to write a policy at all. --Michael Dillon

2 1

Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 08 Jan '04

08 Jan '04

>>People seem to be confused about the meaning of "critical infrastructure" >>so I decided to see what Google has to say. The first thing it comes up >>with is an American government organization called the Department for >>Homeland Security. On their question and answer page they say this: >>http://www.ciao.gov/publicaffairs/qsandas.htm >Why should Europe and the RIPE region care about what the US defines as >critical infrastructure? Two reasons. 1. We were talking about Google and if you use Google to search for "critical infrastructure" that is the first link that comes up. 2. There was confusion about the meaning of the English language phrase "critical infrastructure" and it is useful to study how native speakers of English define this phrase. The U.S.A. contains a large number of native English speakers. If you prefer European sources, here is a PDF booklet from the UK's National Infrastructure Security Co-ordination Centre formed in 1999 before the U.S.A. was putting so much emphasis on homeland security. http://www.niscc.gov.uk/aboutniscc/booklet/NISCC%20Booklet2.pdf And if you want EU sources, then here is a report to the EU Parliament on Scientific and Technological Options Assessment (STOA) that is published in both English and German http://www.europarl.eu.int/workshop/itsecurity/docs/helmbrecht_en.pdf http://www.europarl.eu.int/workshop/itsecurity/docs/helmbrecht_de.pdf The point is that "critical infrastructure" is a term that many people already use in policies and they always find it important to provide a definition for the term within the context that they are discussing. RIPE can do the same. --Michael Dillon (living and working in London)

1 0

Re: Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Sabine Dolderer/Denic 08 Jan '04

08 Jan '04

On 08.01.2004 12:10 Hank Nussbacher <hank(a)att.net.il> wrote: > > At 11:01 AM 08-01-04 +0000, Michael.Dillon(a)radianz.com wrote: > > >People seem to be confused about the meaning of "critical infrastructure" > >so I decided to see what Google has to say. The first thing it comes up > >with is an American government organization called the Department for > >Homeland Security. On their question and answer page they say this: > >http://www.ciao.gov/publicaffairs/qsandas.htm > > > >1.) What is a critical infrastructure? > > > >The USA Patriot Act defines critical infrastructures as those > >"systems and assets, whether physical or virtual, so vital to the > >United States that the incapacity or destruction of such systems > >and assets would have a debilitating impact on security, national > >economic security, national public health or safety, or any > >combination of those matters." > > Why should Europe and the RIPE region care about what the US defines as > critical infrastructure? Because it is not only a US-centric view of the Internet. Most governments (at least the German which I know best and most other Europeans) have started to make their own definitions about what they define as critical to their national infrastructure. And they are asking questions how these infrastructure is protected. But I tend to agree that it is maybe better if we find a more neutral wording. Sabine > > > > > Es gibt Luegen, verdammte Luegen und RIPE-141(-219)-Netzantraege. > > > >Translated: There are lies, damned lies and RIPE-141 request forms. > > It is RIPE-219. RIPE-141 is dead. > > > >--Michael Dillon > > -Hank > > Viele Grüße Sabine Dolderer -- Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235

1 0

Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 08 Jan '04

08 Jan '04

>> Conservation is not an issue regarding IPv6. >...within an address block, this is true. However, what is being >talked about here is "globally routeable chunks of addresses", and >there conservation *is* an issue, since nothing really changes with >respect to routing with IPv6 compared to IPv4. It is best to clarify what resource we want to conserve. I don't think there is any need to conserve IPv4 addresses any more. Exponential growth is a think of the past and we have enough IPv4 addresses to last 10 to 20 years. We also have a replacement protocol, IPv6, that is already commercially deployed in Asia and in Europe. However, we might still want to conserve the number of entries in the global routing table because of the impact on router memory, router CPU and the time required to reload a full view of the Internet when a router is restarted. If we refuse to give DENIC a /24 from the recovered "Class C" swamp space we would be saving a small amount of IPv4 address space but we might not save any global routing table entries... --Michael Dillon

2 1

Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 08 Jan '04

08 Jan '04

>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). I agree that there should be a specific and well-defined policy. But I think that this policy does not need to be restricted to anycast services. It is a good thing to allocate only /24s and not any longer prefixes like /32 because there is no shortage of IPv4 address space and no need to conserve this space so severely. And I think that the well-known block used for this type of allocation should come from the old "Class C" swamp space. We have recovered lots of unused addresses from this area and we should begin to allocate them for special purposes which can benefit a large part of the community. --Michael Dillon

2 1

Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 07 Jan '04

07 Jan '04

>On Wed, Jan 07, 2004 at 04:15:11PM +0100, Andreas Bäß/Denic wrote: >> Request For An IPv4/IPv6 Policy Allowing Assignments >> For Network Critical Infrastructure >I strictly oppose anything that has "Assignments For Network Critical >Infrastructure" in its title. I think you are wrong here. The important part of this proposal is the critical infrastructure. Anycast is a technical solution and it can be used for unimportant things as well. >NB: the other 3 RIR's "critical infrastructure" policies are just broken >by design - what's special about ARIN's or ICANN's network, as opposed to >the network that runs google.com? I'd say Google is much more critical >to the average network user... DNS services are critical infrastructure, especially top level domain services. You might argue that it would be better for all top level domains to pool their resources and share the same anycast architecture and I would probably agree with you. But I believe that the .de DNS service is far more important than Google's search engine because if the .de service is unavailable then no-one will be able to resolve google.de so the search engine will become unreachable. I agree that the other RIR policies may not be a good example for RIPE to follow. Sometimes RIPE can do things better. Personally I would rather have seen DENIC propose a simple policy text and then explain why. That might be easier to discuss than a request for someone else to write the policy text. Suggestion... RIPE will allocate /24 blocks from the IPv4 address range that was once called "Class C" address space for use by services that are part of the Internet's critical infrastructure. These blocks are for services that will exist for the forseeable future, are used freely by many organizations, and are likely to outlive the lifetime of the organization currently operating the service. I think that .de nameservice meets this criteria. The .de DNS will exist forever, anybody can use it without subscribing or registering, and if DENIC ceased to exist, some other organization would take over the responsibility of hosting .de. --Michael Dillon

3 2

RE: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michel Py 07 Jan '04

07 Jan '04

> Gert Doering wrote: > (To repeat myself: I have no doubts that all these > instutitions are very important for the well-being > of the network. But IP being what it is, their > network infrastructure is "just any other network"). Although the wording is a little strong, I would second this. The issue here is, then why not google, then why not me? Michel.

1 0