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>, Vízdal Aleš <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>, "dhcwg@ietf.org" > <dhcwg@ietf.org>, 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. >
- [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.… internet-drafts
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Templin, Fred L
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Ted Lemon
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Ted Lemon
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Ted Lemon
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Vízdal Aleš
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Ted Lemon
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Vízdal Aleš
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Ted Lemon
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Vízdal Aleš
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Ted Lemon
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Vízdal Aleš
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Ted Lemon
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Ted Lemon
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Ted Lemon
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… 神明達哉
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… 神明達哉
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Alexandre Petrescu
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Templin, Fred L
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Ted Lemon
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Templin, Fred L
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Roy Marples
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Ted Lemon
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Ted Lemon
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Roy Marples
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Roy Marples
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… Ted Lemon
- Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis… mohamed.boucadair