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

["Bernie Volz (volz)" <[e-mail]>]

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

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:

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

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'm confused as I think you are saying in:

>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:[e-mail]] 
Sent: Wednesday, October 18, 2017 1:42 PM
To: Bernie Volz (volz) <[e-mail]>
Cc: [e-mail]
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 à 18:31, Bernie Volz (volz) a écrit :
> 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).

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

> 
> 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:[e-mail]]
> Sent: Wednesday, October 18, 2017 12:01 PM
> To: Bernie Volz (volz) <[e-mail]>
> Cc: [e-mail]
> 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 à 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
>>
>> On 10/18/17, 10:06 AM, "Alexandre Petrescu"
>> <[e-mail]> wrote:
>>
>> 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:[e-mail]] Sent: Thursday, July 13,
>>> 2017 12:01 PM To: Bernie Volz (volz) <[e-mail]> Cc:
>>> [e-mail] 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
>>>
>>
>>