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

Re: [address-policy-wg] New Draft Document: De-boganising New Address Blocks
by Michael.Dillon＠radianz.com 25 Feb '04

25 Feb '04

>The RIPE NCC has prepared a draft document titled "De-Bogonising New >Address Blocks": That is a misleading title. The problem is that ISPs cannot react quickly enough to open filters when new ranges are allocated. The proposed solution is to provide advance notification. I suppose this could allow ISPs to open filters before the new addresses are actually in use officially. However, it will also allow spammers to announce this space and get it through bogon filters. The real solution to this problem is to make it possible for ISPs to closely track RIR allocations in their filters in a semi-automated way. There may still be a few days of delay before a new allocation is fully routable but ISPs can compensate for that with internal processes. Why can't ISPs subscribe to a feed of all new RIPE allocations in near real-time? --Michael Dillon

12 18

New Draft Document: De-boganising New Address Blocks
by RIPE NCC WebMaster 25 Feb '04

25 Feb '04

(Apologies for duplicate mails) Dear Colleagues, The RIPE NCC has prepared a draft document titled "De-Bogonising New Address Blocks": <http://www.ripe.net/ripe/draft-documents/deboganising-draft.html> Abstract "This document describes an improvement in the notification process about new blocks of address space being distributed by the RIRs. It is a draft at this stage and your comments are solicited. However to gain experience before finalising the procedures, the RIPE NCC will shortly start announcing the routes from 84/8 described in the document under "pilot"." This document is published as a draft document in order to give RIPE NCC members time to read it and provide feedback. This draft document can be discussed on the RIPE NCC Services Working Group mailing list at <ncc-services-wg(a)ripe.net>. Regards, Webmaster RIPE NCC

2 1

REMINDER: ARIN to allocate from 70.0.0.0/8
by Leslie Nobile 24 Feb '04

24 Feb '04

Hello- This is a reminder that ARIN will begin allocating IP address space from 70.0.0.0/8 in the immediate future. 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

RIPE 47 Meeting Report
by Nick Hyrka 23 Feb '04

23 Feb '04

(Apologies for any duplicate mails.) RIPE 47 Meeting Report Dear Colleagues, The <http://www.ripe.net/ripe/meetings/ripe-47/index.html>RIPE 47 Meeting was held from 26 - 30 January 2004 at the Grand Hotel Krasnapolsky, Amsterdam, the Netherlands. There were a total of 253 attendees comprised of the RIPE NCC membership, the RIPE community and government representatives. Attendees also included representatives from APNIC, ARIN, AfriNIC, LACNIC, ICANN and IANA. HIGHLIGHTS ========== - Highlights of RIPE 47 included the open discussion on the services of the RIPE NCC during the RIPE NCC Services Working Group; updates on the World Summit on the Information Society from Mirjam Khne, ISOC, and Axel Pawlik, Managing Director, RIPE NCC; an AfriNIC update; the proposal by the RIPE community to make RIPE 152 ( 'Charging by Local Internet Registries') a historical document. - As announced by Rob Blokzijl, RIPE Chair, two RIPE Meetings will be held in 2005. Based on the feedback from the community, this schedule will continue in 2006. The RIPE NCC will offer additional support to RIPE Working Groups to facilitate discussion and progress between RIPE Meetings. - Robin Tasker (CCLRC) gave a presentation on the European Commission-sponsored DataTAG project. - The European Operators Forum (EOF) featured an NSP Security BoF, a presentation on which types of SMTP flows should be blocked to prevent spam, a case study on the migration of AOL's backbone network from OSPF to IS-IS and discussion on the use of XML in network configuration. EOF presentations can be viewed at: <http://www.ripe.net/ripe/meetings/ripe-47/presentations/index.html#eof>http://www.ripe.net/ripe/meetings/ripe-47/presentations/index.html#eof - The RIPE NCC, Afilias, Cisco, NIKHEF, NOKIA, Riverhead and SURFnet are thanked for the support they provided to the meeting. Global Voice Networks are thanked for the provision of excellent Internet connectivity. SUMMARY ======== ADDRESS POLICY - It was proposed that RIPE 152 ('Charging by Local Internet Registries') should be made a historical document and that the RIPE NCC should make a clear statement on <http://www.ripe.net/>www.ripe.net that it does not charge for IP addresses. - Hans Petter Holen, Chair, will form a task force to write a policy development process proposal. - Consensus is needed on the mailing list on the AfriNIC proposal regarding /22 minimum allocation size. - Hans Petter Holen, Chair, will start a discussion on the mailing list on changing the 80% rule for IPv4 allocations. Address Policy Working Group presentations can be viewed at: <http://www.ripe.net/ripe/meetings/ripe-47/presentations/#ap>http://www.ripe.net/ripe/meetings/ripe-47/presentations/#ap DATABASE - The issue of CRISP versus joint Whois was discussed. - The proposal to introduce new attribute "abuse-c" in the inet(6)num objects was discussed. - A detailed proposal about "abuse-c" will be sent to Database Working Group mailing list. Database Working Group presentations can be viewed at: <http://www.ripe.net/ripe/meetings/ripe-47/presentations/#db>http://www.ripe.net/ripe/meetings/ripe-47/presentations/#db TEST TRAFFIC MEASUREMENT (TTM) - It was noted that as of 1/1/2004 changes were made to the TTM service contract: Fees were lowered (from 3000 EUR per year to 1000 EUR per year) and all data has been made public as specified in RIPE 300 ('Test Traffic Measurement Service Data Disclosure Policy'). - Two presentations made use of TTM delay data: a presentation on delay tomography used traceroute data from the TTM project; a presentation on the reordering of IP packets used delay data. TTM Working Group presentations can be viewed at: <http://www.ripe.net/ripe/meetings/ripe-47/presentations/#tt>http://www.ripe.net/ripe/meetings/ripe-47/presentations/#tt ANTI-SPAM - A proposal has been sent to the Database Working Group mailing list regarding the inclusion of an abuse-c attribute/object in the RIPE Database to help solve the problem of misdirected/multiple spam complaints. - It was noted that the European Commission Directive is now widely implemented and that in the United States CAN-SPAM is the first federal legislation. IPv6 - The anycast policy discussion was sent to the Address Policy Working Group. - There was discussion on how 6 to 4 is being used to spoof IPv4 origin addresses to make Distributed Denial of Service (DDoS) attacks anonymous. - There was a presentation on the security implications of IPv6 on IPv4 networks. IPv6 Working Group presentations can be viewed at: <http://www.ripe.net/ripe/meetings/ripe-47/presentations/#ipv6>http://www.ripe.net/ripe/meetings/ripe-47/presentations/#ipv6 EIX - An editorial group will be set up to revise the exchange point operator wish list for switches. - Operator-member charters for exchange points were discussed. - DE-CIX presented their experience migrating to new hardware and adding new premises. EIX Working Group presentations can be viewed at: <http://www.ripe.net/ripe/meetings/ripe-47/presentations/#eix>http://www.ripe.net/ripe/meetings/ripe-47/presentations/#eix DN* - The DNR Forum and the DNS Working Group were combined under the DNS Working Group heading. - It was noted that the ENUM RFC 2916bis has been approved by the IETF Working Group and is in the queue of the RFC editor. - It was noted that Internationalized Domain Names (IDN) are being deployed in more new regions. DN* Working Group presentations can be viewed at: <http://www.ripe.net/ripe/meetings/ripe-47/presentations/#dn>http://www.ripe.net/ripe/meetings/ripe-47/presentations/#dn ROUTING - There was a presentation on RISwhois, a tool that allows IP address to origin ASN mapping. - Case studies about convergence of IGP protocols were presented and discussed. Routing Working Group presentations can be viewed at: <http://www.ripe.net/ripe/meetings/ripe-47/presentations/#routing>http://www.ripe.net/ripe/meetings/ripe-47/presentations/#routing RIPE NCC SERVICES - Bijal Sanghani, FLAG Telecom, was appointed as the co-chair of the Working Group. - The RIPE NCC will explore the possibility of providing a service giving test statistics on the routability of new blocks. - The RIPE NCC will give a status update on the Activity Plan 2004 and request input for the Activity Plan 2005 during the RIPE NCC Services Working Group at RIPE 48. RIPE NCC Services Working Group presentations can be viewed at: <http://www.ripe.net/ripe/meetings/ripe-47/presentations/#ncc-services>http://www.ripe.net/ripe/meetings/ripe-47/presentations/#ncc-services TUTORIALS ========= The RIPE NCC staff presented the RIPE NCC IP Request Tutorial. It explained address space assignment and allocation procedures in the RIPE NCC region: <http://www.ripe.net/ripe/meetings/ripe-47/tutorials/ip-request/>http://www.ripe.net/ripe/meetings/ripe-47/tutorials/ip-request/ RIPE 47 WEBCASTING AND ARCHIVES ============================== During RIPE 47, the RIPE NCC held trials in collecting feedback from participants watching the webcast. The mediums used for this were IRC and Jabber. Archives of presentations, webcasts and IRC/Jabber feedback from RIPE 47 are available at: <http://www.ripe.net/ripe/meetings/ripe-47/sessions-archive.html>http://www.ripe.net/ripe/meetings/ripe-47/sessions-archive.html HOSTMASTER CONSULTATION CENTRE (HCC) ==================================== The RIPE NCC Hostmaster Consultation Centre was open at RIPE 47, allowing RIPE NCC Members to discuss issues relating to their business directly with RIPE NCC Hostmasters. RIPE 47 REFERENCE PAGE ====================== A complete list of RIPE 47 sessions, tutorials and presentations can be found at: <http://www.ripe.net/ripe/meetings/ripe-47/index.html>http://www.ripe.net/ripe/meetings/ripe-47/index.html "MEET & GREET" ============= The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 47. "Meet & Greet" introduces newcomers to the meetings, to key attendees from the RIPE community and to social events throughout the week. More information can be obtained by contacting: <meet-greet(a)ripe.net>. RIPE 48 ====== RIPE 48 will be held in Amsterdam, the Netherlands, from 3 - 7 May 2004. Information on RIPE 48 will soon be made available at: <http://www.ripe.net/ripe/meetings/ripe-48/>http://www.ripe.net/ripe/meetings/ripe-48/ New Local Internet Registries (LIRs) ========================== Please note: New LIRs are entitled to two (2) free tickets to attend a RIPE Meeting. The tickets cover the meeting fee only and do not apply to the RIPE dinner, travel or hotel accommodation. More information on the new LIR tickets can be found at: <http://www.ripe.net/ripe/meetings/new-lir.html>http://www.ripe.net/ripe/meetings/new-lir.html For more information, contact <meeting(a)ripe.net>. -- end --

1 0

Draft minutes: RIPE 47 Address Policy WG session
by leo vegoda 20 Feb '04

20 Feb '04

Dear Colleagues, Draft minutes from the Address Policy Working Group session at RIPE 47 can be found at: http://www.ripe.net/ripe/wg/address-policy/r47-minutes.html Please check the minutes for errors or omissions. Comments and corrections can be sent directly to this list or to one of the WG chairs personally. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

IP assignment
by Tahsin Bekdemir 16 Feb '04

16 Feb '04

Hi, One of the our customers use an IP block including few IP addresses now. They plan to upgrade their IP network and will need C class network.They asked us a independent IP block . What is the requirements for a PI assignment? Tahsin BEKDEMIR Network Services Dogan Online Hurriyet Medya Towers,Gunesli Istanbul, TURKEY Phone: +90-212-677 00 00 /ext:2363 E-mail: tbekdemir(a)dol.com.tr -----Original Message----- From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Thilo Salmon Sent: Monday, January 26, 2004 8:57 PM To: address-policy-wg(a)ripe.net Subject: [address-policy-wg] (no subject) 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/news ticker/data/hob-26.01.04-000/ (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

1 0

(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