Re: [dhcwg] DHCPv6 and IPv6ND

Le 16/11/2017 à 12:57, mohamed.boucadair@orange.com a écrit :
> Alex,
> 
> Actually, it seems that we are in agreement in almost all points :)
> 
> The question is how this group can help fixing the modem issue (or
> any other blocking filters that may be in-between clients and
> servers).

Maybe they can not.  But until that is fixed we can not talk about 
DHCPv6-and-IPv6ND on cellular networks.

And I dont see that fixing happening.

Alex

> 
> Cheers, Med
> 
>> -----Message d'origine----- De : Alexandru Petrescu
>> [mailto:alexandru.petrescu@gmail.com] Envoyé : jeudi 16 novembre
>> 2017 12:50 À : BOUCADAIR Mohamed IMT/OLN Cc : Ted Lemon; dhcwg;
>> Bernie Volz (volz) Objet : Re: [dhcwg] DHCPv6 and IPv6ND
>> 
>> Med,
>> 
>> Thank you for the reply.  I agree with some parts, but not with
>> others.
>> 
>> Le 16/11/2017 à 12:25, mohamed.boucadair@orange.com a écrit :
>>> Re-,
>>> 
>>> Please see inline.
>>> 
>>> Cheers, Med
>>> 
>>>> -----Message d'origine----- De : Alexandru Petrescu
>>>> [mailto:alexandru.petrescu@gmail.com] Envoyé : jeudi 16
>>>> novembre 2017 12:05 À : BOUCADAIR Mohamed IMT/OLN Cc : Ted
>>>> Lemon; dhcwg; Bernie Volz (volz) Objet : Re: [dhcwg] DHCPv6 and
>>>> IPv6ND
>>>> 
>>>> Med, Which part do you disagree with in my text?
>>>> 
>>>> I agree the problems are indeed implementation problems,
>>> 
>>> [Med] Cool.
>>> 
>>> but I need to
>>>> understand which part do you disagree?
>>>> 
>>> 
>>> [Med] I disagree that the spec needs to say that the port number
>>> is
>> variable. This should be left to implementers, if neede. BTW,
>> configuring a distinct port number will require that the client is
>> able to learn that alternate port. This will lead to more
>> interoperability problems than it solves.
>>> 
>>>> Do you disagree when I say that the entire issue about making
>>>> DHCPv6 work on 3GPP should be forgotten?
>>> 
>>> [Med] Prefix delegation can work easily in cellular networks if
>>> all
>> involved parties/implementers are following current specs. That
>> is:
>>> - The client uses the defined multicast address + service port
>>> when
>> issuing its solicit messages + supply prefix_exclude.
>>> - The server listens on the service port + does not make any
>>> assumption
>> about the source IP address + treat DUIDs as opaque values that are
>> only used to compare equality.
>> 
>> I think after all this time we can safely say that the
>> specification written above has never been experimented
>> successfully.
>> 
>> YEs, my ARM runs DHCPv6-PD with all the options that you required.
>> Yes, the operator DHCPv6 Server is running and configured to do PD
>> a /56. But no, the two have never performed a successful exchange.
>> 
>> The problem is in the middle - the modem.
>> 
>> It's not only me who says this.  Lorenzo complained about modems
>> and DHCPv6 several years ago.  Others on the v6ops WG agreed with
>> him.
>> 
>> Yes, they made a wrong assertion saying the operator does not
>> support DHCPv6: the operator _can_ do DHCPv6, and the assertion was
>> wrong.
>> 
>>> I'm aware that some messages are "blocked" by some chipset
>>> vendors, but
>> again this is an implementation issue.
>> 
>> I checked Qualcomm and Balong modems.  That represents quite a lot
>> of the installed base.
>> 
>> I will be happy to check others like Intel modems, but I dont know
>> how.
>> 
>> There is also a possibility that the specification that you write
>> above, and where you refer to involved parties: maybe it's a matter
>> between operator, implementers at router manufacturer and
>> implementers at modem manufacturer.  I do not represent any: just
>> implementer of open source.
>> 
>> A modem implementer has access to source code of the modem.
>> 
>> A router manufacturer implementer has access to source code of
>> router.
>> 
>> Alex
>> 
>>> I do agree with you it is frustrating.
>> 
>> Yes.
>> 
>> Alex
>> 
>>> 
>>> Or other part?
>>>> 
>>>> Alex
>>>> 
>>>> Le 16/11/2017 à 11:08, mohamed.boucadair@orange.com a écrit :
>>>>> Hi Alex,
>>>>> 
>>>>> I disagree.
>>>>> 
>>>>> The problems you are describing are implementation ones.
>>>>> 
>>>>> Cheers, Med
>>>>> 
>>>>>> -----Message d'origine----- De : dhcwg
>>>>>> [mailto:dhcwg-bounces@ietf.org] De la part de Alexandru 
>>>>>> Petrescu Envoyé : jeudi 16 novembre 2017 07:38 À : Ted
>>>>>> Lemon Cc : dhcwg; Bernie Volz (volz) Objet : Re: [dhcwg]
>>>>>> DHCPv6 and IPv6ND
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Le 16/11/2017 à 06:29, Ted Lemon a écrit :
>>>>>>> I'm having trouble figuring out how changing the port
>>>>>>> would help. You'd still have to make the same
>>>>>>> modifications.   You'd still have to define a business
>>>>>>> model.
>>>>>> 
>>>>>> _If_ there is a standard that says port number is variable,
>>>>>> and if hardware manufacturer implements it, then it will
>>>>>> help.
>>>>>> 
>>>>>> If not, not.
>>>>>> 
>>>>>> If so, this entire issue about making DHCPv6 work on 3GPP
>>>>>> networks should be forgotten.   It's impossible to make it
>>>>>> work.
>>>>>> 
>>>>>> That puts the discussion of DHCPv6 and IPv6ND outside the
>>>>>> 3GPP
>> context
>>>>>> altogether.
>>>>>> 
>>>>>> For the business model: I am not an economist.
>>>>>> 
>>>>>> Alex
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> _______________________________________________ dhcwg
>>>>>> mailing list dhcwg@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/dhcwg