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

[Alexandre Petrescu <[e-mail]>]

Le 15/07/2017 à 11:25, Bernie Volz (volz) a écrit :
>> 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

By the name of that multicast constant it sounds as if all multicast 
packets - be them link-scope or other scope - would have a default Hop 
Limit of 1.

It is strange, because routers decrement the Hop Limit regardless of the 
the dst address being multicast or unicast.

> (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?

The hop limit can be set with a C function on the socket interface, for 
packets sent out of that socket.

Implementers of protocol extensions in the ND and MIP world do set it 
that way for their userspace software (not with system-wide calls like 
sysctl).

Alex

> 
> - Bernie
> 
> -----Original Message----- From: Alexandre Petrescu
> [mailto:[e-mail]] Sent: Saturday, July 15, 2017
> 4:48 AM To: Bernie Volz (volz) <[e-mail]> Cc: Ted Lemon
> <[e-mail]>; Vízdal Aleš <[e-mail]>; dhcwg
> <[e-mail]> 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 <[e-mail]> *Date: *Saturday, July 15,
>> 2017 at 6:36 AM *To: *Alexandre Petrescu
>> <[e-mail]> *Cc: *Vízdal Aleš
>> <[e-mail]>, "[e-mail]" <[e-mail]>,
>> Bernie Volz <[e-mail]> *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 
>> <[e-mail]
>> <mailto:[e-mail]>> wrote:
>> 
>> 
>> 
>> Le 14/07/2017 à 21:26, Vízdal Aleš a écrit :
>> 
>> On 14 Jul 2017, at 21:15, Alexandre Petrescu 
>> <[e-mail] 
>> <mailto:[e-mail]>> 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 
>> <[e-mail] 
>> <mailto:[e-mail]> 
>> <mailto:[e-mail] 
>> <mailto:[e-mail]>>> wrote: Le 13/07/2017 à
>> 23:14, Ted Lemon a écrit : On Jul 13, 2017 16:01, "Alexandre
>> Petrescu" <[e-mail] 
>> <mailto:[e-mail]> 
>> <mailto:[e-mail] 
>> <mailto:[e-mail]>> 
>> <mailto:[e-mail] 
>> <mailto:[e-mail]> 
>> <mailto:[e-mail] 
>> <mailto:[e-mail]>>>> 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
>> [e-mail] <mailto:[e-mail]> 
>> 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.
>>