Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

[Xuxiaohu <[e-mail]>]

Hi Bernie,

Thanks a lot for your comments and suggestions. Please see my response in line.

> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 代表
> Bernie Volz (volz)
> 发送时间: 2012年9月28日 21:36
> 收件人: Xuxiaohu; Tomek Mrugalski; [e-mail]
> 主题: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
> 
> I also think the draft's proposed solution is a bad one. It does make locating the
> 'correct' relay agent information (since in some cases there may be multiple)
> difficult for the server -- sure lack of a link-address value (all 0's) might trigger
> correct processing (advance to next relay), but there are many other cases
> where the server needs to use the 'correct' relay information.

As said in section 20.1.2. Relaying a Message from a Relay Agent,
" If the source address from the IP datagram header of the received
   message is a global or site-local address (and the device on which
   the relay agent is running belongs to only one site), the relay agent
   sets the link-address field to 0 "  This is the case that you pointed out where the server could correctly process the received DHCP messages.

In addition, since this draft is just intended to use stateless DHCPv6, would you please list any concrete cases where the server needs to use the correct relay information?
 
> I think section 13 of RFC 3315 (Transmission of Messages by a Client) was
> meant to cover all aspects of sending packets - not just the 'destination'
> address of the packet.
> 
> While I don't know enough about the 6rd / tunnel environment, I'm not sure
> what other general IPv6 issues lack of a link-local address causes. But, let's put
> that aside as I don't think the client's packet source address is that critical -- it
> just needs to be something that the 'first' hop device can use to send a
> response packet back to the client.
> 
> The intent of using multicast addresses and link-local was to 'force' the client to
> always communicate via the relay agent since lack of relay agent information in
> some of the DHCPv4 interactions caused issues and had to have special
> workarounds to address. I think this is something CRITICAL to keep. The server
> can tell a client it is OK to use a unicast address, but that is not possible in the
> Solicit so I'm not sure how Tomek's proposal to extend this would work -- the
> client has to know what to use BEFORE it starts any interactions with the
> server.
> 
> And, in "traditional" RFC 3315 environments the only communication that was
> known to be possible was link-local (since that was the only address the client
> was known to always have available).
> 
> At the time RFC 3315 was written, if I recall, anycast addresses were still a bit
> new and not completely baked (and it wasn't possible to identify an anycast
> address, it was meant more for network locality issues (which doesn't really
> come into play with communication on a single link, and there wasn't any way
> to "tell" the client what anycast address to use anyway). However, I don't
> really see that an anycast address violates the spirit of RFC 3315 with respect
> to multicast -- in some ways, anycast is a different form of multicast.
> 
> I don't know for sure, but with the intent of using the "6rd BR IPv6 anycast
> address", there would be a relay agent on this end-point (or the DHCPv6 server
> would be there). If a relay agent is present, then there's no issue as the
> DHCPv6 server doesn't really care how the client <-> relay communication
> occurs and has nothing to check to determine how the packet was exchanged.

Sure, if a relay agent is present on that BR, there is no issue for the DHCPv6 servers. However, the implementation of relay agent on that BR is not in accordance with the existing RFC3315 specifications anymore. 

> If the DHCPv6 server is present on that BR, then it can have rules for that
> environment.

Similarly, if a DHCP server is present on that BR, the implementation of DHCP server on that BR is not in accordance with the existing RFC3315 specifications anymore. 

> So I think for this environment, I would prefer to see the transmission rules for
> clients changed to:
> 
> 1. Allow unicast packets to an anycast address from clients (note that there is
> no way to tell an anycast address from a unicast address). Specifically the 6rd
> BR IPv6 anycast address. (There might be text here to recommend use of the
> standard DHCPv6 multicast address (ff02::1:2) if multicast available.)
> 
> 2. Allow the client's source-address to be in whatever scope is appropriate for
> that destination address (i.e., whatever is appropriate for that first hop
> communication even if this is may be a globally routable address). There might
> be text here to recommend use of the link-local address if one is available as
> that limits the message exchange to where it should be.
> 
> And similar changes to accommodate any checking in relays or servers with
> respect to how the client packet was transmitted to that first hop devices.

As such, no matter a DHCP server or a DHCP relay agent is present on that BR, the implementations of DHCP on both the BR (either as a server or a relay agent) and the CE (as a client) should be changed and therefore are not in accordance with the existing RFC3315 specifications anymore.

Best regards,
Xiaohu

> Note that these changes do allow for DHCPv6 client traffic to not be limited to
> a single 'link'.
> 
> This does of course require the client to know that it is in this environment, but
> I think that is a given in the draft's solution too.
> 
> Personally, I think these changes are far better than having to include relay
> functionality into the client and dealing with the fallout.
> 
> Perhaps you've considered this but decided against it? I haven't been following
> this work closely so if this had been suggested but shot down previously, sorry
> for raising it again.
> 
> - Bernie
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Xuxiaohu
> Sent: Thursday, September 27, 2012 10:19 PM
> To: Tomek Mrugalski; [e-mail]
> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
> 
> > -----邮件原件-----
> > 发件人: [e-mail] [mailto:[e-mail]] 代表
> > Tomek Mrugalski
> > 发送时间: 2012年9月28日 5:15
> > 收件人: [e-mail]
> > 主题: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
> >
> > On 12-08-10 14:42, Ted Lemon wrote:
> > > The authors of this draft have requested a working group last call.
> > > The draft explains how DHCP clients operate in an environment where
> > > the interface being configured doesn't support multicast (e.g., 6RD).
> > > If this is a matter of interest to you, please review the draft and
> > > send comments to the list.
> > >
> > > If you are in favor of advancing the draft, please say so on the
> > > list; if nobody supports it, it won't advance.   If you oppose
> > > advancing it, please also say so.   We will determine consensus on
> > > August 24.
> > Hi,
> >
> > I'm terribly sorry for not joining the discussion earlier. I'm in
> > favor of advancing the draft, but not in its current form.
> 
> Hi Tomek,
> 
> Thanks a lot for your comments. As Ole has said earlier, we should do both. I
> fully agree that updating RFC3315 to relax the usage of link-local addresses is
> great. However, we still need a mechanism as described in the current draft so
> far to deal with existing DHCPv6 servers which have been implemented
> according to the current RFC3315 specifications, rather than the RFC3315bis.
> 
> Best regards,
> Xiaohu
> 
> > In my opinion allowing the client to send every message encapsulated
> > in relay-forw will not give you much, but will just bring more
> > problems. In
> > particular:
> >
> > - What would you put in the peer-addr and link-addr fields of the
> > relay-forw message? Bernie's suggestion for putting 0s in peer-addr
> > makes sense, but what about link-addr? Would you put CE's global
> > unicast address there? That would work, but in many cases it would
> > scale up poorly. If you have 1000 CEs in your network, you would
> > potentially need to configure 1000 subnets as the server is supposed
> > to use link-addr to find out those links. Some servers require
> > explicit network topology information (i.e. listing all links that the
> > server is supposed to support). On the other hand, you can define one
> > large subnet that covers all your 6rd CE's global addresses, but that
> > would not work in certain implementations. This leads to a question if
> > the server is supposed to treat all CEs as being the same or different links.
> >
> > - This draft mentions DNS, SIP and NTP options. Are we talking
> > stateless or stateful (or both) here? That should be clarified.
> >
> > - The argument for not having to update 3315 is weak. There are couple
> > inconsistencies in it and there's 3315 bis planned anyway. To be more
> > specific, This statement "client MUST use link-local address..." from
> > 3315 is in direct contradiction with a another sentence from section
> > 18.1 of 3315: "If the client has a source address of sufficient scope
> > that can be used by the server as a return address, and the client has
> > received a Server Unicast option (section 22.12) from the server, the
> > client SHOULD unicast any Request, Renew, Release and Decline messages
> > to the server."
> >
> > Have you considered a different approach? Something like this:
> >
> > 1. Say that any DHCPv6 solution working over tunnels (or
> > non-multicast, no link-local interfaces in general) MUST support server
> unicast.
> > 2. Make the 6rd CE send normal messages (not relayed) from its global
> > address to 6rd BR anycast address.
> > 3. Extend the server unicast to work on solicit, confirm, rebind and
> > inf-request. (update 3315, section 15, second paragraph).
> > 4. Optionally update 3315 to point out inconsistencies regarding
> > source address ("MUST use link-local address..." in section 16 vs.
> > 18.1 "If the client has a source address of sufficient scope...").
> > That is really optional, as any server that implements server unicast
> > already disobeys that rule.
> >
> > This will work on all servers that adhere to sections 17.2.2
> > (advertise) and 18.2.8 (reply): " If the Solicit message was received
> > directly by the server, the server unicasts the Advertise message
> > directly to the client using the address in the source address field
> > from the IP datagram in which the Solicit message was received.".
> >
> > I understand that you want to have it deployed as soon as possible,
> > but we have 3315bis work planned anyway, so there will be changes and
> > that is unavoidable. And with the server-unicast approach, it really
> > isn't that big change.
> >
> > Step 4 will happen anyway. So it's a matter of updating section 15:
> >
> > "A server MUST discard any Solicit, Confirm, Rebind or
> > Information-request messages it receives with a unicast destination
> > address."
> >
> > to
> >
> > "A server MUST discard any Solicit, Confirm, Rebind or
> > Information-request messages it receives with a unicast destination
> > address, unless explicitly configured to use server unicast option
> > with that address.".
> >
> > If we are concerned of any possible side effects in normal deployment
> > scenarios, we may work out some extra safety checks (add "... and the
> > receiving interface does not support multicast nor link-local addresses").
> >
> > Sure, expecting the client to magically know server address when
> > sending the first solicit is odd, but if we want to make DHCPv6 work
> > on non-multicast, no link-local interfaces, we need to make some
> > compromises. I very much prefer that approach, compared to the server
> > reporting that there are 1000s of new relays or server starting to
> > blindly accepting unicast messages.
> >
> > On the other hand, there's RFC6276 that talks about co-locating relay
> > and PD client, so the effort to avoid it is already lost.
> >
> > Editorial comment:
> > "The 6rd CE DHCPv6 relay agent SHOULD use the 6rd BR IPv6 anycast
> > address as the destination address, section 20 of [RFC3315]". That
> > reference to section 20 of RFC3315 is strange. Section 20 describes
> > relay operation. What exactly authors want to point to in this context?
> >
> > Hope that helps,
> > Tomek
> >
> > p.s.
> > Where are we with the 3315bis plans? I know that it is a major work,
> > so it is not easy to commit to it, but there are more and more things
> > that require update. I'm already overburdened with the failover work
> > and other stuff, but for such a grand purpose I will find some time.
> >
> >
> >
> > _______________________________________________
> > dhcwg mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg