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

[Xuxiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: [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