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