Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
Leaf yeh <leaf.y.yeh@huawei.com> Fri, 28 September 2012 03:47 UTC
Return-Path: <leaf.y.yeh@huawei.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD1721F84CE for <dhcwg@ietfa.amsl.com>; Thu, 27 Sep 2012 20:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.416
X-Spam-Level:
X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiWjBnWzZrsi for <dhcwg@ietfa.amsl.com>; Thu, 27 Sep 2012 20:47:44 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B7BC321F8471 for <dhcwg@ietf.org>; Thu, 27 Sep 2012 20:47:43 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALC85499; Fri, 28 Sep 2012 03:47:42 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Sep 2012 04:46:55 +0100
Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Sep 2012 04:47:40 +0100
Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.192]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Fri, 28 Sep 2012 11:47:20 +0800
From: Leaf yeh <leaf.y.yeh@huawei.com>
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
Thread-Index: AQHNnPUoSDMOAnuzpUmlatl1eCUEGJefHSeA
Date: Fri, 28 Sep 2012 03:47:19 +0000
Message-ID: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3CE34119@szxeml546-mbx.china.huawei.com>
References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <5064C1D6.6070201@gmail.com>
In-Reply-To: <5064C1D6.6070201@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.83.152]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Sep 2012 03:47:45 -0000
Tomek - Where are we with the 3315bis plans? I know that it is a major work, ..., but for such a grand purpose I will find some time. I'd also like to join the plan if I could provide any help. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Friday, September 28, 2012 5:15 AM To: dhcwg@ietf.org Subject: 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. 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 dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Ted Lemon
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Xuxiaohu
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Bernie Volz (volz)
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… g57775
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Zhangdacheng (Dacheng)
- [dhcwg] 答复: WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Guodayong
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… sunqi
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Leaf yeh
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Leaf yeh
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Ted Lemon
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Ole Trøan
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Ted Lemon
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Xuxiaohu
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Ole Trøan
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Ted Lemon
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Ted Lemon
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Ole Trøan
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Ted Lemon
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Leaf yeh
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Ole Trøan
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Ted Lemon
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Tomek Mrugalski
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Xuxiaohu
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Leaf yeh
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Bernie Volz (volz)
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Xuxiaohu
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Ted Lemon
- Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01… Bernie Volz (volz)