From A.Hoenes@tr-sys.de Wed Apr 1 09:56:40 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14883A6842 for ; Wed, 1 Apr 2009 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.987 X-Spam-Level: ** X-Spam-Status: No, score=2.987 tagged_above=-999 required=5 tests=[AWL=-0.564, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+qwD74c0I7Z for ; Wed, 1 Apr 2009 09:56:40 -0700 (PDT) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id BDFB93A6949 for ; Wed, 1 Apr 2009 09:56:38 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA105064913; Wed, 1 Apr 2009 18:55:13 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA22617; Wed, 1 Apr 2009 18:55:11 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200904011655.SAA22617@TR-Sys.de> To: dhcwg@ietf.org, volz@cisco.com Date: Wed, 1 Apr 2009 18:55:11 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: [dhcwg] draft-ietf-dhc-dhcpv4-vendor-message-00 WGLC comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 16:56:41 -0000 I have studied draft-ietf-dhc-dhcpv4-vendor-message-00 and have a couple of recommendations for editorial improvements of the draft. (1) Section 1, 1st para -- improved wording For enhanced readability, I suggest to swap words: vvvvvvvvvvvvvvvvvv | The DHCPv4 [RFC2131] protocol specifies a mechanism for the assignment of addresses and configuration information to nodes. [...] --- vvvvvvvvvvvvvvvvvv | The DHCPv4 protocol [RFC2131] specifies a mechanism for the assignment of addresses and configuration information to nodes. [...] (2) Section 3 -- document structure This draft is structured along his DHCPv6 companion draft; but the message structure in DHCPv4 is significantly different than in DHCPv6. Therefore, and to easily allow making future references to parts of the document more precise, I suggest to split Section 3 into three new sections: 3. Vendor-specific Message 4. Vendor Message Option 4.1 Vendor Message Sub-Options The new Section 3 should comprise the first 4 paragraphs of the current Section 3. Section 4 would start with: |4. Vendor Message Option | The format of the Vendor Message Option is shown below: ... [ Alternatively, the 4th para of Section 3 could be moved into this section as well -- maybe with slight rewording. ] This section should extend down to the field explanations for the Vendor Message Option, and include the last two paragraphs of the old Section 3. More details for this section are discussed below. [ Alternatively, the last paragraph could go to the end of the new Section 3. ] The remainder of the old Section 3 would go into the new subsection 4.1: |4.1. Vendor Message Sub-Options | More details for this section are discussed below as well. Note: All subsequent section numbers need to be bumped accordingly. (3) [old] Section 3 -- terminological clarification The field designation "vendor-option-data" in the Vendor Message Option seems to be chosen in an unfortunate manner. I suggest to precisely indicate what the subsequent text specifies: a series of regularly structured *sub*-options. It seems to be important for clarity (within this document and future documents making reference of it) to precisely distinguish the terms "option" and "suboption". Hence the field should better be designated as "vendor-msg-subopts" [name chosen to be no longer than the old name]. This change needs to be applied to the diagram and the explanation of "option-len", and the final field explanation should be made more precise: vendor-option-data Vendor specific data (of length option-len minus 5 octets). This is optional. --- | vendor-msg-subopts A sequence of zero or more sub-options | (of length option-len minus 5 octets). I suggest to split the subsequent paragraph and leave its first part in the new Section 4, while moving the second part into Section 4.1. There, I suggest to rename the data field using a more regular naming pattern. | The vendor-msg-subopts field MUST be encoded as a sequence of code/ | length/value fields in a format identical to the DHCP options field, | as specified in Section 4.1 below. | << last two paragraphs of old Section 3 >> | |4.1. Vendor Message Sub-Options | | The Vendor Message Suboptions placed into the Vendor Message Option | are TLV structured like regular DHCP options. | | The suboption codes are defined by the vendor identified in the | enterprise-number field of the Vendor Message Option and are not | managed by IANA. Suboption codes 0 and 255 have no pre-defined | interpretation or format. | | Each of the encapsulated suboptions is formatted as follows: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subopt-code | subopt-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / subopt-data / ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subopt-code The code for the encapsulated suboption. subopt-len An unsigned integer giving the length of the | subopt-data field in this encapsulated | suboption in octets. | subopt-data Data area for the encapsulated suboption. [ Note: In all field explanations above, the word "encapsulated" might well be deleted; it should suffice to have it in the intial text of the new section -- the designation "sub"[option] has taken over its role. ] Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@tr-sys.de Wed Apr 1 10:09:02 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12BA3A6840 for ; Wed, 1 Apr 2009 10:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 754E6oFkufJz for ; Wed, 1 Apr 2009 10:09:01 -0700 (PDT) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id EFFA73A659B for ; Wed, 1 Apr 2009 10:09:00 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA105125675; Wed, 1 Apr 2009 19:07:55 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id TAA22635; Wed, 1 Apr 2009 19:07:53 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200904011707.TAA22635@TR-Sys.de> To: dhcwg@ietf.org, volz@cisco.com Date: Wed, 1 Apr 2009 19:07:53 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: [dhcwg] draft-ietf-dhc-dhcpv6-vendor-message-00 WGLC comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:09:02 -0000 I also have studied draft-ietf-dhc-dhcpv6-vendor-message-00 and have a few recommendations for editorial improvements of this draft as well. (1) Section 1, 1st para -- improved wording I suggest to swap words for clarity: vvvvvvvvvvvvvvvvvv | The DHCPv6 [RFC3315] protocol specifies a mechanism for the assignment of addresses and configuration information to nodes. [...] --- vvvvvvvvvvvvvvvvvv | The DHCPv6 protocol [RFC3315] specifies a mechanism for the assignment of addresses and configuration information to nodes. [...] (2) Section 1, 1st para, and Section 6.2 RFC 2434 has been obsoleted and replaced by the new BCP 26, RFC 5226. Please update the reference and the citation tag accordingly. (3) Sections 3 and 5 -- code point assignment strategy The strategy followed for assignment of the DHCPv6 msg-type code point VENDOR-SPECIFIC is confusing: In the IANA Considerations, the draft assumes normative behavior of the WG, by stating: IANA is requested to assign DHCPv6 Message type 254 to the Vendor- specific Message in the registry maintained in [DHCPv6Params]: 254 VENDOR-SPECIFIC Contrary to that, below the first diagram in Setcion 3, it says: | msg-type VENDOR-SPECIFIC (to-be-assigned) ^^^^^^^^^^^^^^ For consistency, that should be changed to: | msg-type VENDOR-SPECIFIC (254) ^^^ (4) Section 3 -- language improvement ? In the paragraph above the second diagram, the phrase "of identical format to" seems to be unpleasant. How about "in a format identical to" ? Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From volz@cisco.com Wed Apr 1 10:24:15 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BB953A6B5B for ; Wed, 1 Apr 2009 10:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.283 X-Spam-Level: X-Spam-Status: No, score=-5.283 tagged_above=-999 required=5 tests=[AWL=-1.284, BAYES_00=-2.599, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkstRAtke7BD for ; Wed, 1 Apr 2009 10:24:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E54E33A6A98 for ; Wed, 1 Apr 2009 10:24:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,307,1235952000"; d="scan'208";a="278241654" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2009 17:25:14 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n31HPEXf014241; Wed, 1 Apr 2009 10:25:14 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n31HP1Ps025606; Wed, 1 Apr 2009 17:25:10 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 13:25:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Apr 2009 13:25:09 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB210BFF95F0@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <200904011655.SAA22617@TR-Sys.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dhc-dhcpv4-vendor-message-00 WGLC comments Thread-Index: Acmy6vlXFsjpW8WMSBCe4iPUT8CWNgAAmh1g References: <200904011655.SAA22617@TR-Sys.de> From: "Bernie Volz (volz)" To: =?iso-8859-1?Q?Alfred_H=CEnes?= , X-OriginalArrivalTime: 01 Apr 2009 17:25:09.0980 (UTC) FILETIME=[CEE451C0:01C9B2EE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5932; t=1238606714; x=1239470714; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20draft-ietf-dhc-dhcpv4-vendor-message-00 =20WGLC=20comments |Sender:=20; bh=NPtU8JgA+Fk5GlKUyjvAMolxOMkQbarm3iqtCmMcm1I=; b=QmXBrcRE2FYtxYLLPkYzj95gi6mINDyAm9TobpyCnlof6hAcpxcy4L/gq2 /SCO9cR0qbmBKxVXjpRIbfGl2NRU5yhcEI9X2Fbd2k0jqy/zwoMJI8H80xsg kmdyWEOmRl; Authentication-Results: sj-dkim-4; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-vendor-message-00 WGLC comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:24:15 -0000 Alfred: Thanks for the comments ... We'll see what happens as the draft = progresses to the end of the WGLC before revising anything. Regarding switching to Vendor Suboptions, I took this from = http://www.ietf.org/rfc/rfc3925.txt. And, I think the convention started = there would be best to continue to avoid confusion as ideally vendors = should be using ONE number space for their suboptions. Perhaps to follow = RFC 3925 even more closely, vendor-option-data should just be = option-data. And, a direct reference to that RFC is appropriate. - Bernie -----Original Message----- From: Alfred H=CEnes [mailto:ah@tr-sys.de]=20 Sent: Wednesday, April 01, 2009 12:55 PM To: dhcwg@ietf.org; Bernie Volz (volz) Subject: draft-ietf-dhc-dhcpv4-vendor-message-00 WGLC comments I have studied draft-ietf-dhc-dhcpv4-vendor-message-00 and have a couple of recommendations for editorial improvements of the draft. (1) Section 1, 1st para -- improved wording For enhanced readability, I suggest to swap words: vvvvvvvvvvvvvvvvvv | The DHCPv4 [RFC2131] protocol specifies a mechanism for the assignment of addresses and configuration information to nodes. [...] --- vvvvvvvvvvvvvvvvvv | The DHCPv4 protocol [RFC2131] specifies a mechanism for the assignment of addresses and configuration information to nodes. [...] (2) Section 3 -- document structure This draft is structured along his DHCPv6 companion draft; but the message structure in DHCPv4 is significantly different than in DHCPv6. Therefore, and to easily allow making future references to parts of the document more precise, I suggest to split Section 3 into three new sections: 3. Vendor-specific Message 4. Vendor Message Option 4.1 Vendor Message Sub-Options The new Section 3 should comprise the first 4 paragraphs of the current Section 3. Section 4 would start with: |4. Vendor Message Option | The format of the Vendor Message Option is shown below: ... [ Alternatively, the 4th para of Section 3 could be moved into this section as well -- maybe with slight rewording. ] This section should extend down to the field explanations for the Vendor Message Option, and include the last two paragraphs of the old Section 3. More details for this section are discussed below. [ Alternatively, the last paragraph could go to the end of the new Section 3. ] The remainder of the old Section 3 would go into the new subsection 4.1: |4.1. Vendor Message Sub-Options | More details for this section are discussed below as well. Note: All subsequent section numbers need to be bumped accordingly. (3) [old] Section 3 -- terminological clarification The field designation "vendor-option-data" in the Vendor Message Option seems to be chosen in an unfortunate manner. I suggest to precisely indicate what the subsequent text specifies: a series of regularly structured *sub*-options. It seems to be important for clarity (within this document and future documents making reference of it) to precisely distinguish the terms "option" and "suboption". Hence the field should better be designated as "vendor-msg-subopts" [name chosen to be no longer than the old name]. This change needs to be applied to the diagram and the explanation of "option-len", and the final field explanation should be made more precise: vendor-option-data Vendor specific data (of length option-len minus 5 octets). This is optional. --- | vendor-msg-subopts A sequence of zero or more sub-options | (of length option-len minus 5 octets). I suggest to split the subsequent paragraph and leave its first part in the new Section 4, while moving the second part into Section 4.1. There, I suggest to rename the data field using a more regular naming pattern. | The vendor-msg-subopts field MUST be encoded as a sequence of code/ | length/value fields in a format identical to the DHCP options field, | as specified in Section 4.1 below. | << last two paragraphs of old Section 3 >> | |4.1. Vendor Message Sub-Options | | The Vendor Message Suboptions placed into the Vendor Message Option | are TLV structured like regular DHCP options. | | The suboption codes are defined by the vendor identified in the | enterprise-number field of the Vendor Message Option and are not | managed by IANA. Suboption codes 0 and 255 have no pre-defined | interpretation or format. | | Each of the encapsulated suboptions is formatted as follows: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subopt-code | subopt-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / subopt-data / ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subopt-code The code for the encapsulated suboption. subopt-len An unsigned integer giving the length of the | subopt-data field in this encapsulated | suboption in octets. | subopt-data Data area for the encapsulated suboption. [ Note: In all field explanations above, the word "encapsulated" might well be deleted; it should suffice to have it in the intial text of the new section -- the designation "sub"[option] has taken over its role. ] Kind regards, Alfred H=CEnes. --=20 +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@tr-sys.de Thu Apr 2 02:47:30 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C053A67A8 for ; Thu, 2 Apr 2009 02:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.862 X-Spam-Level: * X-Spam-Status: No, score=1.862 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7qmb3Yfhw+8 for ; Thu, 2 Apr 2009 02:47:29 -0700 (PDT) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 02F543A692C for ; Thu, 2 Apr 2009 02:47:28 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA108735585; Thu, 2 Apr 2009 11:46:25 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA24208; Thu, 2 Apr 2009 11:46:24 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200904020946.LAA24208@TR-Sys.de> To: draft-ietf-dhc-dhcpv6-agentopt-delegate@cabernet.tools.ietf.org, dhcwg@ietf.org Date: Thu, 2 Apr 2009 11:46:24 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs. Leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 09:47:30 -0000 Hello, studying the recently refreshed DHCPv6 RAAN Option draft, draft-ietf-dhc-dhcpv6-agentopt-delegate-03, I find some close relationship to [Bulk] Leasequery: the RAAN Option is intended to establish client specific state, e.g. routing state, on a DHCP Relay Agent node; [Bulk] Leasequery is intended to restore such state. However, the DHCPv6 RAAN Option draft does not discuss this relationship and/or potential applicability of the RAAN Option to DHCPv6 [Bulk] Leasequery. I would appreciate this being discussed and perhaps, the applicability of RAAN expanded in the next draft revision. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From rdroms@cisco.com Fri Apr 3 07:03:15 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8CF3A6D52 for ; Fri, 3 Apr 2009 07:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1u61lu7ZGfz for ; Fri, 3 Apr 2009 07:03:15 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DE68B3A6D4C for ; Fri, 3 Apr 2009 07:02:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,319,1235952000"; d="scan'208";a="40917619" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Apr 2009 14:03:49 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n33E3ms9009994; Fri, 3 Apr 2009 10:03:48 -0400 Received: from [161.44.65.174] ([161.44.65.174]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n33E3mS1025553; Fri, 3 Apr 2009 14:03:48 GMT Message-Id: <7F36D5FF-0DEC-4D52-A228-F90EF290AC7E@cisco.com> From: Ralph Droms To: =?ISO-8859-1?Q?Alfred_H=CEnes?= In-Reply-To: <200904020946.LAA24208@TR-Sys.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 10:03:48 -0400 References: <200904020946.LAA24208@TR-Sys.de> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1490; t=1238767429; x=1239631429; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20draft-ietf-dhc-dhcpv6-agentopt-delegate -03=20vs.=20Leasequery |Sender:=20 |To:=20=3D?ISO-8859-1?Q?Alfred_H=3DCEnes?=3D=20; bh=YLIKi7IQv5M6iBCF7qsc0sOvsRdQ199Uj9URLowC2xU=; b=BAibrOszdabHC5oHaNLgGFcMjdZTjch0EI1TKGtCOvAyeB1ql1JaRHs7rH tWQY8WXgjv50rLNDACXt6/95xYhrLBGxiKW/MKkJtGjBnSX8r1Q1bgRcZSzL /+oioYAv9P; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Dhcwg WG , draft-ietf-dhc-dhcpv6-agentopt-delegate@tools.IETF.ORG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs. Leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 14:03:15 -0000 Alfred - good question. You're right, the RAAN option introduces =20 state in the network element hosting the relay agent, which must be =20 restored if the network element loses that state. We'll review DHCPv6 leasequery to see if what extensions would be =20 required for routing state recovery. - Ralph On Apr 2, 2009, at 5:46 AM 4/2/09, Alfred H=CEnes wrote: > Hello, > studying the recently refreshed DHCPv6 RAAN Option draft, > draft-ietf-dhc-dhcpv6-agentopt-delegate-03, > I find some close relationship to [Bulk] Leasequery: > the RAAN Option is intended to establish client specific > state, e.g. routing state, on a DHCP Relay Agent node; > [Bulk] Leasequery is intended to restore such state. > > However, the DHCPv6 RAAN Option draft does not discuss this > relationship and/or potential applicability of the RAAN Option > to DHCPv6 [Bulk] Leasequery. > > I would appreciate this being discussed and perhaps, the > applicability of RAAN expanded in the next draft revision. > > > Kind regards, > Alfred H=CEnes. > > --=20 > > +------------------------=20 > +--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-=20 > Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: =20 > -18 | > | D-71254 Ditzingen | E-Mail: ah@TR-=20 > Sys.de | > +------------------------=20 > +--------------------------------------------+ > From john_brzozowski@cable.comcast.com Fri Apr 3 07:41:04 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0A23A6E58 for ; Fri, 3 Apr 2009 07:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.804 X-Spam-Level: X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[AWL=-4.104, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eipknt6L4oda for ; Fri, 3 Apr 2009 07:41:03 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 19D1E3A6D06 for ; Fri, 3 Apr 2009 07:41:03 -0700 (PDT) Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.68698206; Fri, 03 Apr 2009 10:41:43 -0400 Received: from NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 10:41:43 -0400 Received: from 68.44.29.26 ([68.44.29.26]) by NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 3 Apr 2009 14:41:22 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 03 Apr 2009 10:41:19 -0400 From: John Jason Brzozowski To: Ralph Droms , Alfred =?ISO-8859-1?B?SM5uZXM=?= Message-ID: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leasequery Thread-Index: Acm0ZT4XJTuFl4YzSSO9KBApUiZE9gABQHrE In-Reply-To: <7F36D5FF-0DEC-4D52-A228-F90EF290AC7E@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 03 Apr 2009 14:41:43.0714 (UTC) FILETIME=[4EBA6020:01C9B46A] Cc: dhc WG , draft-ietf-dhc-dhcpv6-agentopt-delegate@tools.IETF.ORG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 14:41:04 -0000 Ralph, Alfred, I believe the expectation is that when a relay agent performs DHCPv6 bulk lease query the RAAN option will be retrieved as part of the LEASEQUERY-DAT= A Option providing the lease query includes the RAAN option (TBD). RFC5007 and RFC5460 specify the protocol and mechanism required to retrieve lease data from the DHCP server. Just so I am clear are we suggesting that RFC5460 and or the RAAN draft should specify how the relay agent is to rebuild routing state? John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Corporation e) mailto:john_brzozowski@cable.comcast.com m) 609-377-6594 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > From: Ralph Droms > Date: Fri, 3 Apr 2009 10:03:48 -0400 > To: Alfred H=CEnes > Cc: dhc WG , > > Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leaseq= uery >=20 > Alfred - good question. You're right, the RAAN option introduces > state in the network element hosting the relay agent, which must be > restored if the network element loses that state. >=20 > We'll review DHCPv6 leasequery to see if what extensions would be > required for routing state recovery. >=20 > - Ralph >=20 > On Apr 2, 2009, at 5:46 AM 4/2/09, Alfred H=CEnes wrote: >=20 >> Hello, >> studying the recently refreshed DHCPv6 RAAN Option draft, >> draft-ietf-dhc-dhcpv6-agentopt-delegate-03, >> I find some close relationship to [Bulk] Leasequery: >> the RAAN Option is intended to establish client specific >> state, e.g. routing state, on a DHCP Relay Agent node; >> [Bulk] Leasequery is intended to restore such state. >>=20 >> However, the DHCPv6 RAAN Option draft does not discuss this >> relationship and/or potential applicability of the RAAN Option >> to DHCPv6 [Bulk] Leasequery. >>=20 >> I would appreciate this being discussed and perhaps, the >> applicability of RAAN expanded in the next draft revision. >>=20 >>=20 >> Kind regards, >> Alfred H=CEnes. >>=20 >> -- >>=20 >> +------------------------ >> +--------------------------------------------+ >> | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.- >> Phys. | >> | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: >> -18 | >> | D-71254 Ditzingen | E-Mail: ah@TR- >> Sys.de | >> +------------------------ >> +--------------------------------------------+ >>=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From rdroms@cisco.com Fri Apr 3 07:49:23 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2373A6A7F for ; Fri, 3 Apr 2009 07:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4WzAtTg5PCX for ; Fri, 3 Apr 2009 07:49:22 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 64EE23A6A61 for ; Fri, 3 Apr 2009 07:49:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,319,1235952000"; d="scan'208";a="40883742" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Apr 2009 14:50:24 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n33EoOJ4003162; Fri, 3 Apr 2009 10:50:24 -0400 Received: from [161.44.65.174] ([161.44.65.174]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n33EoO4s012114; Fri, 3 Apr 2009 14:50:24 GMT Message-Id: <895EB6E1-FD4C-4EA7-9DA9-088DFB7E4F16@cisco.com> From: Ralph Droms To: John Jason Brzozowski In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 10:50:24 -0400 References: X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3209; t=1238770224; x=1239634224; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-agentop t-delegate-03=20vs.Leasequery |Sender:=20 |To:=20John=20Jason=20Brzozowski=20; bh=tfZH2aPGuBbwEZiEAsK1tSYgXRPaHg/TDz01v7J8TlY=; b=S37QpgteZTFe3kicMWIDMSGdRZm444OkACdSR9bsaU7JG+WWEZmwScgvMt y5cC84XbdbFLvWbDSWwIG3m+Ld3CLmfgcuJ9cZB8VCrYeWnAAw1H35asMnOM 4Jr/wOQPxm; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: dhc WG , =?ISO-8859-1?Q?Alfred_H=CEnes?= , draft-ietf-dhc-dhcpv6-agentopt-delegate@tools.IETF.ORG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 14:49:23 -0000 John - I don't recall: does the leasequery draft have a mechanism =20 through which the routing information, as carried in the RAAN option, =20= can be delivered to the relay agent? - Ralph On Apr 3, 2009, at 10:41 AM 4/3/09, John Jason Brzozowski wrote: > Ralph, Alfred, > > I believe the expectation is that when a relay agent performs DHCPv6 =20= > bulk > lease query the RAAN option will be retrieved as part of the =20 > LEASEQUERY-DATA > Option providing the lease query includes the RAAN option (TBD). > > RFC5007 and RFC5460 specify the protocol and mechanism required to =20 > retrieve > lease data from the DHCP server. > > Just so I am clear are we suggesting that RFC5460 and or the RAAN =20 > draft > should specify how the relay agent is to rebuild routing state? > > John > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > John Jason Brzozowski > Comcast Corporation > e) mailto:john_brzozowski@cable.comcast.com > m) 609-377-6594 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> From: Ralph Droms >> Date: Fri, 3 Apr 2009 10:03:48 -0400 >> To: Alfred H=CEnes >> Cc: dhc WG , >> >> Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 =20 >> vs.Leasequery >> >> Alfred - good question. You're right, the RAAN option introduces >> state in the network element hosting the relay agent, which must be >> restored if the network element loses that state. >> >> We'll review DHCPv6 leasequery to see if what extensions would be >> required for routing state recovery. >> >> - Ralph >> >> On Apr 2, 2009, at 5:46 AM 4/2/09, Alfred H=CEnes wrote: >> >>> Hello, >>> studying the recently refreshed DHCPv6 RAAN Option draft, >>> draft-ietf-dhc-dhcpv6-agentopt-delegate-03, >>> I find some close relationship to [Bulk] Leasequery: >>> the RAAN Option is intended to establish client specific >>> state, e.g. routing state, on a DHCP Relay Agent node; >>> [Bulk] Leasequery is intended to restore such state. >>> >>> However, the DHCPv6 RAAN Option draft does not discuss this >>> relationship and/or potential applicability of the RAAN Option >>> to DHCPv6 [Bulk] Leasequery. >>> >>> I would appreciate this being discussed and perhaps, the >>> applicability of RAAN expanded in the next draft revision. >>> >>> >>> Kind regards, >>> Alfred H=CEnes. >>> >>> -- >>> >>> +------------------------ >>> +--------------------------------------------+ >>> | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.- >>> Phys. | >>> | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: >>> -18 | >>> | D-71254 Ditzingen | E-Mail: ah@TR- >>> Sys.de | >>> +------------------------ >>> +--------------------------------------------+ >>> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > > From john_brzozowski@cable.comcast.com Fri Apr 3 08:03:21 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9364C3A6A58 for ; Fri, 3 Apr 2009 08:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.098 X-Spam-Level: * X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[AWL=-1.902, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tJVT+1odCP5 for ; Fri, 3 Apr 2009 08:03:20 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 887783A68DF for ; Fri, 3 Apr 2009 08:03:16 -0700 (PDT) Received: from ([10.195.246.152]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.68700068; Fri, 03 Apr 2009 11:04:01 -0400 Received: from NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 11:04:01 -0400 Received: from 68.44.29.26 ([68.44.29.26]) by NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 3 Apr 2009 15:03:48 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 03 Apr 2009 11:03:47 -0400 From: John Jason Brzozowski To: Ralph Droms Message-ID: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leasequery Thread-Index: Acm0a8EEql5Dz+CpTD6GBqARNenS7AAAaJyb In-Reply-To: <895EB6E1-FD4C-4EA7-9DA9-088DFB7E4F16@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 03 Apr 2009 15:04:01.0444 (UTC) FILETIME=[6C13C640:01C9B46D] Cc: dhc WG , Alfred =?ISO-8859-1?B?SM5uZXM=?= , draft-ietf-dhc-dhcpv6-agentopt-delegate@tools.IETF.ORG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:03:21 -0000 Unless I am missing something, if the RAAN option is specified as part of the initial lease query request via the ORO, the server will return it to the requestor, if available. In this case the RAAN option will be present for processing by the relay agent. Do we aim to specify how the relay agent will perform routing updates? I assume not. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Corporation e) mailto:john_brzozowski@cable.comcast.com m) 609-377-6594 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > From: Ralph Droms > Date: Fri, 3 Apr 2009 10:50:24 -0400 > To: "Brzozowski, John" > Cc: Alfred H=CEnes , dhc WG , > > Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leaseq= uery >=20 > John - I don't recall: does the leasequery draft have a mechanism > through which the routing information, as carried in the RAAN option, > can be delivered to the relay agent? >=20 > - Ralph >=20 > On Apr 3, 2009, at 10:41 AM 4/3/09, John Jason Brzozowski wrote: >=20 >> Ralph, Alfred, >>=20 >> I believe the expectation is that when a relay agent performs DHCPv6 >> bulk >> lease query the RAAN option will be retrieved as part of the >> LEASEQUERY-DATA >> Option providing the lease query includes the RAAN option (TBD). >>=20 >> RFC5007 and RFC5460 specify the protocol and mechanism required to >> retrieve >> lease data from the DHCP server. >>=20 >> Just so I am clear are we suggesting that RFC5460 and or the RAAN >> draft >> should specify how the relay agent is to rebuild routing state? >>=20 >> John >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> John Jason Brzozowski >> Comcast Corporation >> e) mailto:john_brzozowski@cable.comcast.com >> m) 609-377-6594 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >>> From: Ralph Droms >>> Date: Fri, 3 Apr 2009 10:03:48 -0400 >>> To: Alfred H=CEnes >>> Cc: dhc WG , >>> >>> Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 >>> vs.Leasequery >>>=20 >>> Alfred - good question. You're right, the RAAN option introduces >>> state in the network element hosting the relay agent, which must be >>> restored if the network element loses that state. >>>=20 >>> We'll review DHCPv6 leasequery to see if what extensions would be >>> required for routing state recovery. >>>=20 >>> - Ralph >>>=20 >>> On Apr 2, 2009, at 5:46 AM 4/2/09, Alfred H=CEnes wrote: >>>=20 >>>> Hello, >>>> studying the recently refreshed DHCPv6 RAAN Option draft, >>>> draft-ietf-dhc-dhcpv6-agentopt-delegate-03, >>>> I find some close relationship to [Bulk] Leasequery: >>>> the RAAN Option is intended to establish client specific >>>> state, e.g. routing state, on a DHCP Relay Agent node; >>>> [Bulk] Leasequery is intended to restore such state. >>>>=20 >>>> However, the DHCPv6 RAAN Option draft does not discuss this >>>> relationship and/or potential applicability of the RAAN Option >>>> to DHCPv6 [Bulk] Leasequery. >>>>=20 >>>> I would appreciate this being discussed and perhaps, the >>>> applicability of RAAN expanded in the next draft revision. >>>>=20 >>>>=20 >>>> Kind regards, >>>> Alfred H=CEnes. >>>>=20 >>>> -- >>>>=20 >>>> +------------------------ >>>> +--------------------------------------------+ >>>> | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.- >>>> Phys. | >>>> | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: >>>> -18 | >>>> | D-71254 Ditzingen | E-Mail: ah@TR- >>>> Sys.de | >>>> +------------------------ >>>> +--------------------------------------------+ >>>>=20 >>>=20 >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >>=20 >=20 From volz@cisco.com Fri Apr 3 08:13:48 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7BD3A6A61 for ; Fri, 3 Apr 2009 08:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIjQEzjazgs9 for ; Fri, 3 Apr 2009 08:13:48 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C7C343A68CF for ; Fri, 3 Apr 2009 08:13:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,320,1235952000"; d="scan'208";a="150028952" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-3.cisco.com with ESMTP; 03 Apr 2009 15:14:50 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n33FEoct012353; Fri, 3 Apr 2009 11:14:50 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n33FEo6i020596; Fri, 3 Apr 2009 15:14:50 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 11:14:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 11:14:48 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB210BFFA009@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <7F36D5FF-0DEC-4D52-A228-F90EF290AC7E@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs. Leasequery Thread-Index: Acm0ZQ8vy3mZGmWlTT+Z4EPvSb03AgACEsjQ References: <200904020946.LAA24208@TR-Sys.de> <7F36D5FF-0DEC-4D52-A228-F90EF290AC7E@cisco.com> From: "Bernie Volz (volz)" To: "Ralph Droms (rdroms)" , =?iso-8859-1?Q?Alfred_H=CEnes?= X-OriginalArrivalTime: 03 Apr 2009 15:14:49.0905 (UTC) FILETIME=[EE971210:01C9B46E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2525; t=1238771690; x=1239635690; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20draft-ietf-dhc-dhcpv6-agentopt-delegate -03=20vs.=20Leasequery |Sender:=20 |To:=20=22Ralph=20Droms=20(rdroms)=22=20, =0A=20=20=20=20=20=20=20=20=3D?iso-8859-1?Q?Alfred_H=3DCEnes ?=3D=20; bh=zLvA+RWbNLHxQivq5mQgtJyHMyVIn9+x/PP3+m3W6Ic=; b=D6/RCTgOX46yIo2Oz80T9QSCvoebAzj998COYQBN0ni6UB3y9HsQ8x7Msl WVSo9Y4lsj9JOabeFpGuwk1uB39vLbGezrR/HdTL8UTnJElUKBLJogNdwKMH S3wZgJWVY6; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Dhcwg WG , draft-ietf-dhc-dhcpv6-agentopt-delegate@tools.IETF.ORG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs. Leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:13:49 -0000 Yes, the RAAN draft should reference the LQ and bulk LQ drafts (Ralph = just re-submitted the expired version without other changes to restore = the draft to active status). And, at the time the draft last had major = revisions was before the bulk LQ draft existed. The 02 draft was from = Nov 2006. Bulk LQ was first submitted Oct 2007. The RAAN option always required a separate state recovery mechanism and = that was what (Bulk) LQ was to address. Normal on-demand LQ is = incomplete because it required traffic to flow (ie, if the relay/router = also needed to inject the prefixes, no traffic would ever flow if the = injecting doesn't occur). Bulk LQ was to solve that issue. So for state = recovery, LQ & bulk LQ is the correct way to go. - Bernie -----Original Message----- From: Ralph Droms (rdroms)=20 Sent: Friday, April 03, 2009 10:04 AM To: Alfred H=CEnes Cc: draft-ietf-dhc-dhcpv6-agentopt-delegate@tools.IETF.ORG; Dhcwg WG Subject: Re: draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs. Leasequery Alfred - good question. You're right, the RAAN option introduces =20 state in the network element hosting the relay agent, which must be =20 restored if the network element loses that state. We'll review DHCPv6 leasequery to see if what extensions would be =20 required for routing state recovery. - Ralph On Apr 2, 2009, at 5:46 AM 4/2/09, Alfred H=CEnes wrote: > Hello, > studying the recently refreshed DHCPv6 RAAN Option draft, > draft-ietf-dhc-dhcpv6-agentopt-delegate-03, > I find some close relationship to [Bulk] Leasequery: > the RAAN Option is intended to establish client specific > state, e.g. routing state, on a DHCP Relay Agent node; > [Bulk] Leasequery is intended to restore such state. > > However, the DHCPv6 RAAN Option draft does not discuss this > relationship and/or potential applicability of the RAAN Option > to DHCPv6 [Bulk] Leasequery. > > I would appreciate this being discussed and perhaps, the > applicability of RAAN expanded in the next draft revision. > > > Kind regards, > Alfred H=CEnes. > > --=20 > > +------------------------=20 > +--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-=20 > Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: =20 > -18 | > | D-71254 Ditzingen | E-Mail: ah@TR-=20 > Sys.de | > +------------------------=20 > +--------------------------------------------+ > From jari.arkko@piuha.net Mon Apr 6 05:32:16 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15993A6C49 for ; Mon, 6 Apr 2009 05:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CzG-YF6jd6f for ; Mon, 6 Apr 2009 05:32:16 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E0DD33A6979 for ; Mon, 6 Apr 2009 05:32:15 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 25844198723; Mon, 6 Apr 2009 15:33:21 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id BC66D198674; Mon, 6 Apr 2009 15:33:20 +0300 (EEST) Message-ID: <49D9F689.30604@piuha.net> Date: Mon, 06 Apr 2009 15:33:13 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Bernie Volz (volz)" , draft-ietf-mipshop-mos-dhcp-options@tools.ietf.org References: <49B5828A.6020609@piuha.net> <8E296595B6471A4689555D5D725EBB210B958833@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB210B958833@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Dhcwg , Mipshop Chairs Subject: Re: [dhcwg] way forward for the mipshop-mos-dhcp document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 12:32:16 -0000 Authors, Bernie, I looked at the -12 version, and it seemed that there were a few remaining issues: > *Note: The values `0` '4' to '255' are reserved and MUST NOT be used. ... values '0' and '4' to '255' are reserved ... (2 instances in the document) Also, in Section 5: > The sub-option Codes are summarized below. This text appears to have moved to an incorrect place, it should preceding the table of sub-option codes... > In case that the server cannot find any Mobility Server satisfying > the requested Sub-opt Code, the server MUST return the MoS Option > with a sub-option by setting the Sub-opt Code to the requested > Sub-opt Code. > This was changed from previous version by deleting text that said something about the length of the option. Bernie's comment was that the indicated length 1 seemed incorrect. But the above text is also incorrect, now you say nothing and we can't distinguish an error from a correctly returned server address. I would suggest keeping the old text but using length 0. Two instances of this in the document. Please update the document with a -13 and have Bernie OK your changes. Once that is done, we are moving forward. Jari From volz@cisco.com Mon Apr 6 09:39:39 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD55428C1BF for ; Mon, 6 Apr 2009 09:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gcWBiKdMwF3 for ; Mon, 6 Apr 2009 09:39:33 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 607A428C157 for ; Mon, 6 Apr 2009 09:39:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,331,1235952000"; d="scan'208";a="167468752" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 06 Apr 2009 16:40:38 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n36GebpG021188; Mon, 6 Apr 2009 12:40:37 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n36GebOI025282; Mon, 6 Apr 2009 16:40:37 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 12:40:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Apr 2009 12:40:35 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB210C12D0A3@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leasequery Thread-Index: Acm0a8EEql5Dz+CpTD6GBqARNenS7AAAaJybAJodBtA= References: <895EB6E1-FD4C-4EA7-9DA9-088DFB7E4F16@cisco.com> From: "Bernie Volz (volz)" To: "John Jason Brzozowski" , "Ralph Droms (rdroms)" X-OriginalArrivalTime: 06 Apr 2009 16:40:37.0210 (UTC) FILETIME=[69DCBBA0:01C9B6D6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5718; t=1239036037; x=1239900037; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-agentop t-delegate-03=20vs.Leasequery |Sender:=20 |To:=20=22John=20Jason=20Brzozowski=22=20,=0A=20=20=20=20=20=20=20=20=22Ralph=20Drom s=20(rdroms)=22=20; bh=8v/DHfes+a5w0HqX1039Wf8FlwU/ibbYdTMde0FGNHM=; b=VCtF6ktcqnIQbvQRButsFtWdN3IEXTBxtBOWRuEY8KMbPtHbov40RsaOju uW5Hvii0biYSxs2ZbggD3qjcZsfpOSz+vTMu/cE/JXKg7NUYgg6ZV2GGf3lZ wYyRa9r66B; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: dhc WG , =?iso-8859-1?Q?Alfred_H=CEnes?= , draft-ietf-dhc-dhcpv6-agentopt-delegate@tools.IETF.ORG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 16:39:39 -0000 I'm not sure why the RAAN option would be needed at all for the Bulk LQ. The main purpose of the RAAN option was to avoid having the Relay need = to peek inside the message it is relaying to the client (and for some = messages that also requires that the Relay would have peeked inside the = message that it forwarded to the server). And, the information in the Bulk LQ is designed for relay agents (or = other devices that are NOT the client itself), so there's little reason = to add yet another set / copy of the data. I think Alfred's point was just that RAAN doesn't solve the power = failure/reboot case of how a relay agent would recover any state. That = is what BULK LQ was designed for and it already provides sufficient = data. - Bernie=20 -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of John Jason Brzozowski Sent: Friday, April 03, 2009 11:04 AM To: Ralph Droms (rdroms) Cc: dhc WG; Alfred H=CEnes; = draft-ietf-dhc-dhcpv6-agentopt-delegate@tools.IETF.ORG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 = vs.Leasequery Unless I am missing something, if the RAAN option is specified as part = of the initial lease query request via the ORO, the server will return it = to the requestor, if available. In this case the RAAN option will be = present for processing by the relay agent. Do we aim to specify how the relay agent will perform routing updates? = I assume not. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Corporation e) mailto:john_brzozowski@cable.comcast.com m) 609-377-6594 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > From: Ralph Droms > Date: Fri, 3 Apr 2009 10:50:24 -0400 > To: "Brzozowski, John" > Cc: Alfred H=CEnes , dhc WG , > > Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 = vs.Leasequery >=20 > John - I don't recall: does the leasequery draft have a mechanism > through which the routing information, as carried in the RAAN option, > can be delivered to the relay agent? >=20 > - Ralph >=20 > On Apr 3, 2009, at 10:41 AM 4/3/09, John Jason Brzozowski wrote: >=20 >> Ralph, Alfred, >>=20 >> I believe the expectation is that when a relay agent performs DHCPv6 >> bulk >> lease query the RAAN option will be retrieved as part of the >> LEASEQUERY-DATA >> Option providing the lease query includes the RAAN option (TBD). >>=20 >> RFC5007 and RFC5460 specify the protocol and mechanism required to >> retrieve >> lease data from the DHCP server. >>=20 >> Just so I am clear are we suggesting that RFC5460 and or the RAAN >> draft >> should specify how the relay agent is to rebuild routing state? >>=20 >> John >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> John Jason Brzozowski >> Comcast Corporation >> e) mailto:john_brzozowski@cable.comcast.com >> m) 609-377-6594 >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >>> From: Ralph Droms >>> Date: Fri, 3 Apr 2009 10:03:48 -0400 >>> To: Alfred H=CEnes >>> Cc: dhc WG , >>> >>> Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 >>> vs.Leasequery >>>=20 >>> Alfred - good question. You're right, the RAAN option introduces >>> state in the network element hosting the relay agent, which must be >>> restored if the network element loses that state. >>>=20 >>> We'll review DHCPv6 leasequery to see if what extensions would be >>> required for routing state recovery. >>>=20 >>> - Ralph >>>=20 >>> On Apr 2, 2009, at 5:46 AM 4/2/09, Alfred H=CEnes wrote: >>>=20 >>>> Hello, >>>> studying the recently refreshed DHCPv6 RAAN Option draft, >>>> draft-ietf-dhc-dhcpv6-agentopt-delegate-03, >>>> I find some close relationship to [Bulk] Leasequery: >>>> the RAAN Option is intended to establish client specific >>>> state, e.g. routing state, on a DHCP Relay Agent node; >>>> [Bulk] Leasequery is intended to restore such state. >>>>=20 >>>> However, the DHCPv6 RAAN Option draft does not discuss this >>>> relationship and/or potential applicability of the RAAN Option >>>> to DHCPv6 [Bulk] Leasequery. >>>>=20 >>>> I would appreciate this being discussed and perhaps, the >>>> applicability of RAAN expanded in the next draft revision. >>>>=20 >>>>=20 >>>> Kind regards, >>>> Alfred H=CEnes. >>>>=20 >>>> -- >>>>=20 >>>> +------------------------ >>>> +--------------------------------------------+ >>>> | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.- >>>> Phys. | >>>> | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: >>>> -18 | >>>> | D-71254 Ditzingen | E-Mail: ah@TR- >>>> Sys.de | >>>> +------------------------ >>>> +--------------------------------------------+ >>>>=20 >>>=20 >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >>=20 >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From john_brzozowski@cable.comcast.com Mon Apr 6 12:34:50 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6CD28C1F7 for ; Mon, 6 Apr 2009 12:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uu9vvdcTgHPg for ; Mon, 6 Apr 2009 12:34:49 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id CBD7C28C1EE for ; Mon, 6 Apr 2009 12:34:48 -0700 (PDT) Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.68896220; Mon, 06 Apr 2009 15:35:36 -0400 Received: from NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 15:35:36 -0400 Received: from 147.191.8.64 ([147.191.8.64]) by NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Mon, 6 Apr 2009 19:35:01 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Mon, 06 Apr 2009 15:34:53 -0400 From: John Jason Brzozowski To: Bernie Volz , Ralph Droms Message-ID: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leasequery Thread-Index: Acm27sH/cqbFXVFUk0SZrQJjii7vgg== In-Reply-To: <8E296595B6471A4689555D5D725EBB210C12D0A3@xmb-rtp-20a.amer.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 06 Apr 2009 19:35:36.0220 (UTC) FILETIME=[DBC285C0:01C9B6EE] Cc: dhc WG , Alfred =?ISO-8859-1?B?SM5uZXM=?= , draft-ietf-dhc-dhcpv6-agentopt-delegate@tools.IETF.ORG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 19:34:50 -0000 Perhaps I am missing something if a relay agent simply performs bulk leasequery this at best results in all lease data being proactively re-populated which does not explicitly suggest that routing information wil= l be re-established right? So in cases where the bindings are being used for access control the relay agent would have all the information required. However, for cases where routing state needs to be recreated proactively I was operating under the assumption that the bulk leasequery would specify i= n the ORO the RAAN option to ensure that this data is returned in the LEASEQUERY-DATA in turn enabling the relay agent to (re)create routing state. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Corporation e) mailto:john_brzozowski@cable.comcast.com m) 609-377-6594 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > From: Bernie Volz > Date: Mon, 6 Apr 2009 12:40:35 -0400 > To: "Brzozowski, John" , Ralph Droms > > Cc: dhc WG , Alfred H=CEnes , > > Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leaseq= uery >=20 > I'm not sure why the RAAN option would be needed at all for the Bulk LQ. >=20 > The main purpose of the RAAN option was to avoid having the Relay need to= peek > inside the message it is relaying to the client (and for some messages th= at > also requires that the Relay would have peeked inside the message that it > forwarded to the server). >=20 > And, the information in the Bulk LQ is designed for relay agents (or othe= r > devices that are NOT the client itself), so there's little reason to add = yet > another set / copy of the data. >=20 > I think Alfred's point was just that RAAN doesn't solve the power > failure/reboot case of how a relay agent would recover any state. That is= what > BULK LQ was designed for and it already provides sufficient data. >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= John > Jason Brzozowski > Sent: Friday, April 03, 2009 11:04 AM > To: Ralph Droms (rdroms) > Cc: dhc WG; Alfred H=CEnes; > draft-ietf-dhc-dhcpv6-agentopt-delegate@tools.IETF.ORG > Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leaseq= uery >=20 > Unless I am missing something, if the RAAN option is specified as part of > the initial lease query request via the ORO, the server will return it to > the requestor, if available. In this case the RAAN option will be presen= t > for processing by the relay agent. >=20 > Do we aim to specify how the relay agent will perform routing updates? I > assume not. >=20 > John > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > John Jason Brzozowski > Comcast Corporation > e) mailto:john_brzozowski@cable.comcast.com > m) 609-377-6594 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >> From: Ralph Droms >> Date: Fri, 3 Apr 2009 10:50:24 -0400 >> To: "Brzozowski, John" >> Cc: Alfred H=CEnes , dhc WG , >> >> Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Lease= query >>=20 >> John - I don't recall: does the leasequery draft have a mechanism >> through which the routing information, as carried in the RAAN option, >> can be delivered to the relay agent? >>=20 >> - Ralph >>=20 >> On Apr 3, 2009, at 10:41 AM 4/3/09, John Jason Brzozowski wrote: >>=20 >>> Ralph, Alfred, >>>=20 >>> I believe the expectation is that when a relay agent performs DHCPv6 >>> bulk >>> lease query the RAAN option will be retrieved as part of the >>> LEASEQUERY-DATA >>> Option providing the lease query includes the RAAN option (TBD). >>>=20 >>> RFC5007 and RFC5460 specify the protocol and mechanism required to >>> retrieve >>> lease data from the DHCP server. >>>=20 >>> Just so I am clear are we suggesting that RFC5460 and or the RAAN >>> draft >>> should specify how the relay agent is to rebuild routing state? >>>=20 >>> John >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> John Jason Brzozowski >>> Comcast Corporation >>> e) mailto:john_brzozowski@cable.comcast.com >>> m) 609-377-6594 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>>=20 >>>> From: Ralph Droms >>>> Date: Fri, 3 Apr 2009 10:03:48 -0400 >>>> To: Alfred H=CEnes >>>> Cc: dhc WG , >>>> >>>> Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 >>>> vs.Leasequery >>>>=20 >>>> Alfred - good question. You're right, the RAAN option introduces >>>> state in the network element hosting the relay agent, which must be >>>> restored if the network element loses that state. >>>>=20 >>>> We'll review DHCPv6 leasequery to see if what extensions would be >>>> required for routing state recovery. >>>>=20 >>>> - Ralph >>>>=20 >>>> On Apr 2, 2009, at 5:46 AM 4/2/09, Alfred H=CEnes wrote: >>>>=20 >>>>> Hello, >>>>> studying the recently refreshed DHCPv6 RAAN Option draft, >>>>> draft-ietf-dhc-dhcpv6-agentopt-delegate-03, >>>>> I find some close relationship to [Bulk] Leasequery: >>>>> the RAAN Option is intended to establish client specific >>>>> state, e.g. routing state, on a DHCP Relay Agent node; >>>>> [Bulk] Leasequery is intended to restore such state. >>>>>=20 >>>>> However, the DHCPv6 RAAN Option draft does not discuss this >>>>> relationship and/or potential applicability of the RAAN Option >>>>> to DHCPv6 [Bulk] Leasequery. >>>>>=20 >>>>> I would appreciate this being discussed and perhaps, the >>>>> applicability of RAAN expanded in the next draft revision. >>>>>=20 >>>>>=20 >>>>> Kind regards, >>>>> Alfred H=CEnes. >>>>>=20 >>>>> -- >>>>>=20 >>>>> +------------------------ >>>>> +--------------------------------------------+ >>>>> | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.- >>>>> Phys. | >>>>> | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: >>>>> -18 | >>>>> | D-71254 Ditzingen | E-Mail: ah@TR- >>>>> Sys.de | >>>>> +------------------------ >>>>> +--------------------------------------------+ >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dhcwg mailing list >>>> dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Apr 6 12:42:32 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE12828C27C for ; Mon, 6 Apr 2009 12:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJPQuduipLYe for ; Mon, 6 Apr 2009 12:42:25 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1F04E28C286 for ; Mon, 6 Apr 2009 12:41:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,332,1235952000"; d="scan'208";a="281307181" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 06 Apr 2009 19:42:58 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n36JgwoC001436; Mon, 6 Apr 2009 15:42:58 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n36JgwHw012675; Mon, 6 Apr 2009 19:42:58 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 15:42:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Apr 2009 15:42:55 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB210C12D1AB@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leasequery Thread-Index: Acm27sH/cqbFXVFUk0SZrQJjii7vggAAGnvw References: <8E296595B6471A4689555D5D725EBB210C12D0A3@xmb-rtp-20a.amer.cisco.com> From: "Bernie Volz (volz)" To: "John Jason Brzozowski" , "Ralph Droms (rdroms)" X-OriginalArrivalTime: 06 Apr 2009 19:42:58.0578 (UTC) FILETIME=[E36CFF20:01C9B6EF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8860; t=1239046978; x=1239910978; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-agentop t-delegate-03=20vs.Leasequery |Sender:=20 |To:=20=22John=20Jason=20Brzozowski=22=20,=0A=20=20=20=20=20=20=20=20=22Ralph=20Drom s=20(rdroms)=22=20; bh=317NMupAonCavo2lg355OVx24nHuionIsCJb8Xwun/Y=; b=dl4K/EK9qSmPxdivbh0sQQ37M8P5oppDqG4Zk7fT/WxenXf2hjuFj32j9H Pw1zTMdO6Bx6EmpMyigs3HsrwDR+eRkB5SzCJZepHbDdN/Y58dclkEqSf7k3 /r7cEC9J/R; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: dhc WG , =?iso-8859-1?Q?Alfred_H=CEnes?= , draft-ietf-dhc-dhcpv6-agentopt-delegate@tools.IETF.ORG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 vs.Leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 19:42:33 -0000 The RAAN option as it is presently defined just contains the IAADDR and = IAPREFIX options: The RAAN option carries information about assigned IPv6 addresses and prefixes. It encapsulates IA Address options (RFC 3315) and/or IA Prefix options (RFC 3633), and possibly other options that carry other information related to the assigned IPv6 address or prefix. ... The contents of options encapsulated in the RAAN option are interpreted according to the use of those options in the node on which the relay agent is implemented. For the purposes of address and prefix assignment, the uses of the DHCP IA Address and IA Prefix options are defined in this document. As Bulk LQ also returns this information, what information would be = missing? And, if there were additional options defined to be = encapsulated in the RAAN option, it would likely be easier if for Bulk = LQ these were directly requested (in the ORO) and returned rather than = having to encapsulate in the RAAN option? But I guess that will need to = wait until they are defined? - Bernie -----Original Message----- From: John Jason Brzozowski [mailto:john_brzozowski@cable.comcast.com]=20 Sent: Monday, April 06, 2009 3:35 PM To: Bernie Volz (volz); Ralph Droms (rdroms) Cc: dhc WG; Alfred H=CEnes; = draft-ietf-dhc-dhcpv6-agentopt-delegate@tools.IETF.ORG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 = vs.Leasequery Perhaps I am missing something if a relay agent simply performs bulk leasequery this at best results in all lease data being proactively re-populated which does not explicitly suggest that routing information = will be re-established right? So in cases where the bindings are being used = for access control the relay agent would have all the information required. However, for cases where routing state needs to be recreated proactively = I was operating under the assumption that the bulk leasequery would = specify in the ORO the RAAN option to ensure that this data is returned in the LEASEQUERY-DATA in turn enabling the relay agent to (re)create routing state. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Corporation e) mailto:john_brzozowski@cable.comcast.com m) 609-377-6594 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > From: Bernie Volz > Date: Mon, 6 Apr 2009 12:40:35 -0400 > To: "Brzozowski, John" , Ralph = Droms > > Cc: dhc WG , Alfred H=CEnes , > > Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 = vs.Leasequery >=20 > I'm not sure why the RAAN option would be needed at all for the Bulk = LQ. >=20 > The main purpose of the RAAN option was to avoid having the Relay need = to peek > inside the message it is relaying to the client (and for some messages = that > also requires that the Relay would have peeked inside the message that = it > forwarded to the server). >=20 > And, the information in the Bulk LQ is designed for relay agents (or = other > devices that are NOT the client itself), so there's little reason to = add yet > another set / copy of the data. >=20 > I think Alfred's point was just that RAAN doesn't solve the power > failure/reboot case of how a relay agent would recover any state. That = is what > BULK LQ was designed for and it already provides sufficient data. >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of John > Jason Brzozowski > Sent: Friday, April 03, 2009 11:04 AM > To: Ralph Droms (rdroms) > Cc: dhc WG; Alfred H=CEnes; > draft-ietf-dhc-dhcpv6-agentopt-delegate@tools.IETF.ORG > Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 = vs.Leasequery >=20 > Unless I am missing something, if the RAAN option is specified as part = of > the initial lease query request via the ORO, the server will return it = to > the requestor, if available. In this case the RAAN option will be = present > for processing by the relay agent. >=20 > Do we aim to specify how the relay agent will perform routing updates? = I > assume not. >=20 > John > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > John Jason Brzozowski > Comcast Corporation > e) mailto:john_brzozowski@cable.comcast.com > m) 609-377-6594 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >> From: Ralph Droms >> Date: Fri, 3 Apr 2009 10:50:24 -0400 >> To: "Brzozowski, John" >> Cc: Alfred H=CEnes , dhc WG , >> >> Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 = vs.Leasequery >>=20 >> John - I don't recall: does the leasequery draft have a mechanism >> through which the routing information, as carried in the RAAN option, >> can be delivered to the relay agent? >>=20 >> - Ralph >>=20 >> On Apr 3, 2009, at 10:41 AM 4/3/09, John Jason Brzozowski wrote: >>=20 >>> Ralph, Alfred, >>>=20 >>> I believe the expectation is that when a relay agent performs DHCPv6 >>> bulk >>> lease query the RAAN option will be retrieved as part of the >>> LEASEQUERY-DATA >>> Option providing the lease query includes the RAAN option (TBD). >>>=20 >>> RFC5007 and RFC5460 specify the protocol and mechanism required to >>> retrieve >>> lease data from the DHCP server. >>>=20 >>> Just so I am clear are we suggesting that RFC5460 and or the RAAN >>> draft >>> should specify how the relay agent is to rebuild routing state? >>>=20 >>> John >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> John Jason Brzozowski >>> Comcast Corporation >>> e) mailto:john_brzozowski@cable.comcast.com >>> m) 609-377-6594 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>>=20 >>>> From: Ralph Droms >>>> Date: Fri, 3 Apr 2009 10:03:48 -0400 >>>> To: Alfred H=CEnes >>>> Cc: dhc WG , >>>> >>>> Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-agentopt-delegate-03 >>>> vs.Leasequery >>>>=20 >>>> Alfred - good question. You're right, the RAAN option introduces >>>> state in the network element hosting the relay agent, which must be >>>> restored if the network element loses that state. >>>>=20 >>>> We'll review DHCPv6 leasequery to see if what extensions would be >>>> required for routing state recovery. >>>>=20 >>>> - Ralph >>>>=20 >>>> On Apr 2, 2009, at 5:46 AM 4/2/09, Alfred H=CEnes wrote: >>>>=20 >>>>> Hello, >>>>> studying the recently refreshed DHCPv6 RAAN Option draft, >>>>> draft-ietf-dhc-dhcpv6-agentopt-delegate-03, >>>>> I find some close relationship to [Bulk] Leasequery: >>>>> the RAAN Option is intended to establish client specific >>>>> state, e.g. routing state, on a DHCP Relay Agent node; >>>>> [Bulk] Leasequery is intended to restore such state. >>>>>=20 >>>>> However, the DHCPv6 RAAN Option draft does not discuss this >>>>> relationship and/or potential applicability of the RAAN Option >>>>> to DHCPv6 [Bulk] Leasequery. >>>>>=20 >>>>> I would appreciate this being discussed and perhaps, the >>>>> applicability of RAAN expanded in the next draft revision. >>>>>=20 >>>>>=20 >>>>> Kind regards, >>>>> Alfred H=CEnes. >>>>>=20 >>>>> -- >>>>>=20 >>>>> +------------------------ >>>>> +--------------------------------------------+ >>>>> | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.- >>>>> Phys. | >>>>> | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: >>>>> -18 | >>>>> | D-71254 Ditzingen | E-Mail: ah@TR- >>>>> Sys.de | >>>>> +------------------------ >>>>> +--------------------------------------------+ >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dhcwg mailing list >>>> dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From swb@employees.org Tue Apr 7 11:24:09 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930B23A68EC; Tue, 7 Apr 2009 11:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-MoldEV9-QQ; Tue, 7 Apr 2009 11:24:08 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9B3A03A688F; Tue, 7 Apr 2009 11:24:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,338,1235952000"; d="scan'208";a="41106122" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Apr 2009 18:25:13 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n37IPDYp026053; Tue, 7 Apr 2009 14:25:13 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n37IPDNI018617; Tue, 7 Apr 2009 18:25:13 GMT Date: Tue, 7 Apr 2009 14:25:11 -0400 From: Scott Brim To: Black_David@emc.com Message-ID: <20090407182511.GA98039@cisco.com> Mail-Followup-To: Scott Brim , Black_David@emc.com, gen-art@ietf.org, ietf@ietf.org, rdroms@cisco.com, dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral X-Mailman-Approved-At: Wed, 08 Apr 2009 13:26:59 -0700 Cc: dhcwg@ietf.org, gen-art@ietf.org, ietf@ietf.org, rdroms@cisco.com Subject: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 18:24:09 -0000 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-dhc-container-00 Reviewer: Scott Brim Review Date: 7 April 2009 IESG Telechat date: 14 April 2009 Summary: This draft is on the right track but has open issues. Comments: More significant: I am concerned about multiple interface scenarios as are being discussed in MIF and 6MAN, where either the RG is multiply connected or the end device is. For a discussion of the sort of problems that lead to this concern, see (for example) notes from the MIF BOF at IETF74. - There must be a way to associate options with a particular upstream DHS they were obtained from, when the container is passed to the RG server and perhaps to the end device. This source information may or may not be in the container itself -- that's up to the WG to decide. If it is decided that the source information will not be part of the container syntax, at least the fact that it is necessary should be documented for people who ultimately do specify how container options are passed. - The SP server may have its ideas of how a consumer device should be configured, but it is not appropriate to say that the "SP server MUST be able to control which DHCP options are transmitted to the consumer device". The RG server may need to make decisions about information from multiple DHCP servers. Perhaps you could say that the SP server MUST be able to "provide information" to the RG server. Less significant: 5.1 and 5.2 Alignment between the v4 and v6 descriptions would be better. The v4 description has "code" in the diagram and says that "code" is OPTION_CONTAINER_V4. The v6 description has "OPTION_CONTAINER_V6" in the diagram and says that "option-code" is OPTION_CONTAINER_V6. From rdroms@cisco.com Fri Apr 10 12:24:43 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D5A3A6D52; Fri, 10 Apr 2009 12:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T87cPV0+KamB; Fri, 10 Apr 2009 12:24:42 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id AB4B03A67F0; Fri, 10 Apr 2009 12:24:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,168,1238976000"; d="scan'208";a="41514972" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Apr 2009 19:25:50 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3AJPo5O018923; Fri, 10 Apr 2009 15:25:50 -0400 Received: from bxb-rdroms-8711.cisco.com (bxb-rdroms-8711.cisco.com [10.98.10.82]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3AJPn4Z026942; Fri, 10 Apr 2009 19:25:49 GMT Message-Id: From: Ralph Droms To: Scott Brim In-Reply-To: <20090407182511.GA98039@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 10 Apr 2009 15:25:49 -0400 References: <20090407182511.GA98039@cisco.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3387; t=1239391550; x=1240255550; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20Gen-ART=20review=20of=20draft-ietf-dhc- container-00 |Sender:=20 |To:=20Scott=20Brim=20; bh=T893YAcfxlhkTX7j2QQFW99wba63VcoBKs40bwM71BA=; b=ED8sIqeeRa1+V7aTg8qAaIeYJbGT6DIdLCU0GDLN+IBKU5Vic1bfdcWymn Py3gqYSKZIJD4+s/OBxc8bRNd5JMsjUoF9FL4x9nu10pDF4oIJIfOmxmC5lR +wShtzl3Lq; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: dhc WG , gen-art@ietf.org, Black_David@emc.com, ietf@ietf.org Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 19:24:43 -0000 Scott raises an interesting point about identifying the source of options when delivered to clients. BTW, Scott - what is "DHS"? The usual case - almost the only case today - is that there is a single upstream service provider and a single source of DHCP options to be passed along to the client. In this scenario, there's no need to pass along any information identifying the source of the options. To allow for a multihomed subscriber network, I can imagine adding a tag that would be passed along with the options so the subscriber client can identify the source of each option. But, what would the client do with that information? How would the client interpret it? What is the syntax and semantics of the tagging? Taken a step farther, sourcing information might be required even if there is no intermediate RG and the contained option is not in use. How does a device with multiple interfaces make policy decisions about information received on those multiple interfaces (which is pretty much the question Scott asks about the container option)? - Ralph On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-dhc-container-00 > Reviewer: Scott Brim > Review Date: 7 April 2009 > IESG Telechat date: 14 April 2009 > > Summary: > > This draft is on the right track but has open issues. > > Comments: > > More significant: > > I am concerned about multiple interface scenarios as are being > discussed in MIF and 6MAN, where either the RG is multiply connected > or the end device is. For a discussion of the sort of problems that > lead to this concern, see (for example) notes from the MIF BOF at > IETF74. > > - There must be a way to associate options with a particular > upstream DHS they were obtained from, when the container is passed > to the RG server and perhaps to the end device. This source > information may or may not be in the container itself -- that's up > to the WG to decide. If it is decided that the source information > will not be part of the container syntax, at least the fact that > it is necessary should be documented for people who ultimately do > specify how container options are passed. > > - The SP server may have its ideas of how a consumer device should > be configured, but it is not appropriate to say that the "SP > server MUST be able to control which DHCP options are transmitted > to the consumer device". The RG server may need to make decisions > about information from multiple DHCP servers. Perhaps you could > say that the SP server MUST be able to "provide information" to > the RG server. > > Less significant: > > 5.1 and 5.2 > > Alignment between the v4 and v6 descriptions would be better. The > v4 description has "code" in the diagram and says that "code" is > OPTION_CONTAINER_V4. The v6 description has "OPTION_CONTAINER_V6" > in the diagram and says that "option-code" is OPTION_CONTAINER_V6. From swb@employees.org Sat Apr 11 02:59:40 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECFE53A67F9; Sat, 11 Apr 2009 02:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDK1yrtiiG4X; Sat, 11 Apr 2009 02:59:39 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C1C073A67CC; Sat, 11 Apr 2009 02:59:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,171,1238976000"; d="scan'208";a="153583723" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 11 Apr 2009 10:00:48 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3BA0mCC012297; Sat, 11 Apr 2009 03:00:48 -0700 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3BA0mKs029242; Sat, 11 Apr 2009 10:00:48 GMT Date: Sat, 11 Apr 2009 06:00:44 -0400 From: Scott Brim To: Ralph Droms Message-ID: <20090411100044.GA96599@cisco.com> Mail-Followup-To: Scott Brim , Ralph Droms , Black_David@emc.com, gen-art@ietf.org, ietf@ietf.org, dhc WG , mif References: <20090407182511.GA98039@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: sj-dkim-4; header.From=swb@employees.org; dkim=neutral Cc: dhc WG , gen-art@ietf.org, mif , Black_David@emc.com, ietf@ietf.org Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 09:59:41 -0000 Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: > Scott raises an interesting point about identifying the source of > options when delivered to clients. > > BTW, Scott - what is "DHS"? Sorry, DHCP server > The usual case - almost the only case today - is that there is a single > upstream service provider and a single source of DHCP options to be > passed along to the client. In this scenario, there's no need to pass > along any information identifying the source of the options. > > To allow for a multihomed subscriber network, I can imagine adding a tag > that would be passed along with the options so the subscriber client can > identify the source of each option. But, what would the client do with > that information? How would the client interpret it? What is the syntax > and semantics of the tagging? > > Taken a step farther, sourcing information might be required even if > there is no intermediate RG and the contained option is not in use. How > does a device with multiple interfaces make policy decisions about > information received on those multiple interfaces (which is pretty much > the question Scott asks about the container option)? > > - Ralph Well put. It all comes down to where information is going to be merged. The case where a single RG client connected to multiple SP servers is essentially already covered by MIF/6man, they just need to document it. If the information is merged at the RG server, then the RG server should somehow know which interface which DHCP information came from. If all of the information is transparently passed to the consumer device, then it needs the tags as well. I don't know how the information could be usefully tagged -- the SP server's IP address doesn't sound like a good idea. The WG should decide if tagging should be included in the container syntax or added later (but documented now as needing study). I'm CCing MIF in case people there aren't on the ietf list. Thanks ... Scott > > On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: > >> I have been selected as the General Area Review Team (Gen-ART) >> reviewer for this draft (for background on Gen-ART, please see >> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >> >> Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> Document: draft-ietf-dhc-container-00 >> Reviewer: Scott Brim >> Review Date: 7 April 2009 >> IESG Telechat date: 14 April 2009 >> >> Summary: >> >> This draft is on the right track but has open issues. >> >> Comments: >> >> More significant: >> >> I am concerned about multiple interface scenarios as are being >> discussed in MIF and 6MAN, where either the RG is multiply connected >> or the end device is. For a discussion of the sort of problems that >> lead to this concern, see (for example) notes from the MIF BOF at >> IETF74. >> >> - There must be a way to associate options with a particular >> upstream DHS they were obtained from, when the container is passed >> to the RG server and perhaps to the end device. This source >> information may or may not be in the container itself -- that's up >> to the WG to decide. If it is decided that the source information >> will not be part of the container syntax, at least the fact that >> it is necessary should be documented for people who ultimately do >> specify how container options are passed. >> >> - The SP server may have its ideas of how a consumer device should >> be configured, but it is not appropriate to say that the "SP >> server MUST be able to control which DHCP options are transmitted >> to the consumer device". The RG server may need to make decisions >> about information from multiple DHCP servers. Perhaps you could >> say that the SP server MUST be able to "provide information" to >> the RG server. >> >> Less significant: >> >> 5.1 and 5.2 >> >> Alignment between the v4 and v6 descriptions would be better. The >> v4 description has "code" in the diagram and says that "code" is >> OPTION_CONTAINER_V4. The v6 description has "OPTION_CONTAINER_V6" >> in the diagram and says that "option-code" is OPTION_CONTAINER_V6. From rdroms@cisco.com Sat Apr 11 10:41:06 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59DC53A69D4; Sat, 11 Apr 2009 10:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-eWdfIz+to1; Sat, 11 Apr 2009 10:41:05 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id F1F273A685F; Sat, 11 Apr 2009 10:40:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,172,1238976000"; d="scan'208";a="41642031" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Apr 2009 17:41:42 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3BHfgqG007591; Sat, 11 Apr 2009 13:41:42 -0400 Received: from bxb-rdroms-8711.cisco.com (bxb-rdroms-8711.cisco.com [10.98.10.82]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3BHfgZg006944; Sat, 11 Apr 2009 17:41:42 GMT Message-Id: From: Ralph Droms To: Scott Brim In-Reply-To: <20090411100044.GA96599@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 11 Apr 2009 13:41:42 -0400 References: <20090407182511.GA98039@cisco.com> <20090411100044.GA96599@cisco.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5100; t=1239471702; x=1240335702; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20Gen-ART=20review=20of=20draft-ietf-dhc- container-00 |Sender:=20 |To:=20Scott=20Brim=20; bh=aW7Lfr56YKhXFcD93VJkms4NzcXCLvRGvhgM6huBT7M=; b=u4tG455oj9OtVIa3wcG5O9FUtqPwuMDeoCiiWVQ9hNprOeIArEtA9KHavx VvkfeABBYKQEdRXHCG4M521OXfh8eKrAeuFurOxsilcMF9gXX6H9DP9Qo7+1 faIDoTd9gX; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: dhc WG , gen-art@ietf.org, mif , Black_David@emc.com, ietf@ietf.org Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 17:41:06 -0000 Scott - even knowing "which interface which DHCP information came from" may not be enough for a device with multiple interfaces. Can policies for merging information be written just based on the characteristics of the interface - say, 3GPP versus 802.11, or IP address of the interface - or does the device need to differentiate between Verizon Wireless and Starbucks if I'm away from home? Or differentiate between my AT&T femtocell and my home WiFi network? - Ralph On Apr 11, 2009, at 6:00 AM 4/11/09, Scott Brim wrote: > Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >> Scott raises an interesting point about identifying the source of >> options when delivered to clients. >> >> BTW, Scott - what is "DHS"? > > Sorry, DHCP server > >> The usual case - almost the only case today - is that there is a >> single >> upstream service provider and a single source of DHCP options to be >> passed along to the client. In this scenario, there's no need to >> pass >> along any information identifying the source of the options. >> >> To allow for a multihomed subscriber network, I can imagine adding >> a tag >> that would be passed along with the options so the subscriber >> client can >> identify the source of each option. But, what would the client do >> with >> that information? How would the client interpret it? What is the >> syntax >> and semantics of the tagging? >> >> Taken a step farther, sourcing information might be required even if >> there is no intermediate RG and the contained option is not in >> use. How >> does a device with multiple interfaces make policy decisions about >> information received on those multiple interfaces (which is pretty >> much >> the question Scott asks about the container option)? >> >> - Ralph > > Well put. It all comes down to where information is going to be > merged. The case where a single RG client connected to multiple SP > servers is essentially already covered by MIF/6man, they just need to > document it. If the information is merged at the RG server, then the > RG server should somehow know which interface which DHCP information > came from. If all of the information is transparently passed to the > consumer device, then it needs the tags as well. > > I don't know how the information could be usefully tagged -- the SP > server's IP address doesn't sound like a good idea. The WG should > decide if tagging should be included in the container syntax or added > later (but documented now as needing study). > > I'm CCing MIF in case people there aren't on the ietf list. > > Thanks ... Scott > >> >> On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >> >>> I have been selected as the General Area Review Team (Gen-ART) >>> reviewer for this draft (for background on Gen-ART, please see >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>> >>> Please wait for direction from your document shepherd >>> or AD before posting a new version of the draft. >>> >>> Document: draft-ietf-dhc-container-00 >>> Reviewer: Scott Brim >>> Review Date: 7 April 2009 >>> IESG Telechat date: 14 April 2009 >>> >>> Summary: >>> >>> This draft is on the right track but has open issues. >>> >>> Comments: >>> >>> More significant: >>> >>> I am concerned about multiple interface scenarios as are being >>> discussed in MIF and 6MAN, where either the RG is multiply >>> connected >>> or the end device is. For a discussion of the sort of problems >>> that >>> lead to this concern, see (for example) notes from the MIF BOF at >>> IETF74. >>> >>> - There must be a way to associate options with a particular >>> upstream DHS they were obtained from, when the container is >>> passed >>> to the RG server and perhaps to the end device. This source >>> information may or may not be in the container itself -- that's >>> up >>> to the WG to decide. If it is decided that the source >>> information >>> will not be part of the container syntax, at least the fact that >>> it is necessary should be documented for people who ultimately do >>> specify how container options are passed. >>> >>> - The SP server may have its ideas of how a consumer device should >>> be configured, but it is not appropriate to say that the "SP >>> server MUST be able to control which DHCP options are transmitted >>> to the consumer device". The RG server may need to make >>> decisions >>> about information from multiple DHCP servers. Perhaps you could >>> say that the SP server MUST be able to "provide information" to >>> the RG server. >>> >>> Less significant: >>> >>> 5.1 and 5.2 >>> >>> Alignment between the v4 and v6 descriptions would be better. The >>> v4 description has "code" in the diagram and says that "code" is >>> OPTION_CONTAINER_V4. The v6 description has >>> "OPTION_CONTAINER_V6" >>> in the diagram and says that "option-code" is >>> OPTION_CONTAINER_V6. From denghui02@gmail.com Sat Apr 11 23:32:58 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D073A6BAB; Sat, 11 Apr 2009 23:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpbkAwmVSbja; Sat, 11 Apr 2009 23:32:57 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id DAB183A6B46; Sat, 11 Apr 2009 23:32:56 -0700 (PDT) Received: by ewy9 with SMTP id 9so1700710ewy.37 for ; Sat, 11 Apr 2009 23:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Fl0vlIaF3dWXtZdLrEPkiIKSYPk32ICY2+IAS+npTqs=; b=KCxo2gc7aOI4hLfiAU7QwLfvv4zGUDwFAXJT4t79hqRaZWIXkV2UL8EgWaoA7+Pp6f qfAMjQbXm7p+Dl2Or3RZkpF9w+/W3gEXycBX4KfSxoinab/HUVa4j+ygpzGR+y23gLk1 fLIjoLAhhAlk6eHMPGlfvKJTZrfXfO4k9U0g0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=XVyYRCtTNyPO3ACnbypWoMGx8TZWlMHtfiR8OaK0fIvItJR/sWGuju6/su36mlDHfj NwSyjK2teCXcvq9u/wqy8sXjgeLCgFmwa3WXiMg8XzP7027C3QICaeVDABaI/9sS4jNt 5kyJvD2xDEVjCf9y0RxXJafIj1yiEvIA+V4Oc= MIME-Version: 1.0 Received: by 10.210.62.12 with SMTP id k12mr955591eba.44.1239518045998; Sat, 11 Apr 2009 23:34:05 -0700 (PDT) In-Reply-To: <20090411100044.GA96599@cisco.com> References: <20090407182511.GA98039@cisco.com> <20090411100044.GA96599@cisco.com> Date: Sun, 12 Apr 2009 14:34:05 +0800 Message-ID: <1d38a3350904112334s5fc9d40bp269ec389c27f1a38@mail.gmail.com> From: Hui Deng To: Scott Brim , Ralph Droms , Black_David@emc.com, gen-art@ietf.org, ietf@ietf.org, dhc WG , mif Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 06:32:58 -0000 Hi, Scott, Based on the current MIF charter proposal, it consider only host. http://www.ietf.org/mail-archive/web/mif/current/msg00367.html I am wondering whether RG is a kind of host? Anyhow, this discussion benefit MIF for the future consideration how to identify the source. Many thanks -Hui 2009/4/11 Scott Brim : > Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >> Scott raises an interesting point about identifying the source of >> options when delivered to clients. >> >> BTW, Scott - what is "DHS"? > > Sorry, DHCP server > >> The usual case - almost the only case today - is that there is a single >> upstream service provider and a single source of DHCP options to be >> passed along to the client. =A0In this scenario, there's no need to pass >> along any information identifying the source of the options. >> >> To allow for a multihomed subscriber network, I can imagine adding a tag >> that would be passed along with the options so the subscriber client can >> identify the source of each option. =A0But, what would the client do wit= h >> that information? =A0How would the client interpret it? =A0What is the s= yntax >> and semantics of the tagging? >> >> Taken a step farther, sourcing information might be required even if >> there is no intermediate RG and the contained option is not in use. =A0H= ow >> does a device with multiple interfaces make policy decisions about >> information received on those multiple interfaces (which is pretty much >> the question Scott asks about the container option)? >> >> - Ralph > > Well put. =A0It all comes down to where information is going to be > merged. =A0The case where a single RG client connected to multiple SP > servers is essentially already covered by MIF/6man, they just need to > document it. =A0If the information is merged at the RG server, then the > RG server should somehow know which interface which DHCP information > came from. =A0If all of the information is transparently passed to the > consumer device, then it needs the tags as well. > > I don't know how the information could be usefully tagged -- the SP > server's IP address doesn't sound like a good idea. =A0The WG should > decide if tagging should be included in the container syntax or added > later (but documented now as needing study). > > I'm CCing MIF in case people there aren't on the ietf list. > > Thanks ... Scott > >> >> On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >> >>> I have been selected as the General Area Review Team (Gen-ART) >>> reviewer for this draft (for background on Gen-ART, please see >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>> >>> Please wait for direction from your document shepherd >>> or AD before posting a new version of the draft. >>> >>> Document: draft-ietf-dhc-container-00 >>> Reviewer: Scott Brim >>> Review Date: =A0 =A0 =A0 =A0 7 April 2009 >>> IESG Telechat date: 14 April 2009 >>> >>> Summary: >>> >>> This draft is on the right track but has open issues. >>> >>> Comments: >>> >>> More significant: >>> >>> =A0 I am concerned about multiple interface scenarios as are being >>> =A0 discussed in MIF and 6MAN, where either the RG is multiply connecte= d >>> =A0 or the end device is. =A0For a discussion of the sort of problems t= hat >>> =A0 lead to this concern, see (for example) notes from the MIF BOF at >>> =A0 IETF74. >>> >>> =A0 - There must be a way to associate options with a particular >>> =A0 =A0 upstream DHS they were obtained from, when the container is pas= sed >>> =A0 =A0 to the RG server and perhaps to the end device. =A0This source >>> =A0 =A0 information may or may not be in the container itself -- that's= up >>> =A0 =A0 to the WG to decide. =A0If it is decided that the source inform= ation >>> =A0 =A0 will not be part of the container syntax, at least the fact tha= t >>> =A0 =A0 it is necessary should be documented for people who ultimately = do >>> =A0 =A0 specify how container options are passed. >>> >>> =A0 - The SP server may have its ideas of how a consumer device should >>> =A0 =A0 be configured, but it is not appropriate to say that the "SP >>> =A0 =A0 server MUST be able to control which DHCP options are transmitt= ed >>> =A0 =A0 to the consumer device". =A0The RG server may need to make deci= sions >>> =A0 =A0 about information from multiple DHCP servers. =A0Perhaps you co= uld >>> =A0 =A0 say that the SP server MUST be able to "provide information" to >>> =A0 =A0 the RG server. >>> >>> Less significant: >>> >>> =A0 5.1 and 5.2 >>> >>> =A0 =A0 Alignment between the v4 and v6 descriptions would be better. T= he >>> =A0 =A0 v4 description has "code" in the diagram and says that "code" i= s >>> =A0 =A0 OPTION_CONTAINER_V4. =A0The v6 description has "OPTION_CONTAINE= R_V6" >>> =A0 =A0 in the diagram and says that "option-code" is OPTION_CONTAINER_= V6. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From mstjohns@comcast.net Sat Apr 11 12:59:26 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336793A68FE for ; Sat, 11 Apr 2009 12:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ehRGkUZGEMw for ; Sat, 11 Apr 2009 12:59:25 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id EC3213A6917 for ; Sat, 11 Apr 2009 12:59:24 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA03.westchester.pa.mail.comcast.net with comcast id eEtl1b0021GhbT853L0Cem; Sat, 11 Apr 2009 20:00:12 +0000 Received: from MIKES-LAPTOM.comcast.net ([68.48.0.201]) by OMTA07.westchester.pa.mail.comcast.net with comcast id eL0a1b0054LCBKY3TL0a2M; Sat, 11 Apr 2009 20:00:35 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 11 Apr 2009 16:00:33 -0400 To: Ralph Droms ,Scott Brim From: Michael StJohns In-Reply-To: References: <20090407182511.GA98039@cisco.com> <20090411100044.GA96599@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20090411195924.EC3213A6917@core3.amsl.com> X-Mailman-Approved-At: Mon, 13 Apr 2009 02:44:44 -0700 Cc: dhc WG , gen-art@ietf.org, mif , Black_David@emc.com, ietf@ietf.org Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:59:26 -0000 Sorry to stick my oar in, but does this or could this interact with the options specified in RFC3046 in an unexpected way? At 01:41 PM 4/11/2009, Ralph Droms wrote: >Scott - even knowing "which interface which DHCP information came >from" may not be enough for a device with multiple interfaces. Can >policies for merging information be written just based on the >characteristics of the interface - say, 3GPP versus 802.11, or IP >address of the interface - or does the device need to differentiate >between Verizon Wireless and Starbucks if I'm away from home? Or >differentiate between my AT&T femtocell and my home WiFi network? > >- Ralph > >On Apr 11, 2009, at 6:00 AM 4/11/09, Scott Brim wrote: > >>Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >>>Scott raises an interesting point about identifying the source of >>>options when delivered to clients. >>> >>>BTW, Scott - what is "DHS"? >> >>Sorry, DHCP server >> >>>The usual case - almost the only case today - is that there is a >>>single >>>upstream service provider and a single source of DHCP options to be >>>passed along to the client. In this scenario, there's no need to >>>pass >>>along any information identifying the source of the options. >>> >>>To allow for a multihomed subscriber network, I can imagine adding >>>a tag >>>that would be passed along with the options so the subscriber >>>client can >>>identify the source of each option. But, what would the client do >>>with >>>that information? How would the client interpret it? What is the >>>syntax >>>and semantics of the tagging? >>> >>>Taken a step farther, sourcing information might be required even if >>>there is no intermediate RG and the contained option is not in >>>use. How >>>does a device with multiple interfaces make policy decisions about >>>information received on those multiple interfaces (which is pretty >>>much >>>the question Scott asks about the container option)? >>> >>>- Ralph >> >>Well put. It all comes down to where information is going to be >>merged. The case where a single RG client connected to multiple SP >>servers is essentially already covered by MIF/6man, they just need to >>document it. If the information is merged at the RG server, then the >>RG server should somehow know which interface which DHCP information >>came from. If all of the information is transparently passed to the >>consumer device, then it needs the tags as well. >> >>I don't know how the information could be usefully tagged -- the SP >>server's IP address doesn't sound like a good idea. The WG should >>decide if tagging should be included in the container syntax or added >>later (but documented now as needing study). >> >>I'm CCing MIF in case people there aren't on the ietf list. >> >>Thanks ... Scott >> >>> >>>On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >>> >>>>I have been selected as the General Area Review Team (Gen-ART) >>>>reviewer for this draft (for background on Gen-ART, please see >>>>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>> >>>>Please wait for direction from your document shepherd >>>>or AD before posting a new version of the draft. >>>> >>>>Document: draft-ietf-dhc-container-00 >>>>Reviewer: Scott Brim >>>>Review Date: 7 April 2009 >>>>IESG Telechat date: 14 April 2009 >>>> >>>>Summary: >>>> >>>>This draft is on the right track but has open issues. >>>> >>>>Comments: >>>> >>>>More significant: >>>> >>>> I am concerned about multiple interface scenarios as are being >>>> discussed in MIF and 6MAN, where either the RG is multiply >>>>connected >>>> or the end device is. For a discussion of the sort of problems >>>>that >>>> lead to this concern, see (for example) notes from the MIF BOF at >>>> IETF74. >>>> >>>> - There must be a way to associate options with a particular >>>> upstream DHS they were obtained from, when the container is >>>>passed >>>> to the RG server and perhaps to the end device. This source >>>> information may or may not be in the container itself -- that's >>>>up >>>> to the WG to decide. If it is decided that the source >>>>information >>>> will not be part of the container syntax, at least the fact that >>>> it is necessary should be documented for people who ultimately do >>>> specify how container options are passed. >>>> >>>> - The SP server may have its ideas of how a consumer device should >>>> be configured, but it is not appropriate to say that the "SP >>>> server MUST be able to control which DHCP options are transmitted >>>> to the consumer device". The RG server may need to make >>>>decisions >>>> about information from multiple DHCP servers. Perhaps you could >>>> say that the SP server MUST be able to "provide information" to >>>> the RG server. >>>> >>>>Less significant: >>>> >>>> 5.1 and 5.2 >>>> >>>> Alignment between the v4 and v6 descriptions would be better. The >>>> v4 description has "code" in the diagram and says that "code" is >>>> OPTION_CONTAINER_V4. The v6 description has >>>>"OPTION_CONTAINER_V6" >>>> in the diagram and says that "option-code" is >>>>OPTION_CONTAINER_V6. > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf From rdroms@cisco.com Mon Apr 13 04:08:05 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15EAA3A6D1C; Mon, 13 Apr 2009 04:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzm4e075Ryv4; Mon, 13 Apr 2009 04:08:03 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 231433A6823; Mon, 13 Apr 2009 04:08:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,179,1238976000"; d="scan'208";a="41681894" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2009 11:09:13 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3DB9Dot012167; Mon, 13 Apr 2009 07:09:13 -0400 Received: from bxb-rdroms-8711.cisco.com (bxb-rdroms-8711.cisco.com [10.98.10.82]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3DB9CLQ002281; Mon, 13 Apr 2009 11:09:12 GMT Message-Id: From: Ralph Droms To: Michael StJohns In-Reply-To: <20090411195924.EC3213A6917@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 07:09:12 -0400 References: <20090407182511.GA98039@cisco.com> <20090411100044.GA96599@cisco.com> <20090411195924.EC3213A6917@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6675; t=1239620953; x=1240484953; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20Gen-ART=20review=20of=20draft -ietf-dhc-container-00 |Sender:=20 |To:=20Michael=20StJohns=20; bh=il14ZBG6OwZOfJMCIEzeZxi11infOejM2UQpMSXvvz0=; b=Bs0RrKqLJJT/y20tUopXzQ8XXx/HVDxmuNJiGaK2FzxWJgRVK79WYpRf8r xh/f5n6VWUYYBAQMFM1J7sS6LfunzgWKirgkV/4lab8QUdqXHBJpNNCR7pLl 2qQjjDAirQ; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: mif , ietf@ietf.org, Scott Brim , Black_David@emc.com, dhc WG , gen-art@ietf.org Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 11:08:05 -0000 Mike - Can you give a little more detail? I'm not sure I see how the RFC 3046 options - passed between a relay agent and a server - would interact with the container option. BTW, please feel free to join the conversation at any time. The SF meeting marked the 20th year anniversary of the first dhc WG meeting at IETF 13 in Cocoa Beach. I was looking at the list of attendees ... and you were at that first meeting, so we welcome your input as a charter member. Also, from the minutes of that first dhc WG meeting: We quickly decided to limit the scope of our discussion to "Internet participants" with only a single interface. This decision allowed us to avoid the "host versus gateway" and "multi-homed host" religious wars... Guess we won't be able to duck the issue any more. - Ralph On Apr 11, 2009, at 4:00 PM 4/11/09, Michael StJohns wrote: > Sorry to stick my oar in, but does this or could this interact with > the options specified in RFC3046 in an unexpected way? > > At 01:41 PM 4/11/2009, Ralph Droms wrote: >> Scott - even knowing "which interface which DHCP information came >> from" may not be enough for a device with multiple interfaces. Can >> policies for merging information be written just based on the >> characteristics of the interface - say, 3GPP versus 802.11, or IP >> address of the interface - or does the device need to differentiate >> between Verizon Wireless and Starbucks if I'm away from home? Or >> differentiate between my AT&T femtocell and my home WiFi network? >> >> - Ralph >> >> On Apr 11, 2009, at 6:00 AM 4/11/09, Scott Brim wrote: >> >>> Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >>>> Scott raises an interesting point about identifying the source of >>>> options when delivered to clients. >>>> >>>> BTW, Scott - what is "DHS"? >>> >>> Sorry, DHCP server >>> >>>> The usual case - almost the only case today - is that there is a >>>> single >>>> upstream service provider and a single source of DHCP options to be >>>> passed along to the client. In this scenario, there's no need to >>>> pass >>>> along any information identifying the source of the options. >>>> >>>> To allow for a multihomed subscriber network, I can imagine adding >>>> a tag >>>> that would be passed along with the options so the subscriber >>>> client can >>>> identify the source of each option. But, what would the client do >>>> with >>>> that information? How would the client interpret it? What is the >>>> syntax >>>> and semantics of the tagging? >>>> >>>> Taken a step farther, sourcing information might be required even >>>> if >>>> there is no intermediate RG and the contained option is not in >>>> use. How >>>> does a device with multiple interfaces make policy decisions about >>>> information received on those multiple interfaces (which is pretty >>>> much >>>> the question Scott asks about the container option)? >>>> >>>> - Ralph >>> >>> Well put. It all comes down to where information is going to be >>> merged. The case where a single RG client connected to multiple SP >>> servers is essentially already covered by MIF/6man, they just need >>> to >>> document it. If the information is merged at the RG server, then >>> the >>> RG server should somehow know which interface which DHCP information >>> came from. If all of the information is transparently passed to the >>> consumer device, then it needs the tags as well. >>> >>> I don't know how the information could be usefully tagged -- the SP >>> server's IP address doesn't sound like a good idea. The WG should >>> decide if tagging should be included in the container syntax or >>> added >>> later (but documented now as needing study). >>> >>> I'm CCing MIF in case people there aren't on the ietf list. >>> >>> Thanks ... Scott >>> >>>> >>>> On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >>>> >>>>> I have been selected as the General Area Review Team (Gen-ART) >>>>> reviewer for this draft (for background on Gen-ART, please see >>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>> >>>>> Please wait for direction from your document shepherd >>>>> or AD before posting a new version of the draft. >>>>> >>>>> Document: draft-ietf-dhc-container-00 >>>>> Reviewer: Scott Brim >>>>> Review Date: 7 April 2009 >>>>> IESG Telechat date: 14 April 2009 >>>>> >>>>> Summary: >>>>> >>>>> This draft is on the right track but has open issues. >>>>> >>>>> Comments: >>>>> >>>>> More significant: >>>>> >>>>> I am concerned about multiple interface scenarios as are being >>>>> discussed in MIF and 6MAN, where either the RG is multiply >>>>> connected >>>>> or the end device is. For a discussion of the sort of problems >>>>> that >>>>> lead to this concern, see (for example) notes from the MIF BOF at >>>>> IETF74. >>>>> >>>>> - There must be a way to associate options with a particular >>>>> upstream DHS they were obtained from, when the container is >>>>> passed >>>>> to the RG server and perhaps to the end device. This source >>>>> information may or may not be in the container itself -- that's >>>>> up >>>>> to the WG to decide. If it is decided that the source >>>>> information >>>>> will not be part of the container syntax, at least the fact that >>>>> it is necessary should be documented for people who ultimately do >>>>> specify how container options are passed. >>>>> >>>>> - The SP server may have its ideas of how a consumer device should >>>>> be configured, but it is not appropriate to say that the "SP >>>>> server MUST be able to control which DHCP options are transmitted >>>>> to the consumer device". The RG server may need to make >>>>> decisions >>>>> about information from multiple DHCP servers. Perhaps you could >>>>> say that the SP server MUST be able to "provide information" to >>>>> the RG server. >>>>> >>>>> Less significant: >>>>> >>>>> 5.1 and 5.2 >>>>> >>>>> Alignment between the v4 and v6 descriptions would be better. The >>>>> v4 description has "code" in the diagram and says that "code" is >>>>> OPTION_CONTAINER_V4. The v6 description has >>>>> "OPTION_CONTAINER_V6" >>>>> in the diagram and says that "option-code" is >>>>> OPTION_CONTAINER_V6. >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From rdroms@cisco.com Mon Apr 13 04:25:32 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A943A6915; Mon, 13 Apr 2009 04:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGWe2fGBVxDf; Mon, 13 Apr 2009 04:25:31 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CFA233A6C6F; Mon, 13 Apr 2009 04:25:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,179,1238976000"; d="scan'208";a="41755180" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2009 11:26:34 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3DBQYew016760; Mon, 13 Apr 2009 07:26:34 -0400 Received: from bxb-rdroms-8711.cisco.com (bxb-rdroms-8711.cisco.com [10.98.10.82]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3DBQY3W005557; Mon, 13 Apr 2009 11:26:34 GMT Message-Id: <62D8C3C1-44CB-424E-81F5-AA23B56EBA69@cisco.com> From: Ralph Droms To: Hui Deng In-Reply-To: <1d38a3350904112334s5fc9d40bp269ec389c27f1a38@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 07:26:33 -0400 References: <20090407182511.GA98039@cisco.com> <20090411100044.GA96599@cisco.com> <1d38a3350904112334s5fc9d40bp269ec389c27f1a38@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5857; t=1239621994; x=1240485994; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20Gen-ART=20review=20of=20draft -ietf-dhc-container-00 |Sender:=20 |To:=20Hui=20Deng=20; bh=3IUlYppY27K4z/J2JiIcJ0xcKu6ydEqbmba8v3VO6us=; b=fPyl9vUVxsO16vYOfivJtBDhX8ZLmvp8LXvZonRRq5TLKYjHJaiyTH+t/9 mpW1l1zPhzpY1Yx8Q1X9f1WTL8e1z3cbwK6ulciMOkZtsVieWrnm0CDvjFQR BH5X7MzPXH; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: mif , ietf@ietf.org, gen-art@ietf.org, Black_David@emc.com, dhc WG , Scott Brim Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 11:25:32 -0000 Hui - I think there is an issue for hosts with multiple interfaces triggered by Scott's comments about the container option: even if a host is physically aware that it has multiple interfaces, how does it take the characteristics of the networks behind those interfaces into account when it merges information? For example, would a host process information received from a Starbucks network over its 802.11 interface differently from information received a home network over the 802.11 interface? - Ralph On Apr 12, 2009, at 2:34 AM 4/12/09, Hui Deng wrote: > Hi, Scott, > > Based on the current MIF charter proposal, it consider only host. > http://www.ietf.org/mail-archive/web/mif/current/msg00367.html > I am wondering whether RG is a kind of host? > > Anyhow, this discussion benefit MIF for the future consideration how > to identify the source. > > Many thanks > > -Hui > > 2009/4/11 Scott Brim : >> Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >>> Scott raises an interesting point about identifying the source of >>> options when delivered to clients. >>> >>> BTW, Scott - what is "DHS"? >> >> Sorry, DHCP server >> >>> The usual case - almost the only case today - is that there is a >>> single >>> upstream service provider and a single source of DHCP options to be >>> passed along to the client. In this scenario, there's no need to >>> pass >>> along any information identifying the source of the options. >>> >>> To allow for a multihomed subscriber network, I can imagine adding >>> a tag >>> that would be passed along with the options so the subscriber >>> client can >>> identify the source of each option. But, what would the client do >>> with >>> that information? How would the client interpret it? What is the >>> syntax >>> and semantics of the tagging? >>> >>> Taken a step farther, sourcing information might be required even if >>> there is no intermediate RG and the contained option is not in >>> use. How >>> does a device with multiple interfaces make policy decisions about >>> information received on those multiple interfaces (which is pretty >>> much >>> the question Scott asks about the container option)? >>> >>> - Ralph >> >> Well put. It all comes down to where information is going to be >> merged. The case where a single RG client connected to multiple SP >> servers is essentially already covered by MIF/6man, they just need to >> document it. If the information is merged at the RG server, then the >> RG server should somehow know which interface which DHCP information >> came from. If all of the information is transparently passed to the >> consumer device, then it needs the tags as well. >> >> I don't know how the information could be usefully tagged -- the SP >> server's IP address doesn't sound like a good idea. The WG should >> decide if tagging should be included in the container syntax or added >> later (but documented now as needing study). >> >> I'm CCing MIF in case people there aren't on the ietf list. >> >> Thanks ... Scott >> >>> >>> On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >>> >>>> I have been selected as the General Area Review Team (Gen-ART) >>>> reviewer for this draft (for background on Gen-ART, please see >>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>> >>>> Please wait for direction from your document shepherd >>>> or AD before posting a new version of the draft. >>>> >>>> Document: draft-ietf-dhc-container-00 >>>> Reviewer: Scott Brim >>>> Review Date: 7 April 2009 >>>> IESG Telechat date: 14 April 2009 >>>> >>>> Summary: >>>> >>>> This draft is on the right track but has open issues. >>>> >>>> Comments: >>>> >>>> More significant: >>>> >>>> I am concerned about multiple interface scenarios as are being >>>> discussed in MIF and 6MAN, where either the RG is multiply >>>> connected >>>> or the end device is. For a discussion of the sort of problems >>>> that >>>> lead to this concern, see (for example) notes from the MIF BOF at >>>> IETF74. >>>> >>>> - There must be a way to associate options with a particular >>>> upstream DHS they were obtained from, when the container is >>>> passed >>>> to the RG server and perhaps to the end device. This source >>>> information may or may not be in the container itself -- >>>> that's up >>>> to the WG to decide. If it is decided that the source >>>> information >>>> will not be part of the container syntax, at least the fact >>>> that >>>> it is necessary should be documented for people who >>>> ultimately do >>>> specify how container options are passed. >>>> >>>> - The SP server may have its ideas of how a consumer device >>>> should >>>> be configured, but it is not appropriate to say that the "SP >>>> server MUST be able to control which DHCP options are >>>> transmitted >>>> to the consumer device". The RG server may need to make >>>> decisions >>>> about information from multiple DHCP servers. Perhaps you >>>> could >>>> say that the SP server MUST be able to "provide information" to >>>> the RG server. >>>> >>>> Less significant: >>>> >>>> 5.1 and 5.2 >>>> >>>> Alignment between the v4 and v6 descriptions would be better. >>>> The >>>> v4 description has "code" in the diagram and says that "code" >>>> is >>>> OPTION_CONTAINER_V4. The v6 description has >>>> "OPTION_CONTAINER_V6" >>>> in the diagram and says that "option-code" is >>>> OPTION_CONTAINER_V6. >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> From denghui02@gmail.com Mon Apr 13 08:22:41 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E38C3A6D79; Mon, 13 Apr 2009 08:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3Myec1PdDc4; Mon, 13 Apr 2009 08:22:39 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 68FB93A687F; Mon, 13 Apr 2009 08:22:39 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so2972259ywh.49 for ; Mon, 13 Apr 2009 08:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ow4hX8BgaXBFlGo2JBKrQuWRI9Siv3V1HhRy2AdFodE=; b=i7fB7y+eWkRB0YOMsMAhZSiyXGsaVwgra2ZmXMifQGJH5ZLR4dOUCfGDngE4W4x3wi +5aKKp3TPGuBDTRI5lkqRZlq9VuXSrbT9xPCRr9Rj/Fmkvj35XqmSO1FKWFDZFbh4+xs uZrDh5W3ZfKU0GmPGSWfS9BcoDbnyGTXyNJpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BmPSK0cfXfw316vQliBRAFKHVUep9OH5w4TczuWLLLEaR4yRSYcgH+2i/Y5cvuFBrD ywz6xgD2Ikx51KNtSL256YH5l3ORZwTzDh4t2pSCTYCK/XbEICwfqZAC8tfMUt4+tSLb cbDhL7NJMcTCHJORVPYmduumuM+r8kbP/siG4= MIME-Version: 1.0 Received: by 10.142.51.4 with SMTP id y4mr2655792wfy.303.1239636229564; Mon, 13 Apr 2009 08:23:49 -0700 (PDT) In-Reply-To: <62D8C3C1-44CB-424E-81F5-AA23B56EBA69@cisco.com> References: <20090407182511.GA98039@cisco.com> <20090411100044.GA96599@cisco.com> <1d38a3350904112334s5fc9d40bp269ec389c27f1a38@mail.gmail.com> <62D8C3C1-44CB-424E-81F5-AA23B56EBA69@cisco.com> Date: Mon, 13 Apr 2009 23:23:49 +0800 Message-ID: <1d38a3350904130823u4ee3f79ek79ed670da89913e8@mail.gmail.com> From: Hui Deng To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , ietf@ietf.org, gen-art@ietf.org, Black_David@emc.com, dhc WG , Scott Brim Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 15:22:41 -0000 Hi, Ralph, I agree what you said here, Scott raised the possible issue how to differentiate the source. One instant thinking about the two different 802.11 interface is that the principal source policy selection will not be able to tell the diffference, we could allow high level policy to recommend how to handle it, give a example, we may prioritize some wifi apn policy, and make others as just a category of normal wifi. Anyhow, those thing need to be further studied based on the current practic= e. Thanks for the discussion. -Hui 2009/4/13 Ralph Droms : > Hui - I think there is an issue for hosts with multiple interfaces trigge= red > by Scott's comments about the container option: even if a host is physica= lly > aware that it has multiple interfaces, how does it take the characteristi= cs > of the networks behind those interfaces into account when it merges > information? =A0For example, would a host process information received fr= om a > Starbucks network over its 802.11 interface differently from information > received a home network over the 802.11 interface? > > - Ralph > > On Apr 12, 2009, at 2:34 AM 4/12/09, Hui Deng wrote: > >> Hi, Scott, >> >> Based on the current MIF charter proposal, it consider only host. >> http://www.ietf.org/mail-archive/web/mif/current/msg00367.html >> I am wondering whether RG is a kind of host? >> >> Anyhow, this discussion benefit MIF for the future consideration how >> to identify the source. >> >> Many thanks >> >> -Hui >> >> 2009/4/11 Scott Brim : >>> >>> Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >>>> >>>> Scott raises an interesting point about identifying the source of >>>> options when delivered to clients. >>>> >>>> BTW, Scott - what is "DHS"? >>> >>> Sorry, DHCP server >>> >>>> The usual case - almost the only case today - is that there is a singl= e >>>> upstream service provider and a single source of DHCP options to be >>>> passed along to the client. =A0In this scenario, there's no need to pa= ss >>>> along any information identifying the source of the options. >>>> >>>> To allow for a multihomed subscriber network, I can imagine adding a t= ag >>>> that would be passed along with the options so the subscriber client c= an >>>> identify the source of each option. =A0But, what would the client do w= ith >>>> that information? =A0How would the client interpret it? =A0What is the >>>> syntax >>>> and semantics of the tagging? >>>> >>>> Taken a step farther, sourcing information might be required even if >>>> there is no intermediate RG and the contained option is not in use. = =A0How >>>> does a device with multiple interfaces make policy decisions about >>>> information received on those multiple interfaces (which is pretty muc= h >>>> the question Scott asks about the container option)? >>>> >>>> - Ralph >>> >>> Well put. =A0It all comes down to where information is going to be >>> merged. =A0The case where a single RG client connected to multiple SP >>> servers is essentially already covered by MIF/6man, they just need to >>> document it. =A0If the information is merged at the RG server, then the >>> RG server should somehow know which interface which DHCP information >>> came from. =A0If all of the information is transparently passed to the >>> consumer device, then it needs the tags as well. >>> >>> I don't know how the information could be usefully tagged -- the SP >>> server's IP address doesn't sound like a good idea. =A0The WG should >>> decide if tagging should be included in the container syntax or added >>> later (but documented now as needing study). >>> >>> I'm CCing MIF in case people there aren't on the ietf list. >>> >>> Thanks ... Scott >>> >>>> >>>> On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >>>> >>>>> I have been selected as the General Area Review Team (Gen-ART) >>>>> reviewer for this draft (for background on Gen-ART, please see >>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>> >>>>> Please wait for direction from your document shepherd >>>>> or AD before posting a new version of the draft. >>>>> >>>>> Document: draft-ietf-dhc-container-00 >>>>> Reviewer: Scott Brim >>>>> Review Date: =A0 =A0 =A0 =A0 7 April 2009 >>>>> IESG Telechat date: 14 April 2009 >>>>> >>>>> Summary: >>>>> >>>>> This draft is on the right track but has open issues. >>>>> >>>>> Comments: >>>>> >>>>> More significant: >>>>> >>>>> =A0I am concerned about multiple interface scenarios as are being >>>>> =A0discussed in MIF and 6MAN, where either the RG is multiply connect= ed >>>>> =A0or the end device is. =A0For a discussion of the sort of problems = that >>>>> =A0lead to this concern, see (for example) notes from the MIF BOF at >>>>> =A0IETF74. >>>>> >>>>> =A0- There must be a way to associate options with a particular >>>>> =A0 =A0upstream DHS they were obtained from, when the container is pa= ssed >>>>> =A0 =A0to the RG server and perhaps to the end device. =A0This source >>>>> =A0 =A0information may or may not be in the container itself -- that'= s up >>>>> =A0 =A0to the WG to decide. =A0If it is decided that the source infor= mation >>>>> =A0 =A0will not be part of the container syntax, at least the fact th= at >>>>> =A0 =A0it is necessary should be documented for people who ultimately= do >>>>> =A0 =A0specify how container options are passed. >>>>> >>>>> =A0- The SP server may have its ideas of how a consumer device should >>>>> =A0 =A0be configured, but it is not appropriate to say that the "SP >>>>> =A0 =A0server MUST be able to control which DHCP options are transmit= ted >>>>> =A0 =A0to the consumer device". =A0The RG server may need to make dec= isions >>>>> =A0 =A0about information from multiple DHCP servers. =A0Perhaps you c= ould >>>>> =A0 =A0say that the SP server MUST be able to "provide information" t= o >>>>> =A0 =A0the RG server. >>>>> >>>>> Less significant: >>>>> >>>>> =A05.1 and 5.2 >>>>> >>>>> =A0 =A0Alignment between the v4 and v6 descriptions would be better. = The >>>>> =A0 =A0v4 description has "code" in the diagram and says that "code" = is >>>>> =A0 =A0OPTION_CONTAINER_V4. =A0The v6 description has "OPTION_CONTAIN= ER_V6" >>>>> =A0 =A0in the diagram and says that "option-code" is OPTION_CONTAINER= _V6. >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>> > > From mstjohns@comcast.net Mon Apr 13 10:24:24 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1B8328C11B for ; Mon, 13 Apr 2009 10:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VV4ZZTRl9Wdd for ; Mon, 13 Apr 2009 10:24:23 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 12FE03A69AE for ; Mon, 13 Apr 2009 10:24:22 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA02.westchester.pa.mail.comcast.net with comcast id ez2p1b0050bG4ec525RHHY; Mon, 13 Apr 2009 17:25:17 +0000 Received: from MIKES-LAPTOM.comcast.net ([68.48.0.201]) by OMTA03.westchester.pa.mail.comcast.net with comcast id f5RU1b00K4LCBKY3P5RUjl; Mon, 13 Apr 2009 17:25:28 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Apr 2009 13:25:33 -0400 To: Ralph Droms From: Michael StJohns In-Reply-To: References: <20090407182511.GA98039@cisco.com> <20090411100044.GA96599@cisco.com> <20090411195924.EC3213A6917@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20090413172423.12FE03A69AE@core3.amsl.com> Cc: mif , ietf@ietf.org, Scott Brim , Black_David@emc.com, dhc WG , gen-art@ietf.org Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 17:24:24 -0000 Hi Ralph - Yup.. we've been at this way too long. On the matter at hand: Both of these documents allow a bit of twiddling with what gets sent to the ultimate end client. The DHCP relay agent does this indirectly by signally which branch of the network tree it exist in so the upstream DHCP server can serve addresses (and specific configuration options) to the client from the appropriate address pool. The container document does it by having an autonomous DHCP server in an RG fetch configuration options that can then be supplied to the client. What happens if you get a relay agent which inserts a relay agent option in the RG to SP DHCP query and the SP responds by returning the options related to that relay agent as well as the container related to the RG? Specifically, which options control if they are incompatible with each other? What happens if the RG is implemented using the third version of section 4 and the request passes through both the RG and the relay agent? (In the diagrams, the relay agent is between the RG and the SP DHCP - in a cable modem system it would be the cable modem termination system or CMTS). As I said - not sure this is an issue, but the lack of mention of 3046 seemed problematic. Mike At 07:09 AM 4/13/2009, Ralph Droms wrote: >Mike - Can you give a little more detail? I'm not sure I see how the >RFC 3046 options - passed between a relay agent and a server - would >interact with the container option. > >BTW, please feel free to join the conversation at any time. The SF >meeting marked the 20th year anniversary of the first dhc WG meeting >at IETF 13 in Cocoa Beach. I was looking at the list of attendees ... >and you were at that first meeting, so we welcome your input as a >charter member. > >Also, from the minutes of that first dhc WG meeting: > > We quickly decided to limit the scope of our discussion to "Internet > participants" with only a single interface. This decision allowed us > to avoid the "host versus gateway" and "multi-homed host" religious > wars... > >Guess we won't be able to duck the issue any more. > >- Ralph > >On Apr 11, 2009, at 4:00 PM 4/11/09, Michael StJohns wrote: > >>Sorry to stick my oar in, but does this or could this interact with >>the options specified in RFC3046 in an unexpected way? >> >>At 01:41 PM 4/11/2009, Ralph Droms wrote: >>>Scott - even knowing "which interface which DHCP information came >>>from" may not be enough for a device with multiple interfaces. Can >>>policies for merging information be written just based on the >>>characteristics of the interface - say, 3GPP versus 802.11, or IP >>>address of the interface - or does the device need to differentiate >>>between Verizon Wireless and Starbucks if I'm away from home? Or >>>differentiate between my AT&T femtocell and my home WiFi network? >>> >>>- Ralph >>> >>>On Apr 11, 2009, at 6:00 AM 4/11/09, Scott Brim wrote: >>> >>>>Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >>>>>Scott raises an interesting point about identifying the source of >>>>>options when delivered to clients. >>>>> >>>>>BTW, Scott - what is "DHS"? >>>> >>>>Sorry, DHCP server >>>> >>>>>The usual case - almost the only case today - is that there is a >>>>>single >>>>>upstream service provider and a single source of DHCP options to be >>>>>passed along to the client. In this scenario, there's no need to >>>>>pass >>>>>along any information identifying the source of the options. >>>>> >>>>>To allow for a multihomed subscriber network, I can imagine adding >>>>>a tag >>>>>that would be passed along with the options so the subscriber >>>>>client can >>>>>identify the source of each option. But, what would the client do >>>>>with >>>>>that information? How would the client interpret it? What is the >>>>>syntax >>>>>and semantics of the tagging? >>>>> >>>>>Taken a step farther, sourcing information might be required even >>>>>if >>>>>there is no intermediate RG and the contained option is not in >>>>>use. How >>>>>does a device with multiple interfaces make policy decisions about >>>>>information received on those multiple interfaces (which is pretty >>>>>much >>>>>the question Scott asks about the container option)? >>>>> >>>>>- Ralph >>>> >>>>Well put. It all comes down to where information is going to be >>>>merged. The case where a single RG client connected to multiple SP >>>>servers is essentially already covered by MIF/6man, they just need >>>>to >>>>document it. If the information is merged at the RG server, then >>>>the >>>>RG server should somehow know which interface which DHCP information >>>>came from. If all of the information is transparently passed to the >>>>consumer device, then it needs the tags as well. >>>> >>>>I don't know how the information could be usefully tagged -- the SP >>>>server's IP address doesn't sound like a good idea. The WG should >>>>decide if tagging should be included in the container syntax or >>>>added >>>>later (but documented now as needing study). >>>> >>>>I'm CCing MIF in case people there aren't on the ietf list. >>>> >>>>Thanks ... Scott >>>> >>>>> >>>>>On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >>>>> >>>>>>I have been selected as the General Area Review Team (Gen-ART) >>>>>>reviewer for this draft (for background on Gen-ART, please see >>>>>>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>>> >>>>>>Please wait for direction from your document shepherd >>>>>>or AD before posting a new version of the draft. >>>>>> >>>>>>Document: draft-ietf-dhc-container-00 >>>>>>Reviewer: Scott Brim >>>>>>Review Date: 7 April 2009 >>>>>>IESG Telechat date: 14 April 2009 >>>>>> >>>>>>Summary: >>>>>> >>>>>>This draft is on the right track but has open issues. >>>>>> >>>>>>Comments: >>>>>> >>>>>>More significant: >>>>>> >>>>>>I am concerned about multiple interface scenarios as are being >>>>>>discussed in MIF and 6MAN, where either the RG is multiply >>>>>>connected >>>>>>or the end device is. For a discussion of the sort of problems >>>>>>that >>>>>>lead to this concern, see (for example) notes from the MIF BOF at >>>>>>IETF74. >>>>>> >>>>>>- There must be a way to associate options with a particular >>>>>> upstream DHS they were obtained from, when the container is >>>>>>passed >>>>>> to the RG server and perhaps to the end device. This source >>>>>> information may or may not be in the container itself -- that's >>>>>>up >>>>>> to the WG to decide. If it is decided that the source >>>>>>information >>>>>> will not be part of the container syntax, at least the fact that >>>>>> it is necessary should be documented for people who ultimately do >>>>>> specify how container options are passed. >>>>>> >>>>>>- The SP server may have its ideas of how a consumer device should >>>>>> be configured, but it is not appropriate to say that the "SP >>>>>> server MUST be able to control which DHCP options are transmitted >>>>>> to the consumer device". The RG server may need to make >>>>>>decisions >>>>>> about information from multiple DHCP servers. Perhaps you could >>>>>> say that the SP server MUST be able to "provide information" to >>>>>> the RG server. >>>>>> >>>>>>Less significant: >>>>>> >>>>>>5.1 and 5.2 >>>>>> >>>>>> Alignment between the v4 and v6 descriptions would be better. The >>>>>> v4 description has "code" in the diagram and says that "code" is >>>>>> OPTION_CONTAINER_V4. The v6 description has >>>>>>"OPTION_CONTAINER_V6" >>>>>> in the diagram and says that "option-code" is >>>>>>OPTION_CONTAINER_V6. >>> >>>_______________________________________________ >>>Ietf mailing list >>>Ietf@ietf.org >>>https://www.ietf.org/mailman/listinfo/ietf >> >> >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Apr 13 13:51:13 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE1A73A67D8; Mon, 13 Apr 2009 13:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qR3f8GjEHr3L; Mon, 13 Apr 2009 13:51:12 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7047F3A69F1; Mon, 13 Apr 2009 13:51:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,181,1238976000"; d="scan'208";a="285508987" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 13 Apr 2009 20:52:23 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3DKqMAE015831; Mon, 13 Apr 2009 16:52:22 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3DKqMhU005636; Mon, 13 Apr 2009 20:52:22 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Apr 2009 16:52:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Apr 2009 16:52:21 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Thread-Index: Acm6Ek9W0EosDW0pQ+SnhWf3M9wSxgCZYduw References: <20090407182511.GA98039@cisco.com> From: "Bernie Volz (volz)" To: "Ralph Droms (rdroms)" , "Scott Brim" X-OriginalArrivalTime: 13 Apr 2009 20:52:22.0833 (UTC) FILETIME=[BE682210:01C9BC79] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5560; t=1239655942; x=1240519942; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Gen-ART=20review=20of=20draft -ietf-dhc-container-00 |Sender:=20 |To:=20=22Ralph=20Droms=20(rdroms)=22=20, =0A=20=20=20=20=20=20=20=20=22Scott=20Brim=22=20; bh=D5+76gbmSO5qWJpQKl5MESIxgycWiQUYboJept5lgjc=; b=Y50ZdLFiEZB3hrOPCDn7ZBFKcLcHqJVQXDxY+W8rZJ9rO+pdqlC20FIwIL a+Op5D3sfPMDB2xt9ItHDxeUJ4XP5Pp+uooNlTDmZKLLAveS/H85Dkpj4Nvb vNTnfaGI7M; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: dhc WG , gen-art@ietf.org, Black_David@emc.com, ietf@ietf.org Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 20:51:13 -0000 While this is certainly an interesting point, I don't really see that it is specific to the container option or that the container option adds any new or different issues? I don't see why this would hold up this draft (perhaps it is not holding it up)? Perhaps at most some statement(s) about the issue should be added to the draft. If there was no container option, the RG would have to extract those options it received that it thought where of interest to the client and pass them on when the client requested them. So, whether there is a container option or not does not change anything (it just makes it easier to deliver information the RG for its clients and to potentially deliver different information to the RG's clients from what is given the RG itself). The issue of how a multi-homed device decides to use sources of information is certainly an interesting one, but no different than what has existed for years with multi-homed clients. I guess one choice for those developing multi-interface RGs is to provide configuration for which interface(s) options are to be 'preferred' over others. In the simple case, this could be just a preference value that applies to any information from that interface. In more complex cases, one might envision policy that would indicate a preference on an option-by-option basis, with even the ability to merge data from multiple interfaces (in perference order). Though, this doesn't account for mobile RGs which might be connecting to vastly different services over the same interface(s) depending on where they are located (with the preferences for the interface changing based on the provider). - Bernie=20 -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ralph Droms (rdroms) Sent: Friday, April 10, 2009 3:26 PM To: Scott Brim Cc: dhc WG; gen-art@ietf.org; Black_David@emc.com; ietf@ietf.org Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Scott raises an interesting point about identifying the source of =20 options when delivered to clients. BTW, Scott - what is "DHS"? The usual case - almost the only case today - is that there is a =20 single upstream service provider and a single source of DHCP options =20 to be passed along to the client. In this scenario, there's no need =20 to pass along any information identifying the source of the options. To allow for a multihomed subscriber network, I can imagine adding a =20 tag that would be passed along with the options so the subscriber =20 client can identify the source of each option. But, what would the =20 client do with that information? How would the client interpret it? =20 What is the syntax and semantics of the tagging? Taken a step farther, sourcing information might be required even if =20 there is no intermediate RG and the contained option is not in use. =20 How does a device with multiple interfaces make policy decisions about =20 information received on those multiple interfaces (which is pretty =20 much the question Scott asks about the container option)? - Ralph On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-dhc-container-00 > Reviewer: Scott Brim > Review Date: 7 April 2009 > IESG Telechat date: 14 April 2009 > > Summary: > > This draft is on the right track but has open issues. > > Comments: > > More significant: > > I am concerned about multiple interface scenarios as are being > discussed in MIF and 6MAN, where either the RG is multiply connected > or the end device is. For a discussion of the sort of problems that > lead to this concern, see (for example) notes from the MIF BOF at > IETF74. > > - There must be a way to associate options with a particular > upstream DHS they were obtained from, when the container is passed > to the RG server and perhaps to the end device. This source > information may or may not be in the container itself -- that's up > to the WG to decide. If it is decided that the source information > will not be part of the container syntax, at least the fact that > it is necessary should be documented for people who ultimately do > specify how container options are passed. > > - The SP server may have its ideas of how a consumer device should > be configured, but it is not appropriate to say that the "SP > server MUST be able to control which DHCP options are transmitted > to the consumer device". The RG server may need to make decisions > about information from multiple DHCP servers. Perhaps you could > say that the SP server MUST be able to "provide information" to > the RG server. > > Less significant: > > 5.1 and 5.2 > > Alignment between the v4 and v6 descriptions would be better. The > v4 description has "code" in the diagram and says that "code" is > OPTION_CONTAINER_V4. The v6 description has "OPTION_CONTAINER_V6" > in the diagram and says that "option-code" is OPTION_CONTAINER_V6. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Mon Apr 13 14:10:04 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD98B3A6EA9; Mon, 13 Apr 2009 14:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.873 X-Spam-Level: X-Spam-Status: No, score=-5.873 tagged_above=-999 required=5 tests=[AWL=0.726, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zD1GVbHYhmRR; Mon, 13 Apr 2009 14:10:04 -0700 (PDT) Received: from chip3mo2-old.postini.com (chip3mo2-old.postini.com [64.18.14.205]) by core3.amsl.com (Postfix) with ESMTP id 8BB4B3A6924; Mon, 13 Apr 2009 14:10:03 -0700 (PDT) Received: from source ([64.89.228.229]) by chip3ob64.postini.com ([64.18.6.12]) with SMTP ID DSNKSeOqb06esCJ2CIoONiKCPinT8V8PWXpD@postini.com; Mon, 13 Apr 2009 14:11:15 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 83C731B8409; Mon, 13 Apr 2009 14:11:23 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 13 Apr 2009 14:11:10 -0700 Message-ID: From: Ted Lemon To: Bernie Volz In-Reply-To: <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 14:11:06 -0700 References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: "ietf@ietf.org" , Scott Brim , "Black_David@emc.com" , dhc WG , "Ralph Droms \(rdroms\)" , "gen-art@ietf.org" Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 21:10:04 -0000 How realistic is it anyway that an RG would get different *relevant* options on its different interfaces? This would seem to me to be an administrative error. Of course the broadcast address and subnet mask options might be different, but it doesn't make sense to send the RG, e.g., different name servers for each interface. From root@core3.amsl.com Tue Apr 14 02:00:01 2009 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 317313A69AE; Tue, 14 Apr 2009 02:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090414090001.317313A69AE@core3.amsl.com> Date: Tue, 14 Apr 2009 02:00:01 -0700 (PDT) Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 09:00:01 -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 : DHCPv6 option for network boot Author(s) : T. Huth, et al. Filename : draft-ietf-dhc-dhcpv6-opt-netboot-04.txt Pages : 11 Date : 2009-04-14 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes new options for DHCPv6 which are required for booting a node from the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-netboot-04.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-dhcpv6-opt-netboot-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-14014624.I-D@ietf.org> --NextPart-- From rdroms@cisco.com Tue Apr 14 03:30:41 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7075C3A694D; Tue, 14 Apr 2009 03:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y46tkyhYh6R1; Tue, 14 Apr 2009 03:30:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 691923A6840; Tue, 14 Apr 2009 03:30:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,183,1238976000"; d="scan'208";a="285872501" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2009 10:31:48 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3EAVluG024695; Tue, 14 Apr 2009 03:31:47 -0700 Received: from bxb-rdroms-8711.cisco.com (bxb-rdroms-8711.cisco.com [10.98.10.82]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3EAVklh029798; Tue, 14 Apr 2009 10:31:46 GMT Message-Id: <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> From: Ralph Droms To: Ted Lemon In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 06:31:38 -0400 References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1196; t=1239705107; x=1240569107; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20Gen-ART=20review=20of=20draft -ietf-dhc-container-00 |Sender:=20; bh=IGAwsf3SNwy83bPB70nsnvKL3OSs5bMmOTvMyCmL0VQ=; b=UXtK+asJ4OvpQS7RgyKAOY+w6+CjnTtbEjlveXfr2qKE//pLUrPFzd/m3r 9NwQMRL6G7milp/gFBOCtXyV5jrpr2wMBqKKjfOTOKjoCjlNIzAlw2AQA3z5 0ToW1O1W58; Authentication-Results: sj-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mif , ietf@ietf.org, Scott Brim , Black_David@emc.com, dhc WG , gen-art@ietf.org, Bernie Volz Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 10:30:41 -0000 Ted - I think it's just as likely for the RG to get different information from different interfaces (or different "administrative domains") as it is for a host to get get different information directly. Traffic from the host, which is then forwarded by the RG to one of more than one possible interfaces or routers, might be affected by the configuration information from the "administrative domain" through which the traffic is forwarded. Now, I admit I'm describing a hypothetical and abstract scenario. I don't have a specific example of a situation in which a host might make decisions - either in the stack or in an application or ??? - about outbound traffic based on knowledge of how that traffic would be forwarded by the RG. - Ralph On Apr 13, 2009, at 5:11 PM 4/13/09, Ted Lemon wrote: > How realistic is it anyway that an RG would get different *relevant* > options on its different interfaces? This would seem to me to be > an administrative error. Of course the broadcast address and > subnet mask options might be different, but it doesn't make sense to > send the RG, e.g., different name servers for each interface. > From Ted.Lemon@nominum.com Tue Apr 14 14:47:02 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767533A686A; Tue, 14 Apr 2009 14:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeitxMXUT-fz; Tue, 14 Apr 2009 14:47:01 -0700 (PDT) Received: from chip3og65.obsmtp.com (chip3og65.obsmtp.com [64.18.14.207]) by core3.amsl.com (Postfix) with ESMTP id 9EE683A63D3; Tue, 14 Apr 2009 14:47:00 -0700 (PDT) Received: from source ([64.89.228.229]) by chip3ob65.postini.com ([64.18.6.12]) with SMTP ID DSNKSeUEmT89V9N0u3Me9ytES/hkpS+qEwbH@postini.com; Tue, 14 Apr 2009 14:48:13 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E2C281B83E2; Tue, 14 Apr 2009 14:48:21 -0700 (PDT) Received: from uma.here (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Tue, 14 Apr 2009 14:48:08 -0700 Message-ID: <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> From: Ted Lemon To: Ralph Droms In-Reply-To: <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 14:48:06 -0700 References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: mif , "ietf@ietf.org" , Scott Brim , "Black_David@emc.com" , dhc WG , "gen-art@ietf.org" , Bernie Volz Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 21:47:02 -0000 On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: > Now, I admit I'm describing a hypothetical and abstract scenario. I > don't have a specific example of a situation in which a host might > make decisions - either in the stack or in an application or ??? - > about outbound traffic based on knowledge of how that traffic would be > forwarded by the RG. That's right. But I think it's not an accident that this is a hypothetical scenario. In reality, a scenario like this has been likely ever since wireless and wired network interfaces became standard on laptops. And yet we don't have any real-life examples of problems that this has caused, which need solving. To me, that seems like an indication that this is not a real operational problem. That is, that the answer "if two DHCP servers send the same client conflicting information on two different interfaces, that is a misconfiguration, and should be solved by correcting the misconfiguration" is, in practice, the correct answer. If it were not, we would be hearing about concrete, real-world scenarios of the type you describe, not about hypothetical ones. I don't mean to minimize this issue - if in fact there is some future real-world scenario where this would be a serious problem, it would be good if we could anticipate it. It might be profitable to consider analogies. For instance, right now I have IPv6 set up at home. Because IPv6 isn't deployed at all in Tucson, the way I have this working is by tunneling. Since there are two tunnel brokers offering service for people like me, and I am a bit adventurous, I have two tunnels. Right now, every IPv6 packet I ever transmit goes out one of those tunnels, with the exception of packets destined for a specific net, for which I have defined a static route. First of all, this scenario works just fine. Both tunnels are configured as a default route - it just happens that Linux's route selection process always chooses the first one. This algorithm would work poorly if one interface were preferable to the other, but since both are equivalent it's not a problem. Second, though, why do I have a default route configured? It's because I'm talking to a node on that network that will only answer if I use the source address of one of the tunnels; and will ignore any packets I send it with the other source address. So in the case where there was a problem, I manually configured a workaround. How could we automatically solve this problem? Simple: any time we are initiating communication with a device on the network, and do not know that the communication is going to work, we simultaneously start the communication in every plausible way. So suppose that there are two AAAA records corresponding to the machine I want to talk to, and I have two global IP addresses. I'm going to send four syn packets. The first syn-ack I get back is the one I'm actually going to use - I'll send RST packets to the other three. This is analogous to the solution Stuart Cheshire described a couple of IETFs ago to the problem of IPv6 causing connectivity problems instead of expanding connectivity opportunities - you can't prefer one solution over the other, because you have no basis for doing so, so you have to try all possible solutions and choose the one that works best. My only extension, if it is one, is that I've added the source address to the matrix - I'm not sure Stuart mentioned that. Now, how does this extend when we go to DHCP? Suppose I have DNS resolver configurations from two DHCP servers. I try both in parallel. I can winnow it down a bit: since I received the DNS server information from one DHCP server on one interface, and the DNS server information from the other DHCP server on a different interface, I only have to try to query the DNS server using the source addresses of the interface on which that DNS server's configuration information was received. But how do I do that if the device that has two interfaces is not the device originating the query, as is the case with the container option? I think the answer is that I can't. There is no heuristic that I can define that will always make the right choice, because the device receiving the container options has to make the choice for the client. In DHCPv6, we could at least give the client a hint about what to do as follows: Suppose that I am dual-homed. I ask for, and get, a container option on both outward-facing interfaces. I also wind up configuring one or more prefixes as a result of my communication with the DHCPv6 server on these two interfaces. I wind up advertising prefixes to the client based on the answers that I get on both outward-facing interfaces, so for example if I get a single prefix delegation from each DHCPv6 server, I will advertise two prefixes to the client. So when the client asks for, and gets, IA_ADDR configurations for both prefixes, I include the container option information from each DHCPv6 server in the IA_ADDR option for the prefix provided by that DHCPv6 server. Now the client has enough information to make a choice - it can use the source address for the prefix from a DHCP server to communicate with the DNS servers provided by that DHCP server. But this requires a great deal of complexity on the client, and on the server. Is this complexity that we want? And we haven't even talked about the case where either due to cost considerations, or due to speed considerations, one interface is preferable to the other. How would we communicate that? How would we configure that? Supposing that one prefix is more expensive than another, does the client then not try the expensive prefix until it's timed out on the cheap prefix? What does that look like to the end-user? Does it fail gracefully? So I think it's an interesting problem space. And actually I think that you could come up with heuristics that would work most of the time, potentially at the cost of increased load on name servers, and increased network usage, and the occasional $1000 cellular data bill. But to come up with heuristics that will work the right way every time, I think that is very difficult. From volz@cisco.com Wed Apr 15 07:09:53 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EB4328C1D2; Wed, 15 Apr 2009 07:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56yZd9eGPwMv; Wed, 15 Apr 2009 07:09:51 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5182E3A69FC; Wed, 15 Apr 2009 07:09:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,192,1238976000"; d="scan'208";a="41895102" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Apr 2009 14:11:03 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3FEB39j025007; Wed, 15 Apr 2009 10:11:03 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FEB3WS024895; Wed, 15 Apr 2009 14:11:03 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 10:11:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Apr 2009 10:11:00 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB210C28A918@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FCD0@XCH42YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Thread-Index: Acm9bS0eCLBGto29TXqPRM/5XXc1WAAYCP/wAAErE0A= References: <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> <777025D7F9E074449F3DAEB73C25690205F0FCD0@XCH42YKF.rim.net> From: "Bernie Volz (volz)" To: "Giyeong Son" , "Ted Lemon" , "Ralph Droms (rdroms)" X-OriginalArrivalTime: 15 Apr 2009 14:11:03.0152 (UTC) FILETIME=[029FE700:01C9BDD4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10434; t=1239804663; x=1240668663; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[mif]=20[dhcwg]=20Gen-ART=20review=20of =20draft-ietf-dhc-container-00 |Sender:=20 |To:=20=22Giyeong=20Son=22=20,=20=22Ted=20Lem on=22=20,=0A=20=20=20=20=20=20=20=20= 22Ralph=20Droms=20(rdroms)=22=20; bh=Xp15jXs99rM8zUPSClk/7qwKagM2w8zZO2MhQtHW08U=; b=EzQK8w8JiSHz1HJQ45ivkZoi2/NvUyaBCg9yYBZLRfiaN/zEzQ+mTWDeEh wQNGlW4aIuWenpLN8pu3HhZPNw6f5AH32dHWBVnlKBBK2hlPrYAyQYXksb6Z 9Tf6MAM73K; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: dhc WG , gen-art@ietf.org, mif , ietf@ietf.org, Black_David@emc.com Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:09:53 -0000 I think there are two separate, but related, issues: One is the multiple interfaces issue on a host. The other is the multiple interfaces issue on a RG (router/gateway or routing gateway). The host behind the RG knows nothing of multiple interfaces -- except in IPv6 it may see multiple prefixes and be assigned multiple addresses. For the host case, the host "knows" it has multiple interfaces and could do things specific to those interfaces. The issue for the RG is how does it present information it obtained from multiple sources (ie, different upstream DHCP servers) to the host as the host only believes there is ONE interface with multiple prefixes/addresses and a single set of configuration data. (And in DHCPv6 we're supposed to be using globally unique addresses and no NATing so the decisions can't be made at the RG as would be possible in DHCPv4 -- since then the RG could chose the address it uses for communicatio with the outside world.) I again don't see how the container option really changes anything -- as it just allows the RG to be told what to potentially pass on its clients (rather than having to pass on information it itself is using). How realistic is that most RGs with multiple interface will connect to DIFFERENT service providers? And, in the case where they do, this likely means someone (the owner of the RG) has to make some decisions -- requiring appropriate configuration. - Bernie=20 -----Original Message----- From: Giyeong Son [mailto:gson@rim.com]=20 Sent: Wednesday, April 15, 2009 9:53 AM To: Ted Lemon; Ralph Droms (rdroms) Cc: mif; ietf@ietf.org; Black_David@emc.com; dhc WG; gen-art@ietf.org; Bernie Volz (volz) Subject: RE: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 I think Ted pointed out very interesting but crucial problems if I understood correctly. So, I'd like to confirm what Ted indicated and emphasized: 1. How to dynamically/automatically/efficiently enable and manage multiple active interfaces on a host? 2. How to utilize multiple active interfaces on a host? 2. What are the efficient (or cost-effective) routing decision policy? Is it least cost routing policy? Or other? If it is least cost routing policy, what are the costs? Are they "money" to use the connection (e.g. WiFi vs. cellular), "time" to spend for the transmission, "reliability" of the transmission, etc? If those are what Ted indicated, I am also interested in asking if the above things are in scope of MIF. Based on my experience in terms of simultaneous use of multiple interfaces, the aboves are the most critical and interesting issues in practice in order to utilize the network environment of simultaneous use of multiple interfaces reliably and efficiently. =20 Giyeong =20 -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Ted Lemon Sent: April 14, 2009 5:48 PM To: Ralph Droms Cc: mif; ietf@ietf.org; Black_David@emc.com; dhc WG; gen-art@ietf.org; Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: > Now, I admit I'm describing a hypothetical and abstract scenario. I=20 > don't have a specific example of a situation in which a host might=20 > make decisions - either in the stack or in an application or ??? -=20 > about outbound traffic based on knowledge of how that traffic would be > forwarded by the RG. That's right. But I think it's not an accident that this is a =20 hypothetical scenario. In reality, a scenario like this has been =20 likely ever since wireless and wired network interfaces became =20 standard on laptops. And yet we don't have any real-life examples of =20 problems that this has caused, which need solving. To me, that seems =20 like an indication that this is not a real operational problem. That =20 is, that the answer "if two DHCP servers send the same client conflicting information on two different interfaces, that is a misconfiguration, and should be solved by correcting the misconfiguration" is, in practice, the correct answer. If it were not, we would be hearing about concrete, real-world scenarios of the type you describe, not about hypothetical ones. I don't mean to minimize this issue - if in fact there is some future real-world scenario where this would be a serious problem, it would be =20 good if we could anticipate it. It might be profitable to consider =20 analogies. For instance, right now I have IPv6 set up at home. Because IPv6 =20 isn't deployed at all in Tucson, the way I have this working is by =20 tunneling. Since there are two tunnel brokers offering service for =20 people like me, and I am a bit adventurous, I have two tunnels. =20 Right now, every IPv6 packet I ever transmit goes out one of those tunnels, with the exception of packets destined for a specific net, for which I have defined a static route. First of all, this scenario works just fine. Both tunnels are =20 configured as a default route - it just happens that Linux's route =20 selection process always chooses the first one. This algorithm would =20 work poorly if one interface were preferable to the other, but since both are equivalent it's not a problem. Second, though, why do I have a default route configured? It's =20 because I'm talking to a node on that network that will only answer if I use the source address of one of the tunnels; and will ignore any =20 packets I send it with the other source address. So in the case =20 where there was a problem, I manually configured a workaround. How could we automatically solve this problem? Simple: any time we =20 are initiating communication with a device on the network, and do not know that the communication is going to work, we simultaneously start =20 the communication in every plausible way. So suppose that there are =20 two AAAA records corresponding to the machine I want to talk to, and I =20 have two global IP addresses. I'm going to send four syn packets. =20 The first syn-ack I get back is the one I'm actually going to use - I'll send RST packets to the other three. This is analogous to the solution Stuart Cheshire described a couple of IETFs ago to the problem of IPv6 causing connectivity problems instead of expanding connectivity opportunities - you can't prefer one solution over the other, because you have no basis for doing so, so you have to try all possible solutions and choose the one that works =20 best. My only extension, if it is one, is that I've added the source =20 address to the matrix - I'm not sure Stuart mentioned that. Now, how does this extend when we go to DHCP? Suppose I have DNS =20 resolver configurations from two DHCP servers. I try both in =20 parallel. I can winnow it down a bit: since I received the DNS =20 server information from one DHCP server on one interface, and the DNS server information from the other DHCP server on a different interface, I only have to try to query the DNS server using the source addresses of the interface on which that DNS server's configuration information was received. But how do I do that if the device that has two interfaces is not the device originating the query, as is the case with the container =20 option? I think the answer is that I can't. There is no heuristic =20 that I can define that will always make the right choice, because the device receiving the container options has to make the choice for the client. In DHCPv6, we could at least give the client a hint about what to do as follows: Suppose that I am dual-homed. I ask for, and get, a container option =20 on both outward-facing interfaces. I also wind up configuring one or =20 more prefixes as a result of my communication with the DHCPv6 server =20 on these two interfaces. I wind up advertising prefixes to the =20 client based on the answers that I get on both outward-facing interfaces, so for example if I get a single prefix delegation from =20 each DHCPv6 server, I will advertise two prefixes to the client. So =20 when the client asks for, and gets, IA_ADDR configurations for both prefixes, I include the container option information from each DHCPv6 server in the IA_ADDR option for the prefix provided by that DHCPv6 =20 server. Now the client has enough information to make a choice - it =20 can use the source address for the prefix from a DHCP server to communicate with the DNS servers provided by that DHCP server. But this requires a great deal of complexity on the client, and on the =20 server. Is this complexity that we want? And we haven't even =20 talked about the case where either due to cost considerations, or due =20 to speed considerations, one interface is preferable to the other. =20 How would we communicate that? How would we configure that? =20 Supposing that one prefix is more expensive than another, does the client then not try the expensive prefix until it's timed out on the =20 cheap prefix? What does that look like to the end-user? Does it =20 fail gracefully? So I think it's an interesting problem space. And actually I think =20 that you could come up with heuristics that would work most of the time, potentially at the cost of increased load on name servers, and increased network usage, and the occasional $1000 cellular data =20 bill. But to come up with heuristics that will work the right way =20 every time, I think that is very difficult. _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. From Ted.Lemon@nominum.com Wed Apr 15 12:47:06 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0DE728C1E9; Wed, 15 Apr 2009 12:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsZGqwPsrGlh; Wed, 15 Apr 2009 12:47:06 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 6C3B93A6F0D; Wed, 15 Apr 2009 12:47:02 -0700 (PDT) Received: from source ([64.89.228.229]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSeY5/dp35BeGGm7z0AMeAUJEsJmA+Lmb@postini.com; Wed, 15 Apr 2009 12:48:17 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 13B5F1B83D0; Wed, 15 Apr 2009 12:48:26 -0700 (PDT) Received: from uma.here (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Wed, 15 Apr 2009 12:48:13 -0700 Message-ID: <9CA784CF-1F7E-41FD-81F5-6FCA4AC75926@nominum.com> From: Ted Lemon To: Bernie Volz In-Reply-To: <8E296595B6471A4689555D5D725EBB210C28A918@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 12:48:11 -0700 References: <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> <777025D7F9E074449F3DAEB73C25690205F0FCD0@XCH42YKF.rim.net> <8E296595B6471A4689555D5D725EBB210C28A918@xmb-rtp-20a.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: mif , "ietf@ietf.org" , Giyeong Son , "gen-art@ietf.org" , "Ralph Droms \(rdroms\)" , dhc WG , "Black_David@emc.com" Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 19:47:07 -0000 On Apr 15, 2009, at 7:11 AM, Bernie Volz (volz) wrote: > How realistic is that most RGs with multiple interface will connect to > DIFFERENT service providers? And, in the case where they do, this > likely > means someone (the owner of the RG) has to make some decisions -- > requiring appropriate configuration. (Apologies in advance for being so long-winded - I think the conclusion I reached at the bottom is interesting, and I didn't realize I was going to reach it until I walked through the line of reasoning I'm long-windedly including here, so I feel like it's worth sharing that line of reasoning in case it helps someone else to get to the same conclusion.) The only scenario that springs to mind for me is something like the Kyocera cellular data gateway, only with a WiFi outward-facing port as well. It might connect opportunistically to open WiFi networks and also roam to 3G networks that cost more or less. The primary problem is, how do we figure out which outgoing route to prefer? Obviously we want to use the cheap connection; how do we know it's cheap? It may be that the primary cellular data network is free, whereas roaming is not, and we would have to know that somehow. But the secondary problem is the killer: we're advertising prefixes. The routing decision is really made by the client, when it chooses the source address. Even if the gateway always routes the packet out the cheap port, it's going to come back on the port corresponding to the prefix the client chose. And you probably can't do that because there's probably egress filtering on the cheap prefix anyway. Bear in mind that I'm using the routing scenario as an *analogy* for what to do with the container option. I'm not a routing expert, and I'm not proposing new routing protocols to solve this problem. What I *am* saying is that in this analogy the client has to decide, and it's crucial that the client make a good decision here. And I think the analogy applies perfectly to the container option. So if we want to solve this problem, we have to solve it in such a way that the *client* has enough information to make a good decision, even though it's the RG that's actually *getting* the container options. I should say that in IPv4, the question is moot, because there's no way to even give the client an opportunity to make this decision. And to circle back around to my original point, I'd just like to point out that the scenario I just came up with is brutally contrived. Nobody actually makes devices like the Kyocera cellular data gateway that *also* have a second outward-facing WiFi interface, and I think there's a good reason nobody does - it's not a good idea. So although I was able to contrive a scenario where we have a real problem that needs to be solved, I don't think that scenario would happen in real life. I think in real life Bernie's scenario is the right model. You have a static gateway, set up to be multihomed by someone who knows what they are doing. They manually configure it as to what decision it should make regarding information it gets from multiple DHCP servers. So to me, the interesting problem is really how that RG handles the vicissitudes of daily life for a router - links, which are expected to be persistent, going up and down, and what to do with the container options received on those links when they go up and down. From swb@employees.org Wed Apr 15 13:51:08 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A503A6867; Wed, 15 Apr 2009 13:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyPTB5zdclSS; Wed, 15 Apr 2009 13:51:07 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id DC83A3A67B7; Wed, 15 Apr 2009 13:50:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,194,1238976000"; d="scan'208";a="153701387" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2009 20:51:57 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3FKpve9008472; Wed, 15 Apr 2009 13:51:57 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FKpfwm012313; Wed, 15 Apr 2009 20:51:57 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 16:51:52 -0400 Received: from cisco.com ([10.86.248.228]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 16:51:52 -0400 Date: Wed, 15 Apr 2009 16:51:50 -0400 From: Scott Brim To: Ted Lemon Message-ID: <20090415205150.GN44356@cisco.com> Mail-Followup-To: Scott Brim , Ted Lemon , Ralph Droms , Bernie Volz , dhc WG , "gen-art@ietf.org" , "Black_David@emc.com" , "ietf@ietf.org" , mif References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 15 Apr 2009 20:51:52.0137 (UTC) FILETIME=[00EFCB90:01C9BE0C] Authentication-Results: sj-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: mif , "ietf@ietf.org" , "gen-art@ietf.org" , Ralph Droms , dhc WG , "Black_David@emc.com" , Bernie Volz Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 20:51:08 -0000 Excerpts from Ted Lemon on Tue, Apr 14, 2009 02:48:06PM -0700: > I don't mean to minimize this issue - if in fact there is some > future real-world scenario where this would be a serious problem, > it would be good if we could anticipate it. I'm just saying the WG should make an explicit decision one way or another: - decide the draft needs no change - document source info as TBD and outside of the container syntax or - document source info as part of container syntax Scott From volz@cisco.com Wed Apr 15 14:11:40 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283873A6C43; Wed, 15 Apr 2009 14:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwpinzHgZxZt; Wed, 15 Apr 2009 14:11:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2368D3A6C3B; Wed, 15 Apr 2009 14:11:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,194,1238976000"; d="scan'208";a="153708543" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2009 21:12:51 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3FLCpnR031363; Wed, 15 Apr 2009 17:12:51 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3FLCoCs007542; Wed, 15 Apr 2009 21:12:50 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 17:12:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Apr 2009 17:12:50 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB210C3EC565@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <20090415205150.GN44356@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Thread-Index: Acm+DAFTJmdAwnNyQiyILfqtAqNwGgAAoIeg References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> <20090415205150.GN44356@cisco.com> From: "Bernie Volz (volz)" To: "Scott Brim" , "Ted Lemon" X-OriginalArrivalTime: 15 Apr 2009 21:12:50.0787 (UTC) FILETIME=[EF268B30:01C9BE0E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1116; t=1239829971; x=1240693971; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Gen-ART=20review=20of=20draft -ietf-dhc-container-00 |Sender:=20 |To:=20=22Scott=20Brim=22=20,=20=22Ted=2 0Lemon=22=20; bh=Wlr6G1bisiz65Qkxiw1v2HaHLPrnXpWDHqjXtgGPXXM=; b=DeH6apv3r4GwXbdfKEJPtLW7y4MACngDhplmofWHWZnhDQAQoQd8iMFe6t f4Btp9yS1A4+NmM3U9JpchG+ZY7tKALsKw16/Bed+FuIp0cOMtvo+13EDj99 sBdH9t76sk; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: mif , ietf@ietf.org, gen-art@ietf.org, "Ralph Droms \(rdroms\)" , dhc WG , Black_David@emc.com Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 21:11:40 -0000 My "vote" would be no change. But, I'd be OK if Ralph wanted to state it is TBD and outside the scope of this document and perhaps indicate that it is an issue whether the RG gets options to pass on from either the container option or from those supplied to the RG. - Bernie=20 -----Original Message----- From: Scott Brim [mailto:swb@employees.org]=20 Sent: Wednesday, April 15, 2009 4:52 PM To: Ted Lemon Cc: Ralph Droms (rdroms); Bernie Volz (volz); dhc WG; gen-art@ietf.org; Black_David@emc.com; ietf@ietf.org; mif Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Excerpts from Ted Lemon on Tue, Apr 14, 2009 02:48:06PM -0700: > I don't mean to minimize this issue - if in fact there is some > future real-world scenario where this would be a serious problem, > it would be good if we could anticipate it. =20 I'm just saying the WG should make an explicit decision one way or another: - decide the draft needs no change - document source info as TBD and outside of the container syntax or - document source info as part of container syntax Scott From Ted.Lemon@nominum.com Wed Apr 15 16:24:24 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340F53A6A70; Wed, 15 Apr 2009 16:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jS-JrDZM81X; Wed, 15 Apr 2009 16:24:23 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 5BFCF3A6965; Wed, 15 Apr 2009 16:24:23 -0700 (PDT) Received: from source ([64.89.228.229]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSeZs54EG/xU6mREfeCRvwtqZ3Yd88B+n@postini.com; Wed, 15 Apr 2009 16:25:36 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 644B01B83D0; Wed, 15 Apr 2009 16:25:40 -0700 (PDT) Received: from uma.here (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Wed, 15 Apr 2009 16:25:27 -0700 Message-ID: <3750E438-1F0A-4E0B-B4A6-4AE3FDE22240@nominum.com> From: Ted Lemon To: Bernie Volz In-Reply-To: <8E296595B6471A4689555D5D725EBB210C3EC565@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 16:25:23 -0700 References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> <20090415205150.GN44356@cisco.com> <8E296595B6471A4689555D5D725EBB210C3EC565@xmb-rtp-20a.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: mif , "ietf@ietf.org" , Scott Brim , "Black_David@emc.com" , dhc WG , "Ralph Droms \(rdroms\)" , "gen-art@ietf.org" Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 23:24:24 -0000 On Apr 15, 2009, at 2:12 PM, Bernie Volz (volz) wrote: > My "vote" would be no change. But, I'd be OK if Ralph wanted to > state it > is TBD and outside the scope of this document and perhaps indicate > that > it is an issue whether the RG gets options to pass on from either the > container option or from those supplied to the RG. Me too. I think it's an interesting topic for future consideration, but out of scope for the present work, and also very much not an emergency requiring us to expand the scope. From rdroms@cisco.com Thu Apr 16 04:49:03 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4653A6C3F; Thu, 16 Apr 2009 04:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IBKmpvqGnRa; Thu, 16 Apr 2009 04:49:02 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 454C03A679C; Thu, 16 Apr 2009 04:49:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,198,1238976000"; d="scan'208";a="155376749" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 16 Apr 2009 11:50:13 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3GBoDBR014751; Thu, 16 Apr 2009 04:50:13 -0700 Received: from sjc-vpnasa1-74.cisco.com (sjc-vpnasa1-74.cisco.com [10.21.104.74]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3GBoB5L009281; Thu, 16 Apr 2009 11:50:12 GMT Message-Id: From: Ralph Droms To: dhc WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 07:39:44 -0400 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=522; t=1239882613; x=1240746613; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20New=20dhc=20WG=20co-chair |Sender:=20; bh=p/Jov27Pp7lNErO4o4dfjDQGZdmlMTBO+1SKt/duvOc=; b=lsjUvdzIMh/Hn4gSiFkvBkT+QD1IGrUcE9u3WS1ydLRRAPKd5d7gsE6kMA 0V+bq5tSLRsbBI9gmrxx9h7Ea1w6ywuPbI90nVlPIFXlAE8b0GmNIhwVPxs1 nXbXKeYNf+; Authentication-Results: sj-dkim-3; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: The IESG Subject: [dhcwg] New dhc WG co-chair X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 11:49:03 -0000 I am pleased to announce that Ted Lemon has agreed to serve as dhc WG co-chair. Ted has been an active participant and contributor to the WG for many years, and brings broad understanding of IP, network operation and device configuration along with in-depth implementation, deployment and operational experience with DHCP to this job. Thanks, Ted, for volunteering and accepting this position. I'll speak for Jari and the WG in saying that we're all looking forward to working with you. - Ralph From gson@rim.com Tue Apr 14 10:37:09 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADEB93A6872; Tue, 14 Apr 2009 10:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CanWgHxfCCD; Tue, 14 Apr 2009 10:37:08 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 1B5633A6840; Tue, 14 Apr 2009 10:37:07 -0700 (PDT) Received: from mhs04ykf.rim.net (unknown [127.0.0.1]) by mhs04ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 4EC835C516; Tue, 14 Apr 2009 13:38:18 -0400 (EDT) X-AuditID: 0a666446-ac193bb000007e46-01-49e4ca0ac55f Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs04ykf.rim.net (Symantec Mail Security) with ESMTP id 070035C4FF; Tue, 14 Apr 2009 13:38:18 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Apr 2009 13:38:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Tue, 14 Apr 2009 13:38:17 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FCC3@XCH42YKF.rim.net> In-Reply-To: <1d38a3350904130823u4ee3f79ek79ed670da89913e8@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Thread-Index: Acm8S/RJc3ZG3zD1TBai0wxN3UuBJAA1K4Ig From: "Giyeong Son" To: "Hui Deng" , "Ralph Droms" X-OriginalArrivalTime: 14 Apr 2009 17:38:17.0855 (UTC) FILETIME=[CBDF40F0:01C9BD27] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Thu, 16 Apr 2009 09:29:32 -0700 Cc: dhc WG , gen-art@ietf.org, mif , ietf@ietf.org, Black_David@emc.com Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 17:37:09 -0000 I agree on Hui's and Ralpha's thoughts. There may be a necessary or worthy study that identifies and classifies what= kind of information or network characteristics of/from the interfaces are n= ecessary and helpful in order to judge active and valid routable interfaces= for the destination (I am not sure the meaning and scope of "routable" with= a destination in terms of MIF though) and determine an efficient/best one a= mong them for the destination endpoint for the moment. Giyeong -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui De= ng Sent: April 13, 2009 11:24 AM To: Ralph Droms Cc: mif; ietf@ietf.org; gen-art@ietf.org; Black_David@emc.com; dhc WG Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Hi, Ralph, I agree what you said here, Scott raised the possible issue how to different= iate the source. One instant thinking about the two different 802.11 interface is that the pr= incipal source policy selection will not be able to tell the diffference, we= could allow high level policy to recommend how to handle it, give a example= , we may prioritize some wifi apn policy, and make others as just a category= of normal wifi. Anyhow, those thing need to be further studied based on the current practice= . Thanks for the discussion. -Hui 2009/4/13 Ralph Droms : > Hui - I think there is an issue for hosts with multiple interfaces > triggered by Scott's comments about the container option: even if a > host is physically aware that it has multiple interfaces, how does it > take the characteristics of the networks behind those interfaces into > account when it merges information? =A0For example, would a host process > information received from a Starbucks network over its 802.11 > interface differently from information received a home network over the 80= 2.11 interface? > > - Ralph > > On Apr 12, 2009, at 2:34 AM 4/12/09, Hui Deng wrote: > >> Hi, Scott, >> >> Based on the current MIF charter proposal, it consider only host. >> http://www.ietf.org/mail-archive/web/mif/current/msg00367.html >> I am wondering whether RG is a kind of host? >> >> Anyhow, this discussion benefit MIF for the future consideration how >> to identify the source. >> >> Many thanks >> >> -Hui >> >> 2009/4/11 Scott Brim : >>> >>> Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >>>> >>>> Scott raises an interesting point about identifying the source of >>>> options when delivered to clients. >>>> >>>> BTW, Scott - what is "DHS"? >>> >>> Sorry, DHCP server >>> >>>> The usual case - almost the only case today - is that there is a >>>> single upstream service provider and a single source of DHCP >>>> options to be passed along to the client. =A0In this scenario, >>>> there's no need to pass along any information identifying the source of= the options. >>>> >>>> To allow for a multihomed subscriber network, I can imagine adding >>>> a tag that would be passed along with the options so the subscriber >>>> client can identify the source of each option. =A0But, what would the >>>> client do with that information? =A0How would the client interpret >>>> it? =A0What is the syntax and semantics of the tagging? >>>> >>>> Taken a step farther, sourcing information might be required even >>>> if there is no intermediate RG and the contained option is not in >>>> use. =A0How does a device with multiple interfaces make policy >>>> decisions about information received on those multiple interfaces >>>> (which is pretty much the question Scott asks about the container optio= n)? >>>> >>>> - Ralph >>> >>> Well put. =A0It all comes down to where information is going to be >>> merged. =A0The case where a single RG client connected to multiple SP >>> servers is essentially already covered by MIF/6man, they just need >>> to document it. =A0If the information is merged at the RG server, then >>> the RG server should somehow know which interface which DHCP >>> information came from. =A0If all of the information is transparently >>> passed to the consumer device, then it needs the tags as well. >>> >>> I don't know how the information could be usefully tagged -- the SP >>> server's IP address doesn't sound like a good idea. =A0The WG should >>> decide if tagging should be included in the container syntax or >>> added later (but documented now as needing study). >>> >>> I'm CCing MIF in case people there aren't on the ietf list. >>> >>> Thanks ... Scott >>> >>>> >>>> On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >>>> >>>>> I have been selected as the General Area Review Team (Gen-ART) >>>>> reviewer for this draft (for background on Gen-ART, please see >>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>> >>>>> Please wait for direction from your document shepherd or AD before >>>>> posting a new version of the draft. >>>>> >>>>> Document: draft-ietf-dhc-container-00 >>>>> Reviewer: Scott Brim >>>>> Review Date: =A0 =A0 =A0 =A0 7 April 2009 >>>>> IESG Telechat date: 14 April 2009 >>>>> >>>>> Summary: >>>>> >>>>> This draft is on the right track but has open issues. >>>>> >>>>> Comments: >>>>> >>>>> More significant: >>>>> >>>>> =A0I am concerned about multiple interface scenarios as are being >>>>> =A0discussed in MIF and 6MAN, where either the RG is multiply >>>>> connected >>>>> =A0or the end device is. =A0For a discussion of the sort of problems >>>>> that >>>>> =A0lead to this concern, see (for example) notes from the MIF BOF at >>>>> =A0IETF74. >>>>> >>>>> =A0- There must be a way to associate options with a particular >>>>> =A0 =A0upstream DHS they were obtained from, when the container is >>>>> passed >>>>> =A0 =A0to the RG server and perhaps to the end device. =A0This source >>>>> =A0 =A0information may or may not be in the container itself -- that's= >>>>> up >>>>> =A0 =A0to the WG to decide. =A0If it is decided that the source >>>>> information >>>>> =A0 =A0will not be part of the container syntax, at least the fact >>>>> that >>>>> =A0 =A0it is necessary should be documented for people who ultimately= >>>>> do >>>>> =A0 =A0specify how container options are passed. >>>>> >>>>> =A0- The SP server may have its ideas of how a consumer device >>>>> should >>>>> =A0 =A0be configured, but it is not appropriate to say that the "SP >>>>> =A0 =A0server MUST be able to control which DHCP options are >>>>> transmitted >>>>> =A0 =A0to the consumer device". =A0The RG server may need to make >>>>> decisions >>>>> =A0 =A0about information from multiple DHCP servers. =A0Perhaps you >>>>> could >>>>> =A0 =A0say that the SP server MUST be able to "provide information" to >>>>> =A0 =A0the RG server. >>>>> >>>>> Less significant: >>>>> >>>>> =A05.1 and 5.2 >>>>> >>>>> =A0 =A0Alignment between the v4 and v6 descriptions would be better. >>>>> The >>>>> =A0 =A0v4 description has "code" in the diagram and says that "code" >>>>> is >>>>> =A0 =A0OPTION_CONTAINER_V4. =A0The v6 description has "OPTION_CONTAINE= R_V6" >>>>> =A0 =A0in the diagram and says that "option-code" is OPTION_CONTAINER_= V6. >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>> > > _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From gson@rim.com Wed Apr 15 06:51:49 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F25E3A6E6F; Wed, 15 Apr 2009 06:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7A4SoGgye6J6; Wed, 15 Apr 2009 06:51:48 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 2D4E83A6E6A; Wed, 15 Apr 2009 06:51:47 -0700 (PDT) Received: from mhs04ykf.rim.net (unknown [127.0.0.1]) by mhs04ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 7823B5C23C; Wed, 15 Apr 2009 09:52:58 -0400 (EDT) X-AuditID: 0a666446-a918dbb000007e46-38-49e5e6ba2cac Received: from XCH39YKF.rim.net (unknown [10.64.31.40]) by mhs04ykf.rim.net (Symantec Mail Security) with ESMTP id 2AD245C22F; Wed, 15 Apr 2009 09:52:58 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2009 09:52:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Wed, 15 Apr 2009 09:52:57 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FCD0@XCH42YKF.rim.net> In-Reply-To: <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Thread-Index: Acm9bS0eCLBGto29TXqPRM/5XXc1WAAYCP/w From: "Giyeong Son" To: "Ted Lemon" , "Ralph Droms" X-OriginalArrivalTime: 15 Apr 2009 13:52:58.0107 (UTC) FILETIME=[7BE32CB0:01C9BDD1] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Thu, 16 Apr 2009 09:29:32 -0700 Cc: mif , ietf@ietf.org, gen-art@ietf.org, dhc WG , Black_David@emc.com, Bernie Volz Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 13:51:49 -0000 I think Ted pointed out very interesting but crucial problems if I understood correctly. So, I'd like to confirm what Ted indicated and emphasized: 1. How to dynamically/automatically/efficiently enable and manage multiple active interfaces on a host? 2. How to utilize multiple active interfaces on a host? 2. What are the efficient (or cost-effective) routing decision policy? Is it least cost routing policy? Or other? If it is least cost routing policy, what are the costs? Are they "money" to use the connection (e.g. WiFi vs. cellular), "time" to spend for the transmission, "reliability" of the transmission, etc? If those are what Ted indicated, I am also interested in asking if the above things are in scope of MIF. Based on my experience in terms of simultaneous use of multiple interfaces, the aboves are the most critical and interesting issues in practice in order to utilize the network environment of simultaneous use of multiple interfaces reliably and efficiently. Giyeong -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Ted Lemon Sent: April 14, 2009 5:48 PM To: Ralph Droms Cc: mif; ietf@ietf.org; Black_David@emc.com; dhc WG; gen-art@ietf.org; Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: > Now, I admit I'm describing a hypothetical and abstract scenario. I > don't have a specific example of a situation in which a host might > make decisions - either in the stack or in an application or ??? - > about outbound traffic based on knowledge of how that traffic would be > forwarded by the RG. That's right. But I think it's not an accident that this is a hypothetical scenario. In reality, a scenario like this has been likely ever since wireless and wired network interfaces became standard on laptops. And yet we don't have any real-life examples of problems that this has caused, which need solving. To me, that seems like an indication that this is not a real operational problem. That is, that the answer "if two DHCP servers send the same client conflicting information on two different interfaces, that is a misconfiguration, and should be solved by correcting the misconfiguration" is, in practice, the correct answer. If it were not, we would be hearing about concrete, real-world scenarios of the type you describe, not about hypothetical ones. I don't mean to minimize this issue - if in fact there is some future real-world scenario where this would be a serious problem, it would be good if we could anticipate it. It might be profitable to consider analogies. For instance, right now I have IPv6 set up at home. Because IPv6 isn't deployed at all in Tucson, the way I have this working is by tunneling. Since there are two tunnel brokers offering service for people like me, and I am a bit adventurous, I have two tunnels. Right now, every IPv6 packet I ever transmit goes out one of those tunnels, with the exception of packets destined for a specific net, for which I have defined a static route. First of all, this scenario works just fine. Both tunnels are configured as a default route - it just happens that Linux's route selection process always chooses the first one. This algorithm would work poorly if one interface were preferable to the other, but since both are equivalent it's not a problem. Second, though, why do I have a default route configured? It's because I'm talking to a node on that network that will only answer if I use the source address of one of the tunnels; and will ignore any packets I send it with the other source address. So in the case where there was a problem, I manually configured a workaround. How could we automatically solve this problem? Simple: any time we are initiating communication with a device on the network, and do not know that the communication is going to work, we simultaneously start the communication in every plausible way. So suppose that there are two AAAA records corresponding to the machine I want to talk to, and I have two global IP addresses. I'm going to send four syn packets. The first syn-ack I get back is the one I'm actually going to use - I'll send RST packets to the other three. This is analogous to the solution Stuart Cheshire described a couple of IETFs ago to the problem of IPv6 causing connectivity problems instead of expanding connectivity opportunities - you can't prefer one solution over the other, because you have no basis for doing so, so you have to try all possible solutions and choose the one that works best. My only extension, if it is one, is that I've added the source address to the matrix - I'm not sure Stuart mentioned that. Now, how does this extend when we go to DHCP? Suppose I have DNS resolver configurations from two DHCP servers. I try both in parallel. I can winnow it down a bit: since I received the DNS server information from one DHCP server on one interface, and the DNS server information from the other DHCP server on a different interface, I only have to try to query the DNS server using the source addresses of the interface on which that DNS server's configuration information was received. But how do I do that if the device that has two interfaces is not the device originating the query, as is the case with the container option? I think the answer is that I can't. There is no heuristic that I can define that will always make the right choice, because the device receiving the container options has to make the choice for the client. In DHCPv6, we could at least give the client a hint about what to do as follows: Suppose that I am dual-homed. I ask for, and get, a container option on both outward-facing interfaces. I also wind up configuring one or more prefixes as a result of my communication with the DHCPv6 server on these two interfaces. I wind up advertising prefixes to the client based on the answers that I get on both outward-facing interfaces, so for example if I get a single prefix delegation from each DHCPv6 server, I will advertise two prefixes to the client. So when the client asks for, and gets, IA_ADDR configurations for both prefixes, I include the container option information from each DHCPv6 server in the IA_ADDR option for the prefix provided by that DHCPv6 server. Now the client has enough information to make a choice - it can use the source address for the prefix from a DHCP server to communicate with the DNS servers provided by that DHCP server. But this requires a great deal of complexity on the client, and on the server. Is this complexity that we want? And we haven't even talked about the case where either due to cost considerations, or due to speed considerations, one interface is preferable to the other. How would we communicate that? How would we configure that? Supposing that one prefix is more expensive than another, does the client then not try the expensive prefix until it's timed out on the cheap prefix? What does that look like to the end-user? Does it fail gracefully? So I think it's an interesting problem space. And actually I think that you could come up with heuristics that would work most of the time, potentially at the cost of increased load on name servers, and increased network usage, and the occasional $1000 cellular data bill. But to come up with heuristics that will work the right way every time, I think that is very difficult. _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From Ted.Lemon@nominum.com Thu Apr 16 10:17:03 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16F353A6C55; Thu, 16 Apr 2009 10:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cm99HF8QwIop; Thu, 16 Apr 2009 10:17:02 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id EB3153A69E3; Thu, 16 Apr 2009 10:17:00 -0700 (PDT) Received: from source ([64.89.228.229]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSedoVS7fCENI/AdE8Zs96fgKL0DwaiZU@postini.com; Thu, 16 Apr 2009 10:18:14 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 616CC1B83E0; Thu, 16 Apr 2009 10:18:26 -0700 (PDT) Received: from uma.here (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Thu, 16 Apr 2009 10:18:13 -0700 Message-ID: <768A70B9-BB01-4BF9-8002-19CDDDDEE4FA@nominum.com> From: Ted Lemon To: Ralph Droms In-Reply-To: Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 10:18:11 -0700 References: X-Mailer: Apple Mail (2.930.3) Cc: dhc WG , The IESG Subject: Re: [dhcwg] New dhc WG co-chair X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:17:03 -0000 On Apr 16, 2009, at 4:39 AM, Ralph Droms wrote: > I'll speak for Jari and the WG in saying that we're all looking > forward to > working with you. I'm looking forward to it too. :') From Ted.Lemon@nominum.com Thu Apr 16 10:25:15 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78F0F3A6C55; Thu, 16 Apr 2009 10:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS9gvYLmW9zV; Thu, 16 Apr 2009 10:25:13 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 64F5E3A6EA0; Thu, 16 Apr 2009 10:25:12 -0700 (PDT) Received: from source ([64.89.228.229]) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSedqP6sMUBEsZD8gHxjM7HJVx5yS2Gfe@postini.com; Thu, 16 Apr 2009 10:26:26 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9A2791B83E0; Thu, 16 Apr 2009 10:26:35 -0700 (PDT) Received: from uma.here (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Thu, 16 Apr 2009 10:26:22 -0700 Message-ID: <132AB535-49B3-4C90-9C11-DAE73BFC46C0@nominum.com> From: Ted Lemon To: Giyeong Son In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FCC3@XCH42YKF.rim.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 10:26:20 -0700 References: <777025D7F9E074449F3DAEB73C25690205F0FCC3@XCH42YKF.rim.net> X-Mailer: Apple Mail (2.930.3) Cc: mif , "ietf@ietf.org" , "gen-art@ietf.org" , Ralph Droms , dhc WG , "Black_David@emc.com" Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:25:15 -0000 On 2009/4/13 Ralph Droms wrote: > For example, would a host process > information received from a Starbucks network over its 802.11 > interface differently from information received a home network over > the 802.11 interface? It's even more fun than that. How do we reliably know that we are at Starbucks, and not at home? The SSID? That's not an authenticated token. Currently Windows makes security decisions based on the SSID. You could call this the best answer they could come up with for a problem with no good answers. Or you could say that it instills the user with a false sense of security. Either way, it's not something I'd be comfortable seeing in a protocol spec, so if the client is in fact to make decisions as you've suggested, we'd need a secure way of doing this. I don't know enough about WPA Enterprise to know if there's a bidirectional authentication going on there - from the UI perspective it looks like it's one-way. From rdroms@cisco.com Thu Apr 16 10:31:47 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63ADE3A6C55; Thu, 16 Apr 2009 10:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUgN0nTeX5eN; Thu, 16 Apr 2009 10:31:46 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6D0D83A6B6B; Thu, 16 Apr 2009 10:31:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,199,1238976000"; d="scan'208";a="72303930" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 16 Apr 2009 17:32:13 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3GHWD1h014247; Thu, 16 Apr 2009 10:32:13 -0700 Received: from sjc-vpnasa1-98.cisco.com (sjc-vpnasa1-98.cisco.com [10.21.104.98]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3GHVdJt005401; Thu, 16 Apr 2009 17:32:10 GMT Message-Id: <9E06629B-2B0E-4AD3-BD5F-94F2C2192CAE@cisco.com> From: Ralph Droms To: Ted Lemon In-Reply-To: <132AB535-49B3-4C90-9C11-DAE73BFC46C0@nominum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 13:31:38 -0400 References: <777025D7F9E074449F3DAEB73C25690205F0FCC3@XCH42YKF.rim.net> <132AB535-49B3-4C90-9C11-DAE73BFC46C0@nominum.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1346; t=1239903133; x=1240767133; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20[mif]=20=20Gen-ART=20review=2 0of=20draft-ietf-dhc-container-00 |Sender:=20; bh=aTm+xsXT0alHKoaPUfFi8hnKfO7pQOQ1Su81nqrYXnM=; b=E9mc30l3v/Dq0SmShHzM+BGRueDdB8hte4y5+NUPgrtXM+jaPeEVw+cd+8 doFN4LlIfOsls2Lic0ghlAbuQX5XGyOFuZBJlal6cctzVd4qguPZ3wQOyLWs mhvLWZKWzndZ5S57cK+BRe7Ze1fmU3UNVbxpL4HlWI0LlOmWkGXtU=; Authentication-Results: sj-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Giyeong Son , ietf@ietf.org, gen-art@ietf.org, dhc WG , mif , Black_David@emc.com Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:31:47 -0000 Yup ... there is currently no way to provide authenticated, meaningful identification of the network(s) to which a host is attached. Without that identification, it's pretty hard to write any reasonable policies. - Ralph On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote: > On 2009/4/13 Ralph Droms wrote: >> For example, would a host process >> information received from a Starbucks network over its 802.11 >> interface differently from information received a home network over >> the 802.11 interface? > > It's even more fun than that. How do we reliably know that we are > at Starbucks, and not at home? The SSID? That's not an > authenticated token. Currently Windows makes security decisions > based on the SSID. You could call this the best answer they could > come up with for a problem with no good answers. Or you could say > that it instills the user with a false sense of security. Either > way, it's not something I'd be comfortable seeing in a protocol > spec, so if the client is in fact to make decisions as you've > suggested, we'd need a secure way of doing this. I don't know > enough about WPA Enterprise to know if there's a bidirectional > authentication going on there - from the UI perspective it looks > like it's one-way. > From jari.arkko@piuha.net Sat Apr 18 02:06:06 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E78D3A6828; Sat, 18 Apr 2009 02:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDra-89v+zF3; Sat, 18 Apr 2009 02:06:05 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id BDA713A6A32; Sat, 18 Apr 2009 02:05:35 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id D930A198781; Sat, 18 Apr 2009 12:06:48 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 5347B1986D9; Sat, 18 Apr 2009 12:06:48 +0300 (EEST) Message-ID: <49E9981C.1010709@piuha.net> Date: Sat, 18 Apr 2009 12:06:36 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Ted Lemon References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> <20090415205150.GN44356@cisco.com> <8E296595B6471A4689555D5D725EBB210C3EC565@xmb-rtp-20a.amer.cisco.com> <3750E438-1F0A-4E0B-B4A6-4AE3FDE22240@nominum.com> In-Reply-To: <3750E438-1F0A-4E0B-B4A6-4AE3FDE22240@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: mif , Bernie Volz , Scott Brim , "Ralph Droms \(rdroms\)" , "gen-art@ietf.org" , dhc WG , "Black_David@emc.com" , "ietf@ietf.org" Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 09:06:06 -0000 I would be in favor of stating explicitly that this issue is outside the scope of the specification at hand. Jari From jari.arkko@piuha.net Sat Apr 18 02:07:44 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCCA03A6802; Sat, 18 Apr 2009 02:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cL7hHdlPcij; Sat, 18 Apr 2009 02:07:44 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id A84023A688A; Sat, 18 Apr 2009 02:07:43 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 62EE0198781; Sat, 18 Apr 2009 12:08:57 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id EDCED1986D9; Sat, 18 Apr 2009 12:08:56 +0300 (EEST) Message-ID: <49E9989D.5030807@piuha.net> Date: Sat, 18 Apr 2009 12:08:45 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Ralph Droms References: <777025D7F9E074449F3DAEB73C25690205F0FCC3@XCH42YKF.rim.net> <132AB535-49B3-4C90-9C11-DAE73BFC46C0@nominum.com> <9E06629B-2B0E-4AD3-BD5F-94F2C2192CAE@cisco.com> In-Reply-To: <9E06629B-2B0E-4AD3-BD5F-94F2C2192CAE@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: dhc WG , mif , Ted Lemon , ietf@ietf.org Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 09:07:44 -0000 802.11i authentication, if enabled, provides mutual authentication, but that's only between the client and the _home_ network. You know that the home network trusts the access network because it was given the session key, but you have no idea if the access network is, say, CheapAccessInc or WorldsMostExpensiveRoamingCorp. There are extensions of network access authentication methods where you also get some form of an authenticated identity for the access network. 3GPP LTE access authentication or EAP-AKA', for instance. Not yet widely deployed, of course. (But I'm digressing from the original stop.) Jari Ralph Droms wrote: > Yup ... there is currently no way to provide authenticated, meaningful > identification of the network(s) to which a host is attached. Without > that identification, it's pretty hard to write any reasonable policies. > > - Ralph > > On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote: > >> On 2009/4/13 Ralph Droms wrote: >>> For example, would a host process >>> information received from a Starbucks network over its 802.11 >>> interface differently from information received a home network over >>> the 802.11 interface? >> >> It's even more fun than that. How do we reliably know that we are at >> Starbucks, and not at home? The SSID? That's not an authenticated >> token. Currently Windows makes security decisions based on the SSID. >> You could call this the best answer they could come up with for a >> problem with no good answers. Or you could say that it instills the >> user with a false sense of security. Either way, it's not something >> I'd be comfortable seeing in a protocol spec, so if the client is in >> fact to make decisions as you've suggested, we'd need a secure way of >> doing this. I don't know enough about WPA Enterprise to know if >> there's a bidirectional authentication going on there - from the UI >> perspective it looks like it's one-way. >> > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > From denghui02@gmail.com Sun Apr 19 01:01:41 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CF5B3A6CCE; Sun, 19 Apr 2009 01:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI-Yu350iqlY; Sun, 19 Apr 2009 01:01:39 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id C7D4F3A6B92; Sun, 19 Apr 2009 01:01:39 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1760018wfg.31 for ; Sun, 19 Apr 2009 01:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4rOLEW7sbUqluFu5pFc06KwCIekfoAUVEaPX9CMZNvw=; b=QtMaTatfUw89DonJ9Cu8nBKv3+lHrbL7KPeXy6uA+fcTpQ7JtkRZO5QBFuzI7OzWnp hs2rvgya1uC0kABhwaFBQIbZH8s4YazDM/AXI+lyh5kNnfof24Ix5UdmU3JPPGJ+Jgt4 3SyX8G29IVPhgkEfBa/X0cG1YKG6qt7L9A3Fo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xCk82UsM9t9It+45QuU7JUzlfahcxMkkZ2g86FmpZvx+tZnA8kFXO051AFpUtuAuP8 cu1+WUxLkqjWhi7fJnQg/2CF5+XWFq6Jtt2GBYFbtGHerxW7lwksB78Y/spMZuL53Es1 hpJk5pDfwgdukn23437BYSyE7opri2/I2i0+Q= MIME-Version: 1.0 Received: by 10.142.71.16 with SMTP id t16mr3954862wfa.273.1240128174395; Sun, 19 Apr 2009 01:02:54 -0700 (PDT) In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FCC3@XCH42YKF.rim.net> References: <1d38a3350904130823u4ee3f79ek79ed670da89913e8@mail.gmail.com> <777025D7F9E074449F3DAEB73C25690205F0FCC3@XCH42YKF.rim.net> Date: Sun, 19 Apr 2009 16:02:54 +0800 Message-ID: <1d38a3350904190102k6f8576bdu7e021244bb48d1e6@mail.gmail.com> From: Hui Deng To: Giyeong Son Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , ietf@ietf.org, gen-art@ietf.org, Ralph Droms , dhc WG , Black_David@emc.com Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 08:01:41 -0000 I guess "routable" in mif mostly talking about there exist at least two routing entry,(it doesn't matter whether it is the default router) and both of them support one specific destination. In that case, at least one routing entry will not work, it means not routab= le. -Hui 2009/4/15 Giyeong Son : > I agree on Hui's and Ralpha's thoughts. > > There may be a necessary or worthy study that identifies and classifies w= hat kind of information or network characteristics of/from the interfaces a= re necessary and helpful in order to judge active and valid routable interf= aces for the destination (I am not sure the meaning and scope of "routable"= with a destination in terms of MIF though) and determine an efficient/best= one among them for the destination endpoint for the moment. > > Giyeong > > > > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui= Deng > Sent: April 13, 2009 11:24 AM > To: Ralph Droms > Cc: mif; ietf@ietf.org; gen-art@ietf.org; Black_David@emc.com; dhc WG > Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 > > Hi, Ralph, > > I agree what you said here, Scott raised the possible issue how to differ= entiate the source. > > One instant thinking about the two different 802.11 interface is that the= principal source policy selection will not be able to tell the diffference= , we could allow high level policy to recommend how to handle it, give a ex= ample, we may prioritize some wifi apn policy, and make others as just a ca= tegory of normal wifi. > > Anyhow, those thing need to be further studied based on the current pract= ice. > Thanks for the discussion. > > -Hui > > > 2009/4/13 Ralph Droms : >> Hui - I think there is an issue for hosts with multiple interfaces >> triggered by Scott's comments about the container option: even if a >> host is physically aware that it has multiple interfaces, how does it >> take the characteristics of the networks behind those interfaces into >> account when it merges information? =A0For example, would a host process >> information received from a Starbucks network over its 802.11 >> interface differently from information received a home network over the = 802.11 interface? >> >> - Ralph >> >> On Apr 12, 2009, at 2:34 AM 4/12/09, Hui Deng wrote: >> >>> Hi, Scott, >>> >>> Based on the current MIF charter proposal, it consider only host. >>> http://www.ietf.org/mail-archive/web/mif/current/msg00367.html >>> I am wondering whether RG is a kind of host? >>> >>> Anyhow, this discussion benefit MIF for the future consideration how >>> to identify the source. >>> >>> Many thanks >>> >>> -Hui >>> >>> 2009/4/11 Scott Brim : >>>> >>>> Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >>>>> >>>>> Scott raises an interesting point about identifying the source of >>>>> options when delivered to clients. >>>>> >>>>> BTW, Scott - what is "DHS"? >>>> >>>> Sorry, DHCP server >>>> >>>>> The usual case - almost the only case today - is that there is a >>>>> single upstream service provider and a single source of DHCP >>>>> options to be passed along to the client. =A0In this scenario, >>>>> there's no need to pass along any information identifying the source = of the options. >>>>> >>>>> To allow for a multihomed subscriber network, I can imagine adding >>>>> a tag that would be passed along with the options so the subscriber >>>>> client can identify the source of each option. =A0But, what would the >>>>> client do with that information? =A0How would the client interpret >>>>> it? =A0What is the syntax and semantics of the tagging? >>>>> >>>>> Taken a step farther, sourcing information might be required even >>>>> if there is no intermediate RG and the contained option is not in >>>>> use. =A0How does a device with multiple interfaces make policy >>>>> decisions about information received on those multiple interfaces >>>>> (which is pretty much the question Scott asks about the container opt= ion)? >>>>> >>>>> - Ralph >>>> >>>> Well put. =A0It all comes down to where information is going to be >>>> merged. =A0The case where a single RG client connected to multiple SP >>>> servers is essentially already covered by MIF/6man, they just need >>>> to document it. =A0If the information is merged at the RG server, then >>>> the RG server should somehow know which interface which DHCP >>>> information came from. =A0If all of the information is transparently >>>> passed to the consumer device, then it needs the tags as well. >>>> >>>> I don't know how the information could be usefully tagged -- the SP >>>> server's IP address doesn't sound like a good idea. =A0The WG should >>>> decide if tagging should be included in the container syntax or >>>> added later (but documented now as needing study). >>>> >>>> I'm CCing MIF in case people there aren't on the ietf list. >>>> >>>> Thanks ... Scott >>>> >>>>> >>>>> On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >>>>> >>>>>> I have been selected as the General Area Review Team (Gen-ART) >>>>>> reviewer for this draft (for background on Gen-ART, please see >>>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>>> >>>>>> Please wait for direction from your document shepherd or AD before >>>>>> posting a new version of the draft. >>>>>> >>>>>> Document: draft-ietf-dhc-container-00 >>>>>> Reviewer: Scott Brim >>>>>> Review Date: =A0 =A0 =A0 =A0 7 April 2009 >>>>>> IESG Telechat date: 14 April 2009 >>>>>> >>>>>> Summary: >>>>>> >>>>>> This draft is on the right track but has open issues. >>>>>> >>>>>> Comments: >>>>>> >>>>>> More significant: >>>>>> >>>>>> =A0I am concerned about multiple interface scenarios as are being >>>>>> =A0discussed in MIF and 6MAN, where either the RG is multiply >>>>>> connected >>>>>> =A0or the end device is. =A0For a discussion of the sort of problems >>>>>> that >>>>>> =A0lead to this concern, see (for example) notes from the MIF BOF at >>>>>> =A0IETF74. >>>>>> >>>>>> =A0- There must be a way to associate options with a particular >>>>>> =A0 =A0upstream DHS they were obtained from, when the container is >>>>>> passed >>>>>> =A0 =A0to the RG server and perhaps to the end device. =A0This sourc= e >>>>>> =A0 =A0information may or may not be in the container itself -- that= 's >>>>>> up >>>>>> =A0 =A0to the WG to decide. =A0If it is decided that the source >>>>>> information >>>>>> =A0 =A0will not be part of the container syntax, at least the fact >>>>>> that >>>>>> =A0 =A0it is necessary should be documented for people who ultimatel= y >>>>>> do >>>>>> =A0 =A0specify how container options are passed. >>>>>> >>>>>> =A0- The SP server may have its ideas of how a consumer device >>>>>> should >>>>>> =A0 =A0be configured, but it is not appropriate to say that the "SP >>>>>> =A0 =A0server MUST be able to control which DHCP options are >>>>>> transmitted >>>>>> =A0 =A0to the consumer device". =A0The RG server may need to make >>>>>> decisions >>>>>> =A0 =A0about information from multiple DHCP servers. =A0Perhaps you >>>>>> could >>>>>> =A0 =A0say that the SP server MUST be able to "provide information" = to >>>>>> =A0 =A0the RG server. >>>>>> >>>>>> Less significant: >>>>>> >>>>>> =A05.1 and 5.2 >>>>>> >>>>>> =A0 =A0Alignment between the v4 and v6 descriptions would be better. >>>>>> The >>>>>> =A0 =A0v4 description has "code" in the diagram and says that "code" >>>>>> is >>>>>> =A0 =A0OPTION_CONTAINER_V4. =A0The v6 description has "OPTION_CONTAI= NER_V6" >>>>>> =A0 =A0in the diagram and says that "option-code" is OPTION_CONTAINE= R_V6. >>>> >>>> _______________________________________________ >>>> dhcwg mailing list >>>> dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>> >> >> > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > From denghui02@gmail.com Sun Apr 19 07:44:51 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D682328C1C3; Sun, 19 Apr 2009 07:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVjq7mGCOz20; Sun, 19 Apr 2009 07:44:50 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 9ABBB3A684F; Sun, 19 Apr 2009 07:44:50 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1877504wfg.31 for ; Sun, 19 Apr 2009 07:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MBgr8lvpWdn1eDC0CFSYwk4WKRRdS/9WZH2jhIiv1oE=; b=scC4wydE/B1x7thRMDSwiQ7AZe/6ftnPWrnllkGN4viJmeNartxG6e33xnJKoG6++1 d618/Y0uFErhMEUw0nbhTSaI1ffc6itIUqFjX9gBafeuO3OmdqafW8euRR4W/3lnSD0m ADIaK4I+PexxGl4nEnhu+S8pMm+1MSkgpRiL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mN4NfQcd6es5Xsi2lmGR027+aXddscCcpAf5HUJ/W7u/gJOTqU9ccqYTAmieqrbZvE 79/PtDwr9JrB3qxw+R85edZPiuxRnIXGhq00ou5PhQPm6UKm/ajYQUZpjqIBFIkYtETF K3JP29KwRDSFdg48YN5ofsV/RRU+iPN/uQja0= MIME-Version: 1.0 Received: by 10.142.156.2 with SMTP id d2mr4081134wfe.179.1240152365876; Sun, 19 Apr 2009 07:46:05 -0700 (PDT) In-Reply-To: <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> Date: Sun, 19 Apr 2009 22:46:05 +0800 Message-ID: <1d38a3350904190746v577179d8u82123e5d889cffdc@mail.gmail.com> From: Hui Deng To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , "ietf@ietf.org" , Scott Brim , Ralph Droms , "gen-art@ietf.org" , dhc WG , "Black_David@emc.com" , Bernie Volz Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 14:44:51 -0000 Hi, Ted, Excuse me for my late comment, I try to catch this thread. For the case of the device has two interfaces which originate query. Your suggestion looks quite interesting: try every plausible way. I guess this is interesting topic in MIF future work. And you talked about Stuart Cheshire described a couple of IETFs ago, Could you help to point out the link? many thanks -Hui 2009/4/15 Ted Lemon : > On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: > >> Now, I admit I'm describing a hypothetical and abstract scenario. =A0I >> don't have a specific example of a situation in which a host might >> make decisions - either in the stack or in an application or ??? - >> about outbound traffic based on knowledge of how that traffic would be >> forwarded by the RG. > > That's right. =A0 But I think it's not an accident that this is a hypothe= tical > scenario. =A0 In reality, a scenario like this has been likely ever since > wireless and wired network interfaces became standard on laptops. =A0 And= yet > we don't have any real-life examples of problems that this has caused, wh= ich > need solving. =A0 To me, that seems like an indication that this is not a= real > operational problem. =A0 That is, that the answer "if two DHCP servers se= nd > the same client conflicting information on two different interfaces, that= is > a misconfiguration, and should be solved by correcting the misconfigurati= on" > is, in practice, the correct answer. > > If it were not, we would be hearing about concrete, real-world scenarios = of > the type you describe, not about hypothetical ones. > > I don't mean to minimize this issue - if in fact there is some future > real-world scenario where this would be a serious problem, it would be go= od > if we could anticipate it. =A0 It might be profitable to consider analogi= es. > > For instance, right now I have IPv6 set up at home. =A0 Because IPv6 isn'= t > deployed at all in Tucson, the way I have this working is by tunneling. > Since there are two tunnel brokers offering service for people like me, a= nd > I am a bit adventurous, I have two tunnels. =A0 Right now, every IPv6 pac= ket I > ever transmit goes out one of those tunnels, with the exception of packet= s > destined for a specific net, for which I have defined a static route. > > First of all, this scenario works just fine. =A0 Both tunnels are configu= red > as a default route - it just happens that Linux's route selection process > always chooses the first one. =A0 This algorithm would work poorly if one > interface were preferable to the other, but since both are equivalent it'= s > not a problem. > > Second, though, why do I have a default route configured? =A0 It's becaus= e I'm > talking to a node on that network that will only answer if I use the sour= ce > address of one of the tunnels; and will ignore any packets I send it with > the other source address. =A0 So in the case where there was a problem, I > manually configured a workaround. > > How could we automatically solve this problem? =A0 Simple: any time we ar= e > initiating communication with a device on the network, and do not know th= at > the communication is going to work, we simultaneously start the > communication in every plausible way. =A0 So suppose that there are two A= AAA > records corresponding to the machine I want to talk to, and I have two > global IP addresses. =A0 I'm going to send four syn packets. =A0 The firs= t > syn-ack I get back is the one I'm actually going to use - I'll send RST > packets to the other three. > > This is analogous to the solution Stuart Cheshire described a couple of > IETFs ago to the problem of IPv6 causing connectivity problems instead of > expanding connectivity opportunities - you can't prefer one solution over > the other, because you have no basis for doing so, so you have to try all > possible solutions and choose the one that works best. =A0 My only extens= ion, > if it is one, is that I've added the source address to the matrix - I'm n= ot > sure Stuart mentioned that. > > Now, how does this extend when we go to DHCP? =A0 Suppose I have DNS reso= lver > configurations from two DHCP servers. =A0 I try both in parallel. =A0 I c= an > winnow it down a bit: since I received the DNS server information from on= e > DHCP server on one interface, and the DNS server information from the oth= er > DHCP server on a different interface, I only have to try to query the DNS > server using the source addresses of the interface on which that DNS > server's configuration information was received. > > But how do I do that if the device that has two interfaces is not the dev= ice > originating the query, as is the case with the container option? =A0 I th= ink > the answer is that I can't. =A0 There is no heuristic that I can define t= hat > will always make the right choice, because the device receiving the > container options has to make the choice for the client. > > In DHCPv6, we could at least give the client a hint about what to do as > follows: > > Suppose that I am dual-homed. =A0 I ask for, and get, a container option = on > both outward-facing interfaces. =A0 I also wind up configuring one or mor= e > prefixes as a result of my communication with the DHCPv6 server on these = two > interfaces. =A0 I wind up advertising prefixes to the client based on the > answers that I get on both outward-facing interfaces, so for example if I > get a single prefix delegation from each DHCPv6 server, I will advertise = two > prefixes to the client. =A0 So when the client asks for, and gets, IA_ADD= R > configurations for both prefixes, I include the container option informat= ion > from each DHCPv6 server in the IA_ADDR option for the prefix provided by > that DHCPv6 server. =A0 Now the client has enough information to make a c= hoice > - it can use the source address for the prefix from a DHCP server to > communicate with the DNS servers provided by that DHCP server. > > But this requires a great deal of complexity on the client, and on the > server. =A0 Is this complexity that we want? =A0 And we haven't even talk= ed > about the case where either due to cost considerations, or due to speed > considerations, one interface is preferable to the other. =A0 How would w= e > communicate that? =A0How would we configure that? =A0 Supposing that one = prefix > is more expensive than another, does the client then not try the expensiv= e > prefix until it's timed out on the cheap prefix? =A0 What does that look = like > to the end-user? =A0 Does it fail gracefully? > > So I think it's an interesting problem space. =A0 And actually I think th= at > you could come up with heuristics that would work most of the time, > potentially at the cost of increased load on name servers, and increased > network usage, and the occasional $1000 cellular data bill. =A0 But to co= me up > with heuristics that will work the right way every time, I think that is > very difficult. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From denghui02@gmail.com Sun Apr 19 08:38:27 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B79BE28C0EF; Sun, 19 Apr 2009 08:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCZAcbRyXnuw; Sun, 19 Apr 2009 08:38:26 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 58FB03A686E; Sun, 19 Apr 2009 08:38:26 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1894559wfg.31 for ; Sun, 19 Apr 2009 08:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=V5ul3hehJohRx4Mcex1oGLHzgjIBqqaByWgBPJ0vNcY=; b=ZyhndReheKQ9kbq/cUVk5/x0sxy8nmLQzqT5gQTW4EVwTU/jXluKF0lZFI8muUHavU EuumT07gC2Ka++4UQYrydqIMRoGQ9vfzauX/DoUaqufeKBDtuiEQGQDJT+xw6DMZzwKR 9BiWw/vRUMBKyUyKOYk9Miouq70fDeKilt+Rw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tCVUDWJC+Wvd5liUumEqNm2+y0t1y6aSuloVqHlKBXdwINRT4/AyoICBj7EaoDmPd+ eAN4uWSe8k7yvbiQH38EdkzWOZ9MIWV14SL9hx+wNXT5IGzFIVvWMN8GOcJZUrhEwXey FSfGgoY/7oaVxG+xzz5f5DyXkZzgfrYMvNfiY= MIME-Version: 1.0 Received: by 10.143.158.2 with SMTP id k2mr4078496wfo.245.1240155581538; Sun, 19 Apr 2009 08:39:41 -0700 (PDT) In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FCD0@XCH42YKF.rim.net> References: <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> <777025D7F9E074449F3DAEB73C25690205F0FCD0@XCH42YKF.rim.net> Date: Sun, 19 Apr 2009 23:39:41 +0800 Message-ID: <1d38a3350904190839p159daf72q8e6f5c7145536944@mail.gmail.com> From: Hui Deng To: Giyeong Son Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , ietf@ietf.org, gen-art@ietf.org, Ralph Droms , Ted Lemon , dhc WG , Black_David@emc.com, Bernie Volz Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 15:38:27 -0000 Hi, Giyeong, At least those are not in the current charter scope. but Ted gave a one potential solution on one problem. Regarding to Money et al, I think IETF is not going to talk about it. which is more operational recommendation. Operation could recommend the benchmark to let the user to select what he favoriate by human language other than technical language. thanks -HUi 2009/4/15 Giyeong Son : > I think Ted pointed out very interesting but crucial problems if I > understood correctly. So, I'd like to confirm what Ted indicated and > emphasized: > > 1. How to dynamically/automatically/efficiently enable and manage > multiple active interfaces on a host? > 2. How to utilize multiple active interfaces on a host? > 2. What are the efficient (or cost-effective) routing decision policy? > Is it least cost routing policy? Or other? If it is least cost routing > policy, what are the costs? Are they "money" to use the connection (e.g. > WiFi vs. cellular), "time" to spend for the transmission, "reliability" > of the transmission, etc? > > If those are what Ted indicated, I am also interested in asking if the > above things are in scope of MIF. Based on my experience in terms of > simultaneous use of multiple interfaces, the aboves are the most > critical and interesting issues in practice in order to utilize the > network environment of simultaneous use of multiple interfaces reliably > and efficiently. > > > Giyeong > > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > Ted Lemon > Sent: April 14, 2009 5:48 PM > To: Ralph Droms > Cc: mif; ietf@ietf.org; Black_David@emc.com; dhc WG; gen-art@ietf.org; > Bernie Volz > Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 > > On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: > >> Now, I admit I'm describing a hypothetical and abstract scenario. =A0I >> don't have a specific example of a situation in which a host might >> make decisions - either in the stack or in an application or ??? - >> about outbound traffic based on knowledge of how that traffic would be > >> forwarded by the RG. > > That's right. =A0 But I think it's not an accident that this is a > hypothetical scenario. =A0 In reality, a scenario like this has been > likely ever since wireless and wired network interfaces became > standard on laptops. =A0 And yet we don't have any real-life examples of > problems that this has caused, which need solving. =A0 To me, that seems > like an indication that this is not a real operational problem. =A0 That > is, that the answer "if two DHCP servers send the same client > conflicting information on two different interfaces, that is a > misconfiguration, and should be solved by correcting the > misconfiguration" is, in practice, the correct answer. > > If it were not, we would be hearing about concrete, real-world scenarios > of the type you describe, not about hypothetical ones. > > I don't mean to minimize this issue - if in fact there is some future > real-world scenario where this would be a serious problem, it would be > good if we could anticipate it. =A0 It might be profitable to consider > analogies. > > For instance, right now I have IPv6 set up at home. =A0 Because IPv6 > isn't deployed at all in Tucson, the way I have this working is by > tunneling. =A0 Since there are two tunnel brokers offering service for > people like me, and I am a bit adventurous, I have two tunnels. > Right now, every IPv6 packet I ever transmit goes out one of those > tunnels, with the exception of packets destined for a specific net, for > which I have defined a static route. > > First of all, this scenario works just fine. =A0 Both tunnels are > configured as a default route - it just happens that Linux's route > selection process always chooses the first one. =A0 This algorithm would > work poorly if one interface were preferable to the other, but since > both are equivalent it's not a problem. > > Second, though, why do I have a default route configured? =A0 It's > because I'm talking to a node on that network that will only answer if I > use the source address of one of the tunnels; and will ignore any > packets I send it with the other source address. =A0 So in the case > where there was a problem, I manually configured a workaround. > > How could we automatically solve this problem? =A0 Simple: any time we > are initiating communication with a device on the network, and do not > know that the communication is going to work, we simultaneously start > the communication in every plausible way. =A0 So suppose that there are > two AAAA records corresponding to the machine I want to talk to, and I > have two global IP addresses. =A0 I'm going to send four syn packets. > The first syn-ack I get back is the one I'm actually going to use - I'll > send RST packets to the other three. > > This is analogous to the solution Stuart Cheshire described a couple of > IETFs ago to the problem of IPv6 causing connectivity problems instead > of expanding connectivity opportunities - you can't prefer one solution > over the other, because you have no basis for doing so, so you have to > try all possible solutions and choose the one that works > best. =A0 My only extension, if it is one, is that I've added the source > address to the matrix - I'm not sure Stuart mentioned that. > > Now, how does this extend when we go to DHCP? =A0 Suppose I have DNS > resolver configurations from two DHCP servers. =A0 I try both in > parallel. =A0 I can winnow it down a bit: since I received the DNS > server information from one DHCP server on one interface, and the DNS > server information from the other DHCP server on a different interface, > I only have to try to query the DNS server using the source addresses of > the interface on which that DNS server's configuration information was > received. > > But how do I do that if the device that has two interfaces is not the > device originating the query, as is the case with the container > option? =A0 I think the answer is that I can't. =A0 There is no heuristic > that I can define that will always make the right choice, because the > device receiving the container options has to make the choice for the > client. > > In DHCPv6, we could at least give the client a hint about what to do as > follows: > > Suppose that I am dual-homed. =A0 I ask for, and get, a container option > on both outward-facing interfaces. =A0 I also wind up configuring one or > more prefixes as a result of my communication with the DHCPv6 server > on these two interfaces. =A0 I wind up advertising prefixes to the > client based on the answers that I get on both outward-facing > interfaces, so for example if I get a single prefix delegation from > each DHCPv6 server, I will advertise two prefixes to the client. =A0 So > when the client asks for, and gets, IA_ADDR configurations for both > prefixes, I include the container option information from each DHCPv6 > server in the IA_ADDR option for the prefix provided by that DHCPv6 > server. =A0 Now the client has enough information to make a choice - it > can use the source address for the prefix from a DHCP server to > communicate with the DNS servers provided by that DHCP server. > > But this requires a great deal of complexity on the client, and on the > server. =A0 Is this complexity that we want? =A0 And we haven't even > talked about the case where either due to cost considerations, or due > to speed considerations, one interface is preferable to the other. > How would we communicate that? =A0How would we configure that? > Supposing that one prefix is more expensive than another, does the > client then not try the expensive prefix until it's timed out on the > cheap prefix? =A0 What does that look like to the end-user? =A0 Does it > fail gracefully? > > So I think it's an interesting problem space. =A0 And actually I think > that you could come up with heuristics that would work most of the time, > potentially at the cost of increased load on name servers, and increased > network usage, and the occasional $1000 cellular data > bill. =A0 But to come up with heuristics that will work the right way > every time, I think that is very difficult. > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From Ted.Lemon@nominum.com Sun Apr 19 16:39:13 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DFE63A6B2B; Sun, 19 Apr 2009 16:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2q3CNq2R5Pk; Sun, 19 Apr 2009 16:39:12 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 7447F3A69B4; Sun, 19 Apr 2009 16:39:12 -0700 (PDT) Received: from source ([64.89.228.229]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSeu2aOkcdLiOhxWoKr1I/guTtWKLFeNJ@postini.com; Sun, 19 Apr 2009 16:40:28 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 40B581B83E3; Sun, 19 Apr 2009 16:40:33 -0700 (PDT) Received: from [10.0.1.106] (67.9.133.211) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Sun, 19 Apr 2009 16:40:20 -0700 Message-ID: From: Ted Lemon To: Hui Deng In-Reply-To: <1d38a3350904190746v577179d8u82123e5d889cffdc@mail.gmail.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 19 Apr 2009 16:40:18 -0700 References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> <1d38a3350904190746v577179d8u82123e5d889cffdc@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: mif , "ietf@ietf.org" , Scott Brim , Ralph Droms , "gen-art@ietf.org" , dhc WG , "Black_David@emc.com" , Bernie Volz Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 23:39:13 -0000 On Apr 19, 2009, at 7:46 AM, Hui Deng wrote: > And you talked about Stuart Cheshire described a couple of IETFs ago, > Could you help to point out the link? Sadly, I don't have it, but I suspect Stuart does, and I'm pretty sure he's reading this. The gist of what he was saying is that if you have an IPv4 address that looks okay, and an IPv6 address that looks okay, you can't assume that they *are* okay, because there may be no route to the global internet on either your IPv4 or your IPv6 link. So you must attempt to use both addresses, not just one, and you must do it at the same time. Whichever one answers first, you take. If you prefer either IPv4 or IPv6, and the transport you preferred happens to be the one that was broken, a smart user will disable the one you've preferred. That user will then advise his or her friends, for example, that "IPv6 creates instability, so you should disable it." This impedes deployment. The unattended multiple interface situation is quite similar. I think the attended case (a laptop with two or more network interfaces) is actually better handled through user intervention, because the user has knowledge of the physical situation that would be difficult to communicate to the computer. But in the unattended case, you can get into the same sort of "wrong learning" situation, where a smart but naive user who debugs a network problem winds up learning a workaround that would impede interoperability if everybody did it. From gwz@net-zen.net Sun Apr 19 21:06:20 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C035B3A6B83 for ; Sun, 19 Apr 2009 21:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=-1.219, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+82D0ZRTgBw for ; Sun, 19 Apr 2009 21:06:20 -0700 (PDT) Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by core3.amsl.com (Postfix) with SMTP id 8FC323A6A4D for ; Sun, 19 Apr 2009 21:06:18 -0700 (PDT) Received: (qmail 9127 invoked from network); 20 Apr 2009 04:07:33 -0000 Received: from unknown (124.120.225.34) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 20 Apr 2009 04:07:32 -0000 From: "Glen Zorn" To: "'Dhcwg WG'" Date: Mon, 20 Apr 2009 11:07:25 +0700 Organization: Network Zen Message-ID: <002701c9c16d$85762bc0$90628340$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnBbYMXz2gwNwcZT7CVtJO0N4lXXg== Content-Language: en-us Subject: [dhcwg] Comment on http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-agentopt-delegate-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 04:06:20 -0000 The acronym "ORO" is used without expansion. ~gwz At one time in the US, in the mid-nineteenth century, working for wage labor was considered not very different from chattel slavery...anyone who thinks it's legitimate to be a wage laborer is internalizing oppression in a way which would have seemed intolerable to people in the mills 150 years ago. -- Noam Chomsky, "Propaganda & the Public Mind" From gwz@net-zen.net Sun Apr 19 21:26:08 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B543A6A4D for ; Sun, 19 Apr 2009 21:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdrwDQY7asmz for ; Sun, 19 Apr 2009 21:26:08 -0700 (PDT) Received: from smtpauth12.prod.mesa1.secureserver.net (smtpauth12.prod.mesa1.secureserver.net [64.202.165.35]) by core3.amsl.com (Postfix) with SMTP id 6AE163A695D for ; Sun, 19 Apr 2009 21:26:05 -0700 (PDT) Received: (qmail 11569 invoked from network); 20 Apr 2009 04:27:20 -0000 Received: from unknown (124.120.225.34) by smtpauth12.prod.mesa1.secureserver.net (64.202.165.35) with ESMTP; 20 Apr 2009 04:27:20 -0000 From: "Glen Zorn" To: "'Dhcwg WG'" Date: Mon, 20 Apr 2009 11:27:13 +0700 Organization: Network Zen Message-ID: <003401c9c170$492fff30$db8ffd90$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnBcEcmFtfRk17ORDew33wUI8blEw== Content-Language: en-us Subject: [dhcwg] RAAN & SRSN drafts X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 04:26:08 -0000 Is there some reason of which I am unaware that these two documents should not be combined? ~gwz At one time in the US, in the mid-nineteenth century, working for wage labor was considered not very different from chattel slavery...anyone who thinks it's legitimate to be a wage laborer is internalizing oppression in a way which would have seemed intolerable to people in the mills 150 years ago. -- Noam Chomsky, "Propaganda & the Public Mind" From gson@rim.com Thu Apr 16 14:33:02 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A56173A6946; Thu, 16 Apr 2009 14:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MaoiaXAbE2X; Thu, 16 Apr 2009 14:33:01 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 882C73A6D15; Thu, 16 Apr 2009 14:33:01 -0700 (PDT) Received: from mhs04ykf.rim.net (unknown [127.0.0.1]) by mhs04ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 02CA45C685; Thu, 16 Apr 2009 17:34:14 -0400 (EDT) X-AuditID: 0a666446-a998ebb000007e46-ac-49e7a455cd22 Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs04ykf.rim.net (Symantec Mail Security) with ESMTP id AE7415C645; Thu, 16 Apr 2009 17:34:13 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 16 Apr 2009 17:34:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Thu, 16 Apr 2009 17:33:58 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FCE3@XCH42YKF.rim.net> In-Reply-To: <9E06629B-2B0E-4AD3-BD5F-94F2C2192CAE@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 Thread-Index: Acm+uWSO2sFWVqJtTSyZjWjNtPZ5IgAGopew From: "Giyeong Son" To: "Ralph Droms" , "Ted Lemon" X-OriginalArrivalTime: 16 Apr 2009 21:34:13.0575 (UTC) FILETIME=[162A3570:01C9BEDB] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Mon, 20 Apr 2009 08:18:13 -0700 Cc: mif , ietf@ietf.org, gen-art@ietf.org, dhc WG , Black_David@emc.com Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 21:33:02 -0000 Again as I mentioned, in order to prepare or build an efficient routing policy and to select an efficient connection/interface, it would be necessary to identify, classify and/or prioritize underlying network characteristics or information of the attached networks. In addition, as many network characteristics which are essential to be used for simultaneous use of multiple interfaces are not generic forms (e.g. SSID only for 802.11), these network characteristics may require a mechanism to make them be associated with generic (formed) elements used for routing policy preparation and routing decision. Therefore, if MIF can provide an efficient guideline or mechanism for associating, it would be really amazing. I believe, the current IP network related protocols and standardized technologies may not be enough to support that on multiple interface network environment. I think each vendor, carrier, service provider and/or technology, which utilizes or supports simultaneous use of multiple connections/interfaces, may have their own proprietary mechanism in terms of gathering of network characteristics of each interface/access network technology (e.g. WiFi, GPRS, CDMA, Bluetooth, etc.), their mapping mechanism with generic formed elements, routing policy and decision mechanisms with different IP based service networks owned by different service providers or different IP network enabling core networks owned by different carriers. So, the problem Ted and Ralph are addressing seems to be just one of issues (but only for WiFi network environments) in terms of network characteristic that may be necessary to be considered during selection of an efficient connection/interface from multiple candidates. Giyeong -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: April 16, 2009 1:32 PM To: Ted Lemon Cc: Giyeong Son; Hui Deng; dhc WG; gen-art@ietf.org; mif; ietf@ietf.org; Black_David@emc.com Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 Yup ... there is currently no way to provide authenticated, meaningful identification of the network(s) to which a host is attached. Without that identification, it's pretty hard to write any reasonable policies. - Ralph On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote: > On 2009/4/13 Ralph Droms wrote: >> For example, would a host process >> information received from a Starbucks network over its 802.11 >> interface differently from information received a home network over >> the 802.11 interface? > > It's even more fun than that. How do we reliably know that we are > at Starbucks, and not at home? The SSID? That's not an > authenticated token. Currently Windows makes security decisions > based on the SSID. You could call this the best answer they could > come up with for a problem with no good answers. Or you could say > that it instills the user with a false sense of security. Either > way, it's not something I'd be comfortable seeing in a protocol spec, > so if the client is in fact to make decisions as you've > suggested, we'd need a secure way of doing this. I don't know > enough about WPA Enterprise to know if there's a bidirectional > authentication going on there - from the UI perspective it looks like > it's one-way. > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From denghui02@gmail.com Mon Apr 20 08:22:00 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7453A6B2B; Mon, 20 Apr 2009 08:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vY2TJJyWhls8; Mon, 20 Apr 2009 08:21:59 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 988AF3A69CA; Mon, 20 Apr 2009 08:21:59 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2493318wfg.31 for ; Mon, 20 Apr 2009 08:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DECfqOUUGrMb7PjVXnj44n8Ay0Ik3RLI28xgN1GK6wI=; b=Uv5MGHurgIO4TV4b2IajRX967mg8ppxvFu5yHM4AbOrm5D6Enl/RJWpzKAIrin9JlY 79N7dwFX8HMe+aPoyAICX5d/++5iUdhA2zjMTaz1VrssAQv+b2z7/3cd6/KPdYAObgzr FnQIztMROdd+kB1ttFYKviJrVBQeiU5tQcpds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oEtj0ICWUIc/J/WOl8guh9d5pKZtXWx/vkQITiTTg9cudp/pYnAD4EfHgBbTKA3FXu m9DfTo4LeMDtOpbx+eZ8FL73bvriaBGGY1zBV8HKgyfJrBEIus0Ob8j8KdGIklMCky5V Db6ykixTWLEiC65B7QMGmCDEio8w7mEGbXLtc= MIME-Version: 1.0 Received: by 10.143.166.10 with SMTP id t10mr1348459wfo.239.1240240995501; Mon, 20 Apr 2009 08:23:15 -0700 (PDT) In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FCE3@XCH42YKF.rim.net> References: <9E06629B-2B0E-4AD3-BD5F-94F2C2192CAE@cisco.com> <777025D7F9E074449F3DAEB73C25690205F0FCE3@XCH42YKF.rim.net> Date: Mon, 20 Apr 2009 23:23:15 +0800 Message-ID: <1d38a3350904200823r2b7f43f8yc3316404061e3f6c@mail.gmail.com> From: Hui Deng To: Giyeong Son Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , ietf@ietf.org, gen-art@ietf.org, Ralph Droms , Ted Lemon , dhc WG , Black_David@emc.com Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 15:22:00 -0000 some level of generic network characteristics benefit for the user. one example could be that routing metric may need to be updated to align with various kind of access technologies. -Hui 2009/4/17 Giyeong Son : > Again as I mentioned, in order to prepare or build an efficient routing > policy and to select an efficient connection/interface, it would be > necessary to identify, classify and/or prioritize underlying network > characteristics or information of the attached networks. > > In addition, as many network characteristics which are essential to be > used for simultaneous use of multiple interfaces are not generic forms > (e.g. SSID only for 802.11), these network characteristics may require a > mechanism to make them be associated with generic (formed) elements used > for routing policy preparation and routing decision. Therefore, if MIF > can provide an efficient guideline or mechanism for associating, it > would be really amazing. > > I believe, the current IP network related protocols and standardized > technologies may not be enough to support that on multiple interface > network environment. > > I think each vendor, carrier, service provider and/or technology, which > utilizes or supports simultaneous use of multiple > connections/interfaces, may have their own proprietary mechanism in > terms of gathering of network characteristics of each interface/access > network technology (e.g. WiFi, GPRS, CDMA, Bluetooth, etc.), their > mapping mechanism with generic formed elements, routing policy and > decision mechanisms with different IP based service networks owned by > different service providers or different IP network enabling core > networks owned by different carriers. > > So, the problem Ted and Ralph are addressing seems to be just one of > issues (but only for WiFi network environments) in terms of network > characteristic that may be necessary to be considered during selection > of an efficient connection/interface from multiple candidates. > > Giyeong > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: April 16, 2009 1:32 PM > To: Ted Lemon > Cc: Giyeong Son; Hui Deng; dhc WG; gen-art@ietf.org; mif; ietf@ietf.org; > Black_David@emc.com > Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 > > Yup ... there is currently no way to provide authenticated, meaningful > identification of the network(s) to which a host is attached. =A0Without > that identification, it's pretty hard to write any reasonable policies. > > - Ralph > > On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote: > >> On 2009/4/13 Ralph Droms wrote: >>> For example, would a host process >>> information received from a Starbucks network over its 802.11 >>> interface differently from information received a home network over >>> the 802.11 interface? >> >> It's even more fun than that. =A0 How do we reliably know that we are >> at Starbucks, and not at home? =A0 The SSID? =A0 That's not an >> authenticated token. =A0 Currently Windows makes security decisions >> based on the SSID. =A0 You could call this the best answer they could >> come up with for a problem with no good answers. =A0 Or you could say >> that it instills the user with a false sense of security. =A0 Either >> way, it's not something I'd be comfortable seeing in a protocol spec, >> so if the client is in fact to make decisions as you've >> suggested, we'd need a secure way of doing this. =A0 I don't know >> enough about WPA Enterprise to know if there's a bidirectional >> authentication going on there - from the UI perspective it looks like >> it's one-way. >> > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > From denghui02@gmail.com Mon Apr 20 08:33:08 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8627B3A67F9; Mon, 20 Apr 2009 08:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGiWcovyZGXe; Mon, 20 Apr 2009 08:33:07 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id B0FD028C2CE; Mon, 20 Apr 2009 08:32:09 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2499398wfg.31 for ; Mon, 20 Apr 2009 08:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2/P827W161OyXLEETS+mj9vlQnTDqZiZ+fuwiu9Bcsw=; b=Dsw0R3gnD4Z1DazEPDRAEN6MaEWI8k+rL86p2/i/scmHD5FZtdybOkTBnMJKedazJQ twWNSHl1s3cxIUHoyfAo6q2MIrSOxFi1svFOBUyhVj+oZ3GXbmjEt6sI6lJH9yjUUzFa vTGpN6/mNNQBGYV3veIou7ZilOt3/KoVqT05s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iRbaokxJ+IQnHsuh1/NbXv3vPsM9PK3xM+cpfkKbYw5oVHBfP6a08TAU2OAEp14pBS F4cK2Dj+6uSVyRs26Y1e4SmEokxl2vHuYmXmVdJ08k0H4IXYF69ZHqY/fdh+8b7Cxk1R Js/srcLk48VFf/30AKfeExr8rjJQVY97PYvgM= MIME-Version: 1.0 Received: by 10.142.200.3 with SMTP id x3mr1378915wff.180.1240241605658; Mon, 20 Apr 2009 08:33:25 -0700 (PDT) In-Reply-To: References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> <1d38a3350904190746v577179d8u82123e5d889cffdc@mail.gmail.com> Date: Mon, 20 Apr 2009 23:33:25 +0800 Message-ID: <1d38a3350904200833h289197bese3c591ae15e7da53@mail.gmail.com> From: Hui Deng To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , "ietf@ietf.org" , Scott Brim , Ralph Droms , "gen-art@ietf.org" , dhc WG , "Black_David@emc.com" , Bernie Volz Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 15:33:08 -0000 >> And you talked about Stuart Cheshire described a couple of IETFs ago, >> Could you help to point out the link? > > Sadly, I don't have it, but I suspect Stuart does, and I'm pretty sure he= 's > reading this. Thanks, let's see whether he is going to talk here. > The gist of what he was saying is that if you have an IPv4 address that > looks okay, and an IPv6 address that looks okay, you can't assume that th= ey > *are* okay, because there may be no route to the global internet on eithe= r > your IPv4 or your IPv6 link. =A0 So you must attempt to use both addresse= s, > not just one, and you must do it at the same time. =A0 Whichever one answ= ers > first, you take. It means that the new IP model will try host's multiple connections each time as you suggested as well. > If you prefer either IPv4 or IPv6, and the transport you preferred happen= s > to be the one that was broken, a smart user will disable the one you've > preferred. =A0 That user will then advise his or her friends, for example= , > that "IPv6 creates instability, so you should disable it." =A0 This imped= es > deployment. > > The unattended multiple interface situation is quite similar. =A0 I think= the > attended case (a laptop with two or more network interfaces) is actually > better handled through user intervention, because the user has knowledge = of > the physical situation that would be difficult to communicate to the > computer. =A0 But in the unattended case, you can get into the same sort = of > "wrong learning" situation, where a smart but naive user who debugs a > network problem winds up learning a workaround that would impede > interoperability if everybody did it. Interesting thoughing, workaround will impede deployment. Thanks -Hui From gson@rim.com Mon Apr 20 08:34:36 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC503A6DE1; Mon, 20 Apr 2009 08:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xM52GCJ2djl; Mon, 20 Apr 2009 08:34:35 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 2888D3A6C54; Mon, 20 Apr 2009 08:34:34 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 2D0B158C4D; Mon, 20 Apr 2009 11:35:49 -0400 (EDT) X-AuditID: 0a401fcb-a41a8bb000002ba2-e8-49ec9654f65e Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id CF65A58C5C; Mon, 20 Apr 2009 11:35:48 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 20 Apr 2009 11:35:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Mon, 20 Apr 2009 11:35:14 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FD00@XCH42YKF.rim.net> In-Reply-To: <1d38a3350904190839p159daf72q8e6f5c7145536944@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Thread-Index: AcnBBRCUbueGuw0xRBGrTk31k03dzQAwRN/w From: "Giyeong Son" To: "Hui Deng" X-OriginalArrivalTime: 20 Apr 2009 15:35:48.0335 (UTC) FILETIME=[ADB1FFF0:01C9C1CD] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: mif , ietf@ietf.org, gen-art@ietf.org, Ralph Droms , Ted Lemon , dhc WG , Black_David@emc.com, Bernie Volz Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 15:34:37 -0000 You are right "money" is more operation related not technical side. However,= I believe that this is also one of the most important factors and popularly= has been used for determining an interface with an (access) network among m= ultiple active interfaces automatically and dynamically. And, the mechanism= to adopt or apply like this network characteristic into the routing policy= on the network environment of simultaneous use of multiple interfaces may b= e deeply related with technical side regarding simultaneous use of multiple= interfaces though. For instance, for a dual-mode device at home with WiFi and IP over cellular= available (e.g. CDMA, GPRS/EDGE, etc), combination of various network chara= cteristics in it would be the major factors to determine either WiFi or cell= ular for packet transmission. My point here is how to present those factors= into the routing policy in order to determine a suitable interface with the= type of *DATA or PACKET* for the transmission would be one of the importan= t technical side to be discussed in terms of simultaneous use of multiple in= terfaces. However, according to Hui, it seems to be out of MIF scope described in the= charter. BTW, again regarding MIF scope, I am wondering if we have already= gone through a scenario for simultaneous use of multiple active interfaces= based on a network environment with necessary associated network entities (= from enabling attachment of multiple access networks to processing a packet= transmission over the access networks from the link layer up to the transpo= rt layer) in order to identify the MIF scope (presented in the charter). If= it has been already done or everyone understands clearly in terms of the MI= F scope, it is OK. Otherwise, it would be good to practice it in order to cl= arify the MIF scope in the charter. Giyeong -----Original Message----- From: Hui Deng [mailto:denghui02@gmail.com] Sent: April 19, 2009 11:40 AM To: Giyeong Son Cc: Ted Lemon; Ralph Droms; mif; ietf@ietf.org; gen-art@ietf.org; dhc WG; Bl= ack_David@emc.com; Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Hi, Giyeong, At least those are not in the current charter scope. but Ted gave a one potential solution on one problem. Regarding to Money et al, I think IETF is not going to talk about it. which is more operational recommendation. Operation could recommend the benc= hmark to let the user to select what he favoriate by human language other th= an technical language. thanks -HUi 2009/4/15 Giyeong Son : > I think Ted pointed out very interesting but crucial problems if I > understood correctly. So, I'd like to confirm what Ted indicated and > emphasized: > > 1. How to dynamically/automatically/efficiently enable and manage > multiple active interfaces on a host? > 2. How to utilize multiple active interfaces on a host? > 2. What are the efficient (or cost-effective) routing decision policy? > Is it least cost routing policy? Or other? If it is least cost routing > policy, what are the costs? Are they "money" to use the connection (e.g. > WiFi vs. cellular), "time" to spend for the transmission, "reliability" > of the transmission, etc? > > If those are what Ted indicated, I am also interested in asking if the > above things are in scope of MIF. Based on my experience in terms of > simultaneous use of multiple interfaces, the aboves are the most > critical and interesting issues in practice in order to utilize the > network environment of simultaneous use of multiple interfaces > reliably and efficiently. > > > Giyeong > > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > Ted Lemon > Sent: April 14, 2009 5:48 PM > To: Ralph Droms > Cc: mif; ietf@ietf.org; Black_David@emc.com; dhc WG; gen-art@ietf.org; > Bernie Volz > Subject: Re: [mif] [dhcwg] Gen-ART review of > draft-ietf-dhc-container-00 > > On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: > >> Now, I admit I'm describing a hypothetical and abstract scenario. =A0I >> don't have a specific example of a situation in which a host might >> make decisions - either in the stack or in an application or ??? - >> about outbound traffic based on knowledge of how that traffic would >> be > >> forwarded by the RG. > > That's right. =A0 But I think it's not an accident that this is a > hypothetical scenario. =A0 In reality, a scenario like this has been > likely ever since wireless and wired network interfaces became > standard on laptops. =A0 And yet we don't have any real-life examples of > problems that this has caused, which need solving. =A0 To me, that seems > like an indication that this is not a real operational problem. =A0 That > is, that the answer "if two DHCP servers send the same client > conflicting information on two different interfaces, that is a > misconfiguration, and should be solved by correcting the > misconfiguration" is, in practice, the correct answer. > > If it were not, we would be hearing about concrete, real-world > scenarios of the type you describe, not about hypothetical ones. > > I don't mean to minimize this issue - if in fact there is some future > real-world scenario where this would be a serious problem, it would be > good if we could anticipate it. =A0 It might be profitable to consider > analogies. > > For instance, right now I have IPv6 set up at home. =A0 Because IPv6 > isn't deployed at all in Tucson, the way I have this working is by > tunneling. =A0 Since there are two tunnel brokers offering service for > people like me, and I am a bit adventurous, I have two tunnels. > Right now, every IPv6 packet I ever transmit goes out one of those > tunnels, with the exception of packets destined for a specific net, > for which I have defined a static route. > > First of all, this scenario works just fine. =A0 Both tunnels are > configured as a default route - it just happens that Linux's route > selection process always chooses the first one. =A0 This algorithm would > work poorly if one interface were preferable to the other, but since > both are equivalent it's not a problem. > > Second, though, why do I have a default route configured? =A0 It's > because I'm talking to a node on that network that will only answer if > I use the source address of one of the tunnels; and will ignore any > packets I send it with the other source address. =A0 So in the case > where there was a problem, I manually configured a workaround. > > How could we automatically solve this problem? =A0 Simple: any time we > are initiating communication with a device on the network, and do not > know that the communication is going to work, we simultaneously start > the communication in every plausible way. =A0 So suppose that there are > two AAAA records corresponding to the machine I want to talk to, and I > have two global IP addresses. =A0 I'm going to send four syn packets. > The first syn-ack I get back is the one I'm actually going to use - > I'll send RST packets to the other three. > > This is analogous to the solution Stuart Cheshire described a couple > of IETFs ago to the problem of IPv6 causing connectivity problems > instead of expanding connectivity opportunities - you can't prefer one > solution over the other, because you have no basis for doing so, so > you have to try all possible solutions and choose the one that works > best. =A0 My only extension, if it is one, is that I've added the source > address to the matrix - I'm not sure Stuart mentioned that. > > Now, how does this extend when we go to DHCP? =A0 Suppose I have DNS > resolver configurations from two DHCP servers. =A0 I try both in > parallel. =A0 I can winnow it down a bit: since I received the DNS > server information from one DHCP server on one interface, and the DNS > server information from the other DHCP server on a different > interface, I only have to try to query the DNS server using the source > addresses of the interface on which that DNS server's configuration > information was received. > > But how do I do that if the device that has two interfaces is not the > device originating the query, as is the case with the container > option? =A0 I think the answer is that I can't. =A0 There is no heuristic= > that I can define that will always make the right choice, because the > device receiving the container options has to make the choice for the > client. > > In DHCPv6, we could at least give the client a hint about what to do > as > follows: > > Suppose that I am dual-homed. =A0 I ask for, and get, a container option > on both outward-facing interfaces. =A0 I also wind up configuring one or > more prefixes as a result of my communication with the DHCPv6 server > on these two interfaces. =A0 I wind up advertising prefixes to the > client based on the answers that I get on both outward-facing > interfaces, so for example if I get a single prefix delegation from > each DHCPv6 server, I will advertise two prefixes to the client. =A0 So > when the client asks for, and gets, IA_ADDR configurations for both > prefixes, I include the container option information from each DHCPv6 > server in the IA_ADDR option for the prefix provided by that DHCPv6 > server. =A0 Now the client has enough information to make a choice - it > can use the source address for the prefix from a DHCP server to > communicate with the DNS servers provided by that DHCP server. > > But this requires a great deal of complexity on the client, and on the > server. =A0 Is this complexity that we want? =A0 And we haven't even > talked about the case where either due to cost considerations, or due > to speed considerations, one interface is preferable to the other. > How would we communicate that? =A0How would we configure that? > Supposing that one prefix is more expensive than another, does the > client then not try the expensive prefix until it's timed out on the > cheap prefix? =A0 What does that look like to the end-user? =A0 Does it > fail gracefully? > > So I think it's an interesting problem space. =A0 And actually I think > that you could come up with heuristics that would work most of the > time, potentially at the cost of increased load on name servers, and > increased network usage, and the occasional $1000 cellular data bill. =A0= > But to come up with heuristics that will work the right way every > time, I think that is very difficult. > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informatio= n. Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immedi= ately reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From volz@cisco.com Mon Apr 20 14:12:43 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D76F33A6E36 for ; Mon, 20 Apr 2009 14:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EV2FCgNzkut for ; Mon, 20 Apr 2009 14:12:43 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8B98028C0FF for ; Mon, 20 Apr 2009 14:12:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,219,1238976000"; d="scan'208";a="42278829" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Apr 2009 21:13:55 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3KLDteY022461; Mon, 20 Apr 2009 17:13:55 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3KLDtaY026863; Mon, 20 Apr 2009 21:13:55 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 17:13:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Apr 2009 17:13:53 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB210C519CB1@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <768A70B9-BB01-4BF9-8002-19CDDDDEE4FA@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] New dhc WG co-chair Thread-Index: Acm+t1iDInvI1kYDQgGQcyEwG7icFwDRYgdQ References: <768A70B9-BB01-4BF9-8002-19CDDDDEE4FA@nominum.com> From: "Bernie Volz (volz)" To: "Ted Lemon" X-OriginalArrivalTime: 20 Apr 2009 21:13:55.0171 (UTC) FILETIME=[E9978330:01C9C1FC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=605; t=1240262035; x=1241126035; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20New=20dhc=20WG=20co-chair |Sender:=20 |To:=20=22Ted=20Lemon=22=20; bh=RpSrYf/tCoVuZ80qX28oTWC/JmSO7rYxYHlK57I1OaY=; b=FI5Fcqju8R8CI9vDKnl+NGZXDnOdEIB/5uw1XMMXg7r4/NUKwdjl2PFJ4G fB7g93/8QwNIybvcvE0u03EuvfbGl7IWkv/2fc7NNELv6ZpsSZ4yBblKf8n8 nmveiHrrua; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: dhc WG Subject: Re: [dhcwg] New dhc WG co-chair X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 21:12:43 -0000 Congrats Ted! - Bernie=20 -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, April 16, 2009 1:18 PM To: Ralph Droms (rdroms) Cc: dhc WG; The IESG Subject: Re: [dhcwg] New dhc WG co-chair On Apr 16, 2009, at 4:39 AM, Ralph Droms wrote: > I'll speak for Jari and the WG in saying that we're all looking =20 > forward to > working with you. I'm looking forward to it too. :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Apr 20 14:22:08 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590513A6FDD for ; Mon, 20 Apr 2009 14:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIifQxZJ1by7 for ; Mon, 20 Apr 2009 14:22:07 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 708AF3A695C for ; Mon, 20 Apr 2009 14:21:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,219,1238976000"; d="scan'208";a="289647684" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Apr 2009 21:22:56 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3KLMuIo018986; Mon, 20 Apr 2009 14:22:56 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3KLMsJS021337; Mon, 20 Apr 2009 21:22:56 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 17:22:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Apr 2009 17:22:54 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB210C519CBD@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <003401c9c170$492fff30$db8ffd90$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] RAAN & SRSN drafts Thread-Index: AcnBcEcmFtfRk17ORDew33wUI8blEwAjK/iQ References: <003401c9c170$492fff30$db8ffd90$@net> From: "Bernie Volz (volz)" To: "Glen Zorn" , "Dhcwg WG" X-OriginalArrivalTime: 20 Apr 2009 21:22:55.0479 (UTC) FILETIME=[2BA3F870:01C9C1FE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1495; t=1240262576; x=1241126576; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20RAAN=20&=20SRSN=20drafts |Sender:=20; bh=LvBPhC7Ey9WQwnPYInp2euGiD+7fGCJQ126BW0jwNRw=; b=tIEVqxvabuJC9sDugQ6mWYjxTtrtG6mSSm+9o5Cvt67gF087P415b2kW8t 9mQrye+ENa9LYoXm+GV7jWWnLOlJBAj8KynRLn13jpzNHchpnWfGnf88xGU5 PFTwQcf8Rl; Authentication-Results: sj-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [dhcwg] RAAN & SRSN drafts X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 21:22:08 -0000 I do think they should be. Ralph and I just re-spun the ones that had expired a while back without making any major changes. While I like the idea of avoiding layer violations which was, at least in my mind, the strongest motivation for RAAN (and thus SRSN), I'm not so sure that this now is a strong enough argument to proceed with RAAN/SRSN because there are already DHCPv6 relay agents that do the layer violations as they had no choice. SRSN might be useful for more than just RAAN (as it provides the 'ordering' data that is missing from DHCPv6 response flows over UDP from the server). But we don't have any applications at present except for RAAN. - Bernie=20 -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Glen Zorn Sent: Monday, April 20, 2009 12:27 AM To: 'Dhcwg WG' Subject: [dhcwg] RAAN & SRSN drafts Is there some reason of which I am unaware that these two documents should not be combined? ~gwz At one time in the US, in the mid-nineteenth century, working for wage labor was considered not very different from chattel slavery...anyone who thinks it's legitimate to be a wage laborer is internalizing oppression in a way which would have seemed intolerable to people in the mills 150 years ago. -- Noam Chomsky, "Propaganda & the Public Mind" _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From gwz@net-zen.net Mon Apr 20 21:48:50 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0029C3A6BB8 for ; Mon, 20 Apr 2009 21:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdPW+JJ-M6IU for ; Mon, 20 Apr 2009 21:48:49 -0700 (PDT) Received: from smtpauth21.prod.mesa1.secureserver.net (smtpauth21.prod.mesa1.secureserver.net [64.202.165.38]) by core3.amsl.com (Postfix) with SMTP id D4C283A6A41 for ; Mon, 20 Apr 2009 21:48:48 -0700 (PDT) Received: (qmail 6766 invoked from network); 21 Apr 2009 04:50:04 -0000 Received: from unknown (124.120.231.79) by smtpauth21.prod.mesa1.secureserver.net (64.202.165.38) with ESMTP; 21 Apr 2009 04:50:03 -0000 From: "Glen Zorn" To: "'Bernie Volz \(volz\)'" References: <003401c9c170$492fff30$db8ffd90$@net> <8E296595B6471A4689555D5D725EBB210C519CBD@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB210C519CBD@xmb-rtp-20a.amer.cisco.com> Date: Tue, 21 Apr 2009 11:49:50 +0700 Organization: Network Zen Message-ID: <00ba01c9c23c$9cf50760$d6df1620$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnBcEcmFtfRk17ORDew33wUI8blEwAjK/iQAA/Rr7A= Content-Language: en-us Cc: 'Dhcwg WG' Subject: Re: [dhcwg] RAAN & SRSN drafts X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 04:48:50 -0000 Bernie Volz (volz) [mailto:volz@cisco.com] writes: > I do think they should be. Ralph and I just re-spun the ones that had > expired a while back without making any major changes. > > While I like the idea of avoiding layer violations which was, at least > in my mind, the strongest motivation for RAAN (and thus SRSN), I'm not > so sure that this now is a strong enough argument to proceed with > RAAN/SRSN because there are already DHCPv6 relay agents that do the > layer violations as they had no choice. Be that as it may, it's nice to have a clean way to do things. > > SRSN might be useful for more than just RAAN (as it provides the > 'ordering' data that is missing from DHCPv6 response flows over UDP > from > the server). True, but other documents can still reference the definition, right? That idea was why I didn't suggest pushing everything into one option... ... From denghui02@gmail.com Tue Apr 21 03:33:02 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D293A6FF9; Tue, 21 Apr 2009 03:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMvXaUx+Rb12; Tue, 21 Apr 2009 03:33:01 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id EDC873A69CC; Tue, 21 Apr 2009 03:33:00 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so3035973wfg.31 for ; Tue, 21 Apr 2009 03:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=G/TWc4d4agRu/RCJ6W0F0RdoUy10d9kicMDQnpWr39I=; b=Cw9icViYPJG9lzrA3MYwxPL5JgUjI4UXwXrxQF8RL8mGYl4/V4jAHdLi5Tci9+GlHj vvTFqCSUEmciitZLKJkje1Od/JJYf4+wD58FuG864B/i2hyyH6L+6ODk0X6lCmOvRUCc LyfPCwLDob0qe+bsnoC8l3tSivyaEEKp2GrvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=N9hTHPTOeZvJbj6Sq9+f/iHGXy/UuzHML5C0zxLiZCLd2k0GlCC7MW94xY9+hI0k9A BYg0WIzvVTZK6de/8bTeMceRWjkiV0diII2TtyWf6Lik8G9CgNVrSyBWYe4gJRessC5P Bmxr+LRRqmU5t/TOvynXYreKIchfU2q3J1ILQ= MIME-Version: 1.0 Received: by 10.142.237.19 with SMTP id k19mr4766038wfh.209.1240310057228; Tue, 21 Apr 2009 03:34:17 -0700 (PDT) In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FD00@XCH42YKF.rim.net> References: <1d38a3350904190839p159daf72q8e6f5c7145536944@mail.gmail.com> <777025D7F9E074449F3DAEB73C25690205F0FD00@XCH42YKF.rim.net> Date: Tue, 21 Apr 2009 18:34:17 +0800 Message-ID: <1d38a3350904210334g294b86ecn73c3219e381c421b@mail.gmail.com> From: Hui Deng To: Giyeong Son Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , ietf@ietf.org, gen-art@ietf.org, Ralph Droms , Ted Lemon , dhc WG , Black_David@emc.com, Bernie Volz Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 10:33:02 -0000 > You are right "money" is more operation related not technical side. Howev= er, I believe that this is also one of the most important factors and popul= arly has been used for determining an interface with an (access) network am= ong multiple active interfaces automatically and dynamically. And, the mech= anism to adopt or apply like this network characteristic into the routing p= olicy on the network environment of simultaneous use of multiple interfaces= may be deeply related with technical side regarding simultaneous use of mu= ltiple interfaces though. =3D=3D> such network characteristic could become a generic routing element which do decide whether to use this routing or interface or not, but IETF not necessraily mention it is "Money" or else. and also if it is not "flat rate" based, I guess that host will be not so suffcient intelligent to lead the routing based on the price like pennys or dollars. > > For instance, for a dual-mode device at home with WiFi and IP over cellul= ar available (e.g. CDMA, GPRS/EDGE, etc), combination of various network ch= aracteristics in it would be the major factors to determine either WiFi or = cellular for packet transmission. My point here is how to present those fac= tors into the routing policy in order to determine a suitable interface wit= h the type of *DATA or PACKET* for the transmission would be one of =A0the = important technical side to be discussed in terms of simultaneous use of mu= ltiple interfaces. =3D=3D> Reply same as the above > > However, according to Hui, it seems to be out of MIF scope described in t= he charter. BTW, again regarding MIF scope, I am wondering if we have alrea= dy gone through a scenario for simultaneous use of multiple active interfac= es based on a network environment with necessary associated network entitie= s (from enabling attachment of multiple access networks to processing a pac= ket transmission over the access networks from the link layer up to the tra= nsport layer) in order to identify the MIF scope (presented in the charter)= . If it has been already done or everyone understands clearly in terms of t= he MIF scope, it is OK. Otherwise, it would be good to practice it in order= to clarify the MIF scope in the charter. =3D=3D> Current charter says best current practice, and problems tatement, those work will be done after the re-charter. thanks -Hui > > > Giyeong > > -----Original Message----- > From: Hui Deng [mailto:denghui02@gmail.com] > Sent: April 19, 2009 11:40 AM > To: Giyeong Son > Cc: Ted Lemon; Ralph Droms; mif; ietf@ietf.org; gen-art@ietf.org; dhc WG;= Black_David@emc.com; Bernie Volz > Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 > > Hi, Giyeong, > > At least those are not in the current charter scope. > but Ted gave a one potential solution on one problem. > > Regarding to Money et al, I think IETF is not going to talk about it. > which is more operational recommendation. Operation could recommend the b= enchmark to let the user to select what he favoriate by human language othe= r than technical language. > > thanks > > -HUi > > 2009/4/15 Giyeong Son : >> I think Ted pointed out very interesting but crucial problems if I >> understood correctly. So, I'd like to confirm what Ted indicated and >> emphasized: >> >> 1. How to dynamically/automatically/efficiently enable and manage >> multiple active interfaces on a host? >> 2. How to utilize multiple active interfaces on a host? >> 2. What are the efficient (or cost-effective) routing decision policy? >> Is it least cost routing policy? Or other? If it is least cost routing >> policy, what are the costs? Are they "money" to use the connection (e.g. >> WiFi vs. cellular), "time" to spend for the transmission, "reliability" >> of the transmission, etc? >> >> If those are what Ted indicated, I am also interested in asking if the >> above things are in scope of MIF. Based on my experience in terms of >> simultaneous use of multiple interfaces, the aboves are the most >> critical and interesting issues in practice in order to utilize the >> network environment of simultaneous use of multiple interfaces >> reliably and efficiently. >> >> >> Giyeong >> >> -----Original Message----- >> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of >> Ted Lemon >> Sent: April 14, 2009 5:48 PM >> To: Ralph Droms >> Cc: mif; ietf@ietf.org; Black_David@emc.com; dhc WG; gen-art@ietf.org; >> Bernie Volz >> Subject: Re: [mif] [dhcwg] Gen-ART review of >> draft-ietf-dhc-container-00 >> >> On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: >> >>> Now, I admit I'm describing a hypothetical and abstract scenario. =A0I >>> don't have a specific example of a situation in which a host might >>> make decisions - either in the stack or in an application or ??? - >>> about outbound traffic based on knowledge of how that traffic would >>> be >> >>> forwarded by the RG. >> >> That's right. =A0 But I think it's not an accident that this is a >> hypothetical scenario. =A0 In reality, a scenario like this has been >> likely ever since wireless and wired network interfaces became >> standard on laptops. =A0 And yet we don't have any real-life examples of >> problems that this has caused, which need solving. =A0 To me, that seems >> like an indication that this is not a real operational problem. =A0 That >> is, that the answer "if two DHCP servers send the same client >> conflicting information on two different interfaces, that is a >> misconfiguration, and should be solved by correcting the >> misconfiguration" is, in practice, the correct answer. >> >> If it were not, we would be hearing about concrete, real-world >> scenarios of the type you describe, not about hypothetical ones. >> >> I don't mean to minimize this issue - if in fact there is some future >> real-world scenario where this would be a serious problem, it would be >> good if we could anticipate it. =A0 It might be profitable to consider >> analogies. >> >> For instance, right now I have IPv6 set up at home. =A0 Because IPv6 >> isn't deployed at all in Tucson, the way I have this working is by >> tunneling. =A0 Since there are two tunnel brokers offering service for >> people like me, and I am a bit adventurous, I have two tunnels. >> Right now, every IPv6 packet I ever transmit goes out one of those >> tunnels, with the exception of packets destined for a specific net, >> for which I have defined a static route. >> >> First of all, this scenario works just fine. =A0 Both tunnels are >> configured as a default route - it just happens that Linux's route >> selection process always chooses the first one. =A0 This algorithm would >> work poorly if one interface were preferable to the other, but since >> both are equivalent it's not a problem. >> >> Second, though, why do I have a default route configured? =A0 It's >> because I'm talking to a node on that network that will only answer if >> I use the source address of one of the tunnels; and will ignore any >> packets I send it with the other source address. =A0 So in the case >> where there was a problem, I manually configured a workaround. >> >> How could we automatically solve this problem? =A0 Simple: any time we >> are initiating communication with a device on the network, and do not >> know that the communication is going to work, we simultaneously start >> the communication in every plausible way. =A0 So suppose that there are >> two AAAA records corresponding to the machine I want to talk to, and I >> have two global IP addresses. =A0 I'm going to send four syn packets. >> The first syn-ack I get back is the one I'm actually going to use - >> I'll send RST packets to the other three. >> >> This is analogous to the solution Stuart Cheshire described a couple >> of IETFs ago to the problem of IPv6 causing connectivity problems >> instead of expanding connectivity opportunities - you can't prefer one >> solution over the other, because you have no basis for doing so, so >> you have to try all possible solutions and choose the one that works >> best. =A0 My only extension, if it is one, is that I've added the source >> address to the matrix - I'm not sure Stuart mentioned that. >> >> Now, how does this extend when we go to DHCP? =A0 Suppose I have DNS >> resolver configurations from two DHCP servers. =A0 I try both in >> parallel. =A0 I can winnow it down a bit: since I received the DNS >> server information from one DHCP server on one interface, and the DNS >> server information from the other DHCP server on a different >> interface, I only have to try to query the DNS server using the source >> addresses of the interface on which that DNS server's configuration >> information was received. >> >> But how do I do that if the device that has two interfaces is not the >> device originating the query, as is the case with the container >> option? =A0 I think the answer is that I can't. =A0 There is no heuristi= c >> that I can define that will always make the right choice, because the >> device receiving the container options has to make the choice for the >> client. >> >> In DHCPv6, we could at least give the client a hint about what to do >> as >> follows: >> >> Suppose that I am dual-homed. =A0 I ask for, and get, a container option >> on both outward-facing interfaces. =A0 I also wind up configuring one or >> more prefixes as a result of my communication with the DHCPv6 server >> on these two interfaces. =A0 I wind up advertising prefixes to the >> client based on the answers that I get on both outward-facing >> interfaces, so for example if I get a single prefix delegation from >> each DHCPv6 server, I will advertise two prefixes to the client. =A0 So >> when the client asks for, and gets, IA_ADDR configurations for both >> prefixes, I include the container option information from each DHCPv6 >> server in the IA_ADDR option for the prefix provided by that DHCPv6 >> server. =A0 Now the client has enough information to make a choice - it >> can use the source address for the prefix from a DHCP server to >> communicate with the DNS servers provided by that DHCP server. >> >> But this requires a great deal of complexity on the client, and on the >> server. =A0 Is this complexity that we want? =A0 And we haven't even >> talked about the case where either due to cost considerations, or due >> to speed considerations, one interface is preferable to the other. >> How would we communicate that? =A0How would we configure that? >> Supposing that one prefix is more expensive than another, does the >> client then not try the expensive prefix until it's timed out on the >> cheap prefix? =A0 What does that look like to the end-user? =A0 Does it >> fail gracefully? >> >> So I think it's an interesting problem space. =A0 And actually I think >> that you could come up with heuristics that would work most of the >> time, potentially at the cost of increased load on name servers, and >> increased network usage, and the occasional $1000 cellular data bill. >> But to come up with heuristics that will work the right way every >> time, I think that is very difficult. >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential i= nformation, privileged material (including material protected by the solici= tor-client or other applicable privileges), or constitute non-public inform= ation. Any use of this information by anyone other than the intended recipi= ent is prohibited. If you have received this transmission in error, please = immediately reply to the sender and delete this information from your syste= m. Use, dissemination, distribution, or reproduction of this transmission b= y unintended recipients is not authorized and may be unlawful. >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > From gson@rim.com Tue Apr 21 06:47:24 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5972C3A6A9A; Tue, 21 Apr 2009 06:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7i6udYeaafEW; Tue, 21 Apr 2009 06:47:22 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 0FA1F3A6A24; Tue, 21 Apr 2009 06:47:18 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id D0CBF58C66; Tue, 21 Apr 2009 09:48:33 -0400 (EDT) X-AuditID: 0a401fcb-ac1b8bb000002ba2-db-49edceb14351 Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id 4F5765891F; Tue, 21 Apr 2009 09:48:33 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Apr 2009 09:48:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Tue, 21 Apr 2009 09:48:12 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FD16@XCH42YKF.rim.net> In-Reply-To: <1d38a3350904210334g294b86ecn73c3219e381c421b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Thread-Index: AcnCbLpRiSXINiDOQlKWk93mhlk5aQAGlFzw From: "Giyeong Son" To: "Hui Deng" X-OriginalArrivalTime: 21 Apr 2009 13:48:13.0034 (UTC) FILETIME=[D072FCA0:01C9C287] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: mif , ietf@ietf.org, gen-art@ietf.org, Ralph Droms , Ted Lemon , dhc WG , Black_David@emc.com, Bernie Volz Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 13:47:24 -0000 My comment with "Giyeong>>" Giyeong -----Original Message----- From: Hui Deng [mailto:denghui02@gmail.com] Sent: April 21, 2009 6:34 AM To: Giyeong Son Cc: Ted Lemon; Ralph Droms; mif; ietf@ietf.org; gen-art@ietf.org; dhc WG; Bl= ack_David@emc.com; Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 > You are right "money" is more operation related not technical side. Howeve= r, I believe that this is also one of the most important factors and popular= ly has been used for determining an interface with an (access) network among= multiple active interfaces automatically and dynamically. And, the mechanis= m to adopt or apply like this network characteristic into the routing policy= on the network environment of simultaneous use of multiple interfaces may b= e deeply related with technical side regarding simultaneous use of multiple= interfaces though. =3D=3D> such network characteristic could become a generic routing element w= hich do decide whether to use this routing or interface or not, but IETF not= necessraily mention it is "Money" or else. and also if it is not "flat rate= " based, I guess that host will be not so suffcient intelligent to lead the= routing based on the price like pennys or dollars. Giyeong>> I agree. It does not need to *explicitly* indicate or utilize "Mon= ey" in IETF. But, as you mentioned, it would be better to provide a recommen= dation to provide the way or mechanism to present that kind of network chara= cteristics to be mapped to generic elements by MIF or other working group in= order to decide routing. > > For instance, for a dual-mode device at home with WiFi and IP over cellula= r available (e.g. CDMA, GPRS/EDGE, etc), combination of various network char= acteristics in it would be the major factors to determine either WiFi or cel= lular for packet transmission. My point here is how to present those factors= into the routing policy in order to determine a suitable interface with the= type of *DATA or PACKET* for the transmission would be one of =A0the import= ant technical side to be discussed in terms of simultaneous use of multiple= interfaces. =3D=3D> Reply same as the above > > However, according to Hui, it seems to be out of MIF scope described in th= e charter. BTW, again regarding MIF scope, I am wondering if we have already= gone through a scenario for simultaneous use of multiple active interfaces= based on a network environment with necessary associated network entities (= from enabling attachment of multiple access networks to processing a packet= transmission over the access networks from the link layer up to the transpo= rt layer) in order to identify the MIF scope (presented in the charter). If= it has been already done or everyone understands clearly in terms of the MI= F scope, it is OK. Otherwise, it would be good to practice it in order to cl= arify the MIF scope in the charter. =3D=3D> Current charter says best current practice, and problems tatement, t= hose work will be done after the re-charter. thanks -Hui > > > Giyeong > > -----Original Message----- > From: Hui Deng [mailto:denghui02@gmail.com] > Sent: April 19, 2009 11:40 AM > To: Giyeong Son > Cc: Ted Lemon; Ralph Droms; mif; ietf@ietf.org; gen-art@ietf.org; dhc > WG; Black_David@emc.com; Bernie Volz > Subject: Re: [mif] [dhcwg] Gen-ART review of > draft-ietf-dhc-container-00 > > Hi, Giyeong, > > At least those are not in the current charter scope. > but Ted gave a one potential solution on one problem. > > Regarding to Money et al, I think IETF is not going to talk about it. > which is more operational recommendation. Operation could recommend the be= nchmark to let the user to select what he favoriate by human language other= than technical language. > > thanks > > -HUi > > 2009/4/15 Giyeong Son : >> I think Ted pointed out very interesting but crucial problems if I >> understood correctly. So, I'd like to confirm what Ted indicated and >> emphasized: >> >> 1. How to dynamically/automatically/efficiently enable and manage >> multiple active interfaces on a host? >> 2. How to utilize multiple active interfaces on a host? >> 2. What are the efficient (or cost-effective) routing decision policy? >> Is it least cost routing policy? Or other? If it is least cost >> routing policy, what are the costs? Are they "money" to use the connectio= n (e.g. >> WiFi vs. cellular), "time" to spend for the transmission, "reliability" >> of the transmission, etc? >> >> If those are what Ted indicated, I am also interested in asking if >> the above things are in scope of MIF. Based on my experience in terms >> of simultaneous use of multiple interfaces, the aboves are the most >> critical and interesting issues in practice in order to utilize the >> network environment of simultaneous use of multiple interfaces >> reliably and efficiently. >> >> >> Giyeong >> >> -----Original Message----- >> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of >> Ted Lemon >> Sent: April 14, 2009 5:48 PM >> To: Ralph Droms >> Cc: mif; ietf@ietf.org; Black_David@emc.com; dhc WG; >> gen-art@ietf.org; Bernie Volz >> Subject: Re: [mif] [dhcwg] Gen-ART review of >> draft-ietf-dhc-container-00 >> >> On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: >> >>> Now, I admit I'm describing a hypothetical and abstract scenario. =A0I >>> don't have a specific example of a situation in which a host might >>> make decisions - either in the stack or in an application or ??? - >>> about outbound traffic based on knowledge of how that traffic would >>> be >> >>> forwarded by the RG. >> >> That's right. =A0 But I think it's not an accident that this is a >> hypothetical scenario. =A0 In reality, a scenario like this has been >> likely ever since wireless and wired network interfaces became >> standard on laptops. =A0 And yet we don't have any real-life examples >> of problems that this has caused, which need solving. =A0 To me, that >> seems like an indication that this is not a real operational problem. =A0= >> That is, that the answer "if two DHCP servers send the same client >> conflicting information on two different interfaces, that is a >> misconfiguration, and should be solved by correcting the >> misconfiguration" is, in practice, the correct answer. >> >> If it were not, we would be hearing about concrete, real-world >> scenarios of the type you describe, not about hypothetical ones. >> >> I don't mean to minimize this issue - if in fact there is some future >> real-world scenario where this would be a serious problem, it would >> be good if we could anticipate it. =A0 It might be profitable to >> consider analogies. >> >> For instance, right now I have IPv6 set up at home. =A0 Because IPv6 >> isn't deployed at all in Tucson, the way I have this working is by >> tunneling. =A0 Since there are two tunnel brokers offering service for >> people like me, and I am a bit adventurous, I have two tunnels. >> Right now, every IPv6 packet I ever transmit goes out one of those >> tunnels, with the exception of packets destined for a specific net, >> for which I have defined a static route. >> >> First of all, this scenario works just fine. =A0 Both tunnels are >> configured as a default route - it just happens that Linux's route >> selection process always chooses the first one. =A0 This algorithm >> would work poorly if one interface were preferable to the other, but >> since both are equivalent it's not a problem. >> >> Second, though, why do I have a default route configured? =A0 It's >> because I'm talking to a node on that network that will only answer >> if I use the source address of one of the tunnels; and will ignore >> any packets I send it with the other source address. =A0 So in the case >> where there was a problem, I manually configured a workaround. >> >> How could we automatically solve this problem? =A0 Simple: any time we >> are initiating communication with a device on the network, and do not >> know that the communication is going to work, we simultaneously start >> the communication in every plausible way. =A0 So suppose that there are >> two AAAA records corresponding to the machine I want to talk to, and >> I have two global IP addresses. =A0 I'm going to send four syn packets. >> The first syn-ack I get back is the one I'm actually going to use - >> I'll send RST packets to the other three. >> >> This is analogous to the solution Stuart Cheshire described a couple >> of IETFs ago to the problem of IPv6 causing connectivity problems >> instead of expanding connectivity opportunities - you can't prefer >> one solution over the other, because you have no basis for doing so, >> so you have to try all possible solutions and choose the one that >> works best. =A0 My only extension, if it is one, is that I've added the >> source address to the matrix - I'm not sure Stuart mentioned that. >> >> Now, how does this extend when we go to DHCP? =A0 Suppose I have DNS >> resolver configurations from two DHCP servers. =A0 I try both in >> parallel. =A0 I can winnow it down a bit: since I received the DNS >> server information from one DHCP server on one interface, and the DNS >> server information from the other DHCP server on a different >> interface, I only have to try to query the DNS server using the >> source addresses of the interface on which that DNS server's >> configuration information was received. >> >> But how do I do that if the device that has two interfaces is not the >> device originating the query, as is the case with the container >> option? =A0 I think the answer is that I can't. =A0 There is no heuristic= >> that I can define that will always make the right choice, because the >> device receiving the container options has to make the choice for the >> client. >> >> In DHCPv6, we could at least give the client a hint about what to do >> as >> follows: >> >> Suppose that I am dual-homed. =A0 I ask for, and get, a container >> option on both outward-facing interfaces. =A0 I also wind up >> configuring one or more prefixes as a result of my communication with >> the DHCPv6 server on these two interfaces. =A0 I wind up advertising >> prefixes to the client based on the answers that I get on both >> outward-facing interfaces, so for example if I get a single prefix >> delegation from each DHCPv6 server, I will advertise two prefixes to >> the client. =A0 So when the client asks for, and gets, IA_ADDR >> configurations for both prefixes, I include the container option >> information from each DHCPv6 server in the IA_ADDR option for the >> prefix provided by that DHCPv6 server. =A0 Now the client has enough >> information to make a choice - it can use the source address for the >> prefix from a DHCP server to communicate with the DNS servers provided by= that DHCP server. >> >> But this requires a great deal of complexity on the client, and on >> the server. =A0 Is this complexity that we want? =A0 And we haven't even= >> talked about the case where either due to cost considerations, or due >> to speed considerations, one interface is preferable to the other. >> How would we communicate that? =A0How would we configure that? >> Supposing that one prefix is more expensive than another, does the >> client then not try the expensive prefix until it's timed out on the >> cheap prefix? =A0 What does that look like to the end-user? =A0 Does it >> fail gracefully? >> >> So I think it's an interesting problem space. =A0 And actually I think >> that you could come up with heuristics that would work most of the >> time, potentially at the cost of increased load on name servers, and >> increased network usage, and the occasional $1000 cellular data bill. >> But to come up with heuristics that will work the right way every >> time, I think that is very difficult. >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicito= r-client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imme= diately reply to the sender and delete this information from your system. Us= e, dissemination, distribution, or reproduction of this transmission by unin= tended recipients is not authorized and may be unlawful. >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informatio= n. Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immedi= ately reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From root@core3.amsl.com Tue Apr 21 13:30:01 2009 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9448828C312; Tue, 21 Apr 2009 13:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090421203001.9448828C312@core3.amsl.com> Date: Tue, 21 Apr 2009 13:30:01 -0700 (PDT) Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-l2ra-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 20:30:01 -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 : Layer 2 Relay Agent Information Author(s) : B. Joshi, P. Kurapati Filename : draft-ietf-dhc-l2ra-04.txt Pages : 18 Date : 2009-4-21 In some networks, DHCP servers rely on Relay Agent Information option appended by Relay Agents for IP address and other parameter assignment policies. This works fine when end hosts are directly connected to Relay Agents. In some network configurations, one or more Layer 2 devices may reside between DHCP clients and Relay agent. In these network scenarios, it is difficult to use the Relay Agent Information option for IP address and other parameter assignment policies effectively. So there is a need for the device that is closest to the end hosts to append a Relay Agent Information option in DHCP messages. These devices are typically known as Layer 2 Relay Agents. This document aims to describe the network scenarios where a Layer 2 Relay Agent is in use and also how it handles DHCP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-l2ra-04.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-l2ra-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-4-21132510.I-D@ietf.org> --NextPart-- From bharat_joshi@infosys.com Tue Apr 21 18:14:02 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C834C3A6AF7 for ; Tue, 21 Apr 2009 18:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTOwnmEk17P7 for ; Tue, 21 Apr 2009 18:14:02 -0700 (PDT) Received: from kecgate06.infosys.com (kecgate06.infosysconsulting.com [61.95.162.82]) by core3.amsl.com (Postfix) with ESMTP id 4B95528C25B for ; Tue, 21 Apr 2009 18:14:01 -0700 (PDT) X-TM-IMSS-Message-ID: Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by kecgate06.infosys.com ([61.95.162.82]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS: TLSv1/SSLv3,128bits,RC4-MD5) id ade76fc400027eeb ; Wed, 22 Apr 2009 06:45:46 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub01.ad.infosys.com ([10.66.236.41]) with mapi; Wed, 22 Apr 2009 06:45:14 +0530 From: Bharat Joshi To: "dhcwg@ietf.org" Date: Wed, 22 Apr 2009 06:43:56 +0530 Thread-Topic: Layer 2 Relay Agent Information draft Thread-Index: AQHJwufKiYx1YRnTAkSuqiNzDSD99A== Message-ID: <31D55C4D55BEED48A4459EB64567589A0E857E6A43@BLRKECMBX02.ad.infosys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] Layer 2 Relay Agent Information draft X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 01:14:02 -0000 Hi=20All, =20=20=20=20=20=20=20We=20have=20published=20version=2004=20of=20Layer=20= 2=20Relay=20Agent=20Information=20draft.=20This=20version=20addresses=20s= everal=20editorial=20comments=20provided=20by=20Alfred. =20=20=20=20=20=20=20Draft=20is=20available=20at=20http://www.ietf.org/in= ternet-drafts/draft-ietf-dhc-l2ra-04.txt Thanks, Bharat ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From swb@employees.org Mon Apr 20 13:57:20 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 303013A6B03; Mon, 20 Apr 2009 13:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssLCJVkFBro2; Mon, 20 Apr 2009 13:57:19 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C56093A6AFD; Mon, 20 Apr 2009 13:57:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,219,1238976000"; d="scan'208";a="42277735" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Apr 2009 20:58:34 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3KKwYGg014873; Mon, 20 Apr 2009 16:58:34 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3KKwYI6021964; Mon, 20 Apr 2009 20:58:34 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 16:58:34 -0400 Received: from cisco.com ([10.86.249.78]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 16:58:33 -0400 Date: Mon, 20 Apr 2009 16:58:26 -0400 From: Scott Brim To: Giyeong Son Message-ID: <20090420205826.GJ34560@cisco.com> Mail-Followup-To: Scott Brim , Giyeong Son , Hui Deng , mif , ietf@ietf.org, gen-art@ietf.org, Ralph Droms , Ted Lemon , dhc WG , Black_David@emc.com, Bernie Volz References: <1d38a3350904190839p159daf72q8e6f5c7145536944@mail.gmail.com> <777025D7F9E074449F3DAEB73C25690205F0FD00@XCH42YKF.rim.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FD00@XCH42YKF.rim.net> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 20 Apr 2009 20:58:33.0478 (UTC) FILETIME=[C4385260:01C9C1FA] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral X-Mailman-Approved-At: Wed, 22 Apr 2009 08:01:51 -0700 Cc: mif , ietf@ietf.org, gen-art@ietf.org, Ralph Droms , Ted Lemon , dhc WG , Black_David@emc.com, Bernie Volz Subject: Re: [dhcwg] [Gen-art] [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 20:57:20 -0000 Excerpts from Giyeong Son on Mon, Apr 20, 2009 11:35:14AM -0400: > For instance, for a dual-mode device at home with WiFi and IP over > cellular available (e.g. CDMA, GPRS/EDGE, etc), combination of > various network characteristics in it would be the major factors to > determine either WiFi or cellular for packet transmission. My point > here is how to present those factors into the routing policy in > order to determine a suitable interface with the type of *DATA or > PACKET* for the transmission would be one of the important > technical side to be discussed in terms of simultaneous use of > multiple interfaces. I think it's partially in scope. I think of MIF as figuring out how to resolve conflicts or gaps in information and storing information in a way that it can be useful to forwarding. It does not cover how forwarding would actually use that information. From denghui02@gmail.com Wed Apr 22 09:30:11 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE92828C24C for ; Wed, 22 Apr 2009 09:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VNSGzVK7LtJ for ; Wed, 22 Apr 2009 09:30:11 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id 0BC4B3A6927 for ; Wed, 22 Apr 2009 09:29:54 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so40581rvb.49 for ; Wed, 22 Apr 2009 09:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=ueErw6Bbk2Dv++hQ7zwCPduDZ1xcQ81VQXefuJkDAPc=; b=qukSAIFXQ1oVy1K1gtVEaNdrpaa1I7OXt/rb6aABZaFrmMjvwVASoEXgz7beURTe0O jgca4bav8UYMBsEQKLeXe18suuRMHaI8tiobOw93edpsMRWF1DUEWm4zMyjFcUZ7IhYq LSogLXyPrZDXvsd1ni02tiX7oBeTDvxyfs5Tc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=ORfnBlevc/oUT44I1h1Xahr4/UANdRU/ZFZeUOX6OH+Dis9ICP7nHbv8Gg+zmlwI07 0myCvjCZsQD+93lgppj9tlHJwsFKhbSDGecSr3Gf/6dMYnJFVjjQewIZSpm95Kvi8y6y 2EA99MQlXdhdmuSJJwCuys1Y96uxFLHLhv3tg= MIME-Version: 1.0 Received: by 10.142.107.5 with SMTP id f5mr5230577wfc.130.1240417871502; Wed, 22 Apr 2009 09:31:11 -0700 (PDT) Date: Thu, 23 Apr 2009 00:31:11 +0800 Message-ID: <1d38a3350904220931va2554a8w83d0ed5fc9849723@mail.gmail.com> From: Hui Deng To: dhc WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Questions for DHCP assign two ipv4 address to one interface X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 16:30:11 -0000 Dear all May I consult whether one interface of DHCP client can get two ipv4 addresses from DHCP server? furthermore could get two default gateway? What we normally do is manual configure two ipv4 addressesfor 1 interface. then manual configure static routing for each of them, it works with complexity. Many thanks for your help Best regards, -Hui From Ted.Lemon@nominum.com Wed Apr 22 09:46:41 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7651D28C580 for ; Wed, 22 Apr 2009 09:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcGKVcr-Q8rj for ; Wed, 22 Apr 2009 09:46:40 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id DE6BE28C5BD for ; Wed, 22 Apr 2009 09:46:32 -0700 (PDT) Received: from source ([64.89.228.229]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSe9KNWLbC70wyIpUky29E3aoghD5idAX@postini.com; Wed, 22 Apr 2009 09:47:50 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F1C0A1B8377; Wed, 22 Apr 2009 09:48:02 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Wed, 22 Apr 2009 09:47:48 -0700 Message-ID: <29EB0EBC-492A-426C-BA48-FF6921E8C1E6@nominum.com> From: Ted Lemon To: Hui Deng In-Reply-To: <1d38a3350904220931va2554a8w83d0ed5fc9849723@mail.gmail.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 11:47:45 -0500 References: <1d38a3350904220931va2554a8w83d0ed5fc9849723@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: dhc WG Subject: Re: [dhcwg] Questions for DHCP assign two ipv4 address to one interface X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 16:46:41 -0000 On Apr 22, 2009, at 11:31 AM, Hui Deng wrote: > May I consult whether one interface of DHCP client can get two ipv4 > addresses from DHCP server? > furthermore could get two default gateway? Not really. You can do two separate DHCP transactions with different client identifiers, on the same interface, but I would expect you to get the same gateway IP address in both replies. Of course you would get two IP addresses, but I don't really see what good it would do. From denghui02@gmail.com Wed Apr 22 09:56:38 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB26728C5F6 for ; Wed, 22 Apr 2009 09:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbiapBnYK2iY for ; Wed, 22 Apr 2009 09:56:38 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 037C23A69BA for ; Wed, 22 Apr 2009 09:56:34 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so65480wff.31 for ; Wed, 22 Apr 2009 09:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MQlks12HminZwofxxMa9Dyye8g6cKeRiiVgnyiJzm6w=; b=jnoADQpcFYE2a0jam43uJU/WBq7FVuZp09eeT4NdhV0laLL9Y+o27fi39RDilKttqR 9ktyt8r+FdlIvVKUQwy7oq5O4/QZpcjDx8DSCOdY4k3vpOHOgmdd3H0DcCHTgAjgMNmU r8rRlnPcUCu/kyCu6YVl50F1wkRL+OrbA2poc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IjzOY5uryDz2cXRswtCybcwwz8aoHKNIj8bKiTKT+JWIK8jy8SSBJSFUGKuUUFG7Nh yQzpOUB5ZK+Z+7LP622W3ffkAPddMbccARfMgY/OddAprh502o+PQ/TSmL/CZNtxW+yB UHBsyXECRz2MOwAdACaj4BiDwc7ssP0QmBwko= MIME-Version: 1.0 Received: by 10.142.200.3 with SMTP id x3mr1555468wff.208.1240419472133; Wed, 22 Apr 2009 09:57:52 -0700 (PDT) In-Reply-To: <29EB0EBC-492A-426C-BA48-FF6921E8C1E6@nominum.com> References: <1d38a3350904220931va2554a8w83d0ed5fc9849723@mail.gmail.com> <29EB0EBC-492A-426C-BA48-FF6921E8C1E6@nominum.com> Date: Thu, 23 Apr 2009 00:57:51 +0800 Message-ID: <1d38a3350904220957t7539da1i6389b3c6f07ec537@mail.gmail.com> From: Hui Deng To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dhc WG Subject: Re: [dhcwg] Questions for DHCP assign two ipv4 address to one interface X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 16:56:39 -0000 thanks for explanation. is this client identifier a mac address? -Hui 2009/4/23 Ted Lemon : > On Apr 22, 2009, at 11:31 AM, Hui Deng wrote: >> >> May I consult whether one interface of DHCP client can get two ipv4 >> addresses from DHCP server? >> furthermore could get two default gateway? > > Not really. =A0 You can do two separate DHCP transactions with different > client identifiers, on the same interface, but I would expect you to get = the > same gateway IP address in both replies. =A0 Of course you would get two = IP > addresses, but I don't really see what good it would do. > > From Ted.Lemon@nominum.com Wed Apr 22 10:04:17 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7F43A6CA7 for ; Wed, 22 Apr 2009 10:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.054 X-Spam-Level: X-Spam-Status: No, score=-6.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldZBxgJPrYCm for ; Wed, 22 Apr 2009 10:04:17 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 0B9753A6915 for ; Wed, 22 Apr 2009 10:04:17 -0700 (PDT) Received: from source ([64.89.228.229]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSe9OUISyxoxynMjh1Y4WJmBlFoQBpmvs@postini.com; Wed, 22 Apr 2009 10:05:34 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F16B11B8379; Wed, 22 Apr 2009 10:05:33 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Wed, 22 Apr 2009 10:05:19 -0700 Message-ID: From: Ted Lemon To: Hui Deng In-Reply-To: <1d38a3350904220957t7539da1i6389b3c6f07ec537@mail.gmail.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 12:05:16 -0500 References: <1d38a3350904220931va2554a8w83d0ed5fc9849723@mail.gmail.com> <29EB0EBC-492A-426C-BA48-FF6921E8C1E6@nominum.com> <1d38a3350904220957t7539da1i6389b3c6f07ec537@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: dhc WG Subject: Re: [dhcwg] Questions for DHCP assign two ipv4 address to one interface X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 17:04:17 -0000 On Apr 22, 2009, at 11:57 AM, Hui Deng wrote: > is this client identifier a mac address? No, don't mess with the mac address - just change the dhcp client identifier option that you send. The DHCP server is supposed to treat two DHCP messages with different client identifier options as if they come from two different DHCP clients. It's possible that some DHCP server might key only on the Mac address, but in that case it's not really a DHCP server, because it's not following the protocol specification. From shemant@cisco.com Wed Apr 22 11:56:50 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 658E628C62D; Wed, 22 Apr 2009 11:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[AWL=0.952, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4CvQXefi52d; Wed, 22 Apr 2009 11:56:49 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D412728C629; Wed, 22 Apr 2009 11:56:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,231,1238976000"; d="scan'208";a="157809297" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2009 18:58:02 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3MIw1B7008003; Wed, 22 Apr 2009 11:58:01 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3MIvx0Q001014; Wed, 22 Apr 2009 18:58:01 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 14:58:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Apr 2009 14:57:59 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] New dhc WG co-chair Thread-Index: Acm+iYRU2ssMM6MVT9iUL8rHdbxVGgE8rPsQ References: From: "Hemant Singh (shemant)" To: "Ralph Droms (rdroms)" , "dhc WG" X-OriginalArrivalTime: 22 Apr 2009 18:58:00.0739 (UTC) FILETIME=[41FF6F30:01C9C37C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=932; t=1240426681; x=1241290681; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20[dhcwg]=20New=20dhc=20WG=20co-chair |Sender:=20; bh=z1lGeShwhx+BXK7mnVjY/+iPINTubC3htn2ZzjNNjds=; b=quIR/ovtd5yIJ2gBqEEbLKOxFzrSdjOv4emmBOnuxDaDvnlbgTNj5n6Omm eiP4GfIWeW7Jw9oA+hx5LLBbzfP64CHLVnvWMCBxzzPuL2iW6FWHjEu1k76N 6jSzuFW+R2; Authentication-Results: sj-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: The IESG Subject: Re: [dhcwg] New dhc WG co-chair X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 18:56:50 -0000 Congratulations, Ted! Hemant -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ralph Droms (rdroms) Sent: Thursday, April 16, 2009 7:40 AM To: dhc WG Cc: The IESG Subject: [dhcwg] New dhc WG co-chair I am pleased to announce that Ted Lemon has agreed to serve as dhc WG =20 co-chair. Ted has been an active participant and contributor to the =20 WG for many years, and brings broad understanding of IP, network =20 operation and device configuration along with in-depth implementation, =20 deployment and operational experience with DHCP to this job. Thanks, Ted, for volunteering and accepting this position. I'll speak =20 for Jari and the WG in saying that we're all looking forward to =20 working with you. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From rdroms@cisco.com Wed Apr 22 11:57:53 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 796C93A6D79 for ; Wed, 22 Apr 2009 11:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9pLEEVtNfk0 for ; Wed, 22 Apr 2009 11:57:52 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A47D63A6D23 for ; Wed, 22 Apr 2009 11:57:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,231,1238976000"; d="scan'208";a="175377223" Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-1.cisco.com with ESMTP; 22 Apr 2009 18:59:10 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id n3MIx9wi004380; Wed, 22 Apr 2009 11:59:09 -0700 Received: from sjc-vpnasa1-166.cisco.com (sjc-vpnasa1-166.cisco.com [10.21.104.166]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3MIx8co027219; Wed, 22 Apr 2009 18:59:09 GMT Message-Id: <911B9C46-F7BE-4A70-AAEA-50DE872E8136@cisco.com> From: Ralph Droms To: Hui Deng In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 14:59:08 -0400 References: <1d38a3350904220931va2554a8w83d0ed5fc9849723@mail.gmail.com> <29EB0EBC-492A-426C-BA48-FF6921E8C1E6@nominum.com> <1d38a3350904220957t7539da1i6389b3c6f07ec537@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1092; t=1240426749; x=1241290749; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20Questions=20for=20DHCP=20assi gn=20two=20ipv4=20address=20to=20one=20interface |Sender:=20; bh=nkDMw3Wbf0Qd8nOzd/ZWRBKkn7GAwS4BS4GYjVsVWCs=; b=nc8MBSNK2dDfqhFXG6wJhzGHz20yNsSGXr1ZHFJkZN+WobkC3URgFA4Ai+ Y4wRrNVhMC+SKU2xTwK2sB29FronOaWACCXuJtpUa6LpfTyAJALE2sfCWQUG 6/IhLaMfnw; Authentication-Results: sj-dkim-6; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); Cc: dhc WG Subject: Re: [dhcwg] Questions for DHCP assign two ipv4 address to one interface X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 18:57:53 -0000 The fundamental idea in DHCP (IPv4) is that each interface gets only one IP address. As Ted suggests, it's possible for one physical host to get two IPv4 addresses by spoofing the idea of two different hosts, but the server won't have any notion that the two addresses have been assigned to a single physical host. - Ralph On Apr 22, 2009, at 1:05 PM 4/22/09, Ted Lemon wrote: > On Apr 22, 2009, at 11:57 AM, Hui Deng wrote: >> is this client identifier a mac address? > > No, don't mess with the mac address - just change the dhcp client > identifier option that you send. The DHCP server is supposed to > treat two DHCP messages with different client identifier options as > if they come from two different DHCP clients. It's possible that > some DHCP server might key only on the Mac address, but in that case > it's not really a DHCP server, because it's not following the > protocol specification. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From rdroms@cisco.com Wed Apr 22 12:16:46 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0983A6B16 for ; Wed, 22 Apr 2009 12:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwyWPKsmJ9C3 for ; Wed, 22 Apr 2009 12:16:45 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8AC8D3A6864 for ; Wed, 22 Apr 2009 12:16:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,231,1238976000"; d="scan'208";a="155862444" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2009 19:18:03 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3MJI3ND008831; Wed, 22 Apr 2009 12:18:03 -0700 Received: from sjc-vpnasa1-166.cisco.com (sjc-vpnasa1-166.cisco.com [10.21.104.166]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3MJI2RM017031; Wed, 22 Apr 2009 19:18:02 GMT Message-Id: <2B956B89-503B-41C5-A7CE-BF0529C667D4@cisco.com> From: Ralph Droms To: Glen Zorn In-Reply-To: <00ba01c9c23c$9cf50760$d6df1620$@net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 15:18:01 -0400 References: <003401c9c170$492fff30$db8ffd90$@net> <8E296595B6471A4689555D5D725EBB210C519CBD@xmb-rtp-20a.amer.cisco.com> <00ba01c9c23c$9cf50760$d6df1620$@net> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1496; t=1240427883; x=1241291883; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20RAAN=20&=20SRSN=20drafts |Sender:=20; bh=f7swR1ftehA8Z0MgVfocMMgPUgGt/RniwxucW0VBcIE=; b=B4a9H+ZJjDjULDpWjVj1urb2qI6DbWPZvFY174rcWKQK51FMGa533zbEky NqMovTOwS6uUaC93P7o2j4Tvk0RkXgQps6mk/7jYj5SViRNbNu4zrW/cedmy jhi8CsgFil; Authentication-Results: sj-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Dhcwg WG , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] RAAN & SRSN drafts X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 19:16:46 -0000 Glen - I think Bernie has it right: the options are in two drafts as a matter of style. Keeping the SRSN option in a separate doc keeps it easier to find, read and understand. SRSN could certainly be referenced as part of a doc that defines RAAN. Is there a particular advantage to putting the options in one doc? - Ralph On Apr 21, 2009, at 12:49 AM 4/21/09, Glen Zorn wrote: > Bernie Volz (volz) [mailto:volz@cisco.com] writes: > >> I do think they should be. Ralph and I just re-spun the ones that had >> expired a while back without making any major changes. >> >> While I like the idea of avoiding layer violations which was, at >> least >> in my mind, the strongest motivation for RAAN (and thus SRSN), I'm >> not >> so sure that this now is a strong enough argument to proceed with >> RAAN/SRSN because there are already DHCPv6 relay agents that do the >> layer violations as they had no choice. > > Be that as it may, it's nice to have a clean way to do things. > >> >> SRSN might be useful for more than just RAAN (as it provides the >> 'ordering' data that is missing from DHCPv6 response flows over UDP >> from >> the server). > > True, but other documents can still reference the definition, > right? That > idea was why I didn't suggest pushing everything into one option... > > ... > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From rdroms@cisco.com Wed Apr 22 12:46:36 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC753A6F20 for ; Wed, 22 Apr 2009 12:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHONqOy3U3nP for ; Wed, 22 Apr 2009 12:46:35 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6409028C649 for ; Wed, 22 Apr 2009 12:46:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,231,1238976000"; d="scan'208";a="291002079" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Apr 2009 19:47:50 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3MJloPt007893; Wed, 22 Apr 2009 12:47:50 -0700 Received: from sjc-vpnasa1-166.cisco.com (sjc-vpnasa1-166.cisco.com [10.21.104.166]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3MJlZaY021220; Wed, 22 Apr 2009 19:47:35 GMT Message-Id: <543881D2-EDE8-4B1B-A5B3-9BE113CCBD3E@cisco.com> From: Ralph Droms To: Glen Zorn In-Reply-To: <002701c9c16d$85762bc0$90628340$@net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 15:47:34 -0400 References: <002701c9c16d$85762bc0$90628340$@net> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=713; t=1240429670; x=1241293670; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20Comment=20on=20http=3A//www.i etf.org/internet-drafts/draft-ietf-dhc-dhcpv6-agentopt-deleg ate-03.txt |Sender:=20; bh=+cc47UqpvB29XHO2NLHelSLGvOxWbYcq9aWUD+s7tQw=; b=bLXXTDHk8UYyuouA3ZdpWBudSLKO+Iwj+dzAoHeSKKOH2JGx9Pm02ww+AY dqj02wm30ls8gI2pgwV5CFpmcnvSeI46STQ1AJiQJi3ycbvyizFDABPlIMjn VrXxgqiv6tATJkEx27HBFObmG/UhC7xnQjXaSyLSCQxeczSpU1Urw=; Authentication-Results: sj-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Dhcwg WG Subject: Re: [dhcwg] Comment on http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-agentopt-delegate-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 19:46:36 -0000 Thanks, Glen. I'll make that fix in the next rev. - Ralph On Apr 20, 2009, at 12:07 AM 4/20/09, Glen Zorn wrote: > The acronym "ORO" is used without expansion. > > ~gwz > > At one time in the US, in the mid-nineteenth century, working for > wage labor > was considered not very different from chattel slavery...anyone who > thinks > it's legitimate to be a wage laborer is internalizing oppression in > a way > which would have seemed intolerable to people in the mills 150 years > ago. > -- Noam Chomsky, "Propaganda & the Public Mind" > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Wed Apr 22 13:17:23 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B547D3A6940 for ; Wed, 22 Apr 2009 13:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TS-wNNwgzrl for ; Wed, 22 Apr 2009 13:17:22 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AFD7928C5FF for ; Wed, 22 Apr 2009 13:17:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,232,1238976000"; d="scan'208";a="291020501" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Apr 2009 20:18:40 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3MKIeMb006589; Wed, 22 Apr 2009 13:18:40 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3MKIcFc028093; Wed, 22 Apr 2009 20:18:40 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 16:18:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Apr 2009 16:18:38 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB210C51A71C@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <911B9C46-F7BE-4A70-AAEA-50DE872E8136@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Questions for DHCP assign two ipv4 address to oneinterface Thread-Index: AcnDfHIWDoikFPa2R6ezMK85HY58vgACogEQ References: <1d38a3350904220931va2554a8w83d0ed5fc9849723@mail.gmail.com><29EB0EBC-492A-426C-BA48-FF6921E8C1E6@nominum.com><1d38a3350904220957t7539da1i6389b3c6f07ec537@mail.gmail.com> <911B9C46-F7BE-4A70-AAEA-50DE872E8136@cisco.com> From: "Bernie Volz (volz)" To: "Ralph Droms (rdroms)" , "Hui Deng" X-OriginalArrivalTime: 22 Apr 2009 20:18:39.0439 (UTC) FILETIME=[861675F0:01C9C387] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2533; t=1240431520; x=1241295520; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Questions=20for=20DHCP=20assi gn=20two=20ipv4=20address=20to=20oneinterface |Sender:=20; bh=gt+Bb8R9qCk3qLF1GPt8clAbpKT3DJ186Ddq36AHC9c=; b=CYkLB/q0zrkWUuvHZVh/QZ8ITVSpoLXcDu5Q8DJi5G5fxOxVxcLa+SFk93 EpWRRO4Pt0updbdqS/X5Je72KVsh1fbCDxrNCWRnnh0iB/DJ3q6cvOH94Fkv QxqvVUnTpXnXfupt8dLb5cfCgJfeV9f3GSeh+qLTCodyieTw9AF1Y=; Authentication-Results: sj-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: dhc WG Subject: Re: [dhcwg] Questions for DHCP assign two ipv4 address to oneinterface X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 20:17:23 -0000 Folks ... Let's not forget Ted and Bill's RFC on this topic - RFC 4361, Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4). This RFC extends the use of the DHCPv6 DUID and identity association concept to DHCPv4 and would be the best way to accomplish getting multiple leases for a single client on a single interface. This is done by using the Client Identifier option (61): Code Len Type IAID DUID +----+----+-----+----+----+----+----+----+----+--- | 61 | n | 255 | i1 | i2 | i3 | i4 | d1 | d2 |... +----+----+-----+----+----+----+----+----+----+--- Then, by varying the IAID value, a single client can get multiple leases with the same DUID (whether on a single or multiple interfaces). The other advantage of this is the DNS updates should work correctly (at least for those servers that understand this format of the client identifier and use just the DUID when doing DNS updates). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ralph Droms (rdroms) Sent: Wednesday, April 22, 2009 2:59 PM To: Hui Deng Cc: dhc WG Subject: Re: [dhcwg] Questions for DHCP assign two ipv4 address to oneinterface The fundamental idea in DHCP (IPv4) is that each interface gets only =20 one IP address. As Ted suggests, it's possible for one physical host =20 to get two IPv4 addresses by spoofing the idea of two different hosts, =20 but the server won't have any notion that the two addresses have been =20 assigned to a single physical host. - Ralph On Apr 22, 2009, at 1:05 PM 4/22/09, Ted Lemon wrote: > On Apr 22, 2009, at 11:57 AM, Hui Deng wrote: >> is this client identifier a mac address? > > No, don't mess with the mac address - just change the dhcp client =20 > identifier option that you send. The DHCP server is supposed to =20 > treat two DHCP messages with different client identifier options as =20 > if they come from two different DHCP clients. It's possible that =20 > some DHCP server might key only on the Mac address, but in that case =20 > it's not really a DHCP server, because it's not following the =20 > protocol specification. > > _______________________________________________ > 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 denghui02@gmail.com Thu Apr 23 05:51:38 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78283A694D for ; Thu, 23 Apr 2009 05:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVRAsdjBl9yX for ; Thu, 23 Apr 2009 05:51:37 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id D659D3A6A69 for ; Thu, 23 Apr 2009 05:51:37 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so553066wff.31 for ; Thu, 23 Apr 2009 05:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=587tK1iP3jKzg9X4Nz7AfJL7uwd3xLRaB9ekedkjvD4=; b=t0PecAsrCzKDVxWbZXjtoRK/yokg+z5H1wES20vei29KMLOjsRMYCyhRFlFPUN05fm EjGUgTj6d8d6M85pq2ci+Jujtct+sWOz4nJldXC84AfaCaSbkOJltUAoS0Y4WJ5i7HtD eKw2ZF4iCKTNtlnIKBlMVFyIxbCWifUbpJNOw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=N5Po1UWO98avQuz5/lIX6zRQfy5elbru3ccCmF94L9WD/J1fv+8cMZKO/bDxCYqXpr h9i0CN090EwSiXGX6Mr0eeSvxX5hIX/mfG/AR5hRnV27HGNfH/fKZFYoP6Jlj3S0DmoV SV9ue+MWZc9tFIs8oQKEIW40++adcMYR7w97Q= MIME-Version: 1.0 Received: by 10.142.231.7 with SMTP id d7mr326583wfh.285.1240491175903; Thu, 23 Apr 2009 05:52:55 -0700 (PDT) In-Reply-To: <8E296595B6471A4689555D5D725EBB210C51A71C@xmb-rtp-20a.amer.cisco.com> References: <1d38a3350904220931va2554a8w83d0ed5fc9849723@mail.gmail.com> <29EB0EBC-492A-426C-BA48-FF6921E8C1E6@nominum.com> <1d38a3350904220957t7539da1i6389b3c6f07ec537@mail.gmail.com> <911B9C46-F7BE-4A70-AAEA-50DE872E8136@cisco.com> <8E296595B6471A4689555D5D725EBB210C51A71C@xmb-rtp-20a.amer.cisco.com> Date: Thu, 23 Apr 2009 20:52:55 +0800 Message-ID: <1d38a3350904230552o2a771ccfpcccfceed9b2aa2bd@mail.gmail.com> From: Hui Deng To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dhc WG , "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] Questions for DHCP assign two ipv4 address to oneinterface X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 12:51:38 -0000 Thanks Ted, Ralph and Bernie, I guess it has been sufficient discussed. the reason I asked this question is that mobile user is really using multiple different ip address es for their different APN communication, it seems workable for only 1 interface. Anyhow, some of their address assignment is not based on DHCP but PDP conte= xt. I guess that application may have diffculty to know which source address is going to use. Thanks again. -Hui 2009/4/23 Bernie Volz (volz) : > Folks ... Let's not forget Ted and Bill's RFC on this topic - RFC 4361, > Node-specific Client Identifiers for Dynamic Host Configuration Protocol > Version Four (DHCPv4). This RFC extends the use of the DHCPv6 DUID and > identity association concept to DHCPv4 and would be the best way to > accomplish getting multiple leases for a single client on a single > interface. > > This is done by using the Client Identifier option (61): > > =A0 =A0 =A0 Code =A0Len =A0Type =A0IAID =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DU= ID > =A0 =A0 =A0 +----+----+-----+----+----+----+----+----+----+--- > =A0 =A0 =A0 | 61 | n =A0| 255 | i1 | i2 | i3 | i4 | d1 | d2 |... > =A0 =A0 =A0 +----+----+-----+----+----+----+----+----+----+--- > > Then, by varying the IAID value, a single client can get multiple leases > with the same DUID (whether on a single or multiple interfaces). The > other advantage of this is the DNS updates should work correctly (at > least for those servers that understand this format of the client > identifier and use just the DUID when doing DNS updates). > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Ralph Droms (rdroms) > Sent: Wednesday, April 22, 2009 2:59 PM > To: Hui Deng > Cc: dhc WG > Subject: Re: [dhcwg] Questions for DHCP assign two ipv4 address to > oneinterface > > The fundamental idea in DHCP (IPv4) is that each interface gets only > one IP address. =A0As Ted suggests, it's possible for one physical host > to get two IPv4 addresses by spoofing the idea of two different hosts, > but the server won't have any notion that the two addresses have been > assigned to a single physical host. > > - Ralph > > On Apr 22, 2009, at 1:05 PM 4/22/09, Ted Lemon wrote: > >> On Apr 22, 2009, at 11:57 AM, Hui Deng wrote: >>> is this client identifier a mac address? >> >> No, don't mess with the mac address - just change the dhcp client >> identifier option that you send. =A0 The DHCP server is supposed to >> treat two DHCP messages with different client identifier options as >> if they come from two different DHCP clients. =A0 It's possible that >> some DHCP server might key only on the Mac address, but in that case >> it's not really a DHCP server, because it's not following the >> protocol specification. >> >> _______________________________________________ >> 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 denghui02@gmail.com Thu Apr 23 05:55:02 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84FEE3A6A47; Thu, 23 Apr 2009 05:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNS9lUgzkBJ9; Thu, 23 Apr 2009 05:55:01 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id C524C3A7295; Thu, 23 Apr 2009 05:55:01 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so421342rvb.49 for ; Thu, 23 Apr 2009 05:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kweqnPlqnbZbZXrf+gfaIIeozDW40ith/jfc6SLKB8E=; b=t12tq3Z7zsxNdUrTxC+dM0kTVRM2zGTZJP7fIUMOM+zFYCIGbwja5ur/LdFBBN3NZ/ l+cdGJW3oqpWaSuD1I4TZExM40PhkujJejXrEtEy+3hkON/sAyJnBzNA862KqvBusVlY beFp1gGt+1WdcX8CldXM6AMa4HUnmlSOsIp0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jipz0Un09auo4VBNXpmiFkOqoX9wDKRjcoJ0RAgtO0zYOBYUz+6shOuodlNKaAcINt ENFYYXNpvEtRmXpix2r6sJzvy0rp2XfhXueKuA5VgY+2Xu2ew7DagzTU1DcMaM//GGGA 4fuDkbv3wZbCK/uxyenWe5coPTx9MAtcoALwE= MIME-Version: 1.0 Received: by 10.142.216.18 with SMTP id o18mr326736wfg.312.1240491379764; Thu, 23 Apr 2009 05:56:19 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Apr 2009 20:56:19 +0800 Message-ID: <1d38a3350904230556v54a1ac32r92039b5bb4133771@mail.gmail.com> From: Hui Deng To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dhc WG , The IESG Subject: Re: [dhcwg] New dhc WG co-chair X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 12:55:02 -0000 Congratulation to Ted. -Hui 2009/4/16 Ralph Droms : > I am pleased to announce that Ted Lemon has agreed to serve as dhc WG > co-chair. =A0Ted has been an active participant and contributor to the WG= for > many years, and brings broad understanding of IP, network operation and > device configuration along with in-depth implementation, deployment and > operational experience with DHCP to this job. > > Thanks, Ted, for volunteering and accepting this position. =A0I'll speak = for > Jari and the WG in saying that we're all looking forward to working with > you. > > - Ralph > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From Basavaraj.Patil@nokia.com Thu Apr 23 05:57:09 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35EAB3A696B for ; Thu, 23 Apr 2009 05:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.383 X-Spam-Level: X-Spam-Status: No, score=-6.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpvqSFIS0RbK for ; Thu, 23 Apr 2009 05:57:08 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 27C313A68FC for ; Thu, 23 Apr 2009 05:57:08 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3NCvw8f016799; Thu, 23 Apr 2009 07:58:15 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Apr 2009 15:57:37 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Apr 2009 15:57:37 +0300 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 23 Apr 2009 14:57:36 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.108]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Thu, 23 Apr 2009 14:57:36 +0200 From: To: , Date: Thu, 23 Apr 2009 14:57:45 +0200 Thread-Topic: [dhcwg] Questions for DHCP assign two ipv4 address to oneinterface Thread-Index: AcnEEn6RNbKpDDWtRgupN/EuNoJ5mQAAJneF Message-ID: In-Reply-To: <1d38a3350904230552o2a771ccfpcccfceed9b2aa2bd@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Apr 2009 12:57:37.0379 (UTC) FILETIME=[13E24B30:01C9C413] X-Nokia-AV: Clean Cc: dhcwg@ietf.org, rdroms@cisco.com Subject: Re: [dhcwg] Questions for DHCP assign two ipv4 address to oneinterface X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 12:57:09 -0000 Hui, In the context of 3GPP networks which use APNs, each PDP connection (or PDN bearer) can be viewed as a separate PtP connection between the host and the GGSN. Hence it is possible to assign unique IPv4 addresses. And I don't see any reason why you could not use DHCP to assign an address for each PDP context. AFAIK, DHCP is a mechanism for assigning addresses to PDP contexts.=20 -Raj On 4/23/09 7:52 AM, "ext Hui Deng" wrote: > Thanks Ted, Ralph and Bernie, >=20 > I guess it has been sufficient discussed. >=20 > the reason I asked this question is that mobile user is really using > multiple different ip address es for their different APN > communication, it seems workable for only 1 interface. >=20 > Anyhow, some of their address assignment is not based on DHCP but PDP con= text. > I guess that application may have diffculty to know which source > address is going to use. >=20 > Thanks again. >=20 > -Hui >=20 > 2009/4/23 Bernie Volz (volz) : >> Folks ... Let's not forget Ted and Bill's RFC on this topic - RFC 4361, >> Node-specific Client Identifiers for Dynamic Host Configuration Protocol >> Version Four (DHCPv4). This RFC extends the use of the DHCPv6 DUID and >> identity association concept to DHCPv4 and would be the best way to >> accomplish getting multiple leases for a single client on a single >> interface. >>=20 >> This is done by using the Client Identifier option (61): >>=20 >> =A0 =A0 =A0 Code =A0Len =A0Type =A0IAID =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0D= UID >> =A0 =A0 =A0 +----+----+-----+----+----+----+----+----+----+--- >> =A0 =A0 =A0 | 61 | n =A0| 255 | i1 | i2 | i3 | i4 | d1 | d2 |... >> =A0 =A0 =A0 +----+----+-----+----+----+----+----+----+----+--- >>=20 >> Then, by varying the IAID value, a single client can get multiple leases >> with the same DUID (whether on a single or multiple interfaces). The >> other advantage of this is the DNS updates should work correctly (at >> least for those servers that understand this format of the client >> identifier and use just the DUID when doing DNS updates). >>=20 >> - Bernie >>=20 >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >> Of Ralph Droms (rdroms) >> Sent: Wednesday, April 22, 2009 2:59 PM >> To: Hui Deng >> Cc: dhc WG >> Subject: Re: [dhcwg] Questions for DHCP assign two ipv4 address to >> oneinterface >>=20 >> The fundamental idea in DHCP (IPv4) is that each interface gets only >> one IP address. =A0As Ted suggests, it's possible for one physical host >> to get two IPv4 addresses by spoofing the idea of two different hosts, >> but the server won't have any notion that the two addresses have been >> assigned to a single physical host. >>=20 >> - Ralph >>=20 >> On Apr 22, 2009, at 1:05 PM 4/22/09, Ted Lemon wrote: >>=20 >>> On Apr 22, 2009, at 11:57 AM, Hui Deng wrote: >>>> is this client identifier a mac address? >>>=20 >>> No, don't mess with the mac address - just change the dhcp client >>> identifier option that you send. =A0 The DHCP server is supposed to >>> treat two DHCP messages with different client identifier options as >>> if they come from two different DHCP clients. =A0 It's possible that >>> some DHCP server might key only on the Mac address, but in that case >>> it's not really a DHCP server, because it's not following the >>> protocol specification. >>>=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 >>=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From denghui02@gmail.com Thu Apr 23 07:38:19 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4202928C174 for ; Thu, 23 Apr 2009 07:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9Xzblm5SA4k for ; Thu, 23 Apr 2009 07:38:18 -0700 (PDT) Received: from mail-gx0-f166.google.com (mail-gx0-f166.google.com [209.85.217.166]) by core3.amsl.com (Postfix) with ESMTP id 34EE428C147 for ; Thu, 23 Apr 2009 07:38:17 -0700 (PDT) Received: by gxk10 with SMTP id 10so1191976gxk.13 for ; Thu, 23 Apr 2009 07:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H9tWWyWvnHTWIkhWya8MH6DCSu+dc2ctmy+aH4t/DMg=; b=hSxiMy4kX+JtJqXNMh/VWjpI6YPz9os6elVF9esS3uEncw6JWIKi4hO9BLWtRQTGQ8 E01u6sDrQbJgD/dXk1GzTfgOI7WsVXaYeIgnW7XTyBMK+IkBkYMTDtzX2Z3h6MMKY2dx +Gn3NYc5YwpNKDZIfNJ7zZ/h4W6nYA5VkKB84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XE3Ee2FzEL+6NKiOikVHyDhLM5y9PxTL9h5TvjTuXdMjUo7PouDZpsJurbE7GlpDt9 1F0oPoVfd6daKPNxHfevlIoMeZJkRFt1/kTR7cG1Up9www+1nR0fdeoVYsK5MVL+++85 iQiS9dML1VTAxJWCq1uC9DflAzROr9M0YE3YE= MIME-Version: 1.0 Received: by 10.142.52.7 with SMTP id z7mr359275wfz.267.1240497574652; Thu, 23 Apr 2009 07:39:34 -0700 (PDT) In-Reply-To: References: <1d38a3350904230552o2a771ccfpcccfceed9b2aa2bd@mail.gmail.com> Date: Thu, 23 Apr 2009 22:39:34 +0800 Message-ID: <1d38a3350904230739v1f563aact41b04ed42f65a72b@mail.gmail.com> From: Hui Deng To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, volz@cisco.com, rdroms@cisco.com Subject: Re: [dhcwg] Questions for DHCP assign two ipv4 address to oneinterface X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 14:38:19 -0000 Raj Good to discuss here, the scenario like this, one interface request two PDP contexts to two different LMA (let's use IETF word here, other than PDN GW), this interface get two different IP addresses from two different DHCP Servers, based on DHC WG's view, it is hard to implement,RFC 4361 may do that. but my problem with this, when the application like IE would like to choose which source address to use, it will be the issue, since both LMA has non-wap website connection. thanks for the discussion -Hui 2009/4/23 : > > Hui, > > In the context of 3GPP networks which use APNs, each PDP connection (or P= DN > bearer) can be viewed as a separate PtP connection between the host and t= he > GGSN. Hence it is possible to assign unique IPv4 addresses. > And I don't see any reason why you could not use DHCP to assign an addres= s > for each PDP context. AFAIK, DHCP is a mechanism for assigning addresses = to > PDP contexts. > > -Raj > > > On 4/23/09 7:52 AM, "ext Hui Deng" wrote: > >> Thanks Ted, Ralph and Bernie, >> >> I guess it has been sufficient discussed. >> >> the reason I asked this question is that mobile user is really using >> multiple different ip address es for their different APN >> communication, it seems workable for only 1 interface. >> >> Anyhow, some of their address assignment is not based on DHCP but PDP co= ntext. >> I guess that application may have diffculty to know which source >> address is going to use. >> >> Thanks again. >> >> -Hui >> >> 2009/4/23 Bernie Volz (volz) : >>> Folks ... Let's not forget Ted and Bill's RFC on this topic - RFC 4361, >>> Node-specific Client Identifiers for Dynamic Host Configuration Protoco= l >>> Version Four (DHCPv4). This RFC extends the use of the DHCPv6 DUID and >>> identity association concept to DHCPv4 and would be the best way to >>> accomplish getting multiple leases for a single client on a single >>> interface. >>> >>> This is done by using the Client Identifier option (61): >>> >>> =A0 =A0 =A0 Code =A0Len =A0Type =A0IAID =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= DUID >>> =A0 =A0 =A0 +----+----+-----+----+----+----+----+----+----+--- >>> =A0 =A0 =A0 | 61 | n =A0| 255 | i1 | i2 | i3 | i4 | d1 | d2 |... >>> =A0 =A0 =A0 +----+----+-----+----+----+----+----+----+----+--- >>> >>> Then, by varying the IAID value, a single client can get multiple lease= s >>> with the same DUID (whether on a single or multiple interfaces). The >>> other advantage of this is the DNS updates should work correctly (at >>> least for those servers that understand this format of the client >>> identifier and use just the DUID when doing DNS updates). >>> >>> - Bernie >>> >>> -----Original Message----- >>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >>> Of Ralph Droms (rdroms) >>> Sent: Wednesday, April 22, 2009 2:59 PM >>> To: Hui Deng >>> Cc: dhc WG >>> Subject: Re: [dhcwg] Questions for DHCP assign two ipv4 address to >>> oneinterface >>> >>> The fundamental idea in DHCP (IPv4) is that each interface gets only >>> one IP address. =A0As Ted suggests, it's possible for one physical host >>> to get two IPv4 addresses by spoofing the idea of two different hosts, >>> but the server won't have any notion that the two addresses have been >>> assigned to a single physical host. >>> >>> - Ralph >>> >>> On Apr 22, 2009, at 1:05 PM 4/22/09, Ted Lemon wrote: >>> >>>> On Apr 22, 2009, at 11:57 AM, Hui Deng wrote: >>>>> is this client identifier a mac address? >>>> >>>> No, don't mess with the mac address - just change the dhcp client >>>> identifier option that you send. =A0 The DHCP server is supposed to >>>> treat two DHCP messages with different client identifier options as >>>> if they come from two different DHCP clients. =A0 It's possible that >>>> some DHCP server might key only on the Mac address, but in that case >>>> it's not really a DHCP server, because it's not following the >>>> protocol specification. >>>> >>>> _______________________________________________ >>>> 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 behcetsarikaya@yahoo.com Thu Apr 23 16:13:17 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AAA33A695C for ; Thu, 23 Apr 2009 16:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5qipz92WDCj for ; Thu, 23 Apr 2009 16:13:16 -0700 (PDT) Received: from n6.bullet.re3.yahoo.com (n6.bullet.re3.yahoo.com [68.142.237.91]) by core3.amsl.com (Postfix) with SMTP id 31A1A3A7358 for ; Thu, 23 Apr 2009 16:12:25 -0700 (PDT) Received: from [68.142.237.88] by n6.bullet.re3.yahoo.com with NNFMP; 23 Apr 2009 23:13:43 -0000 Received: from [67.195.9.82] by t4.bullet.re3.yahoo.com with NNFMP; 23 Apr 2009 23:13:43 -0000 Received: from [67.195.9.105] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 23 Apr 2009 23:13:42 -0000 Received: from [127.0.0.1] by omp109.mail.gq1.yahoo.com with NNFMP; 23 Apr 2009 23:14:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 404081.1236.bm@omp109.mail.gq1.yahoo.com Received: (qmail 55869 invoked by uid 60001); 23 Apr 2009 23:13:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240528422; bh=7uH1kbygpZPc07OhFSZahQ3SWHxub1p/YRmtG3My2sk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BQfMIR8qf8RxVQ/B20TOAVnt/Y2FaHbJ6BdKHQ3En76VEAgLJ/08q8cgSF5WeZebHX908545x/jWz/wCIvcgK66P86BmaiWqtXxs2SVJT2bL3zeXQikk+0cGm8cyiZdKL2gzGdEuecFNiK9FZJL2eEgiTQ/kTRDP3ZjcjLfdBxY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bmylM7YoWH+Jm33/S24bAKTZGNaHGwRLq3iNSgrSpenCJUk24qGzKWlo8Bv8kJLPy36RJKIrJy6J3eODxMItrqLwMJVTodcU9TTICWvQggK3tgQ6ie8c3somcrgpPtncmM7L1XTKZZ1ik0/rdhXAFHtL6hofEoGwf2YJfHf/rcU=; Message-ID: <663722.55650.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: 93m8FOUVM1nNbDZscANwKnBgKwrxhk7gLq_aj.hhlO5ycIku5iFD.AKNfOP_tHcSk5iubK9Vf5DaUyUpsnnxfXeU58Jg_WElxYr4FZmK7nJVLaOHdVT8TLxM9QMd1GJpGzUDfkK1m0fM8I_v7R1nXqzFNUxs2EVn3r1kWttNXFaSIHT.AXM4gTVEh3YYy1Zb8_imRmfsp0folnF4pho4ULcdC2WUqAbkLNDPCNWqw.IyTDyEX7.eB9kKAr4NdFHTzIRYzctuPM9pk5Hco4byDsBOBeTSTxVJAIUA3wRltAUwTOnhrle48AB1I9_CaViegDe19Y70WQ-- Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Thu, 23 Apr 2009 16:13:42 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <1d38a3350904220931va2554a8w83d0ed5fc9849723@mail.gmail.com> <29EB0EBC-492A-426C-BA48-FF6921E8C1E6@nominum.com> <1d38a3350904220957t7539da1i6389b3c6f07ec537@mail.gmail.com> Date: Thu, 23 Apr 2009 16:13:42 -0700 (PDT) From: Behcet Sarikaya To: Hui Deng , Ted Lemon In-Reply-To: <1d38a3350904220957t7539da1i6389b3c6f07ec537@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-796129910-1240528422=:55650" Cc: dhc WG Subject: Re: [dhcwg] Questions for DHCP assign two ipv4 address to one interface X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 23:13:17 -0000 --0-796129910-1240528422=:55650 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hui,=0A=A0 Client ID or DUID is not a MAC address. It is host id, someth= ing like IMEI.=0AI think in DHCP IAID comes closer to MAC address.=0A=0AReg= ards,=0A=0ABehcet=0A=0A=0A=0A=0A________________________________=0AFrom: Hu= i Deng =0ATo: Ted Lemon =0ACc: = dhc WG =0ASent: Wednesday, April 22, 2009 11:57:51 AM=0ASub= ject: Re: [dhcwg] Questions for DHCP assign two ipv4 address to one interfa= ce=0A=0Athanks for explanation.=0Ais this client identifier a mac address?= =0A=0A-Hui=0A=0A2009/4/23 Ted Lemon :=0A> On Apr 22,= 2009, at 11:31 AM, Hui Deng wrote:=0A>>=0A>> May I consult whether one int= erface of DHCP client can get two ipv4=0A>> addresses from DHCP server?=0A>= > furthermore could get two default gateway?=0A>=0A> Not really. =A0 You ca= n do two separate DHCP transactions with different=0A> client identifiers, = on the same interface, but I would expect you to get the=0A> same gateway I= P address in both replies. =A0 Of course you would get two IP=0A> addresses= , but I don't really see what good it would do.=0A>=0A>=0A_________________= ______________________________=0Adhcwg mailing list=0Adhcwg@ietf.org=0Ahttp= s://www.ietf.org/mailman/listinfo/dhcwg=0A=0A=0A=0A --0-796129910-1240528422=:55650 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hui,
=0A
  Client ID or DUID is not a= MAC address. It is host id, something like IMEI.
=0A
I think in D= HCP IAID comes closer to MAC address.
=0A
 
=0A
Rega= rds,
=0A
 
=0A
Behcet
=0A

=0A<= DIV style=3D"FONT-SIZE: 13px; FONT-FAMILY: arial, helvetica, sans-serif">=0A
=0AFrom: Hui Deng <denghui02@gmail.com>
To: Ted Lemon <Ted.Lemon@nominum.c= om>
Cc: dhc WG <dh= cwg@ietf.org>
Sent: W= ednesday, April 22, 2009 11:57:51 AM
Ted.Lemon@nominum.com>:
> On Apr 22, 2009, at 11:31 AM, Hui D= eng wrote:
>>
>> May I consult whether one interface of D= HCP client can get two ipv4
>> addresses from DHCP server?
>= > furthermore could get two default gateway?
>
> Not really.   You can do two separate DHCP t= ransactions with different
> client identifiers, on the same interfac= e, but I would expect you to get the
> same gateway IP address in bot= h replies.   Of course you would get two IP
> addresses, but I d= on't really see what good it would do.
>
>
_________________= ______________________________
dhcwg mailing list
dhcwg@ietf.org
https:/= /www.ietf.org/mailman/listinfo/dhcwg

=0A=0A=0A= =0A --0-796129910-1240528422=:55650-- From David.Miles@alcatel-lucent.com.au Thu Apr 23 18:33:26 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1E33A6B48 for ; Thu, 23 Apr 2009 18:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlE6xhkcqjG6 for ; Thu, 23 Apr 2009 18:33:25 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 9BE1E28C0E6 for ; Thu, 23 Apr 2009 18:33:08 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n3O1YOjH002929 for ; Thu, 23 Apr 2009 20:34:24 -0500 (CDT) Received: from mail.apac.alcatel-lucent.com (h202-65-2-130.alcatel.com [202.65.2.130]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n3O1YMi7019429 for ; Thu, 23 Apr 2009 20:34:23 -0500 (CDT) Received: from sgsinsbhs01.ad4.ad.alcatel.com (sgsinsbhs01.ap.lucent.com [135.254.109.34]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id n3O1VSVg017018 for ; Fri, 24 Apr 2009 09:31:29 +0800 Received: from SGSINSMBS02.ad4.ad.alcatel.com ([135.254.109.29]) by sgsinsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 09:34:20 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 09:34:17 +0800 Message-ID: <986DCE2E44129444B6435ABE8C9E424D0320D83B@SGSINSMBS02.ad4.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DHCPv6 VSIO on a relay agent Thread-Index: AcnEfMg4SuQR6xYCTl+IJfxdzYYz+g== From: "MILES DAVID" To: X-OriginalArrivalTime: 24 Apr 2009 01:34:20.0811 (UTC) FILETIME=[CA7035B0:01C9C47C] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.130 Subject: [dhcwg] DHCPv6 VSIO on a relay agent X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 01:33:26 -0000 Relay agents (especially in broadband environments) may wish to embed vendor-specific values into relayed DHCPv6 messages. I want to clarify the intended use of the Vendor-Specific Information Option (17) as the introductory text mentions: This option is used by clients and servers to exchange vendor-specific information. I cannot see any immediate issues in using option 17 on relay agents but want to check opinion. DHCPv4 gave us RFC 4243 specifically for the purpose of relay agent vendor-specific options so I wanted to see whether there was a more appropriate option to use in DHCPv6 than option 17. Cheers, -David From ramesh22@gmail.com Sun Apr 26 03:12:08 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370113A68CD for ; Sun, 26 Apr 2009 03:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xje+tJUpqXz for ; Sun, 26 Apr 2009 03:12:07 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id DEF673A67B0 for ; Sun, 26 Apr 2009 03:12:06 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so2469176yxb.49 for ; Sun, 26 Apr 2009 03:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=aCbjVUq6jBtWCaGZ7yg9fI61nMxZqq8cymvTV8G/P00=; b=DD+BoVJSu3z0wsjO9u1q79ZwyK/RGDF+bENpyG8ITmmRyL8xCQhpCdw/FHy8zmyPlj W2o72ECKPbSRoCAYIOUwlJp33FDYMNatE0M+UdgFnjVsYsbmKqoW1wHLzpf3fIPCwHYF xtCMdbgu5i3aWd2VBCcLVg1cpHzCMl0lanIik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eYPIxp3U1K52ngQ3ViLe7IlNphsmpNpchQ4VatMS6Pz8bRPluqea2RvWifrxcwH+E9 gUKdmpxPTjMjst58IXrpHKYQFLoE5isENnfghIRBF4LpsMDSoWajnDrfaSCavnME/zsP +yKfEjf0MHTHkEDhgfwr/6YlhPq1F3pecvDQc= MIME-Version: 1.0 Received: by 10.151.111.15 with SMTP id o15mr7750986ybm.71.1240740806513; Sun, 26 Apr 2009 03:13:26 -0700 (PDT) In-Reply-To: <31D55C4D55BEED48A4459EB64567589A0E857E6A43@BLRKECMBX02.ad.infosys.com> References: <31D55C4D55BEED48A4459EB64567589A0E857E6A43@BLRKECMBX02.ad.infosys.com> Date: Sun, 26 Apr 2009 15:43:26 +0530 Message-ID: <42704ecd0904260313y15c90d64o1db7e6384030e0b4@mail.gmail.com> From: Ramesh To: Bharat Joshi Content-Type: multipart/alternative; boundary=0015175770b207d5e50468727b7e Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 10:12:08 -0000 --0015175770b207d5e50468727b7e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bharat, Few comments/suggestions. Search for [Ramesh]. Section 4.1.1 ------------- 3 ... The DHCP server responds with a DHCPOFFER message after applying its local policies. [Ramesh] Will it be good to mention ".. after applying its local policies for address allocation". This is just to make clear of what policy, DHCP is all concerned about and readers do not relate this to any system policies. Section 4.1.1 ------------- 3 ...A Layer 2 Relay Agent may be configured to intercept unicast DHCP messages. [ramesh] I think all L2 Relay Agents SHOULD intercept _all_ the DHCP messages from server _if_ it has inserted option-82. This is because for a client, option-82 do not make any sense. section 4.1.1 ------------- 6. ... DHCPNACK - RFC 2131 refer to DHCPNAK and not DHCPNACK. Is this ok? section 4.2.2 ------------- 1 .... Layer 2 relay agents SHOULD select the longest lease time of two conflicting but similar replies, by discarding replies that shorten the lease time. [Ramesh] I thought, to keep the state of a client, L2 Relay Agent will learn from the REQUEST+ACK message exchange which involves only one server. So there is no question of keeping a client state more than its life time. Am I missing something here? In any case, Maintaining a state ( and hence filter) even after a client is dead, mean anomalies. section 4.3.2 ------------- 3 ...Because of this, it could be difficult for the DHCP server to differentiate between a RENEWING and REBINDING state. [Ramesh] Did you mean "difficult to differentiate between RENEW and REBIND messages here? State is term used in the server context, right? If you are talking about server state - then its server who leased out an IP and hence it would know the state of the client based on T1 & T2. -- cheers ramesh On Wed, Apr 22, 2009 at 6:43 AM, Bharat Joshi wrote: > Hi All, > > We have published version 04 of Layer 2 Relay Agent Information > draft. This version addresses several editorial comments provided by Alfred. > > Draft is available at > http://www.ietf.org/internet-drafts/draft-ietf-dhc-l2ra-04.txt > > Thanks, > Bharat > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > solely > for the use of the addressee(s). If you are not the intended recipient, > please > notify the sender by e-mail and delete the original message. Further, you > are not > to copy, disclose, or distribute this e-mail or its contents to any other > person and > any such actions are unlawful. This e-mail may contain viruses. Infosys has > taken > every reasonable precaution to minimize this risk, but is not liable for > any damage > you may sustain as a result of any virus in this e-mail. You should carry > out your > own virus checks before opening the e-mail or attachment. Infosys reserves > the > right to monitor and review the content of all messages sent to or from > this e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --0015175770b207d5e50468727b7e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
Bharat,
Few comments/suggestions. Search for [Ramesh]. 

Section 4.1.1

-------------<=
br style=3D"font-family: arial narrow,sans-serif;">3 ... The DHCP server responds with a DHCPOFF=
ER message after applying its local policies.

[Ramesh] Will it be g=
ood to mention ".. after applying its local policies for 
address allocation". This is just to make cle=
ar of what policy, DHCP is all concerned 

about and readers do =
not relate this to any system policies.

=
Section 4.1.1<=
br style=3D"font-family: arial narrow,sans-serif;">
-------------<=
br style=3D"font-family: arial narrow,sans-serif;">3 ...A Layer 2 Relay Agent may be configured =
to intercept unicast DHCP messages.

[ramesh] I think all =
L2 Relay Agents SHOULD intercept _all_ the DHCP messages from server=

_if_ it has inserted option-82. This is beca=
use for a client, option-82 do not make any sense. 


section 4.1.1
-------------

6. ...

=
DHCPNACK  - RFC 2131 refer to DHCPNAK and not DHCPNACK. Is this ok?<=
br style=3D"font-family: arial narrow,sans-serif;">


section 4.2.2

-------------<=
br style=3D"font-family: arial narrow,sans-serif;">1 .... Layer 2 relay agents SHOULD select the=
 longest lease time of two conflicting

but similar replies, =
by discarding replies that shorten the lease time.
[Ramesh] I thought, to keep the state of a client, L2 Relay Ag=
ent will learn 

from the REQUEST+ACK =
message exchange which involves only one server. So there
is no question of keeping a client state more than it=
s life time. Am I missing

something here?

In any case, Maintaining a state ( and hence filter) even after a =
client is dead, 

mean anomalies.

section 4.3.2 

-------------<=
br style=3D"font-family: arial narrow,sans-serif;">3 ...Because of this, it could be difficult f=
or the DHCP server to differentiate

between a RENEWING an=
d REBINDING state.
[Ramesh] Did you me=
an "difficult to differentiate between RENEW and REBIND messages

here? State is term u=
sed in the server context, right? 
If =
you are talking about server state - then its server who leased out an IP a=
nd 

hence it would know t=
he state of the client based on T1 & T2. 


-- 
cheers

ramesh



On Wed, Apr 22, 2009 at 6:43 AM, Bharat Joshi <bharat_joshi@inf= osys.com> wrote:
Hi All,

=A0 =A0 =A0 We have published version 04 of Layer 2 Relay Agent Informatio= n draft. This version addresses several editorial comments provided by Alfr= ed.

=A0 =A0 =A0 Draft is available at http://www.ietf.org/in= ternet-drafts/draft-ietf-dhc-l2ra-04.txt

Thanks,
Bharat
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solel= y
for the use of the addressee(s). If you are not the intended recipient, ple= ase
notify the sender by e-mail and delete the original message. Further, you a= re not
to copy, disclose, or distribute this e-mail or its contents to any other p= erson and
any such actions are unlawful. This e-mail may contain viruses. Infosys has= taken
every reasonable precaution to minimize this risk, but is not liable for an= y damage
you may sustain as a result of any virus in this e-mail. You should carry o= ut your
own virus checks before opening the e-mail or attachment. Infosys reserves = the
right to monitor and review the content of all messages sent to or from thi= s e-mail
address. Messages sent to or from this e-mail address may be stored on the<= br> Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg




--0015175770b207d5e50468727b7e-- From pavan_kurapati@infosys.com Sun Apr 26 06:33:09 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6423A69E5 for ; Sun, 26 Apr 2009 06:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rfksjocbohcw for ; Sun, 26 Apr 2009 06:33:08 -0700 (PDT) Received: from kecgate02.infosys.com (unknown [61.95.162.76]) by core3.amsl.com (Postfix) with ESMTP id 8F4343A68E8 for ; Sun, 26 Apr 2009 06:33:07 -0700 (PDT) X-TM-IMSS-Message-ID: Received: from blrkechub02.ad.infosys.com ([10.66.236.42]) by kecgate02.infosys.com ([61.95.162.76]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS: TLSv1/SSLv3,128bits,RC4-MD5) id c53979aa00047a2b ; Sun, 26 Apr 2009 19:04:16 +0530 Received: from BLRKECMBX01.ad.infosys.com ([10.66.236.21]) by blrkechub02.ad.infosys.com ([10.66.236.42]) with mapi; Sun, 26 Apr 2009 19:04:23 +0530 From: pavan_kurapati To: Ramesh , Bharat Joshi Date: Sun, 26 Apr 2009 19:04:23 +0530 Thread-Topic: [dhcwg] Layer 2 Relay Agent Information draft Thread-Index: AcnGV6penttWXMF2QJuANdFAeJCZQAAGOowk Message-ID: <7221E17E68B1A944ADCE8A83364DBEE61AC554F789@BLRKECMBX01.ad.infosys.com> References: <31D55C4D55BEED48A4459EB64567589A0E857E6A43@BLRKECMBX02.ad.infosys.com>, <42704ecd0904260313y15c90d64o1db7e6384030e0b4@mail.gmail.com> In-Reply-To: <42704ecd0904260313y15c90d64o1db7e6384030e0b4@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 13:33:09 -0000 Hi Ramesh, Thanks for the review. Please find replies inline Thannks, Pavan ________________________________ From: dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] On Behalf Of Ramesh [= ramesh22@gmail.com] Sent: Sunday, April 26, 2009 3:43 PM To: Bharat Joshi Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft Bharat, Few comments/suggestions. Search for [Ramesh]. Section 4.1.1 ------------- 3 ... The DHCP server responds with a DHCPOFFER message after applying its = local policies. [Ramesh] Will it be good to mention ".. after applying its local policies f= or address allocation". This is just to make clear of what policy, DHCP is all= concerned about and readers do not relate this to any system policies. [Pavan] I feel the text is generic and conveys the message. Section 4.1.1 ------------- 3 ...A Layer 2 Relay Agent may be configured to intercept unicast DHCP mess= ages. [ramesh] I think all L2 Relay Agents SHOULD intercept _all_ the DHCP messag= es from server _if_ it has inserted option-82. This is because for a client, option-82 do = not make any sense. [Pavan] Mandating all L2RAs to intercept unicast messages may be too strict= behavior given that there are implementations which doesnt do it. I feel = 'may' is good here. section 4.1.1 ------------- 6. ... DHCPNACK - RFC 2131 refer to DHCPNAK and not DHCPNACK. Is this ok? [Pavan] Yes, thanks. Will change it. section 4.2.2 ------------- 1 .... Layer 2 relay agents SHOULD select the longest lease time of two con= flicting but similar replies, by discarding replies that shorten the lease time. [Ramesh] I thought, to keep the state of a client, L2 Relay Agent will lear= n from the REQUEST+ACK message exchange which involves only one server. So th= ere is no question of keeping a client state more than its life time. Am I miss= ing something here? In any case, Maintaining a state ( and hence filter) even after a client is= dead, mean anomalies. [Pavan] This condition can occur when multiple DHCP servers are configured = for failover. In such a configuration, there are servers which ignore serve= r-id and in certain exceptional conditions may respond to the same IP addre= ss request with multiple ACKs. In this scenario, L2RA must take the one whi= ch has more lease time. section 4.3.2 ------------- 3 ...Because of this, it could be difficult for the DHCP server to differen= tiate between a RENEWING and REBINDING state. [Ramesh] Did you mean "difficult to differentiate between RENEW and REBIND = messages here? State is term used in the server context, right? If you are talking about server state - then its server who leased out an I= P and hence it would know the state of the client based on T1 & T2. [Pavan] Actually this state is in terms of client's context. A client would= broadcast the dhcp message with client address filled in this state. In ca= se of failover configurations, a REBIND may imply that one of the primary s= erver is not responding [since it is broadcast]. However, in L2RA, since un= icast messages are also intercepted and option 82 added, a RENEW may be mis= understood as REBIND by server. Let us know if it is not clear. -- cheers ramesh On Wed, Apr 22, 2009 at 6:43 AM, Bharat Joshi > wrote: Hi All, We have published version 04 of Layer 2 Relay Agent Information draft= . This version addresses several editorial comments provided by Alfred. Draft is available at http://www.ietf.org/internet-drafts/draft-ietf-= dhc-l2ra-04.txt Thanks, Bharat **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solel= y for the use of the addressee(s). If you are not the intended recipient, ple= ase notify the sender by e-mail and delete the original message. Further, you a= re not to copy, disclose, or distribute this e-mail or its contents to any other p= erson and any such actions are unlawful. This e-mail may contain viruses. Infosys has= taken every reasonable precaution to minimize this risk, but is not liable for an= y damage you may sustain as a result of any virus in this e-mail. You should carry o= ut your own virus checks before opening the e-mail or attachment. Infosys reserves = the right to monitor and review the content of all messages sent to or from thi= s e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From ramesh22@gmail.com Sun Apr 26 09:18:55 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEFC93A696B for ; Sun, 26 Apr 2009 09:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwHwikQNHnhE for ; Sun, 26 Apr 2009 09:18:54 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id C12073A68E8 for ; Sun, 26 Apr 2009 09:18:53 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so2180330ywj.49 for ; Sun, 26 Apr 2009 09:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=3AyH3ZIj4m38ickqvuoemPjbmNb6cyE59LkeKBotF3w=; b=iPgaidAKLPqDDt62VHEjaup9I7EAMt+run+R9EFppkrqXaVv7EGwdui8kIHWJdCcq9 Um8yv8w19TTSm7s6UaTVYgBxPZeJIR4VMJOhpm8/WCpMkiAEC2lxLvvT5BwhFIeSwiZq keIf2LaWrtnPOgyAxJuT/VvsvWI/QKxPQBbIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WSC80Kh2zNryyDs9iOjbpjd9PEmvdlKfVDqZupOrUJUyPo2X+YrkTEUuBgG3Ihjbaa kyU9S5CWRWsFVY3a10ETTtA35D2MPPQRWsJWAzZCRzDbG18ziFrC9l+Dja0xyFufMGql A8uTuv4tjiYrDC77WX43b2b/3xHn6QNDC42Gk= MIME-Version: 1.0 Received: by 10.151.131.4 with SMTP id i4mr7003400ybn.136.1240762813664; Sun, 26 Apr 2009 09:20:13 -0700 (PDT) In-Reply-To: <7221E17E68B1A944ADCE8A83364DBEE61AC554F789@BLRKECMBX01.ad.infosys.com> References: <31D55C4D55BEED48A4459EB64567589A0E857E6A43@BLRKECMBX02.ad.infosys.com> <42704ecd0904260313y15c90d64o1db7e6384030e0b4@mail.gmail.com> <7221E17E68B1A944ADCE8A83364DBEE61AC554F789@BLRKECMBX01.ad.infosys.com> Date: Sun, 26 Apr 2009 21:50:13 +0530 Message-ID: <42704ecd0904260920l68b8ce36tf08fb1ab4a0802c0@mail.gmail.com> From: Ramesh To: pavan_kurapati Content-Type: multipart/alternative; boundary=001e680f112cc24f930468779a53 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 16:18:56 -0000 --001e680f112cc24f930468779a53 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Pavan, Please see comments inline Section 4.1.1 ------------- 3 ...A Layer 2 Relay Agent may be configured to intercept unicast DHCP messages. [ramesh] I think all L2 Relay Agents SHOULD intercept _all_ the DHCP messages from server _if_ it has inserted option-82. This is because for a client, option-82 do not make any sense. [Pavan] Mandating all L2RAs to intercept unicast messages may be too strict behavior given that there are implementations which doesnt do it. I feel 'may' is good here. [Ramesh] My concern here is, L2RA should intercept all packets from server, as server could do unicast reply for a broadcast request. As per RFC 3046 information option have to be stripped off by the relay agent which added it, " The Relay Agent Information option echoed by a server MUST be removed by either the relay agent or the trusted downstream network element which added it when forwarding a server-to-client response back to the client. " Also, I think it will be harsh on the client by asking it to accept a DHCP option which a client software does not care at all. Today, there _can_ be DHCP clients which misbehave(?) when it see an option-82, as RFC 3046 clearly removes client's relationship with option-82. section 4.2.2 ------------- 1 .... Layer 2 relay agents SHOULD select the longest lease time of two conflicting but similar replies, by discarding replies that shorten the lease time. [Ramesh] I thought, to keep the state of a client, L2 Relay Agent will learn from the REQUEST+ACK message exchange which involves only one server. So there is no question of keeping a client state more than its life time. Am I missing something here? In any case, Maintaining a state ( and hence filter) even after a client is dead, mean anomalies. [Pavan] This condition can occur when multiple DHCP servers are configured for failover. In such a configuration, there are servers which ignore server-id and in certain exceptional conditions may respond to the same IP address request with multiple ACKs. In this scenario, L2RA must take the one which has more lease time. [Ramesh] I feel we are leaving a security hole here. Say you have a client which should be leased IP for 10 minutes. One server lease with 10 minutes and another server with 20 minutes of lease interval. L2RA will assume the client is valid for 20 minutes and tune the filter. Whereas the management box ( eg. BRAS) would think it is valid for 10 minutes. So it is like allowing an unauthorized client to be active from 10 to 20th time instance. ? By the way, how is the client expected to behave when it gets two lease. Is it expected to use the address leased by the server corresponding to the server-id? section 4.3.2 ------------- 3 ...Because of this, it could be difficult for the DHCP server to differentiate between a RENEWING and REBINDING state. [Ramesh] Did you mean "difficult to differentiate between RENEW and REBIND messages here? State is term used in the server context, right? If you are talking about server state - then its server who leased out an IP and hence it would know the state of the client based on T1 & T2. [Pavan] Actually this state is in terms of client's context. A client would broadcast the dhcp message with client address filled in this state. In case of failover configurations, a REBIND may imply that one of the primary server is not responding [since it is broadcast]. However, in L2RA, since unicast messages are also intercepted and option 82 added, a RENEW may be misunderstood as REBIND by server. Let us know if it is not clear. [Ramesh] My understanding is, if unicast messages are intercepted, - RENEW will get option 82 added and giaddr not set. - REBIND will get option 82 added and giaddr set. This difference is sufficient for the DHCP Server to distinguish the client packet. Did I get something wrong? -- cheers ramesh On Sun, Apr 26, 2009 at 7:04 PM, pavan_kurapati wrote: > Hi Ramesh, > Thanks for the review. Please find replies inline > > Thannks, > Pavan > ________________________________ > From: dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] On Behalf Of Ramesh > [ramesh22@gmail.com] > Sent: Sunday, April 26, 2009 3:43 PM > To: Bharat Joshi > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft > > > Bharat, > > Few comments/suggestions. Search for [Ramesh]. > > Section 4.1.1 > > ------------- > 3 ... The DHCP server responds with a DHCPOFFER message after applying its > local policies. > [Ramesh] Will it be good to mention ".. after applying its local policies > for > address allocation". This is just to make clear of what policy, DHCP is all > concerned > about and readers do not relate this to any system policies. > > > > [Pavan] I feel the text is generic and conveys the message. > > > Section 4.1.1 > > ------------- > 3 ...A Layer 2 Relay Agent may be configured to intercept unicast DHCP > messages. > [ramesh] I think all L2 Relay Agents SHOULD intercept _all_ the DHCP > messages from server > _if_ it has inserted option-82. This is because for a client, option-82 do > not make any sense. > > > > [Pavan] Mandating all L2RAs to intercept unicast messages may be too strict > behavior given that there are implementations which doesnt do it. I feel > 'may' is good here. > > section 4.1.1 > ------------- > 6. ... > > DHCPNACK - RFC 2131 refer to DHCPNAK and not DHCPNACK. Is this ok? > > [Pavan] Yes, thanks. Will change it. > > section 4.2.2 > > ------------- > 1 .... Layer 2 relay agents SHOULD select the longest lease time of two > conflicting > but similar replies, by discarding replies that shorten the lease time. > [Ramesh] I thought, to keep the state of a client, L2 Relay Agent will > learn > from the REQUEST+ACK message exchange which involves only one server. So > there > is no question of keeping a client state more than its life time. Am I > missing > something here? > > In any case, Maintaining a state ( and hence filter) even after a client is > dead, > mean anomalies. > > > > [Pavan] This condition can occur when multiple DHCP servers are configured > for failover. In such a configuration, there are servers which ignore > server-id and in certain exceptional conditions may respond to the same IP > address request with multiple ACKs. In this scenario, L2RA must take the one > which has more lease time. > > > section 4.3.2 > > ------------- > 3 ...Because of this, it could be difficult for the DHCP server to > differentiate > between a RENEWING and REBINDING state. > [Ramesh] Did you mean "difficult to differentiate between RENEW and REBIND > messages > here? State is term used in the server context, right? > If you are talking about server state - then its server who leased out an > IP and > hence it would know the state of the client based on T1 & T2. > > [Pavan] Actually this state is in terms of client's context. A client would > broadcast the dhcp message with client address filled in this state. In case > of failover configurations, a REBIND may imply that one of the primary > server is not responding [since it is broadcast]. However, in L2RA, since > unicast messages are also intercepted and option 82 added, a RENEW may be > misunderstood as REBIND by server. Let us know if it is not clear. > > -- > cheers > ramesh > > > > > On Wed, Apr 22, 2009 at 6:43 AM, Bharat Joshi > wrote: > Hi All, > > We have published version 04 of Layer 2 Relay Agent Information draft. > This version addresses several editorial comments provided by Alfred. > > Draft is available at > http://www.ietf.org/internet-drafts/draft-ietf-dhc-l2ra-04.txt > > Thanks, > Bharat > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > solely > for the use of the addressee(s). If you are not the intended recipient, > please > notify the sender by e-mail and delete the original message. Further, you > are not > to copy, disclose, or distribute this e-mail or its contents to any other > person and > any such actions are unlawful. This e-mail may contain viruses. Infosys has > taken > every reasonable precaution to minimize this risk, but is not liable for > any damage > you may sustain as a result of any virus in this e-mail. You should carry > out your > own virus checks before opening the e-mail or attachment. Infosys reserves > the > right to monitor and review the content of all messages sent to or from > this e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > > > --001e680f112cc24f930468779a53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pavan,
Please see comments inline



Section 4.1.1

-------------
3 ...A Layer 2 Relay Agent may be configured to intercept unicast DHCP mess= ages.
[ramesh] I think all L2 Relay Agents SHOULD intercept _all_ the DHCP messag= es from server
_if_ it has inserted option-82. This is because for a client, option-82 do = not make any sense.
[Pavan] Mandating all L2RAs to intercept unicast messages may be too strict behavior =A0given that there are implementations which doesnt do it. I feel 'may' is good here.
[Ramesh] My concern here is, L= 2RA should intercept all packets from server, as server could do unicast re= ply for a broadcast request.
As per RFC 3046 information option have to = be stripped off by the relay agent which added it,
"
   The Relay Agent Information option echoed by a server MUS=
T be removed
   by either the relay agent or the trusted downstream netw=
ork element
   which added it when forwarding a server-to-client respons=
e back to

   the client.
"
Also, I think it will be harsh on the client by asking it to accept a DHCP = option which a client software does not care at all.
Today, there _can_= be DHCP clients which misbehave(?) when it see an option-82, as RFC 3046 c= learly removes client's relationship with option-82.

section 4.2.2

-------------
1 .... Layer 2 relay agents SHOULD select the longest lease time of two con= flicting
but similar replies, by discarding replies that shorten the lease time.
[Ramesh] I thought, to keep the state of a client, L2 Relay Agent will lear= n
from the REQUEST+ACK message exchange which involves only one server. So th= ere
is no question of keeping a client state more than its life time. Am I miss= ing
something here?

In any case, Maintaining a state ( and hence filter) even after a client is= dead,
mean anomalies.
[Pavan] This condition can occur when multiple DHCP servers are configured for failover. In such a configuration, there are servers which ignore server-id and in certain exceptional conditions may respond to the same IP address request with multiple ACKs. In this scenario, L2RA must take the one which has more lease time.
[Ramesh] I f= eel we are leaving a security hole here.
Say you have a client which sho= uld be leased IP for 10 minutes. One server lease with 10 minutes and anoth= er server with 20 minutes of lease interval.
L2RA will assume the client is valid for 20 minutes and tune the filter. Wh= ereas the management box ( eg. BRAS) would think it is valid for 10 minutes= .
So it is like allowing an unauthorized client to be active from 10 to= 20th time instance. ?
By the way, how is the client expected to behave when it gets two lease. Is= it expected to use the address leased by the server corresponding to the s= erver-id?



section 4.3.2

-------------
3 ...Because of this, it could be difficult for the DHCP server to differen= tiate
between a RENEWING and REBINDING state.
[Ramesh] Did you mean "difficult to differentiate between RENEW and RE= BIND messages
here? State is term used in the server context, right?
If you are talking about server state - then its server who leased out an I= P and
hence it would know the state of the client based on T1 & T2.

[Pavan] Actually this state is in terms of client's context. A client would broadcast the dhcp message with client address filled in this state. In case of failover configurations, a REBIND may imply that one of the primary server is not responding [since it is broadcast]. However, in L2RA, since unicast messages are also intercepted and option 82 added, a RENEW may be misunderstood as REBIND by server. Let us know if it is not clear.
[Ramesh] My understanding is, if unicast mes= sages are intercepted,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - REN= EW will get option 82 added and giaddr not set.
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 - REBIND will get option 82 added and giaddr set.
This difference is sufficient for the DHCP Server to distinguish the client= packet.
Did I get something wrong?

--
cheers
ramesh

On Sun, Apr 26, 2009 at 7:04 PM, pavan_kur= apati <p= avan_kurapati@infosys.com> wrote:
Hi Ramesh,
Thanks for the review. Please find replies inline

Thannks,
Pavan
________________________________
From: dhcwg-bounces@ietf.org = [dhcwg-bounces@ietf.org] On B= ehalf Of Ramesh [ramesh22@gmail.com]
Sent: Sunday, April 26, 2009 3:43 PM
To: Bharat Joshi
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft


Bharat,

Few comments/suggestions. Search for [Ramesh].

Section 4.1.1

-------------
3 ... The DHCP server responds with a DHCPOFFER message after applying its = local policies.
[Ramesh] Will it be good to mention ".. after applying its local polic= ies for
address allocation". This is just to make clear of what policy, DHCP i= s all concerned
about and readers do not relate this to any system policies.



[Pavan] I feel the text is generic and conveys the message.


Section 4.1.1

-------------
3 ...A Layer 2 Relay Agent may be configured to intercept unicast DHCP mess= ages.
[ramesh] I think all L2 Relay Agents SHOULD intercept _all_ the DHCP messag= es from server
_if_ it has inserted option-82. This is because for a client, option-82 do = not make any sense.



[Pavan] Mandating all L2RAs to intercept unicast messages may be too = strict behavior =A0given that there are implementations which doesnt do it.= I feel 'may' is good here.

section 4.1.1
-------------
6. ...

DHCPNACK - RFC 2131 refer to DHCPNAK and not DHCPNACK. Is this ok?

[Pavan] Yes, thanks. Will change it.

section 4.2.2

-------------
1 .... Layer 2 relay agents SHOULD select the longest lease time of two con= flicting
but similar replies, by discarding replies that shorten the lease time.
[Ramesh] I thought, to keep the state of a client, L2 Relay Agent will lear= n
from the REQUEST+ACK message exchange which involves only one server. So th= ere
is no question of keeping a client state more than its life time. Am I miss= ing
something here?

In any case, Maintaining a state ( and hence filter) even after a client is= dead,
mean anomalies.



[Pavan] This condition can occur when multiple DHCP servers are confi= gured for failover. In such a configuration, there are servers which ignore= server-id and in certain exceptional conditions may respond to the same IP= address request with multiple ACKs. In this scenario, L2RA must take the o= ne which has more lease time.


section 4.3.2

-------------
3 ...Because of this, it could be difficult for the DHCP server to differen= tiate
between a RENEWING and REBINDING state.
[Ramesh] Did you mean "difficult to differentiate between RENEW and RE= BIND messages
here? State is term used in the server context, right?
If you are talking about server state - then its server who leased out an I= P and
hence it would know the state of the client based on T1 & T2.

[Pavan] Actually this state is in terms of client's context. A cl= ient would broadcast the dhcp message with client address filled in this st= ate. In case of failover configurations, a REBIND may imply that one of the= primary server is not responding [since it is broadcast]. However, in L2RA= , since unicast messages are also intercepted and option 82 added, a RENEW = may be misunderstood as REBIND by server. Let us know if it is not clear.
--
cheers
ramesh




On Wed, Apr 22, 2009 at 6:43 AM, Bharat Joshi <bharat_joshi@infosys.com<mailto:bharat_joshi@infosys.com>> wrote:
Hi All,

=A0 =A0 =A0We have published version 04 of Layer 2 Relay Agent Information= draft. This version addresses several editorial comments provided by Alfre= d.

=A0 =A0 =A0Draft is available at http://www.ietf.org/int= ernet-drafts/draft-ietf-dhc-l2ra-04.txt

Thanks,
Bharat
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solel= y
for the use of the addressee(s). If you are not the intended recipient, ple= ase
notify the sender by e-mail and delete the original message. Further, you a= re not
to copy, disclose, or distribute this e-mail or its contents to any other p= erson and
any such actions are unlawful. This e-mail may contain viruses. Infosys has= taken
every reasonable precaution to minimize this risk, but is not liable for an= y damage
you may sustain as a result of any virus in this e-mail. You should carry o= ut your
own virus checks before opening the e-mail or attachment. Infosys reserves = the
right to monitor and review the content of all messages sent to or from thi= s e-mail
address. Messages sent to or from this e-mail address may be stored on the<= br> Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org<mailto:dhcwg@ietf.org>




--001e680f112cc24f930468779a53-- From pavan_kurapati@infosys.com Tue Apr 28 09:31:40 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFA663A6C0E for ; Tue, 28 Apr 2009 09:31:40 -0700 (PDT) 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=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHmMAFeQX-g5 for ; Tue, 28 Apr 2009 09:31:39 -0700 (PDT) Received: from KECGATE08.infosys.com (Kecgate08.infosys.com [122.98.10.33]) by core3.amsl.com (Postfix) with ESMTP id 977503A6C33 for ; Tue, 28 Apr 2009 09:31:37 -0700 (PDT) X-TM-IMSS-Message-ID: <07c9959a00013a2a@KECGATE08.infosys.com> Received: from blrkechub04.ad.infosys.com ([10.66.236.44]) by KECGATE08.infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 07c9959a00013a2a ; Tue, 28 Apr 2009 22:03:33 +0530 Received: from BLRKECMBX01.ad.infosys.com ([10.66.236.21]) by blrkechub04.ad.infosys.com ([10.66.236.44]) with mapi; Tue, 28 Apr 2009 22:02:56 +0530 From: pavan_kurapati To: Ramesh Date: Tue, 28 Apr 2009 22:02:55 +0530 Thread-Topic: [dhcwg] Layer 2 Relay Agent Information draft Thread-Index: AcnGiuSqPjvyvyhcSEa9PgcLMFU/YwBkwHKM Message-ID: <7221E17E68B1A944ADCE8A83364DBEE61AC554F7A1@BLRKECMBX01.ad.infosys.com> References: <31D55C4D55BEED48A4459EB64567589A0E857E6A43@BLRKECMBX02.ad.infosys.com> <42704ecd0904260313y15c90d64o1db7e6384030e0b4@mail.gmail.com> <7221E17E68B1A944ADCE8A83364DBEE61AC554F789@BLRKECMBX01.ad.infosys.com>, <42704ecd0904260920l68b8ce36tf08fb1ab4a0802c0@mail.gmail.com> In-Reply-To: <42704ecd0904260920l68b8ce36tf08fb1ab4a0802c0@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 16:31:41 -0000 Hi Ramesh, Sorry for the delay. Please see replies inline Thanks, Pavan ________________________________ From: Ramesh [ramesh22@gmail.com] Sent: Sunday, April 26, 2009 9:50 PM To: pavan_kurapati Cc: Bharat Joshi; dhcwg@ietf.org Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft Pavan, Please see comments inline Section 4.1.1 ------------- 3 ...A Layer 2 Relay Agent may be configured to intercept unicast DHCP mess= ages. [ramesh] I think all L2 Relay Agents SHOULD intercept _all_ the DHCP messag= es from server _if_ it has inserted option-82. This is because for a client, option-82 do = not make any sense. [Pavan] Mandating all L2RAs to intercept unicast messages may be too strict= behavior given that there are implementations which doesnt do it. I feel = 'may' is good here. [Ramesh] My concern here is, L2RA should intercept all packets from server,= as server could do unicast reply for a broadcast request. As per RFC 3046 information option have to be stripped off by the relay age= nt which added it, " The Relay Agent Information option echoed by a server MUST be removed by either the relay agent or the trusted downstream network element which added it when forwarding a server-to-client response back to the client. " Also, I think it will be harsh on the client by asking it to accept a DHCP = option which a client software does not care at all. Today, there _can_ be DHCP clients which misbehave(?) when it see an option= -82, as RFC 3046 clearly removes client's relationship with option-82. [Pavan] You are right that ideally L2RAs (or any relay agent) which adds Op= tion 82 must be configured to snoop unicast replies to remove the option 82= . That is how most of the L2RAs (DSLAMs for eg) work today. However, as I m= entioned, there are some L2RAs which cannot snoop unicast messages. Also, p= lease note that this is a informational draft and not a standards draft, so= we cannot mandate anything in this draft. section 4.2.2 ------------- 1 .... Layer 2 relay agents SHOULD select the longest lease time of two con= flicting but similar replies, by discarding replies that shorten the lease time. [Ramesh] I thought, to keep the state of a client, L2 Relay Agent will lear= n from the REQUEST+ACK message exchange which involves only one server. So th= ere is no question of keeping a client state more than its life time. Am I miss= ing something here? In any case, Maintaining a state ( and hence filter) even after a client is= dead, mean anomalies. [Pavan] This condition can occur when multiple DHCP servers are configured = for failover. In such a configuration, there are servers which ignore serve= r-id and in certain exceptional conditions may respond to the same IP addre= ss request with multiple ACKs. In this scenario, L2RA must take the one whi= ch has more lease time. [Ramesh] I feel we are leaving a security hole here. Say you have a client which should be leased IP for 10 minutes. One server = lease with 10 minutes and another server with 20 minutes of lease interval. L2RA will assume the client is valid for 20 minutes and tune the filter. Wh= ereas the management box ( eg. BRAS) would think it is valid for 10 minutes= . So it is like allowing an unauthorized client to be active from 10 to 20th = time instance. ? By the way, how is the client expected to behave when it gets two lease. Is= it expected to use the address leased by the server corresponding to the s= erver-id? [Pavan] We feel that all the elements (including BRAS) must take the highes= t lease time option in this case. Currently, I dont think client has any de= fined bahavior in this case. BTW, please read the below thread on the origi= n of this text. http://www.ietf.org/mail-archive/web/dhcwg/current/msg08427.html section 4.3.2 ------------- 3 ...Because of this, it could be difficult for the DHCP server to differen= tiate between a RENEWING and REBINDING state. [Ramesh] Did you mean "difficult to differentiate between RENEW and REBIND = messages here? State is term used in the server context, right? If you are talking about server state - then its server who leased out an I= P and hence it would know the state of the client based on T1 & T2. [Pavan] Actually this state is in terms of client's context. A client would= broadcast the dhcp message with client address filled in this state. In ca= se of failover configurations, a REBIND may imply that one of the primary s= erver is not responding [since it is broadcast]. However, in L2RA, since un= icast messages are also intercepted and option 82 added, a RENEW may be mis= understood as REBIND by server. Let us know if it is not clear. [Ramesh] My understanding is, if unicast messages are intercepted, - RENEW will get option 82 added and giaddr not set. - REBIND will get option 82 added and giaddr set. This difference is sufficient for the DHCP Server to distinguish the client= packet. Did I get something wrong? [Pavan] There are DHCP servers today which assumes client is in REBIND stat= e if option 82 and client ip address is present. It does not check the 'gia= ddr' and that was the reason for adding this statement. Let me know if this= is still not clear. -- cheers ramesh On Sun, Apr 26, 2009 at 7:04 PM, pavan_kurapati > wrote: Hi Ramesh, Thanks for the review. Please find replies inline Thannks, Pavan ________________________________ From: dhcwg-bounces@ietf.org [dhcwg-bounces@= ietf.org] On Behalf Of Ramesh [ramesh22@gmai= l.com] Sent: Sunday, April 26, 2009 3:43 PM To: Bharat Joshi Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft Bharat, Few comments/suggestions. Search for [Ramesh]. Section 4.1.1 ------------- 3 ... The DHCP server responds with a DHCPOFFER message after applying its = local policies. [Ramesh] Will it be good to mention ".. after applying its local policies f= or address allocation". This is just to make clear of what policy, DHCP is all= concerned about and readers do not relate this to any system policies. [Pavan] I feel the text is generic and conveys the message. Section 4.1.1 ------------- 3 ...A Layer 2 Relay Agent may be configured to intercept unicast DHCP mess= ages. [ramesh] I think all L2 Relay Agents SHOULD intercept _all_ the DHCP messag= es from server _if_ it has inserted option-82. This is because for a client, option-82 do = not make any sense. [Pavan] Mandating all L2RAs to intercept unicast messages may be too strict= behavior given that there are implementations which doesnt do it. I feel = 'may' is good here. section 4.1.1 ------------- 6. ... DHCPNACK - RFC 2131 refer to DHCPNAK and not DHCPNACK. Is this ok? [Pavan] Yes, thanks. Will change it. section 4.2.2 ------------- 1 .... Layer 2 relay agents SHOULD select the longest lease time of two con= flicting but similar replies, by discarding replies that shorten the lease time. [Ramesh] I thought, to keep the state of a client, L2 Relay Agent will lear= n from the REQUEST+ACK message exchange which involves only one server. So th= ere is no question of keeping a client state more than its life time. Am I miss= ing something here? In any case, Maintaining a state ( and hence filter) even after a client is= dead, mean anomalies. [Pavan] This condition can occur when multiple DHCP servers are configured = for failover. In such a configuration, there are servers which ignore serve= r-id and in certain exceptional conditions may respond to the same IP addre= ss request with multiple ACKs. In this scenario, L2RA must take the one whi= ch has more lease time. section 4.3.2 ------------- 3 ...Because of this, it could be difficult for the DHCP server to differen= tiate between a RENEWING and REBINDING state. [Ramesh] Did you mean "difficult to differentiate between RENEW and REBIND = messages here? State is term used in the server context, right? If you are talking about server state - then its server who leased out an I= P and hence it would know the state of the client based on T1 & T2. [Pavan] Actually this state is in terms of client's context. A client would= broadcast the dhcp message with client address filled in this state. In ca= se of failover configurations, a REBIND may imply that one of the primary s= erver is not responding [since it is broadcast]. However, in L2RA, since un= icast messages are also intercepted and option 82 added, a RENEW may be mis= understood as REBIND by server. Let us know if it is not clear. -- cheers ramesh On Wed, Apr 22, 2009 at 6:43 AM, Bharat Joshi >> wrote: Hi All, We have published version 04 of Layer 2 Relay Agent Information draft.= This version addresses several editorial comments provided by Alfred. Draft is available at http://www.ietf.org/internet-drafts/draft-ietf-d= hc-l2ra-04.txt Thanks, Bharat **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solel= y for the use of the addressee(s). If you are not the intended recipient, ple= ase notify the sender by e-mail and delete the original message. Further, you a= re not to copy, disclose, or distribute this e-mail or its contents to any other p= erson and any such actions are unlawful. This e-mail may contain viruses. Infosys has= taken every reasonable precaution to minimize this risk, but is not liable for an= y damage you may sustain as a result of any virus in this e-mail. You should carry o= ut your own virus checks before opening the e-mail or attachment. Infosys reserves = the right to monitor and review the content of all messages sent to or from thi= s e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ dhcwg mailing list dhcwg@ietf.org> https://www.ietf.org/mailman/listinfo/dhcwg From gwz@net-zen.net Tue Apr 28 23:04:48 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3723A6BAD for ; Tue, 28 Apr 2009 23:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmWLnWBBkbIs for ; Tue, 28 Apr 2009 23:04:48 -0700 (PDT) Received: from smtpout05.prod.mesa1.secureserver.net (smtpout05-01.prod.mesa1.secureserver.net [64.202.165.218]) by core3.amsl.com (Postfix) with SMTP id F15513A69A3 for ; Tue, 28 Apr 2009 23:04:47 -0700 (PDT) Received: (qmail 20191 invoked from network); 29 Apr 2009 06:06:09 -0000 Received: from unknown (210.57.242.59) by smtpout05.prod.mesa1.secureserver.net (64.202.165.218) with ESMTP; 29 Apr 2009 06:06:09 -0000 From: "Glen Zorn" To: "'Ralph Droms'" References: <003401c9c170$492fff30$db8ffd90$@net> <8E296595B6471A4689555D5D725EBB210C519CBD@xmb-rtp-20a.amer.cisco.com> <00ba01c9c23c$9cf50760$d6df1620$@net> <2B956B89-503B-41C5-A7CE-BF0529C667D4@cisco.com> In-Reply-To: <2B956B89-503B-41C5-A7CE-BF0529C667D4@cisco.com> Date: Wed, 29 Apr 2009 15:06:06 +0900 Organization: Network Zen Message-ID: <001f01c9c890$970ac100$c5204300$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnDfxD8+gN+rH3XS/K0lz0En/Q/EQFDvo9w Content-Language: en-us Cc: 'Dhcwg WG' , "'Bernie Volz \(volz\)'" Subject: Re: [dhcwg] RAAN & SRSN drafts X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 06:04:48 -0000 Ralph Droms [mailto:rdroms@cisco.com] writes: > Glen - I think Bernie has it right: the options are in two drafts as a > matter of style. Keeping the SRSN option in a separate doc keeps it > easier to find, read and understand. I'm not sure how: all of the text could remain the same -- what we're really talking about is adding a section to a draft. Advancing two dependent drafts simultaneously is always harder than advancing one... > SRSN could certainly be > referenced as part of a doc that defines RAAN. It already is, in http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-02: 9. Reordering received DHCP messages The relay agent MUST use the Server Reply Sequence Number (SRSN) option [4] to detect and discard RAAN options contained in DHCP messages that are received out of order. That's why I made the suggestion: if SRSN MUST be used with RAAN & there aren't any other defined (only potential) uses for the SRSN option, why not keep them together in one place? > > Is there a particular advantage to putting the options in one doc? Reducing 1) the number of documents to advance & 2) keeping dependent options in one place. > > - Ralph > > On Apr 21, 2009, at 12:49 AM 4/21/09, Glen Zorn wrote: > > > Bernie Volz (volz) [mailto:volz@cisco.com] writes: > > > >> I do think they should be. Ralph and I just re-spun the ones that > had > >> expired a while back without making any major changes. > >> > >> While I like the idea of avoiding layer violations which was, at > >> least > >> in my mind, the strongest motivation for RAAN (and thus SRSN), I'm > >> not > >> so sure that this now is a strong enough argument to proceed with > >> RAAN/SRSN because there are already DHCPv6 relay agents that do the > >> layer violations as they had no choice. > > > > Be that as it may, it's nice to have a clean way to do things. > > > >> > >> SRSN might be useful for more than just RAAN (as it provides the > >> 'ordering' data that is missing from DHCPv6 response flows over UDP > >> from > >> the server). > > > > True, but other documents can still reference the definition, > > right? That > > idea was why I didn't suggest pushing everything into one option... > > > > ... > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > From volz@cisco.com Wed Apr 29 04:39:36 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2773A70F4 for ; Wed, 29 Apr 2009 04:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNQ29iHRlkzv for ; Wed, 29 Apr 2009 04:39:35 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8214B3A70DE for ; Wed, 29 Apr 2009 04:39:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,265,1238976000"; d="scan'208";a="42977090" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 29 Apr 2009 11:40:57 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3TBevFT024476; Wed, 29 Apr 2009 07:40:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3TBevmS012286; Wed, 29 Apr 2009 11:40:57 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 07:40:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 07:40:53 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB210C82CE71@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <986DCE2E44129444B6435ABE8C9E424D0320D83B@SGSINSMBS02.ad4.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] DHCPv6 VSIO on a relay agent Thread-Index: AcnEfMg4SuQR6xYCTl+IJfxdzYYz+gEQnZKw References: <986DCE2E44129444B6435ABE8C9E424D0320D83B@SGSINSMBS02.ad4.ad.alcatel.com> From: "Bernie Volz (volz)" To: "MILES DAVID" , X-OriginalArrivalTime: 29 Apr 2009 11:40:57.0157 (UTC) FILETIME=[5C6A9F50:01C9C8BF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1108; t=1241005257; x=1241869257; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20DHCPv6=20VSIO=20on=20a=20rela y=20agent |Sender:=20 |To:=20=22MILES=20DAVID=22=20,=20; bh=5v3VCTXlv/ksWH/DdfI9c+p5kJzMKMaB7tsOq+L/UsE=; b=KyQkHgMk0HKBHv4DeB4FSDwzyVamligFtprsTnXykYvK1YeIJ8JlhE3hJr 3SA6E27lWWEE3h1gQ2lRD6aMW8Y/4/1on5WKxYB4nbUTkpKTZnfh1yAk+Pku 96NP3MXxLm; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [dhcwg] DHCPv6 VSIO on a relay agent X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 11:39:36 -0000 Relay agents already are using this option -- see CableLabs DOCSIS 3.0 specifications. - Bernie=20 -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of MILES DAVID Sent: Thursday, April 23, 2009 9:34 PM To: dhcwg@ietf.org Subject: [dhcwg] DHCPv6 VSIO on a relay agent Relay agents (especially in broadband environments) may wish to embed vendor-specific values into relayed DHCPv6 messages. I want to clarify the intended use of the Vendor-Specific Information Option (17) as the introductory text mentions: This option is used by clients and servers to exchange vendor-specific information. I cannot see any immediate issues in using option 17 on relay agents but want to check opinion. DHCPv4 gave us RFC 4243 specifically for the purpose of relay agent vendor-specific options so I wanted to see whether there was a more appropriate option to use in DHCPv6 than option 17. Cheers, -David _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From mellon@fugue.com Wed Apr 29 10:34:11 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 665D83A7154; Wed, 29 Apr 2009 10:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLJM-+77EFl1; Wed, 29 Apr 2009 10:34:10 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by core3.amsl.com (Postfix) with ESMTP id 4245D28C2C9; Wed, 29 Apr 2009 10:34:10 -0700 (PDT) Received: from [IPv6:2001::53aa:64c:0:2a9b:bcf6:7a2c] (unknown [IPv6:2001:0:53aa:64c:0:2a9b:bcf6:7a2c]) by toccata.fugue.com (Postfix) with ESMTPSA id 2B00234E4507; Wed, 29 Apr 2009 10:35:48 -0700 (MST) Message-Id: <30E0BE17-F10B-4441-8877-D9204EE382EB@fugue.com> From: Ted Lemon To: dhc WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 29 Apr 2009 12:35:30 -0500 X-Mailer: Apple Mail (2.930.3) Cc: netlmm@ietf.org Subject: [dhcwg] Request for review of draft-xia-netlmm-lma-discovery-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 17:34:11 -0000 A new draft came by this morning that needs review by the DHC working group, and I'd like to suggest that people read it. The two things that jump out about this draft are that it uses a DHCPv6 option, and it appears to require that the DHCPv6 server communicate with an AAA server on behalf of the client. So it would be good if some of our DHCP gurus here in the DHC working group could review it and say what they think. Having read the draft myself, I'm curious as to what motivates using the DHCPv6 server for this, and so I am requesting that someone from the netlmm working group briefly summarize the motivation behind this draft and the way it uses DHCPv6 so that we can do an informed review. Thanks! Ted From vijay@wichorus.com Wed Apr 29 10:38:19 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30793A6892; Wed, 29 Apr 2009 10:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2+DgacueZtS; Wed, 29 Apr 2009 10:38:18 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id AB1443A67F0; Wed, 29 Apr 2009 10:38:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 13:39:35 -0400 Message-ID: In-Reply-To: <30E0BE17-F10B-4441-8877-D9204EE382EB@fugue.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Request for review of draft-xia-netlmm-lma-discovery-01.txt Thread-Index: AcnI8OoRka6xP+BqRPmwfnKUCigiWAAAE5uA References: <30E0BE17-F10B-4441-8877-D9204EE382EB@fugue.com> From: "Vijay Devarapalli" To: "Ted Lemon" , "dhc WG" Cc: netlmm@ietf.org Subject: Re: [dhcwg] Request for review of draft-xia-netlmm-lma-discovery-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 17:38:19 -0000 Hi Ted, I am not sure who requested this draft to be reviewed by the DHC WG. There is no consensus in the NETLMM WG at this point for the PMIPv6 MAG function to use DHCPv6 to obtain the LMA IP address. So any DHC WG review would be premature at this point. Vijay > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ted Lemon > Sent: Wednesday, April 29, 2009 10:36 AM > To: dhc WG > Cc: netlmm@ietf.org > Subject: [dhcwg] Request for review of=20 > draft-xia-netlmm-lma-discovery-01.txt >=20 > A new draft came by this morning that needs review by the DHC=20 > working =20 > group, and I'd like to suggest that people read it. The two things =20 > that jump out about this draft are that it uses a DHCPv6 option, and =20 > it appears to require that the DHCPv6 server communicate with an AAA =20 > server on behalf of the client. So it would be good if some of our =20 > DHCP gurus here in the DHC working group could review it and=20 > say what =20 > they think. >=20 > Having read the draft myself, I'm curious as to what motivates using =20 > the DHCPv6 server for this, and so I am requesting that someone from =20 > the netlmm working group briefly summarize the motivation=20 > behind this =20 > draft and the way it uses DHCPv6 so that we can do an informed review. >=20 > Thanks! >=20 > Ted >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 From mellon@fugue.com Wed Apr 29 10:59:30 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1F028C2D9; Wed, 29 Apr 2009 10:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7gSsOYUcLXk; Wed, 29 Apr 2009 10:59:29 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by core3.amsl.com (Postfix) with ESMTP id 9486528C2D6; Wed, 29 Apr 2009 10:59:29 -0700 (PDT) Received: from [IPv6:2001::53aa:64c:0:2a9b:bcf6:7a2c] (unknown [IPv6:2001:0:53aa:64c:0:2a9b:bcf6:7a2c]) by toccata.fugue.com (Postfix) with ESMTPSA id 9DF4234E447F; Wed, 29 Apr 2009 11:01:07 -0700 (MST) Message-Id: <82E7F214-B469-46E8-8EDC-A40FC56E3B37@fugue.com> From: Ted Lemon To: Vijay Devarapalli In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 29 Apr 2009 13:00:49 -0500 References: <30E0BE17-F10B-4441-8877-D9204EE382EB@fugue.com> X-Mailer: Apple Mail (2.930.3) Cc: dhc WG , "netlmm@ietf.org" Subject: Re: [dhcwg] Request for review of draft-xia-netlmm-lma-discovery-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 17:59:30 -0000 On Apr 29, 2009, at 12:39 PM, Vijay Devarapalli wrote: > I am not sure who requested this draft to be reviewed by the DHC WG. > There is no consensus in the NETLMM WG at this point for the PMIPv6 > MAG > function to use DHCPv6 to obtain the LMA IP address. So any DHC WG > review would be premature at this point. My motivation in asking for review of this document before it's been adopted by the netlmm working group as a work item, is that it appears to make a rather novel use of the DHCPv6 protocol. Unless the netlmm working group has already decided not to adopt this draft, I think it makes some sense for you to consider feedback from the DHC working group on the draft when you are deliberating on whether or not to adopt the draft as a netlmm working group item. So if in fact there is no likelihood that the netlmm working group will adopt this draft, it would certainly save us some effort to know that. Otherwise I think actually this is a good time for the DHC working group to give the draft a quick preliminary review. From vijay@wichorus.com Wed Apr 29 11:05:32 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1625C3A6BBD for ; Wed, 29 Apr 2009 11:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu3GDGc+hdiB for ; Wed, 29 Apr 2009 11:05:31 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 3A9B03A6EBA for ; Wed, 29 Apr 2009 11:05:31 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id lQ4a1b0031GXsucA7W6uDt; Wed, 29 Apr 2009 18:06:54 +0000 Received: from [10.166.254.170] ([38.104.122.206]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id lW6e1b00H4THdvq8TW6jR8; Wed, 29 Apr 2009 18:06:52 +0000 Message-ID: <49F89728.6080409@wichorus.com> Date: Wed, 29 Apr 2009 11:06:32 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ted Lemon References: <30E0BE17-F10B-4441-8877-D9204EE382EB@fugue.com> <82E7F214-B469-46E8-8EDC-A40FC56E3B37@fugue.com> In-Reply-To: <82E7F214-B469-46E8-8EDC-A40FC56E3B37@fugue.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: dhc WG , "netlmm@ietf.org" Subject: Re: [dhcwg] Request for review of draft-xia-netlmm-lma-discovery-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 18:05:32 -0000 Ted Lemon wrote: > On Apr 29, 2009, at 12:39 PM, Vijay Devarapalli wrote: >> I am not sure who requested this draft to be reviewed by the DHC WG. >> There is no consensus in the NETLMM WG at this point for the PMIPv6 MAG >> function to use DHCPv6 to obtain the LMA IP address. So any DHC WG >> review would be premature at this point. > > My motivation in asking for review of this document before it's been > adopted by the netlmm working group as a work item, is that it appears > to make a rather novel use of the DHCPv6 protocol. Unless the netlmm > working group has already decided not to adopt this draft, I think it > makes some sense for you to consider feedback from the DHC working group > on the draft when you are deliberating on whether or not to adopt the > draft as a netlmm working group item. > > So if in fact there is no likelihood that the netlmm working group will > adopt this draft, it would certainly save us some effort to know that. > Otherwise I think actually this is a good time for the DHC working group > to give the draft a quick preliminary review. In my personal opinion, the MAG does not have behave as a DHCPv6 client at all. See RFC 5213, that specifies DHCPv6 functions on the MAG and the LMA. So this solution is a non-starter as a solution. Vijay From behcetsarikaya@yahoo.com Wed Apr 29 12:19:35 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997DB3A6889 for ; Wed, 29 Apr 2009 12:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.472 X-Spam-Level: X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25EeNoWN1FXG for ; Wed, 29 Apr 2009 12:19:34 -0700 (PDT) Received: from n7.bullet.re3.yahoo.com (n7.bullet.re3.yahoo.com [68.142.237.92]) by core3.amsl.com (Postfix) with SMTP id 46B5E3A69FB for ; Wed, 29 Apr 2009 12:19:34 -0700 (PDT) Received: from [68.142.230.29] by n7.bullet.re3.yahoo.com with NNFMP; 29 Apr 2009 19:20:56 -0000 Received: from [67.195.9.82] by t2.bullet.re2.yahoo.com with NNFMP; 29 Apr 2009 19:20:55 -0000 Received: from [67.195.9.99] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2009 19:20:55 -0000 Received: from [127.0.0.1] by omp103.mail.gq1.yahoo.com with NNFMP; 29 Apr 2009 19:18:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 486514.37788.bm@omp103.mail.gq1.yahoo.com Received: (qmail 40662 invoked by uid 60001); 29 Apr 2009 19:20:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241032855; bh=kl5U2qb+zyCyVHJ4PC5a6taU4KIo6nWzBnoqKhy/ufk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mlaxiYkPiyq36X0H+8cvOx54HKGCOPOKm5NvhE7GcZseGFFF+W8lXcZqD8IJuTX5sWleWisqUABDG6q6jkVhvvBWzzJrS2enMfd55NnpY2QB/2kFIDooUx+BUIv0hthQQVSzfmc2M3lXUP9EmURgsYRUQ/fxKyQysJsUXddj/xs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=x1TVTVzAVAXZ8UDGM9ghmLNhcv8e+25/z4hs2ufW3z8THyXUpQ/uSg/3BQXwvlo0d8PV7AjSZO/4DJOgdEWt0ydyz+rgIZNMjerHNVgiQQrS/N6z/JDPswhoPI2ka7M6GZY/LhUiRlGjuFScODsrOs72r4dVrYblmMgJJjJOI+c=; Message-ID: <148812.38759.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: _V2WQSQVM1kEJdeZeetXf9q7wVQ1S3alBXEj4V9QZaLgjGijujyRa1couyOALd3TXL6zdphvR2HLb8Qu4ej8gp6GelfK4sO7NBe4XL6L9dJ8E9auqRWzheTj_z66iOiBR4IdagmSH1EDGk.Fz3UqCjjl9oGtT3BCFsEY6vaII_dtz0bHQy4S_gjVXerEIna7UIMVHJiJYrm3Nrcj3.Eb2LAmy0NkDg40Bl5yWT7MJJIJtosCOyBaCDy_reXF9IRR7ZydyvQ3i0xr8GPKuNV9ZO84czG9jUYao5tg.Q8KNIkL08bsFPH3VCt_s84o5Nwpd8ukON0- Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Wed, 29 Apr 2009 12:20:54 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <30E0BE17-F10B-4441-8877-D9204EE382EB@fugue.com> <82E7F214-B469-46E8-8EDC-A40FC56E3B37@fugue.com> Date: Wed, 29 Apr 2009 12:20:54 -0700 (PDT) From: Behcet Sarikaya To: Ted Lemon , Vijay Devarapalli In-Reply-To: <82E7F214-B469-46E8-8EDC-A40FC56E3B37@fugue.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1387963490-1241032854=:38759" Cc: dhc WG , "netlmm@ietf.org" Subject: Re: [dhcwg] Request for review of draft-xia-netlmm-lma-discovery-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 19:19:35 -0000 --0-1387963490-1241032854=:38759 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ted,=0A=A0 The reason we wrote this draft is already stated in netlmm ch= arter (http://www.ietf.org/html.charters/netlmm-charter.html)=A0item 6 whic= h states that:=0A6) Automatic LMA discovery: This will define the ability f= or MAGs to=0Aautomatically discover and use an LMA within a PMIPv6 domain. = The=0Ascope of this effort may include specifying the use of DNS or DHCP=0A= based LMA discovery or LMA discovery using policy information=0Aretrieved v= ia AAA protocols=0A=0A=0A=A0 At the moment we don't know if netlmm will ado= pt this draft. There is another draft co-authored by Vijay which is about s= ome other non-DHCP means of LMA discovery, hence Vijay's intervention here = ..=0A=A0 Based on the above having a quick preliminary review by DHC WG will= be quite helpful to netlmm folks.=0A=A0=0ARegards,=0A=A0=0ABehcet=0AOn Apr= 29, 2009, at 12:39 PM, Vijay Devarapalli wrote:=0A> I am not sure who requ= ested this draft to be reviewed by the DHC WG.=0A> There is no consensus in= the NETLMM WG at this point for the PMIPv6 MAG=0A> function to use DHCPv6 = to obtain the LMA IP address. So any DHC WG=0A> review would be premature a= t this point.=0A=0AMy motivation in asking for review of this document befo= re it's been adopted by the netlmm working group as a work item, is that it= appears to make a rather novel use of the DHCPv6 protocol.=A0 Unless the n= etlmm working group has already decided not to adopt this draft, I think it= makes some sense for you to consider feedback from the DHC working group o= n the draft when you are deliberating on whether or not to adopt the draft = as a netlmm working group item.=0A=0ASo if in fact there is no likelihood t= hat the netlmm working group will adopt this draft, it would certainly save= us some effort to know that.=A0 Otherwise I think actually this is a good = time for the DHC working group to give the draft a quick preliminary review= ..=0A=0A_______________________________________________=0Adhcwg mailing list= =0Adhcwg@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/dhcwg=0A=0A=0A___= _____________________________=0A=0AFrom: Ted Lemon =0ATo:= Vijay Devarapalli =0ACc: dhc WG ; "net= lmm@ietf.org" =0ASent: Wednesday, April 29, 2009 1:00:49 P= M=0ASubject: Re: [dhcwg] Request for review of draft-xia-netlmm-lma-discove= ry-01.txt=0A=0A=0A=0A --0-1387963490-1241032854=:38759 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ted,
=0A
  The reason we wrote this d= raft is already stated in netlmm charter (http://www.ietf.org/html.charters/netlmm-c= harter.html) item 6 which states that:
6)= Automatic LMA discovery: This will define the ability for MAGs to
autom= atically discover and use an LMA within a PMIPv6 domain. The
scope of th= is effort may include specifying the use of DNS or DHCP
based LMA discov= ery or LMA discovery using policy information
retrieved via AAA protocol= s
=0A

=0A
  At the moment we = don't know if netlmm will adopt this draft. There is another draft co-autho= red by Vijay which is about some other non-DHCP means of LMA discovery, hen= ce Vijay's intervention here .
=0A
  Based on the = above having a quick preliminary review by DHC WG will be quite helpful to = netlmm folks.
=0A
 
=0A
Regards,
=0A
 
=0A
Behcet
=0A
=0A
=0A
=0A
From: Ted Lemon <mellon@fugue.com>
= To: Vijay Devarapalli <v= ijay@wichorus.com>
Cc: dhc WG <dhcwg@ietf.org>; "netlmm@ietf.org" <netlmm@ietf.org><= BR>Sent: Wednesday, April 2= 9, 2009 1:00:49 PM
Subject:<= /B> Re: [dhcwg] Request for review of draft-xia-netlmm-lma-discovery-01.txt=

On Apr 29, 2009, at 12:39 PM, Vijay Devarapalli wrote:
&g= t; I am not sure who requested this draft to be reviewed by the DHC WG.
= > There is no consensus in the NETLMM WG at this point for the PMIPv6 MA= G
> function to use DHCPv6 to obtain the LMA IP address. So any DHC W= G
> review would be premature at this point.

My motivation in asking for review of this document before it's been adopted = by the netlmm working group as a work item, is that it appears to make a ra= ther novel use of the DHCPv6 protocol.  Unless the netlmm working grou= p has already decided not to adopt this draft, I think it makes some sense = for you to consider feedback from the DHC working group on the draft when y= ou are deliberating on whether or not to adopt the draft as a netlmm workin= g group item.

So if in fact there is no likelihood that the netlmm w= orking group will adopt this draft, it would certainly save us some effort = to know that.  Otherwise I think actually this is a good time for the = DHC working group to give the draft a quick preliminary review.

____= ___________________________________________
dhcwg mailing list
dhcwg@ietf.or= g
https://www.ietf.org/mailman/listinfo/dhcwg
<= /DIV>

=0A=0A --0-1387963490-1241032854=:38759-- From xiayangsong@huawei.com Wed Apr 29 12:45:31 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BBD13A6DB7; Wed, 29 Apr 2009 12:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.626 X-Spam-Level: X-Spam-Status: No, score=-0.626 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuGBzh4hB2q1; Wed, 29 Apr 2009 12:45:30 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 532BA3A6B0B; Wed, 29 Apr 2009 12:45:30 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIV00KCHO9U9R@szxga02-in.huawei.com>; Thu, 30 Apr 2009 03:46:42 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIV001YKO9UNS@szxga02-in.huawei.com>; Thu, 30 Apr 2009 03:46:42 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIV00290O9R9M@szxml04-in.huawei.com>; Thu, 30 Apr 2009 03:46:42 +0800 (CST) Date: Wed, 29 Apr 2009 14:46:39 -0500 From: Frank Xia To: Vijay Devarapalli , Ted Lemon Message-id: <009a01c9c903$37ebe0a0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <30E0BE17-F10B-4441-8877-D9204EE382EB@fugue.com> <82E7F214-B469-46E8-8EDC-A40FC56E3B37@fugue.com> <49F89728.6080409@wichorus.com> Cc: dhc WG , netlmm@ietf.org Subject: Re: [dhcwg] [netlmm] Request for review ofdraft-xia-netlmm-lma-discovery-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 19:45:31 -0000 Hi Vijay If there is no ready DHCP client function in MAG, we should make it because our job is find a way to solve real business problems. Give you a very relevant example. There is no existing DHCP client function for a mobile router, however, Ralph enables it in his draft http://tools.ietf.org/id/draft-ietf-mext-nemo-pd-02.txt BR Frank ----- Original Message ----- From: "Vijay Devarapalli" To: "Ted Lemon" Cc: "dhc WG" ; Sent: Wednesday, April 29, 2009 1:06 PM Subject: Re: [netlmm] [dhcwg] Request for review ofdraft-xia-netlmm-lma-discovery-01.txt > Ted Lemon wrote: >> On Apr 29, 2009, at 12:39 PM, Vijay Devarapalli wrote: >>> I am not sure who requested this draft to be reviewed by the DHC WG. >>> There is no consensus in the NETLMM WG at this point for the PMIPv6 MAG >>> function to use DHCPv6 to obtain the LMA IP address. So any DHC WG >>> review would be premature at this point. >> >> My motivation in asking for review of this document before it's been >> adopted by the netlmm working group as a work item, is that it appears to >> make a rather novel use of the DHCPv6 protocol. Unless the netlmm >> working group has already decided not to adopt this draft, I think it >> makes some sense for you to consider feedback from the DHC working group >> on the draft when you are deliberating on whether or not to adopt the >> draft as a netlmm working group item. >> >> So if in fact there is no likelihood that the netlmm working group will >> adopt this draft, it would certainly save us some effort to know that. >> Otherwise I think actually this is a good time for the DHC working group >> to give the draft a quick preliminary review. > > In my personal opinion, the MAG does not have behave as a DHCPv6 client at > all. See RFC 5213, that specifies DHCPv6 functions on the MAG and the LMA. > So this solution is a non-starter as a solution. > > Vijay > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm From vijay@wichorus.com Wed Apr 29 13:25:16 2009 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA4703A7168; Wed, 29 Apr 2009 13:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EBV9q9m8eNC; Wed, 29 Apr 2009 13:25:16 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 65E5B3A71A1; Wed, 29 Apr 2009 13:25:15 -0700 (PDT) Received: from 38.104.122.206 ([38.104.122.206]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Wed, 29 Apr 2009 20:26:36 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 29 Apr 2009 13:26:36 -0700 From: Vijay Devarapalli To: Behcet Sarikaya , Ted Lemon Message-ID: Thread-Topic: [dhcwg] Request for review of draft-xia-netlmm-lma-discovery-01.txt Thread-Index: AcnJCMsIWdIF3O3txUqVMCvS2LWfNA== In-Reply-To: <148812.38759.qm@web111403.mail.gq1.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: dhc WG , "netlmm@ietf.org" Subject: Re: [dhcwg] Request for review of draft-xia-netlmm-lma-discovery-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 20:25:17 -0000 Behcet, We had numerous discussions on this in the past. The MAG is not a DHCP client according to any of the specifications we have so far. I don't think it makes sense for the MAG to implement DHCP client functionality just to obtain the LMA IP address. Moreover, the MAG acting as a DHCP client doesn't is not valid in any of the SDO architectures that are using PMIPv6. We shouldn't extend protocols just because we can. Vijay On 4/29/09 12:20 PM, "Behcet Sarikaya" wrote: > Hi Ted, > The reason we wrote this draft is already stated in netlmm charter > (http://www.ietf.org/html.charters/netlmm-charter.html) item 6 which states > that: > 6) Automatic LMA discovery: This will define the ability for MAGs to > automatically discover and use an LMA within a PMIPv6 domain. The > scope of this effort may include specifying the use of DNS or DHCP > based LMA discovery or LMA discovery using policy information > retrieved via AAA protocols > > At the moment we don't know if netlmm will adopt this draft. There is > another draft co-authored by Vijay which is about some other non-DHCP means of > LMA discovery, hence Vijay's intervention here . > Based on the above having a quick preliminary review by DHC WG will be quite > helpful to netlmm folks. > > Regards, > > Behcet > > From: Ted Lemon > To: Vijay Devarapalli > Cc: dhc WG ; "netlmm@ietf.org" > Sent: Wednesday, April 29, 2009 1:00:49 PM > Subject: Re: [dhcwg] Request for review of > draft-xia-netlmm-lma-discovery-01.txt > > On Apr 29, 2009, at 12:39 PM, Vijay Devarapalli wrote: >> I am not sure who requested this draft to be reviewed by the DHC WG. >> There is no consensus in the NETLMM WG at this point for the PMIPv6 MAG >> function to use DHCPv6 to obtain the LMA IP address. So any DHC WG >> review would be premature at this point. > > My motivation in asking for review of this document before it's been adopted > by the netlmm working group as a work item, is that it appears to make a > rather novel use of the DHCPv6 protocol. Unless the netlmm working group has > already decided not to adopt this draft, I think it makes some sense for you > to consider feedback from the DHC working group on the draft when you are > deliberating on whether or not to adopt the draft as a netlmm working group > item. > > So if in fact there is no likelihood that the netlmm working group will adopt > this draft, it would certainly save us some effort to know that. Otherwise I > think actually this is a good time for the DHC working group to give the draft > a quick preliminary review. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > >