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

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 Oct 2017 16:06:12 +0200

Bernie,

Le 13/07/2017 à 19:38, Bernie Volz (volz) a écrit :
[...]

> Regarding Link Local vs GLA in Solicit, I think following the 
> specification would be recommended. Use link-local.

But the I-D 3315bis says this:
> Clients and servers exchange DHCP messages using UDP [RFC0768].  The
>  client uses a link-local address or addresses determined through 
> other mechanisms for transmitting and receiving DHCP messages.
   ^^^^^^^^^^^^^^^^

This "other mechanisms" means that a GUA generated with SLAAC could be
used as an src in a DHCPv6 Solicit.

[...]
> 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").

Hm, that lokks like a relatively less explicit if not outright silent 
assumption(?)  Or maybe I did not look well enough in the I-D?

There is a particular equipment manufacturer's simulator software, and 
potentially real hardware, that uses GUA in src and dst multicast with 
link scope ff02::1:2.547, in the DHCPv6 Solicit.

If this behaviour is standard (src GUA and dst ff02::1:2) then it should 
be in the draft.  If it's not standard: it should get corrected in the 
simulated and in the real implementation.

Because other software than the one from the particular equipment 
manufacturer uses src LL and dst ff02::1:2.

Side note:

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

The picture may be different on point-to-point links like cellular 
links.  It's multicast, but it's just two nodes and they are always 
seeing each other.  Besides, one of the nodes allocates an address to 
the other node by other means than SLAAC, and it knows it.

Alex

> 
> 
>> 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,
> 
> Le 12/07/2017 à 23:33, Bernie Volz (volz) a écrit :
>> Hi:
>> 
>>> 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).
> 
> 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.
> 
>>> 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).
>> 
>> 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.
> 
>>> 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.
> 
> 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: Wed, 18 Oct 2017 14:25:51 +0000

Hi Alex:

Does it really matter what the Client’s source address is as long as the client can receive packets sent to that address (by a relay or server that is on that link)? These are link-local packets and so no router should be involved in them (that’s what the relay agent is there for – to forward the packets to servers not on the local link).

- Bernie

On 10/18/17, 10:06 AM, "Alexandre Petrescu" <[email-masked]> wrote:

    Bernie,

    
       ^^^^^^^^^^^^^^^^

    [...]

    

    

    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 Oct 2017 18:01:14 +0200

Le 18/10/2017 à 16:25, Bernie Volz (volz) a écrit :
> Hi Alex:
> 
> Does it really matter what the Client’s source address

Yes it is guidance that I need.

Alex

  is as long as
> the client can receive packets sent to that address (by a relay or
> server that is on that link)? These are link-local packets and so no
> router should be involved in them (that’s what the relay agent is
> there for – to forward the packets to servers not on the local
> link).
> 
> - Bernie
> 
> Le 13/07/2017 à 19:38, Bernie Volz (volz) a écrit : [...]
> 
>> Clients and servers exchange DHCP messages using UDP [RFC0768].
>> The client uses a link-local address or addresses determined
>> through other mechanisms for transmitting and receiving DHCP
>> messages.
> ^^^^^^^^^^^^^^^^
> 
> This "other mechanisms" means that a GUA generated with SLAAC could
> be used as an src in a DHCPv6 Solicit.
> 
> 
> [...]
>> 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").
> 
> Hm, that lokks like a relatively less explicit if not outright
> silent assumption(?)  Or maybe I did not look well enough in the
> I-D?
> 
> There is a particular equipment manufacturer's simulator software,
> and potentially real hardware, that uses GUA in src and dst multicast
> with link scope ff02::1:2.547, in the DHCPv6 Solicit.
> 
> If this behaviour is standard (src GUA and dst ff02::1:2) then it
> should be in the draft.  If it's not standard: it should get
> corrected in the simulated and in the real implementation.
> 
>> 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).
> 
> seeing each other.  Besides, one of the nodes allocates an address
> to the other node by other means than SLAAC, and it knows it.
> 
> Alex
> 
>> 
>> 
>>> 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.
>> 
>> [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,
>> 
>>>> What is the Hop Limit that a Solicit should contain in the
>>>> IPv6 header?
>>> 
>>> 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:
>>> 
>>> 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).
>> 
>> 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.
>> 
>>>> 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).
>>> 
>>> obviously useless). Though if they are following the rfc3315bis
>>> and doing what they should, there would not be an empty ORO.
>> 
>> Noted.
>> 
>> 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.
>>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 18 Oct 2017 16:31:24 +0000

Actually, the guidance is already there? See section 13.1.

      *  If the server receives the message directly from the client and
         the source address in the IP datagram in which the message was
         received is a link-local address, then the client is on the
         same link to which the interface over which the message was
         received is attached.

      *  If the server receives the message directly from the client and
         the source address in the IP datagram in which the message was
         received is not a link-local address, then the client is on the
         link identified by the source address in the IP datagram (note
         that this situation can occur only if the server has enabled
         the use of unicast message delivery by the client and the
         client has sent a message for which unicast delivery is
         allowed).

In the relay case, the client's source address doesn't really come into play at all. So, in the case technically the client could use either. But since the client has no idea whether a relay will be present, it should follow these rules.

The document has been submitted to the AD for publication. If you have concerns or issues, you can always make the AD aware of these or await the IETF Last-Call period to raise your issues.

- Bernie

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Wednesday, October 18, 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 - src LL vs GUA

Alex

  is as long as

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 Oct 2017 19:42:16 +0200

>           client has sent a message for which unicast delivery is

That is useful guidance if the question was about on which link this 
Client was.  In my case the link involves GTP, UDPv4 and IPv6.

But I need guidance to the following question: if the Client sends a 
Solicit with a LL in src, MUST the Server reply to it?  (yes/no is the 
needed guidance).

I explain why: about 4 distinct clients use LL in src.  If I want these 
clients to use GUA then I must delete the LL from the interface.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Oct 2017 10:55:26 -0700

On Oct 18, 2017, at 10:42 AM, Alexandre Petrescu <[email-masked]> wrote:
> But I need guidance to the following question: if the Client sends a Solicit with a LL in src, MUST the Server reply to it?  (yes/no is the needed guidance).

I don't know what the spec says off the top of my head, but if the server doesn't respond, the client will keep asking, so this seems like a bad idea.

> I explain why: about 4 distinct clients use LL in src.  If I want these clients to use GUA then I must delete the LL from the interface.

The server not responding is not going to help with this.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 18 Oct 2017 10:57:20 -0700

At Wed, 18 Oct 2017 19:42:16 +0200,

> Solicit with a LL in src, MUST the Server reply to it?  (yes/no is the

I don't see the need for such guidance, at least as part of
rfc3315bis.  What's your problem if we didn't have such guidance in
normative text like a "MUST"?

> clients to use GUA then I must delete the LL from the interface.

This one itself doesn't sound like a problem.  Do you have any
specific problem with the clients sending a solicit from a link-local
address?

--
jinmei

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 18 Oct 2017 18:13:07 +0000

> But I need guidance to the following question: if the Client sends a Solicit with a LL in src, MUST the Server reply to it?  (yes/no is the needed guidance).

A server may not respond to a client for a variety of reasons, but we'll assume none of those apply here (hence "MUST" is dangerous).

I don't see why a server would drop a Solicit just because there is a LL in src -- I would think that would be the NORMAL case and hence the server would respond. (Of course, we assume that LL is valid here and can be used.)

>           client has sent a message for which unicast delivery is

Also, some servers could respond with Use Multicast unless server-unicast option has been configured. It may be that they use the source address to determine this (rather than the destination address, which as you say really should be used when server receives packet directly)?

>I explain why: about 4 distinct clients use LL in src.  If I want these clients to use GUA then I must delete the LL from the interface.

That you actually want the global unicast address to be used by the client, not the link-local?

For what it is worth, the server I work on doesn't care what the client's source address is. We monitor the destination address (when packet is received).

- Bernie

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Wednesday, October 18, 2017 1:42 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 - src LL vs GUA

>           client has sent a message for which unicast delivery is

That is useful guidance if the question was about on which link this Client was.  In my case the link involves GTP, UDPv4 and IPv6.

Alex

> questions about Solicit Prefix Delegation - src LL vs GUA
> 
> 
> 
>> there for – to forward the packets to servers not on the local link).
>>
>> - Bernie
>>
>>> The client uses a link-local address or addresses determined through

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 Oct 2017 22:03:26 +0200

Le 18/10/2017 à 19:57, 神明達哉 a écrit :
> At Wed, 18 Oct 2017 19:42:16 +0200, Alexandre Petrescu
> <[email-masked]> wrote:
> 
>>> *  If the server receives the message directly from the client
>>> and the source address in the IP datagram in which the message
>>> was received is a link-local address, then the client is on the 
>> That is useful guidance if the question was about on which link
>> this Client was.  In my case the link involves GTP, UDPv4 and
>> IPv6.
>> 
>> But I need guidance to the following question: if the Client sends
>> a Solicit with a LL in src, MUST the Server reply to it?  (yes/no
>> is the needed guidance).
> 

The problem is the following: exchange between Client and Server does
not work.  CLient believes it needs to send LL in src, whereas Server
believes the Client should use GUA in src.  There are other fields on
which the problem may reside (port number, IA_ID, and others); each
needs separate treatment.

That's a problem.

With respect to GUA-vs-LL in src there is no guidance in 3315bis.

If one wants to change this, i.e. make sure Server to accept LL in src
of Solicit, then one  typically is suggested to first come with an
actual business impact.

That is not normal.

Either LL-in-src MUST be accepted at Server as a standard, or MUST NOT.
  It's not a matter of business impact.

We can turn around phrases as much as we want, but interoperability is
not there.

>> I explain why: about 4 distinct clients use LL in src.  If I want
>> these clients to use GUA then I must delete the LL from the
>> interface.
> 
> specific problem with the clients sending a solicit from a
> link-local address?

With respect, I think you did not understand what I wrote.  Please re-read.

Myself I dont have a problem with Clients sending Solicit with src-LL.
But Server MAY have a problem.  Because the example traces of Server I
have always uses GUA-in-src.  I dont want to follow that example, but I
cant tell the Server's Programmer that is not standard.  Because there
is no guidance.

To come back to my question: do you think it is ok to delete the LL from
the interface?

Alex

> -- jinmei

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 Oct 2017 22:08:19 +0200

Le 18/10/2017 à 20:13, Bernie Volz (volz) a écrit :
> A server may not respond to a client for a variety of reasons, but
> we'll assume none of those apply here (hence "MUST" is dangerous).
> 
> I don't see why a server would drop a Solicit just because there is a
> LL in src -- I would think that would be the NORMAL case and hence
> the server would respond. (Of course, we assume that LL is valid here
> and can be used.)

Again, the NORMAL case for this particular Server, is to show 
GUA-in-src, not LL-in-src.  It is a simulator from a large equipment 
manufacturer.  That simulator is pretended to work accordingly to the 
real network.

> I could see that if a client used a GLA and the server was the first
> hop (no relay), it could drop it if the GLA address as it could mean
> it has no configuration for that "location". Remember the text from
> 13.1:
> 
>> link identified by the source address in the IP datagram (note that
>> this situation can occur only if the server has enabled the use of
>> unicast message delivery by the client and the client has sent a
>> message for which unicast delivery is allowed).
> 
> Also, some servers could respond with Use Multicast unless
> server-unicast option has been configured. It may be that they use
> the source address to determine this (rather than the destination
> address, which as you say really should be used when server receives
> packet directly)?
> 
> 

I want to not modify the Clients.  The 4 Clients all use LL-in-src.  But 
the Server examples use GUA-in-src.  A Server example is a packet trace 
executed on a simulator that pretends to be like in reality.  That 
simulator uses GUA-in-src.  So, I am told, if I want to be interoperable 
to that Server, I must do what that simulator does: put GUA-in-src.  So 
I delete the LL from the interface on the Client.

Do you think it is normal to delete the LL from the interface?

> For what it is worth, the server I work on doesn't care what the
> client's source address is. We monitor the destination address (when
> packet is received).

"Does not care" - ok.

But does it accept a Solicit with LL-in-src?

Alex

> [mailto:[email-masked]] Sent: Wednesday, October 18,
> 2017 1:42 PM To: Bernie Volz (volz) <[email-masked]> Cc:
> Delegation - src LL vs GUA
> 
> 
> 
>> received is a link-local address, then the client is on the same
>> link to which the interface over which the message was received is
>> attached.
>> 
>> link identified by the source address in the IP datagram (note that
>> this situation can occur only if the server has enabled the use of
>> unicast message delivery by the client and the client has sent a
>> message for which unicast delivery is allowed).
> 
> Solicit with a LL in src, MUST the Server reply to it?  (yes/no is
> the needed guidance).
> 
>> In the relay case, the client's source address doesn't really come
>> into play at all. So, in the case technically the client could use
>> either. But since the client has no idea whether a relay will be
>> present, it should follow these rules.
>> 
>> The document has been submitted to the AD for publication. If you
>> have concerns or issues, you can always make the AD aware of these
>> or await the IETF Last-Call period to raise your issues.
>> 
>> - Bernie
>> 
>> [mailto:[email-masked]] Sent: Wednesday, October 18,
>> Delegation - src LL vs GUA
>> 
>> 
>> 
>>> the client can receive packets sent to that address (by a relay
>>> or server that is on that link)? These are link-local packets and
>>> so no router should be involved in them (that’s what the relay
>>> agent is there for – to forward the packets to servers not on the
>>> local link).
>>> 
>>> - Bernie
>>> 
>>>> Clients and servers exchange DHCP messages using UDP
>>>> [RFC0768]. The client uses a link-local address or addresses
>>>> determined through other mechanisms for transmitting and
>>>> receiving DHCP messages.
>>> ^^^^^^^^^^^^^^^^
>>> 
>>> This "other mechanisms" means that a GUA generated with SLAAC
>>> could be used as an src in a DHCPv6 Solicit.
>>> 
>>> 
>>> [...]
>>>> 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").
>>> 
>>> There is a particular equipment manufacturer's simulator
>>> software, and potentially real hardware, that uses GUA in src and
>>> dst multicast with link scope ff02::1:2.547, in the DHCPv6
>>> Solicit.
>>> 
>>> If this behaviour is standard (src GUA and dst ff02::1:2) then
>>> it should be in the draft.  If it's not standard: it should get 
>>> Because other software than the one from the particular
>>> equipment manufacturer uses src LL and dst ff02::1:2.
>>> 
>>> Side note:
>>> 
>>>> 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).
>>> 
>>> The picture may be different on point-to-point links like
>>> cellular links.  It's multicast, but it's just two nodes and they
>>> are always seeing each other.  Besides, one of the nodes
>>> allocates an address to the other node by other means than SLAAC,
>>> and it knows it.
>>> 
>>> Alex
>>> 
>>>> 
>>>> 
>>>>> I can say e.g. some (I believe Cisco) client puts a GUA in
>>>>> the src of aDHCPv6 Solicit.
>>>> 
>>>> 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
>>>> 
>>>> 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).
>>>>> 
>>>>> 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:
>>>>> 
>>>>> 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).
>>>> 
>>>> 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.
>>>> 
>>>>>> 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.
>>>> 
>>>>>> Solicit? (the intention is to get the DNS server from RA,
>>>>>> but some client puts an empty ORO there).
>>>>> 
>>>>> obviously useless). Though if they are following the
>>>>> rfc3315bis and doing what they should, there would not be an
>>>>> empty ORO.
>>>> 
>>>> Noted.
>>>> 
>>>>>> 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.
>>>> 
>>>> 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: 神明達哉 <[email-masked]>
Date: Wed, 18 Oct 2017 13:30:46 -0700

At Wed, 18 Oct 2017 22:03:26 +0200,

> needs separate treatment.

To me, it's just that the server implementation is broken.  Unless the
protocol specification explicitly imposes a limitation on the type of
source addresses it shouldn't assume a limitation and refuse to accept
packets that don't meet its proprietary assumption.

Now, the question is whether a protocol specification needs to
explicitly say that a server MUST NOT have such an assumption.  I
simply don't think so - we can't just add nearly obvious statement
just because there is some broken implementation.  I wouldn't be
surprised if there is a broken DNS server implementation that doesn't
respond to a query from an IPv6 link-local address, but I just don't
think we should write an RFC that has "a DNS server MUST NOT drop a
query from a link-local IPv6 address" just because of such a broken
implementation.  This case is no different from that to me.

You seem to think it's worth noting in the protocol spec, but as far
as I can see you have not successfully convinced the wg about the need
for it.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 18 Oct 2017 20:35:09 +0000

The server vendor is in error here ... as far as I know, clients use the link-local address.

The issue for the server vendor may be then how does the server tell where the client is ... and, in that case, you do what was done for DHCPv4 before -- you use the (non link-local) address of the interface on which the request was received (since that it the network on which the client is located). That's exactly what section 13.1 states:

>> received is a link-local address, then the client is on the same link 
>> to which the interface over which the message was received is 
>> attached.

Note that the DHCP Client test equipment vendor also appears not to be following standard transmission rules (i.e., to use a link-local address). But, you haven't indicated (I don't think) what the destination address for these DHCPv6 requests are - perhaps they were configured to be a GUA (and then it makes sense for the clients to use a GUA).

To summarize:
- If destination of client is link-local [multicast] address, source SHOULD be link-local. (This probably could be a MUST but there might be some odd instances where this is not appropriate - such as point-to-point links. Note also that I don't think there's a restriction that a source address may have wider scope than a destination address.)
- If destination of client is GLA, source MUST be GLA (otherwise, replies cannot be returned to the client).

A few more comments inline below (BV>).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday, October 18, 2017 4:08 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 - src LL vs GUA

Le 18/10/2017 à 20:13, Bernie Volz (volz) a écrit :
> LL in src -- I would think that would be the NORMAL case and hence the 
> server would respond. (Of course, we assume that LL is valid here and 
> can be used.)

Again, the NORMAL case for this particular Server, is to show GUA-in-src, not LL-in-src.  It is a simulator from a large equipment manufacturer.  That simulator is pretended to work accordingly to the real network.

BV> This seems wrong on the simulator's part. But again, please specify what the destination address is. And see comments earlier that src can be wider scope than destination without causing issues in general -- though of course section 13.1 bullet 3 applies.

>> received is not a link-local address, then the client is on the link 
>> identified by the source address in the IP datagram (note that this 
>> situation can occur only if the server has enabled the use of unicast 
>> message delivery by the client and the client has sent a message for 
>> which unicast delivery is allowed).
> 
> server-unicast option has been configured. It may be that they use the 
> source address to determine this (rather than the destination address, 
> which as you say really should be used when server receives packet 
> directly)?
> 
> 

I want to not modify the Clients.  The 4 Clients all use LL-in-src.  But the Server examples use GUA-in-src.  A Server example is a packet trace executed on a simulator that pretends to be like in reality.  That simulator uses GUA-in-src.  So, I am told, if I want to be interoperable to that Server, I must do what that simulator does: put GUA-in-src.  So I delete the LL from the interface on the Client.

BV> That seems rather bizarre to me ... not sure how other IPv6 services (ND, DAD, etc.) might be impacted?
BV> My recommendation is to get the server vendor to fix it as this is rather broken and others will have problem as well. If the server vendor wants to sell their server, they will need to correct it.

"Does not care" - ok.

BV> Yes. That is what 100% of the clients I've ever seen send so our server would not be servicing millions of IPv6 clients if it dropped those packets. (And, yes, it is millions based on just one single customer deployment -- and we have many more customers that are using IPv6.)

Alex

>> received is a link-local address, then the client is on the same link 
>> to which the interface over which the message was received is 
>> attached.
>> 
>> received is not a link-local address, then the client is on the link 
>> identified by the source address in the IP datagram (note that this 
>> situation can occur only if the server has enabled the use of unicast 
>> message delivery by the client and the client has sent a message for 
>> which unicast delivery is allowed).
> 
> these clients to use GUA then I must delete the LL from the interface.
> 
> Alex
> 
>> 
>> have concerns or issues, you can always make the AD aware of these or 
>> await the IETF Last-Call period to raise your issues.
>> 
>> - Bernie
>> 
>>> and potentially real hardware, that uses GUA in src and dst 
>>> multicast with link scope ff02::1:2.547, in the DHCPv6 Solicit.
>>> 
>>>>> verified to contain 255, the maximum legal value.
>>>>> forward, received packets containing a Hop Limit of 255 must have 
>>>>>> Solicit, or must IA_NA be absent altogether?
>>>>>> (the intention is to only request the Prefix, because the address 
>>>>>> comes from RA).
>>>>> 

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 Oct 2017 11:07:35 +0200

> The server vendor is in error here ... as far as I know, clients use 

Noted.  I will continue using the LL address in src of DHCPv6 Solicit.

> The issue for the server vendor may be then how does the server tell 
> where the client is ... and, in that case, you do what was done for 
> DHCPv4 before -- you use the (non link-local) address of the 
> interface on which the request was received (since that it the 
> network on which the client is located). That's exactly what section 
> 13.1 states:
> 
> Note that the DHCP Client test equipment vendor also appears not to 
> be following standard transmission rules (i.e., to use a link-local 
> address). But, you haven't indicated (I don't think) what the 
> destination address for these DHCPv6 requests are - perhaps they
> were configured to be a GUA (and then it makes sense for the clients
> to use a GUA).

The dst address is the link-scoped multicast address.

The capture of address header of a successful DHCPv6 Solicit and DHCPv6
Advertise executed on a simulator client and simulator server is the
following:

GUA_prefix::2:0:0:4e:2201.546 > ff02::1:2.547:  [udp sum ok]
[...]
fe80::IID.547 > GUA_prefix::2:0:0:4e:2201.546:  [udp sum ok]

> To summarize: - If destination of client is link-local [multicast] 
> address, source SHOULD be link-local.

Agreed.

> (This probably could be a MUST but there might be some odd instances
>  where this is not appropriate - such as point-to-point links.

These odd instances should be described.

> Note also that I don't think there's a restriction that a source 
> address may have wider scope than a destination address.)

I think there may be an RFC about matching scopes of addresses in a same 
packet.

> - If destination of client is GLA, source MUST be GLA (otherwise, 
> replies cannot be returned to the client).

But the dst of a Solicit MUST NOT be a GLA (what I call GUA:
Globally-Unique Address).

[...]

> BV> This seems wrong on the simulator's part. But again, please 
> specify what the destination address is.

It is ff02::1:2.547.

[...]

>> I could see that if a client used a GLA and the server was the 
>> first hop (no relay),

YEs, the Server and Client are normally 'on the same link'.  There is no
Relay.

However, that link is not the typical Ethernet link.  It is a cellular link.

This link has the following nodes: User Equipment, eNodeB, SGW and PGW.

The protocol on User Equipment is native IPv6.  But this is encapsulated
by SGW and PGW in another protocol called GTP.  The GTP protocol is an
IPv4 protocol.  Further, it is an UDP protocol too.

>> it could drop it if the GLA address as it could mean it has no 
>> configuration for that "location". Remember the text from 13.1:
>> 
>>> was received is not a link-local address, then the client is on 
>>> the link identified by the source address in the IP datagram

Er, a link is identified by the src address?  I think this is wrong.  A
link could be identified by a prefix.

>>> (note that this situation can occur only if the server has 
>>> enabled the use of unicast message delivery by the client and
>>> the client has sent a message for which unicast delivery is 
>>> allowed).

Er, I think it is forbidden to use unicast addresses in dst of DHCPv6
Solicit.  You seem to say this is configurable.  But the PGW cant do it.

>> server-unicast option has been configured.

So there is a server-unicast option?  Does this option mean that the
Solicit could be sent to the unicast address to the server, instead of
multicast?

This could solve many problems related to multicast.

>> It may be that they use the source address to determine this 
>> (rather than the destination address, which as you say really 
>> should be used when server receives packet directly)?
>> 
>> 
> I want to not modify the Clients.  The 4 Clients all use LL-in-src. 
> But the Server examples use GUA-in-src.  A Server example is a
> packet trace executed on a simulator that pretends to be like in
> reality. That simulator uses GUA-in-src.  So, I am told, if I want to
> be interoperable to that Server, I must do what that simulator does:
> put GUA-in-src.  So I delete the LL from the interface on the
> Client.
> 
> BV> That seems rather bizarre to me ... not sure how other IPv6 
> services (ND, DAD, etc.) might be impacted? BV> My recommendation is 
> to get the server vendor to fix it

I agree.

> as this is rather broken and others will have problem as well. If
> the server vendor wants to sell their server, they will need to
> correct it.

The server is already sold.  I think if they want to sell more of them
then they must be compatible with existing clients.

It is not by using client and server from same manufacturer that
interoperability is guaranteed.

>> client's source address is. We monitor the destination address 
>> (when packet is received).
> 
> "Does not care" - ok.
> 
> BV> Yes. That is what 100% of the clients I've ever seen send so our 
> server would not be servicing millions of IPv6 clients if it dropped 
> those packets. (And, yes, it is millions based on just one single 
> customer deployment -- and we have many more customers that are
> using IPv6.)

I agree, I see the same.

Alex
[...]

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 Oct 2017 11:09:29 +0200

> as I can see you have not successfully convinced the wg about the need

I can agree with you.

Alex

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 19 Oct 2017 12:54:23 +0000

I wasn’t restricting my discussion of source address to just the Solicit case. In the Solicit case, the Server-Unicast option cannot have been received by the client so obviously that situation does not apply – hence, multicast destination must be used.

- Bernie

On 10/19/17, 5:07 AM, "Alexandre Petrescu" <[email-masked]> wrote:

    

    

    Agreed.

    

    
    
    [...]

    It is ff02::1:2.547.
    
    [...]

    

    

    

    

    I agree.

    

    I agree, I see the same.
    
    Alex
    [...]

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Oct 2017 20:46:32 +0000

Sorry I am late to this discussion, but AERO uses link-local source address for
all DHCPv6 PD messaging. It works in the public domain implementations I
have been working with.

Thanks - Fred

> From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
> Sent: Thursday, October 19, 2017 5:54 AM
> To: Alexandre Petrescu <[email-masked]>
> Cc: [email-masked]
> I wasn’t restricting my discussion of source address to just the Solicit case. In the Solicit case, the Server-Unicast option cannot have
> been received by the client so obviously that situation does not apply – hence, multicast destination must be used.
> 
> - Bernie
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Oct 2017 16:52:43 -0400

> all DHCPv6 PD messaging. It works in the public domain implementations I

It's actually nonsensical to use some other address.   One of the purposes of DHCP is to get addresses, so if the server assumes you already have one, how's that going to work?

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Oct 2017 21:41:49 +0000

Shoulda just kept my mouth shut - but, thanks for the clarification!

Fred

From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, October 20, 2017 1:53 PM
To: Templin, Fred L <[email-masked]>
Cc: Bernie Volz (volz) <[email-masked]>; Alexandre Petrescu <[email-masked]>; [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation - src LL vs GUA

On Oct 20, 2017, at 4:46 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Sorry I am late to this discussion, but AERO uses link-local source address for
all DHCPv6 PD messaging. It works in the public domain implementations I
have been working with.