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

>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>; Vízdal Aleš <ales.vizdal@t-mobile.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>, "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.
> 