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

Vízdal Aleš <> Tue, 18 July 2017 08:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24597131DB7 for <>; Tue, 18 Jul 2017 01:40:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 8b8iE69p8rd6 for <>; Tue, 18 Jul 2017 01:40:55 -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 1FFDC131A76 for <>; Tue, 18 Jul 2017 01:40:54 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 E8B1F2E25C9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim2016; t=1500367250; bh=UuFYxAokIXhNZ0TVRhawInelrPgeo7O/gjbdLz99GGY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=h2ljzNkS6bSRI9dX24W7siOlUI86jBw1fz1tDTEW7z8FzhstxJ6alIXub2cJW0PKK dxM8t2YqnUr/hk7l3yrO42W4cPq3u30IUGtk4JMiJfprIFkiOtA7w+84l8PyeTZvUN YCFkJ1HNuoxqJa0KWHVnCUyN4dNNd56hgUi38xdfVO7rgVc542M5vJafvUk1z78RgT 2RveiTO1KuYJUGHmcao+o0hqLpMs5K07l+T0DFVpcpu49TkJwqMF/h9m856iJu0X33 8Ww8fUWSqGBrjWexPafzSvi6Jb4aK5wiFx2KnDIPtymamsvwE1YR2jNBcqwTEfz5C0 myRkHNYl/ABew==
From: Vízdal Aleš <>
To: Ted Lemon <>, Alexandre Petrescu <>
CC: dhcwg <>, "Bernie Volz (volz)" <>
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation
Date: Tue, 18 Jul 2017 08:40:50 +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: multipart/alternative; boundary="_000_bc49c4e4567d4425af4f83e7136817aasrvhk403rdmcz_"
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: Tue, 18 Jul 2017 08:40:58 -0000

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?


From: Ted Lemon []
Sent: Tuesday, July 18, 2017 10:17 AM
To: Vízdal Aleš <>
Cc: Alexandre Petrescu <>; dhcwg <>; Bernie Volz (volz) <>
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<>. 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.