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

Ted Lemon <mellon@fugue.com> Sat, 15 July 2017 04:37 UTC

Return-Path: <mellon@fugue.com>
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 7DAA812785F for <dhcwg@ietfa.amsl.com>; Fri, 14 Jul 2017 21:37:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 sPFylP9bjkfl for <dhcwg@ietfa.amsl.com>; Fri, 14 Jul 2017 21:37:02 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5332120725 for <dhcwg@ietf.org>; Fri, 14 Jul 2017 21:37:02 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id q85so53879646pfq.1 for <dhcwg@ietf.org>; Fri, 14 Jul 2017 21:37:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UQk9DTI9lMxqy46OOLZ+0x0WZBiZlw9KJde9rvOMthE=; b=z564pCJKGZdeh4KRMJb0jYTFwfMNrbOQwv8IS165q3sJYLf5psTqQ35/mSLtiR5+PI 9cz23v+cdj4PvMAaT+/5X2gtYEEBqXwiC8mv3/dCvfh73lGBJRsAJvRHKxwhOf5QyqxZ UauqqzWGE9aPHNz16UibZLDpzhS764881/mqE76u8EqpdzYnH/j61WnC5cLKRFWjrCvH JPkycHMvpCnqrhkNStztmKuaE4Q2n3Lsy8XbD6nZ/7P2A3Hbt1G0FgD1JjKdGvQqlLec QnWorZ621Jm9/Pef3ogH+ymDJAZ539AC4wcyZv8ds7/VcsIH1aS9dmiprEbl8vGjOkQF U5ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UQk9DTI9lMxqy46OOLZ+0x0WZBiZlw9KJde9rvOMthE=; b=RAtG0patTiUITR0AzuTPXMxIbsZL5MAM9BsDAlxgMlkRYHBDNkOyimD1z4vwVVdgJj Fw3UNLGTRRjB/MuC8GC2BM8Q2oRP0HbBcGgpA5OvsNCjwK68mqt90n76GoKei/P/1Hcx HlvVB0ub5GmlqJxwWe+knDJ80jxYPueUu7nj/K+xoVpbZ5xhkSClC44F1xrQ18pEexwM X2kS95k8RocOHMzXuNDbU54p0t0emKwsEU8cnmkcY1reaVukjW48m9dGDNOwbdJU1r34 kzrqCXW1dF/6Rp4XsCpc2xXrjXVrfHEYmRVHgMc6CHvg1hIpkCgwCdbMd0OwGBTAyw+Y S4zw==
X-Gm-Message-State: AIVw113boRgQMi0CvqgSroHucm1CdsWmN5y074Q00mVqPF+a7tr8kP+Z QLZitaljXoYf1/9PrFpzOGACmkDwWSs1
X-Received: by 10.98.15.71 with SMTP id x68mr8705040pfi.176.1500093422113; Fri, 14 Jul 2017 21:37:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Fri, 14 Jul 2017 21:36:21 -0700 (PDT)
In-Reply-To: <243e84a0-2804-d1a3-2d9d-4969c83e81df@gmail.com>
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> <CC675F8E-BCA7-4937-8A26-A5CA227C56C8@t-mobile.cz> <243e84a0-2804-d1a3-2d9d-4969c83e81df@gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Sat, 15 Jul 2017 06:36:21 +0200
Message-ID: <CAPt1N1kysk+EK4LoqzS6Yu2FT=qFkRQSNOYtQhBqKBNrYeQ=Bg@mail.gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: =?UTF-8?B?VsOtemRhbCBBbGXFoQ==?= <ales.vizdal@t-mobile.cz>, dhcwg <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
Content-Type: multipart/alternative; boundary="001a1137741e8e2d16055453b74a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/errVlDrYKthGc43fdEWm9JPuUXM>
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: Sat, 15 Jul 2017 04:37:04 -0000

Alexandre, it appears to me that you are asking the DHC working group to
make a change to the DHCPv6 spec in order to solve a problem you don't know
exists in an IPv6 layer 2 implementation.   I think that this is
wrong-headed on two fronts.   First, you are speculating that the problem
exists.  Find out whether the problem exists, don't speculate.   Second,
the problem is not in DHCP, if it does exist--it is in an IP
implementation.   So fix the implementation--don't ask for a change to the
DHCP spec.

On Fri, Jul 14, 2017 at 9:50 PM, Alexandre Petrescu <
alexandre.petrescu@gmail.com> wrote:

>
>
> Le 14/07/2017 à 21:26, Vízdal Aleš a écrit :
>
>>
>>
>> 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.
>>
>
> You see, I am also told that my "MT" ("Mobile Terminal"?) terminates
> GTP.  I guess both are possible (terminate some times at eNodeB and
> other times at MT).
>
> Or otherwise the expression "terminate at" may have different meanings
> to different people.
>
> 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 dont understand that.  Not sure what you mean by user-data planes.
>
> The IP Hop Limit is in the IP header.  Some IP tunnelling mechanisms do
> touch the Hop Limit of the encapsulated packet.  Why would GTP be
> different than the other IP tunnelling mechanisms?
>
> I suggest a deep dive into 3GPP specs ...
>>
>
> It is certainly advantageous to understand the 3GPP specs.
>
> But I'd rather consider putting that into an Internet Draft.
>
> Alex
>
>
>
>> 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/dcp
>> ublic/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/dc
>> public/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.
>>
>>