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

Vízdal Aleš <ales.vizdal@t-mobile.cz> Fri, 14 July 2017 19:26 UTC

Return-Path: <ales.vizdal@t-mobile.cz>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1A6131897 for <dhcwg@ietfa.amsl.com>; Fri, 14 Jul 2017 12:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=t-mobile.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OF9fYUGoVgUn for <dhcwg@ietfa.amsl.com>; Fri, 14 Jul 2017 12:26:06 -0700 (PDT)
Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13686131457 for <dhcwg@ietf.org>; Fri, 14 Jul 2017 12:26:05 -0700 (PDT)
X-Hostname: ctxmailhub.t-mobile.cz
DKIM-Filter: OpenDKIM Filter v2.10.3 ctxmailhub.t-mobile.cz ED9A22E1E67
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=t-mobile.cz; 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: =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= <ales.vizdal@t-mobile.cz>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
CC: Ted Lemon <mellon@fugue.com>, dhcwg <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
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: <CC675F8E-BCA7-4937-8A26-A5CA227C56C8@t-mobile.cz>
References: <149869621720.6575.278128190348174876@ietfa.amsl.com> <08e4e953-3a68-d6cb-6066-f60514ef0ac5@gmail.com> <3285281858d043649d507b6bda7b8646@XCH-ALN-003.cisco.com> <1f94b780-59c1-42ce-936d-0c8a71143444@gmail.com> <37917a26062f4e4c9715d324604e4d01@XCH-ALN-003.cisco.com> <5fdc7054-7012-30ee-dec7-618f3cd3646f@gmail.com> <CAPt1N1=8Aibz0qWib=RiCr510i6DeGGZSOFNnWG0h-mguUzgqA@mail.gmail.com> <6f811cd2-61f1-05c2-1ede-b6933fa1dbb3@gmail.com> <CAPt1N1=0_U3en3zAJbO0fMxKv32iFYLcTVqn6bO5zm6XjT3+iQ@mail.gmail.com>, <0ea332fc-79a0-4ae9-50fc-465f2389157a@gmail.com>
In-Reply-To: <0ea332fc-79a0-4ae9-50fc-465f2389157a@gmail.com>
Accept-Language: en-GB, cs-CZ, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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: <https://mailarchive.ietf.org/arch/msg/dhcwg/_hTxYyYVCx0298XtujWyAdDnIpI>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jul 2017 19:26:09 -0000


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