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

[Alexandre Petrescu <[e-mail]>]

Le 18/10/2017 à 22:35, Bernie Volz (volz) a écrit :
> The server vendor is in error here ... as far as I know, clients use 
> the link-local address.

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

[...]

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

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:
>> 
>>> *  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

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.

>> Also, some servers could respond with Use Multicast unless 
>> 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'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?
> 
> 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?
> 
> 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.

>> 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?
> 
> 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
[...]