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