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

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

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.

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.

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

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.

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