Michel, There is not reason at all why what you stated could not be link-local addresses. I would argue if sensors do what I hear they will do link-locals are fine and we do have controls on that and they are not forwarded off the link. The cockpit and intra-connections could be viewed as on link easily. Access to the FAA or GPA Sat-Com would require global (hmm maybe inter-planetary scope :--)) and as in my previous mail those would be gateways to the sensors.
You may give good argument to not kill them yet but not sure against what Margaret proposed. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Michel Py [mailto:michel@;arneill-py.sacramento.ca.us] > Sent: Monday, October 28, 2002 5:46 PM > To: Margaret Wasserman; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: Limiting the Use of Site-Local > > > Margaret, > > > What would a light switch do differently to support site-local as > > opposed to global? It still needs to get a prefix from a > router and > > combine it with an IID using address autoconf. So, I don't > understand > > what system requirements could be eliminated by refusing > > to support global prefixes. > > There is a matter of _implementing_ system requirements, not > eliminating them. > > Let's talk about an airplane's IPv6 internal systems. There > will be a requirement that the rudder's embedded controller > reacts to site-local only, just in case a bozo mixes up > something. OTOH, the NAV computer does need to talk to the > outside word to extract weather or other in-flight dynamic > data and to report to ground. > > All that stuff is displayed simultaneously on the glass > cockpit CRTs, so at some point there is one computer in the > plane that has access simultaneously to external data and to > internal data. > > Now, explain me how you design that network (the plane) with > deprecating site-locals when global addresses are present. > Modern plane designs are multiple redundant networks that > carry data for almost all of the plane's devices. > > Michel. > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
