[address-policy-wg] RE: Question - Aviation

["Davis, Terry L" <terry.l.davis@localhost]

Jim

On the private addressing, we are 100% in agreement.   At least myself,
I don't equate a "closed network" to anything resembling "private
addressing".

I like the idea of a face-to-face meeting hopefully with lots of white
board space.

Take care
Terry

> -----Original Message-----
> From: Bound, Jim [
	    
	    
]
> Sent: Tuesday, April 11, 2006 6:54 AM
> To: Davis, Terry L; Tony Hain; PPML; address-policy-wg@localhost
> Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on IPv6");
> ollivier.robert@localhost narten@localhost Brig, Michael P CIV
> DISA GES-E; Pouffary, Yanick; Green, David B RDECOM CERDEC STCD SRI;
Bound,
> Jim
> Subject: RE: Question - Aviation
> 
> 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 [
	    
	    
]
> > Sent: Monday, April 10, 2006 4:13 PM
> > To: Bound, Jim; Tony Hain; PPML; address-policy-wg@localhost
> > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based
> > on IPv6"); ollivier.robert@localhost narten@localhost
> > 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 [
	    
	    
]
> > > Sent: Saturday, April 08, 2006 5:52 AM
> > > To: Tony Hain; PPML; address-policy-wg@localhost
> > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based
> > on IPv6");
> > > Davis, Terry L; ollivier.robert@localhost narten@localhost
> > 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 [
	    
	    
]
> > > > Sent: Friday, April 07, 2006 7:57 PM
> > > > To: 'PPML'; address-policy-wg@localhost
> > > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The
> > New Internet
> > > > based on IPv6")'; 'Davis, Terry L';
> > ollivier.robert@localhost
> > > > narten@localhost '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
> > > >
> > > >
> >