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

RE: Question
by Bound, Jim 24 Apr '06

24 Apr '06

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 > >

15 25

Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive
by Thomas Narten 22 Apr '06

22 Apr '06

"Stephen Sprunk" <stephen(a)sprunk.org> writes: > OTOH, it's ridiculously easy to get PIv4 space today (512 hosts and two > pipes or tunnels), and there's not all that many companies doing it. It's > not growing much either. The doors are already wide open for a land rush > and nobody is taking ARIN up on it. Why does everyone assume it'll happen > with v6 if it's not happening with v4, which _is_ useful today? Because today, people are a lot more network savvy, and they now understand the potential value of getting real PI space. Moreover, anyone who understands history, realizes that getting PI space may become harder in the future, rather than easier. Consequently, it would be a smart business move to get PI space ASAP, in case the rules change down the road. i.e, a rather prudent investment. Thomas

3 2

Re: HD-ratio Proposal - Last Call has ended. Cosensus not reached.
by Hans Petter Holen 20 Apr '06

20 Apr '06

RIPE NCC Policy Coordinator wrote: > PDP Number: 2005-01 > HD-ratio Proposal > > Dear Hans Petter > > This is to remind you that the "Last Call" period for the proposed > change to RIPE Document ripe-368 has ended. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2005-1.html > > Please reply to this e-mail to let me know how you would like to proceed. > > * Consensus has been reached. We should publish the policy. > > * Consensus has not been reached. You want to > > * withdraw the policy; > > * return to the review phase (please tell us what duration to set for > the review period); or > The chairs of the Address policy working group have consulted and are divided on the matter of this policy. The outcome of this discussion and consultation with wg-chairs and RIPE Chair in general is that we see a clear consensus in favor of the current proposal. We do see a growing opposition based on the perception of how this will influence future address allocations to emerging regions. I will therefor return the policy to the review phase, for further discussion on the mailing-list and on the upcoming RIPE meeting. As a side note the matter of how RIPE should relate to other organizations in our policy making process I would like to make the following remark; RIPE policy is made by individual contributions to mailing lists and at RIPE meetings. Not by meetings of other organizations. Our discussions should be based on technical arguments in the relevant RIPE fora. Best Regards, Hans Petter Holen Address Policy Chair

2 2

New Document available: RIPE-376
by RIPE NCC Document Announcement Service 20 Apr '06

20 Apr '06

<<< our apologies for duplicate e-mails >>> New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-376 Title: Assigned Numbers Authority (IANA) Policy for Allocation of IPv6 Blocks to Regional Internet Registries Author: AfriNIC APNIC ARIN LACNIC RIPE NCC Date: 19 April 2006 Format: PDF=10551 TXT=4280 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- This document describes the policy governing the allocation of IPv6 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements will be specified by appropriate agreements between ICANN and the NRO. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL: http://www.ripe.net/ripe/docs/ripe-376.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-376.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-376.txt plain text version Kind Regards, Jeroen Bet RIPE NCC Content Webmaster

1 0

2006-01 New Policy Proposal - PI IPv6 Assignments for End User Organisations
by RIPE NCC Policy Coordinator 20 Apr '06

20 Apr '06

PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations Dear Colleagues A new RIPE Policy has been proposed and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-01.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 18 May 2006. After this date, we will prepare a draft RIPE Document. We will let you know when this is available. Regards Adrian Bedford RIPE NCC

1 0

HD-ratio Proposal - Review Period Date Correction
by RIPE NCC Policy Coordinator 19 Apr '06

19 Apr '06

PDP Number: 2005-01 HD-ratio Proposal Dear Colleagues The Review Period for RIPE policy proposal 2005-01 has been extended until 17 May 2006. Please ignore the previous mail that gave a date of 10 May 2006. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-1.html We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards Adrian Bedford RIPE NCC

1 0

Proposal Accepted - IANA Policy for Allocation of IPv6 Blocks to RIRs
by RIPE NCC Policy Coordinator 19 Apr '06

19 Apr '06

RIPE PDP Number: 2005-09 Internet Assigned Numbers Authority (IANA) Policy for Allocation of IPv6 Blocks to Regional Internet Registries Dear Colleagues Consensus has been reached, and the proposal described in 2005-09 has been accepted by the RIPE community. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-09.html Thank you for your input. Regards Adrian Bedford RIPE NCC

1 0

2005-01 Review Period Extended Until 10 May 2006 (HD-ratio Proposal)
by RIPE NCC Policy Coordinator 19 Apr '06

19 Apr '06

PDP Number: 2005-01 HD-ratio Proposal Dear Colleagues The Review Period for the change to RIPE Document ripe-368 described in proposal 2005-01 has been extended until 10 May 2006 You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-1.html We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards Adrian Bedford RIPE NCC

1 0

Re: [ppml] PI addressing in IPv6 advances in ARIN
by JORDI PALET MARTINEZ 18 Apr '06

18 Apr '06

Hi all, My first idea was submitting a PI IPv6 policy proposal next Monday to RIPE and the rest of the regions, trying to get a consensus for a "global" policy on this, but as this thread is being followed up in several mail exploders, to avoid a long cross-posting, I think it will be better to start some discussion already in a mailing list which is global, and actually I think we have the right one ... global-v6(a)lists.apnic.net So, if you aren't subscribed in the global-v6(a)lists.apnic.net, and you're interested in this thread, please subscribe at http://mailman.apnic.net/mailman/listinfo/global-v6 If you're late because the Eastern, the archives are also available at http://www.apnic.net/mailing-lists/global-v6/ Regards, Jordi > De: JORDI PALET MARTINEZ <jordi.palet(a)consulintel.es> > Responder a: <jordi.palet(a)consulintel.es> > Fecha: Fri, 14 Apr 2006 13:39:07 +0200 > Para: "v6ops(a)ops.ietf.org" <v6ops(a)ops.ietf.org>, "ppml(a)arin.net" > <ppml(a)arin.net>, "shim6(a)psg.com" <shim6(a)psg.com> > Conversación: [ppml] PI addressing in IPv6 advances in ARIN > Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN > > Hi Owen, > > You said it: If somebody find the good solution, it will be attractive to > the people to go for it. Otherwise, you always have the chance to become an > LIR. My proposal actually is already considering this point and a way to > avoid a need for renumbering if that happens. > > I just want to make sure that we have a way-out if it becomes necessary, but > avoid a showstopper now. I think is it possible. > > I don't have a technical solution yet (and agree with your views on this in > the email below in general), but I'm confident we will have. If it will take > 4 years from now, or just 2, who knows, so my proposal is ensuring that we > have those 4 years+3 for allowing the people either to return the block, or > become an LIR and avoid renumbering an any changes in their network. > > By the way, it may happen, and I'm hoping so, that the technical solution > don't make necessary to return the PI block anymore, and in that case, we > will be even able to remove at that time the "temporarily" point in the > policy (if it becomes accepted). > > Regards, > Jordi > > > > >> De: Owen DeLong <owen(a)delong.com> >> Responder a: <owen(a)delong.com> >> Fecha: Fri, 14 Apr 2006 03:48:34 -0700 >> Para: <jordi.palet(a)consulintel.es>, "v6ops(a)ops.ietf.org" >> <v6ops(a)ops.ietf.org>, >> "ppml(a)arin.net" <ppml(a)arin.net>, "shim6(a)psg.com" <shim6(a)psg.com> >> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN >> >> >> >> --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ >> <jordi.palet(a)consulintel.es> wrote: >> >> [snip] >>> However, I want to balance this with the medium-long term implications >>> created in the routing table and with the time needed to build and deploy >>> a better technical solution (or several) which is accepted by the >>> community. >>> >> I think we first need to define what we consider a solution... See below. >> >>> So my proposal basically is about having PI now everywhere (once ARIN >>> adopt it, is unfair not having it in other regions), but those PI >>> allocations for multihoming should be temporary and those address blocks >>> returned to the RIRs some time (lets say 3 years) after the new technical >>> solution is declared as a valid one. >>> >> I would not actually support this idea. The whole point of having PI >> space is to have the addresses for a long-term. Having a timeframe for >> return would simply restore the same barrier to entry that existed >> prior to passing the policy. >> >> Other RIRs are free to implement whatever v6 PI policy they feel is >> appropriate for their region. I would support a globally standardized >> v6 PI policy along the lines of ARIN 2005-1. >> >> However, I would like to argue that if the new technical solution will >> benefit from the return of this address space, it is most likely not >> truly a solution, but, instead, another clever hack piled on top of >> the existing set of hacks. >> >> I suppose if someone found the magic bullet to make geotopological >> addressing really work, that might qualify. However, I have very low >> expectations in that area. >> >> Absent that, any true solution will involve making the size of the routing >> table independent of the number of PI (or even PA) blocks issued by >> the RIRs or will make the size of the routing table practically >> irrelevant. >> >> I know this isn't the easy solution, but, we need to look long and >> hard at the way we do things. I think that solving these problems >> is going to require a significant paradigm shift. Assuming that we >> can use IP addresses for both end system identification and for >> routing topology indicators is how we created this problem. I don't >> see solving it without breaking that assumption, at least at the >> interdomain level. >> >> >>> At this way, on the long-run, we will not have routing table implications, >>> but we allow now the people that want to move ahead only if they have a >>> multihoming solution doing so. >>> >> If you think there is a possible solution (a real solution, not just >> a hack that postpones the inevitable at the expense of usability >> like CIDR did), then I'd like to hear what you are thinking. >> >>> This 3-years time for getting a multihoming network back to the new >>> technical solution (once adopted) is enough time, I think (it could be >>> changed to 5 years if needed, or whatever), so nobody today see the >>> temporarily of the proposal as a showstopper to go for it now. >>> >> I think you underestimate the momentum and requirements of the modern >> enterprise if you believe that to be true. Any capability available >> in v4 that is not available on at least equal or better terms in v6 >> is a deterrent to v6 deployment. >> >> The ability to get permanent addresses which do not have to be returned >> when you switch providers or renumbered on a schedule determined by >> some external organization is a major example of such a capability. >> >> Owen >> >> >> -- >> If it wasn't crypto-signed, it probably didn't come from me. > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

2 1

Re: [address-policy-wg] Global IPv6 PI policy proposal
by JORDI PALET MARTINEZ 18 Apr '06

18 Apr '06

Hi Michael, I know is difficult to achieve, but I think is worth to try and at least try to make it as much close as possible if no way to make a single one. I'm in favor of the RIRs process but also in favor of trying to achieve global consensus, avoiding regional shopping, etc. In fact not trying to make it as much global and fair to all as possible, we could say otherwise that there is no reason to set policy by regions, but by country, or estate, etc., which I'm sure you don't agree. We need to understand the very high importance of the PI implications on a global level, which make a good candidate for a global policy, in my opinion. Regards, Jordi > De: <Michael.Dillon(a)btradianz.com> > Responder a: <Michael.Dillon(a)btradianz.com> > Fecha: Tue, 18 Apr 2006 13:09:26 +0100 > Para: <jordi.palet(a)consulintel.es> > CC: "address-policy-wg-admin(a)ripe.net" <address-policy-wg-admin(a)ripe.net>, > "global-v6(a)lists.apnic.net" <global-v6(a)lists.apnic.net> > Asunto: Re: [address-policy-wg] Global IPv6 PI policy proposal > >> Please, use global-v6(a)lists.apnic.net for inputs to this draft policy >> proposal, in order to avoid threads being split across multiple mail >> exploders in different regions. > > I strongly doubt that you will get anywhere with a global > policy proposal. There is a reason that RIRs set their > policies independently. The IPv6 policy was a special case > due to the need to create a new policy for a new type of > address. But from now on, the 5 RIRs are likely to continue > making local changes to policies and it is extremenly unlikely > for any global policy to survive the 5 RIRs intact. > > In fact, the concept of a global policy is in direct > contradiction with the bottom-up nature of the RIRs. > > --Michael Dillon > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

1 0

IPv6 workshop in Istanbul
by JORDI PALET MARTINEZ 18 Apr '06

18 Apr '06

Hi all, Sponsored by ISOC, there will be an IPv6 workshop next Friday 28th afternoon in Istanbul, right after the RIPE lunch. The workshop is intended for those that don't have IPv6 knowledge. More information and registration: http://www.ipv6tf.org/ipv6_istanbul_isoc.php Please, forward this to your colleagues and other people that may be interested in participating. Thanks ! Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

1 0

RE: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN]
by Bound, Jim 17 Apr '06

17 Apr '06

The IETF has NOTHING to say anymore than any other body about any RIR policy. I want it to remain that way. IETF job is a standards body not a deployment body. /jim > -----Original Message----- > From: owner-shim6(a)psg.com [mailto:owner-shim6@psg.com] On > Behalf Of Iljitsch van Beijnum > Sent: Sunday, April 16, 2006 3:18 AM > To: Patrick W. Gilmore > Cc: shim6-wg; ppml(a)arin.net; global-v6(a)lists.apnic.net; IETF > Discussion; address-policy-wg(a)ripe.net; v6ops(a)ops.ietf.org > Subject: Re: [narten(a)us.ibm.com: PI addressing in IPv6 > advances in ARIN] > > On 16-apr-2006, at 6:09, Patrick W. Gilmore wrote: > > > Wow, Iljitsch, I have never lost so much respect so quickly for > > someone who was not flaming a specific person or using profanity. > > Congratulations. > > Well, that's too bad. But several years of trying to get a > scalable multihoming off the ground (flying to different > meetings on my own > dime) where first my ideas about PI aggregation are rejected > within the IETF mostly without due consideration because it > involves the taboo word "geography" only to see the next best > thing being rejected by people who, as far as I can tell, > lack a view of the big picture, is enough to make me lose my > cool. Just a little. > > > Back on topic, it is not just those 60 people - the "playground" > > appears to overwhelmingly agree with their position. I know I do. > > Don't you think it's strange that the views within ARIN are > so radically different than those within the IETF? Sure, > inside the IETF there are also people who think PI in IPv6 > won't be a problem, but it's not the majority (as far as I > can tell) and certainly not anything close to 90%. Now the > IETF process isn't perfect, as many things depend on whether > people feel like actually doing something. > But many of the best and the brightest in the IETF have been > around for some time in multi6 and really looked at the > problem. Many, if not most, of them concluded that we need > something better than IPv4 practices to make IPv6 last as > long as we need it to last. Do you think all of them were wrong? > > > I am sorry your technical arguments have not persuaded us > in the past. > > But I would urge you to stick to those, > > Stay tuned. > >

3 2

RE: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN]
by Bound, Jim 17 Apr '06

17 Apr '06

I agree. /jim > -----Original Message----- > From: owner-shim6(a)psg.com [mailto:owner-shim6@psg.com] On > Behalf Of Patrick W. Gilmore > Sent: Sunday, April 16, 2006 12:10 AM > To: Iljitsch van Beijnum > Cc: Patrick W. Gilmore; shim6-wg; ppml(a)arin.net; > global-v6(a)lists.apnic.net; IETF Discussion; > address-policy-wg(a)ripe.net; v6ops(a)ops.ietf.org > Subject: Re: [narten(a)us.ibm.com: PI addressing in IPv6 > advances in ARIN] > > On Apr 14, 2006, at 11:07 AM, Iljitsch van Beijnum wrote: > > > On 14-apr-2006, at 16:57, Scott Leibrand wrote: > > > >> 60 voted in favor of moving forward with PI. 6 voted against. > > > > Wow, 10 to 1. Amazing. > > > > Even more amazing: 60 people who represent nobody but their own > > paycheck get to blow up the internet. > > > > Where is ICANN when you need it? This little experiment in > playground > > democracy has to end before people get hurt. > > Wow, Iljitsch, I have never lost so much respect so quickly for > someone who was not flaming a specific person or using profanity. > Congratulations. > > > Back on topic, it is not just those 60 people - the "playground" > appears to overwhelmingly agree with their position. I know I do. > > I am sorry your technical arguments have not persuaded us in > the past. But I would urge you to stick to those, or at > least consider why we remain unconvinced, rather than devolve > into .. whatever that post was supposed to be. > > -- > TTFN, > patrick > >

1 0

Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN]
by Iljitsch van Beijnum 16 Apr '06

16 Apr '06

On 14-apr-2006, at 16:57, Scott Leibrand wrote: > 60 voted in favor of moving forward with PI. 6 voted against. Wow, 10 to 1. Amazing. Even more amazing: 60 people who represent nobody but their own paycheck get to blow up the internet. Where is ICANN when you need it? This little experiment in playground democracy has to end before people get hurt.

6 7

DRAFT agenda for RIPE 52 address policy WG meeting
by Gert Doering 16 Apr '06

16 Apr '06

Hi APWG folks, here's a first draft of an agenda for the RIPE52 address policy meeting in Istanbul in two weeks. Please send me your comments pretty quickly, as we need to hand in the agenda for printing next Tuesday. Gert Doering -- NetMaster --------------------------- snip ------------------------- A. Administrative Matters - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 51: http://www.ripe.net/ripe/wg/address-policy/r51-minutes.html <has this already been circulated for comments?> B. Policy proposal overview (of address policy WG proposals) - Filiz Yilmaz - 2005-02 IP assignments for anycast DNS (OPEN) - 2005-03 IPv6 initial allocation criteria (Discussion) - 2005-08 Amend IPv6 assignment and utilization requirements (Open) - 2005-12 4-byte AS number policy (Open) - 2005-01 HD-Ratio proposal (concluding) - 2005-09 IPv6 IANA->RIR distribution policy (consensus) C. discussion on existing proposals that are not yet closed D. necessary steps to conclude 2005-09 E. ongoing policy work in other regions * presentation in the plenary * plus discussion time in the WG slot F. IPv6 PI policy - ongoing work in other regions * presentation about the ARIN IPv6 PI policy in the plenary (http://www.arin.net/policy/proposals/2005_1.html= * plus discussion time in the WG slot (Jordi Palet) Z. AOB -- Total number of prefixes smaller than registry allocations: 88685 SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

1 0

Global IPv6 PI policy proposal
by JORDI PALET MARTINEZ 14 Apr '06

14 Apr '06

Please, use global-v6(a)lists.apnic.net for inputs to this draft policy proposal, in order to avoid threads being split across multiple mail exploders in different regions. 1. Number: (The RIPE NCC will assign this) 2. Policy Proposal Name: Provider-Independent (PI) IPv6 Assignments for End-User-Organizations Note: We can use ³Portable IPv6 Assignments for End-User-Organizations² if that helps some folks to buy-in the proposal. 3. Author: a. name: Jordi Palet Martinez b. e-mail: jordi.palet(a)consulintel.es c. organisation: Consulintel 4. Proposal Version: 1.1 5. Submission Date: 17/4/2006 6. Suggested RIPE Working Group for discussion and publication: Address Policy 7. Proposal type: a. new, modify, or delete. NEW 8. Policy term: a. temporary, permanent, or renewable. TEMPORARY 9. Summary of proposal: This policy is intended to provide a solution for organizations that have a need for provider independent assignments in IPv6. Typically those organizations will require the provider independent assignment in order to be able to become multihomed in a similar fashion as today is done for IPv4, but other reasons are also foreseen. For example some organizations aren¹t multihomed, but still require being globally routable with stable addressing (avoiding renumbering if they change the upstream provider) and in those cases (reasons behind may be administrative, policy, security, etc.) it seems that no other solution than provider independence is feasible, at least by now. Considering the foreseen consequences in the medium/long-term of this policy in the routing tables, this policy proposes an expiry date of 3 years once a technically correct alternative valid and deployable solution becomes accepted by the community. After that sunset period, the assignments done for multihoming purposes should be reclaimed and this policy should be modified to still allow assignments that could be required for purposes different than multhoming. At the sunset, the organizations that want to avoid renumbering and qualify to become an LIR, will be able to opt for that solution and they will get allocated the same prefix. 10. Policy text: a. Current (if modify): b. New: Provider-Independent IPv6 assignment to End-User-Organizations Qualification for an IPv6 Provider-Independent assignment: To qualify for a direct assignment, the organization must not be an IPv6 LIR and must qualify for an IPv4 assignment or allocation from RIPE NCC under the actual IPv4 policy. This is valid regardless of actually having being assigned or allocated such an IPv4 block. Provider-Independent IPv6 assignment size to End-User-Organizations: The minimum size of the assignment is /32. However a larger assignment can be provided if duly documented and justified. Subsequent assignment size to End-User-Organizations: Whenever possible, further assignments will be made from adjacent address blocks, but only if duly documented and justified. Assignment super-block: Those assignments shall be allocated from a separate super-block to allow for LIRs to filter them if required. Expiry for those assignments: In the case of assignments done under this proposal in order to address the multihoming issue, they will need to return the block in a maximum period of 3 years after a technically correct alternative valid and deployable solution becomes accepted by the community. Alternatively, to avoid renumbering, some of the organizations affected by this, could become an LIR, if they qualify for it. 11. Rationale: a. Arguments supporting the proposal In IPv4 there are organizations that qualify for an allocation for being PI, or could opt to be an LIR, either because they need to be multihomed or have other administrative or technical reasons to require a portable addressing block. This is not the case today for IPv6 and it is perceived as a clear barrier for deployment of IPv6 in some organizations, and is being addressed by this proposal by means of providing a direct assignment from RIPE NCC. These organizations are not allowed to make further assignments to other external organizations, but instead only to assign subnets internally within their own facilities. Assigning /32 will make those blocks to behave as other regular LIR-allocated ones and follow the generally accepted routing filtering practices, but at the same time being identifiable belonging to a special super-block. Also, it allows becoming an LIR, if that¹s the case, without requiring a renumbering. By setting up this policy, we avoid creating an unfairness situation among different regions and allow any organization that requires PI to access to it. All the organizations that opt for this PI, will be in the same fair situation once the technical solution is agreed and will have to either move to the new solution or become an LIR if they qualify. Newcomers will be in the same situation. Organizations that don¹t opt to PI with this policy is because they don¹t need it, so they aren¹t put in an unfair situation. Those that don¹t believe in possible alternative solutions and agree in going for a permanent PI policy instead, don¹t have valid reasons to oppose to this proposal, as the sunset will only enter into effect once that solution is agreed, so this proposal is not against their view. Some organizations my qualify to become an LIR now and avoid using this temporary assignment, but if their only reason to become an LIR is to get the PI block, then it seems better, looking in the long-term routing table size conservation, to go for this choice, which is more fair for the overall community. The ³temporarily² of this assignment must be understood as a long-term one, as we may expect those alternative solutions to be available possible in 3-4 years, which means that with the ³transition² period of 3 years, asking for a change in 6-7 years must not be considered as a pain. b. Arguments opposing the proposal The possible effect of this proposal is the grow of the routing tables to figures which, together with the existing (and forecasted) IPv4 routing entries, could create an important trouble to operators before vendors provide products with implement technical solutions, or even if those technical solutions exists, have an important impact in the cost or/and depreciation period for the infrastructure investments. This is the reason why the proposal provides already a fix sunset, but relative to the date where an alternative and technically correct solution is available and accepted as deployable by the community. Regarding the size of the assignment (/32), being a temporal one, should not be considered as a space waste, and instead be seen as an advantage in the sense of not requiring new special filters. Acknowledgments: I will like to acknowledge the inputs received for the first version of this proposal from Marcelo Bagnulo and Lea Roberts. ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

1 0

RE: [address-policy-wg] RE: Question
by Bound, Jim 14 Apr '06

14 Apr '06

Ray, Thanks for the response. IPv6 Forum does not have an organizational opinion at this time, we have evolved to a technical in depth body and try to avoid such positions unless it interferes with IPv6 deployment. I will take your response as an indirect NO the IETF does not have input to RIRs as a body either. My assumption, which I did not state previously, that the IETF is given any special treatment regarding your policy, was an invalid assumption on my part. So thanks for clearing that up. We have taken this discussion offline to persons who want to continue the analysis discussion. Thank You, /jim > -----Original Message----- > From: Ray Plzak [mailto:plzak@arin.net] > Sent: Thursday, April 13, 2006 8:46 AM > To: Bound, Jim; 'Latif Ladid ("The New Internet based on > IPv6")'; '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: [address-policy-wg] RE: Question > > Jim, > > Regarding direction, ARIN staff implements policies that have > reached community consensus as determined by the ARIN > Advisory Council and as ratified by the Board of Trustees. In > one sense, ARIN works like the IETF in that it is individuals > who contribute to the discussion. An organization is one > voice and is not viewed as representative of its members from > the standpoint of numbers. You are correct. This does not > preclude someone representative of the IPv6 Forum from making > a statement on either the ppml or at a meeting on behalf of > the Forum. One last point, if the Forum feels that the > community is developing policy that is harmful then the Forum > should certainly make a statement, more importantly, its > individual members should become active voices in the > discussion. There are a lot of voices in the IPv6 discussions > but the discussion could be much more robust if those of the > Forum were included. > > Ray > > > -----Original Message----- > > From: Bound, Jim [mailto:Jim.Bound@hp.com] > > Sent: Tuesday, April 11, 2006 9:30 AM > > To: Ray Plzak; Latif Ladid ("The New Internet based on IPv6"); 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; Bound, Jim > > Subject: RE: [address-policy-wg] RE: Question > > > > Ray, So you don't take IETF direction but only from > individuals in the > > IETF? Just want this to be clarified very clearly. This also does > > not preclude the IPv6 Forum stating a public position on the issue > > whether RIRs react to it or not. Not that will happen but > it could if > > the pain is strong enough to prohibit IPv6 deployment. > > > > Thanks > > /jim > > > > > -----Original Message----- > > > From: Ray Plzak [mailto:plzak@arin.net] > > > Sent: Monday, April 10, 2006 6:56 AM > > > To: 'Latif Ladid ("The New Internet based on IPv6")'; 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: [address-policy-wg] RE: Question > > > > > > The NAv6TF is in the ARIN region. If individuals > associated with it > > > think that ARIN should adopt a policy or change an > existing policy > > > they should not only say so they should propose such a policy. > > > Remember policies in the ARIN region, like in all of the RIRs is > > > made not by the RIR organization staff and board but by the > > > community in the region. ARIN staff will be more than > happy to help > > > anyone through the process, which by the way, while an > orderly and > > > formal process is not onerous, but one designed to provide for an > > > open and honest discussion of any policy proposal before it is > > > adopted. If you are interested in pursuing this, please > contact me > > > and I will get a staff member to assist you. > > > > > > Ray > > > > > > > -----Original Message----- > > > > From: address-policy-wg-admin(a)ripe.net > [mailto:address-policy-wg- > > > > admin(a)ripe.net] On Behalf Of Latif Ladid ("The New > Internet based > > > > on > > > > IPv6") > > > > Sent: Saturday, April 08, 2006 9: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: [address-policy-wg] 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: [address-policy-wg] RE: Question
by Bound, Jim 13 Apr '06

13 Apr '06

Ray, So you don't take IETF direction but only from individuals in the IETF? Just want this to be clarified very clearly. This also does not preclude the IPv6 Forum stating a public position on the issue whether RIRs react to it or not. Not that will happen but it could if the pain is strong enough to prohibit IPv6 deployment. Thanks /jim > -----Original Message----- > From: Ray Plzak [mailto:plzak@arin.net] > Sent: Monday, April 10, 2006 6:56 AM > To: 'Latif Ladid ("The New Internet based on IPv6")'; 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: [address-policy-wg] RE: Question > > The NAv6TF is in the ARIN region. If individuals associated > with it think that ARIN should adopt a policy or change an > existing policy they should not only say so they should > propose such a policy. Remember policies in the ARIN region, > like in all of the RIRs is made not by the RIR organization > staff and board but by the community in the region. ARIN > staff will be more than happy to help anyone through the > process, which by the way, while an orderly and formal > process is not onerous, but one designed to provide for an > open and honest discussion of any policy proposal before it > is adopted. If you are interested in pursuing this, please > contact me and I will get a staff member to assist you. > > Ray > > > -----Original Message----- > > From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg- > > admin(a)ripe.net] On Behalf Of Latif Ladid ("The New Internet based on > > IPv6") > > Sent: Saturday, April 08, 2006 9: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: [address-policy-wg] 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 > > > > > > > >

3 2

Re: Question - Aviation
by Thomas Narten 12 Apr '06

12 Apr '06

"Davis, Terry L" <terry.l.davis(a)boeing.com> writes: > 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, Note: in my mind "PI" space is closely associated with the notion of "being routed within the DFZ of the public internet". > 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. So, this type of network isn't connected directly to the internet and is thus not really part of the public internet (which makes sense to me). Thus, it is unclear to me that PI space is really needed for this. Seems to me, that all you really need is globally unique, unrouted (on the public internet) space. Would RFC 4193 "unique local addresses" satisify the need? And if your answer is "they are not unique enough", would centrally assigned ones, ala (expired) draft-ietf-ipv6-ula-central-00.txt meet your needs? (It would be ironic if you answered yes, because the topic of resurrecting this document came up during the discussion of http://www.arin.net/policy/proposals/2006_2.html at Tuesday's ARIN meeting). Thomas

2 1

Re: Question
by Thomas Narten 12 Apr '06

12 Apr '06

"Davis, Terry L" <terry.l.davis(a)boeing.com> writes: > 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? Yes. I spoke with one big ISP at the ARIN meeting that very clearly said "yes, people can and do multihome with PA space today". It turns out that not not everyone wants/needs PI space even though they multihome. Point is, there is spectrum of "requirements" out there. Multihoming does NOT immediately imply PI is a requirement. Thomas

2 1

RE: [address-policy-wg] RE: Question - Aviation
by Bound, Jim 11 Apr '06

11 Apr '06

Terry, I respectfully disagree closed networks can interfere with true end-to-end and end-to-end security, if not done very carefully with IPv6. Back at Digital we ran with global addresses (ok we had a Class A net 16) and implemented secure VPNs before they were popular in the late 80's and a form of IPsec with encryption. We had all the benefits of Firewalls just no "ADDRESS TRANSLATION". Your view of closed networks is far more dangerous than "potential" renumbering. Any network with globally routable addresses can be firewalled and protected it is not rocket science. But at the same time permits the end-to-end secure IP layer 3 model via IPsec as an option, which is the strongest security model we know of today from any cryptographer and black ops security analysts I speak with and quite often. This is also my position as SME (not HP) to the DOD per those furturistic networks for the GIG as one point of input to them . The only way to have global end-to-end which all enties should want is to have a pool of globally routable addresses and never use NAT again on the planet. That being said my view of Tony's proposal for PI space will not cause NAT but I want to be sure it is NAT bullet proof. Next to over abusive egoes/selfishness, elistism, and liars I think NAT is another great evil on the planet earth :--) (thats a joke ok). /jim > -----Original Message----- > From: Davis, Terry L [mailto:terry.l.davis@boeing.com] > Sent: Tuesday, April 11, 2006 10:02 AM > To: CERASI Eivan; 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: RE: [address-policy-wg] RE: Question - Aviation > > Eivan > > I don't think that I suggested changing anything that would > really impact you all. I just suggested the possibility of > formalizing the use of "closed networks" in my closing, I > would not expect it to impact you at all. > > Take care > Terry > > > -----Original Message----- > > From: CERASI Eivan [mailto:eivan.cerasi@eurocontrol.int] > > Sent: Tuesday, April 11, 2006 5:34 AM > > To: Davis, Terry L; 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: RE: [address-policy-wg] RE: Question - Aviation > > > > 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(a)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

RE: [address-policy-wg] RE: Question
by Green, David B RDECOM CERDEC STCD SRI 11 Apr '06

11 Apr '06

>From a technical standpoint, can't you multihome and use PA addresses for external comms and also create a numbering solution for provider independent internal numbering for critical systems by using RFC 4193 Unique Local IPv6 Unicast Addresses http://www.ietf.org/rfc/rfc4193.txt ? I thought this RFC was created to handle a provider independent internal numbering solution within a single routing domain (AKA North American Air Traffic Control) or other large critical operations enterprise. ~~~~~~~~~~~~~~~~~~~~ >From RFC 4193: Local IPv6 unicast addresses have the following characteristics: - Globally unique prefix (with high probability of uniqueness). - Well-known prefix to allow for easy filtering at site boundaries. - Allow sites to be combined or privately interconnected without creating any address conflicts or requiring renumbering of interfaces that use these prefixes. - Internet Service Provider independent and can be used for communications inside of a site without having any permanent or intermittent Internet connectivity. - If accidentally leaked outside of a site via routing or DNS, there is no conflict with any other addresses. - In practice, applications may treat these addresses like global scoped addresses. 4.2. Renumbering and Site Merging The use of Local IPv6 addresses in a site results in making communication that uses these addresses independent of renumbering a site's provider-based global addresses. When merging multiple sites, the addresses created with these prefixes are unlikely to need to be renumbered because all of the addresses have a high probability of being unique. Routes for each specific prefix would have to be configured to allow routing to work correctly between the formerly separate sites.` ~~~~~~~~~~~~~~~~~~~~~~ Does anyone have a technical analysis of how to multihome with RFC 4193 addresses as a PI address space? Can we combine this with multihomed global addresses to avoid a NAT-like trap that hurts the E2E model? Perhaps we need a MOONv6 experiment designed to test this as a PI space option? David Green US Army CERDEC Site Manager SRI International Office: (732) 532-6715 Mobile: (732) 693-6500

1 0

RE: Question - Aviation
by Bound, Jim 11 Apr '06

11 Apr '06

Thanks Terry. Good disagreement but I stand solid on my view. Note I did not say an address change would be transparent what I said is there should be legal binding methods that do not permit any RIR to disrupt any business. Meaning there would be no change that would affect production systems unless planned, that would prevent saftey issues. Regarding RIRs providing PI space I am soft against not hard liner. I do not want to see private addresses ever again on the Internet anywhere it prevents true end-to-end. I think we need to coordinate a time and place to have this debate and resulting effort discussed with all defending their views in person. Problem is we are all tapped with Travel now. Best, /jim > -----Original Message----- > From: Davis, Terry L [mailto:terry.l.davis@boeing.com] > Sent: Monday, April 10, 2006 4:13 PM > To: Bound, Jim; Tony Hain; PPML; address-policy-wg(a)ripe.net > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based > on IPv6"); 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 - 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 > > > > > > >

2 1

RE: [address-policy-wg] RE: Question
by Bound, Jim 11 Apr '06

11 Apr '06

Tony, Thank you very much. I am in China now (I think you are too?) and after tonight I probably won't be capable of to much mail till I get back to the U.S. Saturday. If we do have to do this then great and appreciate it and we can work with Terry and the CTO-EXCOM too. Thanks Again, /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Tuesday, April 11, 2006 10:17 AM > To: Bound, Jim; 'Ray Plzak'; 'Latif Ladid ("The New Internet > based on IPv6")'; '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: [address-policy-wg] RE: Question > > Jim, > > I will let Ray answer the question about individuals, but for > the purposes of this discussion I am willing to do the leg > work for any policy proposal that the task force thinks would > be helpful. As of yesterday's vote it is clear that the ARIN > AC will be working on the finishing touches for a basic PI > policy, and I am already working with Scott Leibrand and a > few others on a companion policy about how to manage the > designated PI block to minimize long term routing impact. > > Tony > > > > -----Original Message----- > > From: Bound, Jim [mailto:Jim.Bound@hp.com] > > Sent: Tuesday, April 11, 2006 6:30 AM > > To: Ray Plzak; Latif Ladid ("The New Internet based on IPv6"); 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; Bound, Jim > > Subject: RE: [address-policy-wg] RE: Question > > > > Ray, So you don't take IETF direction but only from > individuals in the > > IETF? Just want this to be clarified very clearly. This also does > > not preclude the IPv6 Forum stating a public position on the issue > > whether RIRs react to it or not. Not that will happen but > it could if > > the pain is strong enough to prohibit IPv6 deployment. > > > > Thanks > > /jim > > > > > -----Original Message----- > > > From: Ray Plzak [mailto:plzak@arin.net] > > > Sent: Monday, April 10, 2006 6:56 AM > > > To: 'Latif Ladid ("The New Internet based on IPv6")'; 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: [address-policy-wg] RE: Question > > > > > > The NAv6TF is in the ARIN region. If individuals > associated with it > > > think that ARIN should adopt a policy or change an > existing policy > > > they should not only say so they should propose such a policy. > > > Remember policies in the ARIN region, like in all of the RIRs is > > > made not by the RIR organization staff and board but by the > > > community in the region. ARIN staff will be more than > happy to help > > > anyone through the process, which by the way, while an > orderly and > > > formal process is not onerous, but one designed to provide for an > > > open and honest discussion of any policy proposal before it is > > > adopted. If you are interested in pursuing this, please > contact me > > > and I will get a staff member to assist you. > > > > > > Ray > > > > > > > -----Original Message----- > > > > From: address-policy-wg-admin(a)ripe.net > [mailto:address-policy-wg- > > > > admin(a)ripe.net] On Behalf Of Latif Ladid ("The New > Internet based > > > > on > > > > IPv6") > > > > Sent: Saturday, April 08, 2006 9: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: [address-policy-wg] 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: [address-policy-wg] RE: Question - Aviation
by Bound, Jim 11 Apr '06

11 Apr '06

I agree with Eivan bottom line too. At some point we need to bring in the actual U.S. FAA persons and I will go find out who that is that contribute directly from FAA. I have been working with FAA for 4 years and have participate in their Distinguished Lecture Series with U.S. DOD personnel, as CTO IPv6 Forum (not as HP), and have point of contact. FAA has also been reviewing IPv6 and it has been visible to the CIO manager levels and test beds were being created. Will get back to all. FAA will also be driven by the U.S. Whitehouse Enterprise Architecture requirements via OMB and IPv6 is one part of those mandates for Federal Agencies by 2008 at least for the network core of a federated agency network. Thanks /jim > -----Original Message----- > From: CERASI Eivan [mailto:eivan.cerasi@eurocontrol.int] > Sent: Tuesday, April 11, 2006 8:34 AM > To: Davis, Terry L; 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: RE: [address-policy-wg] RE: Question - Aviation > > 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. > > >

1 0