From Ted.Lemon@nominum.com Sun Feb 2 05:33:58 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8922A1A00D0 for ; Sun, 2 Feb 2014 05:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSSa3pIdl3uy for ; Sun, 2 Feb 2014 05:33:56 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 96CEF1A00CF for ; Sun, 2 Feb 2014 05:33:56 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUu5JQIDavA8F87IIBYXJmDzkeSLr33u1@postini.com; Sun, 02 Feb 2014 05:33:52 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 425451B8327 for ; Sun, 2 Feb 2014 05:33:52 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 16613190052; Sun, 2 Feb 2014 05:33:52 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 2 Feb 2014 05:33:51 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <52EBC3EA.1020104@innovationslab.net> Date: Sun, 2 Feb 2014 08:33:49 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <52EBC3EA.1020104@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" , draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 13:33:58 -0000 On Jan 31, 2014, at 10:40 AM, Brian Haberman = wrote: > I have done my AD Evaluation of draft-ietf-dhc-dhcpv6-unknown-msg > (since Ted is listed as a co-author). I only have a few points of > discussion on this document before we move it along in the publication > process. I am by no means a DHCP expert, so let me know if I have = gone > off in the weeds... >=20 > 1. I would like to see a little more clarity in the purpose of this > document. It does a good job clarifying what a relay agent should do > with existing messages, but I think it would be useful to spell out = that > is document is also dictating how future documents that define new = DHCP > messages should specify relay behavior. This is a good suggestion (actually, these are all good suggestions!). = I think the right solution to this is twofold. First, the following = change should be made at the end of 4.1 (this also addresses your point = 2): OLD: In the case that a new type of message is sent by the server to a relay agent but the relay agent does not recognize it, the message is put into a Relay-forward message and sent to the server. NEW: New DHCP message types may be defined in future that are intended to convey information from DHCP servers to relay agents. Relay agents that do not implement these messages will not recognize that such messages are intended for them. A relay agent that implements this specification will necessarily forward such messages to the DHCP servers to which it is configured to relay client messages. At this time, no messages of this variety have been specified. If such a message is specified in the future, the specification could include text something like the following: DHCP servers that send this new message type MAY, when they receive a relayed message of this type, mark the relay agent to which the message was sent as not implementing messages of this type. In this case, the DHCP server MAY implement a strategy of probing the relay agent occasionally to see if it has been updated. However, this is not strictly necessary, since DHCP does not provide a signaling message for rejecting unexpected message types, and therefore DHCP servers are not expected to respond to such messages. Documents specifying new message types should use different types for communicating *to* relay agents than are used for communicating = *from* relay agents, so that no confusion can occur where a message sent to a relay agent is sent back to the DHCP server, which then tries to process it as if it came from a relay agent. In addition to this change, I'd propose the following change to the = abstract: OLD: DHCPv6 is not specific about handling messages with unknown types. This memo describes the problems and defines how a DHCPv6 server, client or relay agent should behave when receiving unknown DHCPv6 messages. This document updates RFC3315. NEW: DHCPv6 is not specific about handling messages with unknown types. This memo describes the problems and defines how a DHCPv6 server, client or relay agent should behave when receiving unknown DHCPv6 messages. This document also provides advice for authors of future documents defining new messages sent from DHCP servers to DHCP relay agents, and should be read by potential authors of such documents. This document updates RFC3315. > 2. In section 4.1, the text talks about targeting a message based on = its > message type. To me, that suggests that a relay must know about all > DHCP message types. I thought (feel free to correct me) that relay > agents were mostly stateless and would forward all messages not > addressed to them to the configured DHCP server. This assumes that = all > Relay-Reply messages are addressed to the relay directly. That is the general effect of 4.1, but I hope the text above makes = clearer what the issues are, both to you and to other future readers of = the document. > 3. After having an exchange with Ralph Droms, I want to ask about > messages from servers to clients. If those messages are *not* in a > Relay-Reply message, but are received by a relay, should those = messages > be dropped? If a server->client message is forwarded to a server by = the > relay, should it be dropped by the server? If this happens, it's an implementation bug: the DHCP server is not in = conformance with RFC3315. I therefore think that we don't need to = address it, although it would certainly break things if an = implementation were to erroneously do that. I think such an = implementation would never make it to the field, because it simply = wouldn't work. > 4. Is there a need to specifically discuss the behavior of single > devices that have both a relay agent and a client running at the same = time? Hm. We generally treat these as two separate implementations that = happen to be running on the same hardware. Also I think usually it's a = client and a server, not a relay agent and a server. We could add text = addressing this, but I don't really see this coming up in practice. = There isn't similar text in RFC3315, for instance, and we haven't seen = evidence of implementors getting this wrong. > 5. Also from Ralph... Could section 5 simply be written as "A client = or > server MUST silently discard any received DHCPv6 message with an = unknown > message type."? Yes, I think this is a good edit. Qi, do you have time to do these = edits? From sunqi.csnet.thu@gmail.com Sun Feb 2 06:53:16 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D151B1A00DE for ; Sun, 2 Feb 2014 06:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRLmHRC92tEl for ; Sun, 2 Feb 2014 06:53:14 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DD5561A00E5 for ; Sun, 2 Feb 2014 06:53:10 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id kl14so6206652pab.1 for ; Sun, 02 Feb 2014 06:53:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PvSSUMHcihn7NDQ+E91NWs9Tcmkk+tlp4CxlKdS8Py0=; b=hDPjR2xb51JV8xUGzf0JEe9dHHiChBAZv72VX4vO7ISYdlWdB3N9moMugH2oKEBnIu xXuVKTPwNise57KcsrgXIpG4Na1tO2A6LJ2SUTIsh/suEMTXOkcBGa6UvjXDAiKaYc/L k7zcy7jKirr9GwwjWMUSxkG/rMCvl/zWGRdHn3Lp+8XVmbwD5ci9GqtrSYZLReHe/tlS ZmAunpwYXR8klsKYxzQwZ1gds0wGAbCcqd/guQojWo7FtARsSmw6sDuWw9HUZkX1Q0z3 0BSOWlp2BWr8ePD7ENEzqqYibvee6tUZC7QRre+VDuLmg+1TrzQPMhx4Ws+opWvrk8FW kXuA== X-Received: by 10.68.185.1 with SMTP id ey1mr32444296pbc.33.1391352786565; Sun, 02 Feb 2014 06:53:06 -0800 (PST) Received: from [192.168.0.109] ([27.213.251.185]) by mx.google.com with ESMTPSA id i10sm120563862pat.11.2014.02.02.06.53.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Feb 2014 06:53:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: Date: Sun, 2 Feb 2014 22:52:55 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <63DDD593-2421-4A18-A893-C2BEAF836243@gmail.com> References: <52EBC3EA.1020104@innovationslab.net> To: Ted Lemon , Brian Haberman X-Mailer: Apple Mail (2.1085) Cc: "dhcwg@ietf.org WG" , draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 14:53:17 -0000 Dear Brian & Ted, Thank you so much for your evaluation/suggestions! I think the = comments/changes are very helpful to make the text clearer.=20 I will do the updates asap. Thank you again! //Sorry for late response because of the Chinese Spring Festival.=20 Best Regards, Qi On 2014-2-2, at =E4=B8=8B=E5=8D=889:33, Ted Lemon wrote: > On Jan 31, 2014, at 10:40 AM, Brian Haberman = wrote: >> I have done my AD Evaluation of draft-ietf-dhc-dhcpv6-unknown-msg >> (since Ted is listed as a co-author). I only have a few points of >> discussion on this document before we move it along in the = publication >> process. I am by no means a DHCP expert, so let me know if I have = gone >> off in the weeds... >>=20 >> 1. I would like to see a little more clarity in the purpose of this >> document. It does a good job clarifying what a relay agent should do >> with existing messages, but I think it would be useful to spell out = that >> is document is also dictating how future documents that define new = DHCP >> messages should specify relay behavior. >=20 > This is a good suggestion (actually, these are all good suggestions!). = I think the right solution to this is twofold. First, the following = change should be made at the end of 4.1 (this also addresses your point = 2): >=20 > OLD: > In the case that a new type of message is sent by the server to a > relay agent but the relay agent does not recognize it, the message = is > put into a Relay-forward message and sent to the server. > NEW: > New DHCP message types may be defined in future that are intended to > convey information from DHCP servers to relay agents. Relay agents > that do not implement these messages will not recognize that such > messages are intended for them. A relay agent that implements this > specification will necessarily forward such messages to the DHCP > servers to which it is configured to relay client messages. >=20 > At this time, no messages of this variety have been specified. > If such a message is specified in the future, the specification = could > include text something like the following: >=20 > DHCP servers that send this new message type MAY, when they > receive a relayed message of this type, mark the relay agent to > which the message was sent as not implementing messages of this > type. In this case, the DHCP server MAY implement a strategy > of probing the relay agent occasionally to see if it has been > updated. >=20 > However, this is not strictly necessary, since DHCP does not provide > a signaling message for rejecting unexpected message types, and > therefore DHCP servers are not expected to respond to such messages. >=20 > Documents specifying new message types should use different types = for > communicating *to* relay agents than are used for communicating = *from* > relay agents, so that no confusion can occur where a message sent to > a relay agent is sent back to the DHCP server, which then tries to > process it as if it came from a relay agent. >=20 > In addition to this change, I'd propose the following change to the = abstract: >=20 > OLD: > DHCPv6 is not specific about handling messages with unknown types. > This memo describes the problems and defines how a DHCPv6 server, > client or relay agent should behave when receiving unknown DHCPv6 > messages. This document updates RFC3315. >=20 > NEW: > DHCPv6 is not specific about handling messages with unknown types. > This memo describes the problems and defines how a DHCPv6 server, > client or relay agent should behave when receiving unknown DHCPv6 > messages. This document also provides advice for authors of future > documents defining new messages sent from DHCP servers to DHCP relay > agents, and should be read by potential authors of such documents. > This document updates RFC3315. >=20 >> 2. In section 4.1, the text talks about targeting a message based on = its >> message type. To me, that suggests that a relay must know about all >> DHCP message types. I thought (feel free to correct me) that relay >> agents were mostly stateless and would forward all messages not >> addressed to them to the configured DHCP server. This assumes that = all >> Relay-Reply messages are addressed to the relay directly. >=20 > That is the general effect of 4.1, but I hope the text above makes = clearer what the issues are, both to you and to other future readers of = the document. >=20 >> 3. After having an exchange with Ralph Droms, I want to ask about >> messages from servers to clients. If those messages are *not* in a >> Relay-Reply message, but are received by a relay, should those = messages >> be dropped? If a server->client message is forwarded to a server by = the >> relay, should it be dropped by the server? >=20 > If this happens, it's an implementation bug: the DHCP server is not in = conformance with RFC3315. I therefore think that we don't need to = address it, although it would certainly break things if an = implementation were to erroneously do that. I think such an = implementation would never make it to the field, because it simply = wouldn't work. >=20 >> 4. Is there a need to specifically discuss the behavior of single >> devices that have both a relay agent and a client running at the same = time? >=20 > Hm. We generally treat these as two separate implementations that = happen to be running on the same hardware. Also I think usually it's a = client and a server, not a relay agent and a server. We could add text = addressing this, but I don't really see this coming up in practice. = There isn't similar text in RFC3315, for instance, and we haven't seen = evidence of implementors getting this wrong. >=20 >> 5. Also from Ralph... Could section 5 simply be written as "A client = or >> server MUST silently discard any received DHCPv6 message with an = unknown >> message type."? >=20 > Yes, I think this is a good edit. Qi, do you have time to do these = edits? >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Sun Feb 2 06:57:49 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415D71A00E3 for ; Sun, 2 Feb 2014 06:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPodc-j1ajkC for ; Sun, 2 Feb 2014 06:57:48 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1087A1A00DE for ; Sun, 2 Feb 2014 06:57:48 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUu5c5xdl1g0FqSL9SBHNC8gKSXdWS9ym@postini.com; Sun, 02 Feb 2014 06:57:44 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id ABA9C1B82FD for ; Sun, 2 Feb 2014 06:57:43 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 9EB60190052; Sun, 2 Feb 2014 06:57:43 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 2 Feb 2014 06:57:43 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <63DDD593-2421-4A18-A893-C2BEAF836243@gmail.com> Date: Sun, 2 Feb 2014 09:57:42 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <0886E9BE-371B-4808-A320-E6B773D15FAE@nominum.com> References: <52EBC3EA.1020104@innovationslab.net> <63DDD593-2421-4A18-A893-C2BEAF836243@gmail.com> To: Qi Sun X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" , Brian Haberman , draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 14:57:49 -0000 On Feb 2, 2014, at 9:52 AM, Qi Sun wrote: > //Sorry for late response because of the Chinese Spring Festival.=20 You responded about an hour after my message, so I think you are = blameless. Happy New Year! From tomasz.mrugalski@gmail.com Sun Feb 2 07:08:00 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28EC1A00DE for ; Sun, 2 Feb 2014 07:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqQE2BjDEewK for ; Sun, 2 Feb 2014 07:07:58 -0800 (PST) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA781A00D9 for ; Sun, 2 Feb 2014 07:07:58 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id d10so3255772eaj.4 for ; Sun, 02 Feb 2014 07:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cuV1zWS3ppUpnO44hYli3nt9bnsyarxMS/sB6PsIUt4=; b=OOpNKn9HNAUZrLSpAqF/WIYO0i5Q7eB3zDBlLGWQMihFJNez/up49IGdB6lEddDjqw PmcBME9yDaxP4pYqftp8zEDgsO6c7j1pLLK2r9RpXDs9fack3Kiv2S40EY+b4JVI/uH3 NKgyEz/63cloxglkcfSO1AO+EDEM6wByhyVM0hXaruO2acu0L9C8ZPm24MrN4OxhY3IM hrVwo5rt0IwY20TQ7ls5TIdvdErY6JVcb1wnvXAwXC7kWXkLXcZ0gVSg3TcIKWh4QBp+ 3EG3h5j3itjbNJbXfY1T2PWob8I61cPJmf9FdruGMLPJa/jCS5GNlwPcfmyIv8NMYZs2 iOhQ== X-Received: by 10.14.179.73 with SMTP id g49mr2000434eem.71.1391353673506; Sun, 02 Feb 2014 07:07:53 -0800 (PST) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id 46sm62775274ees.4.2014.02.02.07.07.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Feb 2014 07:07:52 -0800 (PST) Message-ID: <52EE6D56.4090908@gmail.com> Date: Sun, 02 Feb 2014 17:07:50 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ted Lemon , Brian Haberman References: <52EBC3EA.1020104@innovationslab.net> In-Reply-To: X-Enigmail-Version: 1.5.2 X-TagToolbar-Keys: D20140202170750734 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dhcwg@ietf.org WG" , draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 15:08:00 -0000 On 02.02.2014 14:33, Ted Lemon wrote: >> 5. Also from Ralph... Could section 5 simply be written as "A client or >> server MUST silently discard any received DHCPv6 message with an unknown >> message type."? > > Yes, I think this is a good edit. I would extend the text a bit with "The server or client MAY log the fact.". Silently dropping a message that is typically network setup problem may hide problems and make their debugging harder. If you configured your relay to send message X, but your server is not capable of understanding it, then why did you configure your relay to send it in the first place? Also, if your network has clients that send message Y and your server does not know what to do with it, perhaps its time upgrade your server? Or forbid those particular clients if that new behavior is not welcome in a given network. On the other hand, some people may afraid that their server could be spammed with messages of bogus type and filling in syslog with useless junk. Given those two arguments, MAY seems like a good compromise for the logging. Tomek From Ted.Lemon@nominum.com Sun Feb 2 07:12:31 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22DD1A00EB for ; Sun, 2 Feb 2014 07:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKRYM53jyh9a for ; Sun, 2 Feb 2014 07:12:30 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 48F2C1A00D9 for ; Sun, 2 Feb 2014 07:12:30 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUu5gWtbOCJKac67brW/ux1ENrwoFgjMC@postini.com; Sun, 02 Feb 2014 07:12:26 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 044671B82FD for ; Sun, 2 Feb 2014 07:12:26 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id F0F96190052; Sun, 2 Feb 2014 07:12:25 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 2 Feb 2014 07:12:25 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <52EE6D56.4090908@gmail.com> Date: Sun, 2 Feb 2014 10:12:22 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <094F910C-AEC2-48CF-8BDA-4A337978BE9A@nominum.com> References: <52EBC3EA.1020104@innovationslab.net> <52EE6D56.4090908@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" , Brian Haberman , draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 15:12:31 -0000 On Feb 2, 2014, at 11:07 AM, Tomek Mrugalski = wrote: > I would extend the text a bit with "The server or client MAY log the > fact.". Silently dropping a message that is typically network setup > problem may hide problems and make their debugging harder. The "silent" in "silently drop" conventionally means "drop without = sending any response," not "drop without making any record that you = dropped it." Silently dropped messages are often either logged or = recorded in statistics counters, and I'm pretty sure RFC 3315 recommends = this practice and explains that that's what "silently drop" means. Hm, = actually no, neither 3315 nor 2131 explains, but they do use the term in = this way. I know I've seen it documented somewhere... :} Anyway, it certainly could be clarified, but I don't think it's strictly = necessary, given that it's not clarified in 3315. Maybe you could just = add it to the terminology section in 3315-bis? From brian@innovationslab.net Mon Feb 3 06:47:31 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8731A0118 for ; Mon, 3 Feb 2014 06:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g__rTqg_-EDR for ; Mon, 3 Feb 2014 06:47:29 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 31D9A1A002A for ; Mon, 3 Feb 2014 06:47:29 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 28EB9880D1; Mon, 3 Feb 2014 06:17:12 -0800 (PST) Received: from 10252516.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 185C61368157; Mon, 3 Feb 2014 06:17:02 -0800 (PST) Message-ID: <52EFA4E8.2040404@innovationslab.net> Date: Mon, 03 Feb 2014 09:17:12 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ted Lemon References: <52EBC3EA.1020104@innovationslab.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CsSxC4iwMbj6UuUOeupIa4cTOppLJMeea" Cc: "dhcwg@ietf.org WG" , draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:47:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CsSxC4iwMbj6UuUOeupIa4cTOppLJMeea Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/2/14 8:33 AM, Ted Lemon wrote: > On Jan 31, 2014, at 10:40 AM, Brian Haberman = wrote: >> I have done my AD Evaluation of draft-ietf-dhc-dhcpv6-unknown-msg >> (since Ted is listed as a co-author). I only have a few points of >> discussion on this document before we move it along in the publication= >> process. I am by no means a DHCP expert, so let me know if I have gon= e >> off in the weeds... >> >> 1. I would like to see a little more clarity in the purpose of this >> document. It does a good job clarifying what a relay agent should do >> with existing messages, but I think it would be useful to spell out th= at >> is document is also dictating how future documents that define new DHC= P >> messages should specify relay behavior. >=20 > This is a good suggestion (actually, these are all good suggestions!). = I think the right solution to this is twofold. First, the following c= hange should be made at the end of 4.1 (this also addresses your point 2)= : >=20 > OLD: > In the case that a new type of message is sent by the server to a > relay agent but the relay agent does not recognize it, the message i= s > put into a Relay-forward message and sent to the server. > NEW: > New DHCP message types may be defined in future that are intended to= > convey information from DHCP servers to relay agents. Relay agents= > that do not implement these messages will not recognize that such > messages are intended for them. A relay agent that implements this= > specification will necessarily forward such messages to the DHCP > servers to which it is configured to relay client messages. >=20 Hmm... The text above talks about messages from servers to relays. Would these messages be coming from servers *not* identified in the relay's configuration? That is, do you envision relays seeing messages from servers that the relay is not configured to use for received client messages? If not, shouldn't the guidance be that relays should silently drop them? If they can receive messages from servers they don't know about, the relays will forward these messages to *other* servers and they should drop them. > At this time, no messages of this variety have been specified. > If such a message is specified in the future, the specification coul= d > include text something like the following: >=20 > DHCP servers that send this new message type MAY, when they > receive a relayed message of this type, mark the relay agent to > which the message was sent as not implementing messages of this > type. In this case, the DHCP server MAY implement a strategy > of probing the relay agent occasionally to see if it has been > updated. >=20 > However, this is not strictly necessary, since DHCP does not provide= > a signaling message for rejecting unexpected message types, and > therefore DHCP servers are not expected to respond to such messages.= >=20 > Documents specifying new message types should use different types fo= r > communicating *to* relay agents than are used for communicating *fro= m* > relay agents, so that no confusion can occur where a message sent to= > a relay agent is sent back to the DHCP server, which then tries to > process it as if it came from a relay agent. Almost sounds like DHCP needs a capabilities negotiation between servers and relays. :) >=20 > In addition to this change, I'd propose the following change to the abs= tract: >=20 > OLD: > DHCPv6 is not specific about handling messages with unknown types. > This memo describes the problems and defines how a DHCPv6 server, > client or relay agent should behave when receiving unknown DHCPv6 > messages. This document updates RFC3315. >=20 > NEW: > DHCPv6 is not specific about handling messages with unknown types. > This memo describes the problems and defines how a DHCPv6 server, > client or relay agent should behave when receiving unknown DHCPv6 > messages. This document also provides advice for authors of future > documents defining new messages sent from DHCP servers to DHCP relay= > agents, and should be read by potential authors of such documents. > This document updates RFC3315. >=20 Ok. >> 2. In section 4.1, the text talks about targeting a message based on i= ts >> message type. To me, that suggests that a relay must know about all >> DHCP message types. I thought (feel free to correct me) that relay >> agents were mostly stateless and would forward all messages not >> addressed to them to the configured DHCP server. This assumes that al= l >> Relay-Reply messages are addressed to the relay directly. >=20 > That is the general effect of 4.1, but I hope the text above makes clea= rer what the issues are, both to you and to other future readers of the d= ocument. >=20 Once my follow-up question is answered, I will have a better grasp on the clarity. >> 3. After having an exchange with Ralph Droms, I want to ask about >> messages from servers to clients. If those messages are *not* in a >> Relay-Reply message, but are received by a relay, should those message= s >> be dropped? If a server->client message is forwarded to a server by t= he >> relay, should it be dropped by the server? >=20 > If this happens, it's an implementation bug: the DHCP server is not in = conformance with RFC3315. I therefore think that we don't need to addre= ss it, although it would certainly break things if an implementation were= to erroneously do that. I think such an implementation would never mak= e it to the field, because it simply wouldn't work. >=20 Ok. >> 4. Is there a need to specifically discuss the behavior of single >> devices that have both a relay agent and a client running at the same = time? >=20 > Hm. We generally treat these as two separate implementations that hap= pen to be running on the same hardware. Also I think usually it's a cli= ent and a server, not a relay agent and a server. We could add text add= ressing this, but I don't really see this coming up in practice. There = isn't similar text in RFC3315, for instance, and we haven't seen evidence= of implementors getting this wrong. >=20 If the pairing of a client and relay agent is not expected, this may not be an issue. Regards, Brian --CsSxC4iwMbj6UuUOeupIa4cTOppLJMeea Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS76TuAAoJEBOZRqCi7goqOq0H/jfh8mq81YUfq3BXGT7X0uZi 2kS4wRVF4/EXhYN0mqein2qaUZST5OMLhGEPNQEYV8XEoP9XIpcmc/cmukIornwn C+BtWYAkQgp6cj0xu5SoO5Ibf7FPzxre/6l0VTTrWCHLuDMYidwUmq7OHOtN0rnN bobF/jzpgbztQC1YBcb+ZhIC7DhtQXYSjf+ND5JHWE3MniB/GiAY6yjfvS9iqWQy 2SR++q4yg/27RkUJrWvmnwLnOx8Le/D74k+E2CAhHC/wfk5IjLLOHoOcMhIajJ// O15L2j9VGg5k9XFua1qrz0wrh3qLJfA46PczEtn5VIYkIy3kSZF4adlCT+8nvTU= =6/Td -----END PGP SIGNATURE----- --CsSxC4iwMbj6UuUOeupIa4cTOppLJMeea-- From Ted.Lemon@nominum.com Mon Feb 3 06:48:20 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE831A0124 for ; Mon, 3 Feb 2014 06:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asusqfuLZBYO for ; Mon, 3 Feb 2014 06:48:18 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 590621A011B for ; Mon, 3 Feb 2014 06:48:18 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUu+sMoP1xvh29CGTVofcmiFe98VFVEtc@postini.com; Mon, 03 Feb 2014 06:48:18 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 305BA1B82F5 for ; Mon, 3 Feb 2014 06:48:18 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2930B190052; Mon, 3 Feb 2014 06:48:18 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Feb 2014 06:48:18 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <52EFA4E8.2040404@innovationslab.net> Date: Mon, 3 Feb 2014 09:48:15 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <52EBC3EA.1020104@innovationslab.net> <52EFA4E8.2040404@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" , draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:48:20 -0000 On Feb 3, 2014, at 9:17 AM, Brian Haberman = wrote: > Hmm... The text above talks about messages from servers to relays. > Would these messages be coming from servers *not* identified in the > relay's configuration? That is, do you envision relays seeing = messages > from servers that the relay is not configured to use for received = client > messages? If not, shouldn't the guidance be that relays should = silently > drop them? If they can receive messages from servers they don't know > about, the relays will forward these messages to *other* servers and > they should drop them. Yes, I had a bit of a think about that when replying to your review = yesterday, and thought about it some more just now. I don't think we = can address that here=97we don't know what these messages will look = like, or even if they will be defined, so trying to anticipate their = security implications is a bit futile. I think the language I proposed = is adequate for the time being, and does the right thing in the case of = unknown messages. E.g., a server implemented according to the existing = spec would not do a bad thing with such a message, because it wouldn't = recognize it, and the document defining that message ought to specify = how the server should handle it in the case you've described. > Almost sounds like DHCP needs a capabilities negotiation between = servers > and relays. :) Perish the thought. :) > If the pairing of a client and relay agent is not expected, this may = not > be an issue. It's certainly a plausible configuration=97I've even proposed something = like this in homenet. But I think that the way this would work would = again be something that could be documented in the spec describing how = it works. And homenet doesn't seem very interested in solving the = problem this way anyway. From brian@innovationslab.net Mon Feb 3 06:52:13 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05AC1A00EA for ; Mon, 3 Feb 2014 06:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhTZZ6epIY3b for ; Mon, 3 Feb 2014 06:52:12 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id A791A1A0115 for ; Mon, 3 Feb 2014 06:52:10 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id EBBC2880D1; Mon, 3 Feb 2014 06:52:10 -0800 (PST) Received: from 10252516.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 74DD31368157; Mon, 3 Feb 2014 06:52:10 -0800 (PST) Message-ID: <52EFAD21.6040901@innovationslab.net> Date: Mon, 03 Feb 2014 09:52:17 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ted Lemon References: <52EBC3EA.1020104@innovationslab.net> <52EFA4E8.2040404@innovationslab.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1TjxWWkxuNQ9iUOT3cGnuAvSG2iQMEW0M" Cc: "dhcwg@ietf.org WG" , draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:52:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1TjxWWkxuNQ9iUOT3cGnuAvSG2iQMEW0M Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/3/14 9:48 AM, Ted Lemon wrote: > On Feb 3, 2014, at 9:17 AM, Brian Haberman > wrote: >> Hmm... The text above talks about messages from servers to relays.=20 >> Would these messages be coming from servers *not* identified in >> the relay's configuration? That is, do you envision relays seeing >> messages from servers that the relay is not configured to use for >> received client messages? If not, shouldn't the guidance be that >> relays should silently drop them? If they can receive messages >> from servers they don't know about, the relays will forward these >> messages to *other* servers and they should drop them. >=20 > Yes, I had a bit of a think about that when replying to your review > yesterday, and thought about it some more just now. I don't think > we can address that here=97we don't know what these messages will look > like, or even if they will be defined, so trying to anticipate their > security implications is a bit futile. I think the language I > proposed is adequate for the time being, and does the right thing in > the case of unknown messages. E.g., a server implemented according > to the existing spec would not do a bad thing with such a message, > because it wouldn't recognize it, and the document defining that > message ought to specify how the server should handle it in the case > you've described. Ok. >=20 >> Almost sounds like DHCP needs a capabilities negotiation between >> servers and relays. :) >=20 > Perish the thought. :) Duly noted. >=20 >> If the pairing of a client and relay agent is not expected, this >> may not be an issue. >=20 > It's certainly a plausible configuration=97I've even proposed something= > like this in homenet. But I think that the way this would work > would again be something that could be documented in the spec > describing how it works. And homenet doesn't seem very interested > in solving the problem this way anyway. >=20 Ok. Just wanted to check. When a new version pops out, I will review it and start IETF LC. Regards, Brian --1TjxWWkxuNQ9iUOT3cGnuAvSG2iQMEW0M Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS760hAAoJEBOZRqCi7goq4g4H/3sjLTnHyLZbPPYVzQFJWXgX REFncxr2IV7tCPBYsg+QLvw/HQgo9tFZC9FQEyZ/24K5SAgOUFV61dsAD5D1CQIO vmobusdUjeLqK+Fvzvt/5dcIjI6VlrD1wB8rJMRu1hcuHxrBw4cApaItfYskZXMz oCMBEBTARhPfvnX4Rb8Eggtghr+/PDL+NX7jxQ/haodI99QOxRa6vf24cI9WVM2V mnSSCnYPcq3XGtB5yTvuvg45u3T7j5HHuwvCA99OvN7zBzKBKteO1d8KHB4zyPGW /dc+xKmYmxQyVfEaHb4IHgbTzd9akwDKB6AIo4xeJhiGaFFj4bAT2/qN6WvLRic= =DY7t -----END PGP SIGNATURE----- --1TjxWWkxuNQ9iUOT3cGnuAvSG2iQMEW0M-- From Ted.Lemon@nominum.com Mon Feb 3 06:53:12 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A601A0113 for ; Mon, 3 Feb 2014 06:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpR01gwjVQ7h for ; Mon, 3 Feb 2014 06:53:10 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 316231A00F4 for ; Mon, 3 Feb 2014 06:53:10 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUu+tVgfItek6epcpTEaEdRTG0N2DY8we@postini.com; Mon, 03 Feb 2014 06:53:10 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 30C5A1B82FC for ; Mon, 3 Feb 2014 06:52:39 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 257A1190052; Mon, 3 Feb 2014 06:52:39 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Feb 2014 06:52:39 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <52EFAD21.6040901@innovationslab.net> Date: Mon, 3 Feb 2014 09:52:36 -0500 Content-Transfer-Encoding: 7bit Message-ID: <6F5628CB-7062-474F-BE83-813A28F550E1@nominum.com> References: <52EBC3EA.1020104@innovationslab.net> <52EFA4E8.2040404@innovationslab.net> <52EFAD21.6040901@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" , draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:53:12 -0000 On Feb 3, 2014, at 9:52 AM, Brian Haberman wrote: > When a new version pops out, I will review it and start IETF LC. Thanks! From rdroms.ietf@gmail.com Mon Feb 3 07:03:15 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EBD1A00F2 for ; Mon, 3 Feb 2014 07:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqLR0YQQYKKY for ; Mon, 3 Feb 2014 07:03:13 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 674191A0032 for ; Mon, 3 Feb 2014 07:03:13 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id e9so11522182qcy.29 for ; Mon, 03 Feb 2014 07:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=p3Cxi6eF4RzdeDBVN2FVJSrzWjjIRX/3Q7mJkJZHf+A=; b=wXscgOUZeMUqNFXx7pW20p5yO+ZdKezUnGeHuZagB7gbeNcWaX0qWhus9UUQhWos5N g8NsziQuZX7wRBpc5gAbif09uOB3TwX0Oah8AF23sOn+vE1KNCB6l8UJLmD7pHioidso 5Lht3pvgJkXcrqOZbXGZm+F52N+Xy5ozpTI2RtPLloHk+rENS8JswjdV78oAKzwAnzeg aHsRMm5JbnsB6uHeP6nRHRoqUN+7svjeZybRrckcDK9VOZYm3Hd1M1G91z1PZQLr5SOt W87IK0RrMP0WN0sqAsG43s2Ta5tf8BgQ2HGzvmOT/8wAnbe3eKyP3hUl5wc0rAgOB9YA h+5w== X-Received: by 10.140.29.139 with SMTP id b11mr53789622qgb.48.1391439789255; Mon, 03 Feb 2014 07:03:09 -0800 (PST) Received: from ?IPv6:2001:420:2c52:1316:a12a:883:79cf:6178? ([2001:420:2c52:1316:a12a:883:79cf:6178]) by mx.google.com with ESMTPSA id h12sm27428745qge.0.2014.02.03.07.03.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 07:03:07 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ralph Droms In-Reply-To: Date: Mon, 3 Feb 2014 10:03:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0B24D33F-07DA-4726-BD30-DBCCE93B4560@gmail.com> References: <52EBC3EA.1020104@innovationslab.net> To: Lemon Ted , Haberman Brian X-Mailer: Apple Mail (2.1510) Cc: "dhcwg@ietf.org WG" , draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 15:03:15 -0000 On Feb 2, 2014, at 8:33 AM 2/2/14, Ted Lemon = wrote: > On Jan 31, 2014, at 10:40 AM, Brian Haberman = wrote: >> I have done my AD Evaluation of draft-ietf-dhc-dhcpv6-unknown-msg >> (since Ted is listed as a co-author). I only have a few points of >> discussion on this document before we move it along in the = publication >> process. I am by no means a DHCP expert, so let me know if I have = gone >> off in the weeds... >>=20 >> 1. I would like to see a little more clarity in the purpose of this >> document. It does a good job clarifying what a relay agent should do >> with existing messages, but I think it would be useful to spell out = that >> is document is also dictating how future documents that define new = DHCP >> messages should specify relay behavior. >=20 > This is a good suggestion (actually, these are all good suggestions!). = I think the right solution to this is twofold. First, the following = change should be made at the end of 4.1 (this also addresses your point = 2): >=20 > OLD: > In the case that a new type of message is sent by the server to a > relay agent but the relay agent does not recognize it, the message = is > put into a Relay-forward message and sent to the server. > NEW: > New DHCP message types may be defined in future that are intended to > convey information from DHCP servers to relay agents. Relay agents > that do not implement these messages will not recognize that such > messages are intended for them. A relay agent that implements this > specification will necessarily forward such messages to the DHCP > servers to which it is configured to relay client messages. >=20 > At this time, no messages of this variety have been specified. > If such a message is specified in the future, the specification = could > include text something like the following: >=20 > DHCP servers that send this new message type MAY, when they > receive a relayed message of this type, mark the relay agent to > which the message was sent as not implementing messages of this > type. In this case, the DHCP server MAY implement a strategy > of probing the relay agent occasionally to see if it has been > updated. >=20 > However, this is not strictly necessary, since DHCP does not provide > a signaling message for rejecting unexpected message types, and > therefore DHCP servers are not expected to respond to such messages. >=20 > Documents specifying new message types should use different types = for > communicating *to* relay agents than are used for communicating = *from* > relay agents, so that no confusion can occur where a message sent to > a relay agent is sent back to the DHCP server, which then tries to > process it as if it came from a relay agent. >=20 > In addition to this change, I'd propose the following change to the = abstract: >=20 > OLD: > DHCPv6 is not specific about handling messages with unknown types. > This memo describes the problems and defines how a DHCPv6 server, > client or relay agent should behave when receiving unknown DHCPv6 > messages. This document updates RFC3315. >=20 > NEW: > DHCPv6 is not specific about handling messages with unknown types. > This memo describes the problems and defines how a DHCPv6 server, > client or relay agent should behave when receiving unknown DHCPv6 > messages. This document also provides advice for authors of future > documents defining new messages sent from DHCP servers to DHCP relay > agents, and should be read by potential authors of such documents. > This document updates RFC3315. This proposed text generally looks ok. I see the conversation has = picked up a few messages later in the thread, so I'll jump ahead to that = discussion in another response. >=20 >> 2. In section 4.1, the text talks about targeting a message based on = its >> message type. To me, that suggests that a relay must know about all >> DHCP message types. I thought (feel free to correct me) that relay >> agents were mostly stateless and would forward all messages not >> addressed to them to the configured DHCP server. This assumes that = all >> Relay-Reply messages are addressed to the relay directly. >=20 > That is the general effect of 4.1, but I hope the text above makes = clearer what the issues are, both to you and to other future readers of = the document. OK. >=20 >> 3. After having an exchange with Ralph Droms, I want to ask about >> messages from servers to clients. If those messages are *not* in a >> Relay-Reply message, but are received by a relay, should those = messages >> be dropped? If a server->client message is forwarded to a server by = the >> relay, should it be dropped by the server? >=20 > If this happens, it's an implementation bug: the DHCP server is not in = conformance with RFC3315. I therefore think that we don't need to = address it, although it would certainly break things if an = implementation were to erroneously do that. I think such an = implementation would never make it to the field, because it simply = wouldn't work. Looking ahead to 4, seems to me we should consider the case in which a = client and relay agent are multiplexing inbound DHCPv6 messages on the = same port. >=20 >> 4. Is there a need to specifically discuss the behavior of single >> devices that have both a relay agent and a client running at the same = time? >=20 > Hm. We generally treat these as two separate implementations that = happen to be running on the same hardware. Also I think usually it's a = client and a server, not a relay agent and a server. We could add text = addressing this, but I don't really see this coming up in practice. = There isn't similar text in RFC3315, for instance, and we haven't seen = evidence of implementors getting this wrong. I'm imagining a scenario in which a device is doing DHCP-PD and has a = DHCPv6 client for local configuration. Don't underestimate = implementors; jsut because they haven't gotten it wrong in the past = doesn't mean we shouldn't consider the case. I'm assuming this entire document will be absorbed into RFC3315bis at = some point? Idle thought - is it worth publishing this document now = when it will likely be superseded by RFC3315bis? >=20 >> 5. Also from Ralph... Could section 5 simply be written as "A client = or >> server MUST silently discard any received DHCPv6 message with an = unknown >> message type."? >=20 > Yes, I think this is a good edit. Qi, do you have time to do these = edits? >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From rdroms.ietf@gmail.com Mon Feb 3 07:06:37 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEFC1A00F4 for ; Mon, 3 Feb 2014 07:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeSEgRYhEqee for ; Mon, 3 Feb 2014 07:06:35 -0800 (PST) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BD1C71A00F2 for ; Mon, 3 Feb 2014 07:06:35 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id ii20so10087880qab.33 for ; Mon, 03 Feb 2014 07:06:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oez8p5Rr+bq0pm/fBYbql+TTTSWcGL+VmD8h1phRou0=; b=JnTYFp+pxMfiOmcwlvjsPFXx1T4avv6zb22gbxErLGKkwJX07Mpg6zhArFFmIG1OXS JNqugxESJhW9oLw717T4CA0W2ChHQDOp4VdLhc0Fal244KVgSS81CrQ+sIvuruHIQRDg +bLp8e2qCvyYykrr8esrwwTPTWFiVdeasRZwqKvy7/j7iVDMDtqFwFuNtksy+XIEJR8c bkn7Mrk1Wv/ZUJ5scw/kxV9Cd58utwepduKWYsPUKAPx5oIX3Hye8f5Mjh1uDyFLDACq 1tKTFoZXve24iaiJXXnmZq80b17wBZUrflPMy2ecWLrd/Sfj6tg54RkNyDdwYRtI1gQy lyYA== X-Received: by 10.224.89.4 with SMTP id c4mr57674224qam.64.1391439995486; Mon, 03 Feb 2014 07:06:35 -0800 (PST) Received: from ?IPv6:2001:420:2c52:1316:a12a:883:79cf:6178? ([2001:420:2c52:1316:a12a:883:79cf:6178]) by mx.google.com with ESMTPSA id k107sm27438083qgk.5.2014.02.03.07.06.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 07:06:34 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ralph Droms In-Reply-To: Date: Mon, 3 Feb 2014 10:06:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8ED0F0BC-B198-42C2-B725-A8CB77893278@gmail.com> References: <52EBC3EA.1020104@innovationslab.net> <52EFA4E8.2040404@innovationslab.net> To: Ted Lemon X-Mailer: Apple Mail (2.1510) Cc: "dhcwg@ietf.org WG" , Haberman Brian , draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 15:06:37 -0000 On Feb 3, 2014, at 9:48 AM 2/3/14, Ted Lemon = wrote: > On Feb 3, 2014, at 9:17 AM, Brian Haberman = wrote: >> Hmm... The text above talks about messages from servers to relays. >> Would these messages be coming from servers *not* identified in the >> relay's configuration? That is, do you envision relays seeing = messages >> from servers that the relay is not configured to use for received = client >> messages? If not, shouldn't the guidance be that relays should = silently >> drop them? If they can receive messages from servers they don't know >> about, the relays will forward these messages to *other* servers and >> they should drop them. >=20 > Yes, I had a bit of a think about that when replying to your review = yesterday, and thought about it some more just now. I don't think we = can address that here=97we don't know what these messages will look = like, or even if they will be defined, so trying to anticipate their = security implications is a bit futile. I don't think we can count on the relay agent explciitly knowing all of = the servers for which it is configured. The default configuration for a = realy agent is to forward messages to a multicast address. > I think the language I proposed is adequate for the time being, and = does the right thing in the case of unknown messages. E.g., a server = implemented according to the existing spec would not do a bad thing with = such a message, because it wouldn't recognize it, and the document = defining that message ought to specify how the server should handle it = in the case you've described. >=20 >> Almost sounds like DHCP needs a capabilities negotiation between = servers >> and relays. :) >=20 > Perish the thought. :) We'll get on that as soon as we finish a HA server-server protocol. >=20 >> If the pairing of a client and relay agent is not expected, this may = not >> be an issue. Perhaps I'm insufficiently caffeinated this AM, but I don't understand = "pairing of a client and relay agent"... - Ralph >=20 > It's certainly a plausible configuration=97I've even proposed = something like this in homenet. But I think that the way this would = work would again be something that could be documented in the spec = describing how it works. And homenet doesn't seem very interested in = solving the problem this way anyway. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Mon Feb 3 07:24:19 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957701A012B for ; Mon, 3 Feb 2014 07:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wX3UyYU1FG3h for ; Mon, 3 Feb 2014 07:24:15 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id C2E5F1A002A for ; Mon, 3 Feb 2014 07:24:15 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUu+0n6Rm872izyHjCo9eIJaH3NX3AB5e@postini.com; Mon, 03 Feb 2014 07:24:16 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BBF681B830A for ; Mon, 3 Feb 2014 07:24:15 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 9CE42190052; Mon, 3 Feb 2014 07:24:15 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Feb 2014 07:24:15 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <0B24D33F-07DA-4726-BD30-DBCCE93B4560@gmail.com> Date: Mon, 3 Feb 2014 10:24:12 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <52EBC3EA.1020104@innovationslab.net> <0B24D33F-07DA-4726-BD30-DBCCE93B4560@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" , Brian Haberman , draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 15:24:19 -0000 On Feb 3, 2014, at 10:03 AM, Ralph Droms wrote: > I'm imagining a scenario in which a device is doing DHCP-PD and has a = DHCPv6 client for local configuration. Don't underestimate = implementors; jsut because they haven't gotten it wrong in the past = doesn't mean we shouldn't consider the case. Right, but if they are that creative, it's unlikely we will be able to = stop them. > I'm assuming this entire document will be absorbed into RFC3315bis at = some point? Idle thought - is it worth publishing this document now = when it will likely be superseded by RFC3315bis? Yes, the working group considered that question, and decided to publish. From brian@innovationslab.net Mon Feb 3 07:30:54 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649301A0170 for ; Mon, 3 Feb 2014 07:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEDVavxXZE2o for ; Mon, 3 Feb 2014 07:30:53 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 072BC1A0140 for ; Mon, 3 Feb 2014 07:30:53 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 456E4880D1; Mon, 3 Feb 2014 07:30:53 -0800 (PST) Received: from 10252516.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C778E1368158; Mon, 3 Feb 2014 07:30:52 -0800 (PST) Message-ID: <52EFB62E.90500@innovationslab.net> Date: Mon, 03 Feb 2014 10:30:54 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ralph Droms , Ted Lemon References: <52EBC3EA.1020104@innovationslab.net> <52EFA4E8.2040404@innovationslab.net> <8ED0F0BC-B198-42C2-B725-A8CB77893278@gmail.com> In-Reply-To: <8ED0F0BC-B198-42C2-B725-A8CB77893278@gmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Wm6obDsQKS45jDd5hAHp8HjlkXQs6qxnu" Cc: "dhcwg@ietf.org WG" , draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 15:30:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Wm6obDsQKS45jDd5hAHp8HjlkXQs6qxnu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ralph, On 2/3/14 10:06 AM, Ralph Droms wrote: >=20 > On Feb 3, 2014, at 9:48 AM 2/3/14, Ted Lemon wr= ote: >=20 >> On Feb 3, 2014, at 9:17 AM, Brian Haberman = wrote: >>> If the pairing of a client and relay agent is not expected, this may = not >>> be an issue. >=20 > Perhaps I'm insufficiently caffeinated this AM, but I don't understand = "pairing of a client and relay agent"... >=20 I meant having a client and relay agent functioning in the same box. Brian --Wm6obDsQKS45jDd5hAHp8HjlkXQs6qxnu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS77YzAAoJEBOZRqCi7goq9HQH/ROgz/UAXFMWTmrYemfRPrXd ztzcuBeM+hciHkWwLEBeGMQaomVXPXegyscLi1J5VeMBX2g7Oinhq/Qdvmgavfif 6cRN78KYqJuosRUwTjOZKOcmmaC6zBqLJ2A4Ui0UustbcjoJIA30pWsMfAdOKnRN ZszNFl3ZsUogTCwLy4TTZKYvLJ8pREqoi8GtpU1eEGEmAuSHQciTSkUFpeV3Kz2t m3icPotsNtgJ2lP74ngcDQ1rje+Hj3YARXAlJN9N9Hxts407MjMiTE0Z896aDSQf ZLACZAJUccg7xT1JoiO3QUaruMltFGlfmHF3v95ENmus2TDYw5TllxaM6hLbd7U= =JefU -----END PGP SIGNATURE----- --Wm6obDsQKS45jDd5hAHp8HjlkXQs6qxnu-- From rdroms.ietf@gmail.com Mon Feb 3 07:35:31 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7010D1A0137 for ; Mon, 3 Feb 2014 07:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gz4MylP45tXP for ; Mon, 3 Feb 2014 07:35:29 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 332001A013B for ; Mon, 3 Feb 2014 07:35:29 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id c9so11497248qcz.31 for ; Mon, 03 Feb 2014 07:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/4fZ7jW6mi/d9I9tJOoMRcIYAiinT6cXLKuKQQkh+bs=; b=c0k/4bn2Zw/89YyJntPX6vQvAOPBm/GKweZyp4fcpatcm7U8HlHMm8A6G4F7KXvkW6 X/+VlgHWh+VTe7e2kYq28c8BmOlAkT7//sWmwAi7EV3u4JAGZ2OzZb0J6PYht+3up0fu EmbvxOGwNDB0UWyowS08tZY593AbdijXLSeT8PGmlvEdjVj5/m3xC7GcAHI9+jHu81Qi 9b3tvdzPE/FGxe1HGpX3KoiTSlj+hILSHU0aGcZUNpvodKRSulfwzePE7M1Dt5SSRDQi /8xjmm5CxZjw3oJ2VVBjb1RcpXf2c2MTPoMfXgzxp948sidhTDVkQPK/PAZJjVGJQLKd jcQA== X-Received: by 10.224.65.135 with SMTP id j7mr58061528qai.10.1391441728698; Mon, 03 Feb 2014 07:35:28 -0800 (PST) Received: from ?IPv6:2001:420:2c52:1316:a12a:883:79cf:6178? ([2001:420:2c52:1316:a12a:883:79cf:6178]) by mx.google.com with ESMTPSA id b14sm25429619qac.17.2014.02.03.07.35.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 07:35:27 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ralph Droms In-Reply-To: <52EFAD21.6040901@innovationslab.net> Date: Mon, 3 Feb 2014 10:35:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52EBC3EA.1020104@innovationslab.net> <52EFA4E8.2040404@innovationslab.net> <52EFAD21.6040901@innovationslab.net> To: Haberman Brian , Lemon Ted X-Mailer: Apple Mail (2.1510) Cc: "dhcwg@ietf.org WG" , draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 15:35:31 -0000 On Feb 3, 2014, at 9:52 AM 2/3/14, Brian Haberman = wrote: >=20 >=20 > On 2/3/14 9:48 AM, Ted Lemon wrote: >> On Feb 3, 2014, at 9:17 AM, Brian Haberman >> wrote: >>> Hmm... The text above talks about messages from servers to relays.=20= >>> Would these messages be coming from servers *not* identified in >>> the relay's configuration? That is, do you envision relays seeing >>> messages from servers that the relay is not configured to use for >>> received client messages? If not, shouldn't the guidance be that >>> relays should silently drop them? If they can receive messages >>> from servers they don't know about, the relays will forward these >>> messages to *other* servers and they should drop them. >>=20 >> Yes, I had a bit of a think about that when replying to your review >> yesterday, and thought about it some more just now. I don't think >> we can address that here=97we don't know what these messages will = look >> like, or even if they will be defined, so trying to anticipate their >> security implications is a bit futile. I think the language I >> proposed is adequate for the time being, and does the right thing in >> the case of unknown messages. E.g., a server implemented according >> to the existing spec would not do a bad thing with such a message, >> because it wouldn't recognize it, and the document defining that >> message ought to specify how the server should handle it in the case >> you've described. >=20 > Ok. >=20 >>=20 >>> Almost sounds like DHCP needs a capabilities negotiation between >>> servers and relays. :) >>=20 >> Perish the thought. :) >=20 > Duly noted. >=20 >>=20 >>> If the pairing of a client and relay agent is not expected, this >>> may not be an issue. >>=20 >> It's certainly a plausible configuration=97I've even proposed = something >> like this in homenet. But I think that the way this would work >> would again be something that could be documented in the spec >> describing how it works. And homenet doesn't seem very interested >> in solving the problem this way anyway. I have a less laissez-faire view, here, which is that we ought to = disallow explicitly the deployment of a client and relay agent on the = same device, with a recommendation that a specification for such a = deployment needs to be written if the use case is realized. - Ralph >>=20 >=20 > Ok. Just wanted to check. >=20 > When a new version pops out, I will review it and start IETF LC. >=20 > Regards, > Brian >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Mon Feb 3 07:38:09 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D641A00FC for ; Mon, 3 Feb 2014 07:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJfkFcbg-89Q for ; Mon, 3 Feb 2014 07:38:08 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id BA6F11A0032 for ; Mon, 3 Feb 2014 07:38:07 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUu+33zINt8zQuUX8UIt4NSIFrMkH1XXO@postini.com; Mon, 03 Feb 2014 07:38:08 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B5A241B8305 for ; Mon, 3 Feb 2014 07:38:07 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id ADC3C190052; Mon, 3 Feb 2014 07:38:07 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Feb 2014 07:38:07 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Mon, 3 Feb 2014 10:38:04 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <52EBC3EA.1020104@innovationslab.net> <52EFA4E8.2040404@innovationslab.net> <52EFAD21.6040901@innovationslab.net> To: Ralph Droms X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" , Brian Haberman , draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 15:38:09 -0000 On Feb 3, 2014, at 10:35 AM, Ralph Droms wrote: > I have a less laissez-faire view, here, which is that we ought to = disallow explicitly the deployment of a client and relay agent on the = same device, with a recommendation that a specification for such a = deployment needs to be written if the use case is realized. That sounds like the opposite of a laissez-faire view. The only = problem with this proposal is that there's no reason to think that = anyone who needs to would read it. This sounds like more of a thing to = do in 3315bis. From brian@innovationslab.net Mon Feb 3 07:41:25 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBA21A0167 for ; Mon, 3 Feb 2014 07:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D9GRawLQ_Mc for ; Mon, 3 Feb 2014 07:41:24 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB391A015C for ; Mon, 3 Feb 2014 07:41:24 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 4A537880F3; Mon, 3 Feb 2014 07:41:24 -0800 (PST) Received: from 10252516.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C5BD81368158; Mon, 3 Feb 2014 07:41:23 -0800 (PST) Message-ID: <52EFB8AA.8030506@innovationslab.net> Date: Mon, 03 Feb 2014 10:41:30 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ted Lemon , Ralph Droms References: <52EBC3EA.1020104@innovationslab.net> <52EFA4E8.2040404@innovationslab.net> <52EFAD21.6040901@innovationslab.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Q08hAP69FB4EElJlbQnD5tpnm8Hwo7TVQ" Cc: "dhcwg@ietf.org WG" , draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 15:41:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Q08hAP69FB4EElJlbQnD5tpnm8Hwo7TVQ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/3/14 10:38 AM, Ted Lemon wrote: > On Feb 3, 2014, at 10:35 AM, Ralph Droms > wrote: >> I have a less laissez-faire view, here, which is that we ought to >> disallow explicitly the deployment of a client and relay agent on >> the same device, with a recommendation that a specification for >> such a deployment needs to be written if the use case is realized. >=20 > That sounds like the opposite of a laissez-faire view. The only Umm... He said "less laissez-faire". :) He's not wielding Thor's hammer though. > problem with this proposal is that there's no reason to think that > anyone who needs to would read it. This sounds like more of a thing > to do in 3315bis. >=20 I would be fine with that guidance being in 3315bis., but recall that I am also not a DHCP expert. Regards, Brian --Q08hAP69FB4EElJlbQnD5tpnm8Hwo7TVQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS77iqAAoJEBOZRqCi7goqpqEIALeUDQIayuYmsOe/FiOwG8j5 GqQVy7cH/2vDvKt0vju9eIbbEcD7XRLjLaf3qe0RoXlMNwRiO+DFdEOfHLYzw+I3 Qr4YhiO4rEEEHNnOFU5cJ4D8/rfKyVE0Uph+rDuKiX22HGxwKhF7WsxDdBTsdogt AG/0DWmIqnlcLExJw8MxL9VHIsjGD2RJKnmaueCZMOXp6QWv7fZvYqX//oKYAQ3q 21vQlbzB6yEW4Uk7Yle0sT+XVC5zmDi3VlnquJ9m7dWnX5Aw+Tw3XeZA3jYwNHQ4 WI5U3xDL+9IOaauywiHMoBSnrLap4C4gu4A4EZi6yhMKjx29Z2fN/K+Bev45Juw= =oZZJ -----END PGP SIGNATURE----- --Q08hAP69FB4EElJlbQnD5tpnm8Hwo7TVQ-- From Fred.L.Templin@boeing.com Mon Feb 3 08:49:26 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3C61A01AD for ; Mon, 3 Feb 2014 08:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.837 X-Spam-Level: X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3V8hgiDp2uko for ; Mon, 3 Feb 2014 08:49:25 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id ACA121A0165 for ; Mon, 3 Feb 2014 08:49:25 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s13GnPjw006847; Mon, 3 Feb 2014 08:49:25 -0800 Received: from XCH-PHX-109.sw.nos.boeing.com (xch-phx-109.sw.nos.boeing.com [130.247.25.36]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s13GnKU4006756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 3 Feb 2014 08:49:20 -0800 Received: from XCH-BLV-403.nw.nos.boeing.com (2002:82f7:193e::82f7:193e) by XCH-PHX-109.sw.nos.boeing.com (2002:82f7:1924::82f7:1924) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 3 Feb 2014 08:49:19 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.102]) by XCH-BLV-403.nw.nos.boeing.com ([169.254.3.123]) with mapi id 14.03.0174.001; Mon, 3 Feb 2014 08:49:19 -0800 From: "Templin, Fred L" To: "dhcwg@ietf.org WG" Thread-Topic: Question on relay agent behavior in DHCPv6 prefix delegation Thread-Index: Ac8g/+FYRMW3CqBVRFqGSM7aZaq32Q== Date: Mon, 3 Feb 2014 16:49:19 +0000 Message-ID: <2134F8430051B64F815C691A62D983181C095B@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: [dhcwg] Question on relay agent behavior in DHCPv6 prefix delegation X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 16:49:27 -0000 Hi, RFC3633 says: "14. Relay agent behavior A relay agent forwards messages containing Prefix Delegation options in the same way as described in section 20, "Relay Agent Behavior" of RFC 3315. If a delegating router communicates with a requesting router through a relay agent, the delegating router may need a protocol or other out-of-band communication to add routing information for delegated prefixes into the provider edge router." My question is, since the publication of RFC3633 has there been a new RFC published that specifies "a protocol or other out-of-band communication to add routing information"? Thanks - Fred fred.l.templin@boeing.com From twinters@iol.unh.edu Mon Feb 3 09:07:15 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3B31A0162 for ; Mon, 3 Feb 2014 09:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyMLi5MnZgO5 for ; Mon, 3 Feb 2014 09:07:13 -0800 (PST) Received: from exprod5og111.obsmtp.com (exprod5og111.obsmtp.com [64.18.0.22]) by ietfa.amsl.com (Postfix) with SMTP id 059FB1A01B0 for ; Mon, 3 Feb 2014 09:07:08 -0800 (PST) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob111.postini.com ([64.18.4.12]) with SMTP ID DSNKUu/MvBq1ezI9LL+ADDSaAeMAftTXrn2Z@postini.com; Mon, 03 Feb 2014 09:07:09 PST Received: from openvpn-client22.iol.unh.edu (openvpn-client22.iol.unh.edu [132.177.124.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id DD5E68F0078 for ; Mon, 3 Feb 2014 12:07:07 -0500 (EST) From: Timothy Winters Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <44F7934F-540F-4B41-B37D-08B0C0453D72@iol.unh.edu> Date: Mon, 3 Feb 2014 12:07:06 -0500 To: "dhcwg@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [dhcwg] DHCPv6 Stateful Issues X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 17:07:15 -0000 Hi Bernie, While testing some IPv6 CE Router I've noticed an issue that = this draft might want to address. When a DHCP Client receives both the = IA_NA and IA_PD in the reply, the Client performs DAD on the IA_NA. If = DAD fails some implementations keep the IA_PD and try for a different = IA_NA. Other IPv6 CE Routers will Release the IA_PD in this scenario. =20= I would think the proper thing to do would be to keep the IA_PD = so your LAN as addressing. Is something that we can talk about in this = document? ~Tim From akostur@incognito.com Mon Feb 3 09:35:35 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A141A01CF for ; Mon, 3 Feb 2014 09:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vr48BIhx3s41 for ; Mon, 3 Feb 2014 09:35:34 -0800 (PST) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with SMTP id F0B3B1A016D for ; Mon, 3 Feb 2014 09:35:33 -0800 (PST) Received: from mail-vb0-f41.google.com ([209.85.212.41]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKUu/TZaaQRFGo4bVTzIXDfG5zPV8cFn2h@postini.com; Mon, 03 Feb 2014 09:35:34 PST Received: by mail-vb0-f41.google.com with SMTP id g10so4893050vbg.14 for ; Mon, 03 Feb 2014 09:35:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gpKUNoY4RFTIgAPqc9PKJqGufdYzDoqdqZO/gYWneFo=; b=Pwck5an74QzXuIwv/bLkOF9XMkBhDQOWf5Q7dL3l4KHZ4kGNU1OVWKDI6l9K+WTyLU LJlx6DbchExYV2gMayk+unUlS8e6c8W00LAS5v8Bdsx5lM5MZ4/0PHQJRUdrwlSiSh0u 0H8z04VjGi1oCQJm2Fw2IwwYPEAymCeAAuKKxu6LpAyOTizrC1FasiBMUKcD9yVQpbC8 G+5iDAkKFE5R+ZtLh/Vq8BIW1R1PP+t3l51UuCQs3KCQntMAATkmYZslMydxMtuQIJ4R NgNfwX7KveVG2wxLuM+PFHb9ApzstdSKGT31OIUG7snejnLdfueVmPizVr5ZuD1+l6e2 YxGg== X-Gm-Message-State: ALoCoQl8p5A1uiMI6SMFQpM1SrBXnzoXgaS1ux81E2xqpsfBC2WPNyuaWfg7zGoZH0sstQfDDOyUt6EgKyd1USXCaMhs7poMcCU19LFunbuq1IKRNEF64fPhthoZs1E9T317vqznrBA/KsLOxbL0lHBZCGUZfAS9TA== X-Received: by 10.221.24.200 with SMTP id rf8mr62335vcb.65.1391448933239; Mon, 03 Feb 2014 09:35:33 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.221.24.200 with SMTP id rf8mr62328vcb.65.1391448933156; Mon, 03 Feb 2014 09:35:33 -0800 (PST) Received: by 10.221.16.138 with HTTP; Mon, 3 Feb 2014 09:35:33 -0800 (PST) In-Reply-To: <2134F8430051B64F815C691A62D983181C095B@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181C095B@XCH-BLV-504.nw.nos.boeing.com> Date: Mon, 3 Feb 2014 09:35:33 -0800 Message-ID: From: Andre Kostur To: "Templin, Fred L" Content-Type: text/plain; charset=ISO-8859-1 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Question on relay agent behavior in DHCPv6 prefix delegation X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 17:35:36 -0000 The RFC doesn't get into details since it may not even be the delegating router doing the route updates. As an example, in a cable network, it may be the CMTS (who plays the role of Relay Agent from DHCPv6's perspective) who is snooping the PD traffic and may emit the appropriate routing updates into the network (using some other standard dynamic routing protocol such as OSPF). On Mon, Feb 3, 2014 at 8:49 AM, Templin, Fred L wrote: > Hi, RFC3633 says: > > "14. Relay agent behavior > > A relay agent forwards messages containing Prefix Delegation options > in the same way as described in section 20, "Relay Agent Behavior" of > RFC 3315. > > If a delegating router communicates with a requesting router through > a relay agent, the delegating router may need a protocol or other > out-of-band communication to add routing information for delegated > prefixes into the provider edge router." > > My question is, since the publication of RFC3633 has there been a > new RFC published that specifies "a protocol or other out-of-band > communication to add routing information"? > > Thanks - Fred > fred.l.templin@boeing.com > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Andre Kostur From Fred.L.Templin@boeing.com Mon Feb 3 10:11:03 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5252C1A01E2 for ; Mon, 3 Feb 2014 10:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsVFG5zfxfUG for ; Mon, 3 Feb 2014 10:10:56 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id C9E551A01D7 for ; Mon, 3 Feb 2014 10:10:56 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s13IAuRk019076; Mon, 3 Feb 2014 10:10:56 -0800 Received: from XCH-PHX-313.sw.nos.boeing.com (xch-phx-313.sw.nos.boeing.com [130.247.25.175]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s13IAndt018511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 3 Feb 2014 10:10:50 -0800 Received: from XCH-BLV-205.nw.nos.boeing.com (10.57.37.61) by XCH-PHX-313.sw.nos.boeing.com (130.247.25.175) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 3 Feb 2014 10:10:49 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.102]) by XCH-BLV-205.nw.nos.boeing.com ([169.254.5.70]) with mapi id 14.03.0174.001; Mon, 3 Feb 2014 10:10:49 -0800 From: "Templin, Fred L" To: Andre Kostur Thread-Topic: [dhcwg] Question on relay agent behavior in DHCPv6 prefix delegation Thread-Index: AQHPIQZeEVV3nCWgQkC0s04abY7hyJqj02xw Date: Mon, 3 Feb 2014 18:10:48 +0000 Message-ID: <2134F8430051B64F815C691A62D983181C0A8C@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181C095B@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Question on relay agent behavior in DHCPv6 prefix delegation X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 18:11:03 -0000 Hi Andre, > -----Original Message----- > From: Andre Kostur [mailto:akostur@incognito.com] > Sent: Monday, February 03, 2014 9:36 AM > To: Templin, Fred L > Cc: dhcwg@ietf.org WG > Subject: Re: [dhcwg] Question on relay agent behavior in DHCPv6 prefix de= legation >=20 > The RFC doesn't get into details since it may not even be the > delegating router doing the route updates. As an example, in a cable > network, it may be the CMTS (who plays the role of Relay Agent from > DHCPv6's perspective) who is snooping the PD traffic and may emit the > appropriate routing updates into the network (using some other > standard dynamic routing protocol such as OSPF). Thanks for this. So, it seems that the RFC3633 DHCPv6 relays (and maybe also servers) can snoop the PD exchanges and update the routing system via some unspecified means. But, are there any more recent publications that have either attempted or succeeded in specifying a standard method? Thanks - Fred fred.l.templin@boeing.com=20 > On Mon, Feb 3, 2014 at 8:49 AM, Templin, Fred L > wrote: > > Hi, RFC3633 says: > > > > "14. Relay agent behavior > > > > A relay agent forwards messages containing Prefix Delegation options > > in the same way as described in section 20, "Relay Agent Behavior" o= f > > RFC 3315. > > > > If a delegating router communicates with a requesting router through > > a relay agent, the delegating router may need a protocol or other > > out-of-band communication to add routing information for delegated > > prefixes into the provider edge router." > > > > My question is, since the publication of RFC3633 has there been a > > new RFC published that specifies "a protocol or other out-of-band > > communication to add routing information"? > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg >=20 >=20 >=20 > -- > Andre Kostur From Ted.Lemon@nominum.com Mon Feb 3 11:30:28 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCCF1A010F for ; Mon, 3 Feb 2014 11:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-X6uv-Twv1u for ; Mon, 3 Feb 2014 11:30:25 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id B16B71A01DA for ; Mon, 3 Feb 2014 11:30:24 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUu/uUAErji1NXKex/4RpG9aswlcdCIry@postini.com; Mon, 03 Feb 2014 11:30:25 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3135C1B8307 for ; Mon, 3 Feb 2014 11:30:24 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B5365190052; Mon, 3 Feb 2014 11:30:14 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Feb 2014 11:30:14 -0800 From: Ted Lemon Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Feb 2014 14:30:12 -0500 Message-ID: <50CD0E29-FAAC-428D-BDE6-D65A8F411F41@nominum.com> To: MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: [dhcwg] AD review of draft-ietf-dhc-dhcpv6-failover-design X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 19:30:28 -0000 I've got some detailed comments, but the bottom line is that I am not = ready to submit this to the IESG. This is for two reasons. For the = first, see the last few paragraphs of this review. The other reason is = that it appears to be two documents. One document is trying to explain = the reasoning behind the choices made in developing the failover = protocol. The other is trying to specify how the protocol functions, = without specifying wire format stuff. My understanding of the plan was that there would be a requirements = document, which is done. And then there would be this document, which = would be a specification of the protocol, but would not specify wire = format information. Finally, there would be a third document, which = would specify the wire format. I don't think it's a problem to do a document that describes the = reasoning behind the protocol, and if the wire format document is going = to specify the actual protocol, including all the MUSTs and SHOULDs and = MAYs, then this document would be fine as an informational document. = However, if the third document will not stand on its own, this document = has to be standards track, as it is now. And in that case, it needs to = be chopped down substantially, and the normative language needs to be = thought through carefully and systematically, so that it's not scattered = all over the place and so that things that ought to be validated by = servers are not instead specified as requirements on administrators = (e.g. the suggestions below on the CONTACT message and on 5.2 paragraph = 3). I think the right thing to do is make this document informational, get = rid of the RFC2119 language and the reference to RFC2119, and do that = bit in the third document. The more I think about this, the more I = think that's actually what we said we were going to do originally. = However, if you want to go forward with proposed standard, it's going to = require a lot of rework. Either way is fine with me, but the decision = needs to be made. So, on to the editorial suggestions. I've tried to limit myself to = suggestions that I don't think the RFC editor would make, or that would = be easy to get wrong, and of course to questions and comments about the = spec itself. The abstract is a bit wordy. Suggested edit: OLD DHCPv6 defined in [RFC3315] does not offer server redundancy. This document defines a design for DHCPv6 failover, a mechanism for running two servers on the same network with capability for either server to take over clients' leases in case of server failure or network partition. This is a DHCPv6 Failover design document, it is not a protocol specification document. It is a second document in a planned series of three documents. DHCPv6 failover requirements are specified in [I-D.ietf-dhc-dhcpv6-failover-requirements]. A protocol specification document is planned to follow this document. NEW This document describes a design for DHCPv6 failover, a mechanism that allows two servers for the same network to communicate so as to allow either server to take over clients' leases if the other fails, as well as allowing continued operation in the event of a network partition. This document does not describe the wire protocol. The other text is okay if you really prefer it, but the point of = abstracts is to attract the right readers, and not attract the wrong = readers, nor to tell you anything at all else. So e.g. there is no = reason to refer to the requirements document or to RFC 3315, because = presumably the target audience for this document already knows what = DHCPv6 is and where it is defined, and if not they can read the = references. Section 3, first paragraph, "design" is superfluous, edit for clarity: OLD: The failover protocol design provides a means for cooperating DHCPv6 servers to work together to provide a DHCPv6 service with availability that is increased beyond that which could be provided by a single DHCPv6 server operating alone. It is designed to protect NEW: The failover protocol provides a means for cooperating DHCPv6 servers to work together to provide a DHCPv6 service with greater availability than could be provided by a single DHCPv6 server operating alone. It is designed to protect page 6, second paragraph: Due in part to the additional overhead required as well as requirements to handle time skew between failover partners (See Section 8.1), failover is not suitable for leases shorter than 30 seconds. Does the protocol design guarantee that leases _longer_ than 30 seconds = will work, or is this a rule of thumb? Are sections 3.1 and 3.2 really necessary? Didn't we have a = requirements document that preceded this one? :) Section 4, first paragraph: are listed in Section 4.2. All information is sent over the connection as typical DHCPv6 messages that convey DHCPv6 options, following the format defined in Section 22.1 of [RFC3315]. why not just say "as DHCPv6 messages" and leave out "typical?" Perhaps = you mean "as defined in section 6 of RFC 3315?" But I don't think you = need to say that=97you can just specify the format in the document that = describes the wire format. page 9, paragraph 3, edit for clarity: OLD: Once a server is switched into PARTNER-DOWN (when auto-partner-down is used or as a result of administrative action), it can extend leases, regardless of the original server that initially granted the lease. In that state server handles leases from its own pool, but once its own pool is depleted is also able to serve pool from its downed partner. Some MCLT restrictions no longer apply, but the MCLT NEW: Once a server is switched into PARTNER-DOWN (when auto-partner-down is used or as a result of administrative action), it can extend leases, regardless of which server initially granted the lease. In that state server handles leases from its own pool, but once its own pool is depleted is also able to serve leases from the=20= pool of its downed partner. Some MCLT restrictions no longer apply, but the MCLT Also, doesn't this leave out that the partner down server can = immediately renew leases from the other server's pool, even before its = own pool is depleted? Section 4.2, first paragraph: are assigned in this document. Appropriate implementation details will be specified in a separate protocol specification document. The following list enumerates these messages: You've already said several times that this document doesn't specify the = wire format. I think it's best not to repeat it every time something = that has a wire format is discussed for the first time=97it feels = repetitive to me. Your call, but that's my advice, FWIW. Page 11, last paragraph: o CONTACT - The contact message is used by either server to ensure that the other server continues to see the connection as operational. It MUST be transmitted periodically over every established connection if other message traffic is not flowing, and it MAY be sent at any time. Do you really want to put normative language here? You aren't = describing the flow of state. Surely there's a better place in the = document for this MUST. Section 5.1, paragraph 7: for the CONNECT message from a primary server. If the secondary server doesn't receive a CONNECT message from the primary server in an installation dependent amount of time, it MAY drop the connection. Do you mean "installation dependent" or "administratively configured?" = Or "implementation-dependent"? Why isn't this just specified as a = specific time limit? paragraph 8: Every CONNECT message includes a TLS-request option, and if the CONNECTACK message does not reject the CONNECT message and the TLS- reply option says TLS MUST be used, then the servers will immediately enter into TLS negotiation. Presumably either server could be configured to require TLS; if so, and = if the secondary doesn't say TLS must be used, the primary should drop = the connection and flag an error. section 5.2, paragraph 2: The failover protocol SHOULD be configured with one failover relationship between each pair of failover servers. In this case there is one failover endpoint for that relationship on each failover partner. This failover relationship MUST have a unique name. do you mean: Any pair of failover servers that have a failover relationship is=20 normally configured with exactly one such relationship. In this case there is one failover endpoint for that relationship on each failover partner. This failover relationship MUST have a = unique name. Also, unique in what domain? The entire internet? :) in paragraph 3, I think the normative language is superfluous. How = about: There is typically no need for more than one relationship between any two servers, but such a configuration is not prohibited, and may = make sense in some cases. In such cases, each failover relationship MUST = have a unique relationship name. This paragraph also seems a little weird since you said in the previous = paragraph that failover relationship names are unique. That said, an = additional problem with the above paragraph is that you're using = normative language for what looks like an administrative configuration. = This doesn't make sense=97administrators aren't necessarily reading = this RFC. If you want to make a requirement, you should say something = like "if a DHCP server configured with two failover endpoints detects = that both endpoints have the same name, the DHCP server MUST report the = conflict and MUST NOT attempt to establish or accept connections for = either failover relationship." In 5.2, last paragraph: When a connection is received from the partner, the unique failover endpoint to which the message is directed is determined solely by the IP address of the partner, the relationship-name, and the role of the receiving server. A connection is not a message. I can't tell what this paragraph is = asking the implementor to do. In section 6: you define proportional allocation and independent = allocation in some detail here. I don't see the point in also defining = them in the terminology section, although I understand the impulse. I = would recommend that you delete the entries in the terminology section = to avoid this repetition. Also, I think the reference to dhcpv4-failover is probably unhelpful. = I think it's a normative reference in this particular context, although = you currently have it listed as informative. Until we get that = document published, it's a downref, which is something to avoid, and I = think is easy to avoid here. 6.1, paragraph 1: In this allocation scheme, each server has its own pool of available resources. Remaining available resources are split between the primary and secondary servers in a configured proportion. Note that I think you mean "in a configured ratio," not "proportion." See = http://www.math.com/school/subject1/lessons/S1U2L2GL.html for = explanation. 6.1, paragraph 3: A resource will not become owned by the server which allocated it initially when it is released or the lease expires because, in general, that server will have had to replenish its pool of available resources well in advance of any likely lease expirations. Thus, having a particular resource cycle back to the secondary might well put the secondary more out of balance with respect to the primary instead of enhancing the balance of available addresses or prefixes between them. You've already said that the resource reverts to the primary when it = becomes available after having been allocated to a client. Here you = are explaining why. It is unnecessary to explain why, and the = explanation doesn't really make sense, because it's equally true that = returning the resource to the secondary might put the pool more in = balance. So I think you should delete this paragraph. The reader = simply doesn't need to know this. The use of POOLREQ/POOLRESP in 6.1 doesn't make sense. It's the = primary that needs to send POOLREQ, not the secondary. You've said = that the primary is supposed to automatically balance the pools by = sending BNDUPD messages moving leases from FREE to FREE_BACKUP when = needed. Really, the best thing to do would be to require the secondary = to do the same thing, and get rid of POOLREQ/POOLRESP entirely. You = can deal with the problem of rebalance wars by specifying a hysteresis = threshold rather than suggesting it. You'd also need to make sure that = the ratio is the same on both servers in the CONNECT/CONNECTACK = exchange. Also, allowing the primary to try to steal FREE_BACKUP = leases seems unnecessarily complicated. Proactive pushing seems better = than proactive stealing. In 6.2, I see no justification for allowing the PARTNER-DOWN server to = allocate out of the other server's pool. In 6.3, paragraph 2: The proportional allocation mechanism is more flexible as it can dynamically rebalance available resources between servers. That balance creates an additional burden for the servers and generates You want to say "that balancing," not "that balance," because it is the = balancing process that creates the load=97if the pools are balanced, = there is no balancing, and hence no load. BTW, the advice you're giving here seems like a repetition of what was = said in the two bullet points in section 6. It would be good if you = could cull those, or chop them down so that they don't duplicate what's = said in 6.3. In paragraph 3: between partners simpler. It also makes recovery easier and potential conflict less likely to appear. I think you mean either "It also makes recovery easier and makes it less = likely that the failover pair will wind up in the POTENTIAL-CONFLICT = state," or else you mean "It also makes recovery easier and conflict = less likely." In paragraph 4, I think you mean "more constrained" rather than = "smaller": assign, so there is no need to rebalance. For the prefix delegation mechanism, available resources are typically much smaller, so there also: Independent allocation still may be used, but the implication must be well understood. For example in a network that delegates /64 prefixes out of a /48 prefix (so there can be up to 65536 prefixes delegated) and a 1000 requesting routers, it is safe to use independent allocation. I think you mean here that if the maximum number of requesting routers = is fewer than half the number of prefixes, then there should be no = problem with using the independent model. It's good to give examples, = but here it might be better to just show the math. Of course, you could also safely just delete the last three paragraphs = of this section, because it's unlikely that what is said here will fail = to be obvious to any person smart enough to implement the protocol. In section 7, "common denominator" is an abbreviation of an English = colloquialism where the phrase "least common denominator" is used to = mean "basic common subset" or something like that. I think you can = just say "common" and convey the same meaning. For a reader who is not = familiar with this colloquialism, "denominator" is likely to impede = understanding. So, in paragraph to, I'd suggest the following edit: OLD: In order to transmit binding database updates between one server and another using the failover protocol, some common denominator binding- status values must be defined. It is not expected that these values correspond with any actual implementation of the DHCP protocol in a DHCP server, but rather that the binding-status values defined in this document should be a common denominator of those in use by many DHCP server implementations. NEW: In order to transmit binding database updates between one server and another using the failover protocol, some common binding- status values must be defined. It is not expected that these values correspond with any actual implementation of the DHCP protocol in a DHCP server, but rather that the binding-status values defined in this document should be a common subset of those in use by existing DHCP server implementations. Why the MAY here: The lease binding-status values defined for the failover protocol are listed below. Unless otherwise noted below, there MAY be client information associated with each of these binding-status value. ? I think what you really want is something like this: The lease binding-status values defined for the failover protocol are listed below. As noted below, client information may be required to be associated with the lease when it has a particular binding-status value. Section 7, under FREE, for clarity: OLD: available for assignment by the primary server. Note that on a secondary server running in PARTNER-DOWN state, after waiting the MCLT, the resource MAY be allocated to a client by the secondary server. Client identification MAY appear and indicates the last client to have used this resource as a hint. NEW: available for assignment by the primary server. On a secondary server running in PARTNER-DOWN state, the resource is available for allocation after MCLT has passed. Client identification can appear, and indicates which client last used this resource. Similarly under FREE_BACKUP: OLD: secondary server to a client at any time. Note that the primary server running in PARTNER-DOWN state, after waiting the MCLT, the resource MAY be allocated to a client by the primary server if proportional algorithm was used. Client identification MAY appear and indicates the last client to have used this resource as a hint. NEW: secondary server to a client at any time. On a primary server running in PARTNER-DOWN state, the resource is available for allocation after MCLT has passed. Client identification can appear, and indicates which client last used this resource. In figure 1, is it possible for a lease in ACTIVE to go to RESET? The information documented in figure 2 and the paragraph before it is = also documented in points 5 and 6. You should just delete figure 2 and = that paragraph; if you feel points 5 and 6 are insufficient, add more = information there. The advice in the paragraph following figure 2 is not advice about the = operation of the binding state machine. It is information about the = operating of the pool balancer. It should be in its own section. = Pool balancing has been discussed elsewhere in the document already. This kind of redundancy is prevalent throughout the document. Authors, = please take another pass through this document and try to identify cases = like the one I described above and isolate the advice given in these = cases into sections specific to these cases, and make sure it's not = repeated anywhere else in the document. You can probably reduce the = document length by five pages or even ten pages by doing this, and it = will be much better organized and easier to read. I would appreciate it if the working group could do this before I = continue reviewing the document. What you are specifying here is a = good protocol, but the document needs more work. The working group would be within their rights to insist that I continue = with the review and do not insist on this change, on the basis that the = authors do not have the time or enthusiasm to do the work. If the = working group makes this request, I will attempt to honor it, or else = try to find some resources to help you. I want to see this document = progress, and there is lots of good work in here. But it could be so = much better with a bit of restructuring and winnowing. From Ted.Lemon@nominum.com Mon Feb 3 11:41:26 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5731A010F for ; Mon, 3 Feb 2014 11:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnI948IPU_eJ for ; Mon, 3 Feb 2014 11:41:25 -0800 (PST) Received: from exprod7og129.obsmtp.com (exprod7og129.obsmtp.com [64.18.2.122]) by ietfa.amsl.com (Postfix) with ESMTP id DE3101A016D for ; Mon, 3 Feb 2014 11:41:24 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob129.postini.com ([64.18.6.12]) with SMTP ID DSNKUu/w5ImBwYW7HuOP3pmd2VjAm1suwnrH@postini.com; Mon, 03 Feb 2014 11:41:25 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B35FF1B82FC for ; Mon, 3 Feb 2014 11:41:24 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id A895D190052; Mon, 3 Feb 2014 11:41:24 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Feb 2014 11:41:24 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <2134F8430051B64F815C691A62D983181C0A8C@XCH-BLV-504.nw.nos.boeing.com> Date: Mon, 3 Feb 2014 14:41:17 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <0A4C2767-D7B2-4712-93F9-CC547871D7E9@nominum.com> References: <2134F8430051B64F815C691A62D983181C095B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181C0A8C@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" , Andre Kostur Subject: Re: [dhcwg] Question on relay agent behavior in DHCPv6 prefix delegation X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 19:41:26 -0000 On Feb 3, 2014, at 1:10 PM, Templin, Fred L = wrote: > But, are there any more recent publications > that have either attempted or succeeded in specifying a standard = method? I can't think of any. From rdroms.ietf@gmail.com Mon Feb 3 11:57:11 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6119B1A016D for ; Mon, 3 Feb 2014 11:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrZmjLK3EvZl for ; Mon, 3 Feb 2014 11:57:09 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CF54A1A01DA for ; Mon, 3 Feb 2014 11:57:07 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id c9so11886130qcz.17 for ; Mon, 03 Feb 2014 11:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=632DM4+ShcfyqljzUyuyQPivT8T7sjEDGJhYhAhuFXU=; b=NJYxHwJHt/er5D52sp2XI7d5SIK5zuF2Mp88s99kcE7SA59JcioDXNpsoh+6e3DVMX CdoDK1mWgzEv6VKKisVH+6dzdFHAEf9yfLq7V51emy9xOs+/v5qi113s1CEv4irLAAjs /+P3x2gYWo9O8SqFRBtPmLz0HRfSnhQXwLhYhmxqfIWbhKsI4Cro7OGfwsVGpFvARWOJ YoGcZeiHIBvN+WwiBbRedfHsKHOja/pclxYO51ASsfXwiRiIpYZbWYZjko36smBFS+kH K1QYOTgm5QrqcyeOdNPJrd72kN52d6pGQRVluJJvgn8bp2nvlW88YqWbqEPrZ1rIwoJU 1CTg== X-Received: by 10.224.2.194 with SMTP id 2mr59925876qak.44.1391457427119; Mon, 03 Feb 2014 11:57:07 -0800 (PST) Received: from ?IPv6:2001:420:2c52:1316:a12a:883:79cf:6178? ([2001:420:2c52:1316:a12a:883:79cf:6178]) by mx.google.com with ESMTPSA id 72sm28638419qgv.19.2014.02.03.11.57.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 11:57:03 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ralph Droms In-Reply-To: <0A4C2767-D7B2-4712-93F9-CC547871D7E9@nominum.com> Date: Mon, 3 Feb 2014 14:57:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <43881544-E397-4075-A898-4B2B91082738@gmail.com> References: <2134F8430051B64F815C691A62D983181C095B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181C0A8C@XCH-BLV-504.nw.nos.boeing.com> <0A4C2767-D7B2-4712-93F9-CC547871D7E9@nominum.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1510) Cc: "dhcwg@ietf.org WG" , Andre Kostur , Lemon Ted Subject: Re: [dhcwg] Question on relay agent behavior in DHCPv6 prefix delegation X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 19:57:11 -0000 On Feb 3, 2014, at 2:41 PM 2/3/14, Ted Lemon = wrote: > On Feb 3, 2014, at 1:10 PM, Templin, Fred L = wrote: >> But, are there any more recent publications >> that have either attempted or succeeded in specifying a standard = method? >=20 > I can't think of any. "DHCP Relay Agent Assignment Notification Option" = , R. Droms, B. Volz, O. Troan 1. Introduction The DHCP Relay Agent Assignment Notification option encapsulates address and prefix options to indicate that an address or prefix has been assigned. The option may also carry other information required by the network element for configuration related to the assigned address or prefix. For example, a network administrator uses the DHCP Relay Agent Assignment Notification option to inform a relay agent of a prefix that has been delegated through DHCP PD to a DHCP client. The relay agent notifies the network element on which the it is implemented of the delegation information so the network element can add routing information about the delegated prefix into the appropriate routing protocols. The dhc WG discussed the idea and decided not to take on the work due to = some fundamental issues in using the option reliably; e.g., ensuring = that all DHCPv6 messages were relayed through the device that was = actually interested in configuring itself for the delegated prefix. The idea was to formalize what is now accomplished through snooping. - Ralph >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From kkinnear@cisco.com Mon Feb 3 13:05:30 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A111A0225 for ; Mon, 3 Feb 2014 13:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZBwowuyHJLF for ; Mon, 3 Feb 2014 13:05:27 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4F81A0213 for ; Mon, 3 Feb 2014 13:05:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4481; q=dns/txt; s=iport; t=1391461528; x=1392671128; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cQBQx7IImdhm3WGkXN2HXBwiz2XthlbTLpXVK6t9Opg=; b=mhpzLHXZh4T65lq3iH9ki6IeC+G3F5Uh3D5HVYo9lYc3W3OWM0gkLsnL UmLf3B7ZI+iG0xdtFIaTRK71VAEzBxzlqEI+iRK5cf2GJDyHwxJ1wuhmy 5v6OxK8UgkP31+hoynwnEWPQFuIk0ROwGjgCILkVSLwLvFGWII1JRHFnI 0=; X-IronPort-AV: E=Sophos;i="4.95,774,1384300800"; d="scan'208";a="104769624" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 03 Feb 2014 21:05:27 +0000 Received: from [161.44.65.118] ([161.44.65.118]) (authenticated bits=0) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s13L5PhY012722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Feb 2014 21:05:26 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Kim Kinnear In-Reply-To: <50CD0E29-FAAC-428D-BDE6-D65A8F411F41@nominum.com> Date: Mon, 3 Feb 2014 16:05:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50CD0E29-FAAC-428D-BDE6-D65A8F411F41@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1510) X-Authenticated-User: kkinnear Cc: draft-ietf-dhc-dhcpv6-failover-design@tools.ietf.org, "dhcwg@ietf.org WG" , Kim Kinnear Subject: Re: [dhcwg] AD review of draft-ietf-dhc-dhcpv6-failover-design X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 21:05:30 -0000 Ted, You raise the question: does the third document stand on its own, or does it require this document. My thinking was that the third document absolutely requires this document. That is part of why it needs to be three documents. Otherwise the final document is too = complex and cumbersome to deal with. If we leave out the RFC 2119 language and push all of those decisions to be made and documented in the third document, I think we will end up with another chunk of work that cannot be digested by the WG and IESG. In my thinking, an actual implementation of a failover protocol will require both this document (whatever we call it) and the third document. I think you could probably skip reading the first one (at some risk), but you would absolutely require these last two. If that approach holds up (and I've not talked to Tomek or Bernie about it), then it sounds like we are talking significant rework of this document. Which isn't fun, but much of the point of *having* this document (in my mind) is to *not* defer that work until the final document. The goal here is to deal with the complexity as we go, and not have this mass of stuff that nobody can even read, let alone review, in the final document. So, I'd rather get this document right and agreed to, then just say "sure, we'll deal with it later". I think that is one of the important reasons that this document exists, so that we don't *have* to deal with it later. --------------------- So, what rework are you suggesting? Let me see if I understand. [yes, hmmm, well, ok, but, hmmm] Having written and deleted at least 6 different paragraphs trying to rephrase what you are suggesting as a necessary restructuring of the document, I'm thinking that it might be useful if you and Tomek and I had a conference call so that we could really understand what you are trying to convey regarding the required rework -- before we launch into it and end up having you say "no, that wasn't what I wanted you to do at all!". If we all three had the document in front of us, we might be able to at least understand what you want in much less time than it will take us to write (and read) pages and pages of email trying to get it nailed down. Thoughts? Regards -- Kim On Feb 3, 2014, at 2:30 PM, Ted Lemon wrote: > I've got some detailed comments, but the bottom line is that I am not = ready to submit this to the IESG. This is for two reasons. For the = first, see the last few paragraphs of this review. The other reason is = that it appears to be two documents. One document is trying to explain = the reasoning behind the choices made in developing the failover = protocol. The other is trying to specify how the protocol functions, = without specifying wire format stuff. >=20 > My understanding of the plan was that there would be a requirements = document, which is done. And then there would be this document, which = would be a specification of the protocol, but would not specify wire = format information. Finally, there would be a third document, which = would specify the wire format. >=20 > I don't think it's a problem to do a document that describes the = reasoning behind the protocol, and if the wire format document is going = to specify the actual protocol, including all the MUSTs and SHOULDs and = MAYs, then this document would be fine as an informational document. = However, if the third document will not stand on its own, this document = has to be standards track, as it is now. And in that case, it needs to = be chopped down substantially, and the normative language needs to be = thought through carefully and systematically, so that it's not scattered = all over the place and so that things that ought to be validated by = servers are not instead specified as requirements on administrators = (e.g. the suggestions below on the CONTACT message and on 5.2 paragraph = 3). >=20 > I think the right thing to do is make this document informational, get = rid of the RFC2119 language and the reference to RFC2119, and do that = bit in the third document. The more I think about this, the more I = think that's actually what we said we were going to do originally. = However, if you want to go forward with proposed standard, it's going to = require a lot of rework. Either way is fine with me, but the decision = needs to be made. From Fred.L.Templin@boeing.com Mon Feb 3 14:01:19 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC841A025F for ; Mon, 3 Feb 2014 14:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mr-Tnr2cEElE for ; Mon, 3 Feb 2014 14:01:17 -0800 (PST) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 7076D1A025D for ; Mon, 3 Feb 2014 14:01:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s13M1HI9010792; Mon, 3 Feb 2014 14:01:17 -0800 Received: from XCH-PHX-210.sw.nos.boeing.com (xch-phx-210.sw.nos.boeing.com [130.247.25.65]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s13M1CkZ010225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 3 Feb 2014 14:01:12 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.102]) by XCH-PHX-210.sw.nos.boeing.com ([169.254.10.145]) with mapi id 14.03.0174.001; Mon, 3 Feb 2014 14:01:11 -0800 From: "Templin, Fred L" To: Ralph Droms Thread-Topic: [dhcwg] Question on relay agent behavior in DHCPv6 prefix delegation Thread-Index: AQHPIRoaEVV3nCWgQkC0s04abY7hyJqkEkZw Date: Mon, 3 Feb 2014 22:01:11 +0000 Message-ID: <2134F8430051B64F815C691A62D983181C1EC8@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181C095B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181C0A8C@XCH-BLV-504.nw.nos.boeing.com> <0A4C2767-D7B2-4712-93F9-CC547871D7E9@nominum.com> <43881544-E397-4075-A898-4B2B91082738@gmail.com> In-Reply-To: <43881544-E397-4075-A898-4B2B91082738@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "dhcwg@ietf.org WG" , Andre Kostur , Lemon Ted Subject: Re: [dhcwg] Question on relay agent behavior in DHCPv6 prefix delegation X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 22:01:19 -0000 Hi Ralph, > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > Sent: Monday, February 03, 2014 11:57 AM > To: Templin, Fred L > Cc: dhcwg@ietf.org WG; Andre Kostur; Lemon Ted > Subject: Re: [dhcwg] Question on relay agent behavior in DHCPv6 prefix de= legation >=20 >=20 > On Feb 3, 2014, at 2:41 PM 2/3/14, Ted Lemon wrot= e: >=20 > > On Feb 3, 2014, at 1:10 PM, Templin, Fred L = wrote: > >> But, are there any more recent publications > >> that have either attempted or succeeded in specifying a standard metho= d? > > > > I can't think of any. >=20 > "DHCP Relay Agent Assignment Notification Option" , R. > Droms, B. Volz, O. Troan >=20 > 1. Introduction >=20 > The DHCP Relay Agent Assignment Notification option encapsulates > address and prefix options to indicate that an address or prefix has > been assigned. The option may also carry other information required > by the network element for configuration related to the assigned > address or prefix. >=20 > For example, a network administrator uses the DHCP Relay Agent > Assignment Notification option to inform a relay agent of a prefix > that has been delegated through DHCP PD to a DHCP client. The relay > agent notifies the network element on which the it is implemented of > the delegation information so the network element can add routing > information about the delegated prefix into the appropriate routing > protocols. >=20 > The dhc WG discussed the idea and decided not to take on the work due to = some fundamental issues in > using the option reliably; e.g., ensuring that all DHCPv6 messages were r= elayed through the device > that was actually interested in configuring itself for the delegated pref= ix. Thanks, I think I remember this now. I now have a use case where it is possible to ensure that all DHCPv6 messages are relayed through the same device. Would it make sense to revive this work and try again? > The idea was to formalize what is now accomplished through snooping. Is this kind of snooping for the purpose of routing system manipulation seen in common practice today? Thanks - Fred fred.l.templin@boeing.com > - Ralph >=20 >=20 > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Mon Feb 3 14:02:45 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53A11A0265 for ; Mon, 3 Feb 2014 14:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T84RjsEkf0iY for ; Mon, 3 Feb 2014 14:02:44 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id CB9EF1A0264 for ; Mon, 3 Feb 2014 14:02:44 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUvASBKFnCndr8/oOXejPKOcMncBo1s38@postini.com; Mon, 03 Feb 2014 14:02:45 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A96B11B82FF for ; Mon, 3 Feb 2014 14:02:44 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id A1CF0190043; Mon, 3 Feb 2014 14:02:44 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Feb 2014 14:02:44 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Mon, 3 Feb 2014 17:02:41 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <50CD0E29-FAAC-428D-BDE6-D65A8F411F41@nominum.com> To: Kim Kinnear X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: draft-ietf-dhc-dhcpv6-failover-design@tools.ietf.org, "dhcwg@ietf.org WG" Subject: Re: [dhcwg] AD review of draft-ietf-dhc-dhcpv6-failover-design X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 22:02:45 -0000 On Feb 3, 2014, at 4:05 PM, Kim Kinnear wrote: > If we all three had the document in front of us, we might be able to > at least understand what you want in much less time than it will take > us to write (and read) pages and pages of email trying to get it > nailed down. >=20 > Thoughts? I'm definitely game for this. Maybe we could do a webex, and one of = you could drive? From iesg-secretary@ietf.org Mon Feb 3 14:02:59 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0AB1A025F; Mon, 3 Feb 2014 14:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSeYbAsetO8U; Mon, 3 Feb 2014 14:02:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A95A1A026A; Mon, 3 Feb 2014 14:02:56 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140203220256.13039.41600.idtracker@ietfa.amsl.com> Date: Mon, 03 Feb 2014 14:02:56 -0800 Cc: dhc mailing list , dhc chair , RFC Editor Subject: [dhcwg] Protocol Action: 'Guidelines for Creating New DHCPv6 Options' to Best Current Practice (draft-ietf-dhc-option-guidelines-17.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 22:02:59 -0000 The IESG has approved the following document: - 'Guidelines for Creating New DHCPv6 Options' (draft-ietf-dhc-option-guidelines-17.txt) as Best Current Practice This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/ Technical Summary: This document provides guidance to prospective DHCPv6 developers to help them create new options that are easily adoptable by existing DHCPv6 software. Working Group Summary: This document has been in development in the DHC working group for a long time. It started out targetted for DHCPv4 but was reworked for DHCPv6 as the working group expects more options to be defined for DHCPv6 going fowrard. There has been solid support for this work. Document Quality: The document has had extensive review and input by the working group and "DHCP experts". Personnel: Bernie Volz is the document shepherd. Ted Lemon is the responsible AD. From volz@cisco.com Mon Feb 3 14:10:40 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80141A0271 for ; Mon, 3 Feb 2014 14:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUTRxsehY8V0 for ; Mon, 3 Feb 2014 14:10:38 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id DA5A11A01EE for ; Mon, 3 Feb 2014 14:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7618; q=dns/txt; s=iport; t=1391465437; x=1392675037; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3Q44G/RK/HWJ9pQ/o1j8+oNZZMOfsGyZ94DoPb6wUQ4=; b=Tw2iAAU08EAY+Augcy1nMcxaIrPrNOiWhfzseysQ0IxLbkVv3hQcSkNa tvzzyspu15FZLwXYqhgDGn2Av7H3tF8wyrXynOZ7R2v7023/HZ1PYSy1S c+DOBgGdeuKaNrq3+x2arDfvBJwUfaSodMSUaRa7Ti1V7zZ7yFovOotjv E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAIwT8FKtJV2a/2dsb2JhbABZgww4V74RgQ8WdIIlAQEBAwEBAQEkEzEDCwUHBAIBCA4DBAEBAQoUCQcnCxQJCAIEAQ0FCBOHYggNzWkTBI5YBisHAgSDHoEUAQOqS4Mtgio X-IronPort-AV: E=Sophos;i="4.95,774,1384300800"; d="scan'208";a="17638271" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 03 Feb 2014 22:10:37 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s13MAbox017964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Feb 2014 22:10:37 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 16:10:37 -0600 From: "Bernie Volz (volz)" To: Ralph Droms , Lemon Ted , Haberman Brian Thread-Topic: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg Thread-Index: AQHPIPEKjck3qetjqk62n8g/HJ5S75qkF15w Date: Mon, 3 Feb 2014 22:10:36 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE53CF8@xmb-rcd-x04.cisco.com> References: <52EBC3EA.1020104@innovationslab.net> <0B24D33F-07DA-4726-BD30-DBCCE93B4560@gmail.com> In-Reply-To: <0B24D33F-07DA-4726-BD30-DBCCE93B4560@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.247] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , "draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org" Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 22:10:40 -0000 >I'm assuming this entire document will be absorbed into >RFC3315bis at some point? Idle thought - is it worth >publishing this document now when it will likely be >superseded by RFC3315bis? Yes, that is the DHCPv6bis team's expectation as well. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ralph Droms Sent: Monday, February 03, 2014 10:03 AM To: Lemon Ted; Haberman Brian Cc: dhcwg@ietf.org WG; draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg On Feb 2, 2014, at 8:33 AM 2/2/14, Ted Lemon wrote: > On Jan 31, 2014, at 10:40 AM, Brian Haberman w= rote: >> I have done my AD Evaluation of draft-ietf-dhc-dhcpv6-unknown-msg=20 >> (since Ted is listed as a co-author). I only have a few points of=20 >> discussion on this document before we move it along in the=20 >> publication process. I am by no means a DHCP expert, so let me know=20 >> if I have gone off in the weeds... >>=20 >> 1. I would like to see a little more clarity in the purpose of this=20 >> document. It does a good job clarifying what a relay agent should do=20 >> with existing messages, but I think it would be useful to spell out=20 >> that is document is also dictating how future documents that define=20 >> new DHCP messages should specify relay behavior. >=20 > This is a good suggestion (actually, these are all good suggestions!). = I think the right solution to this is twofold. First, the following chang= e should be made at the end of 4.1 (this also addresses your point 2): >=20 > OLD: > In the case that a new type of message is sent by the server to a > relay agent but the relay agent does not recognize it, the message is > put into a Relay-forward message and sent to the server. > NEW: > New DHCP message types may be defined in future that are intended to > convey information from DHCP servers to relay agents. Relay agents > that do not implement these messages will not recognize that such > messages are intended for them. A relay agent that implements this > specification will necessarily forward such messages to the DHCP > servers to which it is configured to relay client messages. >=20 > At this time, no messages of this variety have been specified. > If such a message is specified in the future, the specification could > include text something like the following: >=20 > DHCP servers that send this new message type MAY, when they > receive a relayed message of this type, mark the relay agent to > which the message was sent as not implementing messages of this > type. In this case, the DHCP server MAY implement a strategy > of probing the relay agent occasionally to see if it has been > updated. >=20 > However, this is not strictly necessary, since DHCP does not provide > a signaling message for rejecting unexpected message types, and > therefore DHCP servers are not expected to respond to such messages. >=20 > Documents specifying new message types should use different types for > communicating *to* relay agents than are used for communicating *from* > relay agents, so that no confusion can occur where a message sent to > a relay agent is sent back to the DHCP server, which then tries to > process it as if it came from a relay agent. >=20 > In addition to this change, I'd propose the following change to the abstr= act: >=20 > OLD: > DHCPv6 is not specific about handling messages with unknown types. > This memo describes the problems and defines how a DHCPv6 server, > client or relay agent should behave when receiving unknown DHCPv6 > messages. This document updates RFC3315. >=20 > NEW: > DHCPv6 is not specific about handling messages with unknown types. > This memo describes the problems and defines how a DHCPv6 server, > client or relay agent should behave when receiving unknown DHCPv6 > messages. This document also provides advice for authors of future > documents defining new messages sent from DHCP servers to DHCP relay > agents, and should be read by potential authors of such documents. > This document updates RFC3315. This proposed text generally looks ok. I see the conversation has picked u= p a few messages later in the thread, so I'll jump ahead to that discussion= in another response. >=20 >> 2. In section 4.1, the text talks about targeting a message based on=20 >> its message type. To me, that suggests that a relay must know about=20 >> all DHCP message types. I thought (feel free to correct me) that=20 >> relay agents were mostly stateless and would forward all messages not=20 >> addressed to them to the configured DHCP server. This assumes that=20 >> all Relay-Reply messages are addressed to the relay directly. >=20 > That is the general effect of 4.1, but I hope the text above makes cleare= r what the issues are, both to you and to other future readers of the docum= ent. OK. >=20 >> 3. After having an exchange with Ralph Droms, I want to ask about=20 >> messages from servers to clients. If those messages are *not* in a=20 >> Relay-Reply message, but are received by a relay, should those=20 >> messages be dropped? If a server->client message is forwarded to a=20 >> server by the relay, should it be dropped by the server? >=20 > If this happens, it's an implementation bug: the DHCP server is not in co= nformance with RFC3315. I therefore think that we don't need to address i= t, although it would certainly break things if an implementation were to er= roneously do that. I think such an implementation would never make it to = the field, because it simply wouldn't work. Looking ahead to 4, seems to me we should consider the case in which a clie= nt and relay agent are multiplexing inbound DHCPv6 messages on the same por= t. >=20 >> 4. Is there a need to specifically discuss the behavior of single=20 >> devices that have both a relay agent and a client running at the same ti= me? >=20 > Hm. We generally treat these as two separate implementations that happe= n to be running on the same hardware. Also I think usually it's a client = and a server, not a relay agent and a server. We could add text addressin= g this, but I don't really see this coming up in practice. There isn't si= milar text in RFC3315, for instance, and we haven't seen evidence of implem= entors getting this wrong. I'm imagining a scenario in which a device is doing DHCP-PD and has a DHCPv= 6 client for local configuration. Don't underestimate implementors; jsut b= ecause they haven't gotten it wrong in the past doesn't mean we shouldn't c= onsider the case. I'm assuming this entire document will be absorbed into RFC3315bis at some = point? Idle thought - is it worth publishing this document now when it wil= l likely be superseded by RFC3315bis? >=20 >> 5. Also from Ralph... Could section 5 simply be written as "A client=20 >> or server MUST silently discard any received DHCPv6 message with an=20 >> unknown message type."? >=20 > Yes, I think this is a good edit. Qi, do you have time to do these edit= s? >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Feb 3 14:18:09 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F821A01EE for ; Mon, 3 Feb 2014 14:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpsZvnq2WX47 for ; Mon, 3 Feb 2014 14:18:06 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 802BD1A015D for ; Mon, 3 Feb 2014 14:18:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8210; q=dns/txt; s=iport; t=1391465886; x=1392675486; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=apGhPV4H65A7Eat/3B1IpWoD71uLRXtB78aGU1lCirc=; b=czfb+DV3gOlda/e5uUoVFq/GE3O5K0PTZPR4sfOoJdWhdxfl+qTIM41k CFGMcP2Fk2OYCzC+ov9WfRrPifIZaYJaHm1mgtsvNzVe8g0oziKV9jKRs PZ1Yd9FrthtZVHsYt2pX8fwTPasrNSLRKJ31THAqpd+ESAi5uVk5F5PSd M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAGQU8FKtJXG9/2dsb2JhbABZgww4V74RgQ8WdIIlAQEBAwEBAQEkEzEDCwUHBAIBCA4DBAEBAQoUCQcnCxQJCAIEAQ0FCBOHYggNzWcTBI5YBisHAgSDHoEUAQOqS4Mtgio X-IronPort-AV: E=Sophos;i="4.95,774,1384300800"; d="scan'208";a="301598919" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 03 Feb 2014 22:18:06 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s13MI5CD010463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Feb 2014 22:18:05 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 16:18:05 -0600 From: "Bernie Volz (volz)" To: Ralph Droms , Lemon Ted , Haberman Brian Thread-Topic: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg Thread-Index: AQHPIPEKjck3qetjqk62n8g/HJ5S75qkF15wgAACPlA= Date: Mon, 3 Feb 2014 22:18:04 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE53D2E@xmb-rcd-x04.cisco.com> References: <52EBC3EA.1020104@innovationslab.net> <0B24D33F-07DA-4726-BD30-DBCCE93B4560@gmail.com> <489D13FBFA9B3E41812EA89F188F018E1AE53CF8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AE53CF8@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.247] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , "draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org" Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 22:18:09 -0000 Sorry, just to be clear - this draft should be published; then it will be i= ncorporated into RFC3315bis. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Monday, February 03, 2014 5:11 PM To: Ralph Droms; Lemon Ted; Haberman Brian Cc: dhcwg@ietf.org WG; draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg >I'm assuming this entire document will be absorbed into RFC3315bis at=20 >some point? Idle thought - is it worth publishing this document now=20 >when it will likely be superseded by RFC3315bis? Yes, that is the DHCPv6bis team's expectation as well. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ralph Droms Sent: Monday, February 03, 2014 10:03 AM To: Lemon Ted; Haberman Brian Cc: dhcwg@ietf.org WG; draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg On Feb 2, 2014, at 8:33 AM 2/2/14, Ted Lemon wrote: > On Jan 31, 2014, at 10:40 AM, Brian Haberman w= rote: >> I have done my AD Evaluation of draft-ietf-dhc-dhcpv6-unknown-msg=20 >> (since Ted is listed as a co-author). I only have a few points of=20 >> discussion on this document before we move it along in the=20 >> publication process. I am by no means a DHCP expert, so let me know=20 >> if I have gone off in the weeds... >>=20 >> 1. I would like to see a little more clarity in the purpose of this=20 >> document. It does a good job clarifying what a relay agent should do=20 >> with existing messages, but I think it would be useful to spell out=20 >> that is document is also dictating how future documents that define=20 >> new DHCP messages should specify relay behavior. >=20 > This is a good suggestion (actually, these are all good suggestions!). = I think the right solution to this is twofold. First, the following chang= e should be made at the end of 4.1 (this also addresses your point 2): >=20 > OLD: > In the case that a new type of message is sent by the server to a > relay agent but the relay agent does not recognize it, the message is > put into a Relay-forward message and sent to the server. > NEW: > New DHCP message types may be defined in future that are intended to > convey information from DHCP servers to relay agents. Relay agents > that do not implement these messages will not recognize that such > messages are intended for them. A relay agent that implements this > specification will necessarily forward such messages to the DHCP > servers to which it is configured to relay client messages. >=20 > At this time, no messages of this variety have been specified. > If such a message is specified in the future, the specification could > include text something like the following: >=20 > DHCP servers that send this new message type MAY, when they > receive a relayed message of this type, mark the relay agent to > which the message was sent as not implementing messages of this > type. In this case, the DHCP server MAY implement a strategy > of probing the relay agent occasionally to see if it has been > updated. >=20 > However, this is not strictly necessary, since DHCP does not provide > a signaling message for rejecting unexpected message types, and > therefore DHCP servers are not expected to respond to such messages. >=20 > Documents specifying new message types should use different types for > communicating *to* relay agents than are used for communicating *from* > relay agents, so that no confusion can occur where a message sent to > a relay agent is sent back to the DHCP server, which then tries to > process it as if it came from a relay agent. >=20 > In addition to this change, I'd propose the following change to the abstr= act: >=20 > OLD: > DHCPv6 is not specific about handling messages with unknown types. > This memo describes the problems and defines how a DHCPv6 server, > client or relay agent should behave when receiving unknown DHCPv6 > messages. This document updates RFC3315. >=20 > NEW: > DHCPv6 is not specific about handling messages with unknown types. > This memo describes the problems and defines how a DHCPv6 server, > client or relay agent should behave when receiving unknown DHCPv6 > messages. This document also provides advice for authors of future > documents defining new messages sent from DHCP servers to DHCP relay > agents, and should be read by potential authors of such documents. > This document updates RFC3315. This proposed text generally looks ok. I see the conversation has picked u= p a few messages later in the thread, so I'll jump ahead to that discussion= in another response. >=20 >> 2. In section 4.1, the text talks about targeting a message based on=20 >> its message type. To me, that suggests that a relay must know about=20 >> all DHCP message types. I thought (feel free to correct me) that=20 >> relay agents were mostly stateless and would forward all messages not=20 >> addressed to them to the configured DHCP server. This assumes that=20 >> all Relay-Reply messages are addressed to the relay directly. >=20 > That is the general effect of 4.1, but I hope the text above makes cleare= r what the issues are, both to you and to other future readers of the docum= ent. OK. >=20 >> 3. After having an exchange with Ralph Droms, I want to ask about=20 >> messages from servers to clients. If those messages are *not* in a=20 >> Relay-Reply message, but are received by a relay, should those=20 >> messages be dropped? If a server->client message is forwarded to a=20 >> server by the relay, should it be dropped by the server? >=20 > If this happens, it's an implementation bug: the DHCP server is not in co= nformance with RFC3315. I therefore think that we don't need to address i= t, although it would certainly break things if an implementation were to er= roneously do that. I think such an implementation would never make it to = the field, because it simply wouldn't work. Looking ahead to 4, seems to me we should consider the case in which a clie= nt and relay agent are multiplexing inbound DHCPv6 messages on the same por= t. >=20 >> 4. Is there a need to specifically discuss the behavior of single=20 >> devices that have both a relay agent and a client running at the same ti= me? >=20 > Hm. We generally treat these as two separate implementations that happe= n to be running on the same hardware. Also I think usually it's a client = and a server, not a relay agent and a server. We could add text addressin= g this, but I don't really see this coming up in practice. There isn't si= milar text in RFC3315, for instance, and we haven't seen evidence of implem= entors getting this wrong. I'm imagining a scenario in which a device is doing DHCP-PD and has a DHCPv= 6 client for local configuration. Don't underestimate implementors; jsut b= ecause they haven't gotten it wrong in the past doesn't mean we shouldn't c= onsider the case. I'm assuming this entire document will be absorbed into RFC3315bis at some = point? Idle thought - is it worth publishing this document now when it wil= l likely be superseded by RFC3315bis? >=20 >> 5. Also from Ralph... Could section 5 simply be written as "A client=20 >> or server MUST silently discard any received DHCPv6 message with an=20 >> unknown message type."? >=20 > Yes, I think this is a good edit. Qi, do you have time to do these edit= s? >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Tue Feb 4 01:36:13 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7131A03DA; Tue, 4 Feb 2014 01:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3uKZy5iPfDB; Tue, 4 Feb 2014 01:36:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FC91A03C7; Tue, 4 Feb 2014 01:36:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2014 01:36:11 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 09:36:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : IP Connectivity Status Notifications for DHCPv6 Authors : Prashanth Patil Mohamed Boucadair Dan Wing Tirumaleswar Reddy Filename : draft-ietf-dhc-conn-status-00.txt Pages : 10 Date : 2014-02-03 Abstract: This specification extends DHCPv6 so that a DHCPv6 Relay Agent can dynamically inform the DHCPv6 server about the IP connectivity status of a host. The IP connectivity status information is also triggered by any change in the connectivity as provided to the host. The DHCPv6 server uses this information as an input to its decision- making about configuration parameters to be conveyed to that host. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-conn-status/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-conn-status-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From volz@cisco.com Tue Feb 4 05:17:35 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0C21A0435 for ; Tue, 4 Feb 2014 05:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrRYUwYS8cou for ; Tue, 4 Feb 2014 05:17:32 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 822E31A0420 for ; Tue, 4 Feb 2014 05:17:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17720; q=dns/txt; s=iport; t=1391519852; x=1392729452; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=MgUkuj5TFlimsmO7+BTlkkENTPh/slnQS7zzOy/gxQ8=; b=NejVL5tUQWAlxTLtnFJ/Q3VxOmYI0dBNslt5hVeJEZjXXY7wEeK7UD2j 32km6NHQs/BPD5hOAIOslRp9+xrRx+uYVwSiirHrZzoRXjqCwy8Aqgs0G RK+LHmGB82trbcTG5tgOhlaY/bEj9mFMEWnTlu6bKhUlnjXDvwC2YeLyp c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFANLn8FKtJXG8/2dsb2JhbABZgkhEOFe+GIELFnSCJQEBAQQdEEEbAgEIEQQBAQsdBzIUCQgBAQQTCAGHfA3OLBeOHgMjNwGDJIEUBJRClgqDLYFpQQ X-IronPort-AV: E=Sophos;i="4.95,779,1384300800"; d="scan'208,217";a="301701673" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 04 Feb 2014 13:17:32 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s14DHV0g019583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Feb 2014 13:17:31 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 07:17:31 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Call for Agenda Items for IETF-89 (London) Thread-Index: Ac8QicsdauE7TMjdQ2Oym9UwCvtTNwRIY+Dg Date: Tue, 4 Feb 2014 13:17:30 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE54FDD@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1AE1B259@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AE1B259@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.97] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AE54FDDxmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: Re: [dhcwg] Call for Agenda Items for IETF-89 (London) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 13:17:35 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AE54FDDxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a reminder to submit agenda items - we haven't received many requests = yet and have a 2.5 hour slot. - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Monday, January 13, 2014 1:04 PM To: dhcwg@ietf.org Subject: [dhcwg] Call for Agenda Items for IETF-89 (London) Hi: The London IETF is not that far off (Mar 2-7). See http://www.ietf.org/meet= ing/89/index.html for more details, including venue information and importa= nt dates. Thus, we are starting the call for agenda items. The co-chairs will finaliz= e the agenda about two weeks before the meeting and will give priority to i= tems as follows (in this order): 1. WG documents with active working group discussion or that are deem= ed critical (i.e., have upcoming milestones) 2. WG documents with little or no discussion (provided there is a str= ong reason for the discussion ... i.e., a higher bandwidth discussion is ne= eded) 3. Non WG documents with active working group discussion 4. Non WG documents with little or no discussion We will limit the number of presentations to reduce the chance that we don'= t get to them all. Please be sure to focus your presentations on issues that need discussion o= r input (new work can include an overview, but should be kept to a minimum)= . Status updates can be sent to the mailing list. If you would like time, please indicate: - Draft name or topic - Who will present - How much time is needed - Why is time needed (tell us why you can't get what you need by p= osting on the mailing list) and what will be covered We have requested a 2.5 hour time slot. Thanks. - Tomek & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1AE54FDDxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a reminder to sub= mit agenda items – we haven’t received many requests yet and ha= ve a 2.5 hour slot.

 

-&nb= sp;         Bernie

 

From: dhcwg [m= ailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Monday, January 13, 2014 1:04 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Call for Agenda Items for IETF-89 (London)

 

Hi:

 

The London IETF is not that far off (Mar 2-7). See <= a href=3D"http://www.ietf.org/meeting/89/index.html"> http://www.ietf.org/meeting/89/index.html for more details, including v= enue information and important dates.

 

Thus, we are starting the call for agenda items. The= co-chairs will finalize the agenda about two weeks before the meeting and = will give priority to items as follows (in this order):

 

1.     &= nbsp; WG documents with active working group discussion o= r that are deemed critical (i.e., have upcoming milestones)

2.     &= nbsp; WG documents with little or no discussion (provided= there is a strong reason for the discussion … i.e., a higher bandwid= th discussion is needed)

3.     &= nbsp; Non WG documents with active working group discussi= on

4.     &= nbsp; Non WG documents with little or no discussion<= /o:p>

 

We will limit the number of presentations to reduce = the chance that we don’t get to them all.

 

Please be sure to focus your presentations on issues= that need discussion or input (new work can include an overview, but shoul= d be kept to a minimum). Status updates can be sent to the mailing list.

 

If you would like time, please indicate:<= /p>

-     &= nbsp;    Draft name or topic

-     &= nbsp;    Who will present

-     &= nbsp;    How much time is needed

-     &= nbsp;    Why is time needed (tell us why you can’t get= what you need by posting on the mailing list) and what will be covered

 

We have requested a 2.5 hour time slot.

 

Thanks.

 

-     &= nbsp;    Tomek & Bernie

 

--_000_489D13FBFA9B3E41812EA89F188F018E1AE54FDDxmbrcdx04ciscoc_-- From volz@cisco.com Tue Feb 4 05:25:35 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38F91A0416 for ; Tue, 4 Feb 2014 05:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgZwKbzRKlKs for ; Tue, 4 Feb 2014 05:25:30 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB0C1A041E for ; Tue, 4 Feb 2014 05:25:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1819; q=dns/txt; s=iport; t=1391520329; x=1392729929; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PyU/wNDlIRBuzrZEPQMn8qxvK+H06GL1ZsstIqRrdQ4=; b=NXhLJ9qdkEqsksMNaS+Fn5t5mVzcbgPZ8CEWNhVEv7palcIfJ7iHvVe8 ki5m57cux2q7ZcwIqiTmCvycUnvLFlmLjsW2I/GcQ3QaB3WkPgERcGm9F GgKTughB1G4oMTKoJQ3UVSQNfr2ivmJNDPgC13vMe/GjVUoFW9q8lS7T2 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAPnp8FKtJV2d/2dsb2JhbABZDoJ+OFe+GIELFnSCJQEBAQQBAQE3NBcEAgEIDgMEAQELFAkHJwsUCQgCBAESCId9Dc4yEwSORCYSBoMegRQEqkyCbj+CKg X-IronPort-AV: E=Sophos;i="4.95,779,1384300800"; d="scan'208";a="17807702" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP; 04 Feb 2014 13:25:29 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s14DPTGw022175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Feb 2014 13:25:29 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 07:25:28 -0600 From: "Bernie Volz (volz)" To: Timothy Winters , "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] DHCPv6 Stateful Issues Thread-Index: AQHPIQJmiQAo8HL4V0q/V8TsAiMQoJqlFU9A Date: Tue, 4 Feb 2014 13:25:28 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE5502E@xmb-rcd-x04.cisco.com> References: <44F7934F-540F-4B41-B37D-08B0C0453D72@iol.unh.edu> In-Reply-To: <44F7934F-540F-4B41-B37D-08B0C0453D72@iol.unh.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] DHCPv6 Stateful Issues X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 13:25:36 -0000 Hi Tim: I too would have expected just the IA_NA (IAADDR) to be declined. You don't= mention what the clients are doing in this case (sending a Decline with bo= th the IA_NA and IA_PD or sending a Release with both - or sending a Declin= e for the IA_NA and Release for the IA_PD)? A DAD conflict should result in a Decline. So, it would seem to me that the= added step of sending a Release for the IA_PD (IAPREFIX) is extra effort a= nd not necessary/warranted. And I would hope these clients aren't sending a= Decline for the IA_PD (IAPREFIX). Also, did the routers doing the IA_PD Release earlier request the IA_NA and= IA_PD in the same packet (transaction) or different ones? Be nice if you had a packet trace available to see what the interaction her= e is? This does sound like a candidate for discussion in the draft, but we need a= bit more information before considering to add it. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Timothy Winters Sent: Monday, February 03, 2014 12:07 PM To: dhcwg@ietf.org WG Subject: [dhcwg] DHCPv6 Stateful Issues Hi Bernie, While testing some IPv6 CE Router I've noticed an issue that this draft mi= ght want to address. When a DHCP Client receives both the IA_NA and IA_PD = in the reply, the Client performs DAD on the IA_NA. If DAD fails some imp= lementations keep the IA_PD and try for a different IA_NA. Other IPv6 CE = Routers will Release the IA_PD in this scenario. =20 I would think the proper thing to do would be to keep the IA_PD so your L= AN as addressing. Is something that we can talk about in this document? ~Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From alexandru.petrescu@gmail.com Tue Feb 4 06:05:48 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0CF1A00E4 for ; Tue, 4 Feb 2014 06:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uP0fgay3rdf for ; Tue, 4 Feb 2014 06:05:45 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id C3BB51A0135 for ; Tue, 4 Feb 2014 06:05:44 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s14E5h9w001968 for ; Tue, 4 Feb 2014 15:05:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 829AD2029FE for ; Tue, 4 Feb 2014 15:06:02 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7A75D2007F6 for ; Tue, 4 Feb 2014 15:06:02 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s14E5gVG022008 for ; Tue, 4 Feb 2014 15:05:43 +0100 Message-ID: <52F0F3B6.4020505@gmail.com> Date: Tue, 04 Feb 2014 15:05:42 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <2134F8430051B64F815C691A62D983181C095B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181C0A8C@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181C0A8C@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Question on relay agent behavior in DHCPv6 prefix delegation X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 14:05:48 -0000 Le 03/02/2014 19:10, Templin, Fred L a écrit : > Hi Andre, > >> -----Original Message----- >> From: Andre Kostur [mailto:akostur@incognito.com] >> Sent: Monday, February 03, 2014 9:36 AM >> To: Templin, Fred L >> Cc: dhcwg@ietf.org WG >> Subject: Re: [dhcwg] Question on relay agent behavior in DHCPv6 prefix delegation >> >> The RFC doesn't get into details since it may not even be the >> delegating router doing the route updates. As an example, in a cable >> network, it may be the CMTS (who plays the role of Relay Agent from >> DHCPv6's perspective) who is snooping the PD traffic and may emit the >> appropriate routing updates into the network (using some other >> standard dynamic routing protocol such as OSPF). > > Thanks for this. So, it seems that the RFC3633 DHCPv6 relays (and maybe > also servers) can snoop the PD exchanges and update the routing system > via some unspecified means. But, are there any more recent publications > that have either attempted or succeeded in specifying a standard method? Solutions (like 'snooping') to the problem have been explored in a number of documents at IETF and others. I with co-authors have attempted to formulate it as a problem in October 2014, and analyzed some solutions "Route Problem at Relay during DHCPv6 Prefix Delegation" draft-petrescu-relay-route-pd-problem-00.txt Alex > > Thanks - Fred > fred.l.templin@boeing.com > >> On Mon, Feb 3, 2014 at 8:49 AM, Templin, Fred L >> wrote: >>> Hi, RFC3633 says: >>> >>> "14. Relay agent behavior >>> >>> A relay agent forwards messages containing Prefix Delegation options >>> in the same way as described in section 20, "Relay Agent Behavior" of >>> RFC 3315. >>> >>> If a delegating router communicates with a requesting router through >>> a relay agent, the delegating router may need a protocol or other >>> out-of-band communication to add routing information for delegated >>> prefixes into the provider edge router." >>> >>> My question is, since the publication of RFC3633 has there been a >>> new RFC published that specifies "a protocol or other out-of-band >>> communication to add routing information"? >>> >>> Thanks - Fred >>> fred.l.templin@boeing.com >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >> >> >> >> -- >> Andre Kostur > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > From simon.perreault@viagenie.ca Tue Feb 4 06:05:57 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88BD1A0212 for ; Tue, 4 Feb 2014 06:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aB6eClWR68Kd for ; Tue, 4 Feb 2014 06:05:55 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id DDE811A020D for ; Tue, 4 Feb 2014 06:05:54 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6E55C4037B for ; Tue, 4 Feb 2014 09:05:54 -0500 (EST) Message-ID: <52F0F3C2.20807@viagenie.ca> Date: Tue, 04 Feb 2014 09:05:54 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> In-Reply-To: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 14:05:58 -0000 This is getting better! Some editorial suggestions about this new part: > option-code OPTION_HOST_CONNECTIVITY (TBA). > option-len 1. > status 8-bit field indicating IP family connectivity status > of a host. The following codes are defined: > +------+----------+ > | Bit | Status | > +----- +----------+ > | 1 | IPv4 | > | 2 | IPv6 | > | 3..8 | Reserved | > +------+----------+ Two things: - It is customary to number bits starting from zero. - It would be better to illustrate the bits in the preceding figure rather than in a separate table. Something like this: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_HOST_CONNECTIVITY | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved |S|F| | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Then explain what Reserved, S, and F stand for. No need for a separate table. In that figure, please also offset bit numbers by one character to the right. The rationale being that we are numbering bits, not frontiers between bits. Also the 3-byte empty space needs to be either named or removed. This would give either this: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_HOST_CONNECTIVITY | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved |S|F| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or this: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_HOST_CONNECTIVITY | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved |S|F| > +-+-+-+-+-+-+-+-+ Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ted.Lemon@nominum.com Tue Feb 4 06:14:51 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3481A00E9 for ; Tue, 4 Feb 2014 06:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Gp1Tzmh8Eab for ; Tue, 4 Feb 2014 06:14:50 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 70A291A00EC for ; Tue, 4 Feb 2014 06:14:50 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUvD12uEEQRj9dFP0/yLCVrCB3jWPvCzX@postini.com; Tue, 04 Feb 2014 06:14:50 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EB8601B831A for ; Tue, 4 Feb 2014 06:14:49 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D1EB6190052; Tue, 4 Feb 2014 06:14:49 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Feb 2014 06:14:49 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <52F0F3C2.20807@viagenie.ca> Date: Tue, 4 Feb 2014 09:14:46 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 14:14:51 -0000 On Feb 4, 2014, at 9:05 AM, Simon Perreault = wrote: > This is getting better! It is, but I still don't understand why this is the right architectural = solution. We already have the DHCPv6 link-layer address relay option. = This allows a DHCPv4/DHCPv6 server to track clients and make = allocations centrally in the same way that this proposal allows it to = happen on relays. =46rom a management perspective, and from a relay = complexity perspective, doing it on the server seems like a win. Can you guys speak to this question? From simon.perreault@viagenie.ca Tue Feb 4 06:28:07 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8501D1A002A for ; Tue, 4 Feb 2014 06:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzzMigxiOZjL for ; Tue, 4 Feb 2014 06:28:05 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 328071A00DB for ; Tue, 4 Feb 2014 06:28:05 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B1FEB4037B; Tue, 4 Feb 2014 09:28:04 -0500 (EST) Message-ID: <52F0F8F4.4060905@viagenie.ca> Date: Tue, 04 Feb 2014 09:28:04 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ted Lemon References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> In-Reply-To: <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 14:28:07 -0000 Le 2014-02-04 09:14, Ted Lemon a écrit : > We already have the DHCPv6 link-layer address relay option. This > allows a DHCPv4/DHCPv6 server to track clients and make allocations > centrally in the same way that this proposal allows it to happen on > relays. From a management perspective, and from a relay complexity > perspective, doing it on the server seems like a win. I'm sorry, I don't understand what you're suggesting. How would the link-layer address be of any use? We want to know what kind of IP-layer connectivity a client has, and we don't care about the link layer. What do you mean by "making allocations"? How is the relay "making allocations" in draft conn-status? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ted.Lemon@nominum.com Tue Feb 4 06:46:32 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FA61A0137 for ; Tue, 4 Feb 2014 06:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNsyZDreZkjV for ; Tue, 4 Feb 2014 06:46:30 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 55A9D1A0124 for ; Tue, 4 Feb 2014 06:46:30 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUvD9RmPm0arB8nxtXT/aNZYTL47PXFZO@postini.com; Tue, 04 Feb 2014 06:46:30 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F02AE1B82C3 for ; Tue, 4 Feb 2014 06:46:29 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D42D4190052; Tue, 4 Feb 2014 06:46:29 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Feb 2014 06:46:29 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <52F0F8F4.4060905@viagenie.ca> Date: Tue, 4 Feb 2014 09:46:27 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 14:46:32 -0000 On Feb 4, 2014, at 9:28 AM, Simon Perreault = wrote: > I'm sorry, I don't understand what you're suggesting. How would the > link-layer address be of any use? We want to know what kind of = IP-layer > connectivity a client has, and we don't care about the link layer. = What > do you mean by "making allocations"? How is the relay "making > allocations" in draft conn-status? You can use the link-layer address in DHCPv6 to correlate to the = link-layer address in DHCPv4. By "make allocations" I mean "do what = DHCP does, including assigning parameters." Sorry for the imprecision. From simon.perreault@viagenie.ca Tue Feb 4 06:57:45 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEC41A00EC for ; Tue, 4 Feb 2014 06:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_AjnDPw0tCK for ; Tue, 4 Feb 2014 06:57:43 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id CCD521A00E4 for ; Tue, 4 Feb 2014 06:57:43 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3F4A14037B; Tue, 4 Feb 2014 09:57:43 -0500 (EST) Message-ID: <52F0FFE6.3050802@viagenie.ca> Date: Tue, 04 Feb 2014 09:57:42 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ted Lemon References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 14:57:45 -0000 Le 2014-02-04 09:46, Ted Lemon a écrit : > You can use the link-layer address in DHCPv6 to correlate to the > link-layer address in DHCPv4. By "make allocations" I mean "do what > DHCP does, including assigning parameters." Sorry for the > imprecision. Ah, I see. One answer is that this needs to work with SLAAC. I'll let the authors reply. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ted.Lemon@nominum.com Tue Feb 4 08:04:46 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7161A0128 for ; Tue, 4 Feb 2014 08:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnPCMJh47B29 for ; Tue, 4 Feb 2014 08:04:45 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 144091A0124 for ; Tue, 4 Feb 2014 08:04:45 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUvEPnAOqFryP+b4q23x791jZ3hBMFehM@postini.com; Tue, 04 Feb 2014 08:04:45 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9FB811B82F7 for ; Tue, 4 Feb 2014 08:04:44 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 7DE07190052; Tue, 4 Feb 2014 08:04:44 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Feb 2014 08:04:44 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <52F0FFE6.3050802@viagenie.ca> Date: Tue, 4 Feb 2014 11:04:42 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> <52F0FFE6.3050802@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:04:46 -0000 On Feb 4, 2014, at 9:57 AM, Simon Perreault = wrote: > One answer is that this needs to work with SLAAC. How can it work with SLAAC? From sunqi.csnet.thu@gmail.com Tue Feb 4 08:31:13 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293561A0157 for ; Tue, 4 Feb 2014 08:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrZupLi5YrVs for ; Tue, 4 Feb 2014 08:31:10 -0800 (PST) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5595D1A013B for ; Tue, 4 Feb 2014 08:31:10 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id rq2so8679028pbb.9 for ; Tue, 04 Feb 2014 08:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=w/EFRE212wr4+DpjveX9HSraiXpivsVZXNsZ1o7h/AQ=; b=jpDUfaCWT6NqYBer+SylLN/Q5SbesKkndDF+gDVCEC6P4hkXlRR08XbiHxSQmbvYdY hIxUFq7VkY7ihlsWHPIoru4/fIgSMwCuOPC3vb3fVJ+MTcxTAM/F+h+/s0YdzYBzNBJ1 kfF3AsiPYcnxofXON6lDbdEI7LQFVQ47e5MJs4pttPM8G61dfeRay2fD77yt3hA2qOID fEZzL+67ep1jlOArR9EQhxjswGBJjp6xWE0G3NYLyH95WogJXMIQHXPUMqvAWjv/sybY ahWXvDzUIv0LHqLI4Gfn2pNNyHIHWXRFi3MZXpdf0B778Yax/JjZ++G4XRgdkTM1ecjB TM8g== X-Received: by 10.68.201.226 with SMTP id kd2mr10623090pbc.157.1391531465949; Tue, 04 Feb 2014 08:31:05 -0800 (PST) Received: from [172.20.10.3] ([219.141.159.40]) by mx.google.com with ESMTPSA id tu3sm173936121pab.1.2014.02.04.08.30.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Feb 2014 08:31:05 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-98-907042557 From: Qi Sun In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AE54FDD@xmb-rcd-x04.cisco.com> Date: Wed, 5 Feb 2014 00:25:02 +0800 Message-Id: <5C539E9F-65CE-4C3F-9711-532AC3556DA6@gmail.com> References: <489D13FBFA9B3E41812EA89F188F018E1AE1B259@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AE54FDD@xmb-rcd-x04.cisco.com> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1085) Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Call for Agenda Items for IETF-89 (London) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:31:13 -0000 --Apple-Mail-98-907042557 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Chairs, During the WGLC of draft-ietf-dhcpv4-over-dhcpv6, we received a lot of = comments/suggestions. We've made an update to address the issues raised. = Considering some technical changes are relatively important, we would = like to have a slot to present it in London. Here is the request info: Draft name: DHCPv4 over DHCPv6 Transport Presenter: Qi Sun Time slot: 10 min Why: Need to discuss the updates according to the issue tracker. Thanks! Qi On 2014-2-4, at =E4=B8=8B=E5=8D=889:17, Bernie Volz (volz) wrote: > Just a reminder to submit agenda items =E2=80=93 we haven=E2=80=99t = received many requests yet and have a 2.5 hour slot. > =20 > - Bernie > =20 > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz = (volz) > Sent: Monday, January 13, 2014 1:04 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Call for Agenda Items for IETF-89 (London) > =20 > Hi: > =20 > The London IETF is not that far off (Mar 2-7). See = http://www.ietf.org/meeting/89/index.html for more details, including = venue information and important dates. > =20 > Thus, we are starting the call for agenda items. The co-chairs will = finalize the agenda about two weeks before the meeting and will give = priority to items as follows (in this order): > =20 > 1. WG documents with active working group discussion or that are = deemed critical (i.e., have upcoming milestones) > 2. WG documents with little or no discussion (provided there is = a strong reason for the discussion =E2=80=A6 i.e., a higher bandwidth = discussion is needed) > 3. Non WG documents with active working group discussion > 4. Non WG documents with little or no discussion > =20 > We will limit the number of presentations to reduce the chance that we = don=E2=80=99t get to them all. > =20 > Please be sure to focus your presentations on issues that need = discussion or input (new work can include an overview, but should be = kept to a minimum). Status updates can be sent to the mailing list. > =20 > If you would like time, please indicate: > - Draft name or topic > - Who will present > - How much time is needed > - Why is time needed (tell us why you can=E2=80=99t get what = you need by posting on the mailing list) and what will be covered > =20 > We have requested a 2.5 hour time slot. > =20 > Thanks. > =20 > - Tomek & Bernie > =20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail-98-907042557 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear = Chairs,

During the WGLC of = draft-ietf-dhcpv4-over-dhcpv6, we received a lot of = comments/suggestions. We've made an update to address the issues raised. = Considering some technical changes are relatively important, we would = like to have a slot to present it in = London.

Here is the request = info:
Draft name: DHCPv4 over DHCPv6 = Transport
Presenter: Qi Sun
Time slot: 10 = min
Why: Need to discuss the updates according to the issue = tracker.

Thanks!
Qi

On 2014-2-4, at =E4=B8=8B=E5=8D=889:17, Bernie Volz (volz) = wrote:

Just a reminder to submit agenda items =E2=80=93 we = haven=E2=80=99t received many requests yet and have a 2.5 hour = slot.
 
- Bernie
From: dhcwg = [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz = (volz)
Sent: Monday, January 13, 2014 = 1:04 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Call for Agenda = Items for IETF-89 (London)
 
Hi:
 
The London IETF is not that = far off (Mar 2-7). See  for more details, including = venue information and important dates.
To: Alexandru Petrescu , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Question on relay agent behavior in DHCPv6 prefix delegation Thread-Index: AQHPIbJAeKpILTaZ/0WCAVjarV2yQ5qlRyGg Date: Tue, 4 Feb 2014 16:31:52 +0000 Message-ID: <2134F8430051B64F815C691A62D983181C2885@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181C095B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181C0A8C@XCH-BLV-504.nw.nos.boeing.com> <52F0F3B6.4020505@gmail.com> In-Reply-To: <52F0F3B6.4020505@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [dhcwg] Question on relay agent behavior in DHCPv6 prefix delegation X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:32:03 -0000 Hi Alex, > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Alexandru Petres= cu > Sent: Tuesday, February 04, 2014 6:06 AM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] Question on relay agent behavior in DHCPv6 prefix de= legation >=20 > Le 03/02/2014 19:10, Templin, Fred L a =E9crit : > > Hi Andre, > > > >> -----Original Message----- > >> From: Andre Kostur [mailto:akostur@incognito.com] > >> Sent: Monday, February 03, 2014 9:36 AM > >> To: Templin, Fred L > >> Cc: dhcwg@ietf.org WG > >> Subject: Re: [dhcwg] Question on relay agent behavior in DHCPv6 prefix= delegation > >> > >> The RFC doesn't get into details since it may not even be the > >> delegating router doing the route updates. As an example, in a cable > >> network, it may be the CMTS (who plays the role of Relay Agent from > >> DHCPv6's perspective) who is snooping the PD traffic and may emit the > >> appropriate routing updates into the network (using some other > >> standard dynamic routing protocol such as OSPF). > > > > Thanks for this. So, it seems that the RFC3633 DHCPv6 relays (and maybe > > also servers) can snoop the PD exchanges and update the routing system > > via some unspecified means. But, are there any more recent publications > > that have either attempted or succeeded in specifying a standard method= ? >=20 > Solutions (like 'snooping') to the problem have been explored in a > number of documents at IETF and others. I have been down this road before too, and can dig up some of my old expired drafts if there is interest. I also remember being actively engaged in the RAAN option discussions a long while back and sort of lost track of where that all ended up, but thanks to Ralph for his update on the status. > I with co-authors have attempted to formulate it as a problem in October > 2014, and analyzed some solutions > "Route Problem at Relay during DHCPv6 Prefix Delegation" > draft-petrescu-relay-route-pd-problem-00.txt That is interesting. Are you planning to continue this work? Thanks - Fred fred.l.templin@boeing.com =20 > Alex >=20 > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> On Mon, Feb 3, 2014 at 8:49 AM, Templin, Fred L > >> wrote: > >>> Hi, RFC3633 says: > >>> > >>> "14. Relay agent behavior > >>> > >>> A relay agent forwards messages containing Prefix Delegation opti= ons > >>> in the same way as described in section 20, "Relay Agent Behavior= " of > >>> RFC 3315. > >>> > >>> If a delegating router communicates with a requesting router thro= ugh > >>> a relay agent, the delegating router may need a protocol or other > >>> out-of-band communication to add routing information for delegate= d > >>> prefixes into the provider edge router." > >>> > >>> My question is, since the publication of RFC3633 has there been a > >>> new RFC published that specifies "a protocol or other out-of-band > >>> communication to add routing information"? > >>> > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>> > >>> _______________________________________________ > >>> dhcwg mailing list > >>> dhcwg@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dhcwg > >> > >> > >> > >> -- > >> Andre Kostur > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > > > >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From rdroms.ietf@gmail.com Tue Feb 4 08:33:56 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C9E1A0201 for ; Tue, 4 Feb 2014 08:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfubviYFx_fP for ; Tue, 4 Feb 2014 08:33:53 -0800 (PST) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 39D541A01BE for ; Tue, 4 Feb 2014 08:33:52 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id f11so12606800qae.35 for ; Tue, 04 Feb 2014 08:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mfJCkTD3xquJ5IMyc3ZUKK1cO/7MOXjqe80969l+4s4=; b=fN3PvYv+fqA11dAhT95dLRCfDo6EEiWJ8RK4z/6Z7GlAxT5cXnywk9/kaCsVqXFTrO oBk3M/FYp7uAoCNgAamHGYtTBbqsXQYmFpMfHoWB67DuQxyYLNHzLDnLBHPwQTGTyjDR lpn6+ONRvVl4SwpCV5R68lkwhM4/Rc5FKxu17x0s63d7VjAfTvqcjiiW3qQReq7gKO+D ttFtcgZW4hmce4SdqWbbsRzRnIwW6qQI14L5fKNL3cM7WGOAXWiw6Yjhif70YbMqAlJK KOVoTeFVG5KcI9sJBkuW8ixuMsN5XZwxDqDKdSHTbbnfgQJrSQroHcWLHh9EWAn4tuAU PhkA== X-Received: by 10.140.100.135 with SMTP id s7mr20774790qge.114.1391531631734; Tue, 04 Feb 2014 08:33:51 -0800 (PST) Received: from [161.44.68.171] ([161.44.68.171]) by mx.google.com with ESMTPSA id l2sm68221201qae.19.2014.02.04.08.33.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Feb 2014 08:33:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ralph Droms In-Reply-To: <2134F8430051B64F815C691A62D983181C1EC8@XCH-BLV-504.nw.nos.boeing.com> Date: Tue, 4 Feb 2014 11:33:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <22985236-2327-49EF-8FE1-4569972DCC00@gmail.com> References: <2134F8430051B64F815C691A62D983181C095B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181C0A8C@XCH-BLV-504.nw.nos.boeing.com> <0A4C2767-D7B2-4712-93F9-CC547871D7E9@nominum.com> <43881544-E397-4075-A898-4B2B91082738@gmail.com> <2134F8430051B64F815C691A62D983181C1EC8@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1510) Cc: "dhcwg@ietf.org WG" , Andre Kostur , Lemon Ted Subject: Re: [dhcwg] Question on relay agent behavior in DHCPv6 prefix delegation X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:33:57 -0000 On Feb 3, 2014, at 5:01 PM 2/3/14, "Templin, Fred L" = wrote: > Hi Ralph, >=20 >> -----Original Message----- >> From: Ralph Droms [mailto:rdroms.ietf@gmail.com] >> Sent: Monday, February 03, 2014 11:57 AM >> To: Templin, Fred L >> Cc: dhcwg@ietf.org WG; Andre Kostur; Lemon Ted >> Subject: Re: [dhcwg] Question on relay agent behavior in DHCPv6 = prefix delegation >>=20 >>=20 >> On Feb 3, 2014, at 2:41 PM 2/3/14, Ted Lemon = wrote: >>=20 >>> On Feb 3, 2014, at 1:10 PM, Templin, Fred L = wrote: >>>> But, are there any more recent publications >>>> that have either attempted or succeeded in specifying a standard = method? >>>=20 >>> I can't think of any. >>=20 >> "DHCP Relay Agent Assignment Notification Option" = , R. >> Droms, B. Volz, O. Troan >>=20 >> 1. Introduction >>=20 >> The DHCP Relay Agent Assignment Notification option encapsulates >> address and prefix options to indicate that an address or prefix = has >> been assigned. The option may also carry other information = required >> by the network element for configuration related to the assigned >> address or prefix. >>=20 >> For example, a network administrator uses the DHCP Relay Agent >> Assignment Notification option to inform a relay agent of a prefix >> that has been delegated through DHCP PD to a DHCP client. The = relay >> agent notifies the network element on which the it is implemented = of >> the delegation information so the network element can add routing >> information about the delegated prefix into the appropriate routing >> protocols. >>=20 >> The dhc WG discussed the idea and decided not to take on the work due = to some fundamental issues in >> using the option reliably; e.g., ensuring that all DHCPv6 messages = were relayed through the device >> that was actually interested in configuring itself for the delegated = prefix. >=20 > Thanks, I think I remember this now. I now have a use case where it is > possible to ensure that all DHCPv6 messages are relayed through the = same > device. Would it make sense to revive this work and try again? I can't speak for the WG. I recommend you review the discussion of the = previous draft in detail and be sure to address the issues raised = there... >=20 >> The idea was to formalize what is now accomplished through snooping. >=20 > Is this kind of snooping for the purpose of routing system = manipulation > seen in common practice today? Cisco implements snooping. I can't say how widely it is used. - Ralph >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> - Ralph >>=20 >>=20 >>>=20 >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >=20 From Ted.Lemon@nominum.com Tue Feb 4 08:36:42 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1908E1A020A for ; Tue, 4 Feb 2014 08:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4w9GIUhEJs7 for ; Tue, 4 Feb 2014 08:36:37 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id B8F7B1A021F for ; Tue, 4 Feb 2014 08:36:34 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUvEXEvwhFeAYOTJgmrnJwcwYq8TjH250@postini.com; Tue, 04 Feb 2014 08:36:34 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 500B91B82EF for ; Tue, 4 Feb 2014 08:36:34 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 336A2190052; Tue, 4 Feb 2014 08:36:34 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Feb 2014 08:36:34 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <5C539E9F-65CE-4C3F-9711-532AC3556DA6@gmail.com> Date: Tue, 4 Feb 2014 11:36:31 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E1AE1B259@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AE54FDD@xmb-rcd-x04.cisco.com> <5C539E9F-65CE-4C3F-9711-532AC3556DA6@gmail.com> To: Qi Sun X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org" , Bernie Volz Subject: Re: [dhcwg] Call for Agenda Items for IETF-89 (London) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:36:42 -0000 On Feb 4, 2014, at 11:25 AM, Qi Sun wrote: > During the WGLC of draft-ietf-dhcpv4-over-dhcpv6, we received a lot of = comments/suggestions. We've made an update to address the issues raised. = Considering some technical changes are relatively important, we would = like to have a slot to present it in London. I am a bit skeptical that we need to do this. The one change Brian = asked for was a clarification, not a substantive change. We could just = announce it to the working group and give folks a chance to object, and = if they have objections to do so during the IETF last call. Otherwise = we're introducing a lot of unnecessary delay. From simon.perreault@viagenie.ca Tue Feb 4 08:37:27 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AFA1A01A7 for ; Tue, 4 Feb 2014 08:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4f8H9ELNxHkq for ; Tue, 4 Feb 2014 08:37:25 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6F21A0211 for ; Tue, 4 Feb 2014 08:37:15 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 938124037A; Tue, 4 Feb 2014 11:37:14 -0500 (EST) Message-ID: <52F1173A.8070903@viagenie.ca> Date: Tue, 04 Feb 2014 11:37:14 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ted Lemon References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> <52F0FFE6.3050802@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:37:28 -0000 Le 2014-02-04 11:04, Ted Lemon a écrit : > How can it work with SLAAC? I was thinking: The relay snoops the addresses as described in section 7. Then it sends a reconfigure request. But then I wondered: where does the DHCPv6 server send its reconfigure if the client is not already "known" by the server? And then I further wondered: what use is this draft if a client is IPv4-only? The DHCPv6 server would not be able to talk to the client. Me confused. (I really should let the authors speak for themselves.) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ted.Lemon@nominum.com Tue Feb 4 08:39:16 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5396F1A0196 for ; Tue, 4 Feb 2014 08:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRoTT2sd71A0 for ; Tue, 4 Feb 2014 08:39:15 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id D61E01A014C for ; Tue, 4 Feb 2014 08:39:14 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUvEXshypiusBz4zgrdL4sTGMY9GwW3Z0@postini.com; Tue, 04 Feb 2014 08:39:14 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6DB271B82F7 for ; Tue, 4 Feb 2014 08:39:14 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 6662A190052; Tue, 4 Feb 2014 08:39:14 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Feb 2014 08:39:14 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <52F1173A.8070903@viagenie.ca> Date: Tue, 4 Feb 2014 11:39:12 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> <52F0FFE6.3050802@viagenie.ca> <52F1173A.8070903@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:39:16 -0000 On Feb 4, 2014, at 11:37 AM, Simon Perreault = wrote: > And then I further wondered: what use is this draft if a client is > IPv4-only? The DHCPv6 server would not be able to talk to the client. If the client is IPv4-only, the DHCPv4 server might change its behavior, = but the DHCPv6 server would not, because there would be no behavior. = :) From volz@cisco.com Tue Feb 4 08:41:44 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858161A00F9 for ; Tue, 4 Feb 2014 08:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5Dnuw8A5ueZ for ; Tue, 4 Feb 2014 08:41:42 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id EE5BE1A01AE for ; Tue, 4 Feb 2014 08:41:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1118; q=dns/txt; s=iport; t=1391532101; x=1392741701; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vqY0t4WKQ7wX1HRue7X8wbfmbDlDiXhbk8WGM5uM8RU=; b=RVhzN1sYthtxzpJ8Ldl+AT78dvTCmRNnLuinneE9eg6t8S6yKTY2+o96 m5ZIReJ2rxMGUWNwg8B566hPEVto9ECQ9DjZ/yiDK2QapDLUdA+yF4vZu iuL3Na/Q03CFdvTlznJOW0/Oqqm00bc9qTZUWWmdukM4oYwCiGB9fzTVA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoFAHcX8VKtJV2d/2dsb2JhbABZgwyBD74ZgQwWdIIlAQEBBB0dPwwEAgEIEQQBAQEKFAkHIREUCQgBAQQBDQUIh2kDEcRdDYkzF4xggUEjMQcGgx6BFAEDlj+OSoVDgy2CKg X-IronPort-AV: E=Sophos;i="4.95,780,1384300800"; d="scan'208";a="17853401" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 04 Feb 2014 16:41:41 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s14Gffpf019243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Feb 2014 16:41:41 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 10:41:41 -0600 From: "Bernie Volz (volz)" To: Ted Lemon , Qi Sun Thread-Topic: [dhcwg] Call for Agenda Items for IETF-89 (London) Thread-Index: Ac8QicsdauE7TMjdQ2Oym9UwCvtTNwRIY+DgABMl4QAAAGargAAMcGzg Date: Tue, 4 Feb 2014 16:41:40 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE5585A@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1AE1B259@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AE54FDD@xmb-rcd-x04.cisco.com> <5C539E9F-65CE-4C3F-9711-532AC3556DA6@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Call for Agenda Items for IETF-89 (London) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:41:44 -0000 Yes, I'd be more in favor of that as well. While we have few agenda items, = best not to fill them with things that don't really require a higher bandwi= dth discussion. - Bernie -----Original Message----- From: Ted Lemon [mailto:ted.lemon@nominum.com]=20 Sent: Tuesday, February 04, 2014 11:37 AM To: Qi Sun Cc: Bernie Volz (volz); dhcwg@ietf.org Subject: Re: [dhcwg] Call for Agenda Items for IETF-89 (London) On Feb 4, 2014, at 11:25 AM, Qi Sun wrote: > During the WGLC of draft-ietf-dhcpv4-over-dhcpv6, we received a lot of co= mments/suggestions. We've made an update to address the issues raised. Cons= idering some technical changes are relatively important, we would like to h= ave a slot to present it in London. I am a bit skeptical that we need to do this. The one change Brian asked = for was a clarification, not a substantive change. We could just announce= it to the working group and give folks a chance to object, and if they hav= e objections to do so during the IETF last call. Otherwise we're introduc= ing a lot of unnecessary delay. From internet-drafts@ietf.org Tue Feb 4 08:42:08 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942401A0217; Tue, 4 Feb 2014 08:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St0q_wHa3JZL; Tue, 4 Feb 2014 08:42:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B511A0120; Tue, 4 Feb 2014 08:42:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140204164207.13966.42794.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2014 08:42:07 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-unknown-msg-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:42:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Handling Unknown DHCPv6 Messages Authors : Yong Cui Qi Sun Ted Lemon Filename : draft-ietf-dhc-dhcpv6-unknown-msg-05.txt Pages : 6 Date : 2014-02-04 Abstract: DHCPv6 is not specific about handling messages with unknown types. This memo describes the problems and defines how a DHCPv6 server, client or relay agent should behave when receiving unknown DHCPv6 messages. This document also provides advice for authors of future documents defining new messages sent from DHCP servers to DHCP relay agents, and should be read by potential authors of such documents. This document updates RFC3315. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-unknown-msg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-unknown-msg-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-unknown-msg-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From volz@cisco.com Tue Feb 4 08:46:36 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C39D1A0120 for ; Tue, 4 Feb 2014 08:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aTtgbB_IEiR for ; Tue, 4 Feb 2014 08:46:33 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 160C31A00F9 for ; Tue, 4 Feb 2014 08:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5779; q=dns/txt; s=iport; t=1391532393; x=1392741993; h=from:to:subject:date:message-id:mime-version; bh=DqrqrgWEemKmJWS0kbpxD19JqmM+FGiFY1EGoFsSV8k=; b=ifv+Gxlzwt4wxygJKVPhX7ipx9Z5VQF/xjRYV7qsMhH8D0vZYTPeXXXJ 1hAyBIa3/R8MkEeF6ix+cMaFQw0/QBsbQLNlFF3blc+goIfto2gTqWz8O ixK4dwXDXx772Pr2NfHID43QQnvTVhUvAnp2JUjqHvZbi91eayGOuSCyn E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAAYZ8VKtJXHA/2dsb2JhbABZgkhEOFe+GoEMFnSCJwEELV4BKlYmAQQbh30NnS6wZBMEjiEjLYMvgRQEqkyBb4E+gio X-IronPort-AV: E=Sophos;i="4.95,780,1384300800"; d="scan'208,217";a="17851816" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-3.cisco.com with ESMTP; 04 Feb 2014 16:46:32 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s14GkWW5010700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Feb 2014 16:46:32 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 10:46:32 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: London IETF - DHC WG Session - Likely Monday AM, not Thursday as in draft agenda Thread-Index: Ac8hyIpkxZYN0q6iQ1mtBLRMbkwFpA== Date: Tue, 4 Feb 2014 16:46:32 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE558E4@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.97] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AE558E4xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] London IETF - DHC WG Session - Likely Monday AM, not Thursday as in draft agenda X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:46:36 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AE558E4xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI - There is a tentative schedule published at https://datatracker.ietf.o= rg/meeting/89/agenda.html (Updated 2014-02-03 09:00:46 PST). This has the D= HC WG session listed for THURSDAY, March 6, 2014, 0900-1130 GMT. HOWEVER, w= e are likely moving to MONDAY, March 3, 2014, 0900-1130 GMT (swapping with = MIF). So if you are planning your travel, you may want to adjust it appropr= iately. Note that as this is all still preliminary, it is still subject to = change!! - Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1AE558E4xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI – There is a tentative schedule published = at https://datatracker.ietf.org/meeting/89/agenda.html (Updated 2014-02-03= 09:00:46 PST). This has the DHC WG session listed for THURSDAY, March 6, 2= 014, 0900-1130 GMT. HOWEVER, we are likely moving to MONDAY, March 3, 2014,= 0900-1130 GMT (swapping with MIF). So if you are planning your travel, you may want to adjust it appropriatel= y. Note that as this is all still preliminary, it is still subject to chang= e!!

 

-     &= nbsp;    Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E1AE558E4xmbrcdx04ciscoc_-- From alexandru.petrescu@gmail.com Tue Feb 4 08:56:00 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C131A0160 for ; Tue, 4 Feb 2014 08:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ew-Fb0IwQOn for ; Tue, 4 Feb 2014 08:55:57 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 91CCE1A0032 for ; Tue, 4 Feb 2014 08:55:57 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s14Gtqog014486; Tue, 4 Feb 2014 17:55:52 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B05B1202D39; Tue, 4 Feb 2014 17:56:11 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A4AFC2026FA; Tue, 4 Feb 2014 17:56:11 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s14GtpRY012407; Tue, 4 Feb 2014 17:55:52 +0100 Message-ID: <52F11B98.9080506@gmail.com> Date: Tue, 04 Feb 2014 17:55:52 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Templin, Fred L" , "dhcwg@ietf.org" References: <2134F8430051B64F815C691A62D983181C095B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181C0A8C@XCH-BLV-504.nw.nos.boeing.com> <52F0F3B6.4020505@gmail.com> <2134F8430051B64F815C691A62D983181C2885@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181C2885@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Question on relay agent behavior in DHCPv6 prefix delegation X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:56:00 -0000 Le 04/02/2014 17:31, Templin, Fred L a écrit : > Hi Alex, > >> -----Original Message----- From: dhcwg >> [mailto:dhcwg-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Tuesday, February 04, 2014 6:06 AM To: dhcwg@ietf.org >> Subject: Re: [dhcwg] Question on relay agent behavior in DHCPv6 >> prefix delegation >> >> Le 03/02/2014 19:10, Templin, Fred L a écrit : >>> Hi Andre, >>> >>>> -----Original Message----- From: Andre Kostur >>>> [mailto:akostur@incognito.com] Sent: Monday, February 03, 2014 >>>> 9:36 AM To: Templin, Fred L Cc: dhcwg@ietf.org WG Subject: Re: >>>> [dhcwg] Question on relay agent behavior in DHCPv6 prefix >>>> delegation >>>> >>>> The RFC doesn't get into details since it may not even be the >>>> delegating router doing the route updates. As an example, in >>>> a cable network, it may be the CMTS (who plays the role of >>>> Relay Agent from DHCPv6's perspective) who is snooping the PD >>>> traffic and may emit the appropriate routing updates into the >>>> network (using some other standard dynamic routing protocol >>>> such as OSPF). >>> >>> Thanks for this. So, it seems that the RFC3633 DHCPv6 relays (and >>> maybe also servers) can snoop the PD exchanges and update the >>> routing system via some unspecified means. But, are there any >>> more recent publications that have either attempted or succeeded >>> in specifying a standard method? >> >> Solutions (like 'snooping') to the problem have been explored in a >> number of documents at IETF and others. > > I have been down this road before too, and can dig up some of my old > expired drafts if there is interest. I also remember being actively > engaged in the RAAN option discussions a long while back and sort of > lost track of where that all ended up, but thanks to Ralph for his > update on the status. > >> I with co-authors have attempted to formulate it as a problem in >> October 2014, and analyzed some solutions "Route Problem at Relay >> during DHCPv6 Prefix Delegation" >> draft-petrescu-relay-route-pd-problem-00.txt > > That is interesting. Are you planning to continue this work? Well yes. I have spent some time identifying interested parties, and laid down a problem draft. I have presented it to DHC WG, got feeback, and subsequently announced it on the RTGAREA email list. I think that formulating a problem meaningfully may help, some times, designing solutions. A future solution to this problem may be useful beyond DHC WG. Hence my interest. It's rather speculative, but there it is. Alex > > Thanks - Fred fred.l.templin@boeing.com > >> Alex >> >>> >>> Thanks - Fred fred.l.templin@boeing.com >>> >>>> On Mon, Feb 3, 2014 at 8:49 AM, Templin, Fred L >>>> wrote: >>>>> Hi, RFC3633 says: >>>>> >>>>> "14. Relay agent behavior >>>>> >>>>> A relay agent forwards messages containing Prefix Delegation >>>>> options in the same way as described in section 20, "Relay >>>>> Agent Behavior" of RFC 3315. >>>>> >>>>> If a delegating router communicates with a requesting router >>>>> through a relay agent, the delegating router may need a >>>>> protocol or other out-of-band communication to add routing >>>>> information for delegated prefixes into the provider edge >>>>> router." >>>>> >>>>> My question is, since the publication of RFC3633 has there >>>>> been a new RFC published that specifies "a protocol or other >>>>> out-of-band communication to add routing information"? >>>>> >>>>> Thanks - Fred fred.l.templin@boeing.com >>>>> >>>>> _______________________________________________ dhcwg mailing >>>>> list dhcwg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>> >>>> >>>> >>>> -- Andre Kostur >>> _______________________________________________ dhcwg mailing >>> list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>> >>> >> >> >> _______________________________________________ dhcwg mailing list >> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > > From volz@cisco.com Tue Feb 4 09:23:27 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE071A012A for ; Tue, 4 Feb 2014 09:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0cHM8l4BJJc for ; Tue, 4 Feb 2014 09:23:24 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id ABFB61A0130 for ; Tue, 4 Feb 2014 09:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1600; q=dns/txt; s=iport; t=1391534603; x=1392744203; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CiVy48jnBY6Qv58lGqWU9apsj19JS/PfZF0waNRJsZs=; b=O0m5EILpuFw30KDbAoCoOtyy1fUgoyTtu+EZn3H3dDvVuGCEBLQvof+q Uk0N4/G3S+Wmf1SGfjX9BE4en+vx0GpVN/UO75TTI9eaRZ1Q037jZ+LUr teo4t/02r4rM1TPNcQKZo2aDWAZvXQgY8cnbNiwe5vOeWnDIVra5nKf+L I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAI4h8VKtJV2d/2dsb2JhbABZgww4V74agQ0WdIIlAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQgTh2oNzhgTBI4hIzEHBoMegRQBA6pMgy2CKg X-IronPort-AV: E=Sophos;i="4.95,781,1384300800"; d="scan'208";a="301793258" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 04 Feb 2014 17:23:23 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s14HNN1S016859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Feb 2014 17:23:23 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 11:23:23 -0600 From: "Bernie Volz (volz)" To: Ted Lemon , Simon Perreault Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt Thread-Index: AQHPIceo9bzRNIc0t0+9ZDQfaLepUpqlVorA Date: Tue, 4 Feb 2014 17:23:22 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE5596C@xmb-rcd-x04.cisco.com> References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> <52F0FFE6.3050802@viagenie.ca> <52F1173A.8070903@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 17:23:28 -0000 This may be one consequence of trying to make the draft more generic. The original problem was about DNS (DNS64) as I recall from draft-wing-dhc-= dns-reconfigure-02. There were only two significant transitions in the dns-reconfigure draft: I= Pv6-only transition to Dual-Stack and Dual-Stack to IPv6-only. As this option is only for DHCPv6, this is only useful when IPv6 (DHCPv6) i= s present. The question is whether IPv4 is also present on the host or not = as that could influence the DNS information returned. This one may be a good document to add to the Agenda for the London IETF - = to try to resolve exactly what problems this is trying to solve and when, a= nd then to figure out the solution. Hopefully one or more of the authors' w= ill make a request for time at the London IETF. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Tuesday, February 04, 2014 11:39 AM To: Simon Perreault Cc: dhcwg@ietf.org WG Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt On Feb 4, 2014, at 11:37 AM, Simon Perreault = wrote: > And then I further wondered: what use is this draft if a client is=20 > IPv4-only? The DHCPv6 server would not be able to talk to the client. If the client is IPv4-only, the DHCPv4 server might change its behavior, bu= t the DHCPv6 server would not, because there would be no behavior. :) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Tue Feb 4 09:25:19 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA43F1A00F9 for ; Tue, 4 Feb 2014 09:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTU-Mfr7hL1n for ; Tue, 4 Feb 2014 09:25:17 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id BF3C91A0165 for ; Tue, 4 Feb 2014 09:25:17 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUvEifS3Hizf+/28oWFijeJnqm+93YIvE@postini.com; Tue, 04 Feb 2014 09:25:17 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 468061B82F2 for ; Tue, 4 Feb 2014 09:25:17 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 3FEE819005D; Tue, 4 Feb 2014 09:25:17 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Feb 2014 09:25:17 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AE5596C@xmb-rcd-x04.cisco.com> Date: Tue, 4 Feb 2014 12:25:13 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> <52F0FFE6.3050802@viagenie.ca> <52F1173A.8070903@viagenie.ca> <489D13FBFA9B3E41812EA89F188F018E1AE5596C@xmb-rcd-x04.cisco.com> To: Bernie Volz X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 17:25:19 -0000 On Feb 4, 2014, at 12:23 PM, Bernie Volz (volz) wrote: > This one may be a good document to add to the Agenda for the London = IETF - to try to resolve exactly what problems this is trying to solve = and when, and then to figure out the solution. Hopefully one or more of = the authors' will make a request for time at the London IETF. Sounds like a good plan. Thanks! From iesg-secretary@ietf.org Tue Feb 4 09:30:04 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAA31A015C; Tue, 4 Feb 2014 09:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbDJK5kbcgv1; Tue, 4 Feb 2014 09:30:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 528341A0117; Tue, 4 Feb 2014 09:30:03 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140204173003.25981.52523.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2014 09:30:03 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] Last Call: (Handling Unknown DHCPv6 Messages) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 17:30:05 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Handling Unknown DHCPv6 Messages' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-02-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract DHCPv6 is not specific about handling messages with unknown types. This memo describes the problems and defines how a DHCPv6 server, client or relay agent should behave when receiving unknown DHCPv6 messages. This document also provides advice for authors of future documents defining new messages sent from DHCP servers to DHCP relay agents, and should be read by potential authors of such documents. This document updates RFC3315. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-unknown-msg/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-unknown-msg/ballot/ No IPR declarations have been submitted directly on this I-D. From praspati@cisco.com Tue Feb 4 20:07:20 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7551A0029 for ; Tue, 4 Feb 2014 20:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Bkvs_-8O0xw for ; Tue, 4 Feb 2014 20:07:16 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B3D6F1A0028 for ; Tue, 4 Feb 2014 20:07:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1063; q=dns/txt; s=iport; t=1391573235; x=1392782835; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5G4jhX12rPOXUcRIGLWXRrEFmplxR6x+DkQrD3xMxUY=; b=Imu/m1EpcTJTbgc/OcB0WA2/tQn+Ujs/dDBdJ4ayzFCLpAfeb0+x/OGz qtqnOvq0w6IC7zVkPxtQWklC13KyMN64zpR50Z9vLV5K+cGfDBo2wa+Q+ spy5TUwjbDEnY0kRZfGkdJgK4P+zpME5QgdZdr9Ib97LoJBpMTEXTtSH/ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAIq38VKtJV2a/2dsb2JhbABZgww4V75MgQoWdIIlAQEBAwEBAQE3NAsFCwIBCDYQJwslAgQBDQWHfQgNziwTBI51B4Q4AQOYK5Ihgy2CKg X-IronPort-AV: E=Sophos;i="4.95,784,1384300800"; d="scan'208";a="301903079" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 05 Feb 2014 04:07:15 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1547F4N026659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 04:07:15 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.109]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 22:07:14 -0600 From: "Prashanth Patil (praspati)" To: Ted Lemon , Simon Perreault Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt Thread-Index: AQHPIifAqrhBbDVm+UGlCKLrE1Sl9Q== Date: Wed, 5 Feb 2014 04:07:14 +0000 Message-ID: References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.43.160] Content-Type: text/plain; charset="us-ascii" Content-ID: <9B2723C26A24EF46ADBCD7DE4F27201F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 04:07:20 -0000 On 2/4/14 8:16 PM, "Ted Lemon" wrote: >On Feb 4, 2014, at 9:28 AM, Simon Perreault >wrote: >> I'm sorry, I don't understand what you're suggesting. How would the >> link-layer address be of any use? We want to know what kind of IP-layer >> connectivity a client has, and we don't care about the link layer. What >> do you mean by "making allocations"? How is the relay "making >> allocations" in draft conn-status? > >You can use the link-layer address in DHCPv6 to correlate to the >link-layer address in DHCPv4. Sure. The idea was to be able to detect transitions as well i.e. Dual stack to IPv6 only, which the server cannot detect unless informed. Whether this detection is generically useful, needs discussion. -Prashanth > By "make allocations" I mean "do what DHCP does, including assigning >parameters." Sorry for the imprecision. > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Wed Feb 5 04:44:07 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA7F1A0103 for ; Wed, 5 Feb 2014 04:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpWovBtHNChC for ; Wed, 5 Feb 2014 04:44:06 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 951A71A00F2 for ; Wed, 5 Feb 2014 04:44:06 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUvIyFreyFw4RUpTl1w2Nz3RyMaAlx3Gw@postini.com; Wed, 05 Feb 2014 04:44:06 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EF3281B8302 for ; Wed, 5 Feb 2014 04:44:05 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E541A190052; Wed, 5 Feb 2014 04:44:05 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Feb 2014 04:44:05 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Wed, 5 Feb 2014 07:44:01 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <07C71B9E-3D2B-4714-9A5C-67C51B9F028F@nominum.com> References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> To: "Prashanth Patil (praspati)" X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 12:44:07 -0000 On Feb 4, 2014, at 11:07 PM, Prashanth Patil (praspati) = wrote: > Sure. The idea was to be able to detect transitions as well i.e. Dual > stack to IPv6 only, which the server cannot detect unless informed. > Whether this detection is generically useful, needs discussion. Of course the server can detect this. When the DHCPv4 lease expires = without being renewed, either the host is no longer attached to the = network, or it's v6-only. Am I missing something? From praspati@cisco.com Wed Feb 5 05:48:12 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7CD1A0134 for ; Wed, 5 Feb 2014 05:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beYpvSe213GD for ; Wed, 5 Feb 2014 05:48:10 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id CF8671A012D for ; Wed, 5 Feb 2014 05:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=846; q=dns/txt; s=iport; t=1391608090; x=1392817690; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XkMi9M3GMchtVee1T5tw9kB5452mR4da8mdeWCvf0hM=; b=kwfsuOerC7mqEVDRcckonntlK89hynbarUDETERDLgFDV+axYRZmUmf9 olKD9KQYZzG2OMoiARrRFMxzwXfwsCIpOPxlnSQSHjtcThoPb++2d3sW9 jN7pS6NB15lBDPBWbLST5zNhIGfwNkukFB0xTwtH4OI0Q5PMde8H6CFG1 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFANs/8lKtJV2Y/2dsb2JhbABZgww4V75DgQ8WdIIlAQEBBDo/EAIBCBgeEDIlAgQOBYgFDc8sF451B4Q4AQOYK4EykG+DLYIq X-IronPort-AV: E=Sophos;i="4.95,786,1384300800"; d="scan'208";a="302016273" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 05 Feb 2014 13:48:10 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s15Dm9Id028279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 13:48:09 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.109]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 07:48:09 -0600 From: "Prashanth Patil (praspati)" To: Ted Lemon Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt Thread-Index: AQHPIm/88WLbaB69ZEKJQ9CMuC10qZqnbbWA Date: Wed, 5 Feb 2014 13:48:08 +0000 Message-ID: References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> <07C71B9E-3D2B-4714-9A5C-67C51B9F028F@nominum.com> In-Reply-To: <07C71B9E-3D2B-4714-9A5C-67C51B9F028F@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [72.163.206.159] Content-Type: text/plain; charset="us-ascii" Content-ID: <480E50C6E77E0043AAAB5C9B577AA817@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 13:48:12 -0000 On 2/5/14 6:14 PM, "Ted Lemon" wrote: >On Feb 4, 2014, at 11:07 PM, Prashanth Patil (praspati) > wrote: >> Sure. The idea was to be able to detect transitions as well i.e. Dual >> stack to IPv6 only, which the server cannot detect unless informed. >> Whether this detection is generically useful, needs discussion. > >Of course the server can detect this. When the DHCPv4 lease expires >without being renewed, either the host is no longer attached to the >network, or it's v6-only. Am I missing something? I should've been more precise. I meant a relay, using snooping mechanisms (http://tools.ietf.org/html/draft-ietf-dhc-conn-status-00#section-7), detecting that IPv4 is no longer active (even if lease hasn't expired) and signaling this to the server. -Prashanth > From Ted.Lemon@nominum.com Wed Feb 5 05:50:51 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4701A013C for ; Wed, 5 Feb 2014 05:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_O0L6f1Ttma for ; Wed, 5 Feb 2014 05:50:49 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 633391A0139 for ; Wed, 5 Feb 2014 05:50:49 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUvJBuKxuXyunrqzNV0ZOr9olOUKyib6t@postini.com; Wed, 05 Feb 2014 05:50:49 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7CA1C1B82E0 for ; Wed, 5 Feb 2014 05:50:48 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 537D1190052; Wed, 5 Feb 2014 05:50:48 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Feb 2014 05:50:48 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Wed, 5 Feb 2014 08:50:45 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <48ADF973-C96B-415D-BA95-0EE5311114E2@nominum.com> References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> <07C71B9E-3D2B-4714-9A5C-67C51B9F028F@nominum.com> To: "Prashanth Patil (praspati)" X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 13:50:51 -0000 On Feb 5, 2014, at 8:48 AM, Prashanth Patil (praspati) = wrote: > I should've been more precise. I meant a relay, using snooping = mechanisms > (http://tools.ietf.org/html/draft-ietf-dhc-conn-status-00#section-7), > detecting that IPv4 is no longer active (even if lease hasn't expired) = and > signaling this to the server. This seems pretty sketchy. From praspati@cisco.com Wed Feb 5 06:15:07 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCEA1A0153 for ; Wed, 5 Feb 2014 06:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqhajHAp3DV0 for ; Wed, 5 Feb 2014 06:15:05 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2A01A0147 for ; Wed, 5 Feb 2014 06:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=770; q=dns/txt; s=iport; t=1391609705; x=1392819305; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2lR01Bpxf0ZF2M8Mq1MkYWk7/wOVOhTnrKnsaSylNxo=; b=J61WyHDSwel/E/XByA+rqoWnxnyBwTFFhSKdFH+xdnkult5VxgUAblah Woey3Q0fUTxwrOlfCZ1F6uhj8FxKAfus64GB/K2js84fxhFrFppgoZJDD yz2kM1hpknZaaJY/rHUuODWpEzI3rtpDLF/qtRKmxmn7/JuJLxkHlayhN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFADJG8lKtJXG9/2dsb2JhbABZgww4V75DgQ4WdIIlAQEBBDo/EAIBCBgeEDIlAgQOBYgFDc86F451B4Q4AQOYK4EykG+DLYIq X-IronPort-AV: E=Sophos;i="4.95,786,1384300800"; d="scan'208";a="18142759" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-2.cisco.com with ESMTP; 05 Feb 2014 14:15:04 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s15EF43g009762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 14:15:04 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.109]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 08:15:04 -0600 From: "Prashanth Patil (praspati)" To: Ted Lemon Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt Thread-Index: AQHPIm/88WLbaB69ZEKJQ9CMuC10qZqmrb4dgADHe4A= Date: Wed, 5 Feb 2014 14:15:03 +0000 Message-ID: References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> <07C71B9E-3D2B-4714-9A5C-67C51B9F028F@nominum.com> <48ADF973-C96B-415D-BA95-0EE5311114E2@nominum.com> In-Reply-To: <48ADF973-C96B-415D-BA95-0EE5311114E2@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [72.163.206.159] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 14:15:07 -0000 On 2/5/14 7:20 PM, "Ted Lemon" wrote: >On Feb 5, 2014, at 8:48 AM, Prashanth Patil (praspati) > wrote: >> I should've been more precise. I meant a relay, using snooping >>mechanisms >> (http://tools.ietf.org/html/draft-ietf-dhc-conn-status-00#section-7), >> detecting that IPv4 is no longer active (even if lease hasn't expired) >>and >> signaling this to the server. > >This seems pretty sketchy. Yes, I suppose it is. The desire was to better manage configuration sent down to the host, if possible. Especially if I started dual stack, see my IPv6 working great and decide to turn off IPv4. The server could then reconfigure appropriately, maybe with something more v6 efficient. -Prashanth > From Ted.Lemon@nominum.com Wed Feb 5 06:18:50 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84671A015B for ; Wed, 5 Feb 2014 06:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvOFt6lBNPOk for ; Wed, 5 Feb 2014 06:18:49 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 615301A0147 for ; Wed, 5 Feb 2014 06:18:49 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUvJISBy8y28ymGlaKpJoGUbhWwAa30FR@postini.com; Wed, 05 Feb 2014 06:18:49 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AC4021B82E3 for ; Wed, 5 Feb 2014 06:18:48 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id A419D190052; Wed, 5 Feb 2014 06:18:48 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Feb 2014 06:18:48 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Wed, 5 Feb 2014 09:18:46 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> <07C71B9E-3D2B-4714-9A5C-67C51B9F028F@nominum.com> <48ADF973-C96B-415D-BA95-0EE5311114E2@nominum.com> To: "Prashanth Patil (praspati)" X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 14:18:50 -0000 On Feb 5, 2014, at 9:15 AM, Prashanth Patil (praspati) = wrote: > The desire was to better manage configuration sent > down to the host, if possible. Especially if I started dual stack, see = my > IPv6 working great and decide to turn off IPv4. It's unlikely that anybody would ever do that. Most end users don't = know the difference, and those that do are probably wise enough to = realize that if the network configuration is working, changing it is as = likely to cause problems as improvements. More likely the network configuration would change as the result of a = software update. The software update would probably reconfigure the = network anyway, so the problems would come out in the wash. A software = update that disables IPv4 by default when it is available on the network = seems vanishingly unlikely. More likely is that the network will stop providing IPv4, and the host = will become IPv6-only by virtue of that change. Are you seeing operational demand for this functionality? From stenc@s-carlsen.dk Wed Feb 5 07:17:39 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195651A0201 for ; Wed, 5 Feb 2014 07:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.891 X-Spam-Level: X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DK=1.009] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOx_PxeRjHbf for ; Wed, 5 Feb 2014 07:17:37 -0800 (PST) Received: from mail2.s-carlsen.dk (0134100024.1.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1C11A0200 for ; Wed, 5 Feb 2014 07:17:36 -0800 (PST) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 76F0E48DD for ; Wed, 5 Feb 2014 16:17:28 +0100 (CET) Message-ID: <52F25607.8060706@s-carlsen.dk> Date: Wed, 05 Feb 2014 16:17:27 +0100 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> <07C71B9E-3D2B-4714-9A5C-67C51B9F028F@nominum.com> <48ADF973-C96B-415D-BA95-0EE5311114E2@nominum.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 15:17:39 -0000 If you turn off IPv4 on the host, that would mean a restart in most cases. Tha means it would also not do anything on IPv4, no Discovery etc. after some time the lease runs out and nothing more happens. Is anything more needed? I am surely missing some detail here. On 05/02/14 15:18, Ted Lemon wrote: > On Feb 5, 2014, at 9:15 AM, Prashanth Patil (praspati) wrote: >> The desire was to better manage configuration sent >> down to the host, if possible. Especially if I started dual stack, see my >> IPv6 working great and decide to turn off IPv4. > > It's unlikely that anybody would ever do that. Most end users don't know the difference, and those that do are probably wise enough to realize that if the network configuration is working, changing it is as likely to cause problems as improvements. > > More likely the network configuration would change as the result of a software update. The software update would probably reconfigure the network anyway, so the problems would come out in the wash. A software update that disables IPv4 by default when it is available on the network seems vanishingly unlikely. > > More likely is that the network will stop providing IPv4, and the host will become IPv6-only by virtue of that change. > > Are you seeing operational demand for this functionality? > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" From twinters@iol.unh.edu Wed Feb 5 08:13:46 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF301A0172 for ; Wed, 5 Feb 2014 08:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUEj-Wpi8zeY for ; Wed, 5 Feb 2014 08:13:44 -0800 (PST) Received: from exprod5og110.obsmtp.com (exprod5og110.obsmtp.com [64.18.0.20]) by ietfa.amsl.com (Postfix) with SMTP id 4668F1A01F6 for ; Wed, 5 Feb 2014 08:13:43 -0800 (PST) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob110.postini.com ([64.18.4.12]) with SMTP ID DSNKUvJjNqXxdA4OeGQsFSbk8B6ByRP8No/j@postini.com; Wed, 05 Feb 2014 08:13:43 PST Received: from openvpn-client22.iol.unh.edu (openvpn-client22.iol.unh.edu [132.177.124.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id 8A53F8F0078; Wed, 5 Feb 2014 11:13:40 -0500 (EST) Content-Type: multipart/mixed; boundary="Apple-Mail=_29F33B28-599B-42C3-A7FE-A00698907A61" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Timothy Winters In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AE5502E@xmb-rcd-x04.cisco.com> Date: Wed, 5 Feb 2014 11:13:37 -0500 Message-Id: References: <44F7934F-540F-4B41-B37D-08B0C0453D72@iol.unh.edu> <489D13FBFA9B3E41812EA89F188F018E1AE5502E@xmb-rcd-x04.cisco.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.1827) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] DHCPv6 Stateful Issues X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 16:13:46 -0000 --Apple-Mail=_29F33B28-599B-42C3-A7FE-A00698907A61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Bernie, I've enclosed a capture of the behavior. This particular = device did send two separate Release messages. Let me know if you have = other questions. Regards, Tim --Apple-Mail=_29F33B28-599B-42C3-A7FE-A00698907A61 Content-Disposition: attachment; filename=DHCP_Decline_IAPD_Release.pcap Content-Type: application/octet-stream; x-unix-mode=0644; name="DHCP_Decline_IAPD_Release.pcap" Content-Transfer-Encoding: base64 Cg0NCnAAAABNPCsaAQAAAP//////////AwAZAExpbnV4IDMuNC40Mi0yLjI4LWRlc2t0b3AAAAAE ACwARHVtcGNhcCAxLjguNyAoU1ZOIFJldiBVbmtub3duIGZyb20gdW5rbm93bikAAAAAcAAAAAEA AABUAAAAAQAAAP//AAACAAYAY2Vfd2FuAAAJAAEABgAAAAsABAAAaXA2DAAZAExpbnV4IDMuNC40 Mi0yLjI4LWRlc2t0b3AAAAAAAAAAVAAAAAQAAAD0AAAAAgAkACYGQQA4jAAgDcJCv07Fn+1JT0xz LU1hYy1taW5pLmxvY2FsAAIAJAD+gAAAAAAAAD4HVP/+bk8rSU9Mcy1NYWMtbWluaS5sb2NhbAAB ABgAqf5fgElPTHMtTWFjLW1pbmkubG9jYWwAAgAkACYGQQA4jAAgPgdU//5uTytJT0xzLU1hYy1t aW5pLmxvY2FsAAIAJAAmBkEAOIwAILSJu0/ov/+vSU9Mcy1NYWMtbWluaS5sb2NhbAACACQAJgZB ADiMACCFNGpH9qruv0lPTHMtTWFjLW1pbmkubG9jYWwAAAAAAPQAAAAGAAAAxAAAAAAAAABf4wQA +QGBuaMAAACjAAAAMzMAAQAC3EUXsx5Rht1gAAAAAG0RQP6AAAAAAAAA3kUX//6zHlH/AgAAAAAA AAAAAAAAAQACAiICIwBtJD8B+sieAAEADgABAAEAAAAB3kUXsx5fABQAAAADAAwAAAAAAAAAAAAA AAAACAACAAAABgAEABcAGAAZACkAAAAAAAAAAAAAAAAAGgAZAABUYAABUYBAAAAAAAAAAAAAAAAA AAAAAADEAAAABgAAAHgBAAAAAAAAX+MEAHwJgblWAQAAVgEAANxFF7MeUcR9T/vNAYbdbgAAAAEg Ef/+gAAAAAAAAMZ9T//++80B/oAAAAAAAADeRRf//rMeUQIjAiIBIEbiAvrIngABAA4AAQABAAAA Ad5FF7MeXwACAA4AAQABFfz43wBQVrMAwwADACgAAAAAAAAAMgAAAFAABQAYJgZBADiMACANwkK/ TsWf7QAAAGQAAACgABkAKQAAAAAAAAAZAAAAKAAaABkAAAAyAAAAUDgmBkEAOI4HAAAAAAAAAAAA ABQAAAAXABAmBkEAOIwAAQAAAAAAAAACABgADQNpb2wDdW5oA2VkdQAAEQBiAAARiwAgABAmBkEA OIwAAQAAAAAAAAACACEACjNiYXNpYy5jZmcAJQAQJgZBADiMAAEAAAAAAAAAAgAiABAmBkEAOIwA AQAAAAAAAAACACYABP//ubAIegAIAAEABAAAAAAAYwAEAAAAPAAAeAEAAAYAAAD0AAAAAAAAAF/j BAAyUJC50QAAANEAAAAzMwABAALcRRezHlGG3WAAAAAAmxFA/oAAAAAAAADeRRf//rMeUf8CAAAA AAAAAAAAAAABAAICIgIjAJtutQMVTpIAAQAOAAEAAQAAAAHeRRezHl8AAgAOAAEAARX8+N8AUFaz AMMAFAAAAAMAKAAAAAAAAAAAAAAAAAAFABgmBkEAOIwAIA3CQr9OxZ/tAAAAZAAAAKAACAACAAAA BgAEABcAGAAZACkAAAAAAAAAAAAAAAAAGgAZAAAAMgAAAFA4JgZBADiOBwAAAAAAAAAAAAAAAPQA AAAGAAAAmAEAAAAAAABf4wQAULCQuXYBAAB2AQAA3EUXsx5RxH1P+80Bht1uAAAAAUAR//6AAAAA AAAAxn1P//77zQH+gAAAAAAAAN5FF//+sx5RAiMCIgFAdEgHFU6SAAEADgABAAEAAAAB3kUXsx5f AAIADgABAAEV/PjfAFBWswDDAAMAKAAAAAAAAAAyAAAAUAAFABgmBkEAOIwAIA3CQr9OxZ/tAAAA ZAAAAKAAGQApAAAAAAAAABkAAAAoABoAGQAAADIAAABQOCYGQQA4jgcAAAAAAAAAAAAAFAAAAAsA HAMBABmBgU8AAEXnAdo+zmK6+G2gxd3uWVrjr+gAFwAQJgZBADiMAAEAAAAAAAAAAgAYAA0DaW9s A3VuaANlZHUAABEAYgAAEYsAIAAQJgZBADiMAAEAAAAAAAAAAgAhAAozYmFzaWMuY2ZnACUAECYG QQA4jAABAAAAAAAAAAIAIgAQJgZBADiMAAEAAAAAAAAAAgAmAAT//7mwCHoACAABAAQAAAAAAGMA BAAAADwAAJgBAAAGAAAAuAAAAAAAAABf4wQAYeiguZgAAACYAAAAMzMAAQAC3EUXsx5Rht1gAAAA AGIRQP6AAAAAAAAA3kUX//6zHlH/AgAAAAAAAAAAAAAAAQACAiICIwBi1QIJFLAgAAEADgABAAEA AAAB3kUXsx5fAAIADgABAAEV/PjfAFBWswDDAAMAKAAAAAAAAAAyAAAAUAAFABgmBkEAOIwAIA3C Qr9OxZ/tAAAAZAAAAKAACAACAAC4AAAABgAAAKAAAAAAAAAAX+MEAGYrobl/AAAAfwAAANxFF7Me UcR9T/vNAYbdbgAAAABJEf/+gAAAAAAAAMZ9T//++80B/oAAAAAAAADeRRf//rMeUQIjAiIASTn6 BxSwIAABAA4AAQABAAAAAd5FF7MeXwACAA4AAQABFfz43wBQVrMAwwANABUAADEgbGVhc2Uocykg ZGVjbGluZWQAoAAAAAYAAAC8AAAAAAAAAF/jBAD+MqG5mQAAAJkAAAAzMwABAALcRRezHlGG3WAA AAAAYxFA/oAAAAAAAADeRRf//rMeUf8CAAAAAAAAAAAAAAABAAICIgIjAGOl8wgo8u8AAQAOAAEA AQAAAAHeRRezHl8AAgAOAAEAARX8+N8AUFazAMMACAACAAAAGQApAAAAAAAAABkAAAAoABoAGQAA ADIAAABQOCYGQQA4jgcAAAAAAAAAAAAAAAC8AAAABgAAAKAAAAAAAAAAX+MEAFIKorl/AAAAfwAA ANxFF7MeUcR9T/vNAYbdbgAAAABJEf/+gAAAAAAAAMZ9T//++80B/oAAAAAAAADeRRf//rMeUQIj AiIASfkHByjy7wABAA4AAQABAAAAAd5FF7MeXwACAA4AAQABFfz43wBQVrMAwwANABUAADEgbGVh c2UocykgcmVsZWFzZWQAoAAAAAUAAABsAAAAAAAAAF/jBABXIdi5AQAcAENvdW50ZXJzIHByb3Zp ZGVkIGJ5IGR1bXBjYXACAAgAX+MEAAAM+bEDAAgAX+MEAK8f2LkEAAgAoAAAAAAAAAAFAAgAAAAA AAAAAAAAAAAAbAAAAA== --Apple-Mail=_29F33B28-599B-42C3-A7FE-A00698907A61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 4, 2014, at 8:25 AM, Bernie Volz (volz) wrote: > Hi Tim: >=20 > I too would have expected just the IA_NA (IAADDR) to be declined. You = don't mention what the clients are doing in this case (sending a Decline = with both the IA_NA and IA_PD or sending a Release with both - or = sending a Decline for the IA_NA and Release for the IA_PD)? >=20 > A DAD conflict should result in a Decline. So, it would seem to me = that the added step of sending a Release for the IA_PD (IAPREFIX) is = extra effort and not necessary/warranted. And I would hope these clients = aren't sending a Decline for the IA_PD (IAPREFIX). >=20 > Also, did the routers doing the IA_PD Release earlier request the = IA_NA and IA_PD in the same packet (transaction) or different ones? >=20 > Be nice if you had a packet trace available to see what the = interaction here is? >=20 > This does sound like a candidate for discussion in the draft, but we = need a bit more information before considering to add it. >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Timothy = Winters > Sent: Monday, February 03, 2014 12:07 PM > To: dhcwg@ietf.org WG > Subject: [dhcwg] DHCPv6 Stateful Issues >=20 > Hi Bernie, > While testing some IPv6 CE Router I've noticed an issue that = this draft might want to address. When a DHCP Client receives both the = IA_NA and IA_PD in the reply, the Client performs DAD on the IA_NA. If = DAD fails some implementations keep the IA_PD and try for a different = IA_NA. Other IPv6 CE Routers will Release the IA_PD in this scenario. =20= >=20 > I would think the proper thing to do would be to keep the IA_PD = so your LAN as addressing. Is something that we can talk about in this = document? >=20 > ~Tim >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail=_29F33B28-599B-42C3-A7FE-A00698907A61-- From Ted.Lemon@nominum.com Wed Feb 5 12:46:43 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF42D1A020E for ; Wed, 5 Feb 2014 12:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AOngCi-fPKe for ; Wed, 5 Feb 2014 12:46:41 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1EED91A0211 for ; Wed, 5 Feb 2014 12:46:39 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUvKjLnmy63wgzSHH/+T6II4zjvkZHyBc@postini.com; Wed, 05 Feb 2014 12:46:38 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5BA651B82E1 for ; Wed, 5 Feb 2014 12:46:38 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 54B27190052; Wed, 5 Feb 2014 12:46:38 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Feb 2014 12:46:38 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <52F25607.8060706@s-carlsen.dk> Date: Wed, 5 Feb 2014 13:39:18 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <1C267188-BEF2-47C5-9347-D50132FF6D73@nominum.com> References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> <07C71B9E-3D2B-4714-9A5C-67C51B9F028F@nominum.com> <48ADF973-C96B-415D-BA95-0EE5311114E2@nominum.com> <52F25607.8060706@s-carlsen.dk> To: Sten Carlsen X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 20:46:44 -0000 On Feb 5, 2014, at 10:17 AM, Sten Carlsen wrote: > Is anything more needed? I am surely missing some detail here. The theory is that the relay agent will be able to inform the DHCPv6 = server that this has happened. I'm just having trouble imagining when = this will happen, or why it's worth putting into a router's firmware. From tomasz.mrugalski@gmail.com Wed Feb 5 13:36:04 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A5E1A022E for ; Wed, 5 Feb 2014 13:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y6pkdKtjUnX for ; Wed, 5 Feb 2014 13:36:02 -0800 (PST) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6085E1A022C for ; Wed, 5 Feb 2014 13:36:02 -0800 (PST) Received: by mail-ea0-f179.google.com with SMTP id q10so429018ead.24 for ; Wed, 05 Feb 2014 13:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qP2kPncJUA+pYvk+KnIL+SIiQG8HEtfKIQsg/SGY0RA=; b=OBtAU6/Z/qH+xxJOKIKgfUDdn4oRWpQ5TRWcv0Uxbs4A7EYjAyo3LN7xy4bl/CqvHf owB49/i4auvhJHCibMiBaZbURwNEmCbE+juWPP5ld+NlMevVEwT4/tv4pqCGyvlN+Mr0 xvx70NzQo0ptDPKLuqNPwwmY7pGLBZMaIzD/GVZ+8Eu9g3tQJDyojasgrFG4FNBvTikp i/08sciG8MtdnY7l5jPsMIo5Beio5ABq1MtbtjI8S+Plo3nYUvAb+lXeSSAuLUMt3S43 wFR3AAM0gGRAwyAERdE6aDli+47YLvmNvtr8i2ndJk8VlQyMp3UUinAvfVvSYZI0TqqW PQ7Q== X-Received: by 10.14.173.68 with SMTP id u44mr1968421eel.102.1391636126202; Wed, 05 Feb 2014 13:35:26 -0800 (PST) Received: from thomson-osx.local (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id m9sm92902710eeh.3.2014.02.05.13.35.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Feb 2014 13:35:25 -0800 (PST) Message-ID: <52F2AE9C.2020805@gmail.com> Date: Wed, 05 Feb 2014 22:35:24 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: DHC WG References: <52D87808.8040107@gmail.com> <52D9A59D.4080100@gmail.com> In-Reply-To: <52D9A59D.4080100@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-v4configuration-04 - respond by Jan. 31 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 21:36:04 -0000 On 17.01.2014, 22:50, Tomek Mrugalski wrote: > Authors and chairs feel that draft-ietf-dhc-v4configuration-04 > (http://datatracker.ietf.org/doc/draft-ietf-dhc-v4configuration/) is > ready for WGLC. Please post your comment by end of January. I support moving forward with this document, but the comments raised during this WGLC should be addressed. I have a handful of mostly editorial comments: Section 1.2 'Host Client Relay' is abbreviated as HCRA. Either use HCR or 'Host Client Relay Agent'. "UDPv6 and IPv6" => "UDP and IPv6". "This interface may be directly on the server...". There's a verb missing somewhere here (implemented? provided? exposed?) Section 1.5. The (unfortunately) message names have changed. They are no longer called BOOTREQUESTV6 and BOOTREPLYV6. (That may have given an absurd idea to some people to run BOOTP in IPv6 only networks. Yikes!). The new names are DHCPV4-QUERY and DHCPV4-RESPONSE. The same is true for the OPTION_BOOTP_MSG => OPTION_DHCPV4_MSG. That applies to the whole text. Typo in the last line of the third paragraph (BOOTPRPLYV6), but it doesn't matter as the name will be replaced with DHCPV4-RESPONSE. Section 1.3 says that it is not known which or how many DHCPv4 options would have to be reimplemented in DHCPv6. Yet section 3.2.1 mentions that implementations exist. Are you sure that's not a copy paste error? Are there implementations that reimplemented DHCPv4 options one by one as DHCPv6 options? Is section 3.4 still necessary? That's essentially native DHCPv4 that is described in section 5, right? Section 7.4: reference to section 10 of RFC3315 seems wrong. Section 10 is a nice section, but it explains basic IA concepts and there's nothing about security there. Perhaps you meant section 11 of draft-ietf-dhc-dhcpv4-over-dhcpv6? Tomek p.s. Sorry for the delay with wrapping up this WGLC. Will get to it soon. From volz@cisco.com Wed Feb 5 14:15:00 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BA91A022E for ; Wed, 5 Feb 2014 14:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo9aOVi5nXAM for ; Wed, 5 Feb 2014 14:14:58 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 225911A0209 for ; Wed, 5 Feb 2014 14:14:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1273; q=dns/txt; s=iport; t=1391638497; x=1392848097; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jFVe7+HzviBTQhsI5IximjJJomLehCdUi3SMpUZpZTw=; b=CvJ+EskIYiLqQSMO8lWFhQHgX/eUQ9z2GCavabGaGOFbHrUCCGjgSkFv wYBh6fwhd5Wz+idN9G0Dxxarf1Rf8bI8qoxJyajAltWiWxl2H8PF5twTA JGOkk0tzHTuXUnibE0aZ2y97pRzYyhggr0t+lHvgXi9eFwoa2kxRGWHWS o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAAm38lKtJXG8/2dsb2JhbABZgww4V75bgREWdIIlAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQgTh2oNzmQTBI5EMQcGgx6BFAEDqkyDLYIq X-IronPort-AV: E=Sophos;i="4.95,789,1384300800"; d="scan'208";a="18299360" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-5.cisco.com with ESMTP; 05 Feb 2014 22:14:56 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s15MEupL010889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 22:14:56 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 16:14:56 -0600 From: "Bernie Volz (volz)" To: Ted Lemon , Sten Carlsen Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt Thread-Index: AQHPIqGT9bzRNIc0t0+9ZDQfaLepUpqnNbHA Date: Wed, 5 Feb 2014 22:14:55 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE594E4@xmb-rcd-x04.cisco.com> References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> <07C71B9E-3D2B-4714-9A5C-67C51B9F028F@nominum.com> <48ADF973-C96B-415D-BA95-0EE5311114E2@nominum.com> <52F25607.8060706@s-carlsen.dk> <1C267188-BEF2-47C5-9347-D50132FF6D73@nominum.com> In-Reply-To: <1C267188-BEF2-47C5-9347-D50132FF6D73@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 22:15:00 -0000 Yeah, I was kind of skeptical about this too ... but (at least some) coauth= ors are from a router vendor, so they obviously believe this is worth doing= (or getting someone within their organization to do). And, that issue was = asked at the Vancouver IETF: Ted: the draft creates a problem: dual stack should always connect to IPv6 only Ted: asked if on charter? Ted: what router vendors plan to implement (Cisco as authors are from there) Simon Perreault: likes the solution - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Wednesday, February 05, 2014 1:39 PM To: Sten Carlsen Cc: dhcwg@ietf.org WG Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt On Feb 5, 2014, at 10:17 AM, Sten Carlsen wrote: > Is anything more needed? I am surely missing some detail here. The theory is that the relay agent will be able to inform the DHCPv6 server= that this has happened. I'm just having trouble imagining when this will= happen, or why it's worth putting into a router's firmware. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Wed Feb 5 15:31:40 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C344C1A0258 for ; Wed, 5 Feb 2014 15:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lkwu0n8JMWda for ; Wed, 5 Feb 2014 15:31:39 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id E4C3B1A0224 for ; Wed, 5 Feb 2014 15:31:38 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUvLJ2pyK4WtBvRF2+6drYJ7FO0wb0Btb@postini.com; Wed, 05 Feb 2014 15:31:38 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2776C1B82F2 for ; Wed, 5 Feb 2014 15:31:38 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 202FD190052; Wed, 5 Feb 2014 15:31:38 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Feb 2014 15:31:37 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AE594E4@xmb-rcd-x04.cisco.com> Date: Wed, 5 Feb 2014 18:31:35 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <50C073ED-1B32-45FE-947E-BAA451353D4D@nominum.com> References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> <07C71B9E-3D2B-4714-9A5C-67C51B9F028F@nominum.com> <48ADF973-C96B-415D-BA95-0EE5311114E2@nominum.com> <52F25607.8060706@s-carlsen.dk> <1C267188-BEF2-47C5-9347-D50132FF6D73@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1AE594E4@xmb-rcd-x04.cisco.com> To: Bernie Volz X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:31:41 -0000 On Feb 5, 2014, at 5:14 PM, Bernie Volz (volz) wrote: > Yeah, I was kind of skeptical about this too ... but (at least some) = coauthors are from a router vendor, so they obviously believe this is = worth doing (or getting someone within their organization to do). And, = that issue was asked at the Vancouver IETF: The fact that someone who works for Cisco thinks Cisco might implement = this isn't an indication that Cisco will implement it. Maybe they = will, maybe they won't. That's why I was asking if there was demand = for this solution. I realize that this has been adopted by the working group, and that we = talked about whether it fits with the charter, but if I agreed that it = fit, I don't know what I was smoking. What's interesting about this = work is its operational aspect. So the motivation for doing this = should be coming from an ops working group, not the DHC working group. Did this in fact come about as the result of some consensus from v6ops = that this work was needed? From volz@cisco.com Wed Feb 5 16:12:23 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5EF1A0290 for ; Wed, 5 Feb 2014 16:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5sBuVaOymQf for ; Wed, 5 Feb 2014 16:12:21 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA6B1A0284 for ; Wed, 5 Feb 2014 16:12:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1661; q=dns/txt; s=iport; t=1391645541; x=1392855141; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ml/xE8qDhv1Ux7xfH+n8OOa8LsU9lrkU8KqQVy623Tg=; b=SZw4LSbxo6Qnkidkrs+5tdVy2v8L3UsTP8P9dNhwNX4B0pvC2zAHcmmS /A2LR9HQ2IAIyd6fHVsHDZQ/49vD5c38a2IPvjUoYGkogV+dDmIhfRja1 ZEZdIRadypErDAXwM2Hk1cfxykklbyvb7mtBJ1lBFJ1cOd2YfJgje41pM Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJLS8lKtJXG+/2dsb2JhbABZgwyBD75egQoWdIIlAQEBAwEdHT8FBwQCAQgRBAEBAQoUCQcyFAkIAgQOBQgTh2IIznAXjkQxBwaDHoEUAQOqTIMtgio X-IronPort-AV: E=Sophos;i="4.95,789,1384300800"; d="scan'208";a="302140162" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 06 Feb 2014 00:12:20 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s160CKQ8011660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 00:12:20 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 18:12:19 -0600 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt Thread-Index: AQHPIqGT9bzRNIc0t0+9ZDQfaLepUpqnNbHAgAB+coD//6Wu8A== Date: Thu, 6 Feb 2014 00:12:19 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE598AB@xmb-rcd-x04.cisco.com> References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> <07C71B9E-3D2B-4714-9A5C-67C51B9F028F@nominum.com> <48ADF973-C96B-415D-BA95-0EE5311114E2@nominum.com> <52F25607.8060706@s-carlsen.dk> <1C267188-BEF2-47C5-9347-D50132FF6D73@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1AE594E4@xmb-rcd-x04.cisco.com> <50C073ED-1B32-45FE-947E-BAA451353D4D@nominum.com> In-Reply-To: <50C073ED-1B32-45FE-947E-BAA451353D4D@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 00:12:23 -0000 > Did this in fact come about as the result of some consensus from v6ops th= at this work was needed? Not to my knowledge. If you won't allow it on the Charter, we will have to drop it. (That might = even be the outcome if it does go on the charter.) From the call for adopti= on, there was support for this work and no one against it. - Bernie -----Original Message----- From: Ted Lemon [mailto:ted.lemon@nominum.com]=20 Sent: Wednesday, February 05, 2014 6:32 PM To: Bernie Volz (volz) Cc: Sten Carlsen; dhcwg@ietf.org WG Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt On Feb 5, 2014, at 5:14 PM, Bernie Volz (volz) wrote: > Yeah, I was kind of skeptical about this too ... but (at least some) coau= thors are from a router vendor, so they obviously believe this is worth doi= ng (or getting someone within their organization to do). And, that issue wa= s asked at the Vancouver IETF: The fact that someone who works for Cisco thinks Cisco might implement this= isn't an indication that Cisco will implement it. Maybe they will, maybe= they won't. That's why I was asking if there was demand for this solutio= n. I realize that this has been adopted by the working group, and that we talk= ed about whether it fits with the charter, but if I agreed that it fit, I d= on't know what I was smoking. What's interesting about this work is its o= perational aspect. So the motivation for doing this should be coming from= an ops working group, not the DHC working group. Did this in fact come about as the result of some consensus from v6ops that= this work was needed? From Ted.Lemon@nominum.com Wed Feb 5 17:05:44 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477041A016D for ; Wed, 5 Feb 2014 17:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBQWM7P2-QD7 for ; Wed, 5 Feb 2014 17:05:43 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED021A011B for ; Wed, 5 Feb 2014 17:05:43 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUvLf5vtqbChLM87zjrnObuPkOWSjdK20@postini.com; Wed, 05 Feb 2014 17:05:42 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 644E61B82EF for ; Wed, 5 Feb 2014 17:05:42 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 3A77C190052; Wed, 5 Feb 2014 17:05:42 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Feb 2014 17:05:42 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AE598AB@xmb-rcd-x04.cisco.com> Date: Wed, 5 Feb 2014 20:05:39 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140204093611.4914.51694.idtracker@ietfa.amsl.com> <52F0F3C2.20807@viagenie.ca> <4B094E1A-431F-4F2B-9004-37D6D12BE8F8@nominum.com> <52F0F8F4.4060905@viagenie.ca> <07C71B9E-3D2B-4714-9A5C-67C51B9F028F@nominum.com> <48ADF973-C96B-415D-BA95-0EE5311114E2@nominum.com> <52F25607.8060706@s-carlsen.dk> <1C267188-BEF2-47C5-9347-D50132FF6D73@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1AE594E4@xmb-rcd-x04.cisco.com> <50C073ED-1B32-45FE-947E-BAA451353D4D@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1AE598AB@xmb-rcd-x04.cisco.com> To: Bernie Volz X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 01:05:44 -0000 On Feb 5, 2014, at 7:12 PM, Bernie Volz (volz) wrote: > If you won't allow it on the Charter, we will have to drop it. (That = might even be the outcome if it does go on the charter.) =46rom the call = for adoption, there was support for this work and no one against it. It's not covered by the current charter. We could charter DHC to do = the work, but is the working group enthusiastic enough about it to go to = that trouble? I'm sorry for being a sticky wicket after you've already = adopted, but I think you need to get some working group who is competent = to evaluate the proposal to look at it before DHC does any serious work = on it. From volz@cisco.com Thu Feb 6 13:23:44 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A161A0133 for ; Thu, 6 Feb 2014 13:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xN3ZbmGeEq_G for ; Thu, 6 Feb 2014 13:23:41 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 588D01A017A for ; Thu, 6 Feb 2014 13:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12886; q=dns/txt; s=iport; t=1391721820; x=1392931420; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=E4RYiFWB7vpXqBErupTgUOpWmDHcHjbnpdy/shmIOxs=; b=NDArDsCoqHOPjCp9feDxqNmlV2jcDbLbd3s21phv4X81dlm1akTOh8OG CqgHjoKFedweeFFDexQ7yK1K9kgOM8mA1tUyknn3KpUHwqr38da59cj0A 3+oSt80aaw84oa0ahEhtBfSosmuyfvqqLBkFOHqawVDNb8JbNnPEaDWJC A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAID881KtJXG8/2dsb2JhbABZDoI6RDhXvnSBDhZ0giUBAQEDAQEBASpBCwUHBAIBCA4DBAEBCx0HJwsUCQgCBA4FCId1CA3NAhMEjkkmBwQGAQaDHoEUBKpMgm4/gio X-IronPort-AV: E=Sophos;i="4.95,795,1384300800"; d="scan'208,217,223";a="302425992" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 06 Feb 2014 21:23:39 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s16LNdpR014050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 21:23:39 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 15:23:39 -0600 From: "Bernie Volz (volz)" To: Timothy Winters Thread-Topic: [dhcwg] DHCPv6 Stateful Issues Thread-Index: AQHPIQJmiQAo8HL4V0q/V8TsAiMQoJqlFU9AgAIntICAAAX6YA== Date: Thu, 6 Feb 2014 21:23:39 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE5BE93@xmb-rcd-x04.cisco.com> References: <44F7934F-540F-4B41-B37D-08B0C0453D72@iol.unh.edu> <489D13FBFA9B3E41812EA89F188F018E1AE5502E@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.35] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AE5BE93xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] DHCPv6 Stateful Issues X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 21:23:44 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AE5BE93xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >From the packet capture it sends a Decline for the address and a Release fo= r the prefix. While I would consider this acceptable, the Release isn't op= timum (and likely creates unnecessary overhead for both client and server).= I would expect the client will Solicit and will get (another different) ad= dress and possibly the same or a different prefix. Would likely have been b= etter for client to keep the prefix ... it can go back to Solicit asking fo= r both, as prefix will be given to client again or based on the Stateful Is= sues, do a Request - but that is not presently allowed per RFC 3315. - Bernie From: Timothy Winters [mailto:twinters@iol.unh.edu] Sent: Wednesday, February 05, 2014 11:14 AM To: Bernie Volz (volz) Cc: dhcwg@ietf.org WG Subject: Re: [dhcwg] DHCPv6 Stateful Issues Hi Bernie, I've enclosed a capture of the behavior. This particular device d= id send two separate Release messages. Let me know if you have other quest= ions. Regards, Tim On Feb 4, 2014, at 8:25 AM, Bernie Volz (volz) > wrote: > Hi Tim: > > I too would have expected just the IA_NA (IAADDR) to be declined. You don= 't mention what the clients are doing in this case (sending a Decline with = both the IA_NA and IA_PD or sending a Release with both - or sending a Decl= ine for the IA_NA and Release for the IA_PD)? > > A DAD conflict should result in a Decline. So, it would seem to me that t= he added step of sending a Release for the IA_PD (IAPREFIX) is extra effort= and not necessary/warranted. And I would hope these clients aren't sending= a Decline for the IA_PD (IAPREFIX). > > Also, did the routers doing the IA_PD Release earlier request the IA_NA a= nd IA_PD in the same packet (transaction) or different ones? > > Be nice if you had a packet trace available to see what the interaction h= ere is? > > This does sound like a candidate for discussion in the draft, but we need= a bit more information before considering to add it. > > - Bernie > > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Timothy Winters > Sent: Monday, February 03, 2014 12:07 PM > To: dhcwg@ietf.org WG > Subject: [dhcwg] DHCPv6 Stateful Issues > > Hi Bernie, > While testing some IPv6 CE Router I've noticed an issue that this = draft might want to address. When a DHCP Client receives both the IA_NA an= d IA_PD in the reply, the Client performs DAD on the IA_NA. If DAD fails = some implementations keep the IA_PD and try for a different IA_NA. Other = IPv6 CE Routers will Release the IA_PD in this scenario. > > I would think the proper thing to do would be to keep the IA_PD s= o your LAN as addressing. Is something that we can talk about in this doc= ument? > > ~Tim > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --_000_489D13FBFA9B3E41812EA89F188F018E1AE5BE93xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From the packet capture i= t sends a Decline for the address and a Release for the prefix. While I wou= ld consider this acceptable, the Release  isn’t optimum (and likely creates unnecessary overhead for both client and server). I wo= uld expect the client will Solicit and will get (another different) address= and possibly the same or a different prefix. Would likely have been better= for client to keep the prefix … it can go back to Solicit asking for both, as prefix will be given to clie= nt again or based on the Stateful Issues, do a Request – but that is = not presently allowed per RFC 3315.

 <= /p>

- =          Bernie=

 <= /p>

From: Timothy = Winters [mailto:twinters@iol.unh.edu]
Sent: Wednesday, February 05, 2014 11:14 AM
To: Bernie Volz (volz)
Cc: dhcwg@ietf.org WG
Subject: Re: [dhcwg] DHCPv6 Stateful Issues

 

Hi Bernie,
        I've enclosed a capture of the b= ehavior.   This particular device did send two separate Release m= essages.  Let me know if you have other questions.

Regards,
Tim



On Feb 4, 2014, at 8:25 AM, Bernie Volz (volz) <volz@cisco.com> wrote:

> Hi Tim:
>
> I too would have expected just the IA_NA (IAADDR) to be declined. You = don't mention what the clients are doing in this case (sending a Decline wi= th both the IA_NA and IA_PD or sending a Release with both - or sending a D= ecline for the IA_NA and Release for the IA_PD)?
>
> A DAD conflict should result in a Decline. So, it would seem to me tha= t the added step of sending a Release for the IA_PD (IAPREFIX) is extra eff= ort and not necessary/warranted. And I would hope these clients aren't send= ing a Decline for the IA_PD (IAPREFIX).
>
> Also, did the routers doing the IA_PD Release earlier request the IA_N= A and IA_PD in the same packet (transaction) or different ones?
>
> Be nice if you had a packet trace available to see what the interactio= n here is?
>
> This does sound like a candidate for discussion in the draft, but we n= eed a bit more information before considering to add it.
>
> - Bernie
>
> -----Original Message-----
> From: dhcwg [mailto:dhcwg-bo= unces@ietf.org] On Behalf Of Timothy Winters
> Sent: Monday, February 03, 2014 12:07 PM
> To: dhcwg@ietf.org WG
> Subject: [dhcwg] DHCPv6 Stateful Issues
>
> Hi Bernie,
>        While testing some IPv6 CE R= outer I've noticed an issue that this draft might want to address.  Wh= en a DHCP Client receives both the IA_NA and IA_PD in the reply, the Client= performs DAD on the IA_NA.   If DAD fails some implementations k= eep the IA_PD and try for a different IA_NA.   Other IPv6 CE Routers will Rele= ase the IA_PD in this scenario. 
>
>         I would think the prop= er thing to do would be to keep the IA_PD so your LAN as addressing. &= nbsp; Is something that we can talk about in this document?
>
> ~Tim
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ie= tf.org/mailman/listinfo/dhcwg

--_000_489D13FBFA9B3E41812EA89F188F018E1AE5BE93xmbrcdx04ciscoc_-- From tomasz.mrugalski@gmail.com Sun Feb 9 12:43:51 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B521A05D3 for ; Sun, 9 Feb 2014 12:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VB7eAOy_VIGl for ; Sun, 9 Feb 2014 12:43:50 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D55571A0591 for ; Sun, 9 Feb 2014 12:43:49 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u56so3721969wes.30 for ; Sun, 09 Feb 2014 12:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=vvtK6a/N0o/GYM9H3YaaBtzdWKldYlORLblXC2uOn4o=; b=R8GKlz3hfXdtvMUFHnC3DKaG5yeC1cuPXJXfJl5roTaz8WOj5O1uwOJ1vksjyJDP4X 2lr0CmKriTv4XGHRiGHsClphz6PczcPffvHcMQ9gvDmCKnNaio6KHAy7epeL//PZb9To +/4xpsm4TQRLA1Bsp+2FuHVy5ASqbYaJyC9Tnvwp1wGdTfiQ2GKgiDSIYdqB2Nn4axjP SiULOyHTAsghQZmVZo+nzlOtttanzD6ke1fol6+mCDIDypbK4hnSr5BkJGUODaKT+q9x +1rTwUcjreDnnRoFUmApsADPQKdE6mwB02FRRrSLk7vFvUDry3MkFA+o4VZCrdwjWXGj 480g== X-Received: by 10.194.22.129 with SMTP id d1mr19367590wjf.22.1391978629565; Sun, 09 Feb 2014 12:43:49 -0800 (PST) Received: from thomson-osx.local (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id 12sm29383002wjm.10.2014.02.09.12.43.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Feb 2014 12:43:48 -0800 (PST) Message-ID: <52F7E87F.1020503@gmail.com> Date: Sun, 09 Feb 2014 21:43:43 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: DHC WG References: <52D87808.8040107@gmail.com> <52D9A59D.4080100@gmail.com> <52F2AE9C.2020805@gmail.com> In-Reply-To: <52F2AE9C.2020805@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-v4configuration-04 - respond by Jan. 31 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 20:43:51 -0000 On 05.02.2014, 22:35, Tomek Mrugalski wrote: > I have a handful of mostly editorial comments: I forgot about one procedural comment. Please remove requirements language ("The key words "MUST", "MUST NOT"...) and reference to RFC2119. The normative language is appropriate only for standards track documents. It is ok to have only informative references. Tomek From tomasz.mrugalski@gmail.com Tue Feb 11 11:17:37 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C90C1A06E1 for ; Tue, 11 Feb 2014 11:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcfnEfhDtqeN for ; Tue, 11 Feb 2014 11:17:35 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 129A21A06E4 for ; Tue, 11 Feb 2014 11:17:34 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hm4so5114397wib.7 for ; Tue, 11 Feb 2014 11:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=LHvy8xc+XS7lehdfuLmF8W7hFr/YSdzYnydrTOYrxio=; b=AfOKotBA8aZ1iotBvm7YwHCsMYzklxhgLfo6IyKod2OowoQ1gZRTQaXLhh33dHkZ88 BNQRVfMb63f+tdSDr990Al54Jc3e057dT44Ul//3B9sDa/1zXAVLlstd2t5eL3MxqAIw C3GMTVJ0VcQROX9DRyTlU3a6bh1AYGxdDHpGlygYqSqrCEMrWt+g0scFmNVCI7Fx6dOM XRIzahULCY6952IBZe2yX1A9jMwy2lFtF7btQ1C6harV4RMHvj6FSq1NLLDzPYbahf9H RqTMA5CwG2gzHy2aAhAap2x9fxVsEsWZNdn8TikaRfkoT6IAruQOi6NTieay50w+LccQ A0OA== X-Received: by 10.180.93.133 with SMTP id cu5mr15826013wib.32.1392146254067; Tue, 11 Feb 2014 11:17:34 -0800 (PST) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id cm5sm40457wid.5.2014.02.11.11.17.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 11:17:33 -0800 (PST) Message-ID: <52FA7749.4020808@gmail.com> Date: Tue, 11 Feb 2014 20:17:29 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dhcwg References: <52FA6F62.5050505@gmail.com> In-Reply-To: <52FA6F62.5050505@gmail.com> X-Enigmail-Version: 1.5.2 X-TagToolbar-Keys: D20140211201729163 X-Forwarded-Message-Id: <52FA6F62.5050505@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] WGLC summary on draft-ietf-dhc-v4configuration-04 (passed) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 19:17:37 -0000 On 17.01.2014 22:50, Tomek Mrugalski wrote: > Authors and chairs feel that draft-ietf-dhc-v4configuration-04 > (http://datatracker.ietf.org/doc/draft-ietf-dhc-v4configuration/) is > ready for WGLC. Please post your comment by end of January. It took a while, but we're finally wrapping up this. We had quite a few responses for this WGLC with healthy discussion and technical comments. It's a welcome change, compared to other WGLCs. This document also was presented twice (three times if you also count shared Sunset4/DHC separately) during meetings, where it received favourable comments. Based on those facts, chairs decided to pass this WGLC. Having said that, an updated version of this document is needed. Authors, please upload -05 as soon as you can. Keep in mind that the submission cut-off is this Friday, Feb. 14th. Once it is published, we will wait couple days for people to comment on it and if there are no major objections, it will be sent to the IESG. Bernie & Tomek From tomasz.mrugalski@gmail.com Tue Feb 11 11:38:58 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB721A0711 for ; Tue, 11 Feb 2014 11:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmDzq8v-TQcS for ; Tue, 11 Feb 2014 11:38:56 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id B43251A06F4 for ; Tue, 11 Feb 2014 11:38:55 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id f8so5163366wiw.15 for ; Tue, 11 Feb 2014 11:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rTUr4iuxxTaoF2HL4tcvdBf6vlD8BHeIBK/oTRQK/FA=; b=lWZdzNuyqVmr0s1xgQ8iRI09AWZakd23oBM4j7xnoEvJwQu9VNJbryx1ZZRv8aIAb6 +HkqNhG0jH14CyGCqrQWaLaN6LiY4cFETP2Z9WfVeaT0RrqjNGNFad6Lz0/4Uk1uOpFK WIYY9IjqtKnRHXreRwki9kX3TEjx3w44r7XC1WORGfkQUrWttvPcvVFW4jd5GD+YcjE3 YIsDNyf1PH8b1KyoeMIlSNmWUeW1A2dx+qBINbpp+okyACjS/aYlJ8sQw1KgsQc2tP53 cj80HAo0QK+56ZoeZ0hgKG5wzf9twq5827NDgzAQVrqJ0gR94989y/REx1d6Ka31zLz2 Yq1A== X-Received: by 10.194.84.144 with SMTP id z16mr27803961wjy.23.1392147534717; Tue, 11 Feb 2014 11:38:54 -0800 (PST) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id f7sm46325275wjb.7.2014.02.11.11.38.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 11:38:53 -0800 (PST) Message-ID: <52FA7C49.9000900@gmail.com> Date: Tue, 11 Feb 2014 20:38:49 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "dhcwg@ietf.org" References: <489D13FBFA9B3E41812EA89F188F018E1AE2B09C@xmb-rcd-x04.cisco.com> <52DD7366.3000101@gmail.com> In-Reply-To: <52DD7366.3000101@gmail.com> X-Enigmail-Version: 1.5.2 X-TagToolbar-Keys: D20140211203849339 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Ole_Tr=F8an?= , "Bernie Volz \(volz\)" Subject: [dhcwg] WGLC summary on draft-ietf-dhc-dhcpv6-stateful-issues-05: Failed X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 19:38:58 -0000 On 20.01.2014 20:05, Tomek Mrugalski wrote: > Since Bernie is co-author, I'll manage this work group last call on my > own. Authors believe that stateful-issues-05 draft is ready for WG last > call. Please post your comments no later than on February 3rd. I'm sorry to announce that this document has failed its WGLC. There were only three responses, one of them being from an author. I'm sorry, but this is not enough to pass a last call. With my chair hat off, I'm very disappointed at this. This is a very good document and essential stepping stone that would help a lot with 3315bis work. We had a discussion with Bernie about why people didn't respond to this. Perhaps there are too many WGLC/adoption calls lately, so people are not able to cope up with the pace? Did people lost interest in this work? That seems unlikely. Please keep in mind that the support is not transitive. If you voiced your support during adoption call, it does not imply that you still support that work during WGLC. Perhaps there are too many other drafts being worked on at the same time? Would it be helpful if we stopped accepting any new work until existing drafts are done (or at least a majority of them)? This document attempts to fix several protocol issues. This is especially depressing, since Timothy Winters, who is involved in DHCPv6 interop testing explicitly mentioned that there are real life interop issues observed. So this draft addressing a very real problem. It's not a theoretical type of thing. I'll work with Bernie and Ole on the next steps. There will likely be a presentation about this draft in London. Tomek From volz@cisco.com Tue Feb 11 11:53:13 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E621A0722 for ; Tue, 11 Feb 2014 11:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oz0fd-PGPxKE for ; Tue, 11 Feb 2014 11:53:11 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B47271A0700 for ; Tue, 11 Feb 2014 11:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3636; q=dns/txt; s=iport; t=1392148391; x=1393357991; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=Em35/PBIpcDja6LF9fK/HXlo46p42kRdFbWshMYjE14=; b=eV7CRi31FRAUcUpiYkD2kqHbacbg921BfdV3VCunqoOCubp1Kawqv66O UpRUOEuFKmfw2qoqJ066NTRRsZCGux5wIkc2JfihE/KF2NssogcnOD1sz nMV4GychJx4INDxwORFtmG2GsGdKMwjnVxdpmNBPR1u/4MN9EOdjC+yZ9 A=; X-IronPort-AV: E=Sophos;i="4.95,827,1384300800"; d="scan'208";a="303330485" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 11 Feb 2014 19:53:11 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1BJrBOL005162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 19:53:11 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 13:53:10 -0600 From: "Bernie Volz (volz)" To: Tomek Mrugalski , "dhcwg@ietf.org" Thread-Topic: London Agenda Item - was RE: WGLC summary on draft-ietf-dhc-dhcpv6-stateful-issues-05: Failed Thread-Index: Ac8nYQwWjlfnywwmTluIAgb4GvHOrg== Date: Tue, 11 Feb 2014 19:53:10 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE64D19@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.65.109] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Ole_Tr=F8an?= Subject: [dhcwg] London Agenda Item - was RE: WGLC summary on draft-ietf-dhc-dhcpv6-stateful-issues-05: Failed X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 19:53:14 -0000 I request a 10 minute slot at IETF-89 for the stateful-issues draft and nex= t steps. The main goal will be to: 1. Determine if there is sufficient interest to continue this work or aband= on it. 2. For sufficient interest, I think we need least 5 people will need to agr= ee to seriously review the document by March 31st. Note that this is more t= han just saying "+1" in an email - there are always issues with a document. --> NOTE: Anyone willing to volunteer now should let Ole and me (and Tomek)= know. There are two known issues that should be addressed in an 06, but both are = fairly minor: 1. Acknowledgements section (7.0) is empty. This needs to be filled in (or = removed). 2. Release Message section (4.7) needs some work, including potentially a t= itle change. Text currently is: 4.7. Release Message A client can release any individual lease at any time. A client can get "back" a lease by using a Renew message. It MAY do this at any time, though must avoid creating a Renew storm. E.g. wait until T1. But mixing the release and renew is less than optimum. Once released, a Ren= ew is obviously not valid. We may want to remove this section as I'm not su= re what purpose it serves and I think 3315/3633 are already clear on Releas= e and Renew processing? There is also the new issue that Tim Winters (UNH) recently raised which we= may want to consider for inclusion - what is the proper behavior for a cli= ent when the Reply includes both an address and prefix, but the client dete= rmines that the address is unusable and must Decline it - what should it do= about the prefix. - Bernie -----Original Message----- From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com]=20 Sent: Tuesday, February 11, 2014 2:39 PM To: dhcwg@ietf.org Cc: Bernie Volz (volz); Ole Tr=F8an Subject: WGLC summary on draft-ietf-dhc-dhcpv6-stateful-issues-05: Failed On 20.01.2014 20:05, Tomek Mrugalski wrote: > Since Bernie is co-author, I'll manage this work group last call on my=20 > own. Authors believe that stateful-issues-05 draft is ready for WG=20 > last call. Please post your comments no later than on February 3rd. I'm sorry to announce that this document has failed its WGLC. There were on= ly three responses, one of them being from an author. I'm sorry, but this i= s not enough to pass a last call. With my chair hat off, I'm very disappointed at this. This is a very good d= ocument and essential stepping stone that would help a lot with 3315bis wor= k. We had a discussion with Bernie about why people didn't respond to this.= Perhaps there are too many WGLC/adoption calls lately, so people are not a= ble to cope up with the pace? Did people lost interest in this work? That s= eems unlikely. Please keep in mind that the support is not transitive. If y= ou voiced your support during adoption call, it does not imply that you sti= ll support that work during WGLC. Perhaps there are too many other drafts being worked on at the same time? W= ould it be helpful if we stopped accepting any new work until existing draf= ts are done (or at least a majority of them)? This document attempts to fix several protocol issues. This is especially d= epressing, since Timothy Winters, who is involved in DHCPv6 interop testing= explicitly mentioned that there are real life interop issues observed. So = this draft addressing a very real problem. It's not a theoretical type of t= hing. I'll work with Bernie and Ole on the next steps. There will likely be a pre= sentation about this draft in London. Tomek From tomasz.mrugalski@gmail.com Tue Feb 11 12:38:33 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306221A072A for ; Tue, 11 Feb 2014 12:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6FSJstQBr0K for ; Tue, 11 Feb 2014 12:38:31 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2111A0709 for ; Tue, 11 Feb 2014 12:38:30 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id e4so5297282wiv.16 for ; Tue, 11 Feb 2014 12:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=3n1XRP5TOZJm3QIptCgZ6BAhQCFlpmm/ZCI7YnP7sHA=; b=fl7P304tr8cl2ZhwRoM0e1VGfh96fbq0DDOwnf4R5Vy8OsBbbI8Rg85VqnBH0EmyFL lCrUKb4h73AFKAylqKj2p2IOVJErqRRSyDMOlH7mBgbs7qtY7nuCYQEXyrU8iXR/FFev yV8cOch1RLf/OqSfG0XLiyAotRA0Mla4it2YnNZmdNVkCQI3v02hUGlWVLNY9S5DR+rP 04pDa3kdhMe0c9QQ8ShY3glrJXDzkUFFCEJmjrPLx++QfrAEkoX68lksKfxYW/aen4kM evU6+mDtKKBUDqrKjXlDaRut7xTTqj74bnHHj91rVqMN6AYJufnodGPnI6HoM38jv7c9 ejdA== X-Received: by 10.180.12.43 with SMTP id v11mr76308wib.33.1392151109947; Tue, 11 Feb 2014 12:38:29 -0800 (PST) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id gt6sm426464wib.8.2014.02.11.12.38.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 12:38:29 -0800 (PST) Message-ID: <52FA8A40.8020703@gmail.com> Date: Tue, 11 Feb 2014 21:38:24 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dhcwg X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-active-leasequery-00 - Respond by Feb. 28 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 20:38:33 -0000 We have adopted two active leasequery drafts after Vancouver meeting. There was moderate interest in that work during adoption call, but we never saw any discussions about them on the ML. Since authors confidence in those proposals are high due to existing implementations, they have requested WGLC. After a quick discussion between chairs, we have decided to go ahead with the WGLC, hoping that it will trigger some reviews and discussion. Please make no mistake - those drafts need reviews and comments. A simple "I support this" followed with couple +1s will not do do the trick here. This WGLC is for draft-ietf-dhc-dhcpv4-active-leasequery-00. Please send your comments by Feb. 28th. Note that although both documents are very similar, they are separate drafts and are going through separate WGLCs. If you support this work, make sure that you clearly state which draft (v4, v6 or both) you support. Each WGLC will be assessed independently. Finally, I'd also remind you that we are looking for volunteers to do the shepherding work. Please let us know if you'd like to be a shepherd for one of those documents. It is not a difficult task, but some prior IETF experience is necessary. As a shepherd, you can get unique insight into the WGLC process and better exposure to how IESG works. Having such an experience can be useful with moving your own draft forward faster. Bernie & Tomek From tomasz.mrugalski@gmail.com Tue Feb 11 12:39:27 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8592B1A073B for ; Tue, 11 Feb 2014 12:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCmH1uPOqoyy for ; Tue, 11 Feb 2014 12:39:26 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id AF5271A072A for ; Tue, 11 Feb 2014 12:39:25 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id cc10so5310978wib.10 for ; Tue, 11 Feb 2014 12:39:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=fP5M1SEF2pmMGmN07LeyODEwfU9EMhfPB0rkpM9mS7c=; b=rRzow3q9ajw2LeJaLPmDKBhM1ROAA0bJU9qUG29iZ8s/gz2dudDbNkzrQdrgec2KKy bsNWGwf3h3VpVuF153mnhwyVkoz8o79OltGDhzT3zI4qqZLBSOQvG0ukbKhia7/KODBY ylugmJI4LbhH+Jg1CbK+bGecdU1PhBmElPWY7uCCVJkfzCXT6TT7mrL4njz+MrJYKWIT qiVr843xqEFIWhevGG2r32HI4dE2zMyq6C11nEZZKHp8HrmkSzVh3ST0VkggUYaqqhFG iPmXmQG+ieEXzw0fb9tDKVGES9koDKTt+t7alR2thx4dxlBCw/XYJHtLcjFXvi3J9l/b gjKw== X-Received: by 10.180.91.17 with SMTP id ca17mr70602wib.41.1392151164734; Tue, 11 Feb 2014 12:39:24 -0800 (PST) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id h13sm46770215wjr.22.2014.02.11.12.39.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 12:39:24 -0800 (PST) Message-ID: <52FA8A77.9000504@gmail.com> Date: Tue, 11 Feb 2014 21:39:19 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dhcwg References: <52FA85BB.7090003@gmail.com> In-Reply-To: <52FA85BB.7090003@gmail.com> X-Enigmail-Version: 1.5.2 X-TagToolbar-Keys: D20140211213919815 X-Forwarded-Message-Id: <52FA85BB.7090003@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - Respond by Feb. 28 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 20:39:27 -0000 We have adopted two active leasequery drafts after Vancouver meeting. There was moderate interest in that work during adoption call, but we never saw any discussions about them on the ML. Since authors confidence in those proposals are high due to existing implementations, they have requested WGLC. After a quick discussion between chairs, we have decided to go ahead with the WGLC, hoping that it will trigger some reviews and discussion. Please make no mistake - those drafts need reviews and comments. A simple "I support this" followed with couple +1s will not do do the trick here. This WGLC is for draft-ietf-dhc-dhcpv6-active-leasequery-00. Please send your comments by Feb. 28th. Note that although both documents are very similar, they are separate drafts and are going through separate WGLCs. If you support this work, make sure that you clearly state which draft (v4, v6 or both) you support. Each WGLC will be assessed independently. Finally, I'd also remind you that we are looking for volunteers to do the shepherding work. Please let us know if you'd like to be a shepherd for one of those documents. It is not a difficult task, but some prior IETF experience is necessary. As a shepherd, you can get unique insight into the WGLC process and better exposure to how IESG works. Having such an experience can be useful with moving your own draft forward faster. Bernie & Tomek From volz@cisco.com Tue Feb 11 13:48:43 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9DF1A076A for ; Tue, 11 Feb 2014 13:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kwId4BAVc6Z for ; Tue, 11 Feb 2014 13:48:41 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C37E41A074D for ; Tue, 11 Feb 2014 13:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1200; q=dns/txt; s=iport; t=1392155321; x=1393364921; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=BY5chnsZ5870zsQo5w/HfT9BvXBLRHoN4/qqhv/xJcc=; b=XyHxrfRlm/QY12Cqeo2lHBRzclg+KQv9OcAjSZ6lqbudSPUiRlSKXfcg 6ephR+CvvBLf9b+PgjxQesaYMqolTAM+KswzSiyndXmijeNkDiaG6iUaH Q4/aUMcBZ7QqgXqa0wEs43AQwGeFaY0bTiLaH7zVnkzB0EWdHoqZPASbT Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAOyZ+lKtJXG//2dsb2JhbABAGoMMOFeDAbwMGH8WdIIlAQEBBCMRUQYBGQQBAQMCBh0DAgQwFAEICQEEEwiHfQ02l36PFaEZF4Epi1mBIyM+gmk1gRQEmVyQboMtgio X-IronPort-AV: E=Sophos;i="4.95,827,1384300800"; d="scan'208";a="303411035" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 11 Feb 2014 21:48:41 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1BLmfYH007417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 11 Feb 2014 21:48:41 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 15:48:40 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Meetecho at IETF 89? Thread-Index: Ac8ncwZ5EfXb9biqSlmBaTx4Jiqk3w== Date: Tue, 11 Feb 2014 21:48:40 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE64EDC@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.65.109] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [dhcwg] Meetecho at IETF 89? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 21:48:43 -0000 SXMgdGhlcmUgYW55IGludGVyZXN0IGluIHRoaXMgZm9yIHRoZSBESEMgV0cgc2Vzc2lvbiAoTW9u ZGF5IEFNIExvbmRvbiB0aW1lKT8NCg0KUGxlYXNlIGxldCB1cyBrbm93IGFuZCB3ZSB3aWxsIHN1 Ym1pdCBhIHJlcXVlc3QuDQoNCi0gQmVybmllDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBXR0NoYWlycyBbbWFpbHRvOndnY2hhaXJzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBJRVRGIEFnZW5kYQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMTEsIDIwMTQgMzo1 MCBQTQ0KVG86IFdvcmtpbmcgR3JvdXAgQ2hhaXJzDQpDYzogaXJzZ0BpcnRmLm9yZw0KU3ViamVj dDogTWVldGVjaG8gYXQgSUVURiA4OQ0KDQoNCkhlbGxvIFdvcmtpbmcgR3JvdXAgQ2hhaXJzIQ0K DQpNZWV0ZWNobyB3aWxsIGJlIHN1cHBvcnRpbmcgZm91ciBzZXNzaW9ucyBzaW11bHRhbmVvdXNs eSBhdCB0aGUgdXBjb21pbmcgbWVldGluZyBpbiBMb25kb24uICBJZiB5b3UgaGF2ZSB5ZXQgdG8g cmVxdWVzdCBNZWV0ZWNobyBidXQgd291bGQgbGlrZSB0bywgcGxlYXNlIGxldCBtZSBrbm93IGJ5 IEZyaWRheSwgRmVicnVhcnkgMTR0aCwgMjAxNC4gIElmIHdlIGRvIG5vdCByZWNlaXZlIGVub3Vn aCByZXF1ZXN0cyB0aGUgTWVldGVjaG8gdGVhbSB3aWxsIGNob29zZSBzZXNzaW9ucyB0aGF0IHdp bGwgYmUgc3VwcG9ydGVkLg0KDQpIZXJlIGFyZSBleGFtcGxlcyBvZiBzZXNzaW9ucyB0aGF0IE1l ZXRlY2hvIHN1cHBvcnRlZCBmb3IgSUVURiA4ODogICANCmh0dHA6Ly9pZXRmODguY29uZi5tZWV0 ZWNoby5jb20vaW5kZXgucGhwL1JlY29yZGVkX1Nlc3Npb25zDQoNClRoYW5rIHlvdSENCg0KU3Rl cGhhbmllIE1jQ2FtbW9uDQoNCg== From volz@cisco.com Tue Feb 11 13:56:03 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA91D1A0787 for ; Tue, 11 Feb 2014 13:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9FOmMsrdpvn for ; Tue, 11 Feb 2014 13:56:02 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id D5BE61A0782 for ; Tue, 11 Feb 2014 13:56:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2436; q=dns/txt; s=iport; t=1392155761; x=1393365361; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=K9+P1vFXM1/+ABGcDqPdV0tainVNFiP/R/SqkWFtcgo=; b=H8PHn913fecVAMUsyGhMEw7jjT5Zf7eTLrQinLh5tsQIwxhgJNoYkBc1 HoIHYpdM8EEch5bHRVwRcmnaz/TZyJRb+4839vaQTAZANKTYEQBPfbW9R Zn8akRiR1W67HaErwO+miEO2Y4EB1X1XjOnWba2LlaTycgow+TyeH6rvL s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAMub+lKtJXG+/2dsb2JhbABagww4V78NgRcWdIIlAQEBBAEBAWsXBAIBCBEEAQEBCh0HJwsUCQgBAQQTCId9DclfEwSOSDgGgx6BFASJEKE6gy2CKg X-IronPort-AV: E=Sophos;i="4.95,827,1384300800"; d="scan'208";a="19685527" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-3.cisco.com with ESMTP; 11 Feb 2014 21:56:01 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1BLu1un010956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 11 Feb 2014 21:56:01 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 15:56:01 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 Thread-Index: Ac8RbvjnR7wHzR7iTQy6lhZdhZEp8gWBDePw Date: Tue, 11 Feb 2014 21:56:00 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE64F11@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1AE1EEB5@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AE1EEB5@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.65.109] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 21:56:04 -0000 This document did pass the WGLC but we had been waiting for the v4configura= tion draft, which has passed. I believe (though need to confirm with the authors) that the 04 draft they = published on Jan 17, 2014 incorporates all of the comments from the last ca= ll. We will shortly send this off to advance (we expect to send this and the v4= configuration draft about the same time). - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Tuesday, January 14, 2014 4:26 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-= 03 Hi: We've left this WGLC open pending the last call on the v4configuration draf= t. The authors of the v4configuration draft have been working on updating i= t and should be submitting it shortly, at which time we will start the WGLC= for it. We will then close the last calls for both documents (dhcpv4-over-= dhcpv6 and v4configuration) at the same time. Sorry for the delay but as the two documents are closely related, we feel i= t is best to hold off until both can be reviewed. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Monday, December 16, 2013 9:58 AM To: dhcwg@ietf.org Subject: Re: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-= 03 - Respond by Dec 9, 2013 On 16.12.2013 15:40, Simon Perreault wrote: > Le 2013-12-14 10:10, Bernie Volz (volz) a =E9crit : >> WGLC on the related draft-ietf-dhc-v4configuration-03 is in progress >=20 > Is this true? I can't find the announcement, and the datatracker=20 > doesn't show the draft as being in WGLC... No, that was a mistake. Bernie and I exchanged preliminary WGLC announcemen= t text, but due to the discussion about dhcpv4-over-dhcpv6 we still haven't= sent it out. So no - there is no WGLC on v4configuration yet, but there li= kely will be in the next couple days. It will be long enough so people who take holiday + new year vacation will = be able to get back and post their comments when they get back in January. Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Tue Feb 11 14:34:28 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0DE1A0798 for ; Tue, 11 Feb 2014 14:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPlPPJ5bHXbo for ; Tue, 11 Feb 2014 14:34:25 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id EE2A31A0793 for ; Tue, 11 Feb 2014 14:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8280; q=dns/txt; s=iport; t=1392158064; x=1393367664; h=from:to:subject:date:message-id:mime-version; bh=GGoVlMsw9XpwOHkzAzjfX4ttIs45euCnOTBhtJ9dCBU=; b=PHYrPbTu0jM+4ZlwjfFDN8MeLoOOKCsGdcLyGMCRzbM/eRFcz6dMm+iF tm/h7DfHfTXJl3TT6GU4tgibSxmsbqrEoVAWZxnU6gIbPfV9aO2oRYhXm UvAyklCH6mnAM8QBTniEuyDT1eKTMqRxGMhQQrmcLWKpri4O5YQO6f6Hc 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFALik+lKtJV2a/2dsb2JhbABagkhEOFe/EYEXFnSCJwEELV4BKlYmAQQbAYd8DZg9sSkXjiUjg1yBFASUQZYJgy2CKg X-IronPort-AV: E=Sophos;i="4.95,828,1384300800"; d="scan'208,217";a="19698015" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 11 Feb 2014 22:34:24 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1BMYOLk032396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 11 Feb 2014 22:34:24 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 16:34:24 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: IETF-89 (London) Draft Agenda Thread-Index: Ac8neNJKxuuX+U0eQReRFZ0FJHl2QQ== Date: Tue, 11 Feb 2014 22:34:22 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE64FAE@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.65.109] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AE64FAExmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] IETF-89 (London) Draft Agenda X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 22:34:29 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AE64FAExmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: We published the current draft agenda (it is available at http://www.ietf.o= rg/proceedings/89/agenda/agenda-89-dhc and appears below). If you want time= or you requested time and it isn't there, let us know. If time estimates a= re correct, we are presently using 90 of our 150 minutes. Please note that = this is a draft agenda and we may rearrange the order (as well as add or re= move items). - Tomek & Bernie ** DRAFT ** DHC WG Agenda for IETF-89 (London) MONDAY, March 3, 2014, 0900-1130 (subject to change) Chairs: Tomek Mrugalski & Bernie Volz Presentations materials: https://datatracker.ietf.org/meeting/89/materials.= html#wg-dhc 1. Co-Chairs - Administrativia (WG Status & Agenda Bashing) - 10 minutes 2. Tomek Mrugalski - RFC-3315bis Issues - 20 minutes 3. Tomek Mrugalski - draft-ietf-dhc-dhcpv6-failover-design - 10 minutes 4. Sheng Jiang - draft-ietf-dhc-sedhcvp6 - 10 minutes 5. Sheng Jiang - draft-jiang-dhc-stateless-reconfiguration - 15 minutes 6. Bernie Volz - DHCPv6 Load Balancing - 10 minutes [TENTATIVE - reviving draft-ietf-dhc-dhcpv6-load-balancing-00) 7. Tomek Mrugalski - draft-ietf-dhc-topo-conf-00 - 5 minutes [TENTATIVE] 8. Bernie Volz - draft-ietf-dhc-dhcpv6-stateful-issues - 10 minutes Last Updated: Feb. 10, 2014 (Subject to Change) --_000_489D13FBFA9B3E41812EA89F188F018E1AE64FAExmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

We published the current draft agenda (it is availab= le at http://www.ietf.org/proceedings/89/agenda/agenda-89-dhc and appears bel= ow). If you want time or you requested time and it isn’t there, let u= s know. If time estimates are correct, we are presently using 90 of our 150= minutes. Please note that this is a draft agenda and we may rearrange the order (as well as add or remove items).

 

-     &= nbsp;    Tomek & Bernie

 

** DRAFT ** DHC WG Agenda for IETF-89 (London)<= /o:p>

 

MONDAY, March 3, 2014, 0900-1130 (subject to change)=

Chairs: Tomek Mrugalski & Bernie Volz=

Presentations materials: https://datatracker.ietf.or= g/meeting/89/materials.html#wg-dhc

 

1. Co-Chairs - Administrativia (WG Status & Agen= da Bashing) - 10 minutes

2. Tomek Mrugalski - RFC-3315bis Issues - 20 minutes=

3. Tomek Mrugalski - draft-ietf-dhc-dhcpv6-failover-= design - 10 minutes

4. Sheng Jiang - draft-ietf-dhc-sedhcvp6 - 10 minute= s

5. Sheng Jiang - draft-jiang-dhc-stateless-reconfigu= ration - 15 minutes

6. Bernie Volz - DHCPv6 Load Balancing - 10 minutes = [TENTATIVE - reviving

   draft-ietf-dhc-dhcpv6-load-balancing-00= )

7. Tomek Mrugalski - draft-ietf-dhc-topo-conf-00 - 5= minutes [TENTATIVE]

8. Bernie Volz - draft-ietf-dhc-dhcpv6-stateful-issu= es - 10 minutes

 

Last Updated: Feb. 10, 2014 (Subject to Change)=

--_000_489D13FBFA9B3E41812EA89F188F018E1AE64FAExmbrcdx04ciscoc_-- From internet-drafts@ietf.org Wed Feb 12 00:55:14 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F371A08B1; Wed, 12 Feb 2014 00:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0V8MnYkz6-W; Wed, 12 Feb 2014 00:55:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C50561A08C4; Wed, 12 Feb 2014 00:55:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140212085512.32380.21586.idtracker@ietfa.amsl.com> Date: Wed, 12 Feb 2014 00:55:12 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 08:55:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Provisioning IPv4 Configuration Over IPv6 Only Networks Authors : Branimir Rajtar Ian Farrer Filename : draft-ietf-dhc-v4configuration-05.txt Pages : 17 Date : 2014-02-12 Abstract: As IPv6 becomes more widely adopted, some service providers are choosing to deploy IPv6 only networks without dual-stack functionality for IPv4. However, as access to IPv4 based services will continue to be a requirement for the foreseeable future, IPv4 over IPv6 mechanisms, such as softwire tunnels are being developed. In order to provision end-user's hosts with the IPv4 configuration necessary for such mechanisms, a number of different approaches have been proposed. This memo discusses each of the proposals, identifies the benefits and drawbacks and recommends approaches to be used as the basis for future deployment and development. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-v4configuration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-v4configuration-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jinmei.tatuya@gmail.com Wed Feb 12 13:25:20 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0585A1A066B for ; Wed, 12 Feb 2014 13:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.922 X-Spam-Level: * X-Spam-Status: No, score=1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jq-EwrOTMmt6 for ; Wed, 12 Feb 2014 13:25:18 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CBA0F1A069B for ; Wed, 12 Feb 2014 13:25:17 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hm4so7653660wib.14 for ; Wed, 12 Feb 2014 13:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=per1mWF9ulquwzWlB1G4EW7LHC1/Nczuc78R8X59xYw=; b=pZ/3POMfDHKNwBR0Ws20BEAEymqc0NJbifR9OgPLA7m8V7WTeMRGGlx3lHrOZeUGQt +M1XapCd/TgaFWHJTsbDoAD9I2RpbWEPwwTTeYLSyvbWR49rL6aHH0HDEBnhu+0H+WAi sdeZeXubompWbk98LC6EkkDUcZcmXO/eEKQOsHWP8BOfEya+Cs5yWsZdSd/exjHaJRQR L5aD7ZvDyGnXY6s61mscAkZ1TWnJOSXbvB750cGURY7a7JNFl9ds4cdtkDL9WI2G0Vmc 1IpY2jKxmUXT3UetUeFlJjfgGwkk7uB9T/z6sYwf/g4M4rDT0xfY9BBEBt21dPvroSJC J6SQ== MIME-Version: 1.0 X-Received: by 10.180.100.70 with SMTP id ew6mr3727590wib.57.1392240316425; Wed, 12 Feb 2014 13:25:16 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Wed, 12 Feb 2014 13:25:16 -0800 (PST) Date: Wed, 12 Feb 2014 13:25:16 -0800 X-Google-Sender-Auth: VrYphGXM_TLtXCy8GWtMegufZ0Q Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: draft-ietf-dhc-dhcpv6-stateful-issues@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: dhcwg@ietf.org Subject: [dhcwg] comments on draft-ietf-dhc-dhcpv6-stateful-issues-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 21:25:20 -0000 I've read the latest version of the draft. First, I have some higher level comments and questions: - I agree that it's a good idea to clarify/generalize the concept of IA so we can handle multiple types of IAs at the same time. But at the same time, I wonder for what a DHCP client would want to request both IA_NA (or IA_TA) and IA_PD at the same time. Is there any specific need for that in practice? Requesting both IA_NA and IA_TA at the same time seem to be a more likely need to me, btw, and, if only in that sense I see the value of the attempt of clarification and extension. - I'm not sure if it's the best approach to consider all types of IAs as a set (if I understand it correctly, that's what this draft basically proposes, right?). For example, assume a client wants to be assigned IA_NA and IA_TA but ends up with accepting an Advertise only containing IA_NA. Then I suspect it's very unlikely IA_TA is now magically assigned in response to the subsequent Request (but I'm okay with this point; there doesn't seem to be any viable option for the client in this situation anyway, and the overhead in this Request and Reply would be marginal). And the client needs to wait until time T1 before retrying the assignment of IA_TA. If the unavailability of IA_TA is a temporary event and T1 is relatively large (e.g., hours or longer), that wouldn't be really good. - (Slightly related to the previous point) The idea of considering T1/T2 to be "protocol timers" (per Section 4.3) is not really well-applicable to IA_TA since IA_TA is inherently free from renewal. We could treat IA_TA as a special case for the general concept of "protocol timers", but if we are trying to generalize the concept of "stateful resources", I suspect we should rather expect such exceptional cases. Considering these, I wonder it may make sense to handle different IAs in dedicated different states, but still in the same single DHCPv6 "session". For example, once a specific server is chosen after a Solicit-Advertise (+ possibly Request-Reply) exchange, each IA is maintained in its own state. Some may involve renewal process, and not-yet-assigned IAs can be Request-ed again after some reasonable delay. One tricky case with this approach is, though, when the server stops responding to Renew and an IA needs Rebind. We then need to consider what to do with other IAs. I'm not necessarily insisting on this is clearly better than the currently described approach in the draft, but my main point is that pros and cons are not so obvious (to me) and we'll probably need some more discussion at this level. Some specific comments (mostly minor) on the draft text follow: - Section 4.1: shouldn't this SHOULD be a "MUST"? when not all IA option types are being offered. A client SHOULD ignore an Advertise message when no bindings at all are being offered. Since in the proposed replace text it states: The client MUST ignore any Advertise message that contains no bindings (if only IA_NA and/or IA_TA options were requested, - In Section 4.4 With: At time T1 for an IA, the client initiates a Renew/Reply message exchange to extend the lifetimes on any addresses in the IA. The client includes an IA option with all addresses currently assigned to the IA in its Renew message. The client also includes an IA option for each binding it desires but has been unable to obtain. Should phrases like "any addresses" be generalized so they'll be applicable to other types of stateful resources? From the replacement of "available addresses" with "available options" in the proposed text in Section 4.1, I thought such generalization was one goal of the replacement text. Same sense of comments apply to some other places of the draft (e.g., in the "With" text of Section 4.5). - Also in Section 4.4: s/records/returns/? If the server cannot find a client entry for the IA the server creates the bindings for that client according to the server's policy and configuration information and records the IAs and other information requested by the client. and s/which is does/which it does/? these IAs. However, it MUST limit the frequency at which is does this to no more often than the renewal frequency. -- JINMEI, Tatuya From volz@cisco.com Wed Feb 12 13:56:25 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F9F1A000A for ; Wed, 12 Feb 2014 13:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FlHO_6xiEVB for ; Wed, 12 Feb 2014 13:56:23 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id BE7D01A0009 for ; Wed, 12 Feb 2014 13:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7590; q=dns/txt; s=iport; t=1392242182; x=1393451782; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KNCnWNK+uDLSVBesneJdAOeILpzhkI8N/2vEkwdWcNU=; b=DeqFbQLzHtptBgSt+MN9LrAAFY+Rqx7rjWHGccYu8MIeGJ8fl3tUfMV0 aZPiMLLHxCjx4vw1Nq/KjF6u8Ykghhd+ykNXy1rGOYiEokKY2R9KINhVy ZKFJ9AXLuJBMr2ZNNYY+pBvPPVgrFpgpW6EQeRk0HnKgO0ikCDUMnvs3Q A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAEPt+1KtJV2b/2dsb2JhbABagwyBD4MBpjGBepQDgRkWdIIlAQEBBCEBVwwEAgEIEQQBAQIDBgUYAgMCIREUCQgCBAENBQiHaQMRimmbegGZZQ2ILheBJos5gUMmJgsHBoJmOIEUAQOWPo5KhUODLYFoAR8EHg X-IronPort-AV: E=Sophos;i="4.95,834,1384300800"; d="scan'208";a="19997516" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 12 Feb 2014 21:56:21 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1CLuLop014137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 21:56:21 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 15:56:21 -0600 From: "Bernie Volz (volz)" To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= , "draft-ietf-dhc-dhcpv6-stateful-issues@tools.ietf.org" Thread-Topic: comments on draft-ietf-dhc-dhcpv6-stateful-issues-05 Thread-Index: AQHPKDj0ZdbcypmIR0uf6QO4SzfBEZqyJKXw Date: Wed, 12 Feb 2014 21:56:20 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE665F6@xmb-rcd-x04.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.65.109] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] comments on draft-ietf-dhc-dhcpv6-stateful-issues-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 21:56:25 -0000 JINMEI: Many thanks for the careful review!!! Some comments below inline (BV>). - Bernie -----Original Message----- From: jinmei.tatuya@gmail.com [mailto:jinmei.tatuya@gmail.com] On Behalf Of= ???? Sent: Wednesday, February 12, 2014 4:25 PM To: draft-ietf-dhc-dhcpv6-stateful-issues@tools.ietf.org Cc: dhcwg@ietf.org Subject: comments on draft-ietf-dhc-dhcpv6-stateful-issues-05 I've read the latest version of the draft. First, I have some higher level comments and questions: - I agree that it's a good idea to clarify/generalize the concept of IA so we can handle multiple types of IAs at the same time. But at the same time, I wonder for what a DHCP client would want to request both IA_NA (or IA_TA) and IA_PD at the same time. Is there any specific need for that in practice? Requesting both IA_NA and IA_TA at the same time seem to be a more likely need to me, btw, and, if only in that sense I see the value of the attempt of clarification and extension. BV> Home gateways (such in Cable, DOCSIS) typically do request an IA_NA and= IA_PD - the IA_NA is for use by the gateway itself whereas the IA_PD is fo= r the prefix within the home (typically stateless is used within the home). - I'm not sure if it's the best approach to consider all types of IAs as a set (if I understand it correctly, that's what this draft basically proposes, right?). For example, assume a client wants to be assigned IA_NA and IA_TA but ends up with accepting an Advertise only containing IA_NA. Then I suspect it's very unlikely IA_TA is now magically assigned in response to the subsequent Request (but I'm okay with this point; there doesn't seem to be any viable option for the client in this situation anyway, and the overhead in this Request and Reply would be marginal). And the client needs to wait until time T1 before retrying the assignment of IA_TA. If the unavailability of IA_TA is a temporary event and T1 is relatively large (e.g., hours or longer), that wouldn't be really good. BV> The IA_NA/IA_TA case was actually "probably" already handled in RFC 331= 5 though I suspect we could improve this. This is more about interacting wi= th IA_PD. The case where IA_TAs aren't provided just means that the client = won't have any DHCP assigned temporary addresses and may either generate it= s own (if allowed) or will be restricted from using temporary addresses. An= IA_TA is more likely requested on demand or periodically when the previous= one becomes non-preferred. This is probably a case where a separate DHCPv6= transaction is warranted and appropriate. BV> I agree though that we should expand the document to discuss this a bit= more - again, the focus of the work was really IA_NA + IA_PD. BV> We might even propose to DEPRECATE IA_TA as there's probably little val= ue in it for DHCPv6 assigned addresses. This grew out of the original priva= cy concerns for EUI-64 mac address based addresses in IPv6 and DHCPv6 assig= ned addresses shouldn=1B$B!G=1B(Bt normally have these privacy concerns (yo= u might get the same address each time you connect at work, but that won't = be related to the one that you get at home or when in your favorite coffee = shop). - (Slightly related to the previous point) The idea of considering T1/T2 to be "protocol timers" (per Section 4.3) is not really well-applicable to IA_TA since IA_TA is inherently free from renewal. We could treat IA_TA as a special case for the general concept of "protocol timers", but if we are trying to generalize the concept of "stateful resources", I suspect we should rather expect such exceptional cases. BV> Surprising RFC 3315 DOES allow IA_TA to be renewed (see RFC 3315, secti= on 22.5). But in any case, I agree with you that we need to discuss this mo= re thoroughly. Or, at indicate that the stateful issues draft is mostly abo= ut IA_NA + IA_PD and leave IA_TA "out" (perhaps taken up for 3315bis work).= But I suspect best to address it in this document. Considering these, I wonder it may make sense to handle different IAs in dedicated different states, but still in the same single DHCPv6 "session". For example, once a specific server is chosen after a Solicit-Advertise (+ possibly Request-Reply) exchange, each IA is maintained in its own state. Some may involve renewal process, and not-yet-assigned IAs can be Request-ed again after some reasonable delay. One tricky case with this approach is, though, when the server stops responding to Renew and an IA needs Rebind. We then need to consider what to do with other IAs. I'm not necessarily insisting on this is clearly better than the currently described approach in the draft, but my main point is that pros and cons are not so obvious (to me) and we'll probably need some more discussion at this level. BV> I'll have to think about this some more, but I think IA_TA are a bit se= parate and should be more independent than the IA_NA/IA_PD (for things like= the Cable home gateways). Some specific comments (mostly minor) on the draft text follow: - Section 4.1: shouldn't this SHOULD be a "MUST"? when not all IA option types are being offered. A client SHOULD ignore an Advertise message when no bindings at all are being offered. Since in the proposed replace text it states: The client MUST ignore any Advertise message that contains no bindings (if only IA_NA and/or IA_TA options were requested, BV> I think we should revisit this now that SOLMAX RFC (7083) is out as thi= s changes this text anyway. When this was written, SOLMAX was still a draft= and thus wasn't considered. But the updated text now should include the RF= C 7083 change -- see section 6 of RFC 7083. - In Section 4.4 With: At time T1 for an IA, the client initiates a Renew/Reply message exchange to extend the lifetimes on any addresses in the IA. The client includes an IA option with all addresses currently assigned to the IA in its Renew message. The client also includes an IA option for each binding it desires but has been unable to obtain. Should phrases like "any addresses" be generalized so they'll be applicable to other types of stateful resources? From the replacement of "available addresses" with "available options" in the proposed text in Section 4.1, I thought such generalization was one goal of the replacement text. Same sense of comments apply to some other places of the draft (e.g., in the "With" text of Section 4.5). BV> Yes, good catch - we need to replace "addresses" with something more ge= neric. Perhaps we can use the term "resources"? Or leases? - Also in Section 4.4: s/records/returns/? If the server cannot find a client entry for the IA the server creates the bindings for that client according to the server's policy and configuration information and records the IAs and other information requested by the client. BV> I think this "records" refers to the fact that server must record this = information? Note that as the server didn't find anything, it needs to stor= e this if it can provide the client the addresses that it claims to be usin= g (because of the Renew). and s/which is does/which it does/? BV> Yes, this should be fixed. these IAs. However, it MUST limit the frequency at which is does this to no more often than the renewal frequency. -- JINMEI, Tatuya From nobody Thu Feb 13 10:11:38 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C886B1A02F8 for ; Thu, 13 Feb 2014 10:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.922 X-Spam-Level: * X-Spam-Status: No, score=1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTzAVht0ARN8 for ; Thu, 13 Feb 2014 10:11:32 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 56EB81A039D for ; Thu, 13 Feb 2014 10:11:29 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hi5so3659628wib.5 for ; Thu, 13 Feb 2014 10:11:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=BlPeEV8QHF6/ufFk8NL6kstToAZz5081ggbmijl+U+A=; b=vT3XxSOrwEeoWqC35Hxw7AtgwHIl5gMye7Xoz2pXNocdA8XcsjIk9l+rNoYiuFZOvg aN7pBc4kQBXOIcvZA5OxWUXd01QqH8ic2Zfe1vqHSXH+1NsXXAw8I5t3/MbtuGjGbKhO iEIxbOky2CS52u7GW2hchXiI7Zg0O494QVLkZbW1B1fNnzBnG0kkHk43Mu0tMV0W8CFi Nxlp10Dd2fapjcI2RsemcdiEfAv0oDwnwW5PiSQrt1aqM549DtMirvk+ynIIOGBqCZdg 7JkwFTRiqbTgryNl6w08Kjsv60aa/YlOMm47f0lz2QKCNlI5hsA6p7z/XqfIfxbsVoDj +7iw== MIME-Version: 1.0 X-Received: by 10.180.24.227 with SMTP id x3mr3743833wif.41.1392315087640; Thu, 13 Feb 2014 10:11:27 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Thu, 13 Feb 2014 10:11:27 -0800 (PST) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AE665F6@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1AE665F6@xmb-rcd-x04.cisco.com> Date: Thu, 13 Feb 2014 10:11:27 -0800 X-Google-Sender-Auth: JU0eYXukhzNHsLthCi2kZL88yi4 Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/F8lyjYc4mH6ClZmfdQHcnMm0YzQ Cc: "dhcwg@ietf.org" , "draft-ietf-dhc-dhcpv6-stateful-issues@tools.ietf.org" Subject: Re: [dhcwg] comments on draft-ietf-dhc-dhcpv6-stateful-issues-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:11:37 -0000 At Wed, 12 Feb 2014 21:56:20 +0000, "Bernie Volz (volz)" wrote: > - I agree that it's a good idea to clarify/generalize the > concept of IA so we can handle multiple types of IAs at the same > time. But at the same time, I wonder for what a DHCP client would > want to request both IA_NA (or IA_TA) and IA_PD at the same time. > > BV> Home gateways (such in Cable, DOCSIS) typically do request an IA_NA a= nd IA_PD - the IA_NA is for use by the gateway itself whereas the IA_PD is = for the prefix within the home (typically stateless is used within the home= ). Ah, okay. Depending on the level of generalization of this document (see below), it may help if the example usage is mentioned. > - I'm not sure if it's the best approach to consider all types of IAs > as a set (if I understand it correctly, that's what this draft > basically proposes, right?). For example, assume a client wants to be > assigned IA_NA and IA_TA but ends up with accepting an Advertise > only containing IA_NA. [...] > > BV> The IA_NA/IA_TA case was actually "probably" already handled in RFC 3= 315 though I suspect we could improve this. This is more about interacting = with IA_PD. The case where IA_TAs aren't provided just means that the clien= t won't have any DHCP assigned temporary addresses and may either generate = its own (if allowed) or will be restricted from using temporary addresses. = An IA_TA is more likely requested on demand or periodically when the previo= us one becomes non-preferred. This is probably a case where a separate DHCP= v6 transaction is warranted and appropriate. > > BV> I agree though that we should expand the document to discuss this a b= it more - again, the focus of the work was really IA_NA + IA_PD. Okay, but this particular topic I simply chose IA_NA and IA_TA is just an example pair of IA_xx and IA_yy. The same question still applies. Now, however, as you clarified the main focus: if we're basically only concerned about the pair of IA_NA and IA_PD, I guess one possibility is to focus on that specific pair, rather than try to generalize the concept. In general it should be better if we can introduce a general concept of IA_xx's, explain everything in the generalized context and the case of IA_NA and IA_PD can be just one application of it. But, as the example of IA_TA case shows, the generalization will require considerations on more tricky cases. I'm not pushing a specific way, but IMO I'd either - try full generalization that's basically applicable to any current and future IA_xx's, or - just focus on the specific case of IA_NA + IA_PD, exploiting the fact of specialization (if that's helpful) In that sense the current shape of the draft seems to be still incomplete. > BV> We might even propose to DEPRECATE IA_TA as there's probably little v= alue in it for DHCPv6 assigned addresses. This grew out of the original pri= vacy concerns for EUI-64 mac address based addresses in IPv6 and DHCPv6 ass= igned addresses shouldn't normally have these privacy concerns (you might g= et the same address each time you connect at work, but that won't be relate= d to the one that you get at home or when in your favorite coffee shop). Possibly, but I think that would be beyond the scope of this discussion; even if we can assume we deprecate IA_TA, "the full generalization" approach would still require considerations on such deviant type of IAs to provide sensible abstraction level. > - (Slightly related to the previous point) The idea of considering > T1/T2 to be "protocol timers" (per Section 4.3) is not really > well-applicable to IA_TA since IA_TA is inherently free from > renewal. We could treat IA_TA as a special case for the general > concept of "protocol timers", but if we are trying to generalize the > concept of "stateful resources", I suspect we should rather expect > such exceptional cases. > > BV> Surprising RFC 3315 DOES allow IA_TA to be renewed (see RFC 3315, sec= tion 22.5). But in any case, I agree with you that we need to discuss this = more thoroughly. Or, at indicate that the stateful issues draft is mostly a= bout IA_NA + IA_PD and leave IA_TA "out" (perhaps taken up for 3315bis work= ). But I suspect best to address it in this document. Ah, okay (about the renewability), but actually that was not the main point here. I should have said IA_TA does not have T1/T2 (so it'll be tricky to define T1/T2 as protocol timers). And, yes, just focusing on IA_NA + IA_PD is one option (see above). > Some specific comments (mostly minor) on the draft text follow: > > - Section 4.1: shouldn't this SHOULD be a "MUST"? > > when not all IA option types are being offered. A client SHOULD > ignore an Advertise message when no bindings at all are being > offered. > > Since in the proposed replace text it states: > > The client MUST ignore any Advertise message that contains no > bindings (if only IA_NA and/or IA_TA options were requested, > > BV> I think we should revisit this now that SOLMAX RFC (7083) is out as t= his changes this text anyway. When this was written, SOLMAX was still a dra= ft and thus wasn't considered. But the updated text now should include the = RFC 7083 change -- see section 6 of RFC 7083. Hmm, I'm not sure if we are on the same page. I just tried to point out that the draft uses different keywords (SHOULD and MUST) to explain essentially the same thing and they should be consistent (so this is more about an editorial matter). > - In Section 4.4 > > With: > > At time T1 for an IA, the client initiates a Renew/Reply message > exchange to extend the lifetimes on any addresses in the IA. The > client includes an IA option with all addresses currently assigned > to the IA in its Renew message. The client also includes an IA > option for each binding it desires but has been unable to obtain. > > Should phrases like "any addresses" be generalized so they'll be > applicable to other types of stateful resources? From the > replacement of "available addresses" with "available options" in the > proposed text in Section 4.1, I thought such generalization was one > goal of the replacement text. Same sense of comments apply to some > other places of the draft (e.g., in the "With" text of Section 4.5). > > BV> Yes, good catch - we need to replace "addresses" with something more = generic. Perhaps we can use the term "resources"? Or leases? I'd prefer resources over leases between these, as a "lease" sounds like a different level of term (it's the available duration for the assigned address/resource/whatever, while we are thinking about the assigned "thing" here). But there may be other better term. I don't have a particular preference. > - Also in Section 4.4: s/records/returns/? > > If the server cannot find a client entry for the IA the server > creates the bindings for that client according to the server's > policy and configuration information and records the IAs and > other information requested by the client. > > BV> I think this "records" refers to the fact that server must record thi= s information? Note that as the server didn't find anything, it needs to st= ore this if it can provide the client the addresses that it claims to be us= ing (because of the Renew). Hmm, I thought in this case the IAs in "records the IAs" mean other IAs than that triggers the Renew. Also, if this is really "records" and means the IA that triggers the Renew, why is this plural (the IAs) while the first occurrence of "IA" is singular? And, even on a closer look, I have some more questions...in "If the server cannot find a client entry for the IA", which IA (there can be multiple of it because of the extension) is it? If the Renew contains IA1 and IA2 (e.g., the former triggers Renew due to T1 expiration and IA2 is not assigned yet), is it possible that "the server cannot find a client entry for IA1" but "the server *can* find a client entry for IA2"? If yes, what should happen in this case? Note, again, that we don't have to be bothered with these in the possible alternative approach I mentioned (once the server is chosen, different IAs are handled separately). -- JINMEI, Tatuya From nobody Thu Feb 13 11:53:19 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B391C1A0468 for ; Thu, 13 Feb 2014 11:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpeHGRaiHRpA for ; Thu, 13 Feb 2014 11:53:08 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7C59E1A045B for ; Thu, 13 Feb 2014 11:53:08 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id v10so10980135pde.0 for ; Thu, 13 Feb 2014 11:53:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=muHNmFW9kNFSRQCVwS8TKZuOSh5uXeaewQId1mqK3Uk=; b=XBvq+TxyDBgDl8Vm8tn4JLlIC87/4verJE86xwaRnEmSWXJD/32nIyBZTnDYgXs/8l tKTDS3oqfwBW211UuiVh0suA+7qn7MATlH47YK8Rx7/FzSA4Z2zpfmkTE5P2WUspIEkD 0+us5KPOe1GDP6o0yxx7bjbXtWeI2AyTPhp31CYanf55q3Db4bZuLAUVDabX2Mtxk78G jiR5sHv2/dvFmkT2bSXyETJsPKzBBIcCqW15MryQHvasbob+wMqetap8AHUAtIqdntwN J2dbDe0PNJ9pstpRjxKnLv8jfbgkn0q06un+OIbbcBGCZLKD2TWv4D6StrIoRG8A7oZC IKrQ== MIME-Version: 1.0 X-Received: by 10.66.221.199 with SMTP id qg7mr3959370pac.88.1392321187127; Thu, 13 Feb 2014 11:53:07 -0800 (PST) Received: by 10.70.1.70 with HTTP; Thu, 13 Feb 2014 11:53:07 -0800 (PST) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AE64F11@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1AE1EEB5@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AE64F11@xmb-rcd-x04.cisco.com> Date: Thu, 13 Feb 2014 20:53:07 +0100 Message-ID: From: Wojciech Dec To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/2CAqYJGauQYyS_n01lO4xd_mgl8 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 19:53:12 -0000 Hi, on re-reading the draft I have one question, perhaps obvious to the authors, about a technical point that deserves to be clarified: What is the expected behaviour for the DHCPv4/DHCPv6 server in terms of selecting the IPv4 address scope? RFC 2131 gives the following SHOULD: "A new address allocated from the server's pool of available addresses; the address is selected based on the subnet from which the message was received (if 'giaddr' is 0) or on the address of the relay agent that forwarded the message ('giaddr' when not 0)." This draft doesn't mention anything about giaddr, so it's rather ambivalent whether the relay agent inserts any giaddr and what is the SHOULD behaviour of the server, etc. Thanks, Wojciech. On 11 February 2014 22:56, Bernie Volz (volz) wrote: > This document did pass the WGLC but we had been waiting for the v4configu= ration draft, which has passed. > > I believe (though need to confirm with the authors) that the 04 draft the= y published on Jan 17, 2014 incorporates all of the comments from the last = call. > > We will shortly send this off to advance (we expect to send this and the = v4configuration draft about the same time). > > - Bernie > > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (vol= z) > Sent: Tuesday, January 14, 2014 4:26 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv= 6-03 > > Hi: > > We've left this WGLC open pending the last call on the v4configuration dr= aft. The authors of the v4configuration draft have been working on updating= it and should be submitting it shortly, at which time we will start the WG= LC for it. We will then close the last calls for both documents (dhcpv4-ove= r-dhcpv6 and v4configuration) at the same time. > > Sorry for the delay but as the two documents are closely related, we feel= it is best to hold off until both can be reviewed. > > - Bernie > > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski > Sent: Monday, December 16, 2013 9:58 AM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv= 6-03 - Respond by Dec 9, 2013 > > On 16.12.2013 15:40, Simon Perreault wrote: >> Le 2013-12-14 10:10, Bernie Volz (volz) a =E9crit : >>> WGLC on the related draft-ietf-dhc-v4configuration-03 is in progress >> >> Is this true? I can't find the announcement, and the datatracker >> doesn't show the draft as being in WGLC... > No, that was a mistake. Bernie and I exchanged preliminary WGLC announcem= ent text, but due to the discussion about dhcpv4-over-dhcpv6 we still haven= 't sent it out. So no - there is no WGLC on v4configuration yet, but there = likely will be in the next couple days. > It will be long enough so people who take holiday + new year vacation wil= l be able to get back and post their comments when they get back in January= . > > Tomek > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Thu Feb 13 12:07:04 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C601A041E for ; Thu, 13 Feb 2014 12:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I62yfaBHdbkT for ; Thu, 13 Feb 2014 12:06:59 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 572D21A0441 for ; Thu, 13 Feb 2014 12:06:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4865; q=dns/txt; s=iport; t=1392322018; x=1393531618; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4m2+nw3Ew3emAvzVuLC24JfC3SVi+30mu+mZ5TjPgso=; b=R+47FHL2/LHTHh9u8TND/HHwiqGXVNhqdk/+bzM5fCMZOIUmnjcZ0x5F ZqdbGHNnqsAHlkVDrEdfhBlBgxlDl+4VKnj3Sp0xeV2wpcLkFTs1eJy1+ qZMXxgIOHHe+2YZ01etEpuVGBGbMt/u2R0+sYecRmThUZY8V7AG+qvLbh 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAAEl/VKtJXG+/2dsb2JhbABZgwY4V79OgRoWdIIlAQEBBAEBAWsLDAQCAQgOAwQBAQEKHQchBgsUCQgBAQQOBQiHaQMRDb8hDYg8EwSMX4FpMQcGgx6BFASJEI0wjkqFRYMtgio X-IronPort-AV: E=Sophos;i="4.95,840,1384300800"; d="scan'208";a="303913502" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 13 Feb 2014 20:06:58 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1DK6vZf010610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 20:06:57 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 14:06:57 -0600 From: "Bernie Volz (volz)" To: Wojciech Dec Thread-Topic: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 Thread-Index: Ac8RbvjnR7wHzR7iTQy6lhZdhZEp8gWBDePwAG0UQoAADGMrgA== Date: Thu, 13 Feb 2014 20:06:56 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE686D3@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1AE1EEB5@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AE64F11@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/GVnCAnUyiIV9cbHiJvIhz3_ySrk Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:07:02 -0000 As I see it there are two basic ways to handle this: 1. If the server is a 'special' 4o6 server which handles these DHCPv4 packe= ts directly, it would use the IPv6 source address or Relay-Forw link-addres= s as a lookup to map to a v4 subnet to use. This is similar to how a v4 ser= ver uses the interface on which giaddr=3D0.0.0.0 packets are received. 2. If the 4o6 server will forward this to a normal DHCPv4 server, it would = act as a relay and add a giaddr (to get back the packet) and option 82, usi= ng the link-selection option-82 suboption to supply the v4 subnet informati= on similar to the processing in (1). Likely the circuit-id or remote-id sub= option (or other option-82 suboption) would be used to store enough to be u= sed when the response is DHCPv4 received (minus the giaddr/option-82 inform= ation) to get the DHCPv6 packet back to the client. Note that this addition= al information may just be some kind of hash to the 'saved' state to return= the packet to the client. (It is also possible to use variants of 1 and 2.) - Bernie -----Original Message----- From: Wojciech Dec [mailto:wdec.ietf@gmail.com]=20 Sent: Thursday, February 13, 2014 2:53 PM To: Bernie Volz (volz) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-= 03 Hi, on re-reading the draft I have one question, perhaps obvious to the authors= , about a technical point that deserves to be clarified: What is the expect= ed behaviour for the DHCPv4/DHCPv6 server in terms of selecting the IPv4 ad= dress scope? RFC 2131 gives the following SHOULD: "A new address allocated from the server's pool of available addresses; the address is selected based on the subnet from which the message was received (if 'giaddr' is 0) or on the address of the relay agent that forwarded the message ('giaddr' when not 0)." This draft doesn't mention anything about giaddr, so it's rather ambivalent= whether the relay agent inserts any giaddr and what is the SHOULD behaviou= r of the server, etc. Thanks, Wojciech. On 11 February 2014 22:56, Bernie Volz (volz) wrote: > This document did pass the WGLC but we had been waiting for the v4configu= ration draft, which has passed. > > I believe (though need to confirm with the authors) that the 04 draft the= y published on Jan 17, 2014 incorporates all of the comments from the last = call. > > We will shortly send this off to advance (we expect to send this and the = v4configuration draft about the same time). > > - Bernie > > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz=20 > (volz) > Sent: Tuesday, January 14, 2014 4:26 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] Results of WGLC for=20 > draft-ietf-dhc-dhcpv4-over-dhcpv6-03 > > Hi: > > We've left this WGLC open pending the last call on the v4configuration dr= aft. The authors of the v4configuration draft have been working on updating= it and should be submitting it shortly, at which time we will start the WG= LC for it. We will then close the last calls for both documents (dhcpv4-ove= r-dhcpv6 and v4configuration) at the same time. > > Sorry for the delay but as the two documents are closely related, we feel= it is best to hold off until both can be reviewed. > > - Bernie > > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek=20 > Mrugalski > Sent: Monday, December 16, 2013 9:58 AM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] Results of WGLC for=20 > draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013 > > On 16.12.2013 15:40, Simon Perreault wrote: >> Le 2013-12-14 10:10, Bernie Volz (volz) a =E9crit : >>> WGLC on the related draft-ietf-dhc-v4configuration-03 is in progress >> >> Is this true? I can't find the announcement, and the datatracker=20 >> doesn't show the draft as being in WGLC... > No, that was a mistake. Bernie and I exchanged preliminary WGLC announcem= ent text, but due to the discussion about dhcpv4-over-dhcpv6 we still haven= 't sent it out. So no - there is no WGLC on v4configuration yet, but there = likely will be in the next couple days. > It will be long enough so people who take holiday + new year vacation wil= l be able to get back and post their comments when they get back in January= . > > Tomek > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Thu Feb 13 12:55:47 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADF01A0422 for ; Thu, 13 Feb 2014 12:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKPTS3OqH-wB for ; Thu, 13 Feb 2014 12:55:41 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EBF9A1A0497 for ; Thu, 13 Feb 2014 12:55:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12326; q=dns/txt; s=iport; t=1392324941; x=1393534541; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SarXOpCruzdT5oij02bapQvFyH6C4aOc2G5YgSHPk0A=; b=DKP5uN2F0uJ+nLA6tDbceHy1mLYamI4zzz5LkOVKu2dc9ZagZIkpImSC hfvIWSszKlKQi3otgftln6HNPLCOMQMvHCKakwJJSNfgpj7YJ//kPiQ5l TO4EkMdk9QbuVdtC+YDAzkyoraXo3asgdjmFRsx5llpCgx6DjIn+aTBcF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFABww/VKtJXG8/2dsb2JhbABZgwiBDYMDphqBd5F9gRsWAXSDfQEBAQMBIQFXBQcEAgEIEQQBAQIDBh0CAwIhERQJCAIEDgUIh2gDCQiKDJtkAZE4DYg7F4Emi1mBOycmBgUHBoJlOIETAQOWK45FhTqDK4FoJB4 X-IronPort-AV: E=Sophos;i="4.95,840,1384300800"; d="scan'208";a="300932408" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 13 Feb 2014 20:55:40 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1DKtdrh015238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 20:55:39 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 14:55:39 -0600 From: "Bernie Volz (volz)" To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= Thread-Topic: [dhcwg] comments on draft-ietf-dhc-dhcpv6-stateful-issues-05 Thread-Index: AQHPKDj0ZdbcypmIR0uf6QO4SzfBEZqyJKXwgAG9hID//5yV8A== Date: Thu, 13 Feb 2014 20:55:38 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE688F6@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1AE665F6@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.20] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/U6NMpt5YEti8VI1OARLT-cFjWxQ Cc: "dhcwg@ietf.org" , "draft-ietf-dhc-dhcpv6-stateful-issues@tools.ietf.org" Subject: Re: [dhcwg] comments on draft-ietf-dhc-dhcpv6-stateful-issues-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:55:46 -0000 Hi: First, I think it will be difficult to provide a completely generalized app= roach to processing of the IAs since IA_TAs are fundamentally very differen= t as they are not generally intended to be renewed and hence have no T1/T2.= Also, we have no idea what future IA_* options may be defined and what cha= racteristics they may have. IA_TAs may be needed when other IA_* options ar= e not ready to be renewed. It is interesting that as RFC 3315 defined both IA_NA and IA_TA, it implies= from what you have indicated to have failed in handling these appropriatel= y? I don't know if that has been confirmed by implementation experience or = not; it may be that IA_TAs are not widely "used"?=20 We have also been discussing terminology (addresses vs resources vs leases)= . As this document is attempting to update text in RFC 3315, it has stuck t= o using RFC 3315 terminology. Thus, I think replacing "addresses" with some= thing else is best left to the RFC 3315bis work where we merge RFC 3315/363= 3. That is one reason why all of the text that updates RFC 3315 has avoided= introducing "delegated prefixes", "IA_PD", and anything not in RFC 3315 - = we are carefully updating the text without explicitly introducing PD materi= al. I forgot about that issue when I responded earlier. (We do have an open= issue to define the terminology to be used in 3315bis.) --- [Section 4.1] >Hmm, I'm not sure if we are on the same page. I just tried to point >out that the draft uses different keywords (SHOULD and MUST) to >explain essentially the same thing and they should be consistent (so >this is more about an editorial matter). OK, sorry I misunderstood. I am not sure when and why that difference crept= in (we will use MUST in both places). RFC 7083 does expand on the "MUST ig= nore" so I should at least add a note in the descriptive text about the 708= 3 requirements. >- just focus on the specific case of IA_NA + IA_PD, exploiting the > fact of specialization (if that's helpful) I think I will favor this approach as this was about IA_NA/IA_PD interactio= n and not about IA_NA/IA_TA. Again, the RFC 3315 text changes are a bit tri= cky since it is limited to using RFC 3315 terminology/context. If you feel there are issues with IA_NA/IA_TA, perhaps you can clarify thos= e and we can treat them as an Errata to RFC 3315 or perhaps work on another= document? I am not opposed to including in Stateful Issues if you can prov= ide some clear list of issues and proposed fixes? Regarding the Section 4.4 issues with the replacement text, I will need to = think about that some more and perhaps work in more of the text from the Re= quest processing (18.2.1). The intent here is to allow new IAs in Renew and= have the server processing them much like it does for a Request - so borro= wing from 18.2.1 will help. I wonder whether saying something like (for rep= lacement of Section 18.2.3): "If the server cannot find a client entry for an IA, the server SHOULD proc= ess the IA as it would for a Request (see section 18.2.1), except that: 1. The server SHOULD use any client specified addresses that it can assign = to the client. 2. Any client specified addresses that are not appropriate for the link to = which the client is attached or cannot be assigned to the client MUST be re= turned to the client with lifetimes of 0." Would that be acceptable? It is indeed the intent. - Bernie -----Original Message----- From: jinmei.tatuya@gmail.com [mailto:jinmei.tatuya@gmail.com] On Behalf Of= ???? Sent: Thursday, February 13, 2014 1:11 PM To: Bernie Volz (volz) Cc: draft-ietf-dhc-dhcpv6-stateful-issues@tools.ietf.org; dhcwg@ietf.org Subject: Re: [dhcwg] comments on draft-ietf-dhc-dhcpv6-stateful-issues-05 At Wed, 12 Feb 2014 21:56:20 +0000, "Bernie Volz (volz)" wrote: > - I agree that it's a good idea to clarify/generalize the > concept of IA so we can handle multiple types of IAs at the same > time. But at the same time, I wonder for what a DHCP client would > want to request both IA_NA (or IA_TA) and IA_PD at the same time. > > BV> Home gateways (such in Cable, DOCSIS) typically do request an IA_NA a= nd IA_PD - the IA_NA is for use by the gateway itself whereas the IA_PD is = for the prefix within the home (typically stateless is used within the home= ). Ah, okay. Depending on the level of generalization of this document (see b= elow), it may help if the example usage is mentioned. > - I'm not sure if it's the best approach to consider all types of IAs > as a set (if I understand it correctly, that's what this draft > basically proposes, right?). For example, assume a client wants to be > assigned IA_NA and IA_TA but ends up with accepting an Advertise > only containing IA_NA. [...] > > BV> The IA_NA/IA_TA case was actually "probably" already handled in RFC 3= 315 though I suspect we could improve this. This is more about interacting = with IA_PD. The case where IA_TAs aren't provided just means that the clien= t won't have any DHCP assigned temporary addresses and may either generate = its own (if allowed) or will be restricted from using temporary addresses. = An IA_TA is more likely requested on demand or periodically when the previo= us one becomes non-preferred. This is probably a case where a separate DHCP= v6 transaction is warranted and appropriate. > > BV> I agree though that we should expand the document to discuss this a b= it more - again, the focus of the work was really IA_NA + IA_PD. Okay, but this particular topic I simply chose IA_NA and IA_TA is just an e= xample pair of IA_xx and IA_yy. The same question still applies. Now, however, as you clarified the main focus: if we're basically only conc= erned about the pair of IA_NA and IA_PD, I guess one possibility is to focu= s on that specific pair, rather than try to generalize the concept. In gen= eral it should be better if we can introduce a general concept of IA_xx's, = explain everything in the generalized context and the case of IA_NA and IA_= PD can be just one application of it. But, as the example of IA_TA case sh= ows, the generalization will require considerations on more tricky cases. I'm not pushing a specific way, but IMO I'd either - try full generalization that's basically applicable to any current and future IA_xx's, or - just focus on the specific case of IA_NA + IA_PD, exploiting the fact of specialization (if that's helpful) In that sense the current shape of the draft seems to be still incomplete. > BV> We might even propose to DEPRECATE IA_TA as there's probably little v= alue in it for DHCPv6 assigned addresses. This grew out of the original pri= vacy concerns for EUI-64 mac address based addresses in IPv6 and DHCPv6 ass= igned addresses shouldn't normally have these privacy concerns (you might g= et the same address each time you connect at work, but that won't be relate= d to the one that you get at home or when in your favorite coffee shop). Possibly, but I think that would be beyond the scope of this discussion; ev= en if we can assume we deprecate IA_TA, "the full generalization" approach = would still require considerations on such deviant type of IAs to provide s= ensible abstraction level. > - (Slightly related to the previous point) The idea of considering > T1/T2 to be "protocol timers" (per Section 4.3) is not really > well-applicable to IA_TA since IA_TA is inherently free from > renewal. We could treat IA_TA as a special case for the general > concept of "protocol timers", but if we are trying to generalize the > concept of "stateful resources", I suspect we should rather expect > such exceptional cases. > > BV> Surprising RFC 3315 DOES allow IA_TA to be renewed (see RFC 3315, sec= tion 22.5). But in any case, I agree with you that we need to discuss this = more thoroughly. Or, at indicate that the stateful issues draft is mostly a= bout IA_NA + IA_PD and leave IA_TA "out" (perhaps taken up for 3315bis work= ). But I suspect best to address it in this document. Ah, okay (about the renewability), but actually that was not the main point= here. I should have said IA_TA does not have T1/T2 (so it'll be tricky to= define T1/T2 as protocol timers). And, yes, just focusing on IA_NA + IA_P= D is one option (see above). > Some specific comments (mostly minor) on the draft text follow: > > - Section 4.1: shouldn't this SHOULD be a "MUST"? > > when not all IA option types are being offered. A client SHOULD > ignore an Advertise message when no bindings at all are being > offered. > > Since in the proposed replace text it states: > > The client MUST ignore any Advertise message that contains no > bindings (if only IA_NA and/or IA_TA options were requested, > > BV> I think we should revisit this now that SOLMAX RFC (7083) is out as t= his changes this text anyway. When this was written, SOLMAX was still a dra= ft and thus wasn't considered. But the updated text now should include the = RFC 7083 change -- see section 6 of RFC 7083. Hmm, I'm not sure if we are on the same page. I just tried to point out th= at the draft uses different keywords (SHOULD and MUST) to explain essential= ly the same thing and they should be consistent (so this is more about an e= ditorial matter). > - In Section 4.4 > > With: > > At time T1 for an IA, the client initiates a Renew/Reply message > exchange to extend the lifetimes on any addresses in the IA. The > client includes an IA option with all addresses currently assigned > to the IA in its Renew message. The client also includes an IA > option for each binding it desires but has been unable to obtain. > > Should phrases like "any addresses" be generalized so they'll be > applicable to other types of stateful resources? From the > replacement of "available addresses" with "available options" in the > proposed text in Section 4.1, I thought such generalization was one > goal of the replacement text. Same sense of comments apply to some > other places of the draft (e.g., in the "With" text of Section 4.5). > > BV> Yes, good catch - we need to replace "addresses" with something more = generic. Perhaps we can use the term "resources"? Or leases? I'd prefer resources over leases between these, as a "lease" sounds like a = different level of term (it's the available duration for the assigned addre= ss/resource/whatever, while we are thinking about the assigned "thing" here= ). But there may be other better term. I don't have a particular preferen= ce. > - Also in Section 4.4: s/records/returns/? > > If the server cannot find a client entry for the IA the server > creates the bindings for that client according to the server's > policy and configuration information and records the IAs and > other information requested by the client. > > BV> I think this "records" refers to the fact that server must record thi= s information? Note that as the server didn't find anything, it needs to st= ore this if it can provide the client the addresses that it claims to be us= ing (because of the Renew). Hmm, I thought in this case the IAs in "records the IAs" mean other IAs tha= n that triggers the Renew. Also, if this is really "records" and means the IA that triggers the Renew, why is this plural (the IAs) whil= e the first occurrence of "IA" is singular? And, even on a closer look, I = have some more questions...in "If the server cannot find a client entry for= the IA", which IA (there can be multiple of it because of the extension) i= s it? If the Renew contains IA1 and IA2 (e.g., the former triggers Renew d= ue to T1 expiration and IA2 is not assigned yet), is it possible that "the = server cannot find a client entry for IA1" but "the server *can* find a cli= ent entry for IA2"? If yes, what should happen in this case? Note, again, that we don't have to be bothered with these in the possible a= lternative approach I mentioned (once the server is chosen, different IAs a= re handled separately). -- JINMEI, Tatuya From nobody Thu Feb 13 23:07:26 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7441A0174; Thu, 13 Feb 2014 23:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDCISW1o4DVG; Thu, 13 Feb 2014 23:07:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 963F11A016D; Thu, 13 Feb 2014 23:07:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214070713.4863.21277.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 23:07:13 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/lVSo0w3TAulAlfd86GhqplhgNT0 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-access-network-identifier-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 07:07:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Access-Network-Identifier Option in DHCP Authors : Shwetha Bhandari Sri Gundavelli Jouni Korhonen Mark Grayson Filename : draft-ietf-dhc-access-network-identifier-02.txt Pages : 18 Date : 2014-02-13 Abstract: This document specifies the format and mechanism that is to be used for encoding access network identifiers in DHCPv4 and DHCPv6 messages by defining new access network identifier options and sub-options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-access-network-identifier-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-access-network-identifier-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 00:11:56 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4F31A0144; Fri, 14 Feb 2014 00:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3sh47-ZaRS8; Fri, 14 Feb 2014 00:11:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E8D1A0114; Fri, 14 Feb 2014 00:11:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214081150.10397.5126.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 00:11:50 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/7ZEunStR31oe23rrsXq7R4drHN8 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 08:11:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Secure DHCPv6 with Public Key Authors : Sheng Jiang Sean Shen Dacheng Zhang Filename : draft-ietf-dhc-sedhcpv6-01.txt Pages : 17 Date : 2014-02-14 Abstract: The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly spoofing attacks. This document analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6 mechanism for communication between DHCPv6 client and server. This mechanism is based on public/private key pairs. The authority of the sender may depend on either pre-configuration mechanism or Public Key Infrastructure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-sedhcpv6-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 09:36:46 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212D41A0370 for ; Fri, 14 Feb 2014 09:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KzAxobwAylW for ; Fri, 14 Feb 2014 09:36:37 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1171A0357 for ; Fri, 14 Feb 2014 09:36:22 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id l4so9495873lbv.38 for ; Fri, 14 Feb 2014 09:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9gI3bcQYP6gX/l/z0zTdL9gVmzg+2YxxFT2IW9zieOM=; b=tsPzyXHUuKKlviOeiBHe/BKFiSX+PrjiY3PO9fONaBRjb6j42lIKKF75uC/kKRgTO9 nptKzlz1agcH6ahpOCYXdv+VxshF6saTOFawj7C+SfwnSv04sPXjL8Xvm+kNir+9Zgqi p4uEfd8vCE0IWUYCGZrrfZSYyAIAQdJl2MLu9dASLWDLufqJyE/T2Dq2rdBPTigiYGzG nbZxuPfijuYT0RqwyHv6pZqquzjPgjR7WUVQgKkbc4SIhzB0lMKpu01TCH5pqlk0UyBi lFlZdcfR2C0Ds1KytLg9ie1f7UOWsA/zSylOgJVTzMVN0jUB8TqxCqtAEhx3GZjH+uH4 ef8A== MIME-Version: 1.0 X-Received: by 10.152.4.68 with SMTP id i4mr6169032lai.8.1392399380223; Fri, 14 Feb 2014 09:36:20 -0800 (PST) Received: by 10.114.170.193 with HTTP; Fri, 14 Feb 2014 09:36:20 -0800 (PST) In-Reply-To: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> References: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 11:36:20 -0600 Message-ID: From: Behcet Sarikaya To: Dhc Chairs Content-Type: multipart/alternative; boundary=089e01493d46719a3504f2613e83 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/wgRQ2OURT5dI_t8zEmgSlq87NJs Cc: "dhcwg@ietf.org" Subject: [dhcwg] Fwd: New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 17:36:39 -0000 --089e01493d46719a3504f2613e83 Content-Type: text/plain; charset=ISO-8859-1 Dear Chairs, We submitted a draft, see below for details. Please reserve a short slot in IETF 89. Note that this is a revised and renamed version of draft-sarikaya-dhc-vxlan-multicast-02. A new version of I-D, draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Name: draft-sarikaya-nvo3-dhc-vxlan-multicast Revision: 00 Title: DHCP Options for Configuring Multicast Addresses in VXLAN Document date: 2014-02-14 Group: Individual Submission Pages: 12 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt Status: https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-dhc-vxlan-multicast/ Htmlized: http://tools.ietf.org/html/draft-sarikaya-nvo3-dhc-vxlan-multicast-00 Abstract: This document defines DHCPv4 and DHCPv6 options for assigning multicast addresses for the Tunnel End Point in the Virtual eXtensible Local Area Network (VXLAN) environments. New DHCP options are defined which allow a VXLAN Tunnel End Point to request any source multicast address for the newly created virtual machine and possibly IPv4/IPv6 address(es) for the virtual machine. Regards, Frank & Behcet --089e01493d46719a3504f2613e83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Chairs,

We submitted a dr= aft, see below for details.
Please reserve a short slot in IETF 89= .

Note that this is a revised and renamed version of draft-sar= ikaya-dhc-vxlan-multicast-02.

A new version of I-D, draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-sarikaya-nvo3-dhc-vxlan-multicast
Revision: =A0 =A0 =A0 00
Title: =A0 =A0 =A0 =A0 =A0DHCP Options for Configuring Multicast Addresses = in VXLAN
Document date: =A02014-02-14
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A012
URL: =A0 =A0 =A0 =A0 =A0 =A0http://ww= w.ietf.org/internet-drafts/draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ie= tf.org/doc/draft-sarikaya-nvo3-dhc-vxlan-multicast/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/d= raft-sarikaya-nvo3-dhc-vxlan-multicast-00


Abstract:
=A0 =A0This document defines DHCPv4 and DHCPv6 options for assigning
=A0 =A0multicast addresses for the Tunnel End Point in the Virtual
=A0 =A0eXtensible Local Area Network (VXLAN) environments. =A0New DHCP opti= ons
=A0 =A0are defined which allow a VXLAN Tunnel End Point to request any
=A0 =A0source multicast address for the newly created virtual machine and =A0 =A0possibly IPv4/IPv6 address(es) for the virtual machine.



Regards,

Frank & Behcet



--089e01493d46719a3504f2613e83-- From nobody Fri Feb 14 10:02:37 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A6A1A0373 for ; Fri, 14 Feb 2014 10:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.922 X-Spam-Level: * X-Spam-Status: No, score=1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZgXysA4mq3i for ; Fri, 14 Feb 2014 10:02:30 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 954491A0383 for ; Fri, 14 Feb 2014 10:02:26 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id q58so8851409wes.21 for ; Fri, 14 Feb 2014 10:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=oKyQVFNK7hx7DqzlgTYq2mRxNlMmMKDeLoz+j8o/WmQ=; b=gd5gDFoEn5VYTXD9A8e9Lm+Poq3bOW4rufJ9xh8F/NKZpqiDO+uLjR+0jQO7/OWGLT inc1VAEPl491gQumg8EjWWCTJV/3NBaOBdJgh8aY4746lOTGXQf0TLb6U7Llt8Z74tRV JGnGlimqYTL8cjVNIW4X0wSFFTcrIO02gC6uNaKSyO12jY0jHCNSeW83/DdAUgwdNmYV BlWH6aYuMY3oi0AWwh1GmDRoUjHNiav9Za6TyBUgSURfPiIy26rGQ+EHpYHoH2xXgMjj UKVgnG8kk9tvTo4GHo+nhFSEnvhh3RFJoLrcRGhrvWC1RkJOron5jfQp3qzLxvFtcoua 5WuA== MIME-Version: 1.0 X-Received: by 10.180.24.134 with SMTP id u6mr2698233wif.41.1392400944349; Fri, 14 Feb 2014 10:02:24 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Fri, 14 Feb 2014 10:02:24 -0800 (PST) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AE688F6@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1AE665F6@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AE688F6@xmb-rcd-x04.cisco.com> Date: Fri, 14 Feb 2014 10:02:24 -0800 X-Google-Sender-Auth: YLrQYznUPw7rzahawzDe6zFywPo Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/i6y0DmYZfeRw78mezYDj55sT97s Cc: "dhcwg@ietf.org" , "draft-ietf-dhc-dhcpv6-stateful-issues@tools.ietf.org" Subject: Re: [dhcwg] comments on draft-ietf-dhc-dhcpv6-stateful-issues-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:02:32 -0000 (I'm now traveling and don't have much time for intensive discussion, so I'm providing some quick feedback). At Thu, 13 Feb 2014 20:55:38 +0000, "Bernie Volz (volz)" wrote: > First, I think it will be difficult to provide a completely generalized a= pproach to processing of the IAs since IA_TAs are fundamentally very differ= ent as they are not generally intended to be renewed and hence have no T1/T= 2. Also, we have no idea what future IA_* options may be defined and what c= haracteristics they may have. IA_TAs may be needed when other IA_* options = are not ready to be renewed. I tend to agree, and now that I understand the original intent of the draft is to clarify the paired use of IA_NA and IA_PD, I have no problem with focusing on this specific issue. > Regarding the Section 4.4 issues with the replacement text, I will need t= o think about that some more and perhaps work in more of the text from the = Request processing (18.2.1). The intent here is to allow new IAs in Renew a= nd have the server processing them much like it does for a Request - so bor= rowing from 18.2.1 will help. I wonder whether saying something like (for r= eplacement of Section 18.2.3): > > "If the server cannot find a client entry for an IA, the server SHOULD pr= ocess the IA as it would for a Request (see section 18.2.1), except that: > 1. The server SHOULD use any client specified addresses that it can assig= n to the client. > 2. Any client specified addresses that are not appropriate for the link t= o which the client is attached or cannot be assigned to the client MUST be = returned to the client with lifetimes of 0." > > Would that be acceptable? It is indeed the intent. Maybe. But I think I need to understand this in the bigger context of the expected operation on pairing IA_NA and IA_PD. Whether we generally expect "both are available or neither is" or whether it's completely okay if one is available but the other isn't, etc. -- jinmei From nobody Fri Feb 14 11:30:51 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532FA1A02AF for ; Fri, 14 Feb 2014 11:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfSm01VuCUBe for ; Fri, 14 Feb 2014 11:30:46 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 9251E1A0322 for ; Fri, 14 Feb 2014 11:30:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3659; q=dns/txt; s=iport; t=1392406244; x=1393615844; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4MWkDSo+ih5rIxoTRibz0XeINYdtlYOvds8Cp/sWlyc=; b=Q6Hy0p6o3TKBEKH3cRjX+CYJEhxPtVb7Ue7DDEozteS2qK5X4mqPmzyn HYj4MUKs+Oqb2Fu3lnH9ULmOl6yJ8iHC8jQPACsMVG+eqTJmsKO2RZVXJ PvhrNGt8FAm3lhTqk6NdqHBJBI4FT+mD3XcfLUk03mj6r8cL4sLyfOTz3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAFFu/lKtJV2Z/2dsb2JhbABZgwaBD4MCqB2UEIEXFnSCJQEBAQMBIQFXBQcEAgEIEQQBAQIDBh0CAwIhERQJCAIEDgUIh2kDCQiLHpt6AZlDDYgHF4EmizmBaSYLBwaCZjiBFAEDlkCOSoVFgy2CKg X-IronPort-AV: E=Sophos;i="4.95,846,1384300800"; d="scan'208";a="20562787" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 14 Feb 2014 19:30:43 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1EJUh2i019650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 19:30:43 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 13:30:43 -0600 From: "Bernie Volz (volz)" To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= Thread-Topic: [dhcwg] comments on draft-ietf-dhc-dhcpv6-stateful-issues-05 Thread-Index: AQHPKDj0ZdbcypmIR0uf6QO4SzfBEZqyJKXwgAG9hID//5yV8IAB8zgA//+yrwA= Date: Fri, 14 Feb 2014 19:30:42 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE72808@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1AE665F6@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AE688F6@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.159] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/h8gHXv9TBexiILCeSuN3lk9sYIg Cc: "dhcwg@ietf.org" , "draft-ietf-dhc-dhcpv6-stateful-issues@tools.ietf.org" Subject: Re: [dhcwg] comments on draft-ietf-dhc-dhcpv6-stateful-issues-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:30:49 -0000 >Maybe. But I think I need to understand this in the bigger context >of the expected operation on pairing IA_NA and IA_PD. Whether >we generally expect "both are available or neither is" or whether >it's completely okay if one is available but the other isn't, etc. The usual expectation is that both would be available. I think there may be= edge cases (misconfigurations) where this isn't the case and hence why han= dling it 'correctly' is desired. Perhaps some cable operators can shed more light on this? I think the core issues where: 1. What happens if something prevents the IA_NA and IA_PD from being provid= ed the 'client' initially. This may result in one not being available. (Not= e that IA_PD not being available is probably a more significant issue than = IA_NA; since home gateway and CMTS can communicate using link-local. Withou= t an address, some SP management capabilities might be restricted?) 2. What happens if the T1/T2 times on the IA_NA and IA_PD are different - w= hen renew happens, should both be renewed or just the one with the expired = time as this could result in two independent renewal transactions at some p= oint. I think we all want to have the clients use one transaction to update both = whenever possible. - Bernie -----Original Message----- From: jinmei.tatuya@gmail.com [mailto:jinmei.tatuya@gmail.com] On Behalf Of= ???? Sent: Friday, February 14, 2014 1:02 PM To: Bernie Volz (volz) Cc: dhcwg@ietf.org; draft-ietf-dhc-dhcpv6-stateful-issues@tools.ietf.org Subject: Re: [dhcwg] comments on draft-ietf-dhc-dhcpv6-stateful-issues-05 (I'm now traveling and don't have much time for intensive discussion, so I'= m providing some quick feedback). At Thu, 13 Feb 2014 20:55:38 +0000, "Bernie Volz (volz)" wrote: > First, I think it will be difficult to provide a completely generalized a= pproach to processing of the IAs since IA_TAs are fundamentally very differ= ent as they are not generally intended to be renewed and hence have no T1/T= 2. Also, we have no idea what future IA_* options may be defined and what c= haracteristics they may have. IA_TAs may be needed when other IA_* options = are not ready to be renewed. I tend to agree, and now that I understand the original intent of the draft= is to clarify the paired use of IA_NA and IA_PD, I have no problem with fo= cusing on this specific issue. > Regarding the Section 4.4 issues with the replacement text, I will need t= o think about that some more and perhaps work in more of the text from the = Request processing (18.2.1). The intent here is to allow new IAs in Renew a= nd have the server processing them much like it does for a Request - so bor= rowing from 18.2.1 will help. I wonder whether saying something like (for r= eplacement of Section 18.2.3): > > "If the server cannot find a client entry for an IA, the server SHOULD pr= ocess the IA as it would for a Request (see section 18.2.1), except that: > 1. The server SHOULD use any client specified addresses that it can assig= n to the client. > 2. Any client specified addresses that are not appropriate for the link t= o which the client is attached or cannot be assigned to the client MUST be = returned to the client with lifetimes of 0." > > Would that be acceptable? It is indeed the intent. Maybe. But I think I need to understand this in the bigger context of the = expected operation on pairing IA_NA and IA_PD. Whether we generally expect= "both are available or neither is" or whether it's completely okay if one = is available but the other isn't, etc. -- jinmei From nobody Fri Feb 14 12:38:13 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D0B1A040A; Fri, 14 Feb 2014 12:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bQ0WK_4I-f5; Fri, 14 Feb 2014 12:38:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2441A03C6; Fri, 14 Feb 2014 12:38:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214203804.24392.65857.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 12:38:04 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/wos0PcyBNyeS9LhvTEWG9kTnwuk Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:38:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Customizing DHCP Configuration on the Basis of Network Topology Authors : Ted Lemon Tomek Mrugalski Filename : draft-ietf-dhc-topo-conf-01.txt Pages : 14 Date : 2014-02-14 Abstract: DHCP servers have evolved over the years to provide significant functionality beyond that which is described in the DHCP base specifications. One aspect of this functionality is support for context-specific configuration information. This memo describes some such features and makes recommendations as to how they can be used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-topo-conf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-topo-conf-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-topo-conf-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 12:46:42 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591C71A03B9 for ; Fri, 14 Feb 2014 12:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KvP2gMMg6qZ for ; Fri, 14 Feb 2014 12:46:32 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 1751E1A0388 for ; Fri, 14 Feb 2014 12:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18587; q=dns/txt; s=iport; t=1392410790; x=1393620390; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=96248QVqd2LWVA1q6lCWUT0Fj1ywO53mRnCK6Xxswco=; b=agPV45biF7H6ehnwqVgODftvQJAfgdj6qPitkcPrK4r5r66aIdc+abq8 bM/iHdo8SuXXLXaT2028P7nditwBHnA2maV2dTt/T+FdG19NUK3d9ehTF oSHkaq+pm0yUjkEKO4HblzV5/tllUqSzV5kxSmmPD0yGeZnnqLcNe4+xw I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosGANF//lKtJV2c/2dsb2JhbABZgkJEOFe2WohVgRgWdIIlAQEBBC1FBQIQAgEIEQQBAQsdByERFAkIAgQBDQUIAYdoAxENwDYNiAcXjF+BaS0EBgGDJIEUBJZAgx6LLIVFgy2CKg X-IronPort-AV: E=Sophos; i="4.95,846,1384300800"; d="scan'208,217"; a="20593682" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 14 Feb 2014 20:46:29 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1EKkToF020995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 20:46:29 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 14:46:29 -0600 From: "Bernie Volz (volz)" To: "sarikaya@ieee.org" , Dhc Chairs Thread-Topic: New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt Thread-Index: AQHPKatLZhldDjj24E2PHlohRA8PqZq1Mr0A Date: Fri, 14 Feb 2014 20:46:28 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE72D20@xmb-rcd-x04.cisco.com> References: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.159] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AE72D20xmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/H9a1HtbXFa7o1ed6Rxz8-pj9Zkw Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:46:40 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AE72D20xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Behcet: Just so we can properly prioritize (though at present we seem to have suffi= cient time), is this intended to be an informational presentation, or do yo= u have issues to discuss/resolve? We'll give preference to those drafts tha= t have issues to discuss/resolve. Also, as this is now (I think) primarily targeted for the NVO3 (Network Vir= tualization Overlays) WG, is there anything of significance to discuss in D= HC - there does seem to be some server processing involved as the client su= pplied option triggers the server to return a specific multicast address. A few comments from a quick look at the document: 1. Why does the client set the address to 0 in the address option? Wh= y have the client include this option at all (server can just add it either= because the network identifier option is present or as client can request = in PRL/ORO)? 2. The option lengths are wrong? In DHCPv6 (& DHCPv4), the option len= gth covers just the data itself (not the option code and option type). 3. Why is the "VXLAN Identifier" apparently 3 bytes for the DHCPv6 op= tion and 4 bytes for the DHCPv4 option? What is the relationship between th= is VXLAN Identifier and the "24-bit Virtual Subnet Identifier (VSID)"? It d= oes state "Note that VSID is simlar to VNI" - but that is still something d= ifferent than the VXLAN Identifier (though even earlier is stated "VXLAN he= ader contains 24-bit VNI"). So I would guess this is 3 byte (octet) field a= nd this is the VNI? Why call it something else then? 4. There's no relay option ... perhaps that is intentional but can th= e client's "Network Identifier" option value be trusted? Would it make sens= e for a relay to provide this? Or is this something only the client would k= now and therefore it has to be trusted? Probably some of the above is because of my lack of understanding of this e= ntire space. - Bernie From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Sent: Friday, February 14, 2014 12:36 PM To: Dhc Chairs Cc: dhcwg@ietf.org Subject: Fwd: New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-mu= lticast-00.txt Dear Chairs, We submitted a draft, see below for details. Please reserve a short slot in IETF 89. Note that this is a revised and renamed version of draft-sarikaya-dhc-vxlan= -multicast-02. A new version of I-D, draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Name: draft-sarikaya-nvo3-dhc-vxlan-multicast Revision: 00 Title: DHCP Options for Configuring Multicast Addresses in VXLAN Document date: 2014-02-14 Group: Individual Submission Pages: 12 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-dhc= -vxlan-multicast-00.txt Status: https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-dhc-vx= lan-multicast/ Htmlized: http://tools.ietf.org/html/draft-sarikaya-nvo3-dhc-vxlan-mu= lticast-00 Abstract: This document defines DHCPv4 and DHCPv6 options for assigning multicast addresses for the Tunnel End Point in the Virtual eXtensible Local Area Network (VXLAN) environments. New DHCP options are defined which allow a VXLAN Tunnel End Point to request any source multicast address for the newly created virtual machine and possibly IPv4/IPv6 address(es) for the virtual machine. Regards, Frank & Behcet --_000_489D13FBFA9B3E41812EA89F188F018E1AE72D20xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Behcet:=

 <= /p>

Just so we can properly p= rioritize (though at present we seem to have sufficient time), is this inte= nded to be an informational presentation, or do you have issues to discuss/resolve? We’ll give preference to those drafts tha= t have issues to discuss/resolve.

 <= /p>

Also, as this is now (I t= hink) primarily targeted for the NVO3 (Network Virtualization Overlays) WG,= is there anything of significance to discuss in DHC – there does seem to be some server processing involved as the client supplied opt= ion triggers the server to return a specific multicast address.<= /span>

 <= /p>

A few comments from a qui= ck look at the document:

1. = ;      Why does the clie= nt set the address to 0 in the address option? Why have the client include = this option at all (server can just add it either because the network identifier option is present or as client can request in PRL/O= RO)?

2. = ;      The option length= s are wrong? In DHCPv6 (& DHCPv4), the option length covers just the da= ta itself (not the option code and option type).

3. = ;      Why is the “= ;VXLAN Identifier” apparently 3 bytes for the DHCPv6 option and 4 byt= es for the DHCPv4 option? What is the relationship between this VXLAN Identifier and the “24-bit Virtual Subnet Identifier (VSID)”? = It does state “Note that VSID is simlar to VNI” – but tha= t is still something different than the VXLAN Identifier (though even earli= er is stated “VXLAN header contains 24-bit VNI”). So I would gu= ess this is 3 byte (octet) field and this is the VNI? Why call it something el= se then?

4. = ;      There’s no = relay option … perhaps that is intentional but can the client’s= “Network Identifier” option value be trusted? Would it make se= nse for a relay to provide this? Or is this something only the client would know and= therefore it has to be trusted?

Probably some of the abov= e is because of my lack of understanding of this entire space.

 <= /p>

- =          Bernie=

 <= /p>

From: Behcet S= arikaya [mailto:sarikaya2012@gmail.com]
Sent: Friday, February 14, 2014 12:36 PM
To: Dhc Chairs
Cc: dhcwg@ietf.org
Subject: Fwd: New Version Notification for draft-sarikaya-nvo3-dhc-v= xlan-multicast-00.txt

 

Dear Chairs,

We submitted a draft, see below for details.

Please reserve a shor= t slot in IETF 89.

Note that this is a revised and renamed version of d= raft-sarikaya-dhc-vxlan-multicast-02.


A new version of I-D, draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-sarikaya-nvo3-dhc-vxlan-mult= icast
Revision:       00
Title:          DHCP Options for Configuring Multi= cast Addresses in VXLAN
Document date:  2014-02-14
Group:          Individual Submission
Pages:          12
URL:            http://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-dhc-vxlan-= multicast-00.txt
Status:         https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-dhc-vxlan-multicast/
Htmlized:       http://tools.ietf.org/html/draft-sarikaya-nvo3-dhc-vxlan-multicast-00

Abstract:
   This document defines DHCPv4 and DHCPv6 options for assigning<= br>    multicast addresses for the Tunnel End Point in the Virtual    eXtensible Local Area Network (VXLAN) environments.  New = DHCP options
   are defined which allow a VXLAN Tunnel End Point to request an= y
   source multicast address for the newly created virtual machine= and
   possibly IPv4/IPv6 address(es) for the virtual machine.



Regards,

Frank & Behcet

 

--_000_489D13FBFA9B3E41812EA89F188F018E1AE72D20xmbrcdx04ciscoc_-- From nobody Fri Feb 14 13:10:14 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39491A0331; Fri, 14 Feb 2014 13:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXoPVNhXCoH5; Fri, 14 Feb 2014 13:10:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A763E1A02DE; Fri, 14 Feb 2014 13:10:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214211006.9831.91801.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 13:10:06 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/6EsDgTeQFCltYDgnrd-gta4MayE Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-dhcpv6-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:10:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCPv4 over DHCPv6 Transport Authors : Qi Sun Yong Cui Marcin Siodelski Suresh Krishnan Ian Farrer Filename : draft-ietf-dhc-dhcpv4-over-dhcpv6-05.txt Pages : 14 Date : 2014-02-14 Abstract: IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv4-over-dhcpv6-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 13:22:30 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E691D1A03DD for ; Fri, 14 Feb 2014 13:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vw2Byn0IhEfP for ; Fri, 14 Feb 2014 13:22:27 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 102AD1A03A9 for ; Fri, 14 Feb 2014 13:22:26 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id hr13so9895649lab.29 for ; Fri, 14 Feb 2014 13:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=UefmTXqOZ0/x/2/Ya3y5KBIKC9SmwBR6MuEv+rmSeQA=; b=FdZ+1wjVK9Z+P722wo7/8Jp5MVoR5hmvA7FaNb0v+pva4uWq3EIAOoLUu+3aoPwkHE lrl3uA6pcQqeRF0G4sCRcsm9TvpOYeah3HeKGO9AdosLfF2fmSMbMcvWFWaXR+FqAUhu YgQQqziUvi6r7rKReGEAgSUNJofzBlHk3s/vglvpkuWSb4yHKNDSszoKQoRv7hThHmO7 sRRcP4RuJ7iMkFlDqS8VRCrXX4nSoKHfXxCYi324NrtKDLwmvtVWBUHrKXkfcK2R3Wpt kOrfkjoGxoBxIPASNahCvCEDFiYhpaE89KHQKSddv6B1bGxEE/YZKitHeMNVx7eOFZMd KaRw== MIME-Version: 1.0 X-Received: by 10.152.2.169 with SMTP id 9mr3481253lav.48.1392412944726; Fri, 14 Feb 2014 13:22:24 -0800 (PST) Received: by 10.112.16.198 with HTTP; Fri, 14 Feb 2014 13:22:24 -0800 (PST) In-Reply-To: <20140214211006.9831.91801.idtracker@ietfa.amsl.com> References: <20140214211006.9831.91801.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 22:22:24 +0100 Message-ID: From: Marcin Siodelski To: "" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/231HgnXHfWYHAqT0Y589UxaiAcU Subject: [dhcwg] Fwd: I-D Action: draft-ietf-dhc-dhcpv4-over-dhcpv6-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:22:30 -0000 The version -05 incorporates some minor (mostly editorial) changes suggested by Bernie during his shepherd work: 1. Update reference to the latest draft-ietf-dhc-dhcpv6-unknown-msg-05, instead of -04 2. Section 5.3 references section 7 which discusses the use of Unicast Flag in detail 3. In section 8, use "global address of appropriate scope" instead of "global scope" 4. Clarify the text about use of Information Refresh Time option (use when in stateless mode) 5. Use the term DHCP 4o6 client (or client) term consistently. 6. Remove reference to RFC6842 - there is no need to mandate that the server copies client id in the DHCPv4 response 7. Clarify how the text which says what the client should do if there is duplicated DHCP 4o6 server address (editorial change) 8. Use MBZ instead of Reserved to make the unused flags in the new messages. Marcin ---------- Forwarded message ---------- From: Date: Fri, Feb 14, 2014 at 10:10 PM Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-dhcpv6-05.txt To: i-d-announce@ietf.org Cc: dhcwg@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCPv4 over DHCPv6 Transport Authors : Qi Sun Yong Cui Marcin Siodelski Suresh Krishnan Ian Farrer Filename : draft-ietf-dhc-dhcpv4-over-dhcpv6-05.txt Pages : 14 Date : 2014-02-14 Abstract: IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv4-over-dhcpv6-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Fri Feb 14 15:13:32 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13231A0460; Fri, 14 Feb 2014 15:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTfUD-m4gRNe; Fri, 14 Feb 2014 15:13:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CFF1A0453; Fri, 14 Feb 2014 15:13:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214231319.22866.73419.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:13:19 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/BSU_gEajwdR37BdKfjadOKUxDBc Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-addr-registration-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:13:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Registering self-generated IPv6 Addresses in DNS using DHCPv6 Authors : Sheng Jiang Gang Chen Suresh Krishnan Rajiv Asati Filename : draft-ietf-dhc-addr-registration-04.txt Pages : 8 Date : 2014-02-14 Abstract: In networks that are centrally managed, self-generated addresses cause some traceability issues due to their decentralized nature. One of the most important issues in this regard is the inability to register such addresses in DNS. This document defines a mechanism to register self-generated and statically configured addresses in DNS through a DHCPv6 server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-addr-registration-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 19:08:16 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758A71A007F for ; Fri, 14 Feb 2014 19:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qN4w7oRYtTh7 for ; Fri, 14 Feb 2014 19:08:12 -0800 (PST) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with SMTP id 589F51A0057 for ; Fri, 14 Feb 2014 19:08:11 -0800 (PST) Received: from mail-ve0-f176.google.com ([209.85.128.176]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKUv7aGgqeLoJrNZCvoDvjBrmYA9YE/NJv@postini.com; Fri, 14 Feb 2014 19:08:11 PST Received: by mail-ve0-f176.google.com with SMTP id jx11so3032992veb.7 for ; Fri, 14 Feb 2014 19:08:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Hw6KgiHPwPkCrekIIi/l2hDlZ1VbfMP9W87BxSJ61Lw=; b=ij3kgoUVXlzZMbAqmXlyAr57qOEPOvYBS5D7wXEWebd48Sj1ZtzLuV5eefSVv/5ZXq B/rk6JU/Pwg/xMJE95T5GbwRLdmXzM63jBZcdCFQX50O0AJ2F78W92dig4zkFwvsloV1 dwhbYarbLfhe+/lPFIjNDjugPUpNRNPb+UqPiSvhdbkd3jxYYudkWt0BUnw02Tnby86J hXkAxd01EY2vnHkcNm3JM5srVuMyuZ5jEYH5qdeqlkTqZSoXpIJwSzOizmuOBJ5NPTy2 JpKIpC1pY8KVoe0vyAfKgb0Z2e2TXnUCJD+oCZfvjhLf+3fgHadeGDuUFPFAkhJAX/XJ t/qQ== X-Gm-Message-State: ALoCoQn4uAxBOJHKzYCKrgLbqZfuS1L8oUfcFy5Z+NFIsBOYL9CBimH5KLahVhoA60kxFNZyrmgMYDZC6KATE2Nw/9/H4BHcN/OpStQvfuzxU5EqwAd5xEODqYSP4qN0Ag1cbznO7M9li5k4L1afY4ZtlzEg0dXMvw== X-Received: by 10.220.106.84 with SMTP id w20mr7924074vco.18.1392433689770; Fri, 14 Feb 2014 19:08:09 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.220.106.84 with SMTP id w20mr7924069vco.18.1392433689656; Fri, 14 Feb 2014 19:08:09 -0800 (PST) Received: by 10.220.145.142 with HTTP; Fri, 14 Feb 2014 19:08:09 -0800 (PST) In-Reply-To: References: <20140214211006.9831.91801.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 19:08:09 -0800 Message-ID: From: Andre Kostur To: Marcin Siodelski Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/338hTOY4UJsbCajMzNTbWeMILMU Cc: "" Subject: Re: [dhcwg] Fwd: I-D Action: draft-ietf-dhc-dhcpv4-over-dhcpv6-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 03:08:14 -0000 Perhaps a quick question on section 6.2. I'm curious as to why there's a special case of "if there are no addresses, use All_DHCP_Relay_Agents_and_Servers"? If an administrator wanted the client to send to that address, they could also just supply that one address in the option. And then clients wouldn't have to have a special case handling of receiving an empty option. Also the section says "This list may include either multicast or unicast addresses." Is that intended to say that it cannot contain a mix of both? -- Andre Kostur From nobody Sat Feb 15 22:38:49 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8361A0043 for ; Sat, 15 Feb 2014 22:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIP_vgtTjMUv for ; Sat, 15 Feb 2014 22:38:45 -0800 (PST) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with SMTP id 51F061A037C for ; Sat, 15 Feb 2014 22:38:44 -0800 (PST) Received: from mail-vc0-f170.google.com ([209.85.220.170]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKUwBc8jzUWI1X7PbchQYo9gnEL4VJMwy7@postini.com; Sat, 15 Feb 2014 22:38:43 PST Received: by mail-vc0-f170.google.com with SMTP id hu8so10824875vcb.29 for ; Sat, 15 Feb 2014 22:38:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=1BBsMr4yQDzJA5kv38gCb34m6Bh4iwu1IPAU87McNT4=; b=SmxRPNYjwcR+UHjHURymSSVxMHYcZQiRocnRNuQ42P0CaOhKEOuSqNSmGDCj7jONbn QvzuRI9yqs8+ijyAtheZyn/Jn/hoYaUK3dbfXg592P0Iw4owO4rjM8aFmV8aY++37gFX Ck5P7V07j/wV5MXbmQBE4GWtydxlnpOkkQLO0i1y7/175IqKbP2Lji7on//uE3YfRRg0 8e0Ojfml+hn52CkMwATb1lkEmvq6UsuCaNaSIxtduaM0VwhM5c5br8KRfrSE1La5vInd Ai8MMnjN5vv+WKYEuIiLPAzcq1Ox1hJeKWsxiw/Wl1Zi9nFkWb1RockSa/pfFFYCPXPX 5n5Q== X-Gm-Message-State: ALoCoQnPnsLDczWqU82hIRGlDaSj790ZCplIDUdPCETuvdPhHvYVDGvEhPiFopJtJsRwkJsqO1cFu35owcMcJqY72v+un2PiRGFYxbDpKk7onKA1vOpJqplHxVYdkCGy1kt4bJLEFT4hGGE2KXJ38IZbq8/UnzushQ== X-Received: by 10.53.8.166 with SMTP id dl6mr8672vdd.60.1392532721990; Sat, 15 Feb 2014 22:38:41 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.53.8.166 with SMTP id dl6mr8659vdd.60.1392532721772; Sat, 15 Feb 2014 22:38:41 -0800 (PST) Received: by 10.220.145.142 with HTTP; Sat, 15 Feb 2014 22:38:41 -0800 (PST) Date: Sat, 15 Feb 2014 22:38:41 -0800 Message-ID: From: Andre Kostur To: "dhcwg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/clujmyUVlQ12-wmUaxAe2IGWa9Q Subject: [dhcwg] draft-ietf-dhc-dhcpv6-load-balancing-01.txt (unofficial) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 06:38:48 -0000 Unfortunately I have to do this unofficially as I cannot formally publish until Mar 3rd, and the chairs and I feel that it is useful that everyone can see the -01 draft before the presentation in London. Title : DHC Load Balancing Algorithm for DHCPv6 Author(s) : Andre Kostur Filename : draft-ietf-dhc-dhcpv6-load-balancing-01.txt Until I formally publish, you can find the xml, html, and txt versions at http://www.kostur.net/ietf HTML: http://www.kostur.net/ietf/draft-ietf-dhc-dhcpv6-load-balancing-01.html TXT: http://www.kostur.net/ietf/draft-ietf-dhc-dhcpv6-load-balancing-01.txt XML: http://www.kostur.net/ietf/draft-ietf-dhc-dhcpv6-load-balancing-01.xml Changed from -00 - more explicit on the handling of each message type - expanding handling of Leasequery - notes on the relation of Load Balancing with Failover - added Triggered Reconfiguration as RFC 6977 has since been published I intend to be awake to publish this formally as soon as I can. Publication is supposed to reopen at midnight of wherever the IETF meeting is. Since it's in London, and I'm in the Pacific time zone... that's only 4 PM for me. -- Andre Kostur From nobody Sun Feb 16 06:45:06 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC0D1A0225 for ; Sun, 16 Feb 2014 06:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74UxjkKCHmcx for ; Sun, 16 Feb 2014 06:45:02 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 63F8E1A01BB for ; Sun, 16 Feb 2014 06:45:02 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id g10so13825504pdj.30 for ; Sun, 16 Feb 2014 06:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=arEeIi9+8QLdSS8xsA9R0mIOjepoXH8p6t1uDvP612E=; b=HAd6iHcj67XmFR7qf6cm3Hg7C6THc3PO+ZLtXKcen3tN9WSAOfvuGtvBCyP51KJDmA I2j9D8p6Mwqqp1ka4Djwewo8KWUp3TgncFkraXgAiH1VxV3YOiEjOlELT2Iqorob6jPw uDTv2nuQmN13U7Xz5chJvqAo/cxv8dVzJJC+5EGbLYgzdWL3VBEjrt2pEn9MXPgM3LD4 sjH85kzvcWUWbRIcdtoH6CJTFsd08F5mEVn5Pvf+YMBjNOZ6JEOwx2fuW7S20b2MyJ0v 5yz7uJ+5NeFS+eUJjGd0d6+7VaSc4kE8ExY9e/4RGTpz7vdtdyfmu67BhmTM7tTCBoFK aJ0w== X-Received: by 10.68.213.41 with SMTP id np9mr20906754pbc.90.1392561900302; Sun, 16 Feb 2014 06:45:00 -0800 (PST) Received: from [192.168.0.104] ([60.215.217.244]) by mx.google.com with ESMTPSA id e6sm36571729pbg.4.2014.02.16.06.44.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Feb 2014 06:44:59 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: Date: Sun, 16 Feb 2014 22:44:48 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <004A4A72-F1A5-480D-9AF7-680C2CC3C14E@gmail.com> References: <20140214211006.9831.91801.idtracker@ietfa.amsl.com> To: Andre Kostur X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/zkVODDGU9_kY9MkNUy9WFVgua4A Cc: "" Subject: Re: [dhcwg] Fwd: I-D Action: draft-ietf-dhc-dhcpv4-over-dhcpv6-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 14:45:05 -0000 Hi Andre, Thanks for review. Please see inline. On 2014-2-15, at =E4=B8=8A=E5=8D=8811:08, Andre Kostur wrote: > Perhaps a quick question on section 6.2. >=20 > I'm curious as to why there's a special case of "if there are no > addresses, use All_DHCP_Relay_Agents_and_Servers"? If an > administrator wanted the client to send to that address, they could > also just supply that one address in the option. And then clients > wouldn't have to have a special case handling of receiving an empty > option. [Qi] This is intended to be compatible with the DHCPv6 architecture, = where the client sends packets to the multicast address by default. So = if there is no address in the 4o6 Server Address option, the 4o6 DHCP = client just works like a DHCPv6 client.=20 >=20 > Also the section says "This list may include either multicast or > unicast addresses." Is that intended to say that it cannot contain a > mix of both? [Qi] There should be no such limit. The client just sends packets to the = address(es) listed int the 4o6 Server Address option. An administrator = can configure this option according to his needs.=20 Will improve the wording. Thanks, QI >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Sun Feb 16 13:18:30 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DCE1A041A for ; Sun, 16 Feb 2014 13:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyb3JDhXlzHq for ; Sun, 16 Feb 2014 13:18:25 -0800 (PST) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 234081A0411 for ; Sun, 16 Feb 2014 13:18:25 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2388B1B817E for ; Sun, 16 Feb 2014 13:18:23 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 1C4F5190052; Sun, 16 Feb 2014 13:18:23 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 16 Feb 2014 13:18:22 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <004A4A72-F1A5-480D-9AF7-680C2CC3C14E@gmail.com> Date: Sun, 16 Feb 2014 16:18:22 -0500 Content-Transfer-Encoding: 7bit Message-ID: References: <20140214211006.9831.91801.idtracker@ietfa.amsl.com> <004A4A72-F1A5-480D-9AF7-680C2CC3C14E@gmail.com> To: Qi Sun X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/_sz00fDV_Bk4VklJEsA-9aQLBN0 Cc: "" , Andre Kostur Subject: Re: [dhcwg] Fwd: I-D Action: draft-ietf-dhc-dhcpv4-over-dhcpv6-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 21:18:26 -0000 On Feb 16, 2014, at 9:44 AM, Qi Sun wrote: > Will improve the wording. suggestion: "may include multicast and unicast addresses". From nobody Sun Feb 16 18:16:23 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650291A0319 for ; Sun, 16 Feb 2014 18:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.94 X-Spam-Level: X-Spam-Status: No, score=-4.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7BdJrQ5jtn7 for ; Sun, 16 Feb 2014 18:16:08 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 83E3B1A0317 for ; Sun, 16 Feb 2014 18:16:07 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id s1H2G2vX001705 for ; Mon, 17 Feb 2014 11:16:02 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id s1H2G2DI029576 for dhcwg@ietf.org; Mon, 17 Feb 2014 11:16:02 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id MAA29574; Mon, 17 Feb 2014 11:16:02 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id s1H2G14g000739 for ; Mon, 17 Feb 2014 11:16:01 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s1H2G1I7001685; Mon, 17 Feb 2014 11:16:01 +0900 (JST) Received: from [133.196.16.86] (ncg-dhcp86.isl.rdc.toshiba.co.jp [133.196.16.86]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 6D40B97D71 for ; Mon, 17 Feb 2014 11:16:01 +0900 (JST) Message-ID: <530170E0.3040004@toshiba.co.jp> Date: Mon, 17 Feb 2014 11:16:00 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/rWoQJWxpxusynv5k4G43j4ecnoQ Subject: [dhcwg] draft-jiang-dhc-stateless-reconfiguration-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 02:16:14 -0000 Hi, Let me speak out (again) that I'm interested in the following draft in the context of roll/6lo-ish LLN, in particular, over 802.15.4. > Title : Stateless Reconfiguration in Dynamic Host Configuration Protocol for IPv6 (DHCPv6) > Authors : Sheng Jiang > Bing Liu > Filename : draft-jiang-dhc-stateless-reconfiguration-01.txt We have an application of DHCPv6 that may use statelss mode to deliver network configurations to nodes over wireless mesh network (=> draft-doi-roll-mpl-parameter-configuration-04). Stateless mode is preferred on traffic efficiency (periodic renewal traffic is not preferred on LLN). However sometimes we may need to update configured parameters. We definitely need stateless reconfiguration. > {Question to WG No.1} There are three potential mechanisms to create > relay agent destinations on the DHCPv6 server: We prefer b) to remove duplicated messages. > {Question to WG No.2} There could be two kind of stateless DHCPv6 > reconfiguration modes as the following, which one is proper? Or we > should support both? Is there any difficulty to support both modes? I think these two modes should have different use cases. 'Push mode' will fit to our use case because the configuration is network-wide and push-mode (with multicast target -- it can be broadcasted on a link) is much much more efficient than trigger mode in LLN. But some administrator may want to have per-client configuration and that is the nature of DHCP, as described. Regards, // Yusuke DOI From nobody Sun Feb 16 21:43:05 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D86C1A035A for ; Sun, 16 Feb 2014 21:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oHkKG8H56WD for ; Sun, 16 Feb 2014 21:43:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 37CC01A033C for ; Sun, 16 Feb 2014 21:43:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBE87455; Mon, 17 Feb 2014 05:42:57 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 05:42:35 +0000 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 05:42:40 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.51]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 13:42:36 +0800 From: Sheng Jiang To: Yusuke DOI , "" Thread-Topic: [dhcwg] draft-jiang-dhc-stateless-reconfiguration-01 Thread-Index: AQHPK4ZD1LIqFKk32E6YYvetgI1Xj5q4tc1Q Date: Mon, 17 Feb 2014 05:42:35 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923ADE4D33@nkgeml512-mbx.china.huawei.com> References: <530170E0.3040004@toshiba.co.jp> In-Reply-To: <530170E0.3040004@toshiba.co.jp> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/KZEUhVvOY_btYmUn1R8zCxqILIg Subject: Re: [dhcwg] draft-jiang-dhc-stateless-reconfiguration-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 05:43:03 -0000 SGksIFl1c3VrZSwNCg0KVGhhbmtzIGZvciB5b3VyIHJlcGx5IGFuZCBzdXBwb3J0LiBTb21lIGV4 cGxhbmF0aW9uIGJlbG93Lg0KDQo+PiAgICB7UXVlc3Rpb24gdG8gV0cgTm8uMn0gVGhlcmUgY291 bGQgYmUgdHdvIGtpbmQgb2Ygc3RhdGVsZXNzIERIQ1B2Ng0KPj4gICAgcmVjb25maWd1cmF0aW9u IG1vZGVzIGFzIHRoZSBmb2xsb3dpbmcsIHdoaWNoIG9uZSBpcyBwcm9wZXI/ICBPciB3ZQ0KPj4g ICAgc2hvdWxkIHN1cHBvcnQgYm90aD8NCj4NCj5JcyB0aGVyZSBhbnkgZGlmZmljdWx0eSB0byBz dXBwb3J0IGJvdGggbW9kZXM/IEkgdGhpbmsgdGhlc2UgdHdvIG1vZGVzIHNob3VsZA0KPmhhdmUg ZGlmZmVyZW50IHVzZSBjYXNlcy4gJ1B1c2ggbW9kZScgd2lsbCBmaXQgdG8gb3VyIHVzZSBjYXNl IGJlY2F1c2UgdGhlDQo+Y29uZmlndXJhdGlvbiBpcyBuZXR3b3JrLXdpZGUgYW5kIHB1c2gtbW9k ZSAod2l0aCBtdWx0aWNhc3QgdGFyZ2V0IC0tIGl0IGNhbg0KPmJlIGJyb2FkY2FzdGVkIG9uIGEg bGluaykgaXMgbXVjaCBtdWNoIG1vcmUgZWZmaWNpZW50IHRoYW4gdHJpZ2dlciBtb2RlIGluDQo+ TExOLiBCdXQgc29tZSBhZG1pbmlzdHJhdG9yIG1heSB3YW50IHRvIGhhdmUgcGVyLWNsaWVudCBj b25maWd1cmF0aW9uIGFuZA0KPnRoYXQgaXMgdGhlIG5hdHVyZSBvZiBESENQLCBhcyBkZXNjcmli ZWQuDQoNClRoZSBkaWZmaWN1bHR5IGlzIG5vIHRlY2huaWNhbCBhc3BlY3QuIEhvd2V2ZXIsIHRo ZXJlIGFyZSB0d28gY29uc2lkZXJhdGlvbnMgZm9yIHB1c2ggbW9kZToNCg0KYSkgdGhlIHB1c2gg bW9kZSBpcyBkaWZmZXJlbnQgZnJvbSB0cmFkaXRpb25hbCBESEMgYmVoYXZpb3IgaW4gdGhhdCBj bGllbnRzIGlzIHRoZSBpbml0aWF0b3IuIFNvLCB0aGlzIHdvdWxkIG5lZWQgdGhlIGFncmVlbWVu dCBvZiBESEMgV0cgSG93ZXZlciwgZXZlbiB0aGUgZXhpc3RpbmcgcmVjb25maWd1cmF0aW9uIGlu IHN0YXRlZnVsIERIQ1B2NiBpcyBpbml0aWF0ZWQgYnkgc2VydmVyIHNpZGUuIFNvLCB0aGlzIG1h eSBub3QgYmUgdG9vIGNvbnRyb3ZlcnNpYWwuIEl0IGlzIHN0aWxsIGEgcXVlc3Rpb24gcmVxdWly aW5nIGNvbmZpcm1hdGlvbiBmb3Igbm93Lg0KDQpiKSAicHVzaCBtb2RlJyBtYXkgaGF2ZSBtb3Jl IHNlY3VyaXR5IGlzc3VlcyB0aGF0IHRyaWdnZXIgbW9kZS4gSG93IHRvIHByZXZlbnQgYSBmYWtl IERIQ1B2NiBzZXJ2ZXIgcHVzaCBtYWxpY2lvdXMgY29uZmlndXJhdGlvbiBpcyBhIGRpZmZpY3Vs dHksIGFsdGhvdWdoIERIQ1B2NiBzbm9vcGluZyBtYXkgaGVscC4gIlRyaWdnZXIgbW9kZSIgaXMg c2FmZXIgZm9yIHRoYXQgY2xpZW50IHdvdWxkIGNvbnRhY3Qgb3JpZ2luYWwgc2VydmVyIGZvciB1 cGRhdGUgY29uZmlndXJhdGlvbi4NCg0KUmVnYXJkcywNCg0KU2hlbmcNCg0KPlJlZ2FyZHMsDQo+ DQo+Ly8gWXVzdWtlIERPSSA8eXVzdWtlLmRvaUB0b3NoaWJhLmNvLmpwPg0KPg0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ZGhjd2cgbWFpbGluZyBs aXN0DQo+ZGhjd2dAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RoY3dnDQo= From nobody Mon Feb 17 01:09:31 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD941A02C3 for ; Mon, 17 Feb 2014 01:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3S-9mPZPn7yo for ; Mon, 17 Feb 2014 01:09:28 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id F12391A00C9 for ; Mon, 17 Feb 2014 01:09:27 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id a1so2049735wgh.22 for ; Mon, 17 Feb 2014 01:09:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6+7ljPqyFRB4NeOnaHGfAifXq/HsRfHrxCUVTIakQqA=; b=WZMBq5+aobHrkzpzJLb+L0sW53Aq7dstUqsyWCQOIcp1YoG6BLWk/9X41arjOQ1WCK AUNtG44cEqbWpiJKQvx3pUMj0IBuWa1VyYLjFVNADFmbTYXpWkwCNMr8d6qCr9kW23IC uIqe9xtzmieRD2BikUV1AbYKdjfzezu6XUrcHqKeOqYmci9RWF9O9QA5SBXj4Jk+PUpf f3SXfoPFdNNMYh7U7I+o/i4dLfuINi5ajkcnb9X1KUclOZ9qQMAJeb5TVQRrzjSo2X0H LOmrDXWRALPPAVxCxto9Rr1ckFvS5QnuPG57I7WkEuL/kj2CoHrw1Sq/Fx91yRLAyHTJ 1M+Q== MIME-Version: 1.0 X-Received: by 10.180.24.134 with SMTP id u6mr11369865wif.41.1392628164986; Mon, 17 Feb 2014 01:09:24 -0800 (PST) Received: by 10.194.171.129 with HTTP; Mon, 17 Feb 2014 01:09:24 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Feb 2014 10:09:24 +0100 Message-ID: From: Daniel Migault To: "dhcwg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/t4OJCLmIoqKpyaq-lDRQA2DRdFU Cc: "Bernie Volz \(volz\)" Subject: [dhcwg] Fwd: draft-mglt-homenet-naming-architecture-dhc-options-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 09:09:30 -0000 Hi, If possible we would like to get a slot to present the DHCP Options we came to to configure the homenet naming architecture. BR, Daniel ---------- Forwarded message ---------- From: Daniel Migault Date: Thu, Feb 13, 2014 at 5:37 PM Subject: draft-mglt-homenet-naming-architecture-dhc-options-01 To: "homenet@ietf.org" Hi, Please find the new version of the draft draft-mglt-homenet-naming-architecture-dhc-options-01. It defines DHCP Options to configure the Homenet naming architecture. Feel free to comment! BR, Daniel A new version of I-D, draft-mglt-homenet-naming-architecture-dhc-options-01.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-homenet-naming-architecture-dhc-options Revision: 01 Title: DHCP Options for Homenet Naming Architecture Document date: 2014-02-13 Group: Individual Submission Pages: 18 URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-01.txt Status: https://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options/ Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-mglt-homenet-naming-architecture-dhc-options-01 Abstract: The home network naming architecture requires a complex naming configuration on the CPE. This configuration MAY not be handled easily by the average end user. Furthermore, such misconfiguration MAY result in making home network unreachable. This document proposes a DHCP options that provide the CPE all necessary parameters to set up the home network naming architecture. First, this DHCP options provide automatic configuration and avoid most end users' misconfiguration. Most average end users may not require specific configuration, and their ISP default configuration MAY fully address their needs. In that case, the naming homenet architecture configuration will be completely transparent to the end users. Then, saving naming configuration outside the CPE, makes it resilient to change of CPE or CPE upgrades. Such configuration may also be configured by the end user, via the customer area of their ISP. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From nobody Mon Feb 17 10:00:11 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17411A03F0 for ; Mon, 17 Feb 2014 10:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MymZNj9vowgn for ; Mon, 17 Feb 2014 10:00:09 -0800 (PST) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3621A002C for ; Mon, 17 Feb 2014 10:00:09 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EE4161B80E5 for ; Mon, 17 Feb 2014 10:00:06 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E6E05190052; Mon, 17 Feb 2014 10:00:06 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 10:00:06 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Mon, 17 Feb 2014 13:00:04 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <2D6D46E6-15C5-4465-843B-3FECA8DC729D@nominum.com> References: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/MijZsTbkN_ArkHiNL1SciOzRHR8 Cc: "dhcwg@ietf.org" , Dhc Chairs Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 18:00:11 -0000 On Feb 14, 2014, at 12:36 PM, Behcet Sarikaya = wrote: > New DHCP options > are defined which allow a VXLAN Tunnel End Point to request any > source multicast address for the newly created virtual machine and > possibly IPv4/IPv6 address(es) for the virtual machine. This sounds like another set of stateful DHCP options. Why not just = use regular DHCP IA_NA or IA_PD? From nobody Tue Feb 18 08:42:51 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1C61A04FB for ; Tue, 18 Feb 2014 08:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjY9TxMYx2gk for ; Tue, 18 Feb 2014 08:42:47 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8821A0073 for ; Tue, 18 Feb 2014 08:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3261; q=dns/txt; s=iport; t=1392741765; x=1393951365; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Srf4PHR7Lqv1M66iof8OjE8uxkBr0HnE8AxOa+L5wEc=; b=b/w09Z3bx4NhXrACVuwWui8bQueQeOCh5fAlWLZNo8trKARTgg14sXu4 idDrmPF+0m2f+5AUzmkdf1VICvDk6Wtll+nyV5dhXafMClJ2VTc3EOPv0 9Ah0M2hUxMKtX/vJJUQ6K4sZoBe0U1xqgD+Mz0Do0Q9kf4TY71my6YeOO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAHiMA1OtJV2b/2dsb2JhbABZgwY4V79QgRoWdIIlAQEBBDo/DAQCAQgOAwECAQEBCxQJByERFAMGCAIEAQ0FCAGHaAMRDcN0DYgPF4xngUYSETEHBoMegRQElkCDHosshUWDLYFqQA X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208";a="304842563" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 18 Feb 2014 16:42:44 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1IGgiSm026479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 16:42:44 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 10:42:44 -0600 From: "Bernie Volz (volz)" To: Daniel Migault , "dhcwg@ietf.org" Thread-Topic: draft-mglt-homenet-naming-architecture-dhc-options-01 Thread-Index: AQHPK7/7Fij6BVIh0UG75m92ObJjVpq7MxuQ Date: Tue, 18 Feb 2014 16:42:43 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE99D3D@xmb-rcd-x04.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.65.111] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/8Ak3eYl9oEgF8hnN9UjFjUjLQ5Q Subject: Re: [dhcwg] draft-mglt-homenet-naming-architecture-dhc-options-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 16:42:49 -0000 Hi: We will add it to the agenda, but it will be lower priority as it has not b= een adopted by the DHC WG and is apparently targeted for the HOMENET WG. At= present, it looks like we will have time for it, but if not those interest= ed can attend HOMENET. Regards and see you in London! - Bernie -----Original Message----- From: Daniel Migault [mailto:mglt.ietf@gmail.com]=20 Sent: Monday, February 17, 2014 4:09 AM To: dhcwg@ietf.org Cc: Tomasz Mrugalski; Bernie Volz (volz) Subject: Fwd: draft-mglt-homenet-naming-architecture-dhc-options-01 Hi, If possible we would like to get a slot to present the DHCP Options we came= to to configure the homenet naming architecture. BR, Daniel ---------- Forwarded message ---------- From: Daniel Migault Date: Thu, Feb 13, 2014 at 5:37 PM Subject: draft-mglt-homenet-naming-architecture-dhc-options-01 To: "homenet@ietf.org" Hi, Please find the new version of the draft draft-mglt-homenet-naming-architec= ture-dhc-options-01. It defines DHCP Options to configure the Homenet namin= g architecture. Feel free to comment! BR, Daniel A new version of I-D, draft-mglt-homenet-naming-architecture-dhc-options-01= .txt has been successfully submitted by Daniel Migault and posted to the IETF re= pository. Name: draft-mglt-homenet-naming-architecture-dhc-options Revision: 01 Title: DHCP Options for Homenet Naming Architecture Document date: 2014-02-= 13 Group: Individual Submission Pages: 18 URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-= dhc-options-01.txt Status: https://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc= -options/ Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-optio= ns-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-homenet-naming-architecture-d= hc-options-01 Abstract: The home network naming architecture requires a complex naming configuration on the CPE. This configuration MAY not be handled easily by the average end user. Furthermore, such misconfiguration MAY result in making home network unreachable. This document proposes a DHCP options that provide the CPE all necessary parameters to set up the home network naming architecture. First, this DHCP options provide automatic configuration and avoid most end users' misconfiguration. Most average end users may not require specific configuration, and their ISP default configuration MAY fully address their needs. In that case, the naming homenet architecture configuration will be completely transparent to the end users. Then, saving naming configuration outside the CPE, makes it resilient to change of CPE or CPE upgrades. Such configuration may also be configured by the end user, via the customer area of their ISP. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From nobody Tue Feb 18 08:50:28 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B4E1A0517 for ; Tue, 18 Feb 2014 08:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJa3mfqG-aIR for ; Tue, 18 Feb 2014 08:50:18 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id C9D371A04D4 for ; Tue, 18 Feb 2014 08:50:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3089; q=dns/txt; s=iport; t=1392742216; x=1393951816; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=UvzJLrpd37UssM0dvxNSKrRp2hbznm42LQdTDQ6L+mA=; b=Q3h2+OL3O/k17sIni+hlBJFILvbMkMYOBFbXHDiikNblzLIqCGsCsOWc gLTjaHu76i7ECpqPB+1AhOhWrFt/uPbRxthDrQCAqtI7w40N0IBFB0Qeg vHG7KTM1gekEqfX0r+Oz64jYx2E64dB0cQWcHczuAaz7YmVC8BkK57lCF c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFABeOA1OtJV2Y/2dsb2JhbABZgwY4UQa/UIEbFnSCJQEBAQQBAQEaHTQLDAYBCBEDAQEBCxQJLgsUCQkBBAENBQgBh3wIBcwRF44tIzENgx6BFASZXpBxgW+BPoIq X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208";a="21311246" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP; 18 Feb 2014 16:50:15 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1IGoFu0006099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 16:50:15 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 10:50:15 -0600 From: "Bernie Volz (volz)" To: Suresh Krishnan , "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-addr-registration-04.txt & document shepherd volunteers! Thread-Index: Ac8syWutBam8c80xQDaP8ZtWyI/Wvw== Date: Tue, 18 Feb 2014 16:50:14 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE9AE4A@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.65.111] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/FtXMgxbdG-LbZYAXaW2fsI2cNI4 Cc: Sheng Jiang Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-addr-registration-04.txt & document shepherd volunteers! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 16:50:22 -0000 Suresh, co-authors, and WG: - We will ask during the London IETF DHC WG status update if anyone feels t= hat this draft is NOT ready for WGLC. Best of course to comment on the mail= ing list if you feel it is not ready (and why). - Unless issues or concerns are raised, we will start a WG last call for th= e document after the London IETF. WG: Please consider being a document shepherd for this (and potentially) other = drafts. Please let the chairs (dhc-chairs@tools.ietf.org) know if you are i= nterested. We will need to assign a shepherd before starting the WG last ca= ll on the document. - Bernie -----Original Message----- From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com]=20 Sent: Monday, February 17, 2014 9:42 AM To: Bernie Volz (volz); Tomasz Mrugalski Cc: Sheng Jiang Subject: Fwd: [dhcwg] I-D Action: draft-ietf-dhc-addr-registration-04.txt Hi Bernie/Tomek, We believe all open issues have been addressed by this version of the dr= aft. The draft is now ready for WGLC. If you find any issues in the documen= t shepherd review we will address them right away before WGLC. Thanks Suresh -------- Original Message -------- Subject: [dhcwg] I-D Action: draft-ietf-dhc-addr-registration-04.txt Date: Fri, 14 Feb 2014 15:13:19 -0800 From: To: CC: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group= of the IETF. Title : Registering self-generated IPv6 Addresses in=20 DNS using DHCPv6 Authors : Sheng Jiang Gang Chen Suresh Krishnan Rajiv Asati Filename : draft-ietf-dhc-addr-registration-04.txt Pages : 8 Date : 2014-02-14 Abstract: In networks that are centrally managed, self-generated addresses cause some traceability issues due to their decentralized nature. One of the most important issues in this regard is the inability to register such addresses in DNS. This document defines a mechanism to register self-generated and statically configured addresses in DNS through a DHCPv6 server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-addr-registration-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Wed Feb 19 08:33:47 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8DC1A04F3; Wed, 19 Feb 2014 08:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ausPFOmXk8ps; Wed, 19 Feb 2014 08:33:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 754D81A0491; Wed, 19 Feb 2014 08:33:41 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140219163341.26355.31084.idtracker@ietfa.amsl.com> Date: Wed, 19 Feb 2014 08:33:41 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/AtSBcmCBxQIfsRg_NNG7IHtf0JY Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv4-over-dhcpv6-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 16:33:44 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCPv4 over DHCPv6 Transport Author(s) : Q. Sun, et al Filename : draft-ietf-dhc-dhcpv4-over-dhcpv6 Pages : 15 Date : 2014-02-19 IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-over-dhcpv6-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv4-over-dhcpv6"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-02-19083341.I-D@ietf.org> --NextPart-- From nobody Wed Feb 19 09:28:27 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B951A0500 for ; Wed, 19 Feb 2014 09:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00EaXiQIQvp5 for ; Wed, 19 Feb 2014 09:28:21 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 11E6A1A0249 for ; Wed, 19 Feb 2014 09:28:19 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id e16so524774lan.12 for ; Wed, 19 Feb 2014 09:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Lu4yP2CO3WqAAJsyozs+UJPOOhqCxRu+WRu2UqaHUP8=; b=Z+BkJeCou2LaLc4EaONfDnz4V2tpzx4Vbp02gBIRe440Of053ob5nE6gwK++Yb4Th4 LF2mxGSLiTBzAYfwHwcqJ8j3e3SAKHDH2Xmwe+RPBxuahu4OkLoziOo2GX/4OY8ux+wC xthCDhCmzK/sxlZIUd6ey8Ocgqk8qTVyahi32374K8JNoz+V7GY/IgzUquZJq3X0/f9U GOw271rt6KU1xZuMAhy/9aiCK3Cz+41cuIHCKDCYIJyrsTVhtbYvxLl78eQBxMLGtj8H pNB4ULMIzGLtB6LoiE7Bi3QKFzf+WHJAvNWhAY+jcIwqmRkspleLLybHiP3wfN5PZgyk FOZQ== MIME-Version: 1.0 X-Received: by 10.152.43.47 with SMTP id t15mr11017935lal.38.1392830896077; Wed, 19 Feb 2014 09:28:16 -0800 (PST) Received: by 10.114.170.195 with HTTP; Wed, 19 Feb 2014 09:28:16 -0800 (PST) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AE72D20@xmb-rcd-x04.cisco.com> References: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1AE72D20@xmb-rcd-x04.cisco.com> Date: Wed, 19 Feb 2014 11:28:16 -0600 Message-ID: From: Behcet Sarikaya To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=001a11c24100caff1d04f2c5b62a Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/ZSdlxtXuATWQJrBtRlLwm91hBOk Cc: "dhcwg@ietf.org" , Dhc Chairs Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:28:24 -0000 --001a11c24100caff1d04f2c5b62a Content-Type: text/plain; charset=ISO-8859-1 Hi Bernie, Thanks for your review, sorry for the delay in my reply, apologies. Please see my replies inline. Regards, Behcet On Fri, Feb 14, 2014 at 2:46 PM, Bernie Volz (volz) wrote: > Behcet: > > > > Just so we can properly prioritize (though at present we seem to have > sufficient time), is this intended to be an informational presentation, or > do you have issues to discuss/resolve? We'll give preference to those > drafts that have issues to discuss/resolve. > > > Since we are defining several DHC options and related client/server behaviour, we thought that it should also be presented in dhc WG, as is customary, no? Also, as this is now (I think) primarily targeted for the NVO3 (Network > Virtualization Overlays) WG, is there anything of significance to discuss > in DHC - there does seem to be some server processing involved as the > client supplied option triggers the server to return a specific multicast > address. > > > The aim is to get dhc specific comments about our draft, much like what you did below. A few comments from a quick look at the document: > > 1. Why does the client set the address to 0 in the address option? > Why have the client include this option at all (server can just add it > either because the network identifier option is present or as client can > request in PRL/ORO)? > Yes, I think this is another way of doing it. Is there a preference by dhc WG on which way we should have it in the draft? > 2. The option lengths are wrong? In DHCPv6 (& DHCPv4), the option > length covers just the data itself (not the option code and option type). > OK, to be corrected. > 3. Why is the "VXLAN Identifier" apparently 3 bytes for the DHCPv6 > option and 4 bytes for the DHCPv4 option? What is the relationship between > this VXLAN Identifier and the "24-bit Virtual Subnet Identifier (VSID)"? It > does state "Note that VSID is simlar to VNI" - but that is still something > different than the VXLAN Identifier (though even earlier is stated "VXLAN > header contains 24-bit VNI"). So I would guess this is 3 byte (octet) field > and this is the VNI? Why call it something else then? > VNI is of size 24-bits, i.e. 3 octets. In DHCPv4 a4 is always set to zero. Maybe we don't need to have a4, I thought DHCPv4 options are always given in 4-octets? 4. There's no relay option ... perhaps that is intentional but can the > client's "Network Identifier" option value be trusted? Would it make sense > for a relay to provide this? Or is this something only the client would > know and therefore it has to be trusted? > We can clarify and say that the client MUST set it to zero, would that be OK? > Probably some of the above is because of my lack of understanding of > this entire space. > > > Thanks again for taking the time and giving us very nice feedback. > - Bernie > > > > *From:* Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > *Sent:* Friday, February 14, 2014 12:36 PM > *To:* Dhc Chairs > *Cc:* dhcwg@ietf.org > *Subject:* Fwd: New Version Notification for > draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt > > > > Dear Chairs, > > We submitted a draft, see below for details. > > Please reserve a short slot in IETF 89. > > Note that this is a revised and renamed version of > draft-sarikaya-dhc-vxlan-multicast-02. > > > A new version of I-D, draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt > has been successfully submitted by Behcet Sarikaya and posted to the > IETF repository. > > Name: draft-sarikaya-nvo3-dhc-vxlan-multicast > Revision: 00 > Title: DHCP Options for Configuring Multicast Addresses in VXLAN > Document date: 2014-02-14 > Group: Individual Submission > Pages: 12 > URL: > http://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt > Status: > https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-dhc-vxlan-multicast/ > Htmlized: > http://tools.ietf.org/html/draft-sarikaya-nvo3-dhc-vxlan-multicast-00 > > > Abstract: > This document defines DHCPv4 and DHCPv6 options for assigning > multicast addresses for the Tunnel End Point in the Virtual > eXtensible Local Area Network (VXLAN) environments. New DHCP options > are defined which allow a VXLAN Tunnel End Point to request any > source multicast address for the newly created virtual machine and > possibly IPv4/IPv6 address(es) for the virtual machine. > > > > Regards, > > Frank & Behcet > > > --001a11c24100caff1d04f2c5b62a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Bernie,

Thanks for you= r review, sorry for the delay in my reply, apologies.

Please s= ee my replies inline.

Regards,

Behcet


On Fri, Feb 14, 2014 at 2:46 PM, Bernie = Volz (volz) <volz@cisco.com> wrote:

Behcet:

 

Just so we can properly p= rioritize (though at present we seem to have sufficient time), is this inte= nded to be an informational presentation, or do you have issues to discuss/resolve? We’ll give preference to those drafts tha= t have issues to discuss/resolve.

 

<= /div>

Since we are defining several D= HC options and related client/server behaviour, we thought that it should a= lso be presented in dhc WG, as is customary, no?

=

Also, as this is now (I t= hink) primarily targeted for the NVO3 (Network Virtualization Overlays) WG,= is there anything of significance to discuss in DHC – there does seem to be some server processing involved as the client supplied opt= ion triggers the server to return a specific multicast address.

 

<= /div>

The aim is to get dhc specific = comments about our draft, much like what you did below. 

=

A few comments from a qui= ck look at the document:

1.       Why does the client = set the address to 0 in the address option? Why have the client include thi= s option at all (server can just add it either because the network identifier option is present or as client can request in PRL/O= RO)?


Yes, I think th= is is another way of doing it. Is there a preference by dhc WG on which way= we should have it in the draft?
 

2.       The option lengths a= re wrong? In DHCPv6 (& DHCPv4), the option length covers just the data = itself (not the option code and option type).

OK, to be corrected.

3.       Why is the “VX= LAN Identifier” apparently 3 bytes for the DHCPv6 option and 4 bytes = for the DHCPv4 option? What is the relationship between this VXLAN Identifier and the “24-bit Virtual Subnet Identifier (VSID)”? = It does state “Note that VSID is simlar to VNI” – but tha= t is still something different than the VXLAN Identifier (though even earli= er is stated “VXLAN header contains 24-bit VNI”). So I would gu= ess this is 3 byte (octet) field and this is the VNI? Why call it something el= se then?


VNI is of s= ize 24-bits, i.e. 3 octets. In DHCPv4   a4 is always set to zero. Mayb= e we don't need to have a4, I thought DHCPv4 options are always given i= n 4-octets?


<= u>

4.       There’s no rel= ay option … perhaps that is intentional but can the client’s &= ldquo;Network Identifier” option value be trusted? Would it make sens= e for a relay to provide this? Or is this something only the client would know and= therefore it has to be trusted?

We can clarify and say that the client MUST set it to zero, wo= uld that be OK?
 

Probably some of the abov= e is because of my lack of understanding of this entire space.

 

<= /div>

Thanks again for taking the tim= e and giving us very nice feedback.
 

-        &nb= sp; Bernie=

 

From: Behcet S= arikaya [mailto:sarikaya2012@gmail.com]
Sent: Friday, February 14, 2014 12:36 PM
To: Dhc Chairs
Cc: dhcwg@ietf.o= rg
Subject: Fwd: New Version Notification for draft-sarikaya-nvo3-dhc-v= xlan-multicast-00.txt

 

Dear Chairs,

We submitted a draft, see below for details.<= u>

Please reserve a shor= t slot in IETF 89.

Note that this is a revised and renamed version of d= raft-sarikaya-dhc-vxlan-multicast-02.


A new version of I-D, draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-sarikaya-nvo3-dhc-vxlan-mult= icast
Revision:       00
Title:          DHCP Options for Configuring Multi= cast Addresses in VXLAN
Document date:  2014-02-14
Group:          Individual Submission
Pages:          12
URL:            http://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-dhc-vxlan-= multicast-00.txt
Status:         https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-dhc-vxlan-multicast/
Htmlized:       http://tools.ietf.org/html/draft-sarikaya-nvo3-dhc-vxlan-multicast-00

Abstract:
   This document defines DHCPv4 and DHCPv6 options for assigning<= br>    multicast addresses for the Tunnel End Point in the Virtual    eXtensible Local Area Network (VXLAN) environments.  New = DHCP options
   are defined which allow a VXLAN Tunnel End Point to request an= y
   source multicast address for the newly created virtual machine= and
   possibly IPv4/IPv6 address(es) for the virtual machine.



Regards,

Frank & Behcet

 


--001a11c24100caff1d04f2c5b62a-- From nobody Wed Feb 19 10:56:41 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421CD1A014C for ; Wed, 19 Feb 2014 10:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_Rj8gvEqfdV for ; Wed, 19 Feb 2014 10:56:34 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C688F1A05EA for ; Wed, 19 Feb 2014 10:56:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26573; q=dns/txt; s=iport; t=1392836191; x=1394045791; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Sr9eL9a2X6AglcIRtbISpYCZ8VPN2kkR2VBynTvvpGk=; b=gn4ZvW2VkCPpoqIHQVVQ7ifRT1ZVKWpcniRTf0UogeHhNib65I8LYh5t wy+M1OKozlXbcCvxtDsX07u6gG+570k3Xnlz++13L7+rQin60WnJP1TZ1 EdG8YHz2AR9wMmyO43tYbSlWUeMhX59B/RiEjVD8LoUZMcmilL6YBvyrM Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4FAF79BFOtJV2d/2dsb2JhbABZgkJEOFe3LIhWgRsWdIIlAQEBBCdHBAUCEAIBCBEDAQEBIQcHIREUCQgCBA4FCYdoAxENxhgNh3AXjE+BMlINBAYBhDgElkSBbIEyiyyFRoMtgWgHOw X-IronPort-AV: E=Sophos;i="4.97,507,1389744000"; d="scan'208,217";a="305178022" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 19 Feb 2014 18:56:30 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1JIuTnE015616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 18:56:30 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 12:56:29 -0600 From: "Bernie Volz (volz)" To: "sarikaya@ieee.org" Thread-Topic: New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt Thread-Index: AQHPKatLZhldDjj24E2PHlohRA8PqZq1Mr0AgAgOcwD//8TQgA== Date: Wed, 19 Feb 2014 18:56:29 +0000 Message-ID: References: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1AE72D20@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [161.44.65.111] Content-Type: multipart/alternative; boundary="_000_CF2A661A190C6volzciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/mxwZWgzMl0K_a9n1j4bBkKrtz1I Cc: "dhcwg@ietf.org" , Dhc Chairs Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 18:56:40 -0000 --_000_CF2A661A190C6volzciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >Since we are defining several DHC options and related client/server behavi= our, we thought that it should also be presented in dhc WG, as is customary= , no? It is more important that it be "presented" on the mailing list than necess= arily in a DHC WG session. If the draft is intended to be adopted by DHC WG= , a presentation is typically a good idea to assure people know about it. B= ut it is not required. Also, we are trying to move "simple" options (I.e., = those that do not have an special processing requirements and follow the Op= tion Guidelines drafts) work out of the DHC WG as other working groups shou= ld be able to handle those following the Option Guidelines. >Yes, I think this is another way of doing it. Is there a preference by dhc= WG on which way we should have it in the draft? For options which are only intended for the information to go one way (I.e.= , server to client), having the client request the option in the PRL/ORO is= the way to go; there's no benefit in having the client send the option. On= ly if the client must present some data to the server which the server need= s to process the request, does it make sense for the client to include it (= and in that case, either using two options (client -> server; server -> cli= ent) or using optional fields in the option makes more sense). >VNI is of size 24-bits, i.e. 3 octets. In DHCPv4 a4 is always set to zer= o. Maybe we don't need to have a4, I thought DHCPv4 options are always give= n in 4-octets? Field should be the size that the data is =96 padding isn't necessary. Alig= nment does make drawing the option diagrams easier, but there's really no b= enefit in client or server processing and it makes the packets larger for n= o good reason. So, if a field is 24-bits, only use 24-bits. (The examples t= ypically used are for 8-bit, 16-bit, or 32-bit values as those line up with= what usually makes the most sense, but that doesn't mean other sizes are n= ot allowed.) >4. There=92s no relay option =85 perhaps that is intentional but can= the client=92s =93Network Identifier=94 option value be trusted? Would it = make sense for a relay to provide this? Or is this something only the clien= t would know and therefore it has to be trusted? >We can clarify and say that the client MUST set it to zero, would that be = OK? I am not sure how this relates to my concern about whether a client or rela= y is best to provide this information. If the client has it and needs it, t= hen client <-> server makes most sense. I suspect that this is a case where= this is just client <-> server and relay is not involved. - Bernie From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Wednesday, February 19, 2014 12:28 PM To: Cisco Employee > Cc: Dhc Chairs = >, "dhcwg@ietf.org" > Subject: Re: New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-mul= ticast-00.txt Hi Bernie, Thanks for your review, sorry for the delay in my reply, apologies. Please see my replies inline. Regards, Behcet On Fri, Feb 14, 2014 at 2:46 PM, Bernie Volz (volz) > wrote: Behcet: Just so we can properly prioritize (though at present we seem to have suffi= cient time), is this intended to be an informational presentation, or do yo= u have issues to discuss/resolve? We=92ll give preference to those drafts t= hat have issues to discuss/resolve. Since we are defining several DHC options and related client/server behavio= ur, we thought that it should also be presented in dhc WG, as is customary,= no? Also, as this is now (I think) primarily targeted for the NVO3 (Network Vir= tualization Overlays) WG, is there anything of significance to discuss in D= HC =96 there does seem to be some server processing involved as the client = supplied option triggers the server to return a specific multicast address. The aim is to get dhc specific comments about our draft, much like what you= did below. A few comments from a quick look at the document: 1. Why does the client set the address to 0 in the address option? Wh= y have the client include this option at all (server can just add it either= because the network identifier option is present or as client can request = in PRL/ORO)? Yes, I think this is another way of doing it. Is there a preference by dhc = WG on which way we should have it in the draft? 2. The option lengths are wrong? In DHCPv6 (& DHCPv4), the option len= gth covers just the data itself (not the option code and option type). OK, to be corrected. 3. Why is the =93VXLAN Identifier=94 apparently 3 bytes for the DHCPv= 6 option and 4 bytes for the DHCPv4 option? What is the relationship betwee= n this VXLAN Identifier and the =9324-bit Virtual Subnet Identifier (VSID)= =94? It does state =93Note that VSID is simlar to VNI=94 =96 but that is st= ill something different than the VXLAN Identifier (though even earlier is s= tated =93VXLAN header contains 24-bit VNI=94). So I would guess this is 3 b= yte (octet) field and this is the VNI? Why call it something else then? VNI is of size 24-bits, i.e. 3 octets. In DHCPv4 a4 is always set to zero= . Maybe we don't need to have a4, I thought DHCPv4 options are always given= in 4-octets? 4. There=92s no relay option =85 perhaps that is intentional but can = the client=92s =93Network Identifier=94 option value be trusted? Would it m= ake sense for a relay to provide this? Or is this something only the client= would know and therefore it has to be trusted? We can clarify and say that the client MUST set it to zero, would that be O= K? Probably some of the above is because of my lack of understanding of this e= ntire space. Thanks again for taking the time and giving us very nice feedback. - Bernie From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Sent: Friday, February 14, 2014 12:36 PM To: Dhc Chairs Cc: dhcwg@ietf.org Subject: Fwd: New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-mu= lticast-00.txt Dear Chairs, We submitted a draft, see below for details. Please reserve a short slot in IETF 89. Note that this is a revised and renamed version of draft-sarikaya-dhc-vxlan= -multicast-02. A new version of I-D, draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Name: draft-sarikaya-nvo3-dhc-vxlan-multicast Revision: 00 Title: DHCP Options for Configuring Multicast Addresses in VXLAN Document date: 2014-02-14 Group: Individual Submission Pages: 12 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-dhc= -vxlan-multicast-00.txt Status: https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-dhc-vx= lan-multicast/ Htmlized: http://tools.ietf.org/html/draft-sarikaya-nvo3-dhc-vxlan-mu= lticast-00 Abstract: This document defines DHCPv4 and DHCPv6 options for assigning multicast addresses for the Tunnel End Point in the Virtual eXtensible Local Area Network (VXLAN) environments. New DHCP options are defined which allow a VXLAN Tunnel End Point to request any source multicast address for the newly created virtual machine and possibly IPv4/IPv6 address(es) for the virtual machine. Regards, Frank & Behcet --_000_CF2A661A190C6volzciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
>Since we are defining several DHC options and related client/serve= r behaviour, we thought that it should also be presented in dhc WG, as is c= ustomary, no?

It is more important that it be "presented" on the mailing l= ist than necessarily in a DHC WG session. If the draft is intended to be ad= opted by DHC WG, a presentation is typically a good idea to assure people k= now about it. But it is not required. Also, we are trying to move "simple" options (I.e., those that do not = have an special processing requirements and follow the Option Guidelines dr= afts) work out of the DHC WG as other working groups should be able to hand= le those following the Option Guidelines.

>Yes, I think this is another way of doing it. Is there a preferenc= e by dhc WG on which way we should have it in the draft?

For options which are only intended for the information to go one way = (I.e., server to client), having the client request the option in the PRL/O= RO is the way to go; there's no benefit in having the client send the optio= n. Only if the client must present some data to the server which the server needs to process the request, doe= s it make sense for the client to include it (and in that case, either usin= g two options (client -> server; server -> client) or using optional = fields in the option makes more sense).

>VNI is of size 24-bits, i.e. 3 octets. In DHCPv4   a4 is alwa= ys set to zero. Maybe we don't need to have a4, I thought DHCPv4 options ar= e always given in 4-octets?

Field should be the size that the data is =96 padding isn't necessary.= Alignment does make drawing the option diagrams easier, but there's really= no benefit in client or server processing and it makes the packets larger = for no good reason. So, if a field is 24-bits, only use 24-bits. (The examples typically used are for 8-bit, = 16-bit, or 32-bit values as those line up with what usually makes the most = sense, but that doesn't mean other sizes are not allowed.)


>4.   = ;    There=92s no relay option =85 perhaps that is= intentional but can the client=92s =93Network Identifier=94 option value be trusted? W= ould it make sense for a relay to provide this? Or is this something only t= he client would know and therefore it has to be trusted?

>We can clarify and say that the client MUST set it to zero, would = that be OK?

I am not sure how this relates to my concern about whether a client or= relay is best to provide this information. If the client has it and needs = it, then client <-> server makes most sense. I suspect that this is a= case where this is just client <-> server and relay is not involved.

- Bernie

From: Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Wednesday, February 19, 2014 = 12:28 PM
To: Cisco Employee <volz@cisco.com>
Cc: Dhc Chairs <dhc-chairs@tools.ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: New Version Notificati= on for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt

Hi Bernie,

Thanks for your review, sorry for the delay in my reply, apologies.

Please see my replies inline.

Regards,

Behcet


On Fri, Feb 14, 2014 at 2:46 PM, Bernie Volz (vo= lz) <volz@cisco.com&= gt; wrote:

Behcet:

 

Just so we can properly prioritize= (though at present we seem to have sufficient time), is this intended to b= e an informational presentation, or do you have issues to discuss/resolve? We=92ll give preference to those dr= afts that have issues to discuss/resolve.

 


Since we are defining several DHC options and related client/server be= haviour, we thought that it should also be presented in dhc WG, as is custo= mary, no?

Also, as this is now (I think) pri= marily targeted for the NVO3 (Network Virtualization Overlays) WG, is there= anything of significance to discuss in DHC =96 there does seem to be some server processing involved as the cl= ient supplied option triggers the server to return a specific multicast add= ress.

 


The aim is to get dhc specific comments about our draft, much like wha= t you did below. 

A few comments from a quick look a= t the document:

1.     &= nbsp; Why does the client set the a= ddress to 0 in the address option? Why have the client include this option = at all (server can just add it either because the network identifier option is present or as client can request = in PRL/ORO)?


Yes, I think this is another way of doing it. Is there a preference by= dhc WG on which way we should have it in the draft?
 

2.     &= nbsp; The option lengths are wrong?= In DHCPv6 (& DHCPv4), the option length covers just the data itself (n= ot the option code and option type).

OK, to be corrected.

3.     &= nbsp; Why is the =93VXLAN Identifie= r=94 apparently 3 bytes for the DHCPv6 option and 4 bytes for the DHCPv4 op= tion? What is the relationship between this VXLAN Identifier and the =9324-bit Virtual Subnet Identifier (VSID)= =94? It does state =93Note that VSID is simlar to VNI=94 =96 but that is st= ill something different than the VXLAN Identifier (though even earlier is s= tated =93VXLAN header contains 24-bit VNI=94). So I would guess this is 3 byte (octet) field and this is the VNI? Why call i= t something else then?


VNI is of size 24-bits, i.e. 3 octets. In DHCPv4   a4 is always s= et to zero. Maybe we don't need to have a4, I thought DHCPv4 options are al= ways given in 4-octets?


4.     &= nbsp; There=92s no relay option =85= perhaps that is intentional but can the client=92s =93Network Identifier= =94 option value be trusted? Would it make sense for a relay to provide this? Or is this something only the client would kn= ow and therefore it has to be trusted?


We can clarify and say that the client MUST set it to zero, would that= be OK?
 

Probably some of the above is beca= use of my lack of understanding of this entire space.<= /p>

 


Thanks again for taking the time and giving us very nice feedback.
 

-     &n= bsp;    Bernie

 

From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
Sent: Friday, February 14, 2014 12:36 PM
To: Dhc Chairs
Cc: dhcwg@ietf.o= rg
Subject: Fwd: New Version Notification for draft-sarikaya-nvo3-dhc-v= xlan-multicast-00.txt

 

Dear Chairs,

We submitted a draft, see below for details.<= u>

Please reserve a shor= t slot in IETF 89.

Note that this is a revised and renamed version of d= raft-sarikaya-dhc-vxlan-multicast-02.


A new version of I-D, draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-sarikaya-nvo3-dhc-vxlan-mult= icast
Revision:       00
Title:          DHCP Options for Configuring Multi= cast Addresses in VXLAN
Document date:  2014-02-14
Group:          Individual Submission
Pages:          12
URL:            http://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-dhc-vxlan-= multicast-00.txt
Status:         https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-dhc-vxlan-multicast/
Htmlized:       http://tools.ietf.org/html/draft-sarikaya-nvo3-dhc-vxlan-multicast-00

Abstract:
   This document defines DHCPv4 and DHCPv6 options for assigning<= br>    multicast addresses for the Tunnel End Point in the Virtual    eXtensible Local Area Network (VXLAN) environments.  New = DHCP options
   are defined which allow a VXLAN Tunnel End Point to request an= y
   source multicast address for the newly created virtual machine= and
   possibly IPv4/IPv6 address(es) for the virtual machine.



Regards,

Frank & Behcet

 


 --_000_CF2A661A190C6volzciscocom_-- From nobody Wed Feb 19 11:19:57 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6265A1A00F2 for ; Wed, 19 Feb 2014 11:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soFq2UEj0MSR for ; Wed, 19 Feb 2014 11:19:55 -0800 (PST) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 282071A04F4 for ; Wed, 19 Feb 2014 11:19:55 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1984D1B826F for ; Wed, 19 Feb 2014 11:19:52 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id DF084190052; Wed, 19 Feb 2014 11:19:51 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Feb 2014 11:19:51 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Wed, 19 Feb 2014 14:19:49 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1AE72D20@xmb-rcd-x04.cisco.com> To: Bernie Volz X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/29ezI_MaxWjoq5iA3DhQ4Uj6-so Cc: "dhcwg@ietf.org" , Dhc Chairs Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 19:19:56 -0000 Before the working group hears a presentation on this, it would be good = if Behcet could answer the question I asked on the mailing list. If = the draft isn't important enough to discuss on the mailing list, it = surely doesn't need time on the schedule in London! From nobody Wed Feb 19 11:28:27 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56191A01F0 for ; Wed, 19 Feb 2014 11:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_VITY1P0kA3 for ; Wed, 19 Feb 2014 11:28:21 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBAE1A05BB for ; Wed, 19 Feb 2014 11:28:20 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id c11so638303lbj.31 for ; Wed, 19 Feb 2014 11:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Ux4PuMrh7SKyeOkjo/zKF332xP/o2djnzgQMWgXizgE=; b=GwsqQ0sgPtYVm4jtYvRrbuWeL2aS+bxKMg7YkdkfmN1NtM2DNgngnhwuru4kQYmaF7 xeGHIhgwZonhE/si1DX5V5STfhyfm0BMbsm2ZTQ0CdFB3fgFsGrId80K279QnZAxr8+8 g+8khmureqYN44Vs+niZM/gQooVnyWWjELvuzFInqSywVUVbnb7eDIAB0cJJTV6XgtxO mbPTfjVcBi5H2yDwGCdUjFFMSceoAs4+nSPfb+C2qHgizAoKM6dRivG44NNEddBn2ko/ qo3NJ2mFki5HxhmUg+ZPXR1/KaV1h1Mi4AE9C7/ayDpxTzFW58xKfrztOOTVF4flTDhm t3VQ== MIME-Version: 1.0 X-Received: by 10.152.3.99 with SMTP id b3mr2238895lab.61.1392838097147; Wed, 19 Feb 2014 11:28:17 -0800 (PST) Received: by 10.114.170.195 with HTTP; Wed, 19 Feb 2014 11:28:17 -0800 (PST) In-Reply-To: References: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1AE72D20@xmb-rcd-x04.cisco.com> Date: Wed, 19 Feb 2014 13:28:17 -0600 Message-ID: From: Behcet Sarikaya To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=089e01419fe2029cdc04f2c7646c Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/et773i5nCv6fdRGhwBhQNwqRqsY Cc: "dhcwg@ietf.org" , Dhc Chairs Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 19:28:26 -0000 --089e01419fe2029cdc04f2c7646c Content-Type: text/plain; charset=ISO-8859-1 Hi Bernie, We will revise the draft based on your review (see inline below). Of course more comments are always welcome. As for the presentation, we leave it up to you. Regards, Behcet On Wed, Feb 19, 2014 at 12:56 PM, Bernie Volz (volz) wrote: > >Since we are defining several DHC options and related client/server > behaviour, we thought that it should also be presented in dhc WG, as is > customary, no? > > It is more important that it be "presented" on the mailing list than > necessarily in a DHC WG session. If the draft is intended to be adopted by > DHC WG, a presentation is typically a good idea to assure people know about > it. But it is not required. Also, we are trying to move "simple" options > (I.e., those that do not have an special processing requirements and follow > the Option Guidelines drafts) work out of the DHC WG as other working > groups should be able to handle those following the Option Guidelines. > > >Yes, I think this is another way of doing it. Is there a preference by > dhc WG on which way we should have it in the draft? > > For options which are only intended for the information to go one way > (I.e., server to client), having the client request the option in the > PRL/ORO is the way to go; there's no benefit in having the client send the > option. Only if the client must present some data to the server which the > server needs to process the request, does it make sense for the client to > include it (and in that case, either using two options (client -> server; > server -> client) or using optional fields in the option makes more sense). > > OK, so we get the client to request it using ORO so the client adds an ORO with OPTION_VNI in the Solicit message. > >VNI is of size 24-bits, i.e. 3 octets. In DHCPv4 a4 is always set to > zero. Maybe we don't need to have a4, I thought DHCPv4 options are always > given in 4-octets? > > Field should be the size that the data is - padding isn't necessary. > Alignment does make drawing the option diagrams easier, but there's really > no benefit in client or server processing and it makes the packets larger > for no good reason. So, if a field is 24-bits, only use 24-bits. (The > examples typically used are for 8-bit, 16-bit, or 32-bit values as those > line up with what usually makes the most sense, but that doesn't mean other > sizes are not allowed.) > > > OK, so I remove a4. > >4. There's no relay option ... perhaps that is intentional but can >> the client's "Network Identifier" option value be trusted? Would it make >> sense for a relay to provide this? Or is this something only the client >> would know and therefore it has to be trusted? >> > >We can clarify and say that the client MUST set it to zero, would that be > OK? > > I think that with ORO, we don't need a relay option, do we? > I am not sure how this relates to my concern about whether a client or > relay is best to provide this information. If the client has it and needs > it, then client <-> server makes most sense. I suspect that this is a case > where this is just client <-> server and relay is not involved. > > Sure, it is client <-> server so relay is not involved. Regards, Behcet > - Bernie > > From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Wednesday, February 19, 2014 12:28 PM > To: Cisco Employee > Cc: Dhc Chairs , "dhcwg@ietf.org" < > dhcwg@ietf.org> > Subject: Re: New Version Notification for > draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt > > Hi Bernie, > > Thanks for your review, sorry for the delay in my reply, apologies. > > Please see my replies inline. > > Regards, > > Behcet > > > On Fri, Feb 14, 2014 at 2:46 PM, Bernie Volz (volz) wrote: > >> Behcet: >> >> >> >> Just so we can properly prioritize (though at present we seem to have >> sufficient time), is this intended to be an informational presentation, or >> do you have issues to discuss/resolve? We'll give preference to those >> drafts that have issues to discuss/resolve. >> >> >> > > Since we are defining several DHC options and related client/server > behaviour, we thought that it should also be presented in dhc WG, as is > customary, no? > > Also, as this is now (I think) primarily targeted for the NVO3 >> (Network Virtualization Overlays) WG, is there anything of significance to >> discuss in DHC - there does seem to be some server processing involved as >> the client supplied option triggers the server to return a specific >> multicast address. >> >> >> > > The aim is to get dhc specific comments about our draft, much like what > you did below. > > A few comments from a quick look at the document: >> >> 1. Why does the client set the address to 0 in the address option? >> Why have the client include this option at all (server can just add it >> either because the network identifier option is present or as client can >> request in PRL/ORO)? >> > > Yes, I think this is another way of doing it. Is there a preference by > dhc WG on which way we should have it in the draft? > > >> 2. The option lengths are wrong? In DHCPv6 (& DHCPv4), the >> option length covers just the data itself (not the option code and option >> type). >> > OK, to be corrected. > >> 3. Why is the "VXLAN Identifier" apparently 3 bytes for the >> DHCPv6 option and 4 bytes for the DHCPv4 option? What is the relationship >> between this VXLAN Identifier and the "24-bit Virtual Subnet Identifier >> (VSID)"? It does state "Note that VSID is simlar to VNI" - but that is >> still something different than the VXLAN Identifier (though even earlier is >> stated "VXLAN header contains 24-bit VNI"). So I would guess this is 3 byte >> (octet) field and this is the VNI? Why call it something else then? >> > > VNI is of size 24-bits, i.e. 3 octets. In DHCPv4 a4 is always set to > zero. Maybe we don't need to have a4, I thought DHCPv4 options are always > given in 4-octets? > > > 4. There's no relay option ... perhaps that is intentional but can >> the client's "Network Identifier" option value be trusted? Would it make >> sense for a relay to provide this? Or is this something only the client >> would know and therefore it has to be trusted? >> > > We can clarify and say that the client MUST set it to zero, would that > be OK? > > >> Probably some of the above is because of my lack of understanding of >> this entire space. >> >> >> > > Thanks again for taking the time and giving us very nice feedback. > > >> - Bernie >> >> >> >> *From:* Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >> *Sent:* Friday, February 14, 2014 12:36 PM >> *To:* Dhc Chairs >> *Cc:* dhcwg@ietf.org >> *Subject:* Fwd: New Version Notification for >> draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt >> >> >> >> Dear Chairs, >> >> We submitted a draft, see below for details. >> >> Please reserve a short slot in IETF 89. >> >> Note that this is a revised and renamed version of >> draft-sarikaya-dhc-vxlan-multicast-02. >> >> >> A new version of I-D, draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt >> has been successfully submitted by Behcet Sarikaya and posted to the >> IETF repository. >> >> Name: draft-sarikaya-nvo3-dhc-vxlan-multicast >> Revision: 00 >> Title: DHCP Options for Configuring Multicast Addresses in VXLAN >> Document date: 2014-02-14 >> Group: Individual Submission >> Pages: 12 >> URL: >> http://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-dhc-vxlan-multicast/ >> Htmlized: >> http://tools.ietf.org/html/draft-sarikaya-nvo3-dhc-vxlan-multicast-00 >> >> >> Abstract: >> This document defines DHCPv4 and DHCPv6 options for assigning >> multicast addresses for the Tunnel End Point in the Virtual >> eXtensible Local Area Network (VXLAN) environments. New DHCP options >> are defined which allow a VXLAN Tunnel End Point to request any >> source multicast address for the newly created virtual machine and >> possibly IPv4/IPv6 address(es) for the virtual machine. >> >> >> >> Regards, >> >> Frank & Behcet >> >> >> > > --089e01419fe2029cdc04f2c7646c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Bernie,

We will revise= the draft based on your review (see inline below). Of course   m= ore comments are always welcome.

As for the presentation, we l= eave it up to you.

Regards,

Behcet


On Wed, Feb 19, = 2014 at 12:56 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
>Since we are defining several DHC options and related client/serve= r behaviour, we thought that it should also be presented in dhc WG, as is c= ustomary, no?

It is more important that it be "presented" on the mai= ling list than necessarily in a DHC WG session. If the draft is intended to= be adopted by DHC WG, a presentation is typically a good idea to assure pe= ople know about it. But it is not required. Also, we are trying to move "simple" options (I.e., those that do not = have an special processing requirements and follow the Option Guidelines dr= afts) work out of the DHC WG as other working groups should be able to hand= le those following the Option Guidelines.

>Yes, I think this is another way of doing it. Is there a preferenc= e by dhc WG on which way we should have it in the draft?

For options which are only intended for the information to go on= e way (I.e., server to client), having the client request the option in the= PRL/ORO is the way to go; there's no benefit in having the client send= the option. Only if the client must present some data to the server which the server needs to process the request, doe= s it make sense for the client to include it (and in that case, either usin= g two options (client -> server; server -> client) or using optional = fields in the option makes more sense).


OK, so we get t= he client to request it using ORO
so the client adds an ORO w= ith OPTION_VNI in the Solicit message.
 
>VNI is of size 24-bits, i.e. 3 octets. In DHCPv4   a4 is alwa= ys set to zero. Maybe we don't need to have a4, I thought DHCPv4 option= s are always given in 4-octets?

Field should be the size that the data is – padding isn= 9;t necessary. Alignment does make drawing the option diagrams easier, but = there's really no benefit in client or server processing and it makes t= he packets larger for no good reason. So, if a field is 24-bits, only use 24-bits. (The examples typically used are for 8-bit, = 16-bit, or 32-bit values as those line up with what usually makes the most = sense, but that doesn't mean other sizes are not allowed.)



OK, so I remove= a4.
 
<= div style=3D"font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-= word">

>4.   &nb= sp;   There’s no relay option … perhaps that is i= ntentional but can the client’s “Network Identifier” option value b= e trusted? Would it make sense for a relay to provide this? Or is this some= thing only the client would know and therefore it has to be trusted?=

>We can clarify and say that the client MUST set it to zero, would = that be OK?


I think that wi= th ORO, we don't need a relay option, do we?

 
I am not sure how this relates to my concern about whether a cli= ent or relay is best to provide this information. If the client has it and = needs it, then client <-> server makes most sense. I suspect that thi= s is a case where this is just client <-> server and relay is not involved.


Sure, it is client &l= t;-> server so relay is not involved.

Regards,

=
Behcet
- Bernie

From: Behcet Sarikaya <sarikaya2012@gmail.com= >
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org> Date: Wednesday, February 19, 2014 = 12:28 PM
To: Cisco Employee <volz@cisco.com>
Cc: Dhc Chairs <dhc-chairs@tools.ietf.org>, "dhcwg@ietf= .org" <dhcw= g@ietf.org>
Subject: Re: New Version Notificati= on for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt

Hi Bernie,

Thanks for your review, sorry for the delay in my reply, apologies.

Please see my replies inline.

Regards,

Behcet


On Fri, Feb 14, 2014 at 2:46 PM, Bernie Volz (vo= lz) <volz@cisco.com&= gt; wrote:

Behcet:

 

Just so we can properly prioritize (though a= t present we seem to have sufficient time), is this intended to be an infor= mational presentation, or do you have issues to discuss/resolve? We’ll give preference to thos= e drafts that have issues to discuss/resolve.

 


Since we are defining several DHC options and related client/server be= haviour, we thought that it should also be presented in dhc WG, as is custo= mary, no?

Also, as this is now (I think) primarily tar= geted for the NVO3 (Network Virtualization Overlays) WG, is there anything = of significance to discuss in DHC – there does seem to be some server processing involved as th= e client supplied option triggers the server to return a specific multicast= address.

 


The aim is to get dhc specific comments about our draft, much like wha= t you did below. 

A few comments from a quick look at the docu= ment:

1.     &= nbsp; Why does the client set the address to = 0 in the address option? Why have the client include this option at all (se= rver can just add it either because the network identifier option is present or as client can request = in PRL/ORO)?


Yes, I think this is another way of doing it. Is there a preference by= dhc WG on which way we should have it in the draft?
 

2.     &= nbsp; The option lengths are wrong? In DHCPv6= (& DHCPv4), the option length covers just the data itself (not the opt= ion code and option type).

OK, to be corrected.

3.     &= nbsp; Why is the “VXLAN Identifier&rdqu= o; apparently 3 bytes for the DHCPv6 option and 4 bytes for the DHCPv4 opti= on? What is the relationship between this VXLAN Identifier and the “24-bit Virtual Subnet Identifier (VSI= D)”? It does state “Note that VSID is simlar to VNI” &nda= sh; but that is still something different than the VXLAN Identifier (though= even earlier is stated “VXLAN header contains 24-bit VNI”). So I would guess this is 3 byte (octet) field and this is the VNI? Why call i= t something else then?


VNI is of size 24-bits, i.e. 3 octets. In DHCPv4   a4 is always s= et to zero. Maybe we don't need to have a4, I thought DHCPv4 options ar= e always given in 4-octets?


4.     &= nbsp; There’s no relay option … = perhaps that is intentional but can the client’s “Network Ident= ifier” option value be trusted? Would it make sense for a relay to provide this? Or is this something only the client would kn= ow and therefore it has to be trusted?


We can clarify and say that the client MUST set it to zero, would that= be OK?
 

Probably some of the above is because of my = lack of understanding of this entire space.

 


Thanks again for taking the time and giving us very nice feedback.
 

-     &n= bsp;    Bernie

 

From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
Sent: Friday, February 14, 2014 12:36 PM
To: Dhc Chairs
Cc: dhcwg@ietf.o= rg
Subject: Fwd: New Version Notification for draft-sarikaya-nvo3-dhc-v= xlan-multicast-00.txt

 

Dear Chairs,<= /u>

We submitted a draft, see below for details.<= u>

Please reserve a short = slot in IETF 89.

Note that this is a revised and renamed version of d= raft-sarikaya-dhc-vxlan-multicast-02.


A new version of I-D, draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-sarikaya-nvo3-dhc-vxlan-mult= icast
Revision:       00
Title:          DHCP Options for Configuring Multi= cast Addresses in VXLAN
Document date:  2014-02-14
Group:          Individual Submission
Pages:          12
URL:            http://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-dhc-vxlan-= multicast-00.txt
Status:         https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-dhc-vxlan-multicast/
Htmlized:       http://tools.ietf.org/html/draft-sarikaya-nvo3-dhc-vxlan-multicast-00

Abstract:
   This document defines DHCPv4 and DHCPv6 options for assigning<= br>    multicast addresses for the Tunnel End Point in the Virtual    eXtensible Local Area Network (VXLAN) environments.  New = DHCP options
   are defined which allow a VXLAN Tunnel End Point to request an= y
   source multicast address for the newly created virtual machine= and
   possibly IPv4/IPv6 address(es) for the virtual machine.



Regards,

Frank & Behcet

 

--089e01419fe2029cdc04f2c7646c-- From nobody Wed Feb 19 12:16:15 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B051A022E for ; Wed, 19 Feb 2014 12:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJC3eBnlHZRQ for ; Wed, 19 Feb 2014 12:16:13 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 935F31A0167 for ; Wed, 19 Feb 2014 12:16:12 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id w7so663017lbi.7 for ; Wed, 19 Feb 2014 12:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jrfvJOdzWGOaDg2pnE2wlFXCo1TEt3ib33KVN76b9Wg=; b=kBy6zO94YKnkLftI3Nbhiuv2iTkjLOJ72oBD0rRmTtPB82ikHgMRJ8lx8k16Igy+zV ULR9q3Mrt14FYos3rv92nXofsN5dgqrttQivsuV6fz7ln5el+0P7qyu31DRd6kuzFOeh LJdcPGRcIACRH74+Ogjzup75KXvXgEA+UGyJZTU8r3VIT7bWwojCJeT8JvDscweNvEKX wnmI5WrW+x7gHq7jfwO5IvgkvM2oXdjpkbWzghTtnEtfG5oT1Cy/gFCbfMygA2wwDd5Z SGoTag9KrCr0sx/HhqFo8CgZLvbgeeLBV+WWEVP6WGsODqIbESZswJ7Wf4505OmIphmG 8tsA== MIME-Version: 1.0 X-Received: by 10.152.164.199 with SMTP id ys7mr27496504lab.31.1392840968422; Wed, 19 Feb 2014 12:16:08 -0800 (PST) Received: by 10.114.170.195 with HTTP; Wed, 19 Feb 2014 12:16:08 -0800 (PST) In-Reply-To: <2D6D46E6-15C5-4465-843B-3FECA8DC729D@nominum.com> References: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> <2D6D46E6-15C5-4465-843B-3FECA8DC729D@nominum.com> Date: Wed, 19 Feb 2014 14:16:08 -0600 Message-ID: From: Behcet Sarikaya To: Ted Lemon Content-Type: multipart/alternative; boundary=001a1134962626cae704f2c80fd8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Q7MgKDDQ4ApYCLyBC4tbGInpqzw Cc: "dhcwg@ietf.org" , Dhc Chairs Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 20:16:14 -0000 --001a1134962626cae704f2c80fd8 Content-Type: text/plain; charset=ISO-8859-1 Hi Ted, Apologies for my very belated reply. Just now I saw your message. Thanks for reminding it. Please see inline. Regards, Behcet On Mon, Feb 17, 2014 at 12:00 PM, Ted Lemon wrote: > On Feb 14, 2014, at 12:36 PM, Behcet Sarikaya > wrote: > > New DHCP options > > are defined which allow a VXLAN Tunnel End Point to request any > > source multicast address for the newly created virtual machine and > > possibly IPv4/IPv6 address(es) for the virtual machine. > > This sounds like another set of stateful DHCP options. Why not just use > regular DHCP IA_NA or IA_PD? > > For IA_NA, are you suggesting to use this option to get multicast addresses? I think that IA_NA is defined for unicast addresses. The other option we need is for VXLAN Network Identifier (VNI) which is certainly not an address. For IA_PD, I believe also is not appropriate to request multicast address to be assigned, as it is not related to prefix delegation. Please advise. --001a1134962626cae704f2c80fd8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ted,

Apologies for my = very belated reply. Just now I saw your message. Thanks for reminding it.
Please see inline.

Regards,

Behcet


On Mon, Feb 1= 7, 2014 at 12:00 PM, Ted Lemon <ted.lemon@nominum.com> w= rote:
On Feb 14, 2014, at 12:36 PM= , Behcet Sarikaya <sarikaya201= 2@gmail.com> wrote:
> New DHCP options
> =A0 =A0are defined which allow a VXLAN Tunnel End Point to request any=
> =A0 =A0source multicast address for the newly created virtual machine = and
> =A0 =A0possibly IPv4/IPv6 address(es) for the virtual machine.

This sounds like another set of stateful DHCP options. =A0 Why not ju= st use regular DHCP IA_NA or IA_PD?


For IA_NA, are you = suggesting to use this option to get multicast addresses?
I think that IA_NA is defined for unicast addresses.

=A0
The other option we need is for VXLAN Network Identifier (VNI) w= hich is certainly not an address.

F= or IA_PD, I believe also is not appropriate to request multicast address to= be assigned, as it is not related to prefix delegation.

Please advise.


--001a1134962626cae704f2c80fd8-- From nobody Wed Feb 19 13:54:19 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F8C1A04FB for ; Wed, 19 Feb 2014 13:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMATrnyU3O7v for ; Wed, 19 Feb 2014 13:54:15 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id B384D1A04CB for ; Wed, 19 Feb 2014 13:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2626; q=dns/txt; s=iport; t=1392846852; x=1394056452; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+jOQ4uURmSXbDi1KOEv5A1PJyST85TPAjmiwTmWe0F4=; b=c+szU8m8Y/kACtPy4mD/Y7In41OLKpyofTqbFuFTP6H+jA7oAPuq5ey2 rk/FeFn7w70fKHl5IiDO6RHLS9OMBB5YQbYn9mdtoO3g+d/jK8FLTC2qS 3W1KPP5C+KRexWBEdoxhmhrjIw583C6QHnz/tDjP0R+FuoQXf+oEsBmP5 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFALYnBVOtJV2d/2dsb2JhbABZgwY4V8AHgR0WdIIlAQEBBAEBATc0CQIMBAIBCBEEAQELFAkHJwsUCQgCBA4FCBOHag3OLRMEjgIOAwEfMQcGgx6BFASUA5ZRgW+BPoFxOQ X-IronPort-AV: E=Sophos;i="4.97,508,1389744000"; d="scan'208";a="21709166" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 19 Feb 2014 21:54:10 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1JLsAIU005331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 21:54:10 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 15:54:10 -0600 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt Thread-Index: AQHPKatLZhldDjj24E2PHlohRA8PqZq1Mr0AgAgOcwD//8TQgIAAWluA//+cQLA= Date: Wed, 19 Feb 2014 21:54:09 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE9FC65@xmb-rcd-x04.cisco.com> References: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1AE72D20@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.65.111] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/CpeYTH5ffY75JAO80vawqN-JLsQ Cc: "dhcwg@ietf.org" , Dhc Chairs Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 21:54:17 -0000 I agree. Though there now has been some discussion :). As this is now targeted at nvo3, I don't see a strong need for a presentati= on in dhc at this time. If the nvo3 adopts this work (i.e., believes it is = a problem that needs a solution), we can revisit for a future presentation?= Of course, you should continue to make the dhc aware of the progress of th= is draft and collecting input when offered or if you raise specific issues = or questions. It is odd that this isn't on the nvo3 agenda (at least at present), as it w= ould seem to be more appropriate there as the intended WG. --- General comment about many individual drafts: I think that people that submit individual drafts don't always take the nex= t [manual] step to notify the DHC WG of that draft. They (mistakenly) belie= ve somehow that the "group" is notified when it isn't (the main ietf mailin= g list gets the notice, but not the dhc wg). I would highly recommend that any new or updated draft posting (whether WG = document or individual) is followed up with an email to the DHC WG: - for new drafts, explain it (perhaps by using the abstract or introduction= ) and why you feel it is important to the WG and what you want the WG to do= with the draft (if individual). Think of this as presenting the main point= s and what areas you feel the WG may want to review or have a particular co= ncern about. - for updates, indicate what has changed and why. And for individual, again= indicate what you want the WG to do next with the draft. Is it FYI? Is it = because you feel it is ready for adoption and will propose a call shortly? = ... There are some WGs where the chairs do post "a new draft or new revision ha= s been posted" (for individual drafts related to the WG). But in the DHC WG= we assume that the authors will do this and expect them to - the chairs ha= ve enough to do! - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Wednesday, February 19, 2014 2:20 PM To: Bernie Volz (volz) Cc: dhcwg@ietf.org; Dhc Chairs Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-v= xlan-multicast-00.txt Before the working group hears a presentation on this, it would be good if = Behcet could answer the question I asked on the mailing list. If the draf= t isn't important enough to discuss on the mailing list, it surely doesn't = need time on the schedule in London! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Thu Feb 20 09:50:01 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0945C1A021D for ; Thu, 20 Feb 2014 09:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdQoLM_rAFwp for ; Thu, 20 Feb 2014 09:49:58 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id C94F91A0053 for ; Thu, 20 Feb 2014 09:49:57 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id 10so1552501lbg.36 for ; Thu, 20 Feb 2014 09:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nYDdZLYucUYLQdBOVmJFg7NR2GdYqo1pyPKHr06yeT8=; b=Y41uENY52NeHZtiefU52cn+W75Fesg95u+xG9zZh/rhBwfm8+pCvkSDaTeaVw0f9GY mAAWm6+EVNrSYHdCd+LVJk3RL1BkTOeBN9tggnKXL6BlelpQPvZQeUmgOHihjij34xNs Mzr/sQ84GlrekOQoDyMuegBaWW5KXFSjOdjQ97INC5NKfd6EWnFFw1zC2fhMxOSEVFXV hqUMw/IYxFZEF6t2gbmHA3XyjYWeWu12WwxpDJLo7nwe0VmCI/v/0qqBPsRRbipRufKZ 8fY5Kk2QBMThdYVtBRFjRMoQ0TZEO6IMmk/bkX4mW9MgnycYOPD1bj42x6Vo791VGEG1 oC2A== MIME-Version: 1.0 X-Received: by 10.112.41.100 with SMTP id e4mr1768138lbl.84.1392918593493; Thu, 20 Feb 2014 09:49:53 -0800 (PST) Received: by 10.114.170.195 with HTTP; Thu, 20 Feb 2014 09:49:53 -0800 (PST) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AE9FC65@xmb-rcd-x04.cisco.com> References: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1AE72D20@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AE9FC65@xmb-rcd-x04.cisco.com> Date: Thu, 20 Feb 2014 11:49:53 -0600 Message-ID: From: Behcet Sarikaya To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=001a1135e87af7631c04f2da2138 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/GxQtu9YumN4WoUw7o1J2iHZa5XY Cc: "dhcwg@ietf.org" , Dhc Chairs , Ted Lemon Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 17:50:00 -0000 --001a1135e87af7631c04f2da2138 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 19, 2014 at 3:54 PM, Bernie Volz (volz) wrote: > I agree. Though there now has been some discussion :). > > As this is now targeted at nvo3, I don't see a strong need for a > presentation in dhc at this time. If the nvo3 adopts this work (i.e., > believes it is a problem that needs a solution), we can revisit for a > future presentation? Of course, you should continue to make the dhc aware > of the progress of this draft and collecting input when offered or if you > raise specific issues or questions. > > It is odd that this isn't on the nvo3 agenda (at least at present), as it > would seem to be more appropriate there as the intended WG. > > Bernie, I presented it in nvo3 in Vancouver, this time we did not ask a slot. About dhc presentation slot, it is up to you, I remember last time we were assigned a slot but never had a chance. We would like to clarify all the comments made so far, right now Ted's comment has not yet been resolved, we are waiting for his reply. Regards, Behcet > --- > > General comment about many individual drafts: > > I think that people that submit individual drafts don't always take the > next [manual] step to notify the DHC WG of that draft. They (mistakenly) > believe somehow that the "group" is notified when it isn't (the main ietf > mailing list gets the notice, but not the dhc wg). > > I would highly recommend that any new or updated draft posting (whether WG > document or individual) is followed up with an email to the DHC WG: > - for new drafts, explain it (perhaps by using the abstract or > introduction) and why you feel it is important to the WG and what you want > the WG to do with the draft (if individual). Think of this as presenting > the main points and what areas you feel the WG may want to review or have a > particular concern about. > - for updates, indicate what has changed and why. And for individual, > again indicate what you want the WG to do next with the draft. Is it FYI? > Is it because you feel it is ready for adoption and will propose a call > shortly? ... > > There are some WGs where the chairs do post "a new draft or new revision > has been posted" (for individual drafts related to the WG). But in the DHC > WG we assume that the authors will do this and expect them to - the chairs > have enough to do! > > - Bernie > > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon > Sent: Wednesday, February 19, 2014 2:20 PM > To: Bernie Volz (volz) > Cc: dhcwg@ietf.org; Dhc Chairs > Subject: Re: [dhcwg] New Version Notification for > draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt > > Before the working group hears a presentation on this, it would be good if > Behcet could answer the question I asked on the mailing list. If the > draft isn't important enough to discuss on the mailing list, it surely > doesn't need time on the schedule in London! > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --001a1135e87af7631c04f2da2138 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Feb 19, 2014 at 3:54 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
I agree. Though there now has been some disc= ussion :).

As this is now targeted at nvo3, I don't see a strong need for a presen= tation in dhc at this time. If the nvo3 adopts this work (i.e., believes it= is a problem that needs a solution), we can revisit for a future presentat= ion? Of course, you should continue to make the dhc aware of the progress o= f this draft and collecting input when offered or if you raise specific iss= ues or questions.

It is odd that this isn't on the nvo3 agenda (at least at present), as = it would seem to be more appropriate there as the intended WG.


Bernie, I presented it in nvo3 in Vanc= ouver, this time we did not ask a slot. About dhc presentation slot, it is = up to you, I remember last time we were assigned a slot but never had a cha= nce.

We would like to clarify all the comments made so far, right= now Ted's comment has not yet been resolved, we are waiting for his re= ply.

Regards,

Behcet
---

General comment about many individual drafts:

I think that people that submit individual drafts don't always take the= next [manual] step to notify the DHC WG of that draft. They (mistakenly) b= elieve somehow that the "group" is notified when it isn't (th= e main ietf mailing list gets the notice, but not the dhc wg).

I would highly recommend that any new or updated draft posting (whether WG = document or individual) is followed up with an email to the DHC WG:
- for new drafts, explain it (perhaps by using the abstract or introduction= ) and why you feel it is important to the WG and what you want the WG to do= with the draft (if individual). Think of this as presenting the main point= s and what areas you feel the WG may want to review or have a particular co= ncern about.
- for updates, indicate what has changed and why. And for individual, again= indicate what you want the WG to do next with the draft. Is it FYI? Is it = because you feel it is ready for adoption and will propose a call shortly? = ...

There are some WGs where the chairs do post "a new draft or new revisi= on has been posted" (for individual drafts related to the WG). But in = the DHC WG we assume that the authors will do this and expect them to - the= chairs have enough to do!

- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces= @ietf.org] On Behalf Of Ted Lemon
Sent: Wednesday, February 19, 2014 2:20 PM
To: Bernie Volz (volz)
Cc: dhcwg@ietf.org; Dhc Chairs
Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-v= xlan-multicast-00.txt

Before the working group hears a presentation on this, it would be good if = Behcet could answer the question I asked on the mailing list. =A0 If the dr= aft isn't important enough to discuss on the mailing list, it surely do= esn't need time on the schedule in London!

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

--001a1135e87af7631c04f2da2138-- From nobody Thu Feb 20 09:55:47 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3528D1A0149 for ; Thu, 20 Feb 2014 09:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWeRm60jK_Ao for ; Thu, 20 Feb 2014 09:55:42 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 485581A0099 for ; Thu, 20 Feb 2014 09:55:42 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id p9so1570728lbv.20 for ; Thu, 20 Feb 2014 09:55:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=USKsVpXQQP/zwmJZGFU8Hp2OgrusdBT9MUXwXWlyPL0=; b=jViRbiWMT5LIqVn2SJhzHnl09oGVrVGyGzduNmca0dQx/QQ9SpZac+Wde+0cZqs825 KIyc2CaRBs2mnxEgpqchom9kUh13oNINBmzqf4U5XhQafFr3qhYGyYXPP6lsSPObBNbf VdfP5Y118dMDOA/FySox8cTG5zG4cIXJL6zZIVGevpX6OlyHDD8dk2iJHO+c+vBw6Iv1 rcZAThPCYWcfXudV33oMxD63YM+EmJoqCkAtyUi+vWuG/xDC4YvKMkzAql4cwi0RXRoB nVnfoCZUqzNm6H0kh+h4qKS9DQqNU6i/RbyZQd7pV/wZ/rOTvGKzKoYrhCqPpbnzOqnD RBug== MIME-Version: 1.0 X-Received: by 10.152.3.99 with SMTP id b3mr1846380lab.61.1392918937929; Thu, 20 Feb 2014 09:55:37 -0800 (PST) Received: by 10.114.170.195 with HTTP; Thu, 20 Feb 2014 09:55:37 -0800 (PST) In-Reply-To: <2D6D46E6-15C5-4465-843B-3FECA8DC729D@nominum.com> References: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> <2D6D46E6-15C5-4465-843B-3FECA8DC729D@nominum.com> Date: Thu, 20 Feb 2014 11:55:37 -0600 Message-ID: From: Behcet Sarikaya To: Ted Lemon Content-Type: multipart/alternative; boundary=089e01419fe27f0ca704f2da3628 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/bBdYdGQEPSF-FE21wvq3hyl92aQ Cc: "dhcwg@ietf.org" , Dhc Chairs Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 17:55:44 -0000 --089e01419fe27f0ca704f2da3628 Content-Type: text/plain; charset=ISO-8859-1 Hi Ted, On Mon, Feb 17, 2014 at 12:00 PM, Ted Lemon wrote: > On Feb 14, 2014, at 12:36 PM, Behcet Sarikaya > wrote: > > New DHCP options > > are defined which allow a VXLAN Tunnel End Point to request any > > source multicast address for the newly created virtual machine and > > possibly IPv4/IPv6 address(es) for the virtual machine. > > This sounds like another set of stateful DHCP options. Why not just use > regular DHCP IA_NA or IA_PD? > > I discussed this with my co-author, our latest idea is that your comment might be referring to this text we have in the abstract: and possibly IPv4/IPv6 address(es) for the virtual machine. We mentioned this but did not elaborate on it. Yes in this case IA_NA or even IA_PD would need to be used. We will add the text in the next revision, is this OK? Regards, Behcet --089e01419fe27f0ca704f2da3628 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ted,


On Mon, Feb 17, 2014 at 12:00 PM, Ted Lemon <ted.lemo= n@nominum.com> wrote:
On Feb 14= , 2014, at 12:36 PM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:
> New DHCP options
> =A0 =A0are defined which allow a VXLAN Tunnel End Point to request any=
> =A0 =A0source multicast address for the newly created virtual machine = and
> =A0 =A0possibly IPv4/IPv6 address(es) for the virtual machine.

This sounds like another set of stateful DHCP options. =A0 Why not ju= st use regular DHCP IA_NA or IA_PD?


I discussed this wi= th my co-author, our latest idea is that your comment might be referring to= this text we have in the abstract:

and possibly IPv4/IPv6 address(e= s) for the virtual machine.

We mentioned this but did not elaborat= e on it.
Yes in this case IA_NA or even= IA_PD would need to be used.
We will a= dd the text in the next revision, is this OK?

Regards,

Behcet
--089e01419fe27f0ca704f2da3628-- From nobody Thu Feb 20 10:02:54 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB921A0224 for ; Thu, 20 Feb 2014 10:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApRjXWZHRzxV for ; Thu, 20 Feb 2014 10:02:49 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DD6551A0210 for ; Thu, 20 Feb 2014 10:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16385; q=dns/txt; s=iport; t=1392919365; x=1394128965; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nx08ZHVJhr0NL6VTeWEqF+tWw0G8GDkaDqOQR+U0C08=; b=g6e8IFsYCZpjEbgbwECAkDCkC27xE90Z0FVe9zloX3Sb22Rj4fOyYTev OGo+rMFdISF+oJ5cxLZCIWk1GqlIA/xPyr8eF8JibvYE8ODk3/AfDR66H hMEOAHLfchaaQpIcFsyLBLOfT18agQjEEMKrVDPtpsMFxDkw/93q4Ny56 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FABNDBlOtJXG//2dsb2JhbABZgkJEOFfADoEQFnSCJQEBAQIBAQEBASpBCQIFBwQCAQgRBAEBCx0HIQYLFAkIAgQOBQgBEodWAwkIDcZADYdJF4xPgTMOAwEfLQQGAQaDHoEUBJQDgkGOSoVGgW+BPoFxOQ X-IronPort-AV: E=Sophos;i="4.97,513,1389744000"; d="scan'208,217";a="305411770" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 20 Feb 2014 18:02:44 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1KI2iYJ001424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 18:02:44 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 12:02:44 -0600 From: "Bernie Volz (volz)" To: "sarikaya@ieee.org" Thread-Topic: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt Thread-Index: AQHPKatLZhldDjj24E2PHlohRA8PqZq1Mr0AgAgOcwD//8TQgIAAWluA//+cQLCAAdz0gP//nQLQ Date: Thu, 20 Feb 2014 18:02:44 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AEA2CFA@xmb-rcd-x04.cisco.com> References: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1AE72D20@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AE9FC65@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.235] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AEA2CFAxmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/b3pwi7DqpD2Zo5Vz2gsphKuem8c Cc: "dhcwg@ietf.org" , Dhc Chairs , Ted Lemon Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 18:02:52 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AEA2CFAxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > About dhc presentation slot, it is up to you, I remember last time we wer= e assigned a slot but never had a chance. That was actually two IETF's ago (IETF-87, Berlin) that you requested a slo= t but we ran out of time. Your most recent nvo3 presentation is at: http://www.ietf.org/proceedings/88/slides/slides-88-nvo3-7.pdf - Bernie From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Sent: Thursday, February 20, 2014 12:50 PM To: Bernie Volz (volz) Cc: Ted Lemon; dhcwg@ietf.org; Dhc Chairs Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-v= xlan-multicast-00.txt On Wed, Feb 19, 2014 at 3:54 PM, Bernie Volz (volz) > wrote: I agree. Though there now has been some discussion :). As this is now targeted at nvo3, I don't see a strong need for a presentati= on in dhc at this time. If the nvo3 adopts this work (i.e., believes it is = a problem that needs a solution), we can revisit for a future presentation?= Of course, you should continue to make the dhc aware of the progress of th= is draft and collecting input when offered or if you raise specific issues = or questions. It is odd that this isn't on the nvo3 agenda (at least at present), as it w= ould seem to be more appropriate there as the intended WG. Bernie, I presented it in nvo3 in Vancouver, this time we did not ask a slo= t. About dhc presentation slot, it is up to you, I remember last time we we= re assigned a slot but never had a chance. We would like to clarify all the comments made so far, right now Ted's comm= ent has not yet been resolved, we are waiting for his reply. Regards, Behcet --- General comment about many individual drafts: I think that people that submit individual drafts don't always take the nex= t [manual] step to notify the DHC WG of that draft. They (mistakenly) belie= ve somehow that the "group" is notified when it isn't (the main ietf mailin= g list gets the notice, but not the dhc wg). I would highly recommend that any new or updated draft posting (whether WG = document or individual) is followed up with an email to the DHC WG: - for new drafts, explain it (perhaps by using the abstract or introduction= ) and why you feel it is important to the WG and what you want the WG to do= with the draft (if individual). Think of this as presenting the main point= s and what areas you feel the WG may want to review or have a particular co= ncern about. - for updates, indicate what has changed and why. And for individual, again= indicate what you want the WG to do next with the draft. Is it FYI? Is it = because you feel it is ready for adoption and will propose a call shortly? = ... There are some WGs where the chairs do post "a new draft or new revision ha= s been posted" (for individual drafts related to the WG). But in the DHC WG= we assume that the authors will do this and expect them to - the chairs ha= ve enough to do! - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] = On Behalf Of Ted Lemon Sent: Wednesday, February 19, 2014 2:20 PM To: Bernie Volz (volz) Cc: dhcwg@ietf.org; Dhc Chairs Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-v= xlan-multicast-00.txt Before the working group hears a presentation on this, it would be good if = Behcet could answer the question I asked on the mailing list. If the draf= t isn't important enough to discuss on the mailing list, it surely doesn't = need time on the schedule in London! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_489D13FBFA9B3E41812EA89F188F018E1AEA2CFAxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> About dhc pre= sentation slot, it is up to you, I remember last time we were assigned a sl= ot but never had a chance.

 <= /p>

That was actually two IET= F’s ago (IETF-87, Berlin) that you requested a slot but we ran out of= time.

 <= /p>

Your most recent nvo3 pre= sentation is at:

http://www.ietf.org/proce= edings/88/slides/slides-88-nvo3-7.pdf

 <= /p>

- =          Bernie=

 <= /p>

From: Behcet S= arikaya [mailto:sarikaya2012@gmail.com]
Sent: Thursday, February 20, 2014 12:50 PM
To: Bernie Volz (volz)
Cc: Ted Lemon; dhcwg@ietf.org; Dhc Chairs
Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo= 3-dhc-vxlan-multicast-00.txt

 

 

 

On Wed, Feb 19, 2014 at 3:54 PM, Bernie Volz (volz) = <volz@cisco.com&= gt; wrote:

I agree. Though there= now has been some discussion :).

As this is now targeted at nvo3, I don't see a strong need for a presentati= on in dhc at this time. If the nvo3 adopts this work (i.e., believes it is = a problem that needs a solution), we can revisit for a future presentation?= Of course, you should continue to make the dhc aware of the progress of this draft and collecting input w= hen offered or if you raise specific issues or questions.

It is odd that this isn't on the nvo3 agenda (at least at present), as it w= ould seem to be more appropriate there as the intended WG.

 

Bernie, I presented i= t in nvo3 in Vancouver, this time we did not ask a slot. About dhc presenta= tion slot, it is up to you, I remember last time we were assigned a slot bu= t never had a chance.

We would like to clar= ify all the comments made so far, right now Ted's comment has not yet been = resolved, we are waiting for his reply.

Regards,

Behcet

---

General comment about many individual drafts:

I think that people that submit individual drafts don't always take the nex= t [manual] step to notify the DHC WG of that draft. They (mistakenly) belie= ve somehow that the "group" is notified when it isn't (the main i= etf mailing list gets the notice, but not the dhc wg).

I would highly recommend that any new or updated draft posting (whether WG = document or individual) is followed up with an email to the DHC WG:
- for new drafts, explain it (perhaps by using the abstract or introduction= ) and why you feel it is important to the WG and what you want the WG to do= with the draft (if individual). Think of this as presenting the main point= s and what areas you feel the WG may want to review or have a particular concern about.
- for updates, indicate what has changed and why. And for individual, again= indicate what you want the WG to do next with the draft. Is it FYI? Is it = because you feel it is ready for adoption and will propose a call shortly? = ...

There are some WGs where the chairs do post "a new draft or new revisi= on has been posted" (for individual drafts related to the WG). But in = the DHC WG we assume that the authors will do this and expect them to - the= chairs have enough to do!

- Bernie


-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces= @ietf.org] On Behalf Of Ted Lemon
Sent: Wednesday, February 19, 2014 2:20 PM
To: Bernie Volz (volz)
Cc: dhcwg@ietf.org; Dhc Chairs
Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-v= xlan-multicast-00.txt

Before the working group hears a presentation on this, it would be good if = Behcet could answer the question I asked on the mailing list.   If the= draft isn't important enough to discuss on the mailing list, it surely doe= sn't need time on the schedule in London!

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

 

--_000_489D13FBFA9B3E41812EA89F188F018E1AEA2CFAxmbrcdx04ciscoc_-- From nobody Thu Feb 20 10:08:05 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BE51A0235 for ; Thu, 20 Feb 2014 10:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL6WHNfqD9bC for ; Thu, 20 Feb 2014 10:08:01 -0800 (PST) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC831A0232 for ; Thu, 20 Feb 2014 10:07:59 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DA7111B82A3 for ; Thu, 20 Feb 2014 10:07:55 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D325F190052; Thu, 20 Feb 2014 10:07:55 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 20 Feb 2014 10:07:55 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Thu, 20 Feb 2014 13:07:53 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <4A06ECB4-7F41-469A-915E-280C25FE7530@nominum.com> References: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> <2D6D46E6-15C5-4465-843B-3FECA8DC729D@nominum.com> To: "" , Behcet Sarikaya X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/oWOKa8u_B0_actER3acfbplc33M Cc: "dhcwg@ietf.org" , Dhc Chairs Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 18:08:03 -0000 My concern is that I got the impression that the addresses this document = provides need to be tracked by the server, that is that they are = stateful. I'm not sure that's the case=97it just looked that way to = me. As for whether this should get a presentation in the DHC working group, = that is of course up to the chairs, but given that this is work needed = by another working group, it would be nice if the working group chairs = for nvo3 were to tell the working group chairs of dhc that they are = seriously looking to adopt this document as a working group item and = want the DHC working group's advice. Otherwise, what's the point? I = certainly wouldn't support advancing this document in the DHC working = group without such a request, and then only if this is in fact a = stateful option. From nobody Thu Feb 20 10:21:41 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9501A01B6 for ; Thu, 20 Feb 2014 10:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhnOVLNIw-aU for ; Thu, 20 Feb 2014 10:21:38 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2771A019F for ; Thu, 20 Feb 2014 10:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2847; q=dns/txt; s=iport; t=1392920495; x=1394130095; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DLqpaXkkUMFEl25ZN9EHkWU6bbYNdHL4Ab6oDNeAfRo=; b=SFWpfwXAkPknW2Sd0BBIVeNw5nv/XLMcrzYT+J47+xPv5/UheswKEEtW CsO6zT0e41LovvPT0Avc7FVMrwGeMEX0fV6kwenpPVvpuewUV3vK1lqAk heKW9igG1HyMoSnqTWjrU/SpiKq2m8/TsFSDURr236ElWUec+jgXLxSwR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAK1GBlOtJV2Z/2dsb2JhbABZgwaBD8AOgRAWdIIlAQEBAwE6PQIFBwQCAQgRBAEBCxQJBzIUCQgCBAENBQiHdQjONBeOMzEHBoMegRQBA6pUgW+BPoIq X-IronPort-AV: E=Sophos;i="4.97,513,1389744000"; d="scan'208";a="305379894" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 20 Feb 2014 18:21:34 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1KILY8Y019896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 18:21:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 12:21:33 -0600 From: "Bernie Volz (volz)" To: Ted Lemon , "" , Behcet Sarikaya Thread-Topic: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt Thread-Index: AQHPKatLZhldDjj24E2PHlohRA8PqZq+ehIugAAAktA= Date: Thu, 20 Feb 2014 18:21:33 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AEA2DE8@xmb-rcd-x04.cisco.com> References: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> <2D6D46E6-15C5-4465-843B-3FECA8DC729D@nominum.com> <4A06ECB4-7F41-469A-915E-280C25FE7530@nominum.com> In-Reply-To: <4A06ECB4-7F41-469A-915E-280C25FE7530@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Bok_Poo_XqCtegOIF3JK-yvRP50 Cc: "dhcwg@ietf.org" , Dhc Chairs Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 18:21:40 -0000 >My concern is that I got the impression that the addresses this document p= rovides need to be tracked by the server, that is that they are stateful ..= . I don't think that is the case. This is the address of a Rendezvous Point a= nd the multicast group that the client needs to join. I think there is one = set of these for each VNI (VXLAN Network Identifier). So the DHCP server ne= eds to have a mapping from VNI to this information to return it to the clie= nt when requested, and this thus makes more careful review by the dhc likel= y a requirement before it becomes a 'standard'. I'm not exactly sure why this isn't just a property of the scope or prefix = the client is on (i.e., assigned addresses from - or if stateless is used, = the address from which the "inform" is received) and why the VNI would have= to be sent from client to server, but that's probably because of my lack o= f understanding as to this entire area. > As for whether this should get a presentation in the DHC working group ..= . That is also my concern. If nvo3 is not interested in this work, why should= we be? If this were targeted to be adopted by dhc (as it was originally) it would = be more reasonable to request a presentation.=20 However, I think it more appropriate in that this be a nvo3 draft as they b= etter understand whether it is needed and appropriate; the dhc wg should ce= rtainly continue to monitor this work and provide suggestions and recommend= ations with respect to the dhc options format and processing requirements. = Once adopted by nvo3 (or if the nvo3 chairs request an assessment by dhc), = we can certainly take a more careful look including a presentation. - Bernie -----Original Message----- From: Ted Lemon [mailto:ted.lemon@nominum.com]=20 Sent: Thursday, February 20, 2014 1:08 PM To: ; Behcet Sarikaya Cc: dhcwg@ietf.org; Dhc Chairs Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-v= xlan-multicast-00.txt My concern is that I got the impression that the addresses this document pr= ovides need to be tracked by the server, that is that they are stateful. = I'm not sure that's the case-it just looked that way to me. As for whether this should get a presentation in the DHC working group, tha= t is of course up to the chairs, but given that this is work needed by anot= her working group, it would be nice if the working group chairs for nvo3 we= re to tell the working group chairs of dhc that they are seriously looking = to adopt this document as a working group item and want the DHC working gro= up's advice. Otherwise, what's the point? I certainly wouldn't support = advancing this document in the DHC working group without such a request, an= d then only if this is in fact a stateful option. From nobody Thu Feb 20 13:05:26 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1314B1A02E6 for ; Thu, 20 Feb 2014 13:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_X9PN9CGzWC for ; Thu, 20 Feb 2014 13:05:23 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id BACC41A02E0 for ; Thu, 20 Feb 2014 13:05:22 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id mc6so1730772lab.14 for ; Thu, 20 Feb 2014 13:05:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Y7r6jN5BAoCgb7nyGe6Xo2ufIFtZ3THJLP6whkCAnks=; b=DKvkdW1vMfyzyOBEE00/aKytJrTDCtgWR6xvkVLyO81p5hDCOwQcv/GTFwF9nsPfcZ yxzyH90enB/XFXE+aFZhWy8PwQxBpi5xzzPgfbQnAq2cc78WNGpTeMkLWEJAOalqgA82 ht8x1wd3pL0PdzjP6H7goC/bKTO9XNtE9rRvBzPK6sYaJty2RmPkgwByIzXcNu0A+rlj tCFbjNM5dmgImV+8ww/qv16E/F8IURvwmOALBO6CsSeEuxLCtMJNVH3HBfpcxTD/esaM xTe7Sc1gHEOyAzxthtEGLEUrcJUU6A7DXKUZPnOqqgDjS03fBW7EsEHR2kq6OnD1NflD A/EQ== MIME-Version: 1.0 X-Received: by 10.152.164.199 with SMTP id ys7mr2325003lab.31.1392930318205; Thu, 20 Feb 2014 13:05:18 -0800 (PST) Received: by 10.114.170.195 with HTTP; Thu, 20 Feb 2014 13:05:18 -0800 (PST) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AEA2DE8@xmb-rcd-x04.cisco.com> References: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> <2D6D46E6-15C5-4465-843B-3FECA8DC729D@nominum.com> <4A06ECB4-7F41-469A-915E-280C25FE7530@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1AEA2DE8@xmb-rcd-x04.cisco.com> Date: Thu, 20 Feb 2014 15:05:18 -0600 Message-ID: From: Behcet Sarikaya To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=001a11349626d047be04f2dcdc35 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/byruLj-OZ16P-MCSzcVw0nqjwdk Cc: "dhcwg@ietf.org" , Dhc Chairs , Ted Lemon Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 21:05:25 -0000 --001a11349626d047be04f2dcdc35 Content-Type: text/plain; charset=ISO-8859-1 Hi Ted, Bernie, On Thu, Feb 20, 2014 at 12:21 PM, Bernie Volz (volz) wrote: > >My concern is that I got the impression that the addresses this document > provides need to be tracked by the server, that is that they are stateful > ... > > I don't think that is the case. This is the address of a Rendezvous Point > and the multicast group that the client needs to join. I think there is one > set of these for each VNI (VXLAN Network Identifier). So the DHCP server > needs to have a mapping from VNI to this information to return it to the > client when requested, and this thus makes more careful review by the dhc > likely a requirement before it becomes a 'standard'. > > agreed. > I'm not exactly sure why this isn't just a property of the scope or prefix > the client is on (i.e., assigned addresses from - or if stateless is used, > the address from which the "inform" is received) and why the VNI would have > to be sent from client to server, but that's probably because of my lack of > understanding as to this entire area. > > We clarified this, client will not send VNI instead it will ask it with ORO as you suggested. > > As for whether this should get a presentation in the DHC working group > ... > > That is also my concern. If nvo3 is not interested in this work, why > should we be? > > If this were targeted to be adopted by dhc (as it was originally) it would > be more reasonable to request a presentation. > > However, I think it more appropriate in that this be a nvo3 draft as they > better understand whether it is needed and appropriate; the dhc wg should > certainly continue to monitor this work and provide suggestions and > recommendations with respect to the dhc options format and processing > requirements. Once adopted by nvo3 (or if the nvo3 chairs request an > assessment by dhc), we can certainly take a more careful look including a > presentation. > > Agreed. Regards, Behcet > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:ted.lemon@nominum.com] > Sent: Thursday, February 20, 2014 1:08 PM > To: ; Behcet Sarikaya > Cc: dhcwg@ietf.org; Dhc Chairs > Subject: Re: [dhcwg] New Version Notification for > draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt > > My concern is that I got the impression that the addresses this document > provides need to be tracked by the server, that is that they are stateful. > I'm not sure that's the case-it just looked that way to me. > > As for whether this should get a presentation in the DHC working group, > that is of course up to the chairs, but given that this is work needed by > another working group, it would be nice if the working group chairs for > nvo3 were to tell the working group chairs of dhc that they are seriously > looking to adopt this document as a working group item and want the DHC > working group's advice. Otherwise, what's the point? I certainly > wouldn't support advancing this document in the DHC working group without > such a request, and then only if this is in fact a stateful option. > > --001a11349626d047be04f2dcdc35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ted, Bernie,



=
On Thu, Feb 20, 2014 at 12:21 PM, Bernie Volz (v= olz) <volz@cisco.com> wrote:
>My concern is that I got the impression = that the addresses this document provides need to be tracked by the server,= that is that they are stateful ...

I don't think that is the case. This is the address of a Rendezvous Poi= nt and the multicast group that the client needs to join. I think there is = one set of these for each VNI (VXLAN Network Identifier). So the DHCP serve= r needs to have a mapping from VNI to this information to return it to the = client when requested, and this thus makes more careful review by the dhc l= ikely a requirement before it becomes a 'standard'.


agreed.
=A0
I'm not exactly sure why this isn't just a property of the scope or= prefix the client is on (i.e., assigned addresses from - or if stateless i= s used, the address from which the "inform" is received) and why = the VNI would have to be sent from client to server, but that's probabl= y because of my lack of understanding as to this entire area.

We clarified this, client will not send VNI instead i= t will ask it with ORO as you suggested.
=A0
> As for whether this should get a presentation in the DHC working group= ...

That is also my concern. If nvo3 is not interested in this work, why should= we be?

If this were targeted to be adopted by dhc (as it was originally) it would = be more reasonable to request a presentation.

However, I think it more appropriate in that this be a nvo3 draft as they b= etter understand whether it is needed and appropriate; the dhc wg should ce= rtainly continue to monitor this work and provide suggestions and recommend= ations with respect to the dhc options format and processing requirements. = Once adopted by nvo3 (or if the nvo3 chairs request an assessment by dhc), = we can certainly take a more careful look including a presentation.


Agreed.


Regards,=

Behcet
- Bernie

-----Original Message-----
From: Ted Lemon [mailto:ted.lemon@= nominum.com]
Sent: Thursday, February 20, 2014 1:08 PM
To: <sarikaya@ieee.org>; Beh= cet Sarikaya
Cc: dhcwg@ietf.org; Dhc Chairs
Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-v= xlan-multicast-00.txt

My concern is that I got the impression that the addresses this docum= ent provides need to be tracked by the server, that is that they are statef= ul. =A0 I'm not sure that's the case-it just looked that way to me.=

As for whether this should get a presentation in the DHC working group, tha= t is of course up to the chairs, but given that this is work needed by anot= her working group, it would be nice if the working group chairs for nvo3 we= re to tell the working group chairs of dhc that they are seriously looking = to adopt this document as a working group item and want the DHC working gro= up's advice. =A0 Otherwise, what's the point? =A0 I certainly would= n't support advancing this document in the DHC working group without su= ch a request, and then only if this is in fact a stateful option.


--001a11349626d047be04f2dcdc35-- From nobody Fri Feb 21 11:45:50 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928101A021B for ; Fri, 21 Feb 2014 11:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SP6IRMfPzcwN for ; Fri, 21 Feb 2014 11:45:45 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 85C851A01DD for ; Fri, 21 Feb 2014 11:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13281; q=dns/txt; s=iport; t=1393011941; x=1394221541; h=from:to:subject:date:message-id:mime-version; bh=P8UPV3rDYJCnMau90wjHO93xtmMNzav2h6HmKrLI0Tg=; b=WMHRKV5IuEXJYWMX/8/FpbqeQq5pnEc319WbAQWD3+zKLZ51Ur9y8Ys7 xVfDSb7gPmG4ExXmGzjPB2bToYBvSYGqRcMLnv97MNIRkT7FUx8QY/mSg JqBm3LOpkNWcB4FuqYZFWRerDCtNh/wC7W0phD81ggJmSv+oqTsaz0zVZ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFANSrB1OtJV2a/2dsb2JhbABagkJEO1fAPYEPFnSCJQEBAQQtXgEIEQQBAQsdORQJCQEEEwgBh3wNmnSwKxeOECM3gyWBFASUSZYSgy2CKg X-IronPort-AV: E=Sophos; i="4.97,520,1389744000"; d="scan'208,217"; a="22265291" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP; 21 Feb 2014 19:45:41 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1LJjfad019436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 21 Feb 2014 19:45:41 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x04.cisco.com ([::1]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 13:45:40 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: IETF-89 (London) Draft Agenda Thread-Index: Ac8vPRvCH+whCuSOR4SyLiOjqIp1WA== Date: Fri, 21 Feb 2014 19:45:39 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AEA686B@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.235] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AEA686Bxmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/m-srADf1evYQdD2-iJJPlyLuzxc Subject: Re: [dhcwg] IETF-89 (London) Draft Agenda X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:45:48 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AEA686Bxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: The updated proposed agenda is at http://www.ietf.org/proceedings/89/agenda= /agenda-89-dhc. Please verify and let us know of issues or missing items. We hope to post t= he 'final' agenda on Monday. For those on the agenda, please be sure to send us your presentation to upl= oad sufficiently in advance of the meeting (we meet Monday, March 3rd 0900-= 1130 UTC). - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Tuesday, February 11, 2014 5:34 PM To: dhcwg@ietf.org Subject: [dhcwg] IETF-89 (London) Draft Agenda Hi: We published the current draft agenda (it is available at http://www.ietf.o= rg/proceedings/89/agenda/agenda-89-dhc and appears below). If you want time= or you requested time and it isn't there, let us know. If time estimates a= re correct, we are presently using 90 of our 150 minutes. Please note that = this is a draft agenda and we may rearrange the order (as well as add or re= move items). - Tomek & Bernie ** DRAFT ** DHC WG Agenda for IETF-89 (London) MONDAY, March 3, 2014, 0900-1130 (subject to change) Chairs: Tomek Mrugalski & Bernie Volz Presentations materials: https://datatracker.ietf.org/meeting/89/materials.= html#wg-dhc 1. Co-Chairs - Administrativia (WG Status & Agenda Bashing) - 10 minutes 2. Tomek Mrugalski - RFC-3315bis Issues - 20 minutes 3. Tomek Mrugalski - draft-ietf-dhc-dhcpv6-failover-design - 10 minutes 4. Sheng Jiang - draft-ietf-dhc-sedhcvp6 - 10 minutes 5. Sheng Jiang - draft-jiang-dhc-stateless-reconfiguration - 15 minutes 6. Bernie Volz - DHCPv6 Load Balancing - 10 minutes [TENTATIVE - reviving draft-ietf-dhc-dhcpv6-load-balancing-00) 7. Tomek Mrugalski - draft-ietf-dhc-topo-conf-00 - 5 minutes [TENTATIVE] 8. Bernie Volz - draft-ietf-dhc-dhcpv6-stateful-issues - 10 minutes Last Updated: Feb. 10, 2014 (Subject to Change) --_000_489D13FBFA9B3E41812EA89F188F018E1AEA686Bxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:<= /p>

 

The updated proposed a= genda is at = http://www.ietf.org/proceedings/89/agenda/agenda-89-dhc.

 

Please verify and let = us know of issues or missing items. We hope to post the ‘final’= agenda on Monday.

 

For those on the agend= a, please be sure to send us your presentation to upload sufficiently in ad= vance of the meeting (we meet Monday, March 3rd 0900-1130 UTC).<= o:p>

 

-&nb= sp;         Bernie

 

From: dhcwg [m= ailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Tuesday, February 11, 2014 5:34 PM
To: dhcwg@ietf.org
Subject: [dhcwg] IETF-89 (London) Draft Agenda

 

Hi:

 

We published the current draft agenda (it is availab= le at http://www.ietf.org/proceedings/89/agenda/agenda-89-dhc and appears bel= ow). If you want time or you requested time and it isn’t there, let u= s know. If time estimates are correct, we are presently using 90 of our 150= minutes. Please note that this is a draft agenda and we may rearrange the order (as well as add or remove items).

 

-     &= nbsp;    Tomek & Bernie

 

** DRAFT ** DHC WG Agenda for IETF-89 (London)<= /o:p>

 

MONDAY, March 3, 2014, 0900-1130 (subject to change)=

Chairs: Tomek Mrugalski & Bernie Volz=

Presentations materials: https://datatracker.ietf.or= g/meeting/89/materials.html#wg-dhc

 

1. Co-Chairs - Administrativia (WG Status & Agen= da Bashing) - 10 minutes

2. Tomek Mrugalski - RFC-3315bis Issues - 20 minutes=

3. Tomek Mrugalski - draft-ietf-dhc-dhcpv6-failover-= design - 10 minutes

4. Sheng Jiang - draft-ietf-dhc-sedhcvp6 - 10 minute= s

5. Sheng Jiang - draft-jiang-dhc-stateless-reconfigu= ration - 15 minutes

6. Bernie Volz - DHCPv6 Load Balancing - 10 minutes = [TENTATIVE - reviving

   draft-ietf-dhc-dhcpv6-load-balancing-00= )

7. Tomek Mrugalski - draft-ietf-dhc-topo-conf-00 - 5= minutes [TENTATIVE]

8. Bernie Volz - draft-ietf-dhc-dhcpv6-stateful-issu= es - 10 minutes

 

Last Updated: Feb. 10, 2014 (Subject to Change)=

--_000_489D13FBFA9B3E41812EA89F188F018E1AEA686Bxmbrcdx04ciscoc_-- From nobody Mon Feb 24 11:42:14 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EFE1A024F for ; Mon, 24 Feb 2014 11:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.348 X-Spam-Level: X-Spam-Status: No, score=-7.348 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF0obJIEaC_K for ; Mon, 24 Feb 2014 11:42:11 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id E68E11A022E for ; Mon, 24 Feb 2014 11:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1960; q=dns/txt; s=iport; t=1393270930; x=1394480530; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=v+N6RwxPju4uoDwadHI3PWasFKSHz8PpocQ4x2fdWQ8=; b=W6XXCtm7xXFwKWewAIQSPx7G+Lig2tofVhPKRuVXKbbM83giK1WmE+rM Gj4a9Cfx9x3/Qu6TBEBpIEKyP8W/tXDvYQk9T4q8rBd8QKng+nsB+xntx 6bOnnV1PUi13QWqOoT9583RarfPNNXBol8piil4FPyB2wxJ75fyRz3uBb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAGufC1OtJV2c/2dsb2JhbABZgwY7V8EMgR0WdIIlAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQTCId9DcV/EwSOMzgGgx6BFASUSZYSgW+BPoIq X-IronPort-AV: E=Sophos;i="4.97,536,1389744000"; d="scan'208";a="22801393" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 24 Feb 2014 19:42:10 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1OJg9sm005007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Feb 2014 19:42:09 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 13:42:09 -0600 From: "Bernie Volz (volz)" To: dhcwg Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - Respond by Feb. 28 Thread-Index: AQHPJ2aKQQMht1vwHkGgg37nM3Zaqpqw6HSAgBP5iAA= Date: Mon, 24 Feb 2014 19:42:08 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AEAB9B8@xmb-rcd-x04.cisco.com> References: <52FA85BB.7090003@gmail.com> <52FA8A77.9000504@gmail.com> In-Reply-To: <52FA8A77.9000504@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/0XFCNj3qTWBzU7uAE9p3go_kcHQ Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - Respond by Feb. 28 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 19:42:12 -0000 Reminder that this WGLC is outstanding. We need feedback in order to determine whether to advance this document. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Tuesday, February 11, 2014 3:39 PM To: dhcwg Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - Resp= ond by Feb. 28 We have adopted two active leasequery drafts after Vancouver meeting. There was moderate interest in that work during adoption call, but we never= saw any discussions about them on the ML. Since authors confidence in thos= e proposals are high due to existing implementations, they have requested W= GLC. After a quick discussion between chairs, we have decided to go ahead with t= he WGLC, hoping that it will trigger some reviews and discussion. Please make no mistake - those drafts need reviews and comments. A simple "= I support this" followed with couple +1s will not do do the trick here. This WGLC is for draft-ietf-dhc-dhcpv6-active-leasequery-00. Please send yo= ur comments by Feb. 28th. Note that although both documents are very simila= r, they are separate drafts and are going through separate WGLCs. If you support this work, make sure that you clearly state which draft (v4,= v6 or both) you support. Each WGLC will be assessed independently. Finally, I'd also remind you that we are looking for volunteers to do the s= hepherding work. Please let us know if you'd like to be a shepherd for one = of those documents. It is not a difficult task, but some prior IETF experie= nce is necessary. As a shepherd, you can get unique insight into the WGLC p= rocess and better exposure to how IESG works. Having such an experience can= be useful with moving your own draft forward faster. Bernie & Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Feb 24 11:42:28 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C141A02B5 for ; Mon, 24 Feb 2014 11:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pg6JS8Rr2ZoO for ; Mon, 24 Feb 2014 11:42:22 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 598A01A02B4 for ; Mon, 24 Feb 2014 11:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1960; q=dns/txt; s=iport; t=1393270939; x=1394480539; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qG6Jlf2usxFSfPJ4/ExuzThNFB98hgihjkkijTl+MbA=; b=V67ofkDrNcavs/SmoQMNKM2TxGRqvi9ilHLwpRxHkQkhvOeFl/0/bH6E SI3VCwjoOxgpKCx5I9ja0F5HeZPcERXEmh5jpVFRH+OMK16HaLWjz+UKo SVqV9OCMce9Yksu1m8TSc/us1lXJ7HHw+15mZ+p1b0H90kI5R5ItYs6Uc A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAFafC1OtJV2Z/2dsb2JhbABZgwY7V8EMgR0WdIIlAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQTCId9DcV+EwSOMzgGgx6BFASUSZYSgW+BPoIq X-IronPort-AV: E=Sophos;i="4.97,536,1389744000"; d="scan'208";a="22801978" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 24 Feb 2014 19:42:18 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1OJgIrS000353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Feb 2014 19:42:18 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 13:42:18 -0600 From: "Bernie Volz (volz)" To: dhcwg Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-active-leasequery-00 - Respond by Feb. 28 Thread-Index: AQHPJ2k/dT5EmXdgSE+4gs6hpAMH4ZrE4jRw Date: Mon, 24 Feb 2014 19:42:17 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AEAB9BF@xmb-rcd-x04.cisco.com> References: <52FA8A40.8020703@gmail.com> In-Reply-To: <52FA8A40.8020703@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/IRmIVJ03wqAeJwyqsuCDBaGmqPw Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-active-leasequery-00 - Respond by Feb. 28 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 19:42:27 -0000 Reminder that this WGLC is outstanding. We need feedback in order to determine whether to advance this document. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Tuesday, February 11, 2014 3:38 PM To: dhcwg Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-active-leasequery-00 - Resp= ond by Feb. 28 We have adopted two active leasequery drafts after Vancouver meeting. There was moderate interest in that work during adoption call, but we never= saw any discussions about them on the ML. Since authors confidence in thos= e proposals are high due to existing implementations, they have requested W= GLC. After a quick discussion between chairs, we have decided to go ahead with t= he WGLC, hoping that it will trigger some reviews and discussion. Please make no mistake - those drafts need reviews and comments. A simple "= I support this" followed with couple +1s will not do do the trick here. This WGLC is for draft-ietf-dhc-dhcpv4-active-leasequery-00. Please send yo= ur comments by Feb. 28th. Note that although both documents are very simila= r, they are separate drafts and are going through separate WGLCs. If you support this work, make sure that you clearly state which draft (v4,= v6 or both) you support. Each WGLC will be assessed independently. Finally, I'd also remind you that we are looking for volunteers to do the s= hepherding work. Please let us know if you'd like to be a shepherd for one = of those documents. It is not a difficult task, but some prior IETF experie= nce is necessary. As a shepherd, you can get unique insight into the WGLC p= rocess and better exposure to how IESG works. Having such an experience can= be useful with moving your own draft forward faster. Bernie & Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Tue Feb 25 10:21:48 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6D21A01DD for ; Tue, 25 Feb 2014 10:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk_XxI_KJpUC for ; Tue, 25 Feb 2014 10:21:37 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9F51A0183 for ; Tue, 25 Feb 2014 10:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13863; q=dns/txt; s=iport; t=1393352497; x=1394562097; h=from:to:subject:date:message-id:mime-version; bh=2TPSrA1/aJ66MDtC78iEzJ2S/voT1nAZQ5hPXR3AMzY=; b=UKEqeD9dRE4EVmiAmjNnjv7KzKn875iNSAknxsYKeXpouDIdyuFs0GoQ qBOpGWUiaaKgCtwEE7ke26f5UzPGHkSu5ltWXrgx/bdMAmNqY2XeRvH6o sSar7O62NeRS4WinZLc8Ytx7X83uvO38b65nPdOG8mfXx5Q/PB7Qc3kc3 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAJ3eDFOtJV2Z/2dsb2JhbABZgkJEO1fBUYEYFnSCJQEBAQQtXgEIEQQBAQsdORQJCQEEEwgBh3wNl0GwFReOECM3gyWBFASMZJMUimODLYIq X-IronPort-AV: E=Sophos; i="4.97,541,1389744000"; d="scan'208,217"; a="23078670" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 25 Feb 2014 18:21:36 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1PILa8E023965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 25 Feb 2014 18:21:36 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 12:21:35 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: IETF-89 (London) Draft Agenda & More Thread-Index: Ac8yVcyNCcQNJH+JQ9iOwn+BcLWPEA== Date: Tue, 25 Feb 2014 18:21:36 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AEAE497@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.121] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AEAE497xmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/5MMBTIfV7bxHYLepVjdIWWEdsEY Subject: Re: [dhcwg] IETF-89 (London) Draft Agenda & More X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 18:21:44 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AEAE497xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: The "final" agenda has been posted at http://www.ietf.org/proceedings/89/ag= enda/agenda-89-dhc. (Please let us know of any issues or changes.) We also need minute takers (preferable using etherpad) and jabber scribes! = Please help out so that we have a good record of what transpired and allow = those unable to attend in person to participate. For those with presentations, please be sure to send us your slides on or b= efore Friday, February 28th at 1700 EST (March 1st 0000 GMT). Presentations= without slides by then may be removed from the agenda or moved to the end,= time permitting. - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Friday, February 21, 2014 2:46 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] IETF-89 (London) Draft Agenda Hi: The updated proposed agenda is at http://www.ietf.org/proceedings/89/agenda= /agenda-89-dhc. Please verify and let us know of issues or missing items. We hope to post t= he 'final' agenda on Monday. For those on the agenda, please be sure to send us your presentation to upl= oad sufficiently in advance of the meeting (we meet Monday, March 3rd 0900-= 1130 UTC). - Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1AEAE497xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:<= /p>

 

The “final”= ; agenda has been posted at http://= www.ietf.org/proceedings/89/agenda/agenda-89-dhc. (Please let us know o= f any issues or changes.)

 

We also need minute ta= kers (preferable using etherpad) and jabber scribes! Please help out so that we have a good record of what transpired and= allow those unable to attend in person to participate.

 

For those with present= ations, please be sure to send us your slides on or before Friday, February 28th at 1700 EST (Ma= rch 1st 0000 GMT). Presentations without slides by then may be r= emoved from the agenda or moved to the end, time permitting.

 

-&nb= sp;         Bernie

 

From: dhcwg [m= ailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Friday, February 21, 2014 2:46 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] IETF-89 (London) Draft Agenda=

 

Hi:<= /p>

 

The updated proposed a= genda is at = http://www.ietf.org/proceedings/89/agenda/agenda-89-dhc.

 

Please verify and let = us know of issues or missing items. We hope to post the ‘final’= agenda on Monday.

 

For those on the agend= a, please be sure to send us your presentation to upload sufficiently in ad= vance of the meeting (we meet Monday, March 3rd 0900-1130 UTC).<= o:p>

 

-&nb= sp;         Bernie

 

--_000_489D13FBFA9B3E41812EA89F188F018E1AEAE497xmbrcdx04ciscoc_-- From nobody Thu Feb 27 07:41:50 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CC71A0303 for ; Thu, 27 Feb 2014 07:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tet_34Mx-Giv for ; Thu, 27 Feb 2014 07:41:47 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0897F1A010C for ; Thu, 27 Feb 2014 07:41:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2359; q=dns/txt; s=iport; t=1393515706; x=1394725306; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4UbWcAp//7/VQogKfj1/yEnfGi+IfsEZcu78qM91wr4=; b=V//BXZGXpcT01EWKuVcZp3GiHcorlX21gPwA6meiZPlbB+Yt+UyN9Mcl g6ZtqMeXl9yiEwVtW2SyevpNkD7qkT+fOJrbp5zmUOTX6QUGZVfmGu/jd WgyHMw568j0Y070cTz4lXAzBYemm2mAnzrmwYL0iBoudENvko1F2MPnKg 4=; X-IronPort-AV: E=Sophos;i="4.97,555,1389744000"; d="scan'208";a="306758805" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 27 Feb 2014 15:41:45 +0000 Received: from [10.86.246.178] ([10.86.246.178]) (authenticated bits=0) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1RFfifh026183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Feb 2014 15:41:45 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Kim Kinnear In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AEAB9B8@xmb-rcd-x04.cisco.com> Date: Thu, 27 Feb 2014 10:41:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3DDB196D-177E-4698-BC28-1732D93E3BAB@cisco.com> References: <52FA85BB.7090003@gmail.com> <52FA8A77.9000504@gmail.com> <489D13FBFA9B3E41812EA89F188F018E1AEAB9B8@xmb-rcd-x04.cisco.com> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1510) X-Authenticated-User: kkinnear Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/ip2NSA1hECv6xa6XpgDyLnsg9lc Cc: dhcwg , Kim Kinnear Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - Respond by Feb. 28 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 15:41:49 -0000 I have read this draft and believe that it should be moved forward. Regards -- Kim On Feb 24, 2014, at 2:42 PM, Bernie Volz (volz) wrote: > Reminder that this WGLC is outstanding. >=20 > We need feedback in order to determine whether to advance this = document. >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek = Mrugalski > Sent: Tuesday, February 11, 2014 3:39 PM > To: dhcwg > Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - = Respond by Feb. 28 >=20 > We have adopted two active leasequery drafts after Vancouver meeting. > There was moderate interest in that work during adoption call, but we = never saw any discussions about them on the ML. Since authors confidence = in those proposals are high due to existing implementations, they have = requested WGLC. >=20 > After a quick discussion between chairs, we have decided to go ahead = with the WGLC, hoping that it will trigger some reviews and discussion. > Please make no mistake - those drafts need reviews and comments. A = simple "I support this" followed with couple +1s will not do do the = trick here. >=20 > This WGLC is for draft-ietf-dhc-dhcpv6-active-leasequery-00. Please = send your comments by Feb. 28th. Note that although both documents are = very similar, they are separate drafts and are going through separate = WGLCs. > If you support this work, make sure that you clearly state which draft = (v4, v6 or both) you support. Each WGLC will be assessed independently. >=20 > Finally, I'd also remind you that we are looking for volunteers to do = the shepherding work. Please let us know if you'd like to be a shepherd = for one of those documents. It is not a difficult task, but some prior = IETF experience is necessary. As a shepherd, you can get unique insight = into the WGLC process and better exposure to how IESG works. Having such = an experience can be useful with moving your own draft forward faster. >=20 > Bernie & Tomek >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Thu Feb 27 07:41:52 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DA41A010C for ; Thu, 27 Feb 2014 07:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuP5IlNu-L88 for ; Thu, 27 Feb 2014 07:41:47 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 8093E1A0300 for ; Thu, 27 Feb 2014 07:41:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2359; q=dns/txt; s=iport; t=1393515706; x=1394725306; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4UbWcAp//7/VQogKfj1/yEnfGi+IfsEZcu78qM91wr4=; b=WGR48YwbkvFNlQ8WaSIMczbd88j7I8SnHkioys7sLP1p2AbOZRyhwCi/ i6IZGpUDlYfQQlGDwBGBoeA/HrfE+kvv1lfvbfDl0y+IPobcYAIgBVlpV L3+W/pE/8YxldcNmo9XPcyD2sIOPCsX6QbATEYFNQDaIc64Qq6J/Rbn/v M=; X-IronPort-AV: E=Sophos;i="4.97,555,1389744000"; d="scan'208";a="23672524" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-6.cisco.com with ESMTP; 27 Feb 2014 15:41:45 +0000 Received: from [10.86.246.178] ([10.86.246.178]) (authenticated bits=0) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1RFfifi026183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Feb 2014 15:41:45 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Kim Kinnear In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AEAB9B8@xmb-rcd-x04.cisco.com> Date: Thu, 27 Feb 2014 10:41:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6A4FFC7E-33D1-4B77-BE71-637813BBDFBB@cisco.com> References: <52FA85BB.7090003@gmail.com> <52FA8A77.9000504@gmail.com> <489D13FBFA9B3E41812EA89F188F018E1AEAB9B8@xmb-rcd-x04.cisco.com> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1510) X-Authenticated-User: kkinnear Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/bqZg8J1xEZiP-0LWUuju1JSRASU Cc: dhcwg , Kim Kinnear Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - Respond by Feb. 28 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 15:41:49 -0000 I have read this draft and believe that it should be moved forward. Regards -- Kim On Feb 24, 2014, at 2:42 PM, Bernie Volz (volz) wrote: > Reminder that this WGLC is outstanding. >=20 > We need feedback in order to determine whether to advance this = document. >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek = Mrugalski > Sent: Tuesday, February 11, 2014 3:39 PM > To: dhcwg > Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - = Respond by Feb. 28 >=20 > We have adopted two active leasequery drafts after Vancouver meeting. > There was moderate interest in that work during adoption call, but we = never saw any discussions about them on the ML. Since authors confidence = in those proposals are high due to existing implementations, they have = requested WGLC. >=20 > After a quick discussion between chairs, we have decided to go ahead = with the WGLC, hoping that it will trigger some reviews and discussion. > Please make no mistake - those drafts need reviews and comments. A = simple "I support this" followed with couple +1s will not do do the = trick here. >=20 > This WGLC is for draft-ietf-dhc-dhcpv6-active-leasequery-00. Please = send your comments by Feb. 28th. Note that although both documents are = very similar, they are separate drafts and are going through separate = WGLCs. > If you support this work, make sure that you clearly state which draft = (v4, v6 or both) you support. Each WGLC will be assessed independently. >=20 > Finally, I'd also remind you that we are looking for volunteers to do = the shepherding work. Please let us know if you'd like to be a shepherd = for one of those documents. It is not a difficult task, but some prior = IETF experience is necessary. As a shepherd, you can get unique insight = into the WGLC process and better exposure to how IESG works. Having such = an experience can be useful with moving your own draft forward faster. >=20 > Bernie & Tomek >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Thu Feb 27 07:43:14 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352A91A0337 for ; Thu, 27 Feb 2014 07:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cemXVGBW_Fqm for ; Thu, 27 Feb 2014 07:43:05 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 75F7E1A032E for ; Thu, 27 Feb 2014 07:43:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2490; q=dns/txt; s=iport; t=1393515779; x=1394725379; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=JsFOndI0cJ2+RlFUJ7SX/BTEkesD0Eas51zX/43Yc3Y=; b=lQCrcLqwze4dLH4ow9FZmYO7M3vqUE0v4kUx0cqhLXPd72kkhtunAYoT W0jTldUtGNQf/pVD5d7pKkSru7gn6S1jQ36oO3oj7JDr7XNgrdNZ5Js02 4fKi8XrKmOc4B77GCdDlazgyMtkfrSqTUzEw/428f16lKpe9aVIj12AZw 8=; X-IronPort-AV: E=Sophos;i="4.97,555,1389744000"; d="scan'208";a="306947174" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 27 Feb 2014 15:42:59 +0000 Received: from [10.86.246.178] ([10.86.246.178]) (authenticated bits=0) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1RFgvVn007362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Feb 2014 15:42:58 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Kim Kinnear In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AEAB9BF@xmb-rcd-x04.cisco.com> Date: Thu, 27 Feb 2014 10:42:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1CD2937E-5A0E-4BD9-AC15-51815EBE8DFB@cisco.com> References: <52FA8A40.8020703@gmail.com> <489D13FBFA9B3E41812EA89F188F018E1AEAB9BF@xmb-rcd-x04.cisco.com> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1510) X-Authenticated-User: kkinnear Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/B7HL5xySwrKFFcmEeOMsGBMAXRM Cc: dhcwg , Kim Kinnear Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-active-leasequery-00 - Respond by Feb. 28 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 15:43:11 -0000 I wrote this draft, and believe that it should be moved forward. I would sure appreciate some additional eyes on it if we elect to move it forward, as I'm sure there are things that we've missed. Regards -- Kim On Feb 24, 2014, at 2:42 PM, Bernie Volz (volz) wrote: > Reminder that this WGLC is outstanding. >=20 > We need feedback in order to determine whether to advance this = document. >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek = Mrugalski > Sent: Tuesday, February 11, 2014 3:38 PM > To: dhcwg > Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-active-leasequery-00 - = Respond by Feb. 28 >=20 > We have adopted two active leasequery drafts after Vancouver meeting. > There was moderate interest in that work during adoption call, but we = never saw any discussions about them on the ML. Since authors confidence = in those proposals are high due to existing implementations, they have = requested WGLC. >=20 > After a quick discussion between chairs, we have decided to go ahead = with the WGLC, hoping that it will trigger some reviews and discussion. > Please make no mistake - those drafts need reviews and comments. A = simple "I support this" followed with couple +1s will not do do the = trick here. >=20 > This WGLC is for draft-ietf-dhc-dhcpv4-active-leasequery-00. Please = send your comments by Feb. 28th. Note that although both documents are = very similar, they are separate drafts and are going through separate = WGLCs. > If you support this work, make sure that you clearly state which draft = (v4, v6 or both) you support. Each WGLC will be assessed independently. >=20 > Finally, I'd also remind you that we are looking for volunteers to do = the shepherding work. Please let us know if you'd like to be a shepherd = for one of those documents. It is not a difficult task, but some prior = IETF experience is necessary. As a shepherd, you can get unique insight = into the WGLC process and better exposure to how IESG works. Having such = an experience can be useful with moving your own draft forward faster. >=20 > Bernie & Tomek >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Thu Feb 27 09:28:56 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677BF1A0136 for ; Thu, 27 Feb 2014 09:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-PaAUdXU534 for ; Thu, 27 Feb 2014 09:28:53 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8893D1A00FB for ; Thu, 27 Feb 2014 09:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3065; q=dns/txt; s=iport; t=1393522132; x=1394731732; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3Zhr2qaJnKhouszyfg5mhD9T+9w05gmV8IwAJv3CSrE=; b=C/5/yLAOTZ5RJn2oaWlQROjSqjmQIMNWHRFD1cer7eda3oXVs4W5b8EF 07au9jFbZ7eMzFa8YjJ9xWxJSiQ/QbKs5NS5t2l6HqQueaxtkLwUgOONn a5P1Sf+cmGVqt6p/au1z1Jvlv8PlVWBqrTJFKjH77LM0QamPyMbrGFDXV s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FADN1D1OtJXHB/2dsb2JhbABagwY7SwzBC4EbFnSCJQEBAQMBAQEBNzQLBQcEAgEIEQQBAQsUCQcnCxQJCAIEAQ0FCIdpCA3KcRMEjiQxBwaDHYEUBJRNlhWBb4E+gio X-IronPort-AV: E=Sophos;i="4.97,556,1389744000"; d="scan'208";a="307058660" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 27 Feb 2014 17:28:50 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1RHSoKB016495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 27 Feb 2014 17:28:50 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 27 Feb 2014 11:28:49 -0600 From: "Hemant Singh (shemant)" To: "Kim Kinnear (kkinnear)" , "Bernie Volz (volz)" Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-active-leasequery-00 - Respond by Feb. 28 Thread-Index: AQHPM9KtaeFxIUaio0arvTlNKTNOI5rJWuOw Date: Thu, 27 Feb 2014 17:28:49 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8911600D58@xmb-rcd-x06.cisco.com> References: <52FA8A40.8020703@gmail.com> <489D13FBFA9B3E41812EA89F188F018E1AEAB9BF@xmb-rcd-x04.cisco.com> <1CD2937E-5A0E-4BD9-AC15-51815EBE8DFB@cisco.com> In-Reply-To: <1CD2937E-5A0E-4BD9-AC15-51815EBE8DFB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/PU-6jZ0SgpYiZliU6wHi6e_KKp8 Cc: dhcwg Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-active-leasequery-00 - Respond by Feb. 28 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 17:28:55 -0000 I read the document and it looks good to move forward. Thanks for putting = together this document.=20 Cheers, Hemant -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Kim Kinnear (kkinn= ear) Sent: Thursday, February 27, 2014 10:43 AM To: Bernie Volz (volz) Cc: dhcwg; Kim Kinnear (kkinnear) Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-active-leasequery-00 - = Respond by Feb. 28 I wrote this draft, and believe that it should be moved forward. I would sure appreciate some additional eyes on it if we elect to move it f= orward, as I'm sure there are things that we've missed. Regards -- Kim On Feb 24, 2014, at 2:42 PM, Bernie Volz (volz) wrote: > Reminder that this WGLC is outstanding. >=20 > We need feedback in order to determine whether to advance this document. >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek=20 > Mrugalski > Sent: Tuesday, February 11, 2014 3:38 PM > To: dhcwg > Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-active-leasequery-00 -=20 > Respond by Feb. 28 >=20 > We have adopted two active leasequery drafts after Vancouver meeting. > There was moderate interest in that work during adoption call, but we nev= er saw any discussions about them on the ML. Since authors confidence in th= ose proposals are high due to existing implementations, they have requested= WGLC. >=20 > After a quick discussion between chairs, we have decided to go ahead with= the WGLC, hoping that it will trigger some reviews and discussion. > Please make no mistake - those drafts need reviews and comments. A simple= "I support this" followed with couple +1s will not do do the trick here. >=20 > This WGLC is for draft-ietf-dhc-dhcpv4-active-leasequery-00. Please send = your comments by Feb. 28th. Note that although both documents are very simi= lar, they are separate drafts and are going through separate WGLCs. > If you support this work, make sure that you clearly state which draft (v= 4, v6 or both) you support. Each WGLC will be assessed independently. >=20 > Finally, I'd also remind you that we are looking for volunteers to do the= shepherding work. Please let us know if you'd like to be a shepherd for on= e of those documents. It is not a difficult task, but some prior IETF exper= ience is necessary. As a shepherd, you can get unique insight into the WGLC= process and better exposure to how IESG works. Having such an experience c= an be useful with moving your own draft forward faster. >=20 > Bernie & Tomek >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Thu Feb 27 11:29:45 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4EE1A046C for ; Thu, 27 Feb 2014 11:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YpoCqssPV2G for ; Thu, 27 Feb 2014 11:29:41 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 21CFE1A0126 for ; Thu, 27 Feb 2014 11:29:41 -0800 (PST) Received: from ians-mbp.fritz.box ([89.0.111.113]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MYOY5-1WniU71rVZ-00V4yG; Thu, 27 Feb 2014 20:29:38 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ian Farrer In-Reply-To: <52FA8A40.8020703@gmail.com> Date: Thu, 27 Feb 2014 20:29:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9701A42A-6369-455F-BB1B-606C9B8B7521@gmx.com> References: <52FA8A40.8020703@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1827) X-Provags-ID: V03:K0:jef21BcaQX8gr5fckANK+SJH8gPe2tUt50qoKg7oFnFR9C2UPny W0x77ZZKCBdtqM3VRYKd53NDXJe6LiWMC/E5/6N/J+LjEoWSqkJg41uy2kvOl5uZeznCdnY 7EoIIpHF0oF5TIuJEkKvjpnatY8xGncYARJbZpt0QWssKGScJlWK69UKbFTzlsHuRUCqVNA l8Nl+9IKFs2OzhsBFdetw== Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/i71a1BlpJSpXcDpI578dZ8GjUF0 Cc: dhcwg Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-active-leasequery-00 - Respond by Feb. 28 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 19:29:43 -0000 I=92ve read the draft and can see some potentially useful applications = for this, so I think it should be moved forward. Cheers, Ian On 11 Feb 2014, at 21:38, Tomek Mrugalski = wrote: > We have adopted two active leasequery drafts after Vancouver meeting. > There was moderate interest in that work during adoption call, but > we never saw any discussions about them on the ML. Since authors > confidence in those proposals are high due to existing = implementations, > they have requested WGLC. >=20 > After a quick discussion between chairs, we have decided to go ahead > with the WGLC, hoping that it will trigger some reviews and = discussion. > Please make no mistake - those drafts need reviews and comments. A > simple "I support this" followed with couple +1s will not do do the > trick here. >=20 > This WGLC is for draft-ietf-dhc-dhcpv4-active-leasequery-00. Please = send > your comments by Feb. 28th. Note that although both documents are very > similar, they are separate drafts and are going through separate = WGLCs. > If you support this work, make sure that you clearly state which draft > (v4, v6 or both) you support. Each WGLC will be assessed = independently. >=20 > Finally, I'd also remind you that we are looking for volunteers to do > the shepherding work. Please let us know if you'd like to be a = shepherd > for one of those documents. It is not a difficult task, but some prior > IETF experience is necessary. As a shepherd, you can get unique = insight > into the WGLC process and better exposure to how IESG works. Having = such > an experience can be useful with moving your own draft forward faster. >=20 > Bernie & Tomek >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Thu Feb 27 11:30:42 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28951A0126 for ; Thu, 27 Feb 2014 11:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M38hmYHFkA3D for ; Thu, 27 Feb 2014 11:30:39 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id AEA3D1A0390 for ; Thu, 27 Feb 2014 11:30:38 -0800 (PST) Received: from ians-mbp.fritz.box ([89.0.111.113]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lu874-1XH1Lx0Aqc-011RfT for ; Thu, 27 Feb 2014 20:30:35 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ian Farrer In-Reply-To: <52FA8A77.9000504@gmail.com> Date: Thu, 27 Feb 2014 20:30:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52FA85BB.7090003@gmail.com> <52FA8A77.9000504@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1827) X-Provags-ID: V03:K0:DTW0a/EhNaoiKfhc4vTHZFeGiVtpZ/e77hir+rg7Dsj61FtDl7f IDNh4liEcSqj689eZwnPulW9b2faylUrjW1e3OkN+Gm58tuBxTKqKenxChRrd9MV+hSHK3Q 2pO+mqg6wy9/iOOFxvuOxgbB+y3Hj9Ye4Swyd+7gBHWY/YogUp3fQ7QLXSwPLbNDA6hPeHp IM6Yc/OSUkH/J7N+vreMg== Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/q7NedViLeXAGpg7HiLNUok8Ss4M Cc: dhcwg Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - Respond by Feb. 28 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 19:30:40 -0000 As-per the DHCPv4 active leasequeury, I think this is useful and support = it progressing. Cheers, Ian On 11 Feb 2014, at 21:39, Tomek Mrugalski = wrote: > We have adopted two active leasequery drafts after Vancouver meeting. > There was moderate interest in that work during adoption call, but > we never saw any discussions about them on the ML. Since authors > confidence in those proposals are high due to existing = implementations, > they have requested WGLC. >=20 > After a quick discussion between chairs, we have decided to go ahead > with the WGLC, hoping that it will trigger some reviews and = discussion. > Please make no mistake - those drafts need reviews and comments. A > simple "I support this" followed with couple +1s will not do do the > trick here. >=20 > This WGLC is for draft-ietf-dhc-dhcpv6-active-leasequery-00. Please = send > your comments by Feb. 28th. Note that although both documents are very > similar, they are separate drafts and are going through separate = WGLCs. > If you support this work, make sure that you clearly state which draft > (v4, v6 or both) you support. Each WGLC will be assessed = independently. >=20 > Finally, I'd also remind you that we are looking for volunteers to do > the shepherding work. Please let us know if you'd like to be a = shepherd > for one of those documents. It is not a difficult task, but some prior > IETF experience is necessary. As a shepherd, you can get unique = insight > into the WGLC process and better exposure to how IESG works. Having = such > an experience can be useful with moving your own draft forward faster. >=20 > Bernie & Tomek >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From lew@pt.net Thu Feb 27 12:01:57 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C620E1A0656 for ; Thu, 27 Feb 2014 12:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml36ceRyPRfs for ; Thu, 27 Feb 2014 12:01:55 -0800 (PST) Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7763E1A068B for ; Thu, 27 Feb 2014 12:01:42 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 8434C8400ED for ; Thu, 27 Feb 2014 14:01:40 -0600 (CST) Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id k9-3kl3ZZebm for ; Thu, 27 Feb 2014 14:01:38 -0600 (CST) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 89E55840100 for ; Thu, 27 Feb 2014 14:01:38 -0600 (CST) X-Virus-Scanned: amavisd-new at mail.pt.net Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id pfDqc4sdf2TD for ; Thu, 27 Feb 2014 14:01:38 -0600 (CST) Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by mail.pt.net (Postfix) with ESMTP id 06F3E8400C3 for ; Thu, 27 Feb 2014 14:01:38 -0600 (CST) From: Lewis Donzis To: "dhcwg" References: <52FA8A40.8020703@gmail.com> <9701A42A-6369-455F-BB1B-606C9B8B7521@gmx.com> Date: Thu, 27 Feb 2014 14:01:37 -0600 (CST) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraConnectorForOutlook/8.0.6.1063) Thread-Index: Yz5g2H+tUPbaxLafBsegMgSgc1jCCA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: <9701A42A-6369-455F-BB1B-606C9B8B7521@gmx.com> Thread-Topic: WGLC for draft-ietf-dhc-dhcpv4-active-leasequery-00 - Respond by Feb. 28 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/1ApSwDGrXzMd9ygqhUdWa9xJ-YU Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-active-leasequery-00 - Respond by Feb. 28 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 20:02:59 -0000 I also have read the draft and agree that it should be moved forward. We have already implemented a client and have experience with this protocol in large production networks, and it has proven to be extremely useful and has significant advantages over standard leasequery. This may be outside the scope of this discussion, but it would be nice if the specification included, perhaps in section 7, that the server MUST or at least SHOULD include lease state changes for both dynamic and reserved addresses. There has been some ambiguity on this and it would be nice if all implementations were consistent in this regard. At a minimum, the DHCP server should provide the same information via active leasequery that it provides via standard leasequery. lew > On 11 Feb 2014, at 21:38, Tomek Mrugalski > wrote: > > > We have adopted two active leasequery drafts after > Vancouver meeting. > > There was moderate interest in that work during adoption call, but > > we never saw any discussions about them on the ML. Since authors > > confidence in those proposals are high due to existing > implementations, > > they have requested WGLC. > > > > After a quick discussion between chairs, we have decided to go ahead > > with the WGLC, hoping that it will trigger some reviews and > discussion. > > Please make no mistake - those drafts need reviews and comments. A > > simple "I support this" followed with couple +1s will not do do the > > trick here. > > > > This WGLC is for > draft-ietf-dhc-dhcpv4-active-leasequery-00. Please send > > your comments by Feb. 28th. Note that although both > documents are very > > similar, they are separate drafts and are going through > separate WGLCs. > > If you support this work, make sure that you clearly state > which draft > > (v4, v6 or both) you support. Each WGLC will be assessed > independently. > > > > Finally, I'd also remind you that we are looking for > volunteers to do > > the shepherding work. Please let us know if you'd like to > be a shepherd > > for one of those documents. It is not a difficult task, but > some prior > > IETF experience is necessary. As a shepherd, you can get > unique insight > > into the WGLC process and better exposure to how IESG > works. Having such > > an experience can be useful with moving your own draft > forward faster. > > > > Bernie & Tomek > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From nobody Thu Feb 27 12:06:53 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691221A0654 for ; Thu, 27 Feb 2014 12:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28gPDDvUIsLE for ; Thu, 27 Feb 2014 12:06:48 -0800 (PST) Received: from mail.pt.net (mail.pt.net [IPv6:2001:4870:610e:2:4::11]) by ietfa.amsl.com (Postfix) with ESMTP id 97F731A065D for ; Thu, 27 Feb 2014 12:06:48 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id C1AC984010D for ; Thu, 27 Feb 2014 14:06:46 -0600 (CST) Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id ou-vhoec1sP7 for ; Thu, 27 Feb 2014 14:06:45 -0600 (CST) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 917E78400D9 for ; Thu, 27 Feb 2014 14:06:45 -0600 (CST) X-Virus-Scanned: amavisd-new at mail.pt.net Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id PIZXHG9J8RbQ for ; Thu, 27 Feb 2014 14:06:45 -0600 (CST) Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by mail.pt.net (Postfix) with ESMTP id F164C8400D0 for ; Thu, 27 Feb 2014 14:06:44 -0600 (CST) From: Lewis Donzis To: "dhcwg" References: <52FA85BB.7090003@gmail.com> <52FA8A77.9000504@gmail.com> Date: Thu, 27 Feb 2014 14:06:44 -0600 (CST) Message-ID: <134a8be8.00000a14.000001c4@lew.perftech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraConnectorForOutlook/8.0.6.1063) Thread-Index: IRzv66gzB/Eb8gSRpelymRSALVWwrw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: Thread-Topic: WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - Respond by Feb. 28 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/HfSH-R_dJCjJqzcZJKcSG0oknTQ Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - Respond by Feb. 28 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 20:06:51 -0000 This is ditto from DHVPv4... same for DHCPv6: I also have read the draft and agree that it should be moved forward. We have already implemented a client for this protocol, as it promises significant advantages over standard leasequery. This may be outside the scope of this discussion, but it would be nice if the specification included, perhaps in section 7, that the server MUST or at least SHOULD include lease state changes for both dynamic and reserved addresses. There has been some ambiguity on this and it would be nice if all implementations were consistent in this regard. At a minimum, the DHCP server should provide the same information via active leasequery that it provides via standard leasequery. lew > On 11 Feb 2014, at 21:39, Tomek Mrugalski > wrote: > > > We have adopted two active leasequery drafts after > Vancouver meeting. > > There was moderate interest in that work during adoption call, but > > we never saw any discussions about them on the ML. Since authors > > confidence in those proposals are high due to existing > implementations, > > they have requested WGLC. > > > > After a quick discussion between chairs, we have decided to go ahead > > with the WGLC, hoping that it will trigger some reviews and > discussion. > > Please make no mistake - those drafts need reviews and comments. A > > simple "I support this" followed with couple +1s will not do do the > > trick here. > > > > This WGLC is for > draft-ietf-dhc-dhcpv6-active-leasequery-00. Please send > > your comments by Feb. 28th. Note that although both > documents are very > > similar, they are separate drafts and are going through > separate WGLCs. > > If you support this work, make sure that you clearly state > which draft > > (v4, v6 or both) you support. Each WGLC will be assessed > independently. > > > > Finally, I'd also remind you that we are looking for > volunteers to do > > the shepherding work. Please let us know if you'd like to > be a shepherd > > for one of those documents. It is not a difficult task, but > some prior > > IETF experience is necessary. As a shepherd, you can get > unique insight > > into the WGLC process and better exposure to how IESG > works. Having such > > an experience can be useful with moving your own draft > forward faster. > > > > Bernie & Tomek > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From nobody Thu Feb 27 14:12:12 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3D11A0131 for ; Thu, 27 Feb 2014 14:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubVXR5shNGR8 for ; Thu, 27 Feb 2014 14:12:07 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id DFA8A1A015E for ; Thu, 27 Feb 2014 14:12:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6982; q=dns/txt; s=iport; t=1393539125; x=1394748725; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=y80GDd344HkcPtorkup7zsKyEBJZemAcADPC6/7Ndyg=; b=dMs9oq3TcTpfa7SvcI4dxrLZ6kzHIUJxiYQJDvhg4xRp/H8E/bcOgRiZ hnB9vO3/tsa5lDCUH74ok5tpPj6bFR5VzsyaCyJ6m5qKQCIz5V9hUNgHr e6D/c/j5Fz5XQAq02VuMl8WRIPl89I8wVERZKNSvEHndzjTRwvyZHitRs s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FABW3D1OtJXHB/2dsb2JhbABagwY7V8EQgR8WdIIlAQEBBAEBASQTNBcEAgEIEQQBAQsUCQcnCxQJCAIEEwgBh3ANyzwXjiQ4BoMdgRQElE2WFYFvgT6CKg X-IronPort-AV: E=Sophos;i="4.97,557,1389744000"; d="scan'208";a="23787453" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-5.cisco.com with ESMTP; 27 Feb 2014 22:12:03 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1RMC3Dc021387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 27 Feb 2014 22:12:03 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Thu, 27 Feb 2014 16:12:03 -0600 From: "Bernie Volz (volz)" To: dhcwg Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - Respond by Feb. 28 Thread-Index: AQHPJ2aKQQMht1vwHkGgg37nM3Zaqpqw6HSAgBP5iACABL3BoA== Date: Thu, 27 Feb 2014 22:12:02 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AEB3850@xmb-rcd-x04.cisco.com> References: <52FA85BB.7090003@gmail.com> <52FA8A77.9000504@gmail.com> <489D13FBFA9B3E41812EA89F188F018E1AEAB9B8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AEAB9B8@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/G9GT7EPjA5R-3EUrsway_qImm7g Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - Respond by Feb. 28 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 22:12:09 -0000 Comments regarding the draft (WG Co-Chair HAT OFF, though I did read this m= ore as a potential document shepherd so it is a bit more thorough): I have read this draft and support it moving forward. I do have an extensive list of minor nits (missing definite articles (the) = such as in section 6.3, spelling errors such as signalled -> signaled, can = not -> cannot, and minor wording issues). I will provide a complete list to= the authors, as I don't think this is a big deal (the RFC Editor would add= ress most of these issues). There are some other minor issues that should be looked at: - The use of "continuous" (i.e., in section 3, "provide continuous updates = of DHCPv6 IPv6 binding activity". While this isn't wrong, I just wonder if = it could be misunderstood as the updates only occur when there are changes = -- so if the server is idle, these updates would be. I would if just removi= ng the word would be appropriate (or the entire sentence as the text before= it is clear enough by itself). - Section 6.1 says "one or more DHCPv6 messages to be sent at a time", thou= gh I don't understand how this is technically possible as the messages must= be sent serially (one after the other). Again, this is probably minor as I= think the intent is probably clear, but perhaps we can use better wording. - Section 6.2.1 has some odd wording (assist requestor keeping -> "keeping = the requestor"?) - Section 6.3.1 specifies that the is an absolute time since midnight Jan 1= 2000 UTC modulo 2^32. I don't understand how that "modulo 2^32" can be use= d. This is a 'future' issue since this will potentially create confusion on= ce the time wraps (hence the modulo part becomes important). But how does a= receiver know what the time should be (well, I would guess we can argue th= at if the year is 2137, the base time is probably 0x100000000 + the receive= d time). While I guess it would be nice to have a fully future proof protoc= ol, I would just remove the "modulo 2^32"? Or, why not make this a 64-bit v= alue and then we avoid any issues for a very very long time? - Section 6.3.1, 6.3.2, 6.3.3, remove "The length of this option is 4 octet= s". This is confusing as it really is the length of the data and that is al= ready indicated in the field definitions. - The text in 6.3 really impacts RFC 5460 because it is adding more functio= nality (as mentioned in the abstract). As this is kind of buried pretty dee= p in the document, I think it may be appropriate to add an explicit section= to the document that indicates that Bulk Leasequery (RFC 5460) is extended= by allowing this? And, nothing in 6.3.1 or 6.3.2 mentions that the those a= re allowed in a Bulk Leasequery, yet 6.3 does say that can? (6.3.3 does men= tion that option.) I think it might be best to add a section "Extensions to= Bulk Leasequery" that describes those that can be used in those operations= ? - This issue also ties in with section 9 ... I assume that the Bulk LQ supp= ort must also have been extended as mentioned in 6.3 (i.e., to support the = new options). So "A DHCPv6 server with supports Active Leasequery MUST also= support DHCPv6 Bulk Leasequery [RFC5460] and as extended herein." Or somet= hing like that? This is where referencing a section which contains the exte= nsions would come in handy. - Section 7, last sentence uses "would never miss", but that isn't true unl= ess the connection remains up. So, perhaps change to "would be less likely = to miss"? - Section 8.2, remove "4 octet" when describing the transmission of the OPT= ION_LQ_BASE_TIME option. (The option itself is 8 octets if the header is in= cluded, and 4 for just the data -- unless this is changed as per comment fo= r 6.3.1.) I don't see any value in the "4 octet". The idnits tool reports some issues that should also be looked at (there we= re some others, but these are because the document was from 80+ days ago): Checking nits according to http://www.ietf.org/id-info/checklist : -------------------------------------------------------------------------= --- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: -------------------------------------------------------------------------= --- =3D=3D The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword= , but does not include the phrase in its RFC 2119 key words list. Again, nothing here to prevent this document from moving forward (likely af= ter a revision). - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Monday, February 24, 2014 2:42 PM To: dhcwg Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - = Respond by Feb. 28 Reminder that this WGLC is outstanding. We need feedback in order to determine whether to advance this document. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Tuesday, February 11, 2014 3:39 PM To: dhcwg Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - Resp= ond by Feb. 28 We have adopted two active leasequery drafts after Vancouver meeting. There was moderate interest in that work during adoption call, but we never= saw any discussions about them on the ML. Since authors confidence in thos= e proposals are high due to existing implementations, they have requested W= GLC. After a quick discussion between chairs, we have decided to go ahead with t= he WGLC, hoping that it will trigger some reviews and discussion. Please make no mistake - those drafts need reviews and comments. A simple "= I support this" followed with couple +1s will not do do the trick here. This WGLC is for draft-ietf-dhc-dhcpv6-active-leasequery-00. Please send yo= ur comments by Feb. 28th. Note that although both documents are very simila= r, they are separate drafts and are going through separate WGLCs. If you support this work, make sure that you clearly state which draft (v4,= v6 or both) you support. Each WGLC will be assessed independently. Finally, I'd also remind you that we are looking for volunteers to do the s= hepherding work. Please let us know if you'd like to be a shepherd for one = of those documents. It is not a difficult task, but some prior IETF experie= nce is necessary. As a shepherd, you can get unique insight into the WGLC p= rocess and better exposure to how IESG works. Having such an experience can= be useful with moving your own draft forward faster. Bernie & Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Fri Feb 28 01:26:21 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79491A0102 for ; Fri, 28 Feb 2014 01:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFSJJeuIER_R for ; Fri, 28 Feb 2014 01:26:16 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 942251A0370 for ; Fri, 28 Feb 2014 01:26:16 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id p10so507880pdj.12 for ; Fri, 28 Feb 2014 01:26:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8pH3a2wFm9y3ZtwoRMO/jeXM3VyucwnT+P8fGw8PJw4=; b=lOkPECKeT61J/FcAt2Nl+GoV/U13WESASuh6M8qeo8AMGv3ibV5qwLFqtNEj3MprWI taBsACKni+geagklpRkg8AXeFBKLSbtHIIYDA75TUjuYBw4jhxYObqt3WoWMaiyvT2zf PSWT8mimu493MbtPs19mLlTLZmTyx8+oSEX//xH9YLEOm1yha5wfCeFvgS25B6/yfWdh v/rJLfI0qmCgoggz899+3Mm9AXY8mUTin+F1bFpbBTbldHTGOOfcsYrh+O6wBjMQAl2k l+g/YRjvZ5IINC5Zwl+CwPJXhRs2MywCGhG7zXJNrmJf/BpYSkbGptEpLVxJWFbmPv8i Ayrg== X-Received: by 10.66.142.233 with SMTP id rz9mr2282031pab.71.1393579574934; Fri, 28 Feb 2014 01:26:14 -0800 (PST) Received: from ?IPv6:2402:f000:ffff:64:9284:dff:fef3:d346? ([2402:f000:ffff:64:9284:dff:fef3:d346]) by mx.google.com with ESMTPSA id op3sm4031198pbc.40.2014.02.28.01.26.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 01:26:14 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <52FA8A40.8020703@gmail.com> Date: Fri, 28 Feb 2014 17:26:07 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52FA8A40.8020703@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/2EluxqyaAry73pOiII1EawgTUvI Cc: dhcwg Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-active-leasequery-00 - Respond by Feb. 28 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 09:26:19 -0000 I have read this document, and I support this document to move forward. A small suggestion: Would it be helpful if there is a reference to related section of = RFC6926 when the query-start-time option is first mentioned? Because I'm = not quite familiar with RFC6929, it confuses me a little on what the = query-start-time option is used for.=20 BTW, I'm OK with the current shape if the option should be a well-known = option.=20 Thanks! Best Regards, Qi=20 On 2014-2-12, at =E4=B8=8A=E5=8D=884:38, Tomek Mrugalski wrote: > We have adopted two active leasequery drafts after Vancouver meeting. > There was moderate interest in that work during adoption call, but > we never saw any discussions about them on the ML. Since authors > confidence in those proposals are high due to existing = implementations, > they have requested WGLC. >=20 > After a quick discussion between chairs, we have decided to go ahead > with the WGLC, hoping that it will trigger some reviews and = discussion. > Please make no mistake - those drafts need reviews and comments. A > simple "I support this" followed with couple +1s will not do do the > trick here. >=20 > This WGLC is for draft-ietf-dhc-dhcpv4-active-leasequery-00. Please = send > your comments by Feb. 28th. Note that although both documents are very > similar, they are separate drafts and are going through separate = WGLCs. > If you support this work, make sure that you clearly state which draft > (v4, v6 or both) you support. Each WGLC will be assessed = independently. >=20 > Finally, I'd also remind you that we are looking for volunteers to do > the shepherding work. Please let us know if you'd like to be a = shepherd > for one of those documents. It is not a difficult task, but some prior > IETF experience is necessary. As a shepherd, you can get unique = insight > into the WGLC process and better exposure to how IESG works. Having = such > an experience can be useful with moving your own draft forward faster. >=20 > Bernie & Tomek >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg