Re: [v6ops] draft-liu-v6ops-ula-usage-analysis

[joel jaeggli <[e-mail]>]

On 3/23/13 11:53 AM, Alexandru Petrescu wrote:
> Le 22/03/2013 16:26, Templin, Fred L a écrit :
>> Hi Merike,
>>
>>> -----Original Message----- From: Merike Kaeo
>>> [mailto:[e-mail]] Sent: Friday, March 22, 2013 2:43 AM To:
>>> joel jaeggli Cc: Templin, Fred L; Brian E Carpenter; Alexandru
>>> Petrescu; [e-mail] Subject: Re: [v6ops]
>>> draft-liu-v6ops-ula-usage-analysis
>>>
>>>
>>> On Mar 21, 2013, at 4:10 PM, joel jaeggli wrote:
>>>
>>>> On 3/21/13 3:46 PM, Templin, Fred L wrote:
>>>>>
>>>>>> -----Original Message----- From: [e-mail]
>>>>>> [mailto:[e-mail]] On Behalf
>>> Of
>>>>>> joel jaeggli Sent: Thursday, March 21, 2013 3:12 PM To: Brian
>>>>>> E Carpenter; Alexandru Petrescu Cc: [e-mail] Subject:
>>>>>> Re: [v6ops] draft-liu-v6ops-ula-usage-analysis
>>>>>>
>>>>>> On 3/21/13 7:10 AM, Brian E Carpenter wrote:
>>>>>>> On 21/03/2013 13:55, Alexandru Petrescu wrote: ...
>>>>>>>> A PI GUA for 2-3 Enterprises may work connected mostly
>>>>>>>> all the time
>>> at
>>>>>>>> the same 2-3 places.  But I think 1 billion PI GUAs
>>>>>>>> moving around
>>> the
>>>>>>>> Internet at the speed of 1 new connection/minute may not
>>>>>>>> work - it involves 'route churning', i.e. too many
>>>>>>>> routing protocol messages
>>> per
>>>>>>>> second and too large routing table entries.  Isnt't there
>>>>>>>> a risk
>>> like
>>>>>> that?
>>>>>>> Well, it was three or four orders of magnitude smaller, but
>>>>>>> there
>>> were a
>>>>>> lot
>>>>>>> of complaints about the churn produced by Connexion by
>>>>>>> Boeing, which
>>> was
>>>>>>> effectively a few hundred IPv4 PI prefixes moving around at
>>>>>>> almost
>>> Mach
>>>>>> 1. iirc there were complaints that it was a relatively bad
>>>>>> idea. there
>>> were
>>>>>> no complaints as far as I know due to impact of the rate of
>>>>>> prefix
>>> churn
>>>>>> which was way lower (by orders of magnitude) than the worst
>>>>>> offendors out there at the time. The prefix advertisement and
>>>>>> withdrawal was in fact done by the groundstatations not the
>>>>>> aircraft.
>>>>>>
>>>>>> There were never hundreds of of transcontinental commercial
>>>>>> aircraft engaged in  roaming on the service (there were
>>>>>> around 200 planes total with the equipment). There are many
>>>>>> more aircraft today operating with satellite or terrestrial
>>>>>> internet connectivity and without such
>>> behavior.
>>>>> This all happened before my time at Boeing, but my
>>>>> understanding is that someone noticed prefixes being announced
>>>>> and withdrawn due to aircraft mobility and brought the
>>>>> situation to light.
>>>> Ben Abarbanel from boeing presented it at nanog 31 yeah.
>>>>
>>>> http://www.nanog.org/meetings/nanog31/presentations/abarbanel.pdf
>>>>
>>>>
>>>>
> and about a year later at the ietf 62 technical plenary.
>>>>
>>>> some papers were published,  etc.
>>>>
>>>> http://quark.net/docs/Global_IP_Network_Mobility_using_BGP.pdf
>>>
>>> Connexion By Boeing peaked my interest since I worked for them and
>>> back in 2005/6 developed their IPv6 strategy plus configured the
>>> testbed ground stations to be dual- stacked (I had a /48 from
>>> Boeing's /32 PI routed by NTT....that caused quite the debates
>>> internal to NTT since at that time ISPs were still debating merits
>>> of doing so).    It was fun trying get the ISPs to tell me the
>>> real deal... "no, I don't want a tunnel I want a native eBGP
>>> connection and please route my /48".  How times change.
>>>
>>> I can definitively state that at that time with v6 there was going
>>> to be NO ULA usage although yes, there was routing churn that was
>>> disliked by ISPs but noone was actively saying it was causing
>>> *great harm*.  It was just very unsavory - hence the talks at NANOG
>>> and APRICOT and RIPE to explain and get more feedback. [and the
>>> folks building the routing had talked to some global ISPs before
>>> finally deciding on going that route]
>>>
>>> Of course using v6 routing at that time if we had gone live *could*
>>> have shown interesting global routing behavior :)
>>>
>>> It's unfortunate Connexion By Boeing went under....we were in
>>> process of moving to production test with v6 at the time (early
>>> 2006).    Although as Fred has stated, the system is still
>>> operational but for a very limited set of folks. Stuck in v4
>>> AFAIK.
>>
>> My understanding was that the service was picked up by Panasonic
>> eXConnect.
>
> This is good to know.  May I mention some commercial deployments of
> Wi-Fi in vehicles.
>
> Currently 'Wi-Fi is already in use aboard 1600 planes that fly over the
> United States' according to a recent respectable paper.  GoGo and OnAir
> as operators, and Boeing and Airbus as manufacturers.
>
> I have tried recently one Wi-Fi on-board of flight (gogo with a delta
> flight in US). It was NAT for the passengers and no IPv6.
>
> I have also tried recently Wi-Fi on board of the IETF shuttle bus in
> Orlando, and Wi-Fi on board of the Thalys train for Brussels. Both were
> NAT for passengers, and no IPv6.
>
> For the Thalys train I could notice handover of the train between 3G and
> WiFi in railway station, by checking the end-to-end RTT.
>
> When NAT IPv4 is used on-board of these vehicles, there is probably no
> routing churn (the onboard addresses are not propagated to the
> infrastructure), and probably little need for Mobile IP.
Connexion by boeing was also natted. the internal addressing was the 
same on every plane...

It is worth noting that mobility-wise, transcontinental aircraft using 
geostationary satellites are not  poster-children for mobility. On the 
timescales on which roaming occurs you can do all sorts of things that 
are familiar to 6renum/homenet people that don't involve moving pi /24s 
or /48s around.
> The on-board WiFi networks of vehicles would be candidates for using ULA
> addressing when migrating to IPv6.
I would think that they would be good candidates for 6296 style nptv6 
and what prefix is used on the inside is kind of not relevant.

My experience with ip speaking devices in aviation systems is that they 
get certifed for operation in a particular configuration which is likely 
consistent across the population of those devices.
> Alex
>
>>> As far as mobility scenarios - due to the routing churn issues in
>>> v4 I was following NEMO and other mobility scenarios to see how
>>> they might be utilized with v6.  Not sure where that went as I
>>> stopped following it.
>>
>> We have taken care of the routing churn issue with SEAL/VET/IRON:
>>
>> https://datatracker.ietf.org/doc/draft-templin-intarea-seal/
>> https://datatracker.ietf.org/doc/draft-templin-intarea-vet/
>> https://datatracker.ietf.org/doc/draft-templin-ironbis/
>>
>> Thanks - Fred [e-mail]
>>
>>> Whether you use ULA or GUA for mobility has no difference.  The
>>> issue comes in whether you have an entirely closed system (air
>>> traffic control and some other global mobile entities do) or
>>> whether you need to communicate to outside world.  The latter gets
>>> more interesting with ULAs.
>>>
>>> - merike
>>
>>
>