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

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