Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation

> On 14 Jul 2017, at 21:15, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
>
>> Le 14/07/2017 à 20:35, Ted Lemon a écrit :
>> So are the DHCP clients you are talking about setting the IP header hop count to 0/1, or the DHCP header hop-count field to 0/1?   That is, what is the behavior you are concerned about, and why do you think it might cause a problem in this case?
>
> Some clients I am talking about issue DHCP Solicit with Hop Limit field in the IPv6 base header (not DHCP UDP header) with value 1.
>
> This Solicit is sent on a cellular network.  The cellular network encapsulates at some point in IPv4, and further decapsulates.  The encapsulation protocol is called "GTPU" by some non-wireshark packet dump format, with fields like "TEID", "GTP_TPDU_MSG".  This cellular network does not offer IPv4 access to end user, it only offers IPv6.
>
> There is no GTP RFC.

GTP aka GPRS Tunnelling Protocol has been specified by 3GPP.

It starts at the eNodeB and terminates at the PGW where the DHCP server/relay would sit.

> There is an RFC for "Generic Packet Tunnelling in IPv6".  This RFC says that encap/decap decrements the Hop Limit.
>
> This raises a potential speculation that the network drops an incoming packet that has Hop Limit 1.
>
> It may be that the GTP encapsulation (no RFC) does not decrement the Hop Limit of a packet-to-be-encapsulated.  In this case there is no problem with DHCP Solicit having Hop Limit 1.

It shall keep the packet as-is, since it is not visible from user/data-plane point of view.
I suggest a deep dive into 3GPP specs ...

> Alex
>
>
>
>> On Fri, Jul 14, 2017 at 8:32 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote:
>>    Le 13/07/2017 à 23:14, Ted Lemon a écrit :
>>        On Jul 13, 2017 16:01, "Alexandre Petrescu"
>>        <alexandre.petrescu@gmail.com
>>        <mailto:alexandre.petrescu@gmail.com>
>>        <mailto:alexandre.petrescu@gmail.com
>>        <mailto:alexandre.petrescu@gmail.com>>> wrote:
>>             My oppinion is to make DHCP spec Hop Limit > 1.  In order
>>        to make sure
>>             that the encap/decap of DHCP Solicit in IPv4 GTP happening
>>        on a cellular
>>             link does not drop it to 0 upon decap.
>>        If a link local sourced multicast with a hop limit of one is
>>        dropped between sender and receiver, ip is broken on that link,
>>        ne c'est pas?
>>    If that link is a real link then yes - ip is broken on that link.
>>    But if the link is a virtual link - like when on a tunnel - then it
>>    may be that tunnel works or no.
>>    Alex
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

Zásady komunikace, které společnost T-Mobile Czech Republic a.s. užívá při sjednávání smluv, jsou uvedeny zde<http://www.t-mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_cz.pdf>. Není-li v zásadách uvedeno jinak, nepředstavuje tato zpráva konečný návrh na uzavření či změnu smlouvy ani přijetí takového návrhu. The communication principles which T-Mobile Czech Republic a.s. applies when negotiating contracts are defined here<http://www.t-mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_en.pdf>. Unless otherwise stated in the principles, this message does not constitute the final offer to contract or an amendment of a contract or acceptance of such offer.