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

Ted Lemon <mellon@fugue.com> Tue, 18 July 2017 09:08 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 BE798131DB8 for <dhcwg@ietfa.amsl.com>; Tue, 18 Jul 2017 02:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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] 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 yokFi44onPPS for <dhcwg@ietfa.amsl.com>; Tue, 18 Jul 2017 02:08:15 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 8BFA5131B11 for <dhcwg@ietf.org>; Tue, 18 Jul 2017 02:08:15 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id q85so8521321pfq.1 for <dhcwg@ietf.org>; Tue, 18 Jul 2017 02:08:15 -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=7Ai01XS/XbcKWB6DKOvibVi1DXcvdskpizVDqDuBPbk=; b=f7XNs0RB4XP+Y5n/34xq2KxNBgwGHmhjd5EzlEBs6bOOZCFQ8yw4PSGpJUq34JF/MQ z0qJL8Bak6122E9aYW5aBV79cQ7gb3Cm4abAwxjHnJ16PYPkK7GGWUc7PPVzGMKKW5o6 qfStBz9QslLNBt7KcNpErWyaykYMeLGnA7AWja9s9XH3WJVx6q5C8MO8QqCZOnPuA3bH olSm2cgyUZn0heMesfl1go3IJQkVE/TPzoHCZ+SFSkN3sgidND/Z9UEnm7zkvCuE0aL8 Pd40jK4rUZVdA9ozCdiCB3gFjaGom28pD0KPrLvElwWAq2NYpVtyVrC05XzOKH3nBiYA y69g==
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=7Ai01XS/XbcKWB6DKOvibVi1DXcvdskpizVDqDuBPbk=; b=ggASWt5cSXfVTItiA1cDBfF5XG/U9S6gU9QnkFLo+hQtvvgdqeXToRm/v6xz4E4Y/Q ZOugPn6qxj0XFjpj9dtjYNkG69i6lydweHtKUYaDbOoVBFp+f0aa7ToixpabeUwu7rAP HvVtJP72IT19NbVdnsbg8zbel4MWyAMgo2qhJfx08hG7dr/B7fPqGqXLwAmBkXbeaeUG nW5YZOYQt0OaebnWC/eRQPEXkQGBVqXZKf9zepsLe+I1AiTOPrUwS/aE3NnGBbwVUvkb XQv1hhuQr873MI3fEk3SMxE4IzacqLeeHcDc7CVjC4dMnJC6rQjkzeFzpHTjWNMPCS12 txgA==
X-Gm-Message-State: AIVw111h9b8mSYcku2+lrO1kiR3N0jsdfk4Jyilo5arH9hHbYQWiKWH/ nIPKsXWMjLx2/9mvHxmAQ73+9DLc/Zne
X-Received: by 10.84.224.66 with SMTP id a2mr719357plt.64.1500368894984; Tue, 18 Jul 2017 02:08:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 02:07:34 -0700 (PDT)
In-Reply-To: <28fcee88f7354927b521c822b50277c6@srvhk403.rdm.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> <CC675F8E-BCA7-4937-8A26-A5CA227C56C8@t-mobile.cz> <243e84a0-2804-d1a3-2d9d-4969c83e81df@gmail.com> <6606c293c34d405e8153273a4bdeb357@srvhk403.rdm.cz> <CAPt1N1nCjEB5vgejn9CjO6y9PU_WqBn41PpvofF1h_ATv3_GmA@mail.gmail.com> <bc49c4e4567d4425af4f83e7136817aa@srvhk403.rdm.cz> <CAPt1N1kUGmp-87MeV0kf9rfGp85ux8RNpENCL1pknybWs_MPNQ@mail.gmail.com> <28fcee88f7354927b521c822b50277c6@srvhk403.rdm.cz>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 18 Jul 2017 11:07:34 +0200
Message-ID: <CAPt1N1mt51V4aHTs46S71qRpoz0iwpAyxq0_YqHX=AtRDa+x-g@mail.gmail.com>
To: =?UTF-8?B?VsOtemRhbCBBbGXFoQ==?= <ales.vizdal@t-mobile.cz>
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, dhcwg <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
Content-Type: multipart/alternative; boundary="f40304374f50079995055493db0e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/p0QO0ciJOgSFMiKNeEVorTze8Yc>
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: Tue, 18 Jul 2017 09:08:18 -0000

He later said that he'd observed this behavior when using the ISC DHCP
client.   My theory is that this is an artifact of the way the ISC DHCP
client transmits packets on the network, and not a problem with the
tunneling protocol.   It would be nice to validate that conjecture.

On Tue, Jul 18, 2017 at 11:00 AM, Vízdal Aleš <ales.vizdal@t-mobile.cz>
wrote:

> Alexandre’s email quoted below calls it ‘a speculation’. There is no
> problem to be solved here.
>
>
>
> > 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.
>
>
>
> 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.
>
>
>
>
>
> *From:* Ted Lemon [mailto:mellon@fugue.com]
> *Sent:* Tuesday, July 18, 2017 10:54 AM
> *To:* Vízdal Aleš <ales.vizdal@t-mobile.cz>
> *Cc:* Alexandre Petrescu <alexandre.petrescu@gmail.com>om>; dhcwg <
> dhcwg@ietf.org>gt;; Bernie Volz (volz) <volz@cisco.com>
> *Subject:* Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt -
> questions about Solicit Prefix Delegation
>
>
>
> I think the issue here is not that it's not clear what should be
> happening, but rather that Alexendre has observed bad behavior in the wild.
>   So it is worth getting to the bottom of the bad behavior.   I have no
> argument with that.   I'm just saying that once we have characterized the
> bad behavior, if it is a bug in the implementation, that should be fixed,
> and if it were a bug in the tunneling specification (which you are saying
> it is not) we would want to fix that.
>
>
>
> But what we definitely would not want to do is require behavior that's
> contrary to the internet architecture in 3315bis in order to paper over a
> bug that isn't a bug in DHCP.
>
>
>
> On Tue, Jul 18, 2017 at 10:40 AM, Vízdal Aleš <ales.vizdal@t-mobile.cz>
> wrote:
>
> I believe it is not a bug / problem, since the IP-link between the UE
> (handset) in the Mobile Network and the first L3 hop (GGSN/PGW or Mobile
> Core if you will) is a virtual-link. There are intermediate nodes between
> the UE and GGSN, but these are not touching the UE originated packets nor
> do any TTL / hop-limit changes since all IP forwarding is done based on GTP
> (or IPSec, since in some networks this traffic is secured by IPSec)
>
>
>
> The GGSN/PGW usually acts as a DHCP server or a relay, so a DHCP packet
> with a TTL=1 / hop-limit=1 will reach it.
>
>
>
> Does it clarify?
>
>
>
> Ales
>
>
>
> *From:* Ted Lemon [mailto:mellon@fugue.com]
> *Sent:* Tuesday, July 18, 2017 10:17 AM
> *To:* Vízdal Aleš <ales.vizdal@t-mobile.cz>
> *Cc:* Alexandre Petrescu <alexandre.petrescu@gmail.com>om>; dhcwg <
> dhcwg@ietf.org>gt;; Bernie Volz (volz) <volz@cisco.com>
> *Subject:* Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt -
> questions about Solicit Prefix Delegation
>
>
>
> I believe what Alexandre was proposing was not that we re-cast 3gpp specs
> as RFCs, but rather that we add text to 3315bis that explicitly says what
> hop limit to use, and that the hop-limit should be what I would describe as
> "incorrect."​   I realize that this is a somewhat judgmental way of
> describing it, but I don't know a different way.   If in fact the 3GPP
> architecture requires this, that's a bug, and it's not clear to me that
> RFC3315 is the right place to address that bug.
>
>
>
> But I'd really like for us to try to figure out whether this is in fact a
> bug, or whether it's just an artifact of the way that the ISC DHCP client
> is transmitting DHCP packets, which can be addressed by fixing that, rather
> than by updating RFC3315 to require behavior that is effectively a
> violation of the internet architecture.
>
>
>
> *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.*
>
>
>
> *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.*
>