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

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Jul 2017 18:21:46 +0200

What is the Hop Limit that a Solicit should contain in the IPv6 header?

(The ISC and a Cisco client set it at 255, whereas odhcp6c client at 1.
  The dst address is a ff02.
  The ND link messaging uses Hop Limit 255.)

Is IA_NA with empty fields a valid option in a Prefix Delegation
Solicit, or must IA_NA be absent altogether? (the intention is to only
request the Prefix, because the address comes from RA).

Is ORO with empty fields illegal in a Prefix Delegation Solicit?  (the
intention is to get the DNS server from RA, but some client puts an
empty ORO there).

Is it ok to use a GUA in the src address of a Solicit Prefix Delegation?
  Is the GUA mandatory, or could LL do it as well? (some server seems to
require it to be a GUA).

Alex

Le 29/06/2017 à 02:30, [email-masked] a écrit :
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Dynamic Host
> Configuration of the IETF.
> 
> Title           : Dynamic Host Configuration Protocol for IPv6
> (DHCPv6) bis Authors         : Tomek Mrugalski Marcin Siodelski 
> Bernie Volz Andrew Yourtchenko Michael C. Richardson Sheng Jiang Ted
> Lemon Timothy Winters Filename        :
> draft-ietf-dhc-rfc3315bis-09.txt Pages           : 140 Date
> : 2017-06-28
> 
> Abstract: This document describes the Dynamic Host Configuration
> Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring
> nodes with network configuration parameters, IP addresses, and
> prefixes. Parameters can be provided statelessly, or in combination
> with stateful assignment of one or more IPv6 addresses and/or IPv6 
> prefixes.  DHCPv6 can operate either in place of or in addition to 
> stateless address autoconfiguration (SLAAC).
> 
> This document updates the text from RFC3315, the original DHCPv6 
> specification, and incorporates prefix delegation (RFC3633), 
> stateless DHCPv6 (RFC3736), an option to specify an upper bound for 
> how long a client should wait before refreshing information 
> (RFC4242), a mechanism for throttling DHCPv6 clients when DHCPv6 
> service is not available (RFC7083), and clarifies the interactions 
> between modes of operation (RFC7550).  As such, this document 
> obsoletes RFC3315, RFC3633, RFC3736, RFC4242, RFC7083, and RFC7550.
> 
> 
> The IETF datatracker status page for this draft is: 
> https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc3315bis/
> 
> There are also htmlized versions available at: 
> https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-09 
> https://datatracker.ietf.org/doc/html/draft-ietf-dhc-rfc3315bis-09
> 
> A diff from the previous version is available at: 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-rfc3315bis-09
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at: 
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________ dhcwg mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 5 Jul 2017 22:58:48 +0000

Hi Alex,

>   Is the GUA mandatory, or could LL do it as well? (some server seems to

How would the client get the GUA before it does the PD Solicit? SLAAC?
IA_NA Solicit? What if all the client needs is the PD and no other GUAs?

With my code, I do PD Solicit with link-local source address with no
problems. I have been using the kea DHCP server, but it seems like
it should work for other servers as well.

Thanks - Fred

> -----Original Message-----
> From: dhcwg [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Wednesday, July 05, 2017 9:22 AM
> To: [email-masked]
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Jul 2017 17:40:43 +0200

> How would the client get the GUA before it does the PD Solicit? SLAAC?

SLAAC or some other unknown under-IP protocol.

> IA_NA Solicit? 

The server does not want to hear IA_NA, I dont know why.

> What if all the client needs is the PD and no other GUAs?

If the server could do it, and if it could provide the default route, 
it would be really great.

> it should work for other servers as well.

I dont know what server my operator uses but I speculate it to be either 
Cisco, or Ericsson or a clone.

Is KEA server able to work on cellular links?

Alex

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 12 Jul 2017 21:33:51 +0000

> What is the Hop Limit that a Solicit should contain in the IPv6 header?

ND uses hop limit of 255 so the destination can check that it is 255 on receipt (whereas 1 could have been anything and forwarded many times).

But I'm not sure if that is a the best practice when you don't want the packet forwarded. I would think that if the destination is a link-local multicast, it really doesn't matter as nothing should forward the packet (and if something is misconfigured to forward the packet, you're probably in deeper trouble than just with DHCPv6).

RFC 4861 has:

11.2.  Securing Neighbor Discovery Messages

   The protocol reduces the exposure to the above threats in the absence
   of authentication by ignoring ND packets received from off-link
   senders.  The Hop Limit field of all received packets is verified to
   contain 255, the maximum legal value.  Because routers decrement the
   Hop Limit on all packets they forward, received packets containing a
   Hop Limit of 255 must have originated from a neighbor.

I don't know off hand if there's any place this is documented (what to use for hop limit with link-local).

> Is IA_NA with empty fields a valid option in a Prefix Delegation Solicit, or must IA_NA be absent altogether? (the intention is to only request the Prefix, because the address comes from RA).

Not sure what an "empty" IA_NA is. Whether you include an IA_NA or not with IA_PD is the client's choice. If it what's an address (such as for management) on the upstream link, than it should include an IA_NA. This is covered in the text in 6.3 (IA_PD only) vs 6.4 (IA_PD and IA_NA, typically).

> Is ORO with empty fields illegal in a Prefix Delegation Solicit?  (the intention is to get the DNS server from RA, but some client puts an empty ORO there).

An empty ORO is fine (it should not cause problems, but is obviously useless). Though if they are following the rfc3315bis and doing what they should, there would not be an empty ORO.

> Is it ok to use a GUA in the src address of a Solicit Prefix Delegation?

See 13.1 of draft-ietf-dhc-rfc3315bis-09 ... the source address here should be link-local. I'd also think using a GLA source address with a link-local destination (multicast) would be rather odd. The 1st "-", third "*" would indicate that this means server-address option has been previously sent which is of course not possible for a Solicit.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday, July 05, 2017 12:22 PM
To: [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation

Is IA_NA with empty fields a valid option in a Prefix Delegation Solicit, or must IA_NA be absent altogether? (the intention is to only request the Prefix, because the address comes from RA).

Is ORO with empty fields illegal in a Prefix Delegation Solicit?  (the intention is to get the DNS server from RA, but some client puts an empty ORO there).

Is it ok to use a GUA in the src address of a Solicit Prefix Delegation?
  Is the GUA mandatory, or could LL do it as well? (some server seems to require it to be a GUA).

Alex

Le 29/06/2017 à 02:30, [email-masked] a écrit :
> specification, and incorporates prefix delegation (RFC3633), stateless 
> DHCPv6 (RFC3736), an option to specify an upper bound for how long a 
> client should wait before refreshing information (RFC4242), a 
> mechanism for throttling DHCPv6 clients when DHCPv6 service is not 
> available (RFC7083), and clarifies the interactions between modes of 
> operation (RFC7550).  As such, this document obsoletes RFC3315, 
> RFC3633, RFC3736, RFC4242, RFC7083, and RFC7550.
> 
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 13 Jul 2017 18:00:39 +0200

Bernie,

Le 12/07/2017 à 23:33, Bernie Volz (volz) a écrit :
> ND uses hop limit of 255 so the destination can check that it is 255 
> on receipt (whereas 1 could have been anything and forwarded many 
> times).
> 
> But I'm not sure if that is a the best practice when you don't want 
> the packet forwarded. I would think that if the destination is a 
> link-local multicast, it really doesn't matter as nothing should 
> forward the packet (and if something is misconfigured to forward the 
> packet, you're probably in deeper trouble than just with DHCPv6).
> 
> RFC 4861 has:
> 

I think your explanation makes sense about ND.

But, about DHCP, I need to know whether a DHCP Solicit with HopLimit 1
is valid or not.

As I said earlier, some DHCP clients set it at 255 whereas others at 1.

In some setting, the DHCP Solicit is encapsulated in IPv4.  Some of the
decapsulation RFCs say that the HopLimit is decremented.

In that setting, it is not clear whether decrementing the hop limit
happens, or not.

But I want to make sure the client which sets HopLimit at 1 (odhcp6c) is
the right way to do.

I think a good place to clarify this is in the DHCP spec.

The spec could say that the HopLimit has some preferred value.

>> Solicit, or must IA_NA be absent altogether? (the intention is to 
>> only request the Prefix, because the address comes from RA).
> 
> Not sure what an "empty" IA_NA is. Whether you include an IA_NA or 
> not with IA_PD is the client's choice. If it what's an address (such 
> as for management) on the upstream link, than it should include an 
> IA_NA. This is covered in the text in 6.3 (IA_PD only) vs 6.4 (IA_PD 
> and IA_NA, typically).

Noted.

>> Is ORO with empty fields illegal in a Prefix Delegation Solicit? 
>> (the intention is to get the DNS server from RA, but some client 
>> puts an empty ORO there).
> 
> An empty ORO is fine (it should not cause problems, but is obviously 
> useless). Though if they are following the rfc3315bis and doing what 
> they should, there would not be an empty ORO.

Noted.

> See 13.1 of draft-ietf-dhc-rfc3315bis-09 ... the source address here 
> should be link-local.

Well, that contradicts some trial.

I can say e.g. some (I believe Cisco) client puts a GUA in the src of a
DHCPv6 Solicit.  Other DHCP clients have this optional between LLA or
GUA.  The operator I work with wants it to be a GUA.

As such, I dont know what is the way forward: should the spec get
updated?  shoudl the operator change?  should the Cisco implementation
change?

Alex

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Jul 2017 17:38:22 +0000

Regarding the hop limit, I don’t have a recommendation; I'd likely leave it be what the OS defaults it to if I were writing a client. I'm not sure I'd put this in the 3315bis specification, but the WG can debate that issue.

Note also that the server does not have an easy way to get the hop count (well, perhaps there is a way but the server I work on doesn't care what it is) and therefore I doubt any of them check.

Regarding Link Local vs GLA in Solicit, I think following the specification would be recommended. Use link-local. For things that use GLA, likely it doesn't matter since if the Solicit is relayed and then the GLA isn't really used by the server -- as the link-address in the Relay-Forw. It may matter if the server is directly on link if it checks. I think that using differing scopes for source/destination addresses is a bad idea (and certainly sending with a source of LL and destination of GLA would be very bad). So, I think the client should stick to using the LL unless it is unicasting.

Note also that section 13.1 (for the unicast, GLA case) assumes the message was not multicast (section 18.4 about UseMulticast Status talks about "Reception of Unicast Messages").

I think section 13.1 was written with the assumption that determining the destination address of a packet is harder than obtaining the source address; hence the assumption is that if a GLA is used as the source address, it was not a multicast [to the link-local multicast address]. Today, kernels typically provide the ability to get the destination address, not just the source address (though it takes a bit more code to do so).

> I can say e.g. some (I believe Cisco) client puts a GUA in the src of aDHCPv6 Solicit.  

That's a bit of a broad statement as Cisco has many different devices (and many different operating systems and versions) ... perhaps if you could indicate which device(s) and software versions you've found this to be the behavior on, I can perhaps follow up.

I will also add that in many cases when devices are doing DHCPv6, they will only have a LL so it may also depend on the network configuration.

- Bernie

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Thursday, July 13, 2017 12:01 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation

Bernie,

But, about DHCP, I need to know whether a DHCP Solicit with HopLimit 1 is valid or not.

In some setting, the DHCP Solicit is encapsulated in IPv4.  Some of the decapsulation RFCs say that the HopLimit is decremented.

In that setting, it is not clear whether decrementing the hop limit happens, or not.

But I want to make sure the client which sets HopLimit at 1 (odhcp6c) is the right way to do.

> Not sure what an "empty" IA_NA is. Whether you include an IA_NA or not 
> with IA_PD is the client's choice. If it what's an address (such as 
> for management) on the upstream link, than it should include an IA_NA. 
> This is covered in the text in 6.3 (IA_PD only) vs 6.4 (IA_PD and 
> IA_NA, typically).

Noted.

>> (the intention is to get the DNS server from RA, but some client puts 
>> an empty ORO there).
> 

Noted.

I can say e.g. some (I believe Cisco) client puts a GUA in the src of a
DHCPv6 Solicit.  Other DHCP clients have this optional between LLA or GUA.  The operator I work with wants it to be a GUA.

As such, I dont know what is the way forward: should the spec get updated?  shoudl the operator change?  should the Cisco implementation change?

Alex

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jul 2017 14:51:47 -0400

DHCP relay is an app layer encapsulation. The hop count isn't even
presented to the app layer. It would be bizarre to do anything special with
it. I don't even know how you would write coffee that would accidentally
get this wrong. So it shouldn't matter what hop count the client uses. Hop
count is only relevant at the routing layer.

On Jul 13, 2017 12:00, "Alexandre Petrescu" <[email-masked]>
wrote:

>> ND uses hop limit of 255 so the destination can check that it is 255 on
>> receipt (whereas 1 could have been anything and forwarded many times).
>>
>> But I'm not sure if that is a the best practice when you don't want the
>> packet forwarded. I would think that if the destination is a link-local
>> multicast, it really doesn't matter as nothing should forward the packet
>> (and if something is misconfigured to forward the packet, you're probably
>> in deeper trouble than just with DHCPv6).
>>
>> RFC 4861 has:
>>
> Is IA_NA with empty fields a valid option in a Prefix Delegation Solicit,
>>> or must IA_NA be absent altogether? (the intention is to only request the
>>> Prefix, because the address comes from RA).
>>>
>>
>> with IA_PD is the client's choice. If it what's an address (such as for
>> management) on the upstream link, than it should include an IA_NA. This is
>> covered in the text in 6.3 (IA_PD only) vs 6.4 (IA_PD and IA_NA, typically).
>>
>
> Noted.
>
>>> intention is to get the DNS server from RA, but some client puts an empty
>>> ORO there).
>>>
>>
>> useless). Though if they are following the rfc3315bis and doing what they
>> should, there would not be an empty ORO.
>>
>
> Noted.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 13 Jul 2017 22:01:10 +0200

Le 13/07/2017 à 19:38, Bernie Volz (volz) a écrit :
> Regarding the hop limit, I don’t have a recommendation; I'd likely 
> leave it be what the OS defaults it to if I were writing a client. 
> I'm not sure I'd put this in the 3315bis specification, but the WG 
> can debate that issue.

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.

It may be that the decap does or does not decrement HopLimit.  I am 
saying 'may' because I am not sure there is a spec for GTP that 
encapsulates IPv6 in IPv4 (or there is but I dont know the number).

> Note also that the server does not have an easy way to get the hop 
> count (well, perhaps there is a way but the server I work on doesn't 
> care what it is) and therefore I doubt any of them check.
> 
> 
> Regarding Link Local vs GLA in Solicit, I think following the 
> specification would be recommended. Use link-local.

Noted.

> For things that use GLA, likely it doesn't matter since if the
> Solicit is relayed and then the GLA isn't really used by the server
> -- as the link-address in the Relay-Forw. It may matter if the server
> is directly on link if it checks. I think that using differing scopes
> for source/destination addresses is a bad idea (and certainly sending
> with a source of LL and destination of GLA would be very bad). So, I
> think the client should stick to using the LL unless it is
> unicasting.

Noted.

> Note also that section 13.1 (for the unicast, GLA case) assumes the 
> message was not multicast (section 18.4 about UseMulticast Status 
> talks about "Reception of Unicast Messages").
> 
> I think section 13.1 was written with the assumption that
> determining the destination address of a packet is harder than
> obtaining the source address; hence the assumption is that if a GLA
> is used as the source address, it was not a multicast [to the
> link-local multicast address]. Today, kernels typically provide the
> ability to get the destination address, not just the source address
> (though it takes a bit more code to do so).
> 
> 
> That's a bit of a broad statement as Cisco has many different
> devices (and many different operating systems and versions) ...
> perhaps if you could indicate which device(s) and software versions
> you've found this to be the behavior on, I can perhaps follow up.

I cant say which precisely Cisco client.  The operator knows.  The 
operator tells me to imitate what the Cisco client does, because that's 
what works.  And that client puts a GUA in the src.

I have informed the operator about this and let's see.

> I will also add that in many cases when devices are doing DHCPv6, 
> they will only have a LL so it may also depend on the network 
> configuration.

I agree there are many cases like that.

The case I am concerned with wants that the GUA comes from the RA, and 
the prefix from DHCPv6-PD (a sort NAT-free scalable tethering on 
cellular connection).

Alex

> 
> - Bernie
> 
> -----Original Message----- From: Alexandre Petrescu 
> [mailto:[email-masked]] Sent: Thursday, July 13, 2017 
> 12:01 PM To: Bernie Volz (volz) <[email-masked]> Cc: [email-masked] 
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - 
> questions about Solicit Prefix Delegation
> 
> Bernie,
> 
>> ND uses hop limit of 255 so the destination can check that it is 
>> 255 on receipt (whereas 1 could have been anything and forwarded 
>> many times).
>> 
>> forward the packet (and if something is misconfigured to forward 
>> the packet, you're probably in deeper trouble than just with 
>> DHCPv6).
>> 
>> RFC 4861 has:
>> 
>> The protocol reduces the exposure to the above threats in the 
>> absence of authentication by ignoring ND packets received from 
>> off-link senders.  The Hop Limit field of all received packets is 
>> verified to contain 255, the maximum legal value.  Because routers 
>> decrement the Hop Limit on all packets they forward, received 
>> packets containing a Hop Limit of 255 must have originated from a 
>> neighbor.
>> 
>> I don't know off hand if there's any place this is documented
>> (what to use for hop limit with link-local).
> 
> In some setting, the DHCP Solicit is encapsulated in IPv4.  Some of 
> the decapsulation RFCs say that the HopLimit is decremented.
> 
>>>  Solicit, or must IA_NA be absent altogether? (the intention is 
>>> to only request the Prefix, because the address comes from RA).
>> 
>> not with IA_PD is the client's choice. If it what's an address 
>> (such as for management) on the upstream link, than it should 
>> include an IA_NA. This is covered in the text in 6.3 (IA_PD only) 
>> vs 6.4 (IA_PD and IA_NA, typically).
> 
> Noted.
> 
>>>  (the intention is to get the DNS server from RA, but some
>>> client puts an empty ORO there).
>> 
>> An empty ORO is fine (it should not cause problems, but is 
>> obviously useless). Though if they are following the rfc3315bis
>> and doing what they should, there would not be an empty ORO.
> 
> Noted.
> 
>> See 13.1 of draft-ietf-dhc-rfc3315bis-09 ... the source address 
>> here should be link-local.
> 
> I can say e.g. some (I believe Cisco) client puts a GUA in the src
> of a DHCPv6 Solicit.  Other DHCP clients have this optional between
> LLA or GUA.  The operator I work with wants it to be a GUA.
> 
> updated?  shoudl the operator change?  should the Cisco 
> implementation change?
> 
> Alex
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 13 Jul 2017 22:01:48 +0200

For relay the DHCP spec says something like HpopLimit 32, which is fine.

Alex

Le 13/07/2017 à 20:51, Ted Lemon a écrit :
> presented to the app layer. It would be bizarre to do anything special 
> with it. I don't even know how you would write coffee that would 
> accidentally get this wrong. So it shouldn't matter what hop count the 
> client uses. Hop count is only relevant at the routing layer.
> 
> On Jul 13, 2017 12:00, "Alexandre Petrescu" 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Bernie,
> 
>         But I'm not sure if that is a the best practice when you don't
>         want the packet forwarded. I would think that if the destination
>         is a link-local multicast, it really doesn't matter as nothing
>         should forward the packet (and if something is misconfigured to
>         forward the packet, you're probably in deeper trouble than just
>         with DHCPv6).
> 
>         RFC 4861 has:
> 
>         absence
>             Is IA_NA with empty fields a valid option in a Prefix
>             Delegation Solicit, or must IA_NA be absent altogether? (the
>             intention is to only request the Prefix, because the address
>             comes from RA).
> 
> 
>         Not sure what an "empty" IA_NA is. Whether you include an IA_NA
>         or not with IA_PD is the client's choice. If it what's an
>         address (such as for management) on the upstream link, than it
>         should include an IA_NA. This is covered in the text in 6.3
>         (IA_PD only) vs 6.4 (IA_PD and IA_NA, typically).
> 
> 
>     Noted.
> 
>             Is ORO with empty fields illegal in a Prefix Delegation
>             Solicit? (the intention is to get the DNS server from RA,
>             but some client puts an empty ORO there).
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dhcwg>
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jul 2017 17:14:55 -0400

On Jul 13, 2017 16:01, "Alexandre Petrescu" <[email-masked]>
wrote:

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?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Jul 2017 21:42:38 +0000

That is a completely different constant, related to the Relay-Forward header. That has nothing to do with IPv6 header field.

- Bernie (from iPhone)

> On Jul 13, 2017, at 4:01 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
>> DHCP relay is an app layer encapsulation. The hop count isn't even presented to the app layer. It would be bizarre to do anything special with it. I don't even know how you would write coffee that would accidentally get this wrong. So it shouldn't matter what hop count the client uses. Hop count is only relevant at the routing layer.
>> On Jul 13, 2017 12:00, "Alexandre Petrescu" <[email-masked] <mailto:[email-masked]>> wrote:
>>    Bernie,

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 14 Jul 2017 20:32:01 +0200

Le 13/07/2017 à 23:14, Ted Lemon a écrit :
> On Jul 13, 2017 16:01, "Alexandre Petrescu" 

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jul 2017 20:35:14 +0200

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?

On Fri, Jul 14, 2017 at 8:32 PM, Alexandre Petrescu <
[email-masked]> wrote:

>> On Jul 13, 2017 16:01, "Alexandre Petrescu" <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
> But if the link is a virtual link - like when on a tunnel - then it may be
> that tunnel works or no.
>
> Alex
>
>
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 14 Jul 2017 21:15:28 +0200

Le 14/07/2017 à 20:35, Ted Lemon a écrit :
> 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 
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>         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?
> 
> 
>     But if the link is a virtual link - like when on a tunnel - then it
>     may be that tunnel works or no.
> 
>     Alex
> 
> 
>

---

From: Vízdal Aleš <[email-masked]>
Date: Fri, 14 Jul 2017 19:26:01 +0000

> On 14 Jul 2017, at 21:15, Alexandre Petrescu <[email-masked]> wrote:
>
>> 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.

> 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 suggest a deep dive into 3GPP specs ...

> Alex
>
>
>
>> On Fri, Jul 14, 2017 at 8:32 PM, Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> wrote:

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.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 14 Jul 2017 21:50:09 +0200

Le 14/07/2017 à 21:26, Vízdal Aleš a écrit :
>>> 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.
>> 
>>  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.
> 

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

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

>>> <mailto:[email-masked]>> wrote: Le 13/07/2017 à 
>>> 23:14, Ted Lemon a écrit : On Jul 13, 2017 16:01, "Alexandre 
>>> Petrescu" <[email-masked] 
>>> <mailto:[email-masked]>>> 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
>> 
> 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.
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 15 Jul 2017 06:36:21 +0200

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 <
[email-masked]> 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
>>> 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.
>>>
>>
>>>> [email-masked] <mailto:[email-masked]>>
>>>> wrote: Le 13/07/2017 à 23:14, Ted Lemon a écrit : On Jul 13, 2017 16:01,
>>>> "Alexandre Petrescu" <[email-masked] <mailto:
>>>> [email-masked]> <mailto:[email-masked]
>>>> 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
>>>>
>>>
>> 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/dcp
>> ublic/Zasady_komunikace_pri_sjednavani_smluv_cz.pdf>.
>>
>>
>>
>> communication principles which T-Mobile Czech Republic a.s. applies when
>> negotiating contracts are defined here<http://www.t-mobile.cz/dc
>> public/Zasady_komunikace_pri_sjednavani_smluv_en.pdf>.
>>
>>
>>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 15 Jul 2017 06:45:24 +0000

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

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 1st sentence, so it was clarified as to what a node that receives a packet should do if the hop count is 0 – process it.

  *   Bernie

From: Ted Lemon <[email-masked]>
Date: Saturday, July 15, 2017 at 6:36 AM
To: Alexandre Petrescu <[email-masked]>
Cc: Vízdal Aleš <[email-masked]>, "[email-masked]" <[email-masked]>, Bernie Volz <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

On 14 Jul 2017, at 21:15, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> 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?

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.

Alex

Alex

On Fri, Jul 14, 2017 at 8:32 PM, Alexandre Petrescu <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote: Le 13/07/2017 à 23:14, Ted Lemon a écrit : On Jul 13, 2017 16:01, "Alexandre Petrescu" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>> 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 [email-masked]<mailto:[email-masked]> 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>.

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 15 Jul 2017 10:44:06 +0200

Le 15/07/2017 à 06:36, Ted Lemon a écrit :
> 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.

In a sense I agree with you.  I speculate on the problem existence with GTP.

However, three different DHCP clients set two different values in the 
Hop Limit (a Cisco client, and the ISC set it to 255, whereas the 
odhcp6c sets it, at 1).  Maybe that is not a problem either, but looks 
like to me like one would like all DHCP clients to set same value in 
that field.  Just like all ND implementations set it at one single 
value.   What do you think?

Alex

> 
> On Fri, Jul 14, 2017 at 9:50 PM, Alexandre Petrescu 
>             On 14 Jul 2017, at 21:15, Alexandre Petrescu
>                 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
>             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
>             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.
> 
> 
>                 <mailto:[email-masked]>>> wrote: Le
>                 13/07/2017 à 23:14, Ted Lemon a écrit : On Jul 13, 2017
>                 16:01, "Alexandre Petrescu"
>                 <mailto:[email-masked]>>
>                 <mailto:[email-masked]>>>> 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 [email-masked] <mailto:[email-masked]>
>         zde<http://www.t-mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_cz.pdf
>         <http://www.t-mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_cz.pdf>>.
> 
> 
> 
>         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
>         <http://www.t-mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_en.pdf>>.
> 
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 15 Jul 2017 10:47:47 +0200

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

> 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 <[email-masked]>
> *Date: *Saturday, July 15, 2017 at 6:36 AM
> *To: *Alexandre Petrescu <[email-masked]>
> *Cc: *Vízdal Aleš <[email-masked]>, "[email-masked]" 
> <[email-masked]>, Bernie Volz <[email-masked]>
> *Subject: *Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt -

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 15 Jul 2017 09:25:44 +0000

>But IPv6 in 3GPP is a wholly different beast for which few specs - if

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:[email-masked]] 
Sent: Saturday, July 15, 2017 4:48 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: Ted Lemon <[email-masked]>; Vízdal Aleš <[email-masked]>; dhcwg <[email-masked]>
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:
> 

And DHCP-PD is probably the only part of DHCP that is considered in these 3GPP networks.

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 16 Jul 2017 22:05:39 +0200

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

> [mailto:[email-masked]] Sent: Saturday, July 15, 2017
> 4:48 AM To: Bernie Volz (volz) <[email-masked]> Cc: Ted Lemon
> <[email-masked]>; Vízdal Aleš <[email-masked]>; dhcwg
> <[email-masked]> Subject: Re: [dhcwg] I-D Action:
> draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix
> Delegation
> 
> 
> 
>> 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.”
> 
> But IPv6 in 3GPP is a wholly different beast for which few specs -
> if any- exist at IETF.
> 
> 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.
>> 
>> 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.
> 
>> *From: *Ted Lemon <[email-masked]> *Date: *Saturday, July 15,
>> 2017 at 6:36 AM *To: *Alexandre Petrescu
>> <[email-masked]> *Cc: *Vízdal Aleš
>> <[email-masked]>, "[email-masked]" <[email-masked]>,
>> Bernie Volz <[email-masked]> *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.
>> 
>> 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
>> 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.
>> 
>> 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?
>> 
>> <mailto:[email-masked]>>> wrote: Le 13/07/2017 à
>> <mailto:[email-masked]>>>> wrote: My oppinion is to 
>> 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
>> 
>> 
Není-li v zásadách uvedeno jinak, nepředstavuje tato zpráva
>> konečný
>> 
>> constitute the final offer to contract or an amendment of a
>> contract or acceptance of such offer.
>>

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 17 Jul 2017 21:42:56 +0000

response inline

Ales

> Sent: Friday, July 14, 2017 9:50 PM
> To: Vízdal Aleš <[email-masked]>
> Cc: Ted Lemon <[email-masked]>; dhcwg <[email-masked]>; Bernie Volz
> (volz) <[email-masked]>
> >> <[email-masked]> wrote:
> >>
> >>> you are talking about setting the IP header hop count to
> 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).

I can only recommend checking the 3GPP technical specification dealing with the architecture and protocol details.
Google will help.

> Or otherwise the expression "terminate at" may have different meanings to
> different people.
>
> >> 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.
> >

You can imagine that your IP traffic (originated by the UE or devices behind the UE) is a payload to the Mobile Network.
It is received on the radio interface of the eNodeB that puts the packet into the GTP, there is no routing involved.
In other words, your UE is assigned an IP address / IPv6 prefix, the L3 next hop is the GGSN/PGW, so any other node between
your UE and the GGSN/PGW does not change the packet as it forwards based on the GTP header.

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

As stated above, there is no routing involved. What is received on the radio interface is encapsulated into GTP and forwarded towards the GGSN/PGW.

> It is certainly advantageous to understand the 3GPP specs.

It is key to understand the architecture ...

> But I'd rather consider putting that into an Internet Draft.

Not sure if recasting 3GPP, ETSI, BBF and other specs as ID's would help.

> >>> <[email-masked] <mailto:[email-masked]>>
> >>> wrote: Le 13/07/2017 à 23:14, Ted Lemon a écrit : On Jul 13, 2017
> >>> 16:01, "Alexandre Petrescu" <[email-masked]
> >>> 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
> >>
> > zde<http://www.t-
> mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_cz.pdf>.
> >
> >
> >
> > here<http://www.t-
> mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_en.pdf>.
> >
> >
> >

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jul 2017 10:17:14 +0200

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.

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 18 Jul 2017 08:40:50 +0000

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:[email-masked]]
Sent: Tuesday, July 18, 2017 10:17 AM
To: Vízdal Aleš <[email-masked]>
Cc: Alexandre Petrescu <[email-masked]>; dhcwg <[email-masked]>; Bernie Volz (volz) <[email-masked]>
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.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jul 2017 10:53:55 +0200

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š <[email-masked]>
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:[email-masked]]
> *Sent:* Tuesday, July 18, 2017 10:17 AM
> *To:* Vízdal Aleš <[email-masked]>
> *Cc:* Alexandre Petrescu <[email-masked]>; dhcwg <
> [email-masked]>; Bernie Volz (volz) <[email-masked]>
> *Subject:* Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt -
> *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
> 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.*
>

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 18 Jul 2017 09:00:52 +0000

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

There is no GTP RFC.

Sent: Tuesday, July 18, 2017 10:54 AM

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š <[email-masked]<mailto:[email-masked]>> 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)

Does it clarify?

Ales

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jul 2017 11:07:34 +0200

He later said that he'd observed this behavior when using the ISC DHCP
client.   My theory is that this is an artifact of the way the ISC DHCP
client transmits packets on the network, and not a problem with the
tunneling protocol.   It would be nice to validate that conjecture.

On Tue, Jul 18, 2017 at 11:00 AM, Vízdal Aleš <[email-masked]>
wrote:

> 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.
>
>
>
> 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.
>
>
>
> *Sent:* Tuesday, July 18, 2017 10:54 AM
> 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.
>
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 19 Jul 2017 11:10:25 +0200

Ted,

Let me explain.  I no longer have a request for the spec 3315bis.  Sorry
for the intrusion.

Le 18/07/2017 à 11:07, Ted Lemon a écrit :
> He later said that he'd observed this behavior when using the ISC 
> DHCP client.   My theory is that this is an artifact of the way the 
> ISC DHCP client transmits packets on the network, and not a problem 
> with the tunneling protocol.   It would be nice to validate that 
> conjecture.

We work on this conjencture, but it takes time, because it involves many
people, I am the only who speaks, and some times wrongly.  Now I prefer
to stay silent until I get some resolution to talk about.

Until then, all I can say is that I have packet dumps that show
encapsulation, and ICMP hoplimit exceeded, and that the DHCP Solicit had
hoplimit 1.  It is however not clear whether or not that's anybody's fault.

This is not a matter of someone's fault; the goal is to make it work.

I am sorry for the confusion this may have created.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Jul 2017 11:52:35 +0200

No worries.   Have you tried compiling with USE_SOCKETS?   Does that
produce the same result?

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 19 Jul 2017 11:57:49 +0200

> No worries.   Have you tried compiling with USE_SOCKETS?   Does that 

Yes and results are different but still not satisfactorily overall.

(FWIW #define USE_SOCKETS 1 goes in build/includes/config.h)

Alex

> 
> On Wed, Jul 19, 2017 at 11:10 AM, Alexandre Petrescu 
>         He later said that he'd observed this behavior when using the
>         ISC DHCP client.   My theory is that this is an artifact of the
>         way the ISC DHCP client transmits packets on the network, and
>         not a problem with the tunneling protocol.   It would be nice to
>         validate that conjecture.
> 
>