Hi Alex, > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] > Sent: Friday, June 12, 2015 8:53 AM > To: Templin, Fred L; Tony Hain; 'Jouni Korhonen'; dmm@ietf.org > Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s > > Hi Fred, > > Le 12/06/2015 17:24, Templin, Fred L a écrit : > > Hi Alex, > > > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] > >> Sent: Friday, June 12, 2015 6:03 AM > >> To: Templin, Fred L; Tony Hain; 'Jouni Korhonen'; dmm@ietf.org > >> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s > >> > >> > >> > >> Le 11/06/2015 18:53, Templin, Fred L a écrit : > >>> Responding to two in one: > >>> > >>>> -----Original Message----- From: dmm [mailto:dmm-boun...@ietf.org] > >>>> On Behalf Of Tony Hain Sent: Thursday, June 11, 2015 9:47 AM To: > >>>> 'Alexandru Petrescu'; 'Jouni Korhonen'; dmm@ietf.org Subject: Re: > >>>> [DMM] vepc draft Rev. 04 - /62s to UE, not /64s > >>>> > >>>> Alexandru Petrescu wrote: > >>>>> Le 11/06/2015 18:02, Jouni Korhonen a écrit : > >>>>>> > >>>>>> > >>>>>> 6/4/2015, 7:08 AM, Alexandru Petrescu kirjoitti: > >>>>>>> Le 04/06/2015 05:42, Templin, Fred L a écrit : > >>>>>>>> Hi Alex, > >>>>>>>> > >>>>>>>>> -----Original Message----- From: Alexandru Petrescu > >>>>>>>>> [mailto:alexandru.petre...@gmail.com] Sent: Wednesday, > >>>>>>>>> June 03, 2015 8:36 AM To: Templin, Fred L; Satoru > >>>>>>>>> Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 > >>>>>>>>> - /62s to UE, not /64s > >>>>>>>>> > >>>>>>>>> Le 29/05/2015 20:21, Templin, Fred L a écrit : > >>>>>>>>>> Hi Alex, > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- From: dmm > >>>>>>>>>>> [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru > >>>>>>>>>>> Petrescu Sent: Friday, May 29, 2015 10:59 AM To: > >>>>>>>>>>> Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc > >>>>>>>>>>> draft Rev. 04 - /62s to UE, not /64s > >>>>>>>>>>> > >>>>>>>>>>> Le 29/05/2015 15:30, Satoru Matsushima a écrit : > >>>>>>>>>>>> Ah OK. thanks. Slightly off-topic, I think that > >>>>>>>>>>>> there is still chance for tethering with single /64 > >>>>>>>>>>>> if it is allocated as a off-link prefix. > >>>>>>>>>>> > >>>>>>>>>>> Yes, there is still such a chance. But it can not > >>>>>>>>>>> tether more than one single subnet. Connected > >>>>>>>>>>> vehicles need several subnets. > >>>>>>>>>> > >>>>>>>>>> How would it be if the vehicle received a single > >>>>>>>>>> prefix, but it could be shorter than /64 (e.g., /56, > >>>>>>>>>> /48. etc.)? Would the vehicle subnetting be satisfied > >>>>>>>>>> if it received a shorter prefix from which many /64s > >>>>>>>>>> could be allocated? > >>>>>>>>> > >>>>>>>>> Certainly yes. > >>>>>>>>> > >>>>>>>>> Each vehicle needs such a shorter-than-64 prefix > >>>>>>>>> allocated to it. > >>>>>>>>> > >>>>>>>>> For example, an automobile connecting to LTE receives a > >>>>>>>>> /62 from the operator and makes four /64s out of it: one > >>>>>>>>> for its CAN-entertainment, one for its CAN-safety, one > >>>>>>>>> for its WiFi and one for its > >>>>> Bluetooth. > >>>>>>>>> > >>>>>>>>> This is a MUST. > >>>>>>>>> > >>>>>>>>> Allocating a single /64 to a vehicle can not accommodate > >>>>>>>>> all these unbridgeable subnets. > >>>>>>>> > >>>>>>>> OK, that is good. Giving a mobile router something shorter > >>>>>>>> than /64 should be no problem, at least up to practical > >>>>>>>> limitations of the prefix delegation authority's available > >>>>>>>> prefix space. DHCPv6 PD provides all that is needed to give > >>>>>>>> out right-sized prefixes. > >>>>>>> > >>>>>>> I agree DHCP-PD provides the necessary tool. But > >>>>>>> unfortunately the cellular operators have not deployed > >>>>>>> DHCPv6-PD (although yes there is some DHCP-non-PD in some > >>>>>>> IPv6/4G deployments). > >>>>>>> > >>>>>>> The common thinking at operators and advisers is still that a > >>>>>>> /64 should be given to an User Equipment. > >>>>>>> > >>>>>>> This must change: the 3GPP specs and operator deployments > >>>>>>> must give /62 to UEs, and not /64. > >>>>>> > >>>>>> I think we are not in the position to force operators or 3GPP > >>>>>> to do anything, unfortunately. The best we can do is to make > >>>>>> sure the protocols we work here in IETF are not prohibiting > >>>>>> better deployments (see e.g. RFC6603 effort). 3GPP specs are > >>>>>> not the show stoppers here. > >>>>>> > >>>>>> I know this is frustrating. For example some operators I know > >>>>>> offer IPv6 PD on their fixed side of business but have no plans > >>>>>> for similar on the cellular side.. reasons are many. I assume > >>>>>> that identofying a strong enough use case would be the key. > >>>>> > >>>>> I would like to discuss these use cases. > >>>>> > >>>>> Use cases of grouping devices under a unique cellular connection > >>>>> are very numerous: IPv6 automobiles, IPv6 tethering smartphones, > >>>>> IPv6 Things on Personal Area Networks. > >>> > >>> Yes, yes and yes. Also IPv6 airplanes. > >> > >> What is the use case when an airplane connects to a cellular operator? > >> They are supposed to be on sattelite often, I guess. > > > > Airplanes have lots of links - some satellite yes, but there are also > > cellular link types such as this: > > > > http://aircell.com/ > > That is a cellular link on-board of a plane, I think. Maybe it requires > a shorter-than-64 prefix from the satellite operator...
Last I checked, Gogo/Aircell is based on a cellular ground network and gives passengers on board an Internet-capable WiFi service. Aircell also offers satcom services including Inmarsat and Iridium, but I was referring to the ground-based cellular network. > But is there a use-case with plane that connects to a cellular network > while taxiing ? I.e. slow speed, spend 1hour on the tarmac, connect the > plane to Verizon, give passengers free WiFi to smartphones so use > Internet to announce safe landing. My understanding is that passenger-domain communications are only above 10Kft. However, Air Traffic Control domain has things like gatelink WiFi, AEROMACS, etc. in the terminal and ground domain area. Think of aircraft as having (at least) three distinct communication domains - Air Traffic Control (ATC), Airline Operations Control (AOC) and Passenger In-flight Entertainment (PIES). Obviously, the passenger domain needs to be kept separate from the safety-of-flight-critical domains. Thanks - Fred fred.l.temp...@boeing.com > This latter certainly requires a shorter-than-64 prefix from the > cellular operator. > > Alex > > > > > Thanks - Fred > > fred.l.temp...@boeing.com > > > >> Alex > >> > >>> > >>>>> All these devices need the cellular operator to deliver > >>>>> shorter-than-64 prefixes to a SIM connection. > >>>> > >>>> For lack of a better description, the cellular side of businesses > >>>> suffer from "bell head:" thinking, where the UE is an application > >>>> endpoint. Nothing more occurs to them, because that is the product > >>>> they have always supported. A routing function implies higher > >>>> aggregate data rates than they have built the system to handle. I > >>>> have been in front of many of them holding up UE and saying, "this > >>>> is a ROUTER, get over it", and got nothing but blank stares back. > >>> > >>> Indeed. But, this is the ongoing dialogue that we need to continue > >>> no matter how many blank stares we get. > >>> > >>> Thanks - Fred fred.l.temp...@boeing.com > >>> > >>>> The first use case on the list should be a wireline > >>>> alternative/backup link for consumer CPE routers, and home control > >>>> or security systems. That is simpler to support because the UE > >>>> doesn't move around, so they can scale the infrastructure to align > >>>> with demand without too much concern about that shifting quickly. > >>>> Once the fear of downstream subnets is removed, working on the > >>>> truly mobile use cases will be an easier mental hurdle to > >>>> overcome. > >>>> > >>>> Tony > >>>> > >>>> ........... > >>>> > >>>> _______________________________________________ dmm mailing list > >>>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
