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 08:54 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 81307131DC6 for <dhcwg@ietfa.amsl.com>; Tue, 18 Jul 2017 01:54:44 -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 XVwTNOGrqFLh for <dhcwg@ietfa.amsl.com>; Tue, 18 Jul 2017 01:54:41 -0700 (PDT)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 4C5A7131A78 for <dhcwg@ietf.org>; Tue, 18 Jul 2017 01:54:36 -0700 (PDT)
Received: by mail-pf0-x234.google.com with SMTP id e199so8302736pfh.2 for <dhcwg@ietf.org>; Tue, 18 Jul 2017 01:54:36 -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=cnA22QyDwZxU6Vb1eyIJ/U2LdkGgJYvHGQ2uXZWq3fg=; b=L6s5AY33nVqR6c8UbA2LW7r43RXbFV6MEq0ARiznpeGXWzGNLpwmVZPttWnrLPr/iE /hW1v84ONwN03kt5Pfmx1H5FghXIorNlrtmDpXNqBZRkZxTSaoyc1etPyTWCgtcm+gkO QK0qderAoRWk0+DNCWbkIFXHGLvdKBZofJLeFV+sGZO6gCR6HzVt46UF+gm2VZL3If6v QH5znCHJgWNMZWYnwOkUQamO6ikS6p3aUzIJQlxg7TWhFRTIlaqTADnww40LvHWK/of3 Io/+4foE/gIVNJtBz4OJU0Mj06p6zYpIFCxU2vxgkYsSd61iTcUbUMGZ3aqsvWB/qbIt a2Mg==
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=cnA22QyDwZxU6Vb1eyIJ/U2LdkGgJYvHGQ2uXZWq3fg=; b=ChFzAwl3yjRxnqLALgHg6AYlZ4MOfE6rMwxzY2fYN6o3GkeeEfXcl3hYH8tM4Z82Jh aM1Uhj29fRZ+hBQkwRjbwcNcZk3TJlnRxiF59esQaYsUiZSB+kKOU81C+4a4afNvb095 r0peCFYeWNb/777yoxczJCZEIAjS12K3V13xcU3ApE/xex4AKlz6i51RrsnCJ0REA3WR y6tp5cqPfPEzuSATLda1SoFFNM619lndRU7kd+J0IQ1NLAziqpsp8HW5GWVcxfHXgJAr Yq3BXbvS1QAbnNJxfuyeFXR56bRBchkL4IqlC7hD/mK4jvo2K6CwtbTCWyZaiIpQDlvG Tk8g==
X-Gm-Message-State: AIVw112hct7box0E/uEbpMutphO8JojsCUmhR3mvPOds76zwNqT+Yhe+ 9JBRUi2NG57KD1lHemvkTI/vOzih4Tf4
X-Received: by 10.99.114.82 with SMTP id c18mr642251pgn.32.1500368075945; Tue, 18 Jul 2017 01:54:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 01:53:55 -0700 (PDT)
In-Reply-To: <bc49c4e4567d4425af4f83e7136817aa@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>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 18 Jul 2017 10:53:55 +0200
Message-ID: <CAPt1N1kUGmp-87MeV0kf9rfGp85ux8RNpENCL1pknybWs_MPNQ@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="f403045c77243309c4055493aab1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/fbFj06Mz-T78OPCiMWcJ3BfLaKs>
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 08:54:44 -0000

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