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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Sat, 15 July 2017 08:47 UTC

Return-Path: <alexandre.petrescu@gmail.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 1491A12EC18 for <dhcwg@ietfa.amsl.com>; Sat, 15 Jul 2017 01:47:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Ir1IJEkgILOT for <dhcwg@ietfa.amsl.com>; Sat, 15 Jul 2017 01:47:54 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1AD412EC19 for <dhcwg@ietf.org>; Sat, 15 Jul 2017 01:47:53 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v6F8ln2D036450; Sat, 15 Jul 2017 10:47:49 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 42EF0200ECA; Sat, 15 Jul 2017 10:47:49 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 31007201540; Sat, 15 Jul 2017 10:47:49 +0200 (CEST)
Received: from [132.166.84.51] ([132.166.84.51]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6F8lmPc014608; Sat, 15 Jul 2017 10:47:48 +0200
To: "Bernie Volz (volz)" <volz@cisco.com>
Cc: Ted Lemon <mellon@fugue.com>, =?UTF-8?B?VsOtemRhbCBBbGXFoQ==?= <ales.vizdal@t-mobile.cz>, dhcwg <dhcwg@ietf.org>
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>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <6c00ce4d-2e97-db4c-973a-9f753e402c08@gmail.com>
Date: Sat, 15 Jul 2017 10:47:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <B5F9980A-3BF0-4069-939A-75683E01D643@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/3Y4kVomyDwF-KXKg_QTZjyQ1_Lg>
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 08:47:56 -0000


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