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

"Bernie Volz (volz)" <volz@cisco.com> Sat, 15 July 2017 09:25 UTC

Return-Path: <volz@cisco.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 85FA5131B03 for <dhcwg@ietfa.amsl.com>; Sat, 15 Jul 2017 02:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 mCx5bU9AB0Bg for <dhcwg@ietfa.amsl.com>; Sat, 15 Jul 2017 02:25:47 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2429012EC4B for <dhcwg@ietf.org>; Sat, 15 Jul 2017 02:25:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13294; q=dns/txt; s=iport; t=1500110747; x=1501320347; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fwDeQsFFINPRxwSHdd4JbCbwUwCoz7FxzB0EJNyHqbo=; b=lWeDSFvMowwv8C8dBmc/TS2iYsMrq5WnoyWuHbOsSi+py6BrjH3eCLfI SP6KrtEdVfbRuKFiie/9HUbuEmllsur53uiLIyZ2aMWk+/P5ZCAg5C36K wV98FKPTH6X4xTqqhZQ6YRZNK+PnbFByTp59ZINbM+7yJMoDjkDqwgSkg 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAADp3mlZ/4gNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHgyiKXJFgiC6NVoIRIQ2FGQIag1c/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAQEBAQEKFxE6CwUHBAIBBgIRAwEBAQECAh8EAwICAh8GCxQBCAgCB?= =?us-ascii?q?A4FCIoPAw0IEI90nWSCJocwDYNdAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELgh2?= =?us-ascii?q?FLQGDJIJXgXANLQ+CbYJhBZ55OwKLEoQShGeSOIwKiUwBHziBCnUVSYUTHBmBT?= =?us-ascii?q?nYBhjWBMYENAQEB?=
X-IronPort-AV: E=Sophos;i="5.40,362,1496102400"; d="scan'208";a="455930132"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jul 2017 09:25:45 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v6F9Pjrg021442 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 15 Jul 2017 09:25:45 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 15 Jul 2017 04:25:45 -0500
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Sat, 15 Jul 2017 04:25:45 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
CC: Ted Lemon <mellon@fugue.com>, =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= <ales.vizdal@t-mobile.cz>, dhcwg <dhcwg@ietf.org>
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation
Thread-Index: AQHS9arXA8HVoh8yrE6qal+jjpOQE6JQvX5QgAGNVYD//8L84IAAgDcAgAAUm4CAAWTSgIAAAOYAgAALPgCAAALygIAABr6AgACTBYD//+D+AIAAZUKA//+ydCA=
Date: Sat, 15 Jul 2017 09:25:44 +0000
Message-ID: <8c343dd606e1442085d298af53dc1e72@XCH-ALN-003.cisco.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> <CAPt1N1kysk+EK4LoqzS6Yu2FT=qFkRQSNOYtQhBqKBNrYeQ=Bg@mail.gmail.com> <B5F9980A-3BF0-4069-939A-75683E01D643@cisco.com> <6c00ce4d-2e97-db4c-973a-9f753e402c08@gmail.com>
In-Reply-To: <6c00ce4d-2e97-db4c-973a-9f753e402c08@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.247.29]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/r0oeS5z_5DGifqePQmEKdJD667o>
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 09:25:49 -0000

>But IPv6 in 3GPP is a wholly different beast for which few specs - if
>any- exist at IETF.

Yes, but it would seem then that they would have issues with pretty much all multicast, unless applications that send multicast have taken steps to set a different hop limit for their packets. I would guess that applications that use non-link local multicast would set the hop limit (perhaps to "default" which I think is typically around 60).

BTW: While it is only 1 data point, I checked a RedHat Enterprise Linux 7.0 system and:

IPV6_UNICAST_HOPS is 64
IPV6_MULTICAST_HOPS is 1

(See RFC 3493 for details on these parameters.)

See https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt - it seems there is a means to change the default unicast hop limit, but not the multicast one?

- Bernie

-----Original Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] 
Sent: Saturday, July 15, 2017 4:48 AM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: Ted Lemon <mellon@fugue.com>om>; Vízdal Aleš <ales.vizdal@t-mobile.cz>cz>; dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation



Le 15/07/2017 à 08:45, Bernie Volz (volz) a écrit :
> I agree with Ted.
> 
> And, it does appear that kernels will default to 1 for a hop limit 
> with
> multicast:
> 
> “By default, IP multicast datagrams are sent with a hop limit of one, 
> which prevents the datagrams from being forwarded beyond a single 
> subnetwork.”

Again it's ok with native IP on native links like IP-over-Ethernet.

But IPv6 in 3GPP is a wholly different beast for which few specs - if
any- exist at IETF.

And DHCP-PD is probably the only part of DHCP that is considered in these 3GPP networks.

In DHCP-PD it would be perfectly fine to use GUA in the src and dst ll. 
This is under discussion.

> Thus, it is the multicast destination (ff02::1:2 for DHCPv6 packets) 
> that controls the (default) hop limit.
> 
> Also note that 2460bis has:
> 
>        Hop Limit           8-bit unsigned integer.  Decremented by 1 by
> 
>                            each node that forwards the packet.  When
> 
>                            forwarding, the packet is discarded if Hop
> 
>                            Limit was zero when received or is 
> decremented
> 
>                            to zero.  A node that is the destination of 
> a
> 
>                            packet should not discard a packet with hop
> 
>                            limit equal to zero, it should process the
> 
>                            packet normally.
> 
> RFC 2460 only has the 1^st sentence, so it was clarified as to what a 
> node that receives a packet should do if the hop count is 0 – process it.

In IPv6 tunnelling both encap and decap decrement - leading to -1.

Alex
> 
>   * Bernie
> 
> *From: *Ted Lemon <mellon@fugue.com>
> *Date: *Saturday, July 15, 2017 at 6:36 AM
> *To: *Alexandre Petrescu <alexandre.petrescu@gmail.com>
> *Cc: *Vízdal Aleš <ales.vizdal@t-mobile.cz>cz>, "dhcwg@ietf.org" 
> <dhcwg@ietf.org>rg>, Bernie Volz <volz@cisco.com>
> *Subject: *Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - 
> questions about Solicit Prefix Delegation
> 
> 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 <mailto: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
>             <mailto: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>
>                 <mailto: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>>
>                 <mailto: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 <mailto: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.
>