From: "Bernie Volz (volz)" <volz@cisco.com>
To: Ted Lemon <Ted.Lemon@nominum.com>, Xuxiaohu <xuxiaohu@huawei.com>
Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
Thread-Index: AQHNnPUoSDMOAnuzpUmlatl1eCUEGJee/TdwgAC6FeCAANr4AIAAZHYA//+0lMA=
Date: Sat, 29 Sep 2012 03:37:45 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F507C50@xmb-rcd-x04.cisco.com>
References: <4D779082-B182-4728-9534-39456573682E@nominum.com>
 <5064C1D6.6070201@gmail.com>
 <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755D36B@szxeml525-mbx.china.huawei.com>
 <489D13FBFA9B3E41812EA89F188F018E0F50792C@xmb-rcd-x04.cisco.com>
 <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755D57E@szxeml525-mbx.china.huawei.com>
 <96AEEED6-F7E2-4C0D-84B8-B4ED0CF5E054@nominum.com>
In-Reply-To: <96AEEED6-F7E2-4C0D-84B8-B4ED0CF5E054@nominum.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
Precedence: list

> This is why we are talking about updating RFC3315.

Yup ... my point exactly.

As stated in RFC3315 section 13, a separate document may detail how to appl=
y DHCPv6 to other link types. I think it is rather natural to have to relax=
 some of the unicast restrictions if multicast isn't used (how else would t=
his work). I think this is perfectly in line with what was intended by such=
 a document.

I would also like to make sure we design something that can support all of =
DHCPv6 and not something limited to Information-Request/Reply. Also, perhap=
s I missed it but I see nothing in your document that states it is limited =
to Information-Request/Reply? But again, even if it did say that, I would s=
till want us to specify something that could accommodate the full DHCPv6 ra=
nge of messages.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20
Sent: Friday, September 28, 2012 10:59 PM
To: Xuxiaohu
Cc: Bernie Volz (volz); Tomek Mrugalski; dhcwg@ietf.org
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

On Sep 28, 2012, at 10:52 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> In addition, since this draft is just intended to use stateless DHCPv6, w=
ould you please list any concrete cases where the server needs to use the c=
orrect relay information?

The reason that even information request messages are required to be broadc=
ast is that a device that does stateful and then stateless should get the s=
ame answers, and this can't happen if the relays aren't in the path and are=
n't able to add their options.


Also, it seems to me that your tunnel draft is applicable to prefix delegat=
ion; I realize this isn't an intended use that you have in mind, but it's c=
ertainly a perfectly valid one, and someone will no doubt want it at some l=
ater date.   So we shouldn't design a solution that we're not comfortable w=
ith in that case.

> 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 re=
lay agent) and the CE (as a client) should be changed and therefore are not=
 in accordance with the existing RFC3315 specifications anymore.

This is why we are talking about updating RFC3315.