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

["Templin, Fred L" <[e-mail]>]

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

> -----Original Message-----
> From: dhcwg [mailto:[e-mail]] On Behalf Of Bernie Volz (volz)
> Sent: Thursday, October 19, 2017 5:54 AM
> To: Alexandre Petrescu <[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
> 
> 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" <[e-mail]> wrote:
> 
>     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
>     [...]
> 
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg