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

[Vízdal Aleš <[e-mail]>]

Alexandre’s email quoted below calls it ‘a speculation’. There is no problem to be solved here.


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


From: Ted Lemon [mailto:[e-mail]]
Sent: Tuesday, July 18, 2017 10:54 AM
To: Vízdal Aleš <[e-mail]>
Cc: Alexandre Petrescu <[e-mail]>; dhcwg <[e-mail]>; Bernie Volz (volz) <[e-mail]>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation

I think the issue here is not that it's not clear what should be happening, but rather that Alexendre has observed bad behavior in the wild.   So it is worth getting to the bottom of the bad behavior.   I have no argument with that.   I'm just saying that once we have characterized the bad behavior, if it is a bug in the implementation, that should be fixed, and if it were a bug in the tunneling specification (which you are saying it is not) we would want to fix that.

But what we definitely would not want to do is require behavior that's contrary to the internet architecture in 3315bis in order to paper over a bug that isn't a bug in DHCP.

On Tue, Jul 18, 2017 at 10:40 AM, Vízdal Aleš <[e-mail]<mailto:[e-mail]>> wrote:
I believe it is not a bug / problem, since the IP-link between the UE (handset) in the Mobile Network and the first L3 hop (GGSN/PGW or Mobile Core if you will) is a virtual-link. There are intermediate nodes between the UE and GGSN, but these are not touching the UE originated packets nor do any TTL / hop-limit changes since all IP forwarding is done based on GTP (or IPSec, since in some networks this traffic is secured by IPSec)

The GGSN/PGW usually acts as a DHCP server or a relay, so a DHCP packet with a TTL=1 / hop-limit=1 will reach it.

Does it clarify?

Ales

From: Ted Lemon [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, July 18, 2017 10:17 AM
To: Vízdal Aleš <[e-mail]<mailto:[e-mail]>>
Cc: Alexandre Petrescu <[e-mail]<mailto:[e-mail]>>; dhcwg <[e-mail]<mailto:[e-mail]>>; Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation

I believe what Alexandre was proposing was not that we re-cast 3gpp specs as RFCs, but rather that we add text to 3315bis that explicitly says what hop limit to use, and that the hop-limit should be what I would describe as "incorrect."​   I realize that this is a somewhat judgmental way of describing it, but I don't know a different way.   If in fact the 3GPP architecture requires this, that's a bug, and it's not clear to me that RFC3315 is the right place to address that bug.

But I'd really like for us to try to figure out whether this is in fact a bug, or whether it's just an artifact of the way that the ISC DHCP client is transmitting DHCP packets, which can be addressed by fixing that, rather than by updating RFC3315 to require behavior that is effectively a violation of the internet architecture.

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.


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.