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

Leaf yeh <leaf.y.yeh@huawei.com> Tue, 25 September 2012 07:48 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 681B721F890F for <dhcwg@ietfa.amsl.com>; Tue, 25 Sep 2012 00:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 DJS54ELt3Y46 for <dhcwg@ietfa.amsl.com>; Tue, 25 Sep 2012 00:48:04 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7B18521F8905 for <dhcwg@ietf.org>; Tue, 25 Sep 2012 00:48:03 -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 ALA15924; Tue, 25 Sep 2012 07:48:02 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 25 Sep 2012 08:47:07 +0100
Received: from SZXEML432-HUB.china.huawei.com (10.72.61.60) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 25 Sep 2012 08:47:44 +0100
Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.119]) by SZXEML432-HUB.china.huawei.com ([10.72.61.60]) with mapi id 14.01.0323.003; Tue, 25 Sep 2012 15:47:41 +0800
From: Leaf yeh <leaf.y.yeh@huawei.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
Thread-Index: AQHNdvWqSDMOAnuzpUmlatl1eCUEGJdX0gXAgBWNlcCALAfOgIABToyQ
Date: Tue, 25 Sep 2012 07:47:41 +0000
Message-ID: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C473EBE@SZXEML510-MBS.china.huawei.com>
References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C4668ED@SZXEML510-MBS.china.huawei.com> <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com>
In-Reply-To: <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.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
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
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: Tue, 25 Sep 2012 07:48:05 -0000

Ted - But how does this work?   The relay agent is co-located with the client, right?   So the client sends a DHCP packet, and the relay agent receives it, and then it relays it up the tunnel, right?   But on what interface does the client send the packet?   On what interface does the relay agent listen?

My reading from the draft sounds:  a. The relay is co-located with the client on the 6rd CE;  b. The relay got the packet from the client internally within the 6rd CE;


Ted - If the answer is that the client sends the packet on the tunnel interface, you haven't solved the stated problem, because you still are out of spec with respect to RFC3315: you still don't have a link-local address to use as a source address.

I suppose the draft intends to use the address of the relay to communicate with the server, then avoids the requirement for the LLA of the client. But the client and the relay sounds in the same device, there is no explicit interface between the client and the relay.


Ted - Second, how does the relay avoid relaying packets from _other_ hosts?

I guess CE might relay packet from other host, but the peer address in the Relay-Forward message will not be the unspecified address (::).


Ted - Third, how does the DHCP server know what configuration information to send?

I guess the server might assign the configuration to the client per the address of the relay, while the peer address in the Relay-Forward message will be the unspecified address (::).

Pls. the authors of the draft correct me if I got something wrong.


Best Regards,
Leaf



-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com] 
Sent: Tuesday, September 25, 2012 12:00 AM
To: Leaf yeh
Cc: dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

First of all, I apologize for having taken so long to look at this draft.   The working group is doing quite a bit of work, and it's hard to stay on top of it all.

I just gave the draft a thorough read, and I have come away with it not knowing how I would write a shepherd doc for the draft, because I don't really understand what it's supposed to do.   The motivation for the draft is to be able to get a DHCP packet up through a tunnel to a DHCP server on the far end of the tunnel.   The solution is to use a relay agent to get the packet through the tunnel.

But how does this work?   The relay agent is co-located with the client, right?   So the client sends a DHCP packet, and the relay agent receives it, and then it relays it up the tunnel, right?   But on what interface does the client send the packet?   On what interface does the relay agent listen?

If the answer is that the client sends the packet on the tunnel interface, you haven't solved the stated problem, because you still are out of spec with respect to RFC3315: you still don't have a link-local address to use as a source address.   If the answer is that the client sends the packet on some other interface, that has several problems.

The first problem is that now the relay agent has to listen on the interface the client will transmit on.   But that interface is a configurable interface in its own right.  How do we distinguish between DHCP packets intended to configure that interface, and DHCP packets intended to go up the tunnel?

Second, how does the relay avoid relaying packets from _other_ hosts?

Third, how does the DHCP server know what configuration information to send?

I think it's quite possible that I have simply failed to understand what this draft is trying to do, and that if I did understand, all of these questions would be satisfactorily answered.   But the point of writing a draft is to allow a new reader to understand the proposed solution to the problem; since I haven't been able to accurately glean that answer from the draft as written, I think the draft needs more work.

As for the question of consensus, Bernie Volz also raised some questions about the draft which Leaf tried to answer, but as far as I can tell did not actually answer.   Although we do seem to have a consensus to advance the draft, without answering Bernie's questions and mine, we aren't actually ready to advance yet.

So I would appreciate it if the authors and the people who said they wanted the draft to advance, and whom I assume therefore carefully reviewed the draft, would make an effort to fix the draft so that it's possible for a naive reader like me to understand what it says to do.

Thanks!