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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 14 July 2017 19:15 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 25740131769 for <dhcwg@ietfa.amsl.com>; Fri, 14 Jul 2017 12:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 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] 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 B9qdoUVNBruN for <dhcwg@ietfa.amsl.com>; Fri, 14 Jul 2017 12:15:40 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 74AF513176F for <dhcwg@ietf.org>; Fri, 14 Jul 2017 12:15:35 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v6EJFU6V025373; Fri, 14 Jul 2017 21:15:30 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EE6E220339B; Fri, 14 Jul 2017 21:15:29 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DE9D0201D5C; Fri, 14 Jul 2017 21:15:29 +0200 (CEST)
Received: from [132.166.84.71] ([132.166.84.71]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6EJFSNu018965; Fri, 14 Jul 2017 21:15:29 +0200
To: Ted Lemon <mellon@fugue.com>
Cc: dhcwg <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@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>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <0ea332fc-79a0-4ae9-50fc-465f2389157a@gmail.com>
Date: Fri, 14 Jul 2017 21:15:28 +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: <CAPt1N1=0_U3en3zAJbO0fMxKv32iFYLcTVqn6bO5zm6XjT3+iQ@mail.gmail.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/RsT4TT0rpWjdmH2Uy_MmtSMZ_D0>
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: Fri, 14 Jul 2017 19:15:41 -0000

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.

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.

Alex



> 
> On Fri, Jul 14, 2017 at 8:32 PM, Alexandre Petrescu 
> <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>>> 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
> 
> 
>