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

RE: [address-policy-wg] RE: Question - Aviation
by CERASI Eivan 11 Apr '06

11 Apr '06

Hello just to give you some status/complement on what we are doing in Europe for air traffic management. EUROCONTROL (a European organization dealing with the safety of air navigation) has become LIR to obtain a /32. We have started using this address space for ground air traffic control unicast applications but take-up is slow due to the nature of our environment. With regard to air-ground applications, we have launched studies for a more global approach vis-à-vis air/ground applications and this is being performed in collaboration with ICAO working groups. Of course our primary goal is to enable an IP service for air traffic control communications, not passenger nor airline communications. As our environment is highly conservative, technology changes are very slow especially if they have to be global. Our European strategy is that IPv6 is our final target for all communications but our X.25 will still be around for another few years and our IPv4 for even more. It is correct to state that our safety critical applications operate in a closed environment as opposed to the use of classical internet services. However we do have exchanges with internet customers (airlines) via dedicated means. Clearly, both IP routing environments are isolated from each other. To come back on one of the points that was raised below, I do not see the benefit of creating a dedicated address space for such type of applications (just as RFC1918 provides private address space for IPv4). For me, it would just increase the end-user perceived complexity of IPv6. In doing so, you would already cause us a problem of having to change something we have already put into operations ! Best regards Eivan Cerasi -----Original Message----- From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Davis, Terry L Sent: Monday 10 April 2006 22:13 To: Bound, Jim; Tony Hain; PPML; address-policy-wg(a)ripe.net Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on IPv6"); ROBERT Ollivier; narten(a)us.ibm.com; Brig, Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM CERDEC STCD SRI Subject: [address-policy-wg] RE: Question - Aviation Jim/All I am going to respond in two parts here on PI issues; one in terms of aviation and one in terms of corporate. This one is on aviation. The next two paragraphs are from an original response to Thomas Narten, that I didn't see make the list. ---- I view systems that run "critical infrastructure" entirely different from those used to run anything else; especially systems that can directly impact the safety of the people using or relying on them. Safety engineering is just like security engineering; both depend on our ability to build in layers of defense and reliability trying to never rely entirely on a single system. By forcing an industry like aviation to accept the potential of address changing in a global fleet, an element of extreme risk is added as the system's overall reliability is decreased. ---- We know that in the next decade that there will be development initiated for a new air traffic control system. It will likely be built upon IP and if so, likely IP-v6. And ICAO currently has a working group studying this and the committee is leaning towards IP-v6 although there is a strong component that is pushing for IP-v4 and a continuation the NAT type usage currently required in the aviation industry by Arinc 664. And I do definitely agree with Jim here, the use IP-v4 and NAT would create huge risks; if in nothing else, the potential for mis-addressing through one of the hundreds of NAT gateways that would be required. I'll respectfully disagree with Jim in that I believe address change in a complex global system like air traffic control can create a hazard. Keep in mind, that the air traffic control system spans virtually every nation on globe and most everything manmade that flies. Likewise the technical and operational capabilities vary from extraordinary to very minimal; like the 30 or so aviation operators that the EU just banned from flying into EU countries because of their poor safety and maintenance performance record. Coordinating an address change across this type of infrastructure with aircraft and ground infrastructure in almost every nation on the globe, is simply beyond my ability comprehend. Assuming the technology would work flawlessly (discussed below), the politics of when and how to implement the change would likely end up on the floor of the UN for debate. Likewise, if a decision was made to implement a change, we would be dealing with such different levels of expertise around the world that no amount of pre-planning could ensure that implementation failures would not occur. Now just a bit about where ATC systems are likely going and why their criticality will likely grow over the next couple decades. Unless we suddenly develop anti-gravity capabilities to allow slow vertical takeoffs, we are stuck with the airports we have and only minimal abilities to expand them (cost, environmental, noise, etc). The only real way we can expand their capacity is with bigger airplanes and more flights. The "more flights" part is where this gets complicated and critical. To handle more flights, we have to decrease landing and takeoff separations and speed up aircraft ground movements so an airport can handle more aircraft per hour. We are about to human capacity with the current systems which means that these improvements will need to move more and more to relying on precise control systems; a minutes interruption here will be a really big deal. Also we as an industry are just beginning to migrate from bus data communications on the aircraft to networks. The commercial aircraft flying today are already largely computer controlled and as I mentioned above we try very hard not design the aircraft to be critically reliant on any one system. In almost all cases, it requires a cascading series of failures to present an aircraft with a catastrophic hazard. Now as I said, we are starting to put networks on the aircraft and as Arinc 664 shows; we are not the world's greatest network engineers (at least not yet..). In a decade or so, we will have hundreds of networked systems on an aircraft. I think the risk here in re-addressing is clear; how well will they all react. And yes we can probably take most of the risk down in certification testing but keep in mind variation in technical competence of the operators around the world and that we are continually accepting upgraded systems from our vendors as replacement parts and this could also inject potential failures in re-addressing. If we were to use 3178 without a single global address space, I still don't think this would scale as we then would be using probably in the neighborhood of 50 or more ISP's (you don't always get to pick your ISP's and while a country might accept addressing from an industry block, they'd probably insist on using theirs otherwise) around the world for the service. And the way I read it, I would still have lots of unnecessary backhauling to the other side of the planet and some very complicated policy routing to set up. Besides and then with mix of address spaces, I would probably be perpetually leaking with the global Internet in what should be a closed network. Finally at the moment with our existing certification processes, I'm not sure that we would even be permitted to change the aircraft addresses without re-issuing all the affected software with new part numbers. (I'll bet you assumed we used DHCP to address the current aircraft; nope we hard code address everything, remember "bus engineering" 101 ;-) With today's current rules, we haven't put any "critical systems" on anything but a closed onboard network. We are just discussing the ability upload new IP_tables/firewall-rules and authentication certs/passwords to the non-critical networks and I believe that this will be solved in the next couple years. And now also keep in mind that every aviation rule-making body around the world would also have to approve of the address change for an ATC network and define how they were going to certify the change. ====================================================================== Finally now having said all this Jim, I think it is possible for aviation to remain conforming. We have probably only two primary needs for stable IP addressed networks; one for Air Traffic Control and one for Airline Operations. These are industry traffic type designations that have safety related functions that are carried out over them. As we have discussed before, I expect both of them to be run as "closed networks" and should never (IMHO) be seen in the global routing tables; a closed network will provide them with a layer of security, better routing performance, the multi-homing that an aircraft needs, and more options for mobility solutions. Further, two organizations already exist that could legitimately hold the addresses; ICAO for the ATC network as they already govern it and the AEEC for "airline operations" whose members already essentially own "Arinc" which is an ISP already. If it were possible to convince these orgs, to apply for space and the registries to grant them, that would seem to be a solution. Take care Terry PS: Apologies for the length.. PSS: Back to "critical infrastructure" networks a moment, I'd say that any network that wanted to declare itself "critical infrastructure" could obtain PI space, BUT to me this type of network should always be run as a "closed network" with exchanges to the Internet only through "mediation gateways" operating at the application level, not at the routing level. Just food for thought but perhaps there is a class of IP-v6 networks for "critical infrastructure" that have their own PI space, but are prohibited from the participating in "Internet routing". Such a concept might solve lots of problems. > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound@hp.com] > Sent: Saturday, April 08, 2006 5:52 AM > To: Tony Hain; PPML; address-policy-wg(a)ripe.net > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on IPv6"); > Davis, Terry L; ollivier.robert(a)eurocontrol.fr; narten(a)us.ibm.com; Brig, > Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM CERDEC > STCD SRI; Bound, Jim > Subject: RE: Question > > Tony, > > Excellent response and educational for sure. It is my belief that the > corporate business model today for operating networks may be broken and > I think you supported that below? If not my apologies for bad parsing? > > > Their models were fine for an IPv4 world where NAT was required and some > even confuse NAT with securing ones network (and some programs in the > U.S. Government) and that is simply bad policy and view. > > In the interim can this be resolved by RIRs creating some kind of > additional wording that address reclaim will be done in manner that is > negotiable, and do no harm to corporate or government business > operations? This would buy us time to work on the issue and stop the > FUD around this topic? > > Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and > addressing you can lead as ajunct to one of our regular meetings you can > lead for an entire day and we get the right players in the room. So > think about that as another option too. > > But do enjoy the beach this thread does not have to be resolved this > week :--) > > Really want to hear from all of you and discussion Terry D., Latif, > Yanick, Dave G. Mike B. etc. > > Thanks > /jim > > > -----Original Message----- > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > Sent: Friday, April 07, 2006 7:57 PM > > To: 'PPML'; address-policy-wg(a)ripe.net > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The New Internet > > based on IPv6")'; 'Davis, Terry L'; ollivier.robert(a)eurocontrol.fr; > > narten(a)us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; Pouffary, > > Yanick; 'Green, David B RDECOM CERDEC STCD SRI' > > Subject: RE: Question > > > > A public answer to a private question as I have been sitting on a > > beach for awhile without the laptop and missed some related > > conversations ... :) > > > > > Is the outcome really open for discussion on the PI issue? > > It doesn't > > > sound like it is. > > > > In the minds of some the route scaling issue outweighs any argument > > for PI. When taken to its extreme, there is a valid point that a > > broken routing system serves no one. At the same time the > > dogmatic stance by the ISPs enforcing lock-in is just as > > broken both for large organizations with financial or legal > > requirements for operational stability, and the individual > > consumer/small business with limited budgets looking for true > > competition. The hard part is finding the middle ground in a > > way that limits the exposure to a potential routing collapse. > > > > I personally refuse to declare some needs legitimate and others not, > > as the only point of such differentiation is to establish a power > > broker. When all uses are legitimate, the problem boils down to the > > technical approach that can be scaled as necessary to contain growth > > in the routing system. This is the logic that leads me to the > > bit-interleaved geo that can be aggregated in varying size pockets > > as necessary using existing BGP deployments. We can start flat and > > implement aggregation over time when a region becomes too > > large to handle. One nice side effect of this geo approach is > > that it mitigates the continuing political demands for > > sovereign rights to IPv6 space. > > > > Any aggregation approach will force the business models to change > > from current practice. That is not as bad a thing as the alarmists > > will make it out to be, because their accountants are claiming the > > current model is a broken money looser as it is (which if so means > > they will eventually change anyway). The primary difference is that > > there will need to be aggregation intermediaries between the > > last-mile and transit providers. The current model eliminates these > > middle-men by trading off their routing mitigation service > > against a larger routing table (actually they already exist > > in the right places but are currently limited to layer2 media > > aggregators). The anti-PI bunch is trying to use social > > engineering to directly counter the bottom line business > > reality that the customer will always win in the end. > > Rather than accept this situation and constructively work on > > the necessary business model and technology developments, > > they effectively stall progress by staunchly claiming there > > is no acceptable technical approach that works within the > > current business structure. > > > > Making the RIRs be the police deciding who qualifies for PI and who > > does not just adds to their workload and raises costs. The > > beneficiaries of this gatekeeper approach are the ISPs that claim > > they need full routing knowledge everywhere, while the cost burden > > for supporting the waste-of-time qualification/evaluation work is > > borne by the applicant. Given that the most vocal and organized > > membership in the RIR community are the ISPs it is easy to > > understand why it would seem like the PI issue is already decided as > > closed. I tend to believe it will just drag out until enough of the > > corporate world becomes aware of the IPv4 exhaustion in light > > of their growth needs that they collectively appear at their > > RIR and demand an immediate solution. Unfortunately this > > 'wait till the last minute' tactic will likely result in a > > reactionary quickie with its own set of long term side effects. > > > > A while back I tried to hold a BOF on geo PI in the IETF, but was > > told that shim6 was the anointed solution. Now that at least nanog > > has told the IAB where to put shim6 it might be possible to get > > the current IESG to reconsider. In any case the result would > > be a technical approach that would still require RIRs to > > establish policies around. As long as they are dominated by > > the ISPs it will be difficult to get real PI. > > > > Tony > > > > ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender.

2 1

ASO Candidates for ICANN Board Announced: Open Call for Statements of Support
by Paul Rendek 10 Apr '06

10 Apr '06

[Apologies for duplicate e-mails] Dear Colleagues, The Address Supporting Organization (ASO) Address Council has announced details of the candidates to fill its seat on the ICANN Board of Directors. You can find the announcement, the list of candidates, and details on how to submit statements of support at: http://aso.icann.org/ Regards, Paul Rendek Head of Member Services and Communications RIPE NCC

1 0

RE: Question
by Bound, Jim 10 Apr '06

10 Apr '06

Terry, SLAs can be set up to route multihoming and should work for high-order prefixes. See below URL RFC 3178. ftp://ftp.rfc-editor.org/in-notes/rfc3178.txt Also all see attached allocations data from Mike Brig long time IPv6 Forum and NAv6TF SME, actually working with ARIN now on address space for his day job. Mike this is very good. /jim > -----Original Message----- > From: Davis, Terry L [mailto:terry.l.davis@boeing.com] > Sent: Sunday, April 09, 2006 8:40 PM > To: Latif Ladid ("The New Internet based on IPv6"); Bound, > Jim; Tony Hain; PPML; address-policy-wg(a)ripe.net > Cc: Richard Jimmerson; ollivier.robert(a)eurocontrol.fr; > narten(a)us.ibm.com; Brig, Michael P CIV DISA GES-E; Pouffary, > Yanick; Green, David B RDECOM CERDEC STCD SRI > Subject: RE: Question > > Latif > > The ITU is one of my top concerns also. I am hearing the > same tune it sounds like you are; they are chomping at the > bit to get a chance to step in and "save the Internet". > > I'll respond with some longer thoughts tomorrow. Between > Tony's and Jim's last response, I have some thinking to do to > see how it might be made to work technically and politically > with some of the caveats they mention. > > One of my open thoughts, is if I have PA space, can I get > somehow get routing service (multi-homing) from more than the > single ISP that provided the addressing? > > Take care > Terry > > > -----Original Message----- > > From: Latif Ladid ("The New Internet based on IPv6") > > [mailto:latif.ladid@village.uunet.lu] > > Sent: Saturday, April 08, 2006 6:53 AM > > To: 'Bound, Jim'; 'Tony Hain'; 'PPML'; address-policy-wg(a)ripe.net > > Cc: 'Richard Jimmerson'; Davis, Terry L; > ollivier.robert(a)eurocontrol.fr; > > narten(a)us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; 'Pouffary, > Yanick'; > > 'Green, David B RDECOM CERDEC STCD SRI' > > Subject: RE: Question > > > > > > > > The technical community should fix this one before the ITU sees this > as > > another chance to have a political say on the IPv6 > addressing. These > > things leak fast. My advice is that ARIN should seriously own this > > issue > before > > the > > ITU turns it to a sovereignty issue, which they could for sure win > this > > time. I know one of their noodles is sizzling at it. > > > > Cheers > > Latif > > > > -----Original Message----- > > From: Bound, Jim [mailto:Jim.Bound@hp.com] > > Sent: 08 April 2006 14:52 > > To: Tony Hain; PPML; address-policy-wg(a)ripe.net > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > on IPv6"); > > Davis, Terry L; ollivier.robert(a)eurocontrol.fr; narten(a)us.ibm.com; > Brig, > > Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM > CERDEC > > STCD SRI; Bound, Jim > > Subject: RE: Question > > > > Tony, > > > > Excellent response and educational for sure. It is my > belief that the > > corporate business model today for operating networks may be broken > and I > > think you supported that below? If not my apologies for > bad parsing? > > > > > > Their models were fine for an IPv4 world where NAT was required and > some > > even confuse NAT with securing ones network (and some > programs in the > U.S. > > Government) and that is simply bad policy and view. > > > > In the interim can this be resolved by RIRs creating some kind of > > additional wording that address reclaim will be done in > manner that is > negotiable, > > and > > do no harm to corporate or government business operations? > This would > buy > > us time to work on the issue and stop the FUD around this topic? > > > > Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and > > addressing you can lead as ajunct to one of our regular meetings you > can > > lead for an entire day and we get the right players in the room. So > think > > about that as another option too. > > > > But do enjoy the beach this thread does not have to be resolved this > week > > :--) > > > > Really want to hear from all of you and discussion Terry D., Latif, > Yanick, > > Dave G. Mike B. etc. > > > > Thanks > > /jim > > > > > -----Original Message----- > > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > > Sent: Friday, April 07, 2006 7:57 PM > > > To: 'PPML'; address-policy-wg(a)ripe.net > > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The > New Internet > > > based on IPv6")'; 'Davis, Terry L'; > ollivier.robert(a)eurocontrol.fr; > > > narten(a)us.ibm.com; 'Brig, Michael P CIV DISA GES-E'; Pouffary, > Yanick; > > > 'Green, David B RDECOM CERDEC STCD SRI' > > > Subject: RE: Question > > > > > > A public answer to a private question as I have been sitting on a > > > beach for awhile without the laptop and missed some related > > > conversations ... :) > > > > > > > Is the outcome really open for discussion on the PI issue? > > > It doesn't > > > > sound like it is. > > > > > > In the minds of some the route scaling issue outweighs > any argument > > > for PI. > > > When taken to its extreme, there is a valid point that a broken > > > routing system serves no one. At the same time the dogmatic stance > by > > > the ISPs enforcing lock-in is just as broken both for large > > > organizations with financial or legal requirements for > operational > > > stability, and the individual consumer/small business > with limited > > > budgets looking for true competition. The hard part is > finding the > > > middle ground in a way that limits the exposure to a potential > routing > > > collapse. > > > > > > I personally refuse to declare some needs legitimate and > others not, > > > as the only point of such differentiation is to establish a power > > > broker. When all uses are legitimate, the problem boils > down to the > > > technical approach that can be scaled as necessary to > contain growth > > > in the routing system. > > > This is the logic that leads me to the bit-interleaved > geo that can > be > > > aggregated in varying size pockets as necessary using > existing BGP > > > deployments. We can start flat and implement aggregation > over time > > > when a region becomes too large to handle. One nice side > effect of > > > this geo approach is that it mitigates the continuing political > > > demands for sovereign rights to IPv6 space. > > > > > > Any aggregation approach will force the business models to change > from > > > current practice. That is not as bad a thing as the > alarmists will > > > make it out to be, because their accountants are claiming the > current > > > model is a broken money looser as it is (which if so > means they will > > > eventually change anyway). The primary difference is that > there will > > > need to be aggregation intermediaries between the last-mile and > > > transit providers. The current model eliminates these > middle-men by > > > trading off their routing mitigation service against a larger > routing > > > table (actually they already exist in the right places but are > > > currently limited to layer2 media aggregators). The > anti-PI bunch is > > > trying to use social engineering to directly counter the > bottom line > > > business reality that the customer will always win in the end. > > > Rather than accept this situation and constructively work on the > > > necessary business model and technology developments, they > effectively > > > stall progress by staunchly claiming there is no acceptable > technical > > > approach that works within the current business structure. > > > > > > Making the RIRs be the police deciding who qualifies for > PI and who > > > does not just adds to their workload and raises costs. The > > > beneficiaries of this gatekeeper approach are the ISPs that claim > they > > > need full routing knowledge everywhere, while the cost burden for > > > supporting the waste-of-time qualification/evaluation > work is borne > by > > > the applicant. > > > Given that the most vocal and organized membership in the RIR > > > community are the ISPs it is easy to understand why it would seem > like > > > the PI issue is already decided as closed. I tend to > believe it will > > > just drag out until enough of the corporate world becomes aware of > the > > > IPv4 exhaustion in light of their growth needs that they > collectively > > > appear at their RIR and demand an immediate solution. > Unfortunately > > > this 'wait till the last minute' tactic will likely result in a > > > reactionary quickie with its own set of long term side effects. > > > > > > A while back I tried to hold a BOF on geo PI in the IETF, but was > told > > > that > > > shim6 was the anointed solution. Now that at least nanog has told > the > > > IAB where to put shim6 it might be possible to get the > current IESG > to > > > reconsider. In any case the result would be a technical approach > that > > > would still require RIRs to establish policies around. As long as > they > > > are dominated by the ISPs it will be difficult to get real PI. > > > > > > Tony > > > > > > > >

1 0

RE: Question
by Tony Hain 08 Apr '06

08 Apr '06

A public answer to a private question as I have been sitting on a beach for awhile without the laptop and missed some related conversations ... :) > Is the outcome really open for discussion on the PI issue? It doesn't > sound like it is. In the minds of some the route scaling issue outweighs any argument for PI. When taken to its extreme, there is a valid point that a broken routing system serves no one. At the same time the dogmatic stance by the ISPs enforcing lock-in is just as broken both for large organizations with financial or legal requirements for operational stability, and the individual consumer/small business with limited budgets looking for true competition. The hard part is finding the middle ground in a way that limits the exposure to a potential routing collapse. I personally refuse to declare some needs legitimate and others not, as the only point of such differentiation is to establish a power broker. When all uses are legitimate, the problem boils down to the technical approach that can be scaled as necessary to contain growth in the routing system. This is the logic that leads me to the bit-interleaved geo that can be aggregated in varying size pockets as necessary using existing BGP deployments. We can start flat and implement aggregation over time when a region becomes too large to handle. One nice side effect of this geo approach is that it mitigates the continuing political demands for sovereign rights to IPv6 space. Any aggregation approach will force the business models to change from current practice. That is not as bad a thing as the alarmists will make it out to be, because their accountants are claiming the current model is a broken money looser as it is (which if so means they will eventually change anyway). The primary difference is that there will need to be aggregation intermediaries between the last-mile and transit providers. The current model eliminates these middle-men by trading off their routing mitigation service against a larger routing table (actually they already exist in the right places but are currently limited to layer2 media aggregators). The anti-PI bunch is trying to use social engineering to directly counter the bottom line business reality that the customer will always win in the end. Rather than accept this situation and constructively work on the necessary business model and technology developments, they effectively stall progress by staunchly claiming there is no acceptable technical approach that works within the current business structure. Making the RIRs be the police deciding who qualifies for PI and who does not just adds to their workload and raises costs. The beneficiaries of this gatekeeper approach are the ISPs that claim they need full routing knowledge everywhere, while the cost burden for supporting the waste-of-time qualification/evaluation work is borne by the applicant. Given that the most vocal and organized membership in the RIR community are the ISPs it is easy to understand why it would seem like the PI issue is already decided as closed. I tend to believe it will just drag out until enough of the corporate world becomes aware of the IPv4 exhaustion in light of their growth needs that they collectively appear at their RIR and demand an immediate solution. Unfortunately this 'wait till the last minute' tactic will likely result in a reactionary quickie with its own set of long term side effects. A while back I tried to hold a BOF on geo PI in the IETF, but was told that shim6 was the anointed solution. Now that at least nanog has told the IAB where to put shim6 it might be possible to get the current IESG to reconsider. In any case the result would be a technical approach that would still require RIRs to establish policies around. As long as they are dominated by the ISPs it will be difficult to get real PI. Tony

1 0

RIR Comparative Policy Overview Update
by leo vegoda 07 Apr '06

07 Apr '06

[Apologies for duplicate e-mails] Dear Colleague, The Regional Internet Registry (RIR) Comparative Policy Overview has been updated and is available on the Number Resource Organization (NRO) website at: http://www.nro.net/policy/index.html This document enables the community to review the policies in the global RIR system. To view specific policy statements from individual RIRs, please visit each RIR's policy pages: - AfriNIC http://www.afrinic.net/policy.htm - APNIC http://www.apnic.net/docs/policy/dev/index.html - ARIN http://www.arin.net/policy/index.html - LACNIC http://lacnic.net/en/politicas/index.html - RIPE NCC http://www.ripe.net/ripe/policies/ Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

ASO/ICANN Board Nominations Close Soon
by Paul Rendek 03 Apr '06

03 Apr '06

[Sent on behalf of the Address Supporting Organization (ASO) - Apologies for Duplicates] Dear Colleagues In line with the ASO MoU and ICANN bylaws, the Address Council calls for nominations to the ICANN Board to fill the ASO seat. Mouhamet Diop currently holds this seat. His term ends in June 2006. You can send your nominations until 4 April 2006 to <nominations(a)aso.icann.org>. Your e-mail should include the following information: - Full name of person that you want to nominate - A contact e-mail address for the person that you nominate - If available, a contact telephone number for your nominee - Your full name - Your contact e-mail address - Your contact telephone number Nominations will be reviewed in accordance with the ASO Board of Directors selection procedures. You can find these on the ASO website. Regards Paul Rendek RIPE NCC

1 0

IP Assignments for anycasting DNS
by Ondřej Surý 24 Mar '06

24 Mar '06

Hi, I would like to stir the waters around /subj policy proposal. When I requested additional anycast IPv4 addresses for our secondaries I was told, that RIPE cannot allocate /24 for one server according to current policies, hence I would like to see this policy proposal finished. Is there anything we can do to help finishing this proposal? Ondrej. -- Ondřej Surý technický ředitel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Lužná 591, 160 00 Praha 6, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420 222 745 110 fax:+420 220 121 184 -----------------------------------------

2 1

ETNO comments on RIPE Policy Proposal 2005-09
by Debecker J.L. 14 Mar '06

14 Mar '06

RIPE Dear Sir, Madam, ETNO, representing 41 major telecom operators from 34 European countries, has studied the proposed global Internet Assigned Numbers Authority (IANA) policy for allocation of IPv6 blocks to Regional Internet Registries. The Association supports the document and welcomes the open and transparent process used in the development of this proposal. More details are in the attached Expert Contribution EC080. The document is the unanimous opinion of ETNO Members represented in the ETNO Naming, Addressing and Numbering Working Group and has been endorsed by the ETNO Board. We are all prepared to discuss these comments in more detail and whenever useful. ETNO will be pleased to contribute to the further development of Europes views on the issue. Best regards, Michael Bartholomew ETNO Director ------------------------- March 2006 ETNO Expert Contribution on the Internet Assigned Numbers Authority (IANA) policy for allocation of IPv6 blocks to Regional Internet Registries Executive Summary ETNO supports the proposed global Internet Assigned Numbers Authority (IANA) policy for allocation of IPv6 blocks to Regional Internet Registries and welcomes the open and transparent process used in the development of this proposal. The European Telecommunications Network Operators' Association ETNO (1) has carefully reviewed the proposed global policy on Internet Assigned Numbers Authority (IANA) Policy for Allocation of IPv6 Blocks to Regional Internet Registries. ETNO understands that currently no global policy for allocating IPv6 addresses from IANA to RIRs is in place and believes that such a policy is needed. Current allocations from IANA are done on a /23 basis, which in practice have shown that this fixed allocation size is too small and do not allow for efficient and effective management of the resource by the RIRs. The proposal to use /12 as a unit of IPv6 allocation from IANA to RIRs will overcome these problems mentioned above. The policy also provides clear rules and procedures for calculation of available and necessary space and criteria for eligibility for initial and additional allocations. This whole new concept was discussed in an open and transparent way and finally supported within all RIRs fora. ETNO supports this approach as it provides higher flexibility for the RIRs to achieve an efficient and effective management of the IPv6 resource for the benefit of their members and the overall Internet community. (1) The European Telecommunications Network Operators' Association is representing 41 major companies from 34 European countries, providing electronic communications networks over fixed, mobile or personal communications systems. ETNO's primary purpose is to establish a constructive dialogue between its member companies and actors involved in the development of the European Information Society to the benefit of users. More information on ETNO can be found at: www.etno.be ETNO Expert Contribution EC080 (2006/03)

1 0

2005-01 - Last Call for Comments (HD-ratio Proposal)
by RIPE NCC Policy Coordinator 08 Mar '06

08 Mar '06

PDP Number: 2005-01 HD-ratio Proposal Dear Colleagues The proposal to change to RIPE Document ripe-324 is now at its final stage. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-1.html Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 7 March 2006. We will publish the new policy after this date if we receive no objections. Regards Adrian Bedford RIPE NCC

3 3

ASO Call for Nominations for ICANN Board Seat
by Paul Rendek 02 Mar '06

02 Mar '06

Apologies for duplicate e-mails Sent on behalf of the The Address Supporting Organization (ASO) *ASO Call for Nominations for ICANN Board Seat* In compliance with the ASO Memorandum of Understanding (MoU) and ICANN bylaws, the Address Council is calling for nominations to the ICANN Board to fill the ASO seat currently held by Mouhamet Diop, whose term expires in June of 2006. This nomination period will close on 4 April 2006. Nominations may be submitted by anyone by sending e-mail to: nominations(a)aso.icann.org Nominations must include the following information: - Full name of person being nominated - Contact email address for person being nominated - Contact telephone number (if available) of the person being nominated - Full name of the person making the nomination - Contact email address for the person making the nomination - Contact telephone number of the person making the nomination Nominations will be reviewed in accordance with the ASO Board of Directors selection procedures, as documented on the ASO website. Best regards, Paul Rendek Head of Member Services and Communications RIPE NCC

1 0

2005-09 Last Call for Comments (IANA Policy for Allocation of IPv6 Blocks to RIRs)
by RIPE NCC Policy Coordinator 28 Feb '06

28 Feb '06

PDP Number: 2005-09 IANA Policy for Allocation of IPv6 Blocks to RIRs Dear Colleagues The proposal described in 2005-09 is now at its final stage. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-09.html Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 27 March 2006. We will publish the new policy after this date if we receive no objections. Regards Adrian Bedford RIPE NCC Policy Coordinator

1 0

RE: [ppml] [address-policy-wg] 2005-01 - Last Call for Comments(HD-ratio Proposal)
by Davis, Terry L 24 Feb '06

24 Feb '06

Geoff/Randy Just as an aside, efficiency targets probably won't work when applied to mobile networks. Most large global mobile (ships & planes) platforms won't use but a much smaller fraction of the assignment. /24 is the smallest workable unit for global movement with any currently defined schemes. Localized mobility (trains/ferries/trucking) within a small geographical area (or even possibly even a region) may be able to get higher efficiencies depending on strategy/architecture. Take care Terry -----Original Message----- From: Geoff Huston [mailto:gih@apnic.net] Sent: Wednesday, February 22, 2006 7:44 PM To: Randy Bush Cc: ppml(a)arin.net; address-policy-wg(a)ripe.net; sig-policy(a)apnic.net Subject: Re: [ppml] [address-policy-wg] 2005-01 - Last Call for Comments(HD-ratio Proposal) At 02:07 PM 23/02/2006, Randy Bush wrote: > > HD Ratio Ratio Mean Std Dev > > 0.98 1.04868 0.02285 > > 0.97 1.25899 0.03363 > > 0.96 1.45854 0.03371 > > 0.95 1.63073 0.02848 > > 0.94 1.78332 0.01859 > >and what does .98 do to the flight ceiling of small folk? > >randy I'll respond to this question, but in the interests of not wishing to overwhelming a whole swag of mailing lists I'll make this my last posting on this topic today. An HD Ratio of 0.98 imposes a higher efficiency target than the existing 80% rate for all prefix sizes smaller than a /16, and lower than 80% for allocations greater than a /16 (e.g. an HD Ratio of 0.98 implies an efficiency threshold of 72% for a /9 allocation.) As an example, if you had an end use population of between 3,277 and 6,554 numbered devices you would qualify for a /19 allocation under an 80% rule, while under an HD Ratio of 0.98 the end use population is between 3,468 and 6,841, corresponding to a required address efficiency level of 84% on this address block in order to qualify for a further address allocation. The use of an HD Ratio of 0.96 corresponds to an 80% efficiency level for a /24, so that 0.96 is no worse than 80% for all allocations, whereas HD Ratios greater than 0.96 impose an efficiency constraint greater than 80% on the smaller address blocks (/16 through to /24) - this can be easily modelled on any spreadsheet of course. regards, Geoff _______________________________________________ PPML mailing list PPML(a)arin.net http://lists.arin.net/mailman/listinfo/ppml

2 1

Re: [address-policy-wg] 2005-01 - Last Call for Comments (HD-ratio Proposal)
by Rene Wilhelm 23 Feb '06

23 Feb '06

> Have either of you run the simulations with other HDR values? Would .97 make > a significant difference? I also did 0.966, the value proposed in the RIPE48 meeting (may 2004). With an HD ratio of 0.966 the projected increase for the historic RIPE NCC allocations is 22% on 1/1/2006. >> my analysis only looked at the 5,121 allocations done by RIPE NCC >> in 2003-2006. Ooops, wrong number slipped in. It's not 5,121 but 2,939 allocations done by the NCC between 1/1/2003 and 1/1/2006. -- Rene

3 2

Re: [address-policy-wg] 2005-01 - Last Call for Comments (HD-ratio Proposal)
by Rene Wilhelm 23 Feb '06

23 Feb '06

Hi Geoff, > I was also surprised by this number [46%] when I first saw it in the output. Your number is higher, but the analysis I did also showed HD ratio could have a significant impact on the address space consumption. (http://www.ripe.net/ripe/policies/proposals/comments/impact_of_hd.html posted on this list some weeks ago) Looking at all invidual allocations done by RIPE NCC between 2003 and 2006, we modelled the observed growth to a policy which used HDR 0.96 instead of 80% utilisation as the criterium for an LIR to be eligible to receive an additional allocation. Starting 1/1/2003 and stepping through time the simulation thus determined the address space held by each LIR on a day by day basis. By 1/1/2006 this resulted in some 60 million (about 30% of the total) more addresses allocated compared to what we actually had handed out under the 80% rule. Reading your report, I believe one of the reasons our numbers differ is that you are simulating 10,000 allocations; my analysis only looked at the 5,121 allocations done by RIPE NCC in 2003-2006. Since the effects of HD ratio are progressive, the more allocations you simulate, the higher the relative increase in address space consumption becomes. > This experiment has been repeated 1,000 times in order to determine a > stable average value for the relative increase in address consumption > corresponding to a change in the address allocation policies from uniform > 80% to an HD Ratio of 0.96, assuming constant demand for addresses. To get a feeling of how stable your average is, could you indicate what the variation, the standard deviation in these 1,000 repeats is? i.e. did all 1000 give you a number close to 46% or were they spread out a lot? > A related consideration is that of the adoption of such a policy proposal > by all 5 RIRs. >From http://www.arin.net/policy/proposals/proposal_archive.html I understand ARIN already abandoned two proposals to use HD ratio for IPv4 allocations (nrs. 2004-2 and 2003-10). Regards, -- Rene =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rene Wilhelm RIPE Network Coordination Centre Email: wilhelm(a)ripe.net Amsterdam, the Netherlands Phone: +31 20 535 4417 Fax: +31 20 535 4445 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

4 5

Re: [address-policy-wg] 2005-01 - Last Call for Comments (HD-ratio Proposal)
by Geoff Huston 22 Feb '06

22 Feb '06

Here is the promised report on the address consumption implications of the policy proposal 2005-1 (HD-Ratio Proposal) If there is any other aspect of implications of adoption of this proposal that folk may want investigated I'd be happy to see what I can do. Also if any part of this report is unclear I'd be happy to attempt to clarify further the process I've used here. I trust that this report is helpful in terms of assessing some of the impacts of the proposal. regards, Geoff Huston An Analysis of the Sensitivity of using the HD Ratio for IPv4 Address Allocations Geoff Huston V1.0 22 February 2005 This document describes the outcomes of an analytical process intended to describe the sensitivity of the use of HD Ratio metrics as the means of assessing address utilization efficiency, and the relation between the use of HD Ratio values and projected lifetimes of the unallocated IPv4 address pool. This document is a commentary on RIPE Policy Proposal 2005-1 1. Methodology -------------- The methodology used here uses only published RIR allocation data. The primary data source for RIPE NCC data is the delegated file: ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest All IPv4 allocation records with an allocation date on or after 1-Jan-2000 are collected. The allocation sizes are rounded up to the next largest power of 2, or 256, which is the greatest. The relative proportion of each allocation size is also calculated. This is shown in the table below (Table 1). ---------------------------------------------------------------- Table 1 - RIPE NCC IPV4 Address Allocations (since 1-Jan-2000) Size Number Relative Cumulative Frequency Relative Frequency /24 2637 23.04 23.04 /23 1383 12.09 35.13 /22 934 8.16 43.29 /21 545 4.76 48.06 /20 2247 19.64 67.69 /19 1713 14.97 82.66 /18 784 6.85 89.51 /17 407 3.56 93.07 /16 499 4.36 97.43 /15 135 1.18 98.61 /14 75 0.66 99.27 /13 44 0.38 99.65 /12 21 0.18 99.83 /11 15 0.13 99.97 /10 4 0.03 100.00 ---------------------------------------------------------------- The assumption made here is that these allocations are made under a policy of a uniform 80% utilization efficiency. From this can be calculated the inferred maximum end use count for each prefix size (Table 2). ---------------------------------------------------------------- Table 2 - Inferred Maximum End Population Count for each Prefix Size under the uniform 80% efficiency policy /24 205 /23 410 /22 819 /21 1638 /20 3277 /19 6554 /18 13107 /17 26214 /16 52429 /15 104858 /14 209715 /13 419430 /12 838861 /11 1677722 /10 3355443 /9 6710886 /8 13421773 ---------------------------------------------------------------- The HD ratio is calculated by the function: HD = log(used)/log(addresses). This implies that the population can be inferred for any given prefix size using the equation: used = 10**(HD x log_base_10(addresses). The inferred maximum end use count for each prefix size using an HD Ratio value of 0.96 is shown below (Table 3). ---------------------------------------------------------------- Table 3 - Inferred Maximum End Population Count for each Prefix Size under an HD = 0.96 allocation policy /24 205 /23 399 /22 776 /21 1510 /20 2937 /19 5713 /18 11113 /17 21619 /16 42055 /15 81811 /14 159147 /13 309590 /12 602249 /11 1171560 /10 2279048 /9 4433455 /8 8624444 ---------------------------------------------------------------- The next step is to determine the relative impact on address consumption by changing from a uniform 80% utilization efficiency metric to one determined by an HD Ratio setting of 0.96. To do this a sequence of 10,000 allocations are simulated. with each allocation being in the range of a /24 to a /10 prefix. with a probability of any particular prefix being selected based on the relatively frequency distribution of Table 1. The inferred population lies between the maximum population of this prefix and that of the population of the next smaller prefix in Table 2. A random value is drawn from this population range (this is a uniform probability selection between the two extreme population values, so that any population value is equally likely to be selected). This population value is used as a lookup key into Table 3, and the next highest population count is used to determine the equivalent HD Ratio allocated prefix. In effect, this approach generates a series of demand populations that would generate the existing RIR allocation prefix distribution, and then uses this population set to generate a HD-Ratio- based set of allocations that would correspond to this population distribution. The total amount of allocated address space is calculated in each case, and the ratio of the two address pool sizes is recorded. This experiment has been repeated 1,000 times in order to determine a stable average value for the relative increase in address consumption corresponding to a change in the address allocation policies from uniform 80% to an HD Ratio of 0.96, assuming constant demand for addresses. This relative change in address demands can then be added into the IPv4 address consumption projection (see http://ipv4.potaroo.net). The change here is in the simulation of the address consumption model, where in the base model all RIR's are assumed to be operating a uniform address efficiency metric of a uniform 80% utilization target. The same exponential growth model in advertised address growth is used, but this model is augmented by the relative increase in address consumption as contributed by the HD Ratio allocation metric. The unadvertised address ratio is then derived from this higher advertised address count, and this, in turn, generates a more rapid overall address consumption model. The measure under investigation in this case is the change in predicted date of the exhaustion of the IANA unallocated address pool 2. Results --------- The relative distribution of allocated prefixes by the RIPE NCC using an HD Ratio of 0.96 as an allocation efficiency metric would be as shown in Table 4. ---------------------------------------------------------------- Table 4 - RIPE NCC IPV4 Address Allocations Size 2000-2006 HD Ratio Relative Relative Frequency Frequency /24 23.04 23.23 /23 12.09 11.37 /22 8.16 7.87 /21 4.76 4.85 /20 19.64 16.33 /19 14.97 15.21 /18 6.85 8.58 /17 3.56 4.39 /16 4.36 3.88 /15 1.18 2.39 /14 0.66 0.86 /13 0.38 0.50 /12 0.18 0.28 /11 0.13 0.15 /10 0.03 0.09 /9 0.00 0.02 /8 0.00 0.00 ---------------------------------------------------------------- From the simulations of registry allocations, the use of an HD Ratio of 0.96 for IPv4 address allocations made by the RIPE NCC is predicted to increase total address consumption by 46% over the existing flat 80% utilization allocation policy framework. The current prediction for the data of exhaustion of the IANA unallocated address pool is 12 January 2012, assuming, among other factors, a continued application of the constant 80% address utilization metric. If the RIPE NCC were to adopt an allocation policy of using an HD Ratio of 0.96 to access IPv4 address allocations, and no other changes were made to the mode, and no other RIRs were to adopt such a policy to use the HS Ratio as a utilization metric, then the impact on the predicted exhaustion date is an overall change in address consumption rates by approximately 17% (as the RIPE NCC is responsible for some 38% of all allocated IPv4 addresses), and a predicted unallocated IANA pool exhaustion date of 9 December 2010 under these conditions (or approximately 1 year earlier than the predictions using the current address allocation policy framework A related consideration is that of the adoption of such a policy proposal by all 5 RIRs. If this were the case, and the adoption of this policy was to be effective immediately, then the relative increase in overall address consumption for each RIR would be: Afrinic 39%, APNIC 47%, ARIN 46%, LACNIC 47%. The simulation of IPv4 address consumption under these conditions predicts that the IANA pool of unallocated addresses would be exhausted by 22 March 2010 (or approximately 2 years earlier than the predictions using the current address allocation policy framework). -------------------------------------------------- At 05:34 PM 21/02/2006, Geoff Huston wrote: >Hi, > >I was wondering if it would help to look at the potential impact of this policy on IPv4 address consumption predictions. I have built a model of projection IPv4 address consumption based on continuity of current address allocation policies <http://ipv4.potaroo.net>http://ipv4.potaroo.net, and it may be useful to look at the impact of using the HD ratio on this model. I'll try and get some results posted by the end of this week on a simulation of the effects of adoption of this policy proposal > >thanks, > > Geoff > > > > >On 2/7/06, RIPE NCC Policy Coordinator <<mailto:adrian@ripe.net>adrian(a)ripe.net> wrote: >PDP Number: 2005-01 >HD-ratio Proposal > >Dear Colleagues > >The proposal to change to RIPE Document ripe-324 is now at its final stage. > >You can find the full proposal at: > > <http://www.ripe.net/ripe/policies/proposals/2005-1.html>http://www.ripe.net/ripe/policies/proposals/2005-1.html > >Please e-mail any final comments about this proposal to <mailto:address-policy-wg@ripe.net>address-policy-wg(a)ripe.net before 7 March 2006. > >We will publish the new policy after this date if we receive no objections. > >Regards > >Adrian Bedford >RIPE NCC >

2 4

2005-01 Last Call for Comments (HD-ration Proposal)
by RIPE NCC Policy Coordinator 07 Feb '06

07 Feb '06

[apologies for duplicate e-mails] PDP Number: 2005-01 HD-ratio Proposal Dear Colleagues We have updated the proposal to change ripe-368 - "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region". The update reflects the changes made when ripe-368 recently replaced ripe-324. We have also updated the draft RIPE Document to remove an additional reference to the 80% rule. You can find the updated draft RIPE Document at: http://www.ripe.net/ripe/draft-documents/ipv4-policies-draft.html Regards Adrian Bedford RIPE NCC

1 0

Updated RIPE Document available
by Laura Cobley 06 Feb '06

06 Feb '06

[Apologies for duplicate e-mails.] Dear Colleagues, We are pleased to announce the publication of an updated RIPE Document. ripe-368 IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region. You can find this document at: http://www.ripe.net/ripe/docs/ipv4-policies.html We have removed the references to African registries. This is in accordance with policy proposal 2005-05 "Proposal to Remove Special African Policies From RIPE Policy Documents". Best Regards, Laura Cobley Registration Services RIPE NCC

1 0

(2005-01) HD-ratio proposal
by leo vegoda 02 Feb '06

02 Feb '06

Dear Colleagues, Proposal 2005-01 has been in discussion for a while. The RIPE NCC's René Wilhelm has done an analysis of its possible impact on the consumption of IPv4 address space. The analysis shows an increase in the number of IPv4 addresses allocated. Details of the analysis are available on our web site at: http://www.ripe.net/ripe/policies/proposals/comments/impact_of_hd.html Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

3 2

2005-09 New Draft Document Published (IANA Policy for Allocation of IPv6 Blocks to RIRs)
by RIPE NCC Policy Coordinator 01 Feb '06

01 Feb '06

PDP Number: 2005-09 Internet Assigned Numbers Authority (IANA) Policy for Allocation of IPv6 Blocks to Regional Internet Registries Dear Colleagues We have published a draft document for the proposal described in 2005-09. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-09.html We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 27 February 2006. Regards Adrian Bedford RIPE NCC

2 1

2005-02 Draft Document will be produced (IP Assignments for anycasting DNS)
by RIPE NCC Policy Coordinator 26 Jan '06

26 Jan '06

PDP Number: 2005-02 IP Assignments for anycasting DNS Dear Colleagues The discussion period for the new RIPE Document described in 2005-02 has ended. A draft document will now be prepared for review. We will publish the document shortly. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-2.html Regards Adrian Bedford RIPE NCC

1 0

Policy Proposal Withdrawn - 2005-04
by RIPE NCC Policy Coordinator 24 Jan '06

24 Jan '06

Dear Colleagues PDP Number: 2005-04 IPv6 Address Allocation and Assignment Policy - Definition for "End-Site" The proposed change to RIPE Document ripe-267 has been withdrawn. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-4.html Regards Adrian Bedford RIPE NCC

1 0

200 customer requirements for IPv6
by Marc van Selm 18 Jan '06

18 Jan '06

Following up on the discussion during RIPE-51, I have not heard much discussion on "200 customer requirement for IPv6" rule. So I would like to hear your views on this. During RIPE-51 the proposal to remove the rule caught serious objections. I can sympathise with those but I do have an issue that I'd like feedback on. I am investigating how NATO should acquire IPv6 address space. NATO will use multiple transmission providers, NATO owned transmission and national networks. Also transmission contracts will have to be opened for bidding every few years. That makes requesting IP space from an ISP a non starter. So we explore the LIR route. Note that NATO has a service provider under its umbrella that provides service towards the other NATO organisations. They operate independently and are like an ISP (and more) for that matter. They are just not selling outside NATO. At this time it is reasonably hard to specify the 200 /48 that will be given out for the "IPv6 Initial Allocation Request". Having reached about 130 or so on my list (not finished yet) I can't help wondering why RIPE-NCC should care about a list of sites that they only a vague clue of what they are and have no means of verification if the list is correct. Having said that, I get the feeling that the 200 rule only ads admin overhead and has limited actual power. Now NATO could include a summarised version in the Initial Allocation and do something like: Subnet: /48 1 year 5 regional sites (/48 per site = 5x /48) Subnet: /48 1 year 20 subordinate sites to the 5 regional sites (/48 per site = 5x 20x /48 = 100 /48) Subnet: /48 2 year 40 deployed elements (/48 per site = 40x /48) Subnet: /48 2 year 70 Crisis Response Operation locations (/48 per location = 70 x /48) Total: 215x /48 Note that the numbers are fiction but they are not very unrealistic as we also need to include standby elements that are ready to go (power up, aim dish and run) systems. Although close to the truth, RIPE-NCC would have no way of verifying this and providing a detailed list would bury RIPE-NCC in details that they don't care about and also cannot verify. I can't help feeling this rule is written for ISPs but will be counter productive for NATO and organisations with a very large privately operated enterprice network. I also can't help the feeling that its a paper tiger. So isn't there another way to achieve the same result as this rule was intended for? Any views? Marc -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm(a)nc3a.nato.int (PGP capable)

23 75

FW: AfriNIC to start allocating from 41/8
by leo vegoda 18 Jan '06

18 Jan '06

Dear Colleagues, The announcement below is should be of interest. Regards, -- leo vegoda RIPE NCC Registration Services Manager -----Original Message----- From: afrinic-discuss-bounces(a)afrinic.net [mailto:afrinic-discuss-bounces@afrinic.net] On Behalf Of Ernest, B.M (AfriNIC - ZA) Sent: 16 January 2006 12:59 To: afrinic-discuss(a)afrinic.net Cc: ioz(a)internet.org.za; afnog(a)afnog.org Subject: [afrinic-discuss] AfriNIC to start allocating from 41/8 Dear Colleagues, As you may be aware, AfriNIC received a 41/8 block from IANA in April 2005. With effect from February 2006, all IPv4 address space allocated within the AfriNIC service region will be made from 41/8. The 196/8 block previously used for allocations in AfriNIC service region will now be used only for direct end-user (PI) assignments. This is therefore a notice that any filters you have may need appropriate adjustments. Kind regards, Ernest, AfriNIC. _______________________________________________ afrinic-discuss mailing list afrinic-discuss(a)afrinic.net http://lists.afrinic.net/mailman/listinfo.cgi/afrinic-discuss

1 0

ASO Call for Nominations for ICANN Board Seat
by Paul Rendek 06 Jan '06

06 Jan '06

[Apologies for duplicate e-mails] This message is sent on behalf of the Address Supporting Organization: Dear Colleagues, In compliance with the ASO MoU and ICANN bylaws the Address Council hereby calls for nominations to the ICANN Board to fill the ASO seat currently held by Mouhamet Diop, whose term expires in June of 2006. This nomination period will close on April 4, 2006. Nominations may be submitted by anyone by sending email to: nominations(a)aso.icann.org. Nominations must include the following information: • Full name of person being nominated • Contact email address for person being nominated • Contact telephone number (if available) of the person being nominated • Full name of the person making the nomination • Contact email address for the person making the nomination • Contact telephone number of the person making the nomination Nominations will be reviewed in accordance with the ASO Board of Directors selection procedures, as documented on the ASO website. ASO Secretariat http://www.aso.icann.org

1 0

RIPE 51 Report
by Nick Hyrka 05 Jan '06

05 Jan '06

[Apologies for duplicate e-mails.] RIPE 51 REPORT The RIPE 51 Meeting took place from 10 - 14 October 2005 at the Hotel Krasnapolsky, Amsterdam, the Netherlands. There were 320 attendees at the meeting. Attendees also included government representatives and representatives from AfriNIC, APNIC, ARIN, LACNIC and ICANN. Highlights of RIPE 51 included the announcement of the RIPE NCC E-learning Centre, a free online resource available to both members of the RIPE NCC and non-members. More information about the E-Learning Centre is available at: http://e-learning.ripe.net Global Crossing, the Amsterdam Internet Exchange, Force10 Networks and the RIPE NCC are thanked for the support they provided to the meeting. Global Voice Networks are thanked for the provision of the meeting Internet connectivity. PRESENTATIONS All the Plenary and Working Group presentations from RIPE 51 can be viewed at: http://www.ripe.net/ripe/meetings/ripe-51/presentations/index.html SUMMARY OF WORKING GROUP SESSIONS ADDRESS POLICY WORKING GROUP Action Points: The text for the policy proposals below will be reviewed by the following people, after concerns were raised by the working group: - #2005-02: TLD anycast allocation policy (Andreas Baess); - #2005-03: Removal of the 200 customer assignments requirement and referral to /48 assignments from the IPv6 initial allocation criteria (Andy Furnell); - #2005-04: IPv6 Address Allocation and Assignment Policy definition for end site (Eric Schmidt); - #2005-08: Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy (Geoff Huston and Kurtis Lindqvist). The working group chairs will set deadlines for discussion after these reviews. Highlights: The working group discussed the six policy proposals that are currently ongoing. The list of current proposals can be seen at: http://www.ripe.net/ripe/policies/proposals/ The working group agreed that a session should be scheduled at a future RIPE Meeting to discuss what mechanisms the community needs for a working Internet after the exhaustion of IPv4 address space. ANTI-SPAM WORKING GROUP Action Points: - Rodney Tillotson: Submit LINX BCP as a revised ripe-206 using the Policy Development Process (PDP). Highlights: - The document on which ripe-206 is based has been updated, and ripe-206 will be revised. - Greylisting discussion showed some consider it harmful, and some use it. - DKIM is an up-and-coming authentication technique. DATABASE WORKING GROUP Action Points: - RIPE NCC: Change the behaviour of the RIPE Whois Database server to return IRT objects by default. - RIPE NCC: Contact anti-spam tool writers to make them aware of the default behaviour change regarding IRT objects. - Peter Koch: Start a Policy Development Process to deprecate CRYPT-PW authorisation in the RIPE Whois Database. - RIPE NCC: Write a document describing the use of the IRT object in the RIPE Whois Database. - Wilfried Woeber: Start a Policy Development Process proposal to make the "country:" attribute in inet(6)num object optional and multiple. - RIPE NCC: Check Gnu Privacy Guard (GnuPG) compatibility before implementing changes to the RIPE Whois Database to prevent replay attacks. - RIPE NCC: Check if contacts can be properly mapped in IRIS (admin-c and tech-c). - RIPE NCC: Check what are other missing attributes in IRIS that are needed for the RIPE community. - Matt Rowley (ARIN): Check if other Routing Registries support RPSLng. - RIPE NCC: Implement the proposed DNSSEC changes. Highlights: - It was noted that there is an ongoing effort for improving documentation regarding the RIPE Whois Database. - It was noted that IRIS prototype server is now implemented and run by the RIPE NCC. DNS WORKING GROUP Action Points: - 51.1 RIPE NCC/Andrei Robachevsky: Agree with RIRs on a date for decommissioning of IP6.INT reverse mapping services. Outline and communicate procedure to be followed based on the presentation made during the working group session. - 51.2 Lars-Johan Liman: Draft a proposal on the future of the RIPE NCC Secondary DNS Service. To be dealt with in co-operation with the RIPE NCC Services Working Group. - 51.3 Peter Koch: Draft text and initiate discussion on the mailing list towards an update of ripe-203 along the lines of the presentation brought to the working group. - 51.4 Carsten Schiefner: Provide text for a proposal for the RIPE NCC to implement ENUM DNS predelegation checks. Also explore the field of regular post delegation sanity checks in the e164.arpa tree. Highlights: - Peter Koch announced that the Policy Proposal 2005-07, "Introducing DNSSEC Service to Reverse DNS Trees" had now completed its run through the formal Policy Proposal Process. As the DNS Working Group Chairs had received no formal objections to it, they declared consensus had been reached. The policy is now published as a RIPE Document: http://www.ripe.net/ripe/docs/ripe-359.html EIX WORKING GROUP Action Points: There were no actions from this working group. Highlights: - The minutes of the RIPE 50 EIX Working Group were approved. - There were 13 short IXP update presentations from EURO-IX, AMS-IX, DE-CIX, INEX, LINX, NDIX, LONAP, Netnod, NIX, NIX.CZ, SFINX, Terremark, VIX. - It was agreed that the as-set object is the appropriate object for showing members of internet exchanges on the RIPE Database. - There was a presentation by Mike Hughes from LINX about Voice over Internet Protocol (VoIP) peering. The presentation questioned people's assertions about the subject, and pointed out how the term had become somewhat overloaded. The presentation showed how VoIP peering affects IXPs, and what IXPs may want or not want to do in this area. ENUM WORKING GROUP Action Points: - RIPE NCC: Publish statistics from all e164.arpa servers. - Carsten Schiefner: Let the RIPE NCC know the details of missing links related to the indexation of requests. - RIPE NCC: Check whether the quarterly reports to the Internet Architecture Board (IAB) on ENUM operations are still necessary. - Peter Koch: Continue counting the reverse delegations in the 9.4.e164.arpa tree and report the results at RIPE 52. - Jim Reid: Stimulate discussion on testbed numbers/ranges. - Carsten Schiefner: Work with the RIPE NCC on ways to help improve the quality of DNS within the e164.arpa tree. - All: Help test Austria's ENUM reachability (see the message on the list). Highlights: - Work on ENUM-related IETF standards continues. - New deployment and operations statistics are being published. - Test activities are expanding. IPv6 WORKING GROUP Action Points: - 51.1 David Kessens: Ask the RIPE NCC to revise the acronym list in the registration package to remove obsolete terms as TLA & NLA Status: Completed - 51.2 RIPE NCC: Create a link from the IPv6 Working Group page to the APNIC events page: http://apnic.net/info/calendar/index.html Status: To be done - 51.3 RIPE NCC: Provide traffic reports on IPv6 usage during the RIPE meetings. If available, data from earlier meetings will be made available as well. Status: To be done RIPE NCC SERVICES WORKING GROUP There were no actions and highlights from this working group. ROUTING WORKING GROUP Action Points: - Philip Smith/Geoff Huston: Produce a document describing why route flap damping is harmful, and why ripe-229 no longer applies. Highlights: - There was discussion on route flap damping. It was agreed that ripe-229 on this subject is obsolete and should be replaced by a new document. It was agreed that this new document should describe why ISPs should not switch on flap damping in their routers, as well as explaining why and noting if there are any exceptions. - There was discussion on a possible Route Aggregation Policy. Joao will evaluate the feasibility of such a document together with some volunteers, including Mike Hughes and Philip Smith. - Arife Vural (RIPE NCC) presented an update on the status of the Routing Information Service (RIS) project. TEST TRAFFIC WORKING GROUP Action points: - RIPE NCC: Research the Multicast connectivity of the test-boxes. - All: Think about how to get more measurement nodes in TTM. Highlights: - Proposal to measure Multicast using TTM. - Consumer Broadband Measurements draft sent to the list and shortly discussed in the working group. - Discussion on how to measure DNSMON from more nodes worldwide. RIPE 51 WEBCASTING AND ARCHIVES During RIPE 51, the RIPE NCC collected feedback from participants watching the webcast and listening to the audiocasts. The mediums used for this were IRC and Jabber. Archives of presentations, webcasts and IRC/Jabber feedback from RIPE 51 are available at: http://www.ripe.net/ripe/meetings/ripe-51/sessions-archive.html RIPE NCC MEMBER SERVICES CENTRE The RIPE NCC Member Services Centre was introduced at RIPE 51 as a replacement to the Hostmaster Consultation Centre and enabled attendees to talk face-to-face with representatives from the RIPE NCC Registration Services, Finance, Training, Software Engineering and Technical Departments. "MEET & GREET" The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 51. "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 51 REFERENCE PAGE A complete list of RIPE 51 sessions and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-51 RIPE 52 RIPE 52 will be held in Istanbul, Turkey from 24 - 28 April 2006. More information on RIPE 52 will soon be available at: http://www.ripe.net/ripe/meetings/ripe-52/index.html If you have any questions about RIPE Meetings, please contact <meeting(a)ripe.net>.

1 0