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

Vízdal Aleš <> Fri, 14 July 2017 19:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD1A6131897 for <>; Fri, 14 Jul 2017 12:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OF9fYUGoVgUn for <>; Fri, 14 Jul 2017 12:26:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 13686131457 for <>; Fri, 14 Jul 2017 12:26:05 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 ED9A22E1E67
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim2016; t=1500060361; bh=Y+pZKsDiQJ+LlRkLVRvqy28SGH5Q4c5oiSPBgl63Mtc=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Se2HOYFTiS2UZ0CPbR4hkQylG9z6ynQD1qyBf2N1dv93sUQccjQgrZmiGQQM/lDj7 Si/dUOt5Uk6wlAulDYLfoM/TnhlyBX8MPMKDkumRN3Lcs5c3oJMDkiwYpnMtCZ10PY H/W1a+cHuLzLq210rsrOPjMp+32Jo+ZlvcUPnogvBei0Ci/M0HgLPxa1GMwF9EccDl wu6VVuf/CEu1LqsZ0NxYnKXHbs3+MNJRGQjFtk3xd3RVSGAhTdx8BkabjTNnkDQKlK aESo1wiiCoX9LTShAeFenktBGpOnxyv4pZBuZwTQ+Ef9Fd5nDB+kz6JtsoivUw9yus hNB2JGbOG/W0w==
From: Vízdal Aleš <>
To: Alexandre Petrescu <>
CC: Ted Lemon <>, dhcwg <>, "Bernie Volz (volz)" <>
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation
Thread-Index: AQHS/M+G8BPWcnoA8ku2dlH89fUEWaJThLcAgAALPQCAACR7yw==
Date: Fri, 14 Jul 2017 19:26:01 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-GB, cs-CZ, en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forwarded
Archived-At: <>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Jul 2017 19:26:09 -0000

> On 14 Jul 2017, at 21:15, Alexandre Petrescu <> 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 < <>> wrote:
>>    Le 13/07/2017 à 23:14, Ted Lemon a écrit :
>>        On Jul 13, 2017 16:01, "Alexandre Petrescu"
>>        <
>>        <>
>>        <
>>        <>>> 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

Zásady komunikace, které společnost T-Mobile Czech Republic a.s. užívá při sjednávání smluv, jsou uvedeny zde<>. 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<>. 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.