From volz@cisco.com Mon Apr 2 08:20:50 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9D921F8629 for ; Mon, 2 Apr 2012 08:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFJhUNYP4riL for ; Mon, 2 Apr 2012 08:20:49 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6821321F8623 for ; Mon, 2 Apr 2012 08:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=1336; q=dns/txt; s=iport; t=1333380049; x=1334589649; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=LS13gR41v0jt6gI2MTXABP1w1AP/HctSCXiqeT+u0RQ=; b=CiT4bH1xb+iolTsc+R9TwOxV5oMqhY+1M0FaprHAkQaZpznaTp9swMB2 cGGcRbi2pt2SbkEj3Kw/4xXI7oLkcZhVmwJYo8VjvuHKhzu6Nk2Gmnv9h 3gxf2ih24nEciC1EjEUz8CTTdgi6/WWnF4vaW8sw+jq9Mz9o+X38heFPK o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJnDeU+tJXG9/2dsb2JhbABFuRCBB4IJAQEBAwEBAQEPAR0KNAsFBwQCAQgQAQQBAQsGFwEGASYfCQgCBAESCBqHYgULmzeeawSQOWMEiFibUIFogwU X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="71385371" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 02 Apr 2012 15:20:49 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q32FKmh5011599; Mon, 2 Apr 2012 15:20:48 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 10:20:48 -0500 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, 2 Apr 2012 10:20:48 -0500 Message-ID: In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D49C0@mbx-01.win.nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] DUID+IAID thread-index: AQHNDk7f4FgtkXLiwESgwgUDJGkpD5aCkfCbgADC4wD//4tAkoAAeMQA//+VNoKAAHcfAP//jNrqAJcejkA= References: <201203300826.q2U8Qx51078004@givry.fdupont.fr><8D23D4052ABE7A4490E77B1A012B6307472D478A@mbx-01.win.nominum.com><8D23D4052ABE7A4490E77B1A012B6307472D4946@mbx-01.win.nominum.com><8D23D4052ABE7A4490E77B1A012B6307472D4986@mbx-01.win.nominum.com>, <8D23D4052ABE7A4490E77B1A012B6307472D49C0@mbx-01.win.nominum.com> From: "Bernie Volz (volz)" To: "Ted Lemon" , "A. Gregory Rabil" X-OriginalArrivalTime: 02 Apr 2012 15:20:48.0771 (UTC) FILETIME=[2ED1ED30:01CD10E4] Cc: dhcwg@ietf.org, Francis Dupont Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:20:50 -0000 Greg: Most of the time the IAID is immaterial unless you want explicit IAIDs to get an explicit address (or prefix delegation). When the client shows up and wants an address or prefix, you give it the reservation based on the Client DUID. If there is a multi-homed client (such as one that has a wired and wireless) and you bridge these networks, you won't be able to assure whether the wired or wireless gets that reservation since they appear on the same "link" to the server, but does that really matter in this case? - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Friday, March 30, 2012 11:12 AM To: A. Gregory Rabil Cc: dhcwg@ietf.org; Francis Dupont Subject: Re: [dhcwg] DUID+IAID > If I want to assign a specific address to the wired interface and a separate, specific address to the wireless interface, how do I know what the IAID will be for each of them? You find out when you get a DHCP packet from each interface, and each packet contains a DUID+IAID, and also contains the hardware address (assuming that you already know which hardware address corresponds to which interface). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Apr 2 08:56:16 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2C421F863F for ; Mon, 2 Apr 2012 08:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JrGXlTTTV46 for ; Mon, 2 Apr 2012 08:56:11 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2CF21F85E7 for ; Mon, 2 Apr 2012 08:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=21828; q=dns/txt; s=iport; t=1333382170; x=1334591770; h=mime-version:subject:date:message-id:from:to; bh=TPCWuWPiyU/tmRCEvBoVgTDS60UXGqCH+xWhemdjBNE=; b=CfYyB0NfAoiLkSK7s2SBXd6UdG5i8qLm0V9l1lqf3nDffBD25jDapFSE PmYXPOAZhhSe3mFvFyjYgLbU4S7ZX/49dQwCdQJmEj1tPmHpJKDhG0tIi QjLoS93/ZxFEzSfjrnxwkUmVq//cJojw9/wTrHtmFE4uYoHrmc+rK5xzg k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAADLeU+tJV2d/2dsb2JhbABDglO2TIEHggsBAgISAQkRA1sBKgYQCAdXAQQbARmHZwueX4EnlxSQOWMEiFibUIFogwU X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208,217";a="71180349" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 02 Apr 2012 15:56:09 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q32Fu96d004169 for ; Mon, 2 Apr 2012 15:56:09 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 10:56:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD10E9.1E5F060E" Date: Mon, 2 Apr 2012 10:56:08 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-troan-dhc-dhcpv6-stateful-issues-00 thread-index: Ac0Q5MgX/amD3onqQTWZNL76hKg8Pg== From: "Bernie Volz (volz)" To: X-OriginalArrivalTime: 02 Apr 2012 15:56:08.0925 (UTC) FILETIME=[1E87C0D0:01CD10E9] Subject: [dhcwg] draft-troan-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:56:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD10E9.1E5F060E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ole submitted the draft-troan-dhc-dhcpv6-stateful-issues-00 draft just before the Paris IETF DHC WG meeting and I presented the http://www.ietf.org/proceedings/83/slides/slides-83-dhc-15.pdf slides at that meeting. =20 Please look over the draft and slides as we are hoping to fast-track these RFC 3315/3633 changes for the RFC 6204bis work. =20 In thinking about this some more since, I believe that encouraging use of Renew (section 3.4 and "Confirm / Renew Handling" slide) is not the best. This "Renew" was to follow the RFC 3633 (section 12.1) requirements: =20 If such verification is needed the requesting router MUST initiate a Rebind/Reply message exchange as described in section 18.1.4, "Creation and Transmission of Rebind Messages" of RFC 3315, with the exception that the retransmission parameters should be set as for the Confirm message, described in section 18.1.2, "Creation and Transmission of Confirm Messages" of RFC 3315. The requesting router includes any IA_PDs, along with prefixes associated with those IA_PDs in its Rebind message. =20 >From RFC 3315: =20 The first Confirm message from the client on the interface MUST be delayed by a random amount of time between 0 and CNF_MAX_DELAY. The client transmits the message according to section 14, using the following parameters: =20 IRT CNF_TIMEOUT =20 MRT CNF_MAX_RT =20 MRC 0 =20 MRD CNF_MAX_RD =20 CNF_MAX_DELAY 1 sec Max delay of first Confirm CNF_TIMEOUT 1 sec Initial Confirm timeout CNF_MAX_RT 4 secs Max Confirm timeout CNF_MAX_RD 10 secs Max Confirm duration =20 Renew is effectively "unicast" to the server that granted the lease(s). Thus: 1. If the client has indeed moved to a new location, or 2. If the client has not moved, but that server is down, The client must always wait 10 seconds (CNF_MAX_RD) before transitioning to sending Rebinds before it can hope to get any feedback (if there is another server present). In many cases, perhaps other information (such as receipt of RAs) might already indicate to the client whether it has likely moved or not? =20 In these cases either using the Confirm or immediately starting with a Rebind has a 10 second advantage. =20 Note also that Confirm has the other advantages outlined in the presentation: 1. It is clear what the client is attempting to do as it doesn't overload the Renew/Rebind requests. 2. It has significant less load on the server since the server does not need to (potentially) extend lifetimes or otherwise record anything about the client/server interaction with respect to these leases (which eliminates any possibility of a write by the server which is generally expensive - especially in a situation where lots of clients might be doing this). The one disadvantage to Confirm is that it provides no useful information to any Relay Agent (CMTS in particular) that might be wanting to gleam information from the transaction. There may also be situations where the Confirm, if used, can't determine if the client has or has not moved in which case the client will get no response to its Confirm - RFC 3315, Section 18.1.2 then states the client SHOULD continue to use the previously obtained information. =20 So what do others think? Do we not consider the 10 second delay to be significant and worth addressing? Do we consider the additional server cost of doing Renew/Rebind processing an issue? =20 - Bernie =20 =20 ------_=_NextPart_001_01CD10E9.1E5F060E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ole = submitted the draft-troan-dhc-dhcpv6-stateful-issues-00 draft just = before the Paris IETF DHC WG meeting and I presented the h= ttp://www.ietf.org/proceedings/83/slides/slides-83-dhc-15.pdf slides = at that meeting.

 

Please look = over the draft and slides as we are hoping to fast-track these RFC = 3315/3633 changes for the RFC 6204bis work.

 

In thinking = about this some more since, I believe that encouraging use of Renew = (section 3.4 and “Confirm / Renew Handling” slide) is not = the best. This “Renew” was to follow the RFC 3633 (section = 12.1) requirements:

 

   If such verification is needed the requesting router = MUST initiate a

   Rebind/Reply message exchange as described in section = 18.1.4,

   "Creation and Transmission of Rebind = Messages" of RFC 3315, with the

   exception that the = retransmission parameters should be set as for = the

   Confirm message, described in section 18.1.2, = "Creation and

   Transmission of Confirm Messages" of RFC = 3315.  The requesting router

   includes any IA_PDs, = along with prefixes associated with those IA_PDs

   = in its Rebind message.

 

From RFC = 3315:

 

   The first Confirm = message from the client on the interface MUST be

   delayed by a random = amount of time between 0 and CNF_MAX_DELAY.  = The

   client transmits the message according to section 14, = using the

   following parameters:

 

      = IRT   CNF_TIMEOUT

 

      MRT   = CNF_MAX_RT

 

      MRC   = 0

 

      = MRD   CNF_MAX_RD

 

   CNF_MAX_DELAY     1 = sec   Max delay of first Confirm

   = CNF_TIMEOUT       1 sec   = Initial Confirm timeout

   CNF_MAX_RT        = 4 secs  Max Confirm timeout

   = CNF_MAX_RD       10 secs  Max Confirm = duration

 

Renew is = effectively “unicast” to the server that granted the = lease(s). Thus:

1.       If = the client has indeed moved to a new location, or

2.       If = the client has not moved, but that server is down,

The client must always wait 10 seconds (CNF_MAX_RD) = before transitioning to sending Rebinds before it can hope to get any = feedback (if there is another server present). In many cases, perhaps = other information (such as receipt of RAs) might already indicate to the = client whether it has likely moved or not?

 

In these = cases either using the Confirm or immediately starting with a Rebind has = a 10 second advantage.

 

Note also = that Confirm has the other advantages outlined in the = presentation:

1.       It = is clear what the client is attempting to do as it doesn’t = overload the Renew/Rebind requests.

2.       It = has significant less load on the server since the server does not need = to (potentially) extend lifetimes or otherwise record anything about the = client/server interaction with respect to these leases (which eliminates = any possibility of a write by the server which is generally expensive = – especially in a situation where lots of clients might be doing = this).

The one disadvantage to = Confirm is that it provides no useful information to any Relay Agent = (CMTS in particular) that might be wanting to gleam information from the = transaction. There may also be situations where the Confirm, if used, = can’t determine if the client has or has not moved in which case = the client will get no response to its Confirm – RFC 3315, Section = 18.1.2 then states the client SHOULD continue to use the previously = obtained information.

 

So what do = others think? Do we not consider the 10 second delay to be significant = and worth addressing? Do we consider the additional server cost of doing = Renew/Rebind processing an issue?

 

-          = Bernie

 

 

------_=_NextPart_001_01CD10E9.1E5F060E-- From greg.rabil@jagornet.com Mon Apr 2 18:05:35 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAC021F86F4 for ; Mon, 2 Apr 2012 18:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LioBqJCbzCn2 for ; Mon, 2 Apr 2012 18:05:35 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF97821F86F1 for ; Mon, 2 Apr 2012 18:05:34 -0700 (PDT) Received: by bkuw5 with SMTP id w5so3125309bku.31 for ; Mon, 02 Apr 2012 18:05:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=CPJiKE2+06S63DVk3/4muAfmOJsvw/YQ/vMI9YoG8aI=; b=hR28gRyP3S5pcDDvJeb6nTi9A1DILHLvD8L2FfnvtcJaGWWsIhNj/aGZjVJSyCpT+o /azQmlj5F58NXm0AhkU9SlOyrxMn5oZR60pohTCI7eeizcEZEsBCXqRG/z+56IinUQJh L1ilSXuJBCM2BO7PPcb5nqUGdkrc7QLDAfexL3MgRoLin2i6/bZ6Y3k5TcwoRW7YJBgD DEp5G2uXQ9Zm+7+kRukuAynIqrh22pUSivnKm14nzaEdnbAm6jNGfg9vfRUGvjE4OcY3 zym5mYz9Cxh1LiVLT4qv5vf9M+4tnnFetCBjssoYxkbyVk6T3yd8luGmT7cukhQfUlLx 5Ehg== MIME-Version: 1.0 Received: by 10.204.154.28 with SMTP id m28mr4367663bkw.102.1333415133610; Mon, 02 Apr 2012 18:05:33 -0700 (PDT) Received: by 10.204.22.4 with HTTP; Mon, 2 Apr 2012 18:05:33 -0700 (PDT) In-Reply-To: References: <201203300826.q2U8Qx51078004@givry.fdupont.fr> <8D23D4052ABE7A4490E77B1A012B6307472D478A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D4946@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D4986@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472D49C0@mbx-01.win.nominum.com> Date: Mon, 2 Apr 2012 21:05:33 -0400 Message-ID: From: "A. Gregory Rabil" To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=0015175d03d260820104bcbbe741 X-Gm-Message-State: ALoCoQmt6B8kvUYcbZdEHoQXUlZglQunlV4xzjDjeq5jAs/M/1iQFjGNVXK8sxS7y0Q272cDBbux Cc: dhcwg@ietf.org, Francis Dupont , Ted Lemon Subject: Re: [dhcwg] DUID+IAID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 01:05:35 -0000 --0015175d03d260820104bcbbe741 Content-Type: text/plain; charset=ISO-8859-1 Hi Bernie, > If there is a multi-homed client (such as one that has a wired and > wireless) and you bridge these networks, you won't be able to assure > whether the wired or wireless gets that reservation since they appear on > the same "link" to the server, but does that really matter in this case? Maybe, maybe not. For example, an administrator may wish to favor the wired interface for the reservation. Provided requests from each interface are sent separately, and contain the proposed link-layer-addr for the interface on which the request is sent, then I suppose they could configure it via the mac as they would in DHCPv4. I do understand why this may be a bad idea, but some admins just want to configure things using the same tag (notice I didn't say identifier ;-)) they are used to using. Greg --0015175d03d260820104bcbbe741 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Bernie,

> If there is a multi-homed client (= such as one that has a wired and
> wireless) and you bridge these net= works, you won't be able to assure
> whether the wired or wireles= s gets that reservation since they appear on
> the same "link" to the server, but does that really matter i= n this case?

Maybe, maybe not. =A0For example, an admini= strator may wish to favor
the wired interface for the reservation= . =A0Provided requests from each
interface are sent separately, and contain the proposed link-layer-add= r
for the interface on which the request is sent, then I suppose = they
could configure it via the mac as they would in DHCPv4. =A0I= do
understand why this may be=A0a bad idea, but some=A0admins just want= =A0
to=A0configure things using the same tag (notice I didn't= say
identifier ;-)) they are used to using.

=
Greg

--0015175d03d260820104bcbbe741-- From mohamed.boucadair@orange.com Tue Apr 3 23:35:55 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288B021F8737 for ; Tue, 3 Apr 2012 23:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYsvdJRzhDfj for ; Tue, 3 Apr 2012 23:35:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0D57921F8621 for ; Tue, 3 Apr 2012 23:35:49 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id CFBA522C545; Wed, 4 Apr 2012 08:35:48 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id B39AA35C045; Wed, 4 Apr 2012 08:35:48 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 4 Apr 2012 08:35:48 +0200 From: To: "dhcwg@ietf.org" Date: Wed, 4 Apr 2012 08:35:46 +0200 Thread-Topic: Review Request for draft-ietf-softwire-multicast-prefix-option Thread-Index: Ac0SLSr8tWiA8sp1Q3KSsttchfwVDw== Message-ID: <94C682931C08B048B7A8645303FDC9F36E28806652@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E28806652PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.3.143318 Cc: Xiaohong Deng , Jacni Qin Subject: [dhcwg] Review Request for draft-ietf-softwire-multicast-prefix-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 06:35:55 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E28806652PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Softiwre WG adopted recently this document: http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix-option-00 Comments from DHC WG are are more than welcome. Thanks. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36E28806652PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear=20 all,
 
S= oftiwre WG=20 adopted recently this document:
<= SPAN=20 class=3D268433512-29032012>http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix-opt= ion-00
 
Comments from DHC WG are are more than welcome.=20 Thanks.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F36E28806652PUEXCB1Bnante_-- From Ted.Lemon@nominum.com Wed Apr 4 09:04:51 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13FD21F87E1 for ; Wed, 4 Apr 2012 09:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.289 X-Spam-Level: X-Spam-Status: No, score=-106.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkuPauH9LNlk for ; Wed, 4 Apr 2012 09:04:51 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 179BB21F8872 for ; Wed, 4 Apr 2012 09:04:51 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT3xxIrIie/sz2pzZebPlHXiKr21eWcda@postini.com; Wed, 04 Apr 2012 09:04:51 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 26E121B8225 for ; Wed, 4 Apr 2012 09:04:50 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1D520190064; Wed, 4 Apr 2012 09:04:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Wed, 4 Apr 2012 09:04:50 -0700 From: Ted Lemon To: " " Thread-Topic: [dhcwg] Review Request for draft-ietf-softwire-multicast-prefix-option Thread-Index: Ac0SLSr8tWiA8sp1Q3KSsttchfwVDwAiiq6A Date: Wed, 4 Apr 2012 16:04:49 +0000 Message-ID: <411D32D0-5D15-4784-B1EE-09997940784E@nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E28806652@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E28806652@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Xiaohong Deng , Jacni Qin Subject: Re: [dhcwg] Review Request for draft-ietf-softwire-multicast-prefix-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:04:51 -0000 Why is this a single option? It seems like you are conveying three separa= te pieces of information, not all of which will be populated, so it would b= e better to have three options, and then the client can request all three, = and the server can return the ones that are configured? Or am I misunders= tanding what you are trying to do here? From mohamed.boucadair@orange.com Wed Apr 4 09:21:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D261821F8792 for ; Wed, 4 Apr 2012 09:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtNkRZSMsbsy for ; Wed, 4 Apr 2012 09:21:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 301EF21F8783 for ; Wed, 4 Apr 2012 09:21:11 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 00B8F2DC12E; Wed, 4 Apr 2012 18:21:10 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id DA070238055; Wed, 4 Apr 2012 18:21:09 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 4 Apr 2012 18:21:09 +0200 From: To: Ted Lemon Date: Wed, 4 Apr 2012 18:21:08 +0200 Thread-Topic: [dhcwg] Review Request for draft-ietf-softwire-multicast-prefix-option Thread-Index: Ac0SLSr8tWiA8sp1Q3KSsttchfwVDwAiiq6AAA58iqA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E288069F8@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E28806652@PUEXCB1B.nanterre.francetelecom.fr> <411D32D0-5D15-4784-B1EE-09997940784E@nominum.com> In-Reply-To: <411D32D0-5D15-4784-B1EE-09997940784E@nominum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.4.135415 Cc: "dhcwg@ietf.org" , Xiaohong Deng , Jacni Qin Subject: Re: [dhcwg] Review Request for draft-ietf-softwire-multicast-prefix-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:21:12 -0000 Dear Ted, Yes, we can do. FYI, we defined these as separate sub-options in http://tools.ietf.org/html= /draft-qin-softwire-multicast-prefix-option-01 but the authors finally agre= ed to define it as a single option. We thought it was more simple. A more s= erious issue is to associate the provisioned U_PREFIX64 with the multicast = service and avoid using it for unicast. An example would be a provider depl= oying NAT64 with a dedicated PREFIX64 (RFC6052) distinct from the one used = for IPv4/IPv6 multicast. Having all these pieces of information in one sing= le packet ensures the provisioned information will be used only for multica= st services. Cheers, Med >-----Message d'origine----- >De : Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 >Envoy=E9 : mercredi 4 avril 2012 18:05 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : dhcwg@ietf.org; Xiaohong Deng; Jacni Qin >Objet : Re: [dhcwg] Review Request for=20 >draft-ietf-softwire-multicast-prefix-option > >Why is this a single option? It seems like you are conveying=20 >three separate pieces of information, not all of which will be=20 >populated, so it would be better to have three options, and=20 >then the client can request all three, and the server can=20 >return the ones that are configured? Or am I=20 >misunderstanding what you are trying to do here? > >= From mohamed.boucadair@orange.com Wed Apr 4 09:25:28 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B03021F883E for ; Wed, 4 Apr 2012 09:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhmPNvf2lAv3 for ; Wed, 4 Apr 2012 09:25:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id AD99B21F8823 for ; Wed, 4 Apr 2012 09:25:27 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1D43B18C4C4; Wed, 4 Apr 2012 18:25:27 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 01ED727C046; Wed, 4 Apr 2012 18:25:27 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 4 Apr 2012 18:25:26 +0200 From: To: Ted Lemon Date: Wed, 4 Apr 2012 18:25:25 +0200 Thread-Topic: [dhcwg] Review Request for draft-ietf-softwire-multicast-prefix-option Thread-Index: Ac0SLSr8tWiA8sp1Q3KSsttchfwVDwAiiq6AAA58iqAAHIgFwA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E288069FE@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E28806652@PUEXCB1B.nanterre.francetelecom.fr> <411D32D0-5D15-4784-B1EE-09997940784E@nominum.com> <94C682931C08B048B7A8645303FDC9F36E288069F8@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E288069F8@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.4.135415 Cc: "dhcwg@ietf.org" , Xiaohong Deng , Jacni Qin Subject: Re: [dhcwg] Review Request for draft-ietf-softwire-multicast-prefix-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:25:28 -0000 >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de mohamed.boucadair@orange.com >Envoy=E9 : mercredi 4 avril 2012 18:21 >=C0 : Ted Lemon >Cc : dhcwg@ietf.org; Xiaohong Deng; Jacni Qin >Objet : Re: [dhcwg] Review Request for=20 >draft-ietf-softwire-multicast-prefix-option > >Dear Ted, > >Yes, we can do. To avoid confusion, I meant we could do it that way but we prefer to have o= ne single option for the reason explained below. > >FYI, we defined these as separate sub-options in=20 >http://tools.ietf.org/html/draft-qin-softwire-multicast-prefix- >option-01 but the authors finally agreed to define it as a=20 >single option. We thought it was more simple. A more serious=20 >issue is to associate the provisioned U_PREFIX64 with the=20 >multicast service and avoid using it for unicast. An example=20 >would be a provider deploying NAT64 with a dedicated PREFIX64=20 >(RFC6052) distinct from the one used for IPv4/IPv6 multicast.=20 >Having all these pieces of information in one single packet=20 >ensures the provisioned information will be used only for=20 >multicast services. > >Cheers, >Med > >>-----Message d'origine----- >>De : Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 >>Envoy=E9 : mercredi 4 avril 2012 18:05 >>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : dhcwg@ietf.org; Xiaohong Deng; Jacni Qin >>Objet : Re: [dhcwg] Review Request for=20 >>draft-ietf-softwire-multicast-prefix-option >> >>Why is this a single option? It seems like you are conveying=20 >>three separate pieces of information, not all of which will be=20 >>populated, so it would be better to have three options, and=20 >>then the client can request all three, and the server can=20 >>return the ones that are configured? Or am I=20 >>misunderstanding what you are trying to do here? >> >> >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >= From laurent.thiebaut@alcatel-lucent.com Thu Apr 5 05:46:39 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A200E21F8691 for ; Thu, 5 Apr 2012 05:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.648 X-Spam-Level: X-Spam-Status: No, score=-9.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lapoe5Mcx0lc for ; Thu, 5 Apr 2012 05:46:36 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1149221F8417 for ; Thu, 5 Apr 2012 05:46:35 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q35Cg7aL020946 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Apr 2012 14:46:27 +0200 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 5 Apr 2012 14:46:01 +0200 From: "THIEBAUT, LAURENT (LAURENT)" To: "dhcwg@ietf.org" , "shwethab@cisco.com" Date: Thu, 5 Apr 2012 14:46:01 +0200 Thread-Topic: Comments on draft-bhandari-dhc-class-based-prefix Thread-Index: Ac0TKg5fU1U46I++QVmuEChI3Dn6Dw== Message-ID: <170E8FCC2134BD42B539B47798ABF8F0133B2C8BBD@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_170E8FCC2134BD42B539B47798ABF8F0133B2C8BBDFRMRSSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [dhcwg] Comments on draft-bhandari-dhc-class-based-prefix X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 12:46:39 -0000 --_000_170E8FCC2134BD42B539B47798ABF8F0133B2C8BBDFRMRSSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Shwetha, hello all As a follow up of the discussion we have had in Paris, please a few comment= s on this very interesting ID 1. As opposed to the "OPTION_USER_CLASS" whose semantics is undefined = and whose impact to the system is loosely defined, the new "PREFIX_CLASS op= tion" allows a well defined structure to ensure inter-operability beyond a = corporate proprietary usage, i.e. to make sure that different organisations= cannot allocate the same value for the "PREFIX_CLASS option". Indeed the d= efinition and structure and indication of usage of the "User Class Option" = is too loose to guarantee inter-operability beyond a corporate deployment 22.15. User Class Option The User Class option is used by a client to identify the type or category = of user or applications it represents. ... The information contained in the data area of this option is contained in o= ne or more *opaque* fields that represent the user class or classes of whic= h the client is a member. A server selects configuration information for t= he client based on the classes identified in this option. For example, the= User Class option can be used to configure all clients of people in the ac= counting department with a different printer than clients of people in the = marketing department. The user class information carried in this option MU= ST be configurable on the client. ...... (The "User Class Option" can't be used in a non proprietary context as diff= erent organisations can by accident allocate the same value to this informa= tion) This comment is an < endorsement" of draft-bhandari-dhc-class-based-prefix 2. The "PREFIX_CLASS option" should allow to specify * Prefix-classes defined by IETF * Prefix classes defined by other standard fora * (proprietary) Prefix classes defined by a corporate 3. The proposed structure would be as follows * "Prefix class name space" with 2 values: "IETF" / "other organisation" * "Prefix class owner" (required in case the "Prefix class name space" i= s "other organisation", not present when "Prefix class name space" is "IETF= "). Other organisation may be another standard forum (e.g. BBF) or a corpor= ate. * "Prefix class value" whose structure depends on the "Prefix class name= space" and "Prefix class owner" 4. As the "User Class Option" does not benefit from such structure it = cannot be used beyond a corporate proprietary usage. Thus the "User Class O= ption" cannot provide an interoperable parameter to be used when a DHCP cli= ent sends an Information-Request message to obtain (IP) configuration infor= mation. Following alternatives may be envisaged: a) Either the "PREFIX_CLASS option" is used in Information-Request. It= is agreed that the name "PREFIX_CLASS option" would then not be well suite= d for usage in Information-Request and that thus the name of this option sh= ould be changed. b) Another possibility is to define a "configuration-information-class= option" whose semantics is explicitly made the same as the "PREFIX_CLASS o= ption" and to be used as follows: o The DHCP client puts a "configuration-information-class option"in= Information-Request to request that the IP parameters values sent by the D= HCP server are determined as the most suitable for the IP service associate= d with the "configuration-information-class option" o when a DHCPv6 client sends a SOLICIT message to request both * for IA_NA address allocation from a specific prefix class * and to obtain (IP) configuration information using Option Request= option (per RFC 3315 section 22.7) it populates the SOLICIT message as follows: * within the IA_NA option, it includes the OPTION_PREFIX_CLASS requ= esting address to be allocated from a specific prefix class indicated in th= at option * within the Option Request option (per RFC 3315 section 22.7) it i= ncludes the "configuration-information-class option" requesting configurati= on parameters sent by the DHCP server are determined as the most suitable f= or the IP service associated with the "configuration-information-class opti= on". If these comments are felt useful, I can provide actual text for the draft. Best regards Laurent --_000_170E8FCC2134BD42B539B47798ABF8F0133B2C8BBDFRMRSSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /span>

 <= /span>

Hello Shwetha, hello all

As a follow up of the discussion we have had in Paris, please a few comments on this ve= ry interesting ID

1.=       As opposed to the “OPTION_USER_CLA= SS” whose semantics is undefin= ed and whose impact to the system is loosely defined, the new “PREFIX_CLASS option” allows a well defined structure to ensure inter-operability beyond a corporate proprietary usage, i.e. to make sure that different organisations cannot allocate the same value for the “PREFIX_CLASS option”. Indeed the definition and structure and indication of usage of the “<= /font>User Class Option” is too loose to guarantee inter-operability beyond a corporate deployment

22.15. User Class Option=

The User Class option is used by a = client to identify the type or category of user or applications it represents.

…

 

The information contained in the da= ta area of this option is contained in one or more *opaque* fields that represent the user class or classes of which the client is a member.  A server selects configuration information for the client bas= ed on the classes identified in this option.  For example, the User Class option can be used to configure all clients of people in the accounting department with a different printer than clients of people in the marketing= department.  The user class information carried in this option MUST be configurable on t= he client.

   ……

(The “User Class Option” can’t be used in a= non proprietary context as different organisations can by accident allocate the same value to this information)

This comment is an « endorsement” of draft-b= handari-dhc-class-based-prefix

 

2.=       The “PREFIX_CLASS op= tion” should allow to specify

  • Prefix-classes defined by IETF<= /span>
  • Prefix classes defined by other standard f= ora
  • (proprietary) Prefix classes defined by a corporate

 

 

3.=       The proposed structure would be as follows<= /font>

  • “Prefix class name space” with= 2 values: “IETF” / “other organisation”
  • “Prefix class owner” (required= in case the “Prefix class name space” is “other organisation”, not present when “Prefix class name space” is “IETF”). Other organisation may be another standard forum (e.g. BBF) or a corporate.
  • “Prefix class value” whose structure depends on the “Prefix class name space” and “Prefix class owner”

 

 

4.=       As the “User Class Opt= ion” does not benefit from such structure it cannot be used beyond a corporate proprietary usage. Thus the = “User Class Option” cannot provide an interoperable parameter to be used when a DHCP client sen= ds an Information-Request message to obtain (IP) configuration information. Following alternatives may be envisaged:

a)=       Either the “PREFIX_CLASS op= tion” is used in Information-Req= uest. It is agreed that the name “PREFIX_CLASS op= tion” would then not be well sui= ted for usage in Information-Request and that thus the name of this option shou= ld be changed.

b)=       Another possibility is to define a “configuration-informa= tion-class option” whose semantics is explicitly made the same as the “PREFIX_CLASS option” and to be used as follows:

o      =   The DHCP client  puts a “configuration-information-class option”in Information-Request to request = that the IP parameters values sent by the DHCP server are determined as the most suitable for the IP service associated with the “configuration-information-class option”

o      =   when a DHCPv6 client sends a SOLICIT message to request both<= o:p>

·<= span style=3D'font:7.0pt "Times New Roman"'>      =    for IA_NA address allocation from a specific prefix class

·<= span style=3D'font:7.0pt "Times New Roman"'>      =    and to obtain (IP) configuration information using Option Req= uest option (per RFC 3315 section 22.7)

it populates the SOLICIT message as follows:

·<= span style=3D'font:7.0pt "Times New Roman"'>      =    within the IA_NA option, it includes the OPTION_PREFIX_CLASS requesting address to be allocated from a specific prefix class indicated i= n that option

·<= span style=3D'font:7.0pt "Times New Roman"'>      =    within the Option Request option (per RFC 3315 section 22.7) = it includes the “configuration-information-class option” requesting configuration parameters sent by the DHCP server are determined as the most suitable for the IP service associated with the “configuration-information-class option”.

 

If these comments are felt useful, I can provide actual text for the draft.

Best regards

Laurent

 

--_000_170E8FCC2134BD42B539B47798ABF8F0133B2C8BBDFRMRSSXCHMBSA_-- From Internet-Drafts@ietf.org Thu Apr 5 09:51:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B5621F8715; Thu, 5 Apr 2012 09:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82qTHoJ2uqgv; Thu, 5 Apr 2012 09:51:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA68221F86B5; Thu, 5 Apr 2012 09:51:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120405165111.13091.4498.idtracker@ietfa.amsl.com> Date: Thu, 05 Apr 2012 09:51:11 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-subnet-alloc-13.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 16:51:12 -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 : Description of Cisco Systems' Subnet Allocation Option for DHCPv4 Author(s) : J. Kumarasamy, et al Filename : draft-ietf-dhc-subnet-alloc Pages : 30 Date : April 5, 2012 This memo documents a currently existing and previously privately defined DHCPv4 option, documenting the operation and usage of the Cisco Systems Subnet Allocation Option for DHCPv4. The option is passed between the DHCPv4 Client and the DHCPv4 Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with [RFC3942], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-alloc-13.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-subnet-alloc"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-04-05095111.I-D@ietf.org> --NextPart-- From volz@cisco.com Thu Apr 5 10:25:32 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F6521F86B2 for ; Thu, 5 Apr 2012 10:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9SbAmOvaS+D for ; Thu, 5 Apr 2012 10:25:32 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id ECBA921F86B3 for ; Thu, 5 Apr 2012 10:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=5191; q=dns/txt; s=iport; t=1333646731; x=1334856331; h=mime-version:subject:date:message-id:from:to; bh=lcw2QJyW4Y2EaWuMA4MqRZQ3kPTjzhKztqJN5XXjBxw=; b=KezujRlideL2jXzwUnC6YpIZza/1nFlwGLTVuDBmgL6G/dlPiZkuwiBp cnNeKD1TrNpyzWKLachFrze79rqPTR6sK6Pd4QeMSXt8Rn02e9QO9/F+E 2pQGXE+TgTvHZz0fEnQdm4ocEYqoNouC4Ys9McT/3v6NNInDTJy3I6/t8 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkEAIXUfU9Io8UY/2dsb2JhbABFgkatO4l1ggsBBBIBCREDWwEqBhgHVwEEGxqHbJligSefbI02gkFjBIhZm12BaYMF X-IronPort-AV: E=Sophos;i="4.75,377,1330905600"; d="scan'208,217";a="9406995" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 05 Apr 2012 17:25:28 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q35HP5XX028148 for ; Thu, 5 Apr 2012 17:25:27 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 12:25:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1351.173671F3" Date: Thu, 5 Apr 2012 12:25:25 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item Thread-Index: Ac0TUOeZoRGLLxAbQp6n2pMNymotwQ== From: "Bernie Volz (volz)" To: X-OriginalArrivalTime: 05 Apr 2012 17:25:27.0009 (UTC) FILETIME=[176FBD10:01CD1351] Subject: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 17:25:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1351.173671F3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the Paris IETF-83 DHC WG meeting there was a lot of support for (and I believe no opposition) adopting this as a DHC WG item. =20 I kindly request that we adopt this document as a DHC WG work item. =20 - Bernie ------_=_NextPart_001_01CD1351.173671F3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the = Paris IETF-83 DHC WG meeting there was a lot of support for (and I = believe no opposition) adopting this as a DHC WG item.

 

I kindly = request that we adopt this document as a DHC WG work = item.

 

-          = Bernie

------_=_NextPart_001_01CD1351.173671F3-- From Ted.Lemon@nominum.com Thu Apr 5 10:34:48 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60E321F8776 for ; Thu, 5 Apr 2012 10:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.402 X-Spam-Level: X-Spam-Status: No, score=-106.402 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfv8N0cE3y-I for ; Thu, 5 Apr 2012 10:34:48 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id E5DCD21F8766 for ; Thu, 5 Apr 2012 10:34:47 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT33Xt1GrkalVVGp3ytOBQ29RL6Gc8NLo@postini.com; Thu, 05 Apr 2012 10:34:48 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C10781B829E for ; Thu, 5 Apr 2012 10:34:46 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B8653190064 for ; Thu, 5 Apr 2012 10:34:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 5 Apr 2012 10:34:46 -0700 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item Thread-Index: AQHNE1Jkl7tgtOxKmkWYH3w2Igkw0Q== Date: Thu, 5 Apr 2012 17:34:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_DDF37113DA0247E4BD64828C9C5C384Bnominumcom_" MIME-Version: 1.0 Subject: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 17:34:49 -0000 --_000_DDF37113DA0247E4BD64828C9C5C384Bnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) > wrote: At the Paris IETF-83 DHC WG meeting there was a lot of support for (and I b= elieve no opposition) adopting this as a DHC WG item. I kindly request that we adopt this document as a DHC WG work item. This draft documents issues that have come up involving interactions betwee= n prefix delegation and regular IP address allocation in practice. If you= would like the working group to work on documenting this, please signify b= y responding to this message in the affirmative. If you don't think we sh= ould work on it, please respond in the negative. If you have no opinion, = please do not respond. We will determine consensus on Thursday, April 19. --_000_DDF37113DA0247E4BD64828C9C5C384Bnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
At the Paris IETF-83 DHC WG meeting there was a lot of support for (and I b= elieve no opposition) adopting this as a DHC WG item.
 
I kindly request that we adopt this document as a DHC WG work item.

This draft documents issues that have come up involving interactions b= etween prefix delegation and regular IP address allocation in practice. &nb= sp; If you would like the working group to work on documenting this, please= signify by responding to this message in the affirmative.   If you don't think we should work on it, please= respond in the negative.   If you have no opinion, please do not resp= ond.

We will determine consensus on Thursday, April 19. 

--_000_DDF37113DA0247E4BD64828C9C5C384Bnominumcom_-- From kkinnear@cisco.com Thu Apr 5 11:25:02 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FD321F869D for ; Thu, 5 Apr 2012 11:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8igaX9weoans for ; Thu, 5 Apr 2012 11:25:01 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 49CF721F84B5 for ; Thu, 5 Apr 2012 11:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kkinnear@cisco.com; l=1037; q=dns/txt; s=iport; t=1333650293; x=1334859893; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=UemQe9+kieN+WWeFpcrYQOB/vwv2WSNF2aYhAoRKPGc=; b=nJVeCIC9UFYsOPrbjfFTj/MHknTG/Ufjcb2xMqCqJH1V98ptlFWIeIYY Sx9x4KyPa+J1zfiqYnJZBDWaJkRl8Xy/1CiEuV3/NlnybZwTXTwHQF4+R cklfhMJvEuLbeewNAfTKCCkqgERfKZ3of7Fi+4OD8FSTNPj8dJYxYGhLa 8=; X-IronPort-AV: E=Sophos;i="4.75,377,1330905600"; d="scan'208";a="72402315" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 05 Apr 2012 18:24:53 +0000 Received: from [161.44.65.102] ([161.44.65.102]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q35IOqZa019826; Thu, 5 Apr 2012 18:24:52 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Kim Kinnear In-Reply-To: Date: Thu, 5 Apr 2012 14:25:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6823A379-9521-4222-B855-BFAFE6D408E0@cisco.com> References: To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org WG" , Kim Kinnear Subject: Re: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 18:25:02 -0000 I support adopting this as a DHC WG work item. Regards -- Kim On Apr 5, 2012, at 1:34 PM, Ted Lemon wrote: > On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) wrote: >> At the Paris IETF-83 DHC WG meeting there was a lot of support for = (and I believe no opposition) adopting this as a DHC WG item. >> =20 >> I kindly request that we adopt this document as a DHC WG work item. >=20 > This draft documents issues that have come up involving interactions = between prefix delegation and regular IP address allocation in practice. = If you would like the working group to work on documenting this, = please signify by responding to this message in the affirmative. If = you don't think we should work on it, please respond in the negative. = If you have no opinion, please do not respond. >=20 > We will determine consensus on Thursday, April 19.=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From daryl.tanner@blueyonder.co.uk Thu Apr 5 15:58:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BCA21F8655 for ; Thu, 5 Apr 2012 15:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1zYDsh0V7xm for ; Thu, 5 Apr 2012 15:58:09 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A890A21F864B for ; Thu, 5 Apr 2012 15:58:09 -0700 (PDT) Received: by iazz13 with SMTP id z13so2854789iaz.31 for ; Thu, 05 Apr 2012 15:58:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ybRW+SbFy+i5F9ddJCiSzaMyOqMACLqTI1zwjEUkLp8=; b=fxTSkWBuTSxKVa1DeNhYUKqtAnvq6cSSibHCLd1uEzS+B8P1QQ7EWpaoKEjHnTkhGi azsASW0wq51+Eeq7WWyQzPYwoZB66fcXO02SUqZakeRUK4VEvz1bVCn5rXCR3ammVHec yuaB2Eu6M1FViCLwl7axTI3WPUqIY6Zi+FvWnhdOrIJ1KJ3gi+fNRydOwKp6pjWneTqO dvxgM8maxRJep4TmDVm+vc3sCNL3aRKW721QfhDRob7Z4KMeAS7qjxuZoIXbre4ytcPU 1wDoYfLqCwsHAPHHb6J7QYesQl8PQOav+3ShCcM+9ZCfpV0WRbceA9imdMJ8v3cf6vZY Y8qQ== MIME-Version: 1.0 Received: by 10.50.192.134 with SMTP id hg6mr3593411igc.59.1333666689043; Thu, 05 Apr 2012 15:58:09 -0700 (PDT) Received: by 10.42.225.67 with HTTP; Thu, 5 Apr 2012 15:58:08 -0700 (PDT) X-Originating-IP: [92.239.43.71] In-Reply-To: <6823A379-9521-4222-B855-BFAFE6D408E0@cisco.com> References: <6823A379-9521-4222-B855-BFAFE6D408E0@cisco.com> Date: Thu, 5 Apr 2012 23:58:08 +0100 Message-ID: From: Daryl Tanner To: Kim Kinnear Content-Type: multipart/alternative; boundary=14dae93411df3fcea204bcf67973 X-Gm-Message-State: ALoCoQnlzkByjooTRzK+2O9auNRgOqnsBgQoIJ3gp/VPE6FYeb1D0vkj3FbnN0p566JcsCilrTph Cc: "dhcwg@ietf.org WG" , Ted Lemon Subject: Re: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 22:58:10 -0000 --14dae93411df3fcea204bcf67973 Content-Type: text/plain; charset=ISO-8859-1 I also support the adoption of this draft within the DHC WG work item Regards Daryl On 5 April 2012 19:25, Kim Kinnear wrote: > > I support adopting this as a DHC WG work item. > > Regards -- Kim > > On Apr 5, 2012, at 1:34 PM, Ted Lemon wrote: > > > On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) wrote: > >> At the Paris IETF-83 DHC WG meeting there was a lot of support for (and > I believe no opposition) adopting this as a DHC WG item. > >> > >> I kindly request that we adopt this document as a DHC WG work item. > > > > This draft documents issues that have come up involving interactions > between prefix delegation and regular IP address allocation in practice. > If you would like the working group to work on documenting this, please > signify by responding to this message in the affirmative. If you don't > think we should work on it, please respond in the negative. If you have > no opinion, please do not respond. > > > > We will determine consensus on Thursday, April 19. > > > > _______________________________________________ > > 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 > --14dae93411df3fcea204bcf67973 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I also support the adoption of this draft within the DHC WG work item
Regards
Daryl


On 5 April 2012 19= :25, Kim Kinnear <kkinnear@cisco.com> wrote:

I support adopting this as a DHC WG work item.

Regards -- Kim

On Apr 5, 2012, at 1:34 PM, Ted Lemon wrote:

> On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
>> At the Paris IETF-83 DHC WG meeting there was a lot of support for= (and I believe no opposition) adopting this as a DHC WG item.
>>
>> I kindly request that we adopt this document as a DHC WG work item= .
>
> This draft documents issues that have come up involving interactions b= etween prefix delegation and regular IP address allocation in practice. =A0= If you would like the working group to work on documenting this, please si= gnify by responding to this message in the affirmative. =A0 If you don'= t think we should work on it, please respond in the negative. =A0 If you ha= ve no opinion, please do not respond.
>
> We will determine consensus on Thursday, April 19.
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

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

--14dae93411df3fcea204bcf67973-- From Hans.Dedecker@technicolor.com Thu Apr 5 23:17:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96A911E8086 for ; Thu, 5 Apr 2012 23:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hefM4QYgz0dh for ; Thu, 5 Apr 2012 23:17:00 -0700 (PDT) Received: from psmtp.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by ietfa.amsl.com (Postfix) with ESMTP id 8653211E8085 for ; Thu, 5 Apr 2012 23:16:59 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKT36KWmmRRPdDzHZNeBNEb019Sr1gnfk2@postini.com; Thu, 05 Apr 2012 23:16:59 PDT Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 6 Apr 2012 08:12:08 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.134]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Fri, 6 Apr 2012 08:12:26 +0200 From: Dedecker Hans To: "dhcwg@ietf.org WG" Date: Fri, 6 Apr 2012 08:12:26 +0200 Thread-Topic: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item Thread-Index: AQHNE1Jkl7tgtOxKmkWYH3w2Igkw0ZaNUEIw Message-ID: <3F4910A77924AF44876B1A096ECC92A7D4AB2DA375@MOPESMBX01.eu.thmulti.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3F4910A77924AF44876B1A096ECC92A7D4AB2DA375MOPESMBX01eut_" MIME-Version: 1.0 Subject: Re: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 06:17:01 -0000 --_000_3F4910A77924AF44876B1A096ECC92A7D4AB2DA375MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adopting this as a DHC WG item. BR, Hans From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: donderdag 5 april 2012 19:35 To: dhcwg@ietf.org WG Subject: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-= 00 as WG item On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) > wrote: At the Paris IETF-83 DHC WG meeting there was a lot of support for (and I b= elieve no opposition) adopting this as a DHC WG item. I kindly request that we adopt this document as a DHC WG work item. This draft documents issues that have come up involving interactions betwee= n prefix delegation and regular IP address allocation in practice. If you= would like the working group to work on documenting this, please signify b= y responding to this message in the affirmative. If you don't think we sh= ould work on it, please respond in the negative. If you have no opinion, = please do not respond. We will determine consensus on Thursday, April 19. --_000_3F4910A77924AF44876B1A096ECC92A7D4AB2DA375MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support adopting this as a DHC WG item.

 

BR,

Hans

 

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ie= tf.org] On Behalf Of Ted Lemon
Sent: donderdag 5 april 201= 2 19:35
To: dhcwg@ietf.org WG
Subject: [dhcwg] Call for= Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item<= /span>

 

<= p class=3DMsoNormal>On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) <volz@cisco.com> wrote:

<= /div>

At the Paris IETF-83 DHC WG meeting there was a lot of = support for (and I believe no opposition) adopting this as a DHC WG item.

 <= /span>

I kindly request that we ado= pt this document as a DHC WG work item.

 

This draft documents issues that have come up involving inte= ractions between prefix delegation and regular IP address allocation in pra= ctice.   If you would like the working group to work on documenting th= is, please signify by responding to this message in the affirmative.  = If you don't think we should work on it, please respond in the negative. &= nbsp; If you have no opinion, please do not respond.

 

We will determine consensus on Thursday, April 19. 

 

= --_000_3F4910A77924AF44876B1A096ECC92A7D4AB2DA375MOPESMBX01eut_-- From twinters@iol.unh.edu Fri Apr 6 05:35:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7317B21F8549 for ; Fri, 6 Apr 2012 05:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jtweIKOb5jA for ; Fri, 6 Apr 2012 05:35:13 -0700 (PDT) Received: from exprod5og101.obsmtp.com (exprod5og101.obsmtp.com [64.18.0.141]) by ietfa.amsl.com (Postfix) with SMTP id ECB5D21F8542 for ; Fri, 6 Apr 2012 05:35:12 -0700 (PDT) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob101.postini.com ([64.18.4.12]) with SMTP ID DSNKT37i/zAbGOV92eF/uyKt21CNuycbw6vR@postini.com; Fri, 06 Apr 2012 05:35:13 PDT Received: from [10.0.1.9] (c-24-63-15-128.hsd1.nh.comcast.net [24.63.15.128]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id 2CC3D8F0067 for ; Fri, 6 Apr 2012 08:35:11 -0400 (EDT) From: Timothy Winters Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_C2DEE900-7AC7-419C-A30F-54A80239D78D" Date: Fri, 6 Apr 2012 08:35:12 -0400 In-Reply-To: <3F4910A77924AF44876B1A096ECC92A7D4AB2DA375@MOPESMBX01.eu.thmulti.com> To: "dhcwg@ietf.org WG" References: <3F4910A77924AF44876B1A096ECC92A7D4AB2DA375@MOPESMBX01.eu.thmulti.com> Message-Id: <38C3CFA7-5919-4BC8-B092-A772C6B67F63@iol.unh.edu> X-Mailer: Apple Mail (2.1257) Subject: Re: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 12:35:14 -0000 --Apple-Mail=_C2DEE900-7AC7-419C-A30F-54A80239D78D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I also support this becoming a DHC WG item. Regards, Tim On Apr 6, 2012, at 2:12 AM, Dedecker Hans wrote: > I support adopting this as a DHC WG item. > =20 > BR, > Hans > =20 > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = OfTed Lemon > Sent: donderdag 5 april 2012 19:35 > To: dhcwg@ietf.org WG > Subject: [dhcwg] Call for Adoption, = draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item > =20 > On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) wrote: > At the Paris IETF-83 DHC WG meeting there was a lot of support for = (and I believe no opposition) adopting this as a DHC WG item. > =20 > I kindly request that we adopt this document as a DHC WG work item. > =20 > This draft documents issues that have come up involving interactions = between prefix delegation and regular IP address allocation in practice. = If you would like the working group to work on documenting this, = please signify by responding to this message in the affirmative. If = you don't think we should work on it, please respond in the negative. = If you have no opinion, please do not respond. > =20 > We will determine consensus on Thursday, April 19.=20 > =20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail=_C2DEE900-7AC7-419C-A30F-54A80239D78D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I also support this becoming a DHC WG = item.

Regards,
Tim

On= Apr 6, 2012, at 2:12 AM, Dedecker Hans wrote:

I support adopting this as a DHC WG = item.
 
Hans
From: dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] On Behalf OfTed = Lemon
Sent: donderdag 5 april 2012 = 19:35
To: dhcwg@ietf.org = WG
Subject: [dhcwg] Call for Adoption, = draft-troan-dhc-dhcpv6-stateful-issues-00 as WG = item
dhcwg@ietf.org
https://www.ietf.org/= mailman/listinfo/dhcwg

= --Apple-Mail=_C2DEE900-7AC7-419C-A30F-54A80239D78D-- From Tina.Tsou.Zouting@huawei.com Fri Apr 6 08:56:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F41C21F84CE for ; Fri, 6 Apr 2012 08:56:24 -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, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oH8qxVezVwfS for ; Fri, 6 Apr 2012 08:56:23 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6435E21F84B9 for ; Fri, 6 Apr 2012 08:56:23 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFA04868; Fri, 06 Apr 2012 11:56:23 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Apr 2012 08:56:20 -0700 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Apr 2012 08:56:18 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.214]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 6 Apr 2012 23:56:11 +0800 From: Tina TSOU To: Timothy Winters Thread-Topic: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item Thread-Index: AQHNE/HAR9dj6umuXE+JtWrROoPHsJaN867c Date: Fri, 6 Apr 2012 15:56:10 +0000 Message-ID: References: <3F4910A77924AF44876B1A096ECC92A7D4AB2DA375@MOPESMBX01.eu.thmulti.com>, <38C3CFA7-5919-4BC8-B092-A772C6B67F63@iol.unh.edu> In-Reply-To: <38C3CFA7-5919-4BC8-B092-A772C6B67F63@iol.unh.edu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_DF707EA3436746059313CF8EF10ACD12huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 15:56:24 -0000 --_000_DF707EA3436746059313CF8EF10ACD12huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adopting this as WG item. Sent from my iPhone On Apr 6, 2012, at 5:35 AM, "Timothy Winters" > wrote: I also support this becoming a DHC WG item. Regards, Tim On Apr 6, 2012, at 2:12 AM, Dedecker Hans wrote: I support adopting this as a DHC WG item. BR, Hans From: dhcwg-bounces@ietf.org [mailto:dhcwg-b= ounces@ietf.org] On Behalf OfTed Lemon Sent: donderdag 5 april 2012 19:35 To: dhcwg@ietf.org WG Subject: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-= 00 as WG item On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) > wrote: At the Paris IETF-83 DHC WG meeting there was a lot of support for (and I b= elieve no opposition) adopting this as a DHC WG item. I kindly request that we adopt this document as a DHC WG work item. This draft documents issues that have come up involving interactions betwee= n prefix delegation and regular IP address allocation in practice. If you= would like the working group to work on documenting this, please signify b= y responding to this message in the affirmative. If you don't think we sh= ould work on it, please respond in the negative. If you have no opinion, = please do not respond. We will determine consensus on Thursday, April 19. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_DF707EA3436746059313CF8EF10ACD12huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I support adopting this as WG item.

Sent from my iPhone

On Apr 6, 2012, at 5:35 AM, "Timothy Winters" <twinters@iol.unh.edu> wrote:

I also support this becoming a DHC WG item= .

Regards,
Tim

On Apr 6, 2012, at 2:12 AM, Dedecker Hans wrote:

I support adopting this as a DHC WG item.<= o:p>
 
BR,
Hans
 
From:&nbs= p;dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] = ;On Behalf OfTed Lemon
Sent: donderdag 5 = april 2012 19:35
To: dhcwg@ietf.org WG
Subject: [dhcwg] C= all for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item=
 
On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) <volz@cisco.co= m> wrote:
At the Paris IETF-83 DHC WG meeting there was a lot of support for (= and I believe no opposition) adopting this as a DHC WG item.
 
I kindly request that we adopt this document as a DHC WG work item.<= o:p>
 
This draft documents issues that have come up involving interactions betwee= n prefix delegation and regular IP address allocation in practice.   I= f you would like the working group to work on documenting this, please sign= ify by responding to this message in the affirmative.   If you don't think we should work on it, please re= spond in the negative.   If you have no opinion, please do not respond= .
 
We will determine consensus on Thursday, April 19. 
 
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.or= g/mailman/listinfo/dhcwg

--_000_DF707EA3436746059313CF8EF10ACD12huaweicom_-- From C.Donley@cablelabs.com Fri Apr 6 14:10:56 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBC511E809C for ; Fri, 6 Apr 2012 14:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYk8kgBrMLzx for ; Fri, 6 Apr 2012 14:10:52 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id D783711E8098 for ; Fri, 6 Apr 2012 14:10:51 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q36LAoUO030963; Fri, 6 Apr 2012 15:10:50 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 06 Apr 2012 15:10:50 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Fri, 6 Apr 2012 15:10:50 -0600 From: Chris Donley To: Ted Lemon , "dhcwg@ietf.org WG" Date: Fri, 6 Apr 2012 15:11:58 -0600 Thread-Topic: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item Thread-Index: Ac0UOb3c9LFIlJ/PQgGBxXfh4LFaDg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBA4B81949FD4cdonleycablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 21:10:57 -0000 --_000_CBA4B81949FD4cdonleycablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adoption of this document. Chris From: Ted Lemon > Date: Thu, 5 Apr 2012 11:34:46 -0600 To: "dhcwg@ietf.org WG" > Subject: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-= 00 as WG item On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) > wrote: At the Paris IETF-83 DHC WG meeting there was a lot of support for (and I b= elieve no opposition) adopting this as a DHC WG item. I kindly request that we adopt this document as a DHC WG work item. This draft documents issues that have come up involving interactions betwee= n prefix delegation and regular IP address allocation in practice. If you= would like the working group to work on documenting this, please signify b= y responding to this message in the affirmative. If you don't think we sh= ould work on it, please respond in the negative. If you have no opinion, = please do not respond. We will determine consensus on Thursday, April 19. --_000_CBA4B81949FD4cdonleycablelabscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I support adop= tion of this document.


= Chris

=
From: Ted Lemon <Ted.Lemon@nominum.com>
Date: Thu, 5 Apr 2012 11:34:46 -0600To: "dhcwg@ietf.org WG" <dhcwg@i= etf.org>
Subject: [dhcwg= ] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item

On Apr = 5, 2012, at 1:25 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
At the Paris IETF-83 DHC WG meeting there was a lot of support for (and I b= elieve no opposition) adopting this as a DHC WG item.
 
I kindly request that we adopt this document as a DHC WG work item.

This draft documents issues that have = come up involving interactions between prefix delegation and regular IP add= ress allocation in practice.   If you would like the working group to = work on documenting this, please signify by responding to this message in the affirmative.   If you don't think we should work on it, please= respond in the negative.   If you have no opinion, please do not resp= ond.

We will determine consensus on Thursday, Apri= l 19. 

 --_000_CBA4B81949FD4cdonleycablelabscom_-- From ghalwasi@cisco.com Fri Apr 6 20:29:09 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6E121F851D for ; Fri, 6 Apr 2012 20:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5hCBfiItkYI for ; Fri, 6 Apr 2012 20:29:08 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 49B1A21F851B for ; Fri, 6 Apr 2012 20:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=9243; q=dns/txt; s=iport; t=1333769347; x=1334978947; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=/ra5aQma41/lpI9eUu7LO1ar0wil7UQTsv1ID7IQEg4=; b=XIZWFV2T63CywR/imQEnsru7DSRj4rWur3qc3V6mSFfPJPl/8wcJJas0 qKuixSZYepIhfi4RBKdBwY0QZ+Z7zAN0TY910e6yCJw81OZ4quhsHP7Q2 C9c+zHaw7cs4KlIUq7bhKKQbkdxg8KHvH5X0fUDZIGoYCvS33jEyBcoTF Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEABm0f09Io8UY/2dsb2JhbABCglO3ZoIJAQEBBBIBCQEQA1kCAQgRBAEBCwYXAQYBRQkIAgQBCggIGodsnmyXco9tYwSIWJthgWmCbw X-IronPort-AV: E=Sophos;i="4.75,384,1330905600"; d="scan'208,217";a="9480435" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 07 Apr 2012 03:29:00 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q373T0Fm025913; Sat, 7 Apr 2012 03:29:00 GMT Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 7 Apr 2012 08:59:00 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD146E.92CA37B2" Date: Sat, 7 Apr 2012 08:58:59 +0530 Message-ID: <3CF88B99A9ED504197498BC6F6F04B81060E5A9A@XMB-BGL-41E.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item Thread-Index: AQHNE1Jkl7tgtOxKmkWYH3w2Igkw0ZaOtlKw References: From: "Gaurav Halwasia (ghalwasi)" To: "Ted Lemon" , X-OriginalArrivalTime: 07 Apr 2012 03:29:00.0966 (UTC) FILETIME=[930CCC60:01CD146E] Subject: Re: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 03:29:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD146E.92CA37B2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adopting this document as a DHC WG item. =20 Thanks, Gaurav =20 From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, April 05, 2012 11:05 PM To: dhcwg@ietf.org WG Subject: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item =20 On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) wrote: At the Paris IETF-83 DHC WG meeting there was a lot of support for (and I believe no opposition) adopting this as a DHC WG item. =20 I kindly request that we adopt this document as a DHC WG work item. =20 This draft documents issues that have come up involving interactions between prefix delegation and regular IP address allocation in practice. If you would like the working group to work on documenting this, please signify by responding to this message in the affirmative. If you don't think we should work on it, please respond in the negative. If you have no opinion, please do not respond. =20 We will determine consensus on Thursday, April 19.=20 =20 ------_=_NextPart_001_01CD146E.92CA37B2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support adopting this document as a DHC WG = item.

 

Thanks,

Gaurav

 

From:= = dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Ted Lemon
Sent: Thursday, April 05, 2012 11:05 = PM
To: dhcwg@ietf.org WG
Subject: [dhcwg] Call for = Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG = item

 

On = Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) <volz@cisco.com> = wrote:

At the Paris IETF-83 DHC WG meeting there was a lot of support for (and = I believe no opposition) adopting this as a DHC WG = item.

 

I kindly request that we adopt this document as a DHC WG work = item.

 

This draft documents issues that have come up = involving interactions between prefix delegation and regular IP address = allocation in practice.   If you would like the working group to = work on documenting this, please signify by responding to this message = in the affirmative.   If you don't think we should work on it, = please respond in the negative.   If you have no opinion, please do = not respond.

 

We will determine consensus on Thursday, April = 19. 

 

------_=_NextPart_001_01CD146E.92CA37B2-- From hansliu@gmail.com Sat Apr 7 02:43:38 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FEF21F8549 for ; Sat, 7 Apr 2012 02:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEUVXWNViVq6 for ; Sat, 7 Apr 2012 02:43:38 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E0C7021F8495 for ; Sat, 7 Apr 2012 02:43:24 -0700 (PDT) Received: by lbok13 with SMTP id k13so1130030lbo.31 for ; Sat, 07 Apr 2012 02:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fqsewGqcUcCgaLSGeWa5c1ND5gkmLrQmwtTlIy45MDY=; b=Pwq+nf3t/JcDM9RUuJqvDM10Z7du01cGhhtEydl4AVP2Xd0UxheKVbDcSbhtcMOi2g UUOQAXPmi1u6oQ/T+kXmHRfrRTuokyMSWAPogw8o+plvLl+G7rU8PApoyQhPbC2Ek7eg 01LfG3OExVMtj9CgB5o5pVN2N5q+EqM+97v4+6GbJ7bSnft24KqmNVeLTYDbAbYipwG3 qplqfQDOoY8QXOmAbwW/Ld5hikznaMHMrSr9ohT0ApVtLQ3uDyOHlqzzQ2rgYxt4vHko dSjE+RzVUms3hSU8SfOLphWN5Ar4CgoRqB/5T85n0V9+IrHqq9OHkBO1kUWpXzjGr42B IITw== MIME-Version: 1.0 Received: by 10.152.111.161 with SMTP id ij1mr1461296lab.19.1333791799838; Sat, 07 Apr 2012 02:43:19 -0700 (PDT) Received: by 10.112.43.8 with HTTP; Sat, 7 Apr 2012 02:43:19 -0700 (PDT) In-Reply-To: References: Date: Sat, 7 Apr 2012 17:43:19 +0800 Message-ID: From: Hans Liu To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 09:43:38 -0000 I support adoption of this document. Cheers, Hans On Fri, Apr 6, 2012 at 1:34 AM, Ted Lemon wrote: > On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) wrote: > > At the Paris IETF-83 DHC WG meeting there was a lot of support for (and I > believe no opposition) adopting this as a DHC WG item. > > I kindly request that we adopt this document as a DHC WG work item. > > > This draft documents issues that have come up involving interactions betw= een > prefix delegation and regular IP address allocation in practice. =C2=A0 I= f you > would like the working group to work on documenting this, please signify = by > responding to this message in the affirmative. =C2=A0 If you don't think = we > should work on it, please respond in the negative. =C2=A0 If you have no = opinion, > please do not respond. > > We will determine consensus on Thursday, April 19. > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From tomasz.mrugalski@gmail.com Sun Apr 8 09:19:05 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F65721F8527 for ; Sun, 8 Apr 2012 09:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBpsctHW6RSD for ; Sun, 8 Apr 2012 09:19:04 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D7BA021F8523 for ; Sun, 8 Apr 2012 09:19:03 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2376258wgb.13 for ; Sun, 08 Apr 2012 09:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=1wxF9s7Dr5U4N2cvR1fcu7Gtaqn7HF9wpZUx2bXjyUk=; b=B5+io2S/gVuobkWskhdBOHB62RlmM6BO1UKm5n/1dXQoVSg8Tco46E1fZgu9GN8RNc hQ7VIM+v/Y2Mv0ZPt1fIz3Tx4gBRebp1rCaw9dHOCa+N3jDKBq4RkdZGHjnRIoHRFn7e SIJnzUQRbDLCkbwvZgq230lQiKCQ0QQJYiQFPOt+fEattxwubgupvypuaQ9TdbG967p2 MTrAjfoo3WyXmZ/rWgNW65BKJQpItOjPiiTXfZnhrc9OQKt94RGvF/8WIE3Mu6KNEckg BTDdl1SpiRou8BoYTcdBGnGawPp6WB+sy/658W2l/iyPF1Hg17WkJPU8+k6P08n7ukTk pSZA== Received: by 10.180.105.194 with SMTP id go2mr9869772wib.22.1333901942993; Sun, 08 Apr 2012 09:19:02 -0700 (PDT) Received: from tomek.local (095160002041.lomza.vectranet.pl. [95.160.2.41]) by mx.google.com with ESMTPS id h8sm37967797wix.4.2012.04.08.09.19.01 (version=SSLv3 cipher=OTHER); Sun, 08 Apr 2012 09:19:02 -0700 (PDT) Message-ID: <4F81BA73.4000400@gmail.com> Date: Sun, 08 Apr 2012 18:18:59 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dhcwg@ietf.org, Ole Troan References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 16:19:05 -0000 On 12-04-05 19:25, Bernie Volz (volz) wrote: > I kindly request that we adopt this document as a DHC WG work item. I do support this work and its adoption. I also have couple of comments: 0. Would it be reasonable to name this work 3315bis? 1. I assume this work will also cover all combinations of IA_NA/IA_PD/IA_TA. But what about IA_PA, specified in draft-ietf-dhc-host-gen-id? This work was adopted by DHC, so authors should take a closer look at it. (I'm sorry I can't offer any better comments here. I haven't read host-gen-id yet). 2. stateful-issues draft is a very useful work. Once adopted it should also look at CGA issues - my understanding is that it basically degrades DHCP into registration service, compared to normal assignment service. I haven't read CGA drafts recently, so again this is only a pointer to something that should be looked at. It is possible that there's nothing to do in that matter. 3. Abstract could be reworded: "the ne options for Prefix Delegation options for DHCPv6 into DHCPv6" part is repetitive. The same is true for first paragraph of Introduction section. 4. Text refer to different IA options as IA_. I think it would look better without the underscore. If that is not clear, perhaps it could be clarified that "IA option" means any of IA_NA, IA_TA or IA_PD. 5. Section 3.1 states that client MUST ignore IAs with status code NoAddrAvail. That doesn't help much. What about other status codes? IA_PD may be returned with NoPrefixAvail. Much better would be to say that client MUST ignore IAs with status code other than Success. We should also add that client SHOULD rate advertise without assigned IAs lower than other advertises, but exact advertise rating algorithm is up to client imlementors. For example, I would implement a client that accepts advertise with preference=5 and all IAs assigned rather than one with preference=10, but without IA_NA or IA_PD assigned. 6. Section 3.2 says that 3 non-success status codes (NoAddrsAvail, NoPrefixAvail and NotOnLink) should appear within IA options. It would be better to not explicitely limit to those 3 status code, but say all non-success status codes to maintain forward compatibility. Something like "e.g. NoAddrsAvail, NoPrefixAvail, NotOnLink and other non-success status codes" will do. BTW you missed UnspecFail code that is already defined and could be used, so the text as it is does not cover all situations from day 1. 7. It should be clarified that status codes are specified per instance of an option, not per option type. Think about client that sends 3 IA_NA options. It can receive 2 addresses and NoAddrAvail in the third instance. That could be either due to pool depletion (unlikely) or server policy that allow server to assign no more than 2 addresses per client (likely). 8. Proposed replacement errata in section 3.2 should clarify that such proposed action should be taken on each IA being answered. 9. Section 3.3 could mention relation between T1/T2 and information refresh option (RFC4242). The reasonable clarification would be that client MAY request other options in ORO when sending RENEW or REBIND. 10. Allowing PD to be confirmed with CONFIRM could be tricky. In many deployment scenarios routing is configured separately for each delegated prefix and server can't really say "yeah, I've never assigned you that one, but it should be valid on your link.". I don't object allowing IA_PD in CONFRIM, but it should be accompanied with a clause that server MUST include IA_PD response only if it is certain that delegated prefix is really valid. This will complicate things. What is client sends CONFIRM with IA_NA and IA_PD and server can confirm that address is on-link, but is not sure about prefix? There's no such status as IdontKnow. Different IA combinations should be given more thought. 11. Section 3.5. A what??? Are you suggesting that client can send RENEW *after* it sent RELEASE? If that is the case, I strongly object. Once client released a lease, it has no further claims to released address/prefix. It MUST NOT send RENEW. Proper way it to send REQUEST, not RENEW. Also. Section 3.5 title mentions DECLINE, but there is nothing about DECLINE in the text. Authors probably forgot adding a sentence that DECLINE may be sent at any time when client owns a lease. 12. A question about proposed operation in section 3.6. What if there are two servers. Imagines a case with 2 servers: one that provides addresses and second one that provides prefixes. Client requests IA_NA and IA_PD. What should client do? 13. In 3rd paragraph in section 3.6 it would be better to say non-success status codes rather than NoAddrsAvail (or at least NoAddrsAvail/NoPrefixAvail/NotOnLink/UnspecFail). 14. Section 3.7 is the most unfortunate. I understand the reasons that led authors to that decision, so I sadly accept it. Despite my comments, I strongly support this work and it adoption. It is great that we will get this thing clarified. Greetings to all woods dwellers, Tomek From volz@cisco.com Sun Apr 8 14:26:50 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF9721F8450 for ; Sun, 8 Apr 2012 14:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwEQAm9NGsJ6 for ; Sun, 8 Apr 2012 14:26:49 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1813021F844E for ; Sun, 8 Apr 2012 14:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7356; q=dns/txt; s=iport; t=1333920409; x=1335130009; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=KLvlR+/+Sjde8zK+v9FPf3uWsp1mhpT65Iwanorw4F4=; b=Nc/FC95SgMhTtlv6mRILp77rj/MHRkidBOWll5MhNCuKRUggErzbdH1x Jl2EbFpGTg6CtD91V+5s/n1JRkm2Pt/zDiRgjOZWDuiTPU9vdOLxu3z5Y dJv3IL5J7ZhZqdIc4O/RzkfHg1c2LXjMZSc3CncK1m98ltxpbBEonMdTg U=; X-IronPort-AV: E=Sophos;i="4.75,391,1330905600"; d="scan'208";a="69976479" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 08 Apr 2012 21:26:48 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q38LQm9i013410; Sun, 8 Apr 2012 21:26:48 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 Apr 2012 16:26:48 -0500 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: Sun, 8 Apr 2012 16:26:47 -0500 Message-ID: In-Reply-To: <4F81BA73.4000400@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item Thread-Index: Ac0Vo1FUC+sddg0sScatsbgk57mmYgAKSwPA References: <4F81BA73.4000400@gmail.com> From: "Bernie Volz (volz)" To: "Tomek Mrugalski" , , "Ole Troan" X-OriginalArrivalTime: 08 Apr 2012 21:26:48.0509 (UTC) FILETIME=[4E5286D0:01CD15CE] Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 21:26:50 -0000 Tomek: Regarding 0, no. This work would be folded into 3315bis but it should proceed separately. Primarily because it is needed "now" and the 3315bis work will probably be at a much slower pace. Regarding the other issues, NA/PD are primary target. TA isn't renewed so it has fewer issues. But, we will look to improving the situation for multiple IA options. And, can consider others that are in various stages of being proposed. I am not sure we can cover all cases as I'm sure anything we conclude might have to be revisited in the future when a new type comes along. This work is really related to 6204bis and the fact that the cable market needs the router behavior to be clarified. Thanks for your other points and we'll review and incorporate or comment on the list as appropriate. I have not reviewed the extensive list in details - I just wanted to send out a note to make the 'scope' of the work a bit clearer. I will add that for: >11. Section 3.5. A what??? Are you suggesting that client can send RENEW *after* it sent RELEASE? No. If the text implies that it will need to be cleaned up. Once you RELEASE that's it. What it was supposed to communicate is that the client can RELEASE the IA_NA, for example, and then do a RENEW with the IA_PD and the IA_NA to get a different address. This is not renewing the existing address. It isn't really clear why a client would release one lease type but not the other, so this case is probably not likely. The more likely cases is that the client finds a DAD conflict or other issue with the address and much DECLINE it ... and rather than having to go back to Solicit, this allows the client the ability to RENEW the IA_PD and include the IA_NA to get a new address (that hopefully won't have the DAD or other conflict). Note that in this RENEW, the IA_NA would not have an IA_ADDR option (or if it does, it would be the unspecified address). - Bernie -----Original Message----- From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com]=20 Sent: Sunday, April 08, 2012 12:19 PM To: dhcwg@ietf.org; Ole Troan Cc: Bernie Volz (volz) Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item On 12-04-05 19:25, Bernie Volz (volz) wrote: > I kindly request that we adopt this document as a DHC WG work item. I do support this work and its adoption. I also have couple of comments: 0. Would it be reasonable to name this work 3315bis? 1. I assume this work will also cover all combinations of IA_NA/IA_PD/IA_TA. But what about IA_PA, specified in draft-ietf-dhc-host-gen-id? This work was adopted by DHC, so authors should take a closer look at it. (I'm sorry I can't offer any better comments here. I haven't read host-gen-id yet). 2. stateful-issues draft is a very useful work. Once adopted it should also look at CGA issues - my understanding is that it basically degrades DHCP into registration service, compared to normal assignment service. I haven't read CGA drafts recently, so again this is only a pointer to something that should be looked at. It is possible that there's nothing to do in that matter. 3. Abstract could be reworded: "the ne options for Prefix Delegation options for DHCPv6 into DHCPv6" part is repetitive. The same is true for first paragraph of Introduction section. 4. Text refer to different IA options as IA_. I think it would look better without the underscore. If that is not clear, perhaps it could be clarified that "IA option" means any of IA_NA, IA_TA or IA_PD. 5. Section 3.1 states that client MUST ignore IAs with status code NoAddrAvail. That doesn't help much. What about other status codes? IA_PD may be returned with NoPrefixAvail. Much better would be to say that client MUST ignore IAs with status code other than Success. We should also add that client SHOULD rate advertise without assigned IAs lower than other advertises, but exact advertise rating algorithm is up to client imlementors. For example, I would implement a client that accepts advertise with preference=3D5 and all IAs assigned rather than = one with preference=3D10, but without IA_NA or IA_PD assigned. 6. Section 3.2 says that 3 non-success status codes (NoAddrsAvail, NoPrefixAvail and NotOnLink) should appear within IA options. It would be better to not explicitely limit to those 3 status code, but say all non-success status codes to maintain forward compatibility. Something like "e.g. NoAddrsAvail, NoPrefixAvail, NotOnLink and other non-success status codes" will do. BTW you missed UnspecFail code that is already defined and could be used, so the text as it is does not cover all situations from day 1. 7. It should be clarified that status codes are specified per instance of an option, not per option type. Think about client that sends 3 IA_NA options. It can receive 2 addresses and NoAddrAvail in the third instance. That could be either due to pool depletion (unlikely) or server policy that allow server to assign no more than 2 addresses per client (likely). 8. Proposed replacement errata in section 3.2 should clarify that such proposed action should be taken on each IA being answered. 9. Section 3.3 could mention relation between T1/T2 and information refresh option (RFC4242). The reasonable clarification would be that client MAY request other options in ORO when sending RENEW or REBIND. 10. Allowing PD to be confirmed with CONFIRM could be tricky. In many deployment scenarios routing is configured separately for each delegated prefix and server can't really say "yeah, I've never assigned you that one, but it should be valid on your link.". I don't object allowing IA_PD in CONFRIM, but it should be accompanied with a clause that server MUST include IA_PD response only if it is certain that delegated prefix is really valid. This will complicate things. What is client sends CONFIRM with IA_NA and IA_PD and server can confirm that address is on-link, but is not sure about prefix? There's no such status as IdontKnow. Different IA combinations should be given more thought. 11. Section 3.5. A what??? Are you suggesting that client can send RENEW *after* it sent RELEASE? If that is the case, I strongly object. Once client released a lease, it has no further claims to released address/prefix. It MUST NOT send RENEW. Proper way it to send REQUEST, not RENEW. Also. Section 3.5 title mentions DECLINE, but there is nothing about DECLINE in the text. Authors probably forgot adding a sentence that DECLINE may be sent at any time when client owns a lease. 12. A question about proposed operation in section 3.6. What if there are two servers. Imagines a case with 2 servers: one that provides addresses and second one that provides prefixes. Client requests IA_NA and IA_PD. What should client do? 13. In 3rd paragraph in section 3.6 it would be better to say non-success status codes rather than NoAddrsAvail (or at least NoAddrsAvail/NoPrefixAvail/NotOnLink/UnspecFail). 14. Section 3.7 is the most unfortunate. I understand the reasons that led authors to that decision, so I sadly accept it. Despite my comments, I strongly support this work and it adoption. It is great that we will get this thing clarified. Greetings to all woods dwellers, Tomek From tomasz.mrugalski@gmail.com Sun Apr 8 15:06:44 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93C221F8471 for ; Sun, 8 Apr 2012 15:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exIrCwxevcPJ for ; Sun, 8 Apr 2012 15:06:44 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id A549121F845C for ; Sun, 8 Apr 2012 15:06:43 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so1779314wgb.1 for ; Sun, 08 Apr 2012 15:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=5lrsB2nYGYqin8nopmCTPOS2ws1JyKL2DJPyoHc9pRw=; b=1FeAEDnJeQPcjkhjkByUQhs6D039kucM2gQpt/CNisuU3lhsnrHNJ4q8L3K1FhmZPi 0P2VilWRIfMMt7+3FsbgcLe1eA5H++JHxsBgI9EXdVSIPXcMXt56qs6nf10nuAJFzFZN ihYyAlMis04/WANhN/PXN6jJrcF5w1E++NEc8VeFCsNvm61Yj9j7jDdqjJJp2ilRTFhs jX1DCkGGwgv2zkNWIGy7TeLpzjHgRnTusfaL05sOkGInBUa1ol2iu15SjrgLnUimj6/T 5jlq5slY+wmfTff+spnhiGzohfYuzZbyrFYw4MxLoJ/oB+DjVq/A1M8DlFFVMDrc/Bgt 1i5g== Received: by 10.180.105.69 with SMTP id gk5mr13382609wib.3.1333922802908; Sun, 08 Apr 2012 15:06:42 -0700 (PDT) Received: from tomek.local (095160002041.lomza.vectranet.pl. [95.160.2.41]) by mx.google.com with ESMTPS id gg2sm41121792wib.7.2012.04.08.15.06.41 (version=SSLv3 cipher=OTHER); Sun, 08 Apr 2012 15:06:42 -0700 (PDT) Message-ID: <4F820BF0.60707@gmail.com> Date: Mon, 09 Apr 2012 00:06:40 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: DHC WG X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comments on draft-yeh-dhc-dhcpv6-authorization-opt-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 22:06:44 -0000 Hi, I finally found some time to read the draft. I do support this work and its adoption (if requested), but I suggest several changes to the text. First and foremost, I agree with Ted's and Bernie's comments. Please pick design 2 and make this a single option that is a container for any Radius options. Here's my opinion why design 1 is very bad. For specific use cases author chose 2 options: pool name and prefix auth, but I'm sure there are cases when other Radius attributes may be useful. There are 160 Radius attributes defined so far. Please do not turn this into one to one Radius to DHCPv6 option translator. Much better approach is to define a single container that conveys required Radius attributes. Don't worry about extra processing required on DHCPv6 server side. Many servers are smart enough to do processing of received options. For example ISC DHCP is able to play various tricks like fancy to string conversion, sub-string search etc. I'm sure other implementations can do similar processing. Also, that is the same approach that was chosen for DHCPv4 (as defined in RFC4014). It works in v4 and the principles are the same, so keep it the same in v6. Having one container option is also forward compatible with any new radius options that may be defined in the future. 1. Introduction - I'm not sure if introductory paragraph about DHCPv6 with all references to all those RFCs is needed. If you think that is useful, a one short sentence with reference to 3315 will do the trick. If you really want to keep those references, make most of them informative. Normative references are the ones that are required to understand your proposal. In this context RFC3646 is informative as it only provides background information. I think simple reference to primary Radius IPv6 RFC will do as well. I'm not a Radius expert, so it you think that keeping those detailed references are useful, I won't object. Please consider if all of them must be kept normative, though. Perhaps informative will be enough. 2. I would strongly suggest to rename that option to OPTION_RADIUS. This name will instantly tell everyone what that option conveys. Authorization may mean many different things in different contexts. 3. In option format specified in Section 4, option name is typically written in all uppercase (OPTION_AUTHORIZATION rather than Option_Authorization). 4. Section that defines an option often briefly specifies it usage. It may be useful to add couple of sentences there: Client MUST NOT send this option. Client MUST ignore this option if received. Relays MAY include this option in RELAY-FORW messages. Server SHOULD NOT/MUST NOT include it in RELAY-REPL messages. 5. I would reword first sentence in "Relay Agent Behavior" (section 6). "The DHCPv6 relay agent must include Option_Authorization in the relay-forward (12) message..." => "The DHCPv6 relay agent that supports this mechanism SHOULD include OPTION_RADIUS in the relay-forward message...". (SHOULD instead of must). 6. It would be useful to say that relay does not have to include all RADIUS attributes, just those that would be useful. 7. Negative case. I'm not sure if I understand that correctly, but what happens if a client is not authorized by Radius? Should relay drop the message? Or do you want relay to forward client's message with the negative radius response and finally server is expected to not assign addresses/prefixes? Some kind of clarification about that could be useful. 8. In section 6. you should also mention that relay MUST ignore received incoming OPTION_RADIUS (server should not echo it back, right?). 9. In "Server Behavior" section it is better to say: "The DHCPv6 server MAY use received RADIUS option to pick appropriate addresses, options and delegate prefixes.". 10. I assume that server does not echo RADIUS option back, right? Something to that effect should be added in Section 7. Also, in Fig. 1 you could add extra space between (Option_Authorization) and Relay-reply lines to show that Authorization/Radius option is expected to appear in relay-forward message only, not in both relay-forward and relay-reply. 11. While clients are not expected to ever see this option, it would be explicitely state that using normative language. Something like "Client MUST NOT send RADIUS option. Client MUST ignore received RADIUS option." 12. Are there any security considerations that are specific to RADIUS? You should probably point to a security considerations section in some RADIUS RFC. 13. As a sole author, I'm not sure if that makes sense to mark your role as editor. Despite quite a few comments, I support this work. It looks useful and I'm quite surprised that RADIUS option was not defined yet. Cheers, Tomek From tomasz.mrugalski@gmail.com Sun Apr 8 15:15:00 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4B021F8541 for ; Sun, 8 Apr 2012 15:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEiuDJjlR5JC for ; Sun, 8 Apr 2012 15:15:00 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id E907C21F852A for ; Sun, 8 Apr 2012 15:14:59 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so1784334wib.1 for ; Sun, 08 Apr 2012 15:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:x-forwarded-message-id:content-type :content-transfer-encoding; bh=ZD3Kq7xW0Ae/LLOBwVn/yp7En/xO+5EC9BWyekBVcq0=; b=LrUev0yO3q9O1ytI6wlrV14AMHAFUoOc2QHdDlYKY/fniMB773OtXC7QnZ0zP+YsPE sVqn4keypC5CLXPYdEQmkRLW6Ih8Wmr1knEh0a0MY1PGFid4iEw1DjCiOVKTp3ozcnR1 bUUN6rbnSJr+4XBowHJhQq60PpVMrZeQ3Mnyf9BoFKA0bPzNAsklbQwpUK4v3LZTZzpt t+TjF1HFxGJDtF9cnzFYb93yffYahUyDXxRRzGlNTC2eIlT9r6F7emojkknszozjR0Dn eFYcQWGopKp53o6/H2o1yU7BdV4d0jxAkC55W96Z79/gUka1A09Rqxizh31VnjBz/18s J8Ng== Received: by 10.180.88.164 with SMTP id bh4mr11356593wib.22.1333923299060; Sun, 08 Apr 2012 15:14:59 -0700 (PDT) Received: from tomek.local (095160002041.lomza.vectranet.pl. [95.160.2.41]) by mx.google.com with ESMTPS id 6sm25522152wiz.1.2012.04.08.15.14.58 (version=SSLv3 cipher=OTHER); Sun, 08 Apr 2012 15:14:58 -0700 (PDT) Message-ID: <4F820DE1.9090907@gmail.com> Date: Mon, 09 Apr 2012 00:14:57 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: DHC WG References: <20120312204156.30819.94209.idtracker@ietfa.amsl.com> In-Reply-To: <20120312204156.30819.94209.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4 X-Forwarded-Message-Id: <20120312204156.30819.94209.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-design-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 22:15:00 -0000 Hi, DHCPv6 Failover Design draft was presented in Paris DHC meeting and it got a lot of support (around 20 supporters) without any notable opposition. I kindly request that we adopt this document as a DHC WG work item. Tomek -------- Original Message -------- Subject: New Version Notification for draft-mrugalski-dhc-dhcpv6-failover-design-01.txt Date: Mon, 12 Mar 2012 13:41:56 -0700 From: internet-drafts@ietf.org To: tomasz.mrugalski@gmail.com CC: kkinnear@cisco.com A new version of I-D, draft-mrugalski-dhc-dhcpv6-failover-design-01.txt has been successfully submitted by Tomasz Mrugalski and posted to the IETF repository. Filename: draft-mrugalski-dhc-dhcpv6-failover-design Revision: 01 Title: DHCPv6 Failover Design Creation date: 2012-03-12 WG ID: Individual Submission Number of pages: 42 Abstract: DHCPv6 defined in [RFC3315] does not offer server redundancy. This document defines a design for DHCPv6 failover, a mechanism for running two servers on the same network with capability for either server to take over clients' leases in case of server failure or network partition. This is a DHCPv6 Failover design document, it is not protocol specification document. It is a second document in a planned series of three documents. DHCPv6 failover requirements are specified in [requirements]. A protocol specification document is planned to follow this document. The IETF Secretariat From tomasz.mrugalski@gmail.com Sun Apr 8 15:36:32 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D5621F84C5 for ; Sun, 8 Apr 2012 15:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBkvSQw0oZ-n for ; Sun, 8 Apr 2012 15:36:31 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 52EE921F84B5 for ; Sun, 8 Apr 2012 15:36:31 -0700 (PDT) Received: by werb10 with SMTP id b10so2765005wer.31 for ; Sun, 08 Apr 2012 15:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=HGxce2V0172s2VCXdZ/6+NIjTQxghvDoGeF6tJjxVnA=; b=pJ8KO+7eXhewDdiElguTUDMVsa11LgoNhjskyMQMmsFkNLM7DuRy3DSkza3aEm3oKZ OtTKU62Rna0CPaTUxll6WvX6oXt2bMtJYo3TwaMhaGPICteFeGxjYqfqojak1fx9zi46 fMjhQ1mietI4B3vtnxZnphdEh5APeDp4f75/ULtHMY6Oh0Wq4+3T5sbWAVzhm5D0ajxF 1LwAiDT9ZWtQ8J/E26nm93V/oXLHnEdACI3K6oxnCV7ak2JMp29bZ7PJ/883YK/ksmYg Ru0tvCqYYO+8q8Vilm/woSgCXlrDBCSdeRHTfzi1laksD1LqODdESHYqsZV+7+Kfq0+q 4zYw== Received: by 10.216.134.41 with SMTP id r41mr2966562wei.13.1333924590108; Sun, 08 Apr 2012 15:36:30 -0700 (PDT) Received: from tomek.local (095160002041.lomza.vectranet.pl. [95.160.2.41]) by mx.google.com with ESMTPS id b3sm25621429wib.4.2012.04.08.15.36.28 (version=SSLv3 cipher=OTHER); Sun, 08 Apr 2012 15:36:29 -0700 (PDT) Message-ID: <4F8212EC.5020706@gmail.com> Date: Mon, 09 Apr 2012 00:36:28 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Bernie Volz (volz)" References: <4F81BA73.4000400@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Ole Troan Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 22:36:32 -0000 On 12-04-08 23:26, Bernie Volz (volz) wrote: > Regarding 0, no. This work would be folded into 3315bis but it should > proceed separately. Primarily because it is needed "now" and the 3315bis > work will probably be at a much slower pace. > ... > This work is really related to 6204bis and the fact that the cable > market needs the router behavior to be clarified. Sure. In that case pick only those of my comments that you think are useful in 6204bis context and we can get back to the other ones later during 3315bis work. > back to Solicit, this allows the client the ability to RENEW the IA_PD > and include the IA_NA to get a new address (that hopefully won't have > the DAD or other conflict). Note that in this RENEW, the IA_NA would not > have an IA_ADDR option (or if it does, it would be the unspecified > address). Ok, that is less scary than it initially looked. Nevertheless, I still don't like it much. Using RENEW to request new addresses or prefixes is wrong and will not work. It is true that to some extent REQUEST and RENEW work in similar manner, but they were kept separated for a reason. I would prefer to send a separate REQUEST for requesting new allocations. Also, the idea to use RENEW to get new address/prefix will not work with conformant implementations. Servers will send back IA, but with status code set to NoBinding. Here's appropriate part of 3315, section 18.2.3: If the server cannot find a client entry for the IA the server returns the IA containing no addresses with a Status Code option set to NoBinding in the Reply message. So no, don't request anything new in RENEW. That's what REQUEST is for. Tomek From volz@cisco.com Sun Apr 8 17:21:26 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EF921F858E for ; Sun, 8 Apr 2012 17:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.524 X-Spam-Level: X-Spam-Status: No, score=-11.524 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRFxg4SiU67g for ; Sun, 8 Apr 2012 17:21:25 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6E19F21F8507 for ; Sun, 8 Apr 2012 17:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=11171; q=dns/txt; s=iport; t=1333930885; x=1335140485; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ONTyNPjAeSV5HDbOyHLTP0NXzuIeXprRJjY3MlsWKJw=; b=KUUulONc0DFaVuMm6Lxvwg6s1RlIi0xVtrzjgLPW/wq6d/JTbpiZiY1J visQwxVGVHGQtA5+4x2erg7L+ZP2YfJOkwHg+o1Ts6PMlO2BPG+/Duy5e TklqripvrQ8JonKMVe+/0IKtQWaT3blXdwIYFgzgjHwz3oBLJYWZYNyGF 8=; X-IronPort-AV: E=Sophos;i="4.75,391,1330905600"; d="scan'208";a="73008789" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 09 Apr 2012 00:21:25 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q390LPqd027138; Mon, 9 Apr 2012 00:21:25 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 Apr 2012 19:21:24 -0500 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: Sun, 8 Apr 2012 19:21:23 -0500 Message-ID: In-Reply-To: <4F81BA73.4000400@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item Thread-Index: Ac0Vo1FUC+sddg0sScatsbgk57mmYgALM5+Q References: <4F81BA73.4000400@gmail.com> From: "Bernie Volz (volz)" To: "Tomek Mrugalski" , , "Ole Troan" X-OriginalArrivalTime: 09 Apr 2012 00:21:24.0796 (UTC) FILETIME=[B2AD0FC0:01CD15E6] Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 00:21:27 -0000 Tomek: I spend some time reviewing your other points and have comments inline. Ole's position on any of these may be different. Thanks again for your support and feedback!! Much appreciated. - Bernie -----Original Message----- From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com]=20 Sent: Sunday, April 08, 2012 12:19 PM To: dhcwg@ietf.org; Ole Troan Cc: Bernie Volz (volz) Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item On 12-04-05 19:25, Bernie Volz (volz) wrote: > I kindly request that we adopt this document as a DHC WG work item. I do support this work and its adoption. I also have couple of comments: 0. Would it be reasonable to name this work 3315bis? BV> Already discussed in previous email. 1. I assume this work will also cover all combinations of IA_NA/IA_PD/IA_TA. But what about IA_PA, specified in draft-ietf-dhc-host-gen-id? This work was adopted by DHC, so authors should take a closer look at it. (I'm sorry I can't offer any better comments here. I haven't read host-gen-id yet). BV> Already discussed in previous email. 2. stateful-issues draft is a very useful work. Once adopted it should also look at CGA issues - my understanding is that it basically degrades DHCP into registration service, compared to normal assignment service. I haven't read CGA drafts recently, so again this is only a pointer to something that should be looked at. It is possible that there's nothing to do in that matter. BV> This will have to be studied further. Another interesting question will be how this interacts with failover. We also need to look at the usage cases - will CGA addresses and PD be used by a device (seems to make some sense) and whether the current CGA procedures can accommodate this in the Solicit/Advertise/Request/Reply[/Renew/Reply...] cycle. 3. Abstract could be reworded: "the ne options for Prefix Delegation options for DHCPv6 into DHCPv6" part is repetitive. The same is true for first paragraph of Introduction section. BV> Yes. 4. Text refer to different IA options as IA_. I think it would look better without the underscore. If that is not clear, perhaps it could be clarified that "IA option" means any of IA_NA, IA_TA or IA_PD. BV> Yes. We should use better/consistent terminology. "IA options" is probably better. 5. Section 3.1 states that client MUST ignore IAs with status code NoAddrAvail. That doesn't help much. What about other status codes? IA_PD may be returned with NoPrefixAvail. Much better would be to say that client MUST ignore IAs with status code other than Success. BV> This is just to replace a specific text in Section 17.1.3 that referred to NoAddrsAvail case. I think the new text needs to be fixed as the 'ignore any IAs' here applies to IA_NA (and perhaps IA_TA) but not IA_PD. But to be fair, RFC 3315 only references IA_NA/IA_TA. The point here is simply that NoAddrsAvail applies to IA_NA/IA_TA options and the client should process these for IA_PD (and potentially other IA options). We should also add that client SHOULD rate advertise without assigned IAs lower than other advertises, but exact advertise rating algorithm is up to client imlementors. For example, I would implement a client that accepts advertise with preference=3D5 and all IAs assigned rather than = one with preference=3D10, but without IA_NA or IA_PD assigned. BV> Yes, this is a good point. Advertises with all requests satisfied should rank higher than ones with one some. This does get complicate fast and we want to make sure to keep it simple since in most cases there will only be one Advertise (there usually aren't a lot of DHCP servers on networks with very different configurations). 6. Section 3.2 says that 3 non-success status codes (NoAddrsAvail, NoPrefixAvail and NotOnLink) should appear within IA options. It would be better to not explicitely limit to those 3 status code, but say all non-success status codes to maintain forward compatibility. Something like "e.g. NoAddrsAvail, NoPrefixAvail, NotOnLink and other non-success status codes" will do. BTW you missed UnspecFail code that is already defined and could be used, so the text as it is does not cover all situations from day 1. BV> 3.2 lists "NoAddrsAvail, NotOnlink, NoBinding" and is describing the differences between the possible location of Status Code options in Reply and Advertise messages.I don't think UnspecFail appears encapsulated in an IA option (where did you find that)? BV> I do think we need to revise the "Proposed Solution" as it isn't just IA_NA but also IA_TA. We believe it best to keep backwards compatibility and not change the existing behavior as we might break client implementations if were to change this. So, we want to stick with the current RFC 3315 behavior. What we feel we can change is that the client SHOULD look at the other IA options that are returned and the 'other configuration' options and use them. Existing clients that follow RFC 3315 to the letter won't as they'll ignore these Advertise messages. 7. It should be clarified that status codes are specified per instance of an option, not per option type. Think about client that sends 3 IA_NA options. It can receive 2 addresses and NoAddrAvail in the third instance. That could be either due to pool depletion (unlikely) or server policy that allow server to assign no more than 2 addresses per client (likely). BV> Actually section 17.2.2 in RFC 3315 says nothing like that. If there are 3 IA_NA options and 2 return addresses, then the Advertise will contain 3 IA_NA options, 2 with IA_ADDR option(s) and one with no IA_ADDR options. The NoAddrAvail is ONLY used when the server returns NO addresses to any IA_NA/IA_TA options. 8. Proposed replacement errata in section 3.2 should clarify that such proposed action should be taken on each IA being answered. BV> Not sure I understand your comment. I think that the text should say this NoAddrsAvail ONLY applies to the IA_NA/IA_TA options). IA_PD is already covered by RFC 3633. And, other IA_* options should state what the behavior is to be (hopefully following IA_PDs lead and encapsulating the status code into the IA option). We can't change IA_NA/IA_TA because of backwards compatibility, but all others should follow the IA_PD lead and place the "NoAddrsAvail" or whatever status code option inside the IA option. 9. Section 3.3 could mention relation between T1/T2 and information refresh option (RFC4242). The reasonable clarification would be that client MAY request other options in ORO when sending RENEW or REBIND. BV> Could you clarify? RFC 4242 (Information Refresh Time) states: "It is only used in Reply messages in response to Information-Request messages." I believe that the T1/T2 times are to cover the 'other information' renewal. 10. Allowing PD to be confirmed with CONFIRM could be tricky. In many deployment scenarios routing is configured separately for each delegated prefix and server can't really say "yeah, I've never assigned you that one, but it should be valid on your link.". I don't object allowing IA_PD in CONFRIM, but it should be accompanied with a clause that server MUST include IA_PD response only if it is certain that delegated prefix is really valid. This will complicate things. What is client sends CONFIRM with IA_NA and IA_PD and server can confirm that address is on-link, but is not sure about prefix? There's no such status as IdontKnow. Different IA combinations should be given more thought. BV> Yes, there is an I Don't Know status. The server MUST NOT Reply in that case. Confirm has this built in. That's why I like Confirm. It doesn't overload other messages. It doesn't require the heavier weight processing of Renew (or Rebind). It allows for 3 responses types - On Link (Success), NotOnLink, and I can't tell / don't know (drop Confirm). BV> I really wonder how often this concept of the delegated prefix being completely outside anything other servers (on the same network) know is. In all of the PD cases I'm aware of, the other would know. Yes, I agree it "could" happen. But in those cases if you used Renew, you'd gain nothing since only the assigning server would be able to say yes or no. 11. Section 3.5. A what??? Are you suggesting that client can send RENEW *after* it sent RELEASE? If that is the case, I strongly object. Once client released a lease, it has no further claims to released address/prefix. It MUST NOT send RENEW. Proper way it to send REQUEST, not RENEW. Also. Section 3.5 title mentions DECLINE, but there is nothing about DECLINE in the text. Authors probably forgot adding a sentence that DECLINE may be sent at any time when client owns a lease. BV> Already answers this in previous email. Yes, we need to clean up this text. DECLINE is the more likely situation. I am not sure why a client would Release just the address but not the prefix if it got both. We probably should add something to the document about discouraging releasing only 'half' the acquired leases. 12. A question about proposed operation in section 3.6. What if there are two servers. Imagines a case with 2 servers: one that provides addresses and second one that provides prefixes. Client requests IA_NA and IA_PD. What should client do? BV> We have specifically indicated that this is NOT a situation we are supporting. We consider this split administrative domains. We will need to add text. BV> If you look at the slide deck uploaded for IETF-83 (Paris), the last slide has a slide about Administrative Domains. So, this is something we will work on. The idea is fairly simple in that we'd add a new "Administrative Domain Name" option which servers could include in replies. The client COULD then decide which administrative domain it wants to use and even support split domains (i.e., accept an Advertise from one domain for addresses and another for prefixes). Clearly there are security issues and client complexity here but if people want this, we'll need to craft something to handle it. BV> Note that the Authentication option already has something like this - the "DHCP Realm". But this would be separating out this concept from any authentication. 13. In 3rd paragraph in section 3.6 it would be better to say non-success status codes rather than NoAddrsAvail (or at least NoAddrsAvail/NoPrefixAvail/NotOnLink/UnspecFail). BV> The RFC 3315 text would only reference NoAddrsAvail. 3633 would need to change to specify NoPrefixAvail instead of NoBinding. But NotOnLink and UnspecFail are not applicable here (they are as already is). 14. Section 3.7 is the most unfortunate. I understand the reasons that led authors to that decision, so I sadly accept it. BV> As mentioned above, we intend to follow on with work to address this (see your 12). Despite my comments, I strongly support this work and it adoption. It is great that we will get this thing clarified. Greetings to all woods dwellers, BV> Thanks! Tomek From volz@cisco.com Sun Apr 8 17:27:40 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0392E21F8513 for ; Sun, 8 Apr 2012 17:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.739 X-Spam-Level: X-Spam-Status: No, score=-10.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLjE4tXYe8MV for ; Sun, 8 Apr 2012 17:27:39 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3059621F84FB for ; Sun, 8 Apr 2012 17:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3564; q=dns/txt; s=iport; t=1333931259; x=1335140859; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=oD8IuojV3oUHBJ+5MAKeYJWr39EMmmIYR4hca16HRJI=; b=Slqb9GBhlqXaXsQYcSZUeaONUNQWC4xp3BtDx1G5SIQevi75qMvd5UXM fDaLT/jGDYRPboae7VrZmXvF0jaiM2zuufuGa7Gxn2ct6v7SKWoT+szx2 PYdZ44Drl/MWJ5RImWyeCLTBjCk4fVEJ3szGcXxgsNw5O9F5h91E1h7y4 E=; X-IronPort-AV: E=Sophos;i="4.75,391,1330905600"; d="scan'208";a="69987836" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 09 Apr 2012 00:27:39 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q390RcvR000323; Mon, 9 Apr 2012 00:27:38 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 Apr 2012 19:27:38 -0500 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: Sun, 8 Apr 2012 19:27:37 -0500 Message-ID: In-Reply-To: <4F8212EC.5020706@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item Thread-Index: Ac0V2A6b4foyEVqHRpqMUKibm1AlwgADqSUA References: <4F81BA73.4000400@gmail.com> <4F8212EC.5020706@gmail.com> From: "Bernie Volz (volz)" To: "Tomek Mrugalski" X-OriginalArrivalTime: 09 Apr 2012 00:27:38.0592 (UTC) FILETIME=[9179CE00:01CD15E7] Cc: dhcwg@ietf.org, Ole Troan Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 00:27:40 -0000 > Also, the idea to use RENEW to get new address/prefix will not work with conformant implementations. Correct. Existing servers will respond as they have been. But clients will be no worse off than they are today. This is probably a point that should be made and clients that can't expect new servers will have to live with the old behavior. What would you propose? Doing a REQUEST hardly seems correct either. We want to avoid separate 'state machines' in the clients and have one set of request messages handle the client recovering. Note also that I believe that the REBIND behavior as specified today is BROKEN for failover. Consider the case Server A gives out a lease but goes down before updating its partner, Server B. Server B now gets the REBIND at T2. It would send back NoBinding as it has no record of the client and/or bindings. This needs to change too for failover to work - at least if we want to be consistent with the way we handle this in v4 failover. I don't think the RENEW (or REBIND) is damaged by allowing new bindings. The client is still asking to renew leases but to also get new ones. Why is that so bad? The addresses (or prefix) can change in a Renew/Rebinding, so why not allow new bindings? Note that we are NEVER saying a client can send a RENEW or REBIND without having at least one valid lease. It must at least have one binding & lease. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Sunday, April 08, 2012 6:36 PM To: Bernie Volz (volz) Cc: dhcwg@ietf.org; Ole Troan Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item On 12-04-08 23:26, Bernie Volz (volz) wrote: > Regarding 0, no. This work would be folded into 3315bis but it should=20 > proceed separately. Primarily because it is needed "now" and the=20 > 3315bis work will probably be at a much slower pace. > ... > This work is really related to 6204bis and the fact that the cable=20 > market needs the router behavior to be clarified. Sure. In that case pick only those of my comments that you think are useful in 6204bis context and we can get back to the other ones later during 3315bis work. > back to Solicit, this allows the client the ability to RENEW the IA_PD > and include the IA_NA to get a new address (that hopefully won't have=20 > the DAD or other conflict). Note that in this RENEW, the IA_NA would=20 > not have an IA_ADDR option (or if it does, it would be the unspecified > address). Ok, that is less scary than it initially looked. Nevertheless, I still don't like it much. Using RENEW to request new addresses or prefixes is wrong and will not work. It is true that to some extent REQUEST and RENEW work in similar manner, but they were kept separated for a reason. I would prefer to send a separate REQUEST for requesting new allocations. Also, the idea to use RENEW to get new address/prefix will not work with conformant implementations. Servers will send back IA, but with status code set to NoBinding. Here's appropriate part of 3315, section 18.2.3: If the server cannot find a client entry for the IA the server returns the IA containing no addresses with a Status Code option set to NoBinding in the Reply message. So no, don't request anything new in RENEW. That's what REQUEST is for. Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dankney@network1.net Mon Apr 9 05:52:42 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B3921F86DF for ; Mon, 9 Apr 2012 05:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQaIALHXyXIZ for ; Mon, 9 Apr 2012 05:52:42 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id CEBC521F86D7 for ; Mon, 9 Apr 2012 05:52:41 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id E89A4542C55; Mon, 9 Apr 2012 08:52:40 -0400 (EDT) Date: Mon, 09 Apr 2012 08:52:40 -0400 (EDT) From: perl-list To: Tomek Mrugalski Message-ID: <57cc53bb-4480-422a-be20-ede9e9bb95d5@zimbra.network1.net> In-Reply-To: <4F820DE1.9090907@gmail.com> Content-Type: multipart/alternative; boundary="=_a755fe60-502f-4ee1-a58b-bf44a0092180" MIME-Version: 1.0 X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Cc: DHC WG Subject: Re: [dhcwg] Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-design-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 12:52:42 -0000 --=_a755fe60-502f-4ee1-a58b-bf44a0092180 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I support adopting this document as a DHC WG item. ----- Original Message ----- > From: "Tomek Mrugalski" > To: "DHC WG" > Sent: Sunday, April 8, 2012 6:14:57 PM > Subject: [dhcwg] Requesting adoption of > draft-mrugalski-dhc-dhcpv6-failover-design-01 > Hi, > DHCPv6 Failover Design draft was presented in Paris DHC meeting and > it > got a lot of support (around 20 supporters) without any notable > opposition. > I kindly request that we adopt this document as a DHC WG work item. > Tomek > -------- Original Message -------- > Subject: New Version Notification for > draft-mrugalski-dhc-dhcpv6-failover-design-01.txt > Date: Mon, 12 Mar 2012 13:41:56 -0700 > From: internet-drafts@ietf.org > To: tomasz.mrugalski@gmail.com > CC: kkinnear@cisco.com > A new version of I-D, > draft-mrugalski-dhc-dhcpv6-failover-design-01.txt > has been successfully submitted by Tomasz Mrugalski and posted to the > IETF repository. > Filename: draft-mrugalski-dhc-dhcpv6-failover-design > Revision: 01 > Title: DHCPv6 Failover Design > Creation date: 2012-03-12 > WG ID: Individual Submission > Number of pages: 42 > Abstract: > DHCPv6 defined in [RFC3315] does not offer server redundancy. This > document defines a design for DHCPv6 failover, a mechanism for > running two servers on the same network with capability for either > server to take over clients' leases in case of server failure or > network partition. This is a DHCPv6 Failover design document, it is > not protocol specification document. It is a second document in a > planned series of three documents. DHCPv6 failover requirements are > specified in [requirements]. A protocol specification document is > planned to follow this document. > The IETF Secretariat > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=_a755fe60-502f-4ee1-a58b-bf44a0092180 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Andale Mono; font-size: 10pt; color: #000000'>I s= upport adopting this document as a DHC WG item.


From: "Tomek Mrugalski" <tomasz.mrugalski@gmail.com>
<= b>To: "DHC WG" <dhcwg@ietf.org>
Sent: Sunday, April 8, = 2012 6:14:57 PM
Subject: [dhcwg] Requesting adoption of &nbs= p;      draft-mrugalski-dhc-dhcpv6-failover-d= esign-01

Hi,
DHCPv6 Failover Design draft was presented in Paris = DHC meeting and it
got a lot of support (around 20 supporters) without a= ny notable opposition.

I kindly request that we adopt this document = as a DHC WG work item.

Tomek

-------- Original Message ------= --
Subject: New Version Notification for
draft-mrugalski-dhc-dhcpv6-f= ailover-design-01.txt
Date: Mon, 12 Mar 2012 13:41:56 -0700
From: int= ernet-drafts@ietf.org
To: tomasz.mrugalski@gmail.com
CC: kkinnear@cis= co.com

A new version of I-D, draft-mrugalski-dhc-dhcpv6-failover-des= ign-01.txt
has been successfully submitted by Tomasz Mrugalski and poste= d to the
IETF repository.

Filename:     =     draft-mrugalski-dhc-dhcpv6-failover-design
Revision:&= nbsp;        01
Title:  &nb= sp;            =   DHCPv6 Failover Design
Creation date:    &nbs= p;    2012-03-12
WG ID:     &nbs= p;           Individual S= ubmission
Number of pages: 42

Abstract:
   DHCPv6 de= fined in [RFC3315] does not offer server redundancy.  This
 &n= bsp; document defines a design for DHCPv6 failover, a mechanism for
&nbs= p;  running two servers on the same network with capability for either=
   server to take over clients' leases in case of server fail= ure or
   network partition.  This is a DHCPv6 Failover d= esign document, it is
   not protocol specification document. =  It is a second document in a
   planned series of three = documents.  DHCPv6 failover requirements are
   specified= in [requirements].  A protocol specification document is
 &nb= sp; planned to follow this document.





The IETF Secret= ariat
_______________________________________________
dhcwg mailing l= ist
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

--=_a755fe60-502f-4ee1-a58b-bf44a0092180-- From Dmitry.Anipko@microsoft.com Mon Apr 9 22:18:57 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B11D21F8782 for ; Mon, 9 Apr 2012 22:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYXWdMrMGhrX for ; Mon, 9 Apr 2012 22:18:56 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id A141621F8498 for ; Mon, 9 Apr 2012 22:18:56 -0700 (PDT) Received: from mail14-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Apr 2012 05:18:56 +0000 Received: from mail14-tx2 (localhost [127.0.0.1]) by mail14-tx2-R.bigfish.com (Postfix) with ESMTP id 0ABA96012C for ; Tue, 10 Apr 2012 05:18:56 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzc85dhzz1202hzzz2fh2a8h683h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail14-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail14-tx2 (localhost.localdomain [127.0.0.1]) by mail14-tx2 (MessageSwitch) id 133403513469186_5138; Tue, 10 Apr 2012 05:18:54 +0000 (UTC) Received: from TX2EHSMHS020.bigfish.com (unknown [10.9.14.253]) by mail14-tx2.bigfish.com (Postfix) with ESMTP id 0C4C71E013D for ; Tue, 10 Apr 2012 05:18:54 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS020.bigfish.com (10.9.99.120) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Apr 2012 05:18:53 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.283.4; Tue, 10 Apr 2012 05:18:52 +0000 Received: from mail7-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Tue, 10 Apr 2012 05:18:51 +0000 Received: from mail7-va3 (localhost [127.0.0.1]) by mail7-va3-R.bigfish.com (Postfix) with ESMTP id B5F35380300 for ; Tue, 10 Apr 2012 05:18:51 +0000 (UTC) Received: from mail7-va3 (localhost.localdomain [127.0.0.1]) by mail7-va3 (MessageSwitch) id 1334035129753754_3265; Tue, 10 Apr 2012 05:18:49 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.244]) by mail7-va3.bigfish.com (Postfix) with ESMTP id A926412005B for ; Tue, 10 Apr 2012 05:18:49 +0000 (UTC) Received: from CH1PRD0310HT005.namprd03.prod.outlook.com (157.56.244.37) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Apr 2012 05:18:49 +0000 Received: from CH1PRD0310MB368.namprd03.prod.outlook.com ([169.254.12.61]) by CH1PRD0310HT005.namprd03.prod.outlook.com ([10.255.137.40]) with mapi id 14.16.0143.004; Tue, 10 Apr 2012 05:18:48 +0000 From: Dmitry Anipko To: "dhcwg@ietf.org" Thread-Topic: draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces Thread-Index: Ac0W2WVgE6a1w+FwSKK6eT929Ok/5g== Date: Tue, 10 Apr 2012 05:18:47 +0000 Message-ID: <96DD85EB136DCD49AB5CDB6DEC9639AD0458D4@CH1PRD0310MB368.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.24.173.147] Content-Type: multipart/alternative; boundary="_000_96DD85EB136DCD49AB5CDB6DEC9639AD0458D4CH1PRD0310MB368na_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT005.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 05:18:57 -0000 --_000_96DD85EB136DCD49AB5CDB6DEC9639AD0458D4CH1PRD0310MB368na_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, during the WG meeting in Paris, there was a brief discussion around the sub= ject and the authors asked me to take it to the list. For context: the CRA behavior in section 6 implies that somehow CRA knows 1= :1 mapping between server responses, received over IPv6, and IPv4 interface= s where decapsulated DHCPv4 packets should be indicated. The mechanism how= CRA knows that is unclear in case there are multiple IPv4 interfaces on th= e host. It would be useful to add text, that discusses whether multiple IPV4 interf= aces are in scope, and if they are - what are the possible ways how they ca= n be handled, and what's the recommended way. If there are multiple ways and all of them are equally preferrable and won'= t affect interoperability, having such analysis&language would be helpful t= oo. -Dmitry --_000_96DD85EB136DCD49AB5CDB6DEC9639AD0458D4CH1PRD0310MB368na_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

during the WG meeting in Paris, there was a brief discussion around the = subject and the authors asked me to take it to the list.

 

For context: the CRA behavior in section 6 implies that somehow CRA know= s 1:1 mapping between server responses, received over IPv6, and IPv4 interf= aces where decapsulated DHCPv4 packets should be indicated.  The mecha= nism how CRA knows that is unclear in case there are multiple IPv4 interfaces on the host.

 

It would be useful to add text, that discusses whether multiple IPV4 int= erfaces are in scope, and if they are - what are the possible ways how they= can be handled, and what's the recommended way.

 

If there are multiple ways and all of them are equally preferrable and w= on't affect interoperability, having such analysis&language would be he= lpful too.

 

-Dmitry

--_000_96DD85EB136DCD49AB5CDB6DEC9639AD0458D4CH1PRD0310MB368na_-- From Ted.Lemon@nominum.com Tue Apr 10 07:14:05 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD77F21F862B for ; Tue, 10 Apr 2012 07:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.432 X-Spam-Level: X-Spam-Status: No, score=-106.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEG2XS5X+AIK for ; Tue, 10 Apr 2012 07:14:05 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7A71F21F8621 for ; Tue, 10 Apr 2012 07:14:00 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT4RAJ4wv3MI0UdCSo0aSeOYjBbwwG7il@postini.com; Tue, 10 Apr 2012 07:14:02 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id ECFD21B8313 for ; Tue, 10 Apr 2012 07:13:57 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E1BB319006D; Tue, 10 Apr 2012 07:13:57 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 10 Apr 2012 07:13:57 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [dhcwg] Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-design-01 Thread-Index: AQHNFdUOdLCpCRiXV0yWYUk8x9pa75aUkgMA Date: Tue, 10 Apr 2012 14:13:57 +0000 Message-ID: References: <20120312204156.30819.94209.idtracker@ietfa.amsl.com> <4F820DE1.9090907@gmail.com> In-Reply-To: <4F820DE1.9090907@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_F7BE5872FD0740CD9F6C3F21932410C9nominumcom_" MIME-Version: 1.0 Cc: DHC WG Subject: Re: [dhcwg] Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-design-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:14:05 -0000 --_000_F7BE5872FD0740CD9F6C3F21932410C9nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 8, 2012, at 6:14 PM, Tomek Mrugalski > wrote: I kindly request that we adopt this document as a DHC WG work item. Please consider Tomek's request an official call for adoption. If you ar= e in favor of adopting this as a working group work item, please say so. = If you are against, please say so. We will evaluate consensus to adopt this draft as a working group work item= on April 24. --_000_F7BE5872FD0740CD9F6C3F21932410C9nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4909AAD11A4F614AA4EAD71E1175702B@nominum.com> Content-Transfer-Encoding: quoted-printable
On Apr 8, 2012, at 6:14 PM, Tomek Mrugalski <tomasz.mrugalski@gmail.com> wrote:
I kindly request that we adopt this document as a DHC WG work item. To: Hans Liu , Ted Lemon Thread-Topic: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item Thread-Index: AQHNE1JrRGmAWNJ1mE2rJP62g6RfYJaPYiOAgATPUpA= Date: Tue, 10 Apr 2012 15:10:45 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61108DBD5@GAALPA1MSGUSR9N.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.164.202.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=LnSh8mvAXcUA:10 a=ueVt6eR2Vb0A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=Qs8R1XBwmid1qB] X-AnalysisOut: [FB/a8mmA==:17 a=48vgC7mUAAAA:8 a=DGbFYnXxAAAA:8 a=AUd_NHdV] X-AnalysisOut: [AAAA:8 a=nqAJsqf0GMNNUvs9Fj4A:9 a=lx5SXbTeKKABrk04SHkA:7 a] X-AnalysisOut: [=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=bSyc6FVMW0oA:10 a=JfD] X-AnalysisOut: [0Fch1gWkA:10 a=gayHzoHnYOVn0EuH:21 a=X7zm8tmscqzjwwYG:21] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:11:23 -0000 KzENCkJhcmJhcmENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkaGN3 Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmDQo+IE9mIEhhbnMgTGl1DQo+IFNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAwNywgMjAxMiA1OjQz IEFNDQo+IFRvOiBUZWQgTGVtb24NCj4gQ2M6IGRoY3dnQGlldGYub3JnIFdHDQo+IFN1YmplY3Q6 IFJlOiBbZGhjd2ddIENhbGwgZm9yIEFkb3B0aW9uLCBkcmFmdC10cm9hbi1kaGMtZGhjcHY2LXN0 YXRlZnVsLQ0KPiBpc3N1ZXMtMDAgYXMgV0cgaXRlbQ0KPiANCj4gSSBzdXBwb3J0IGFkb3B0aW9u IG9mIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiBDaGVlcnMsDQo+IEhhbnMNCj4gDQo+IE9uIEZyaSwg QXByIDYsIDIwMTIgYXQgMTozNCBBTSwgVGVkIExlbW9uIDxUZWQuTGVtb25Abm9taW51bS5jb20+ DQo+IHdyb3RlOg0KPiA+IE9uIEFwciA1LCAyMDEyLCBhdCAxOjI1IFBNLCBCZXJuaWUgVm9seiAo dm9seikgPHZvbHpAY2lzY28uY29tPiB3cm90ZToNCj4gPg0KPiA+IEF0IHRoZSBQYXJpcyBJRVRG LTgzIERIQyBXRyBtZWV0aW5nIHRoZXJlIHdhcyBhIGxvdCBvZiBzdXBwb3J0IGZvcg0KPiA+IChh bmQgSSBiZWxpZXZlIG5vIG9wcG9zaXRpb24pIGFkb3B0aW5nIHRoaXMgYXMgYSBESEMgV0cgaXRl bS4NCj4gPg0KPiA+IEkga2luZGx5IHJlcXVlc3QgdGhhdCB3ZSBhZG9wdCB0aGlzIGRvY3VtZW50 IGFzIGEgREhDIFdHIHdvcmsgaXRlbS4NCj4gPg0KPiA+DQo+ID4gVGhpcyBkcmFmdCBkb2N1bWVu dHMgaXNzdWVzIHRoYXQgaGF2ZSBjb21lIHVwIGludm9sdmluZyBpbnRlcmFjdGlvbnMNCj4gPiBi ZXR3ZWVuIHByZWZpeCBkZWxlZ2F0aW9uIGFuZCByZWd1bGFyIElQIGFkZHJlc3MgYWxsb2NhdGlv biBpbg0KPiA+IHByYWN0aWNlLiDCoCBJZiB5b3Ugd291bGQgbGlrZSB0aGUgd29ya2luZyBncm91 cCB0byB3b3JrIG9uIGRvY3VtZW50aW5nDQo+ID4gdGhpcywgcGxlYXNlIHNpZ25pZnkgYnkgcmVz cG9uZGluZyB0byB0aGlzIG1lc3NhZ2UgaW4gdGhlIGFmZmlybWF0aXZlLg0KPiA+IElmIHlvdSBk b24ndCB0aGluayB3ZSBzaG91bGQgd29yayBvbiBpdCwgcGxlYXNlIHJlc3BvbmQgaW4gdGhlDQo+ ID4gbmVnYXRpdmUuIMKgIElmIHlvdSBoYXZlIG5vIG9waW5pb24sIHBsZWFzZSBkbyBub3QgcmVz cG9uZC4NCj4gPg0KPiA+IFdlIHdpbGwgZGV0ZXJtaW5lIGNvbnNlbnN1cyBvbiBUaHVyc2RheSwg QXByaWwgMTkuDQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4gZGhjd2cgbWFpbGluZyBsaXN0DQo+ID4gZGhjd2dAaWV0Zi5v cmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+ID4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGhj d2cgbWFpbGluZyBsaXN0DQo+IGRoY3dnQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg== From shwethab@cisco.com Tue Apr 10 18:05:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A34611E8081 for ; Tue, 10 Apr 2012 18:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.787 X-Spam-Level: X-Spam-Status: No, score=-6.787 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAoPINjyCZe2 for ; Tue, 10 Apr 2012 18:05:06 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 958E911E8139 for ; Tue, 10 Apr 2012 18:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shwethab@cisco.com; l=21287; q=dns/txt; s=iport; t=1334106305; x=1335315905; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=V6u0lqR1p6csprMsevGqsk9vl3y4Xwlb+ZzSmQMOlhM=; b=AYyMJeDdww9oo70H36SOYvdVJ6j82Ljlm2l6z7sfM2IxpwkFVxu0T+dT c+ZbW70R0/RStm8ArKT69KYjaffNyaxgMkABM+u6BDbG8JLq7tKB3puB+ fVyvxbgAvmytwBsGHktN8ZPKGZgkfgisIi9Jk9Gm+qln0XzfTXE1Z9y2N Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAEbYhE9Io8UY/2dsb2JhbAA6CoJGtgWBeYIJAQEBAwESASoqCAoSAQgJgRQBAQQBCgMFIodnBZo9oCKLGYYlBIgnMYUuh2aOTYFpgm8 X-IronPort-AV: E=Sophos;i="4.75,402,1330905600"; d="scan'208,217";a="9714253" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 11 Apr 2012 01:05:02 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3B152tr016469; Wed, 11 Apr 2012 01:05:02 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 06:35:02 +0530 Received: from 10.65.70.240 ([10.65.70.240]) by XMB-BGL-417.cisco.com ([72.163.129.213]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Apr 2012 01:05:01 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 11 Apr 2012 06:39:40 +0530 From: shwethab To: "THIEBAUT, LAURENT (LAURENT)" , "dhcwg@ietf.org" Message-ID: Thread-Topic: Comments on draft-bhandari-dhc-class-based-prefix Thread-Index: Ac0TKg5fU1U46I++QVmuEChI3Dn6DwEVbbMn In-Reply-To: <170E8FCC2134BD42B539B47798ABF8F0133B2C8BBD@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3416971180_14725138" X-OriginalArrivalTime: 11 Apr 2012 01:05:02.0138 (UTC) FILETIME=[1F8F41A0:01CD177F] Cc: Sri Gundavelli Subject: Re: [dhcwg] Comments on draft-bhandari-dhc-class-based-prefix X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 01:05:10 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3416971180_14725138 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hello Laurent, Thanks for the comments. I agree that we need structure to Prefix class option =AD we could have a a type and value within its content. Type would indicate whether its IETF defined class or Vendor. Based on the type value can then be interpreted, may be from a IANA defined name space if it is IETF. I will rework on the structure of the option and update the draft. Regarding including this option in Information request message: if the semantics and content of configuration-information-class option would be same as Prefix class, we can rename the Prefix class option suitably or let the same option be used to request configuration from a specific class in information request as well. Thanks, Shwetha On 4/5/12 6:16 PM, "THIEBAUT, LAURENT (LAURENT)" wrote: > =20 > =20 > Hello Shwetha, hello all > As a follow up of the discussion we have had in Paris, please a few comme= nts > on this very interesting ID > 1. As opposed to the =B3OPTION_USER_CLASS=B2 whose semantics is undefined= and > whose impact to the system is loosely defined, the new =B3PREFIX_CLASS opti= on=B2 > allows a well defined structure to ensure inter-operability beyond a corp= orate > proprietary usage, i.e. to make sure that different organisations cannot > allocate the same value for the =B3PREFIX_CLASS option=B2. Indeed the definit= ion > and structure and indication of usage of the =B3User Class Option=B2 is too l= oose > to guarantee inter-operability beyond a corporate deployment > 22.15. User Class Option > The User Class option is used by a client to identify the type or categor= y of > user or applications it represents. > =8A > =20 > The information contained in the data area of this option is contained in= one > or more *opaque* fields that represent the user class or classes of which= the > client is a member. A server selects configuration information for the c= lient > based on the classes identified in this option. For example, the User Cl= ass > option can be used to configure all clients of people in the accounting > department with a different printer than clients of people in the marketi= ng > department. The user class information carried in this option MUST be > configurable on the client. > =8A=8A > (The =B3User Class Option=B2 can=B9t be used in a non proprietary context as > different organisations can by accident allocate the same value to this > information) > This comment is an =AB endorsement=B2 of draft-bhandari-dhc-class-based-prefi= x > =20 > 2. The =B3PREFIX_CLASS option=B2 should allow to specify > * Prefix-classes defined by IETF > * Prefix classes defined by other standard fora > * (proprietary) Prefix classes defined by a corporate > =20 > =20 > 3. The proposed structure would be as follows > * =B3Prefix class name space=B2 with 2 values: =B3IETF=B2 / =B3other organisation=B2 > * =B3Prefix class owner=B2 (required in case the =B3Prefix class name space=B2 is > =B3other organisation=B2, not present when =B3Prefix class name space=B2 is =B3IETF= =B2). > Other organisation may be another standard forum (e.g. BBF) or a corporat= e. > * =B3Prefix class value=B2 whose structure depends on the =B3Prefix class name > space=B2 and =B3Prefix class owner=B2 > =20 > =20 > 4. As the =B3User Class Option=B2 does not benefit from such structure it > cannot be used beyond a corporate proprietary usage. Thus the =B3User Class > Option=B2 cannot provide an interoperable parameter to be used when a DHCP > client sends an Information-Request message to obtain (IP) configuration > information. Following alternatives may be envisaged: > a) Either the =B3PREFIX_CLASS option=B2 is used in Information-Request. I= t is > agreed that the name =B3PREFIX_CLASS option=B2 would then not be well suited = for > usage in Information-Request and that thus the name of this option should= be > changed.=20 > b) Another possibility is to define a =B3configuration-information-clas= s > option=B2 whose semantics is explicitly made the same as the =B3PREFIX_CLASS > option=B2 and to be used as follows: > o The DHCP client puts a =B3configuration-information-class option=B2i= n > Information-Request to request that the IP parameters values sent by the = DHCP > server are determined as the most suitable for the IP service associated = with > the =B3configuration-information-class option=B2 > o when a DHCPv6 client sends a SOLICIT message to request both > =B7 for IA_NA address allocation from a specific prefix class > =B7 and to obtain (IP) configuration information using Option Reques= t > option (per RFC 3315 section 22.7) > it populates the SOLICIT message as follows: > =B7 within the IA_NA option, it includes the OPTION_PREFIX_CLASS > requesting address to be allocated from a specific prefix class indicated= in > that option > =B7 within the Option Request option (per RFC 3315 section 22.7) it > includes the =B3configuration-information-class option=B2 requesting configur= ation > parameters sent by the DHCP server are determined as the most suitable fo= r the > IP service associated with the =B3configuration-information-class option=B2. > =20 > If these comments are felt useful, I can provide actual text for the draf= t. > Best regards=20 >=20 > Laurent=20 >=20 >=20 > =20 >=20 --B_3416971180_14725138 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Comments on draft-bhandari-dhc-class-based-prefix Hello Laurent,

Thanks for the comments.

I agree that we need structure to Prefix class option – we could have= a a type and value within its content. Type would indicate whether its IETF= defined class or Vendor. Based on the type value can then be interpreted, m= ay be from a IANA defined name space if it is IETF. I will rework on the str= ucture of the  option and update the draft.

Regarding including this option in Information request message: if = the semantics and content of configuration-inf= ormation-class option would be same as Prefix c= lass, we can rename the Prefix class option suitably or let the same option = be used to request configuration from a specific class in information reques= t as well.

Thanks,
Shwetha


On 4/5/12 6:16 PM, "THIEBAUT, LAURENT (LAURENT)" <laurent.thiebaut@alcatel-lucent.com>= ; wrote:


 
Hello Shwetha, hello all
As a follow up of the discussion we have had in Paris, please a few comment= s on this very interesting ID
1.     As opposed to the “OPTION_USER_CLASS” whose semantics is undefined and whose impact to the s= ystem is loosely defined, the new “PREFIX_CLASS option” allows a well defined structure to ensure inter-operabili= ty beyond a corporate proprietary usage, i.e. to make sure that different or= ganisations cannot allocate the same value for the “PREFIX_CLASS option”. Indeed the definition and structure and= indication of usage of the “User Class O= ption” is too loose to guarantee inter-o= perability beyond a corporate deployment
22.15. User Class Option
The User Class option is used by a client to identify the type or category = of user or applications it represents.
…
 
The information contained in the data area of this option is contained in o= ne or more *opaque* fields that represent the user class or classes o= f which the client is a member.  A server selects configuration informa= tion for the client based on the classes identified in this option.  Fo= r example, the User Class option can be used to configure all clients of peo= ple in the accounting department with a different printer than clients of pe= ople in the marketing department. The user class information carried in this= option MUST be configurable on the client.
   ……
(The “User Cla= ss Option” can’t be used in a non proprietary context as differe= nt organisations can by accident allocate the same value to this information= )
This comment is an « endorsement” of draft-bhandari-dhc-class-b= ased-prefix
 
2.     The “PREFIX_CLASS optionPrefix-classes defined = by IETF=20
  • Prefix classes defined by other standard = fora=20
  • (proprietary) Prefix classes defined by a= corporate

     
    3.     =     The proposed struct= ure would be as follows
    • “Prefix class nam= e space” with 2 values: “IETF” / “other organisation= ”=20
    • “Prefix class owner” (require= d in case the “Prefix class name space” is “other organisa= tion”, not present when “Prefix class name space” is ̶= 0;IETF”). Other organisation may be another standard forum (e.g. BBF) = or a corporate.=20
    • “Prefix class value” whose st= ructure depends on the “Prefix class name space” and “Pref= ix class owner”

     
    4.     =     As the “    User Class Option̶= 1; does not benefit from such structure it cannot be used beyond a corporate= proprietary usage. Thus the “User Class = Option” cannot provide an interoperable = parameter to be used when a DHCP client sends an Information-Request message= to obtain (IP) configuration information. Following alternatives may be envisaged:
    a)     =     Either the “<= /FONT>    PREFIX_CLASS option” is used in Information-Request. It is agr= eed that the name “PRE= FIX_CLASS option̶= 1; would then not be well suited for usage in Information-Request and that t= hus the name of this option should be changed.
    b)         Another possibility is to define a     “configuration-information-class option” w= hose semantics is explicitly made the same as the “PREFIX= _CLASS option” = and to be used as follows:
    o  = ;     The DHCP cli= ent  puts a     “configuration-i= nformation-class option&#= 8221;    in Information-Request to request that th= e IP parameters values sent by the DHCP server are determined as the most su= itable for the IP service associated with the &= #8220;    configuration-information-class o= ption”
    o       when a DHCPv6 client sends a SOLICIT message to request= both
    · &nb= sp;      for = IA_NA address allocation from a specific prefix class
    · &nb= sp;      and = to obtain (IP) configuration information using Option Request option (per RF= C 3315 section 22.7)
    it populates the SOLICIT message as follows:
    · &nb= sp;      with= in the IA_NA option, it includes the OPTION_PREFIX_CLASS requesting address = to be allocated from a specific prefix class indicated in that option
    · &nb= sp;      with= in the Option Request option (per RFC 3315 section 22.7) it includes the “configuration-information-class option” = requesting configuration parameters sent by the DHCP server = are determined as the most suitable for the IP service associated with the <= /SPAN><= SPAN STYLE=3D'font-size:11pt'>“configuration-information-class option”.
    Best regar= ds

    Laurent


     

    • --B_3416971180_14725138-- From shwethab@cisco.com Tue Apr 10 21:03:53 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDBC11E809F for ; Tue, 10 Apr 2012 21:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIgg3IDcP61j for ; Tue, 10 Apr 2012 21:03:52 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1B62E11E8096 for ; Tue, 10 Apr 2012 21:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shwethab@cisco.com; l=217; q=dns/txt; s=iport; t=1334117032; x=1335326632; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=UrHZyoSwWFOkjM1yNnkOlHaAq68tenThmm4d56B4YTQ=; b=d8jk3f8uIkSKGRE71BkAwhJWodx/KDkjwsRVgjYE5zzIQwQJfV001IGj jR5QxMQgoa7lxR8JhC1mruWdyC4hK9IfuG702Qv36nKngj3AXezQ5huQa hQdBMaIyd0mhnaUj663vdYJVqKsyb+Ib75582WnrCTtk9Kxi25nU7OYbg 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIHAAMChU9Io8UY/2dsb2JhbABFiimvE4EJggsBBBIBJwIBPBIBEYEUAgQLAyeHbJpSoCaRPgSIWIUuh2aOTSeBQoJv X-IronPort-AV: E=Sophos;i="4.75,402,1330905600"; d="scan'208";a="9725599" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 11 Apr 2012 04:03:50 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3B43oMU019173; Wed, 11 Apr 2012 04:03:50 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 09:33:50 +0530 Received: from 173.39.64.183 ([173.39.64.183]) by XMB-BGL-417.cisco.com ([72.163.129.213]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Apr 2012 04:03:49 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 11 Apr 2012 09:38:29 +0530 From: shwethab To: Ted Lemon Message-ID: Thread-Topic: [dhcwg] Requesting adoption of draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 Thread-Index: AQHNFdUOdLCpCRiXV0yWYUk8x9pa75aUkgMAgABz07k= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Apr 2012 04:03:50.0198 (UTC) FILETIME=[19FB4D60:01CD1798] Cc: DHC WG Subject: [dhcwg] Requesting adoption of draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 04:03:53 -0000 Hello Ted, DHC wg was in favor of adopting draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 as a WG item at ietf83 Paris. I kindly request that we adopt this document as a DHC WG work item. Thanks, Shwetha From ghalwasi@cisco.com Tue Apr 10 21:10:42 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D121021F865A for ; Tue, 10 Apr 2012 21:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3BjDhtDrfQH for ; Tue, 10 Apr 2012 21:10:42 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id CC68421F8659 for ; Tue, 10 Apr 2012 21:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=5675; q=dns/txt; s=iport; t=1334117439; x=1335327039; h=mime-version:subject:date:message-id:from:to:cc; bh=REZjRwkFLjsmwz1GmRiXkt5C5qlpxBlzPDK3b9i6Qc8=; b=gvvHyNkqIbFCdIOJXU4swSSYim4TpeOnxiIq9jSaYhOYogrb+8nvFlX5 lkRz1xHOz3nV0mksIc5zbh45D0QlhIcRQAw44/V6S3lx62OpVMcjYs8j1 Sb5jYsxtsO4huSS0/G9vLvdX9XDRAK4NzpXcjFm5KH6qJkeD5hl5EWLyy k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4EAEEDhU9Io8UY/2dsb2JhbABDglCuCwGJc4ILAQQSAQkRA0kSASoGGAdXAQQLEBqHbAueV5hAkFtjBIhYjiWNPIFpgm8 X-IronPort-AV: E=Sophos;i="4.75,403,1330905600"; d="scan'208,217";a="9726312" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 11 Apr 2012 04:10:37 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3B4AbcN006249; Wed, 11 Apr 2012 04:10:37 GMT Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 09:40:37 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1799.0C68BE86" Date: Wed, 11 Apr 2012 09:40:36 +0530 Message-ID: <3CF88B99A9ED504197498BC6F6F04B81060E60B0@XMB-BGL-41E.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requesting for WGLC for draft-ietf-dhc-client-id-02 Thread-Index: Ac0XmQwpEAg+V480T8OWyoVqoPY2nw== From: "Gaurav Halwasia (ghalwasi)" To: "Ted Lemon" X-OriginalArrivalTime: 11 Apr 2012 04:10:37.0305 (UTC) FILETIME=[0CA2E690:01CD1799] Cc: dhcwg@ietf.org Subject: [dhcwg] Requesting for WGLC for draft-ietf-dhc-client-id-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 04:10:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1799.0C68BE86 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ted, =20 DHC WG was in favor of doing WGLC for http://tools.ietf.org/html/draft-ietf-dhc-client-id-02 during Paris Meeting. Requesting you to kindly do the WGLC for this WG draft. =20 Thanks, Gaurav =20 =20 ------_=_NextPart_001_01CD1799.0C68BE86 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi = Ted,

     

    DHC WG was in favor of doing WGLC for http://to= ols.ietf.org/html/draft-ietf-dhc-client-id-02 during Paris Meeting. = Requesting you to kindly do the WGLC for this WG draft.

     

    Thanks,

    Gaurav

     

     

    ------_=_NextPart_001_01CD1799.0C68BE86-- From internet-drafts@ietf.org Tue Apr 10 23:52:29 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645CF11E8096; Tue, 10 Apr 2012 23:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dycNtAwXekxN; Tue, 10 Apr 2012 23:52:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF47011E809F; Tue, 10 Apr 2012 23:52:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120411065228.19282.46634.idtracker@ietfa.amsl.com> Date: Tue, 10 Apr 2012 23:52:28 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-cga-config-dhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 06:52:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : Configuring Cryptographically Generated Addresses (CGA) = using DHCPv6 Author(s) : Sheng Jiang Filename : draft-ietf-dhc-cga-config-dhcpv6-02.txt Pages : 11 Date : 2012-04-10 A Cryptographically Generated Address is an IPv6 addresses binding with a public/private key pair. However, the current CGA specifications are lack of procedures to enable proper management of the usage of CGAs. This document defines the process using DHCPv6 to manage CGAs in detail. A new DHCPv6 option is defined accordingly. This document also analyses the configuration of the parameters, which are used to generate CGAs, using DHCPv6. Although the document does not define new DHCPv6 option to carry these parameters for various reasons, the configuration procedure is described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-cga-config-dhcpv6-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-cga-config-dhcpv6-02.txt From Francis.Dupont@fdupont.fr Wed Apr 11 05:39:43 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E701621F8690 for ; Wed, 11 Apr 2012 05:39:42 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZSF4d0wYqok for ; Wed, 11 Apr 2012 05:39:42 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 160FE21F868A for ; Wed, 11 Apr 2012 05:39:41 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3BCde0k050505; Wed, 11 Apr 2012 14:39:41 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204111239.q3BCde0k050505@givry.fdupont.fr> From: Francis Dupont To: Dmitry Anipko In-reply-to: Your message of Tue, 10 Apr 2012 05:18:47 -0000. <96DD85EB136DCD49AB5CDB6DEC9639AD0458D4@CH1PRD0310MB368.namprd03.prod.outlook.com> Date: Wed, 11 Apr 2012 14:39:40 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 12:39:43 -0000 In your previous mail you wrote: > during the WG meeting in Paris, there was a brief discussion around > the subject and the authors asked me to take it to the list. => yes, the authors want to make the I-D ready for a WGLC so any pending questions are wellcome now. > For context: the CRA behavior in section 6 implies that somehow CRA > knows 1:1 mapping between server responses, received over IPv6, and > IPv4 interfaces where decapsulated DHCPv4 packets should be > indicated. The mechanism how CRA knows that is unclear in case > there are multiple IPv4 interfaces on the host. => as I (too briefly) explained at the meeting this is a question I got when I wrote the CRA code: I started from a plain DHCPv4/DHCPv6 relay and I removed all the useless features (e.g., DHCPv6) but when I reached the multiple interface one I stopped a bit I tried to understand the consequences: clearly the CRA is too simple to handle multiple interfaces, for instance there is no way to assign a received answer to an interface. So the choice was between looking what to add in the CRA spec or looking whether it could be a problem. Note DHCPv4 clients usually have the same constraint: a client process manages only one interface and when a host have multiple interfaces multiple client processes (one per interface) are used. According to the DHCPv4 over IPv6 architecture (e.g., the co-location between client and CRA) a similar solution could be applied: a CRA process per interface. I checked if this removes any feature: the only constraint is for the CRA processes to use a different IPv6 address. IMHO this is a very acceptable constraint. > It would be useful to add text, that discusses whether multiple IPV4 > interfaces are in scope, and if they are - what are the possible > ways how they can be handled, and what's the recommended way. => it is far better to add a statement explaining the proposed solution than to make the CRA more complex. > If there are multiple ways and all of them are equally preferrable > and won't affect interoperability, having such analysis&language > would be helpful too. => I am afraid I didn't look for another solution (other than to complexify the CRA). BTW the IPv6 address is used by the server (TSV or a standard DHCPv4 behind a TSA) to "localize" (i.e., to associate to a configured link) the client so IMHO other solutions should make the whole DHCPv4 over IPv6 more complex. Thanks Francis.Dupont@fdupont.fr From dankney@network1.net Wed Apr 11 06:05:52 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17CD21F86A5 for ; Wed, 11 Apr 2012 06:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qo5yEu+Vr3XX for ; Wed, 11 Apr 2012 06:05:52 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAAD21F86A1 for ; Wed, 11 Apr 2012 06:05:51 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 23E23542DB3; Wed, 11 Apr 2012 09:05:51 -0400 (EDT) Date: Wed, 11 Apr 2012 09:05:51 -0400 (EDT) From: perl-list To: shwethab Message-ID: <482bdc01-9428-488d-acef-954ad5e70f45@zimbra.network1.net> In-Reply-To: Content-Type: multipart/alternative; boundary="=_0acd3024-8496-400c-9ecc-b1e362e74075" MIME-Version: 1.0 X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Mac)/7.1.2_GA_3268) Cc: DHC WG , Ted Lemon Subject: Re: [dhcwg] Requesting adoption of draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:05:52 -0000 --=_0acd3024-8496-400c-9ecc-b1e362e74075 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I very much support adopting draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 as a WG item ----- Original Message ----- > From: "shwethab" > To: "Ted Lemon" > Cc: "DHC WG" > Sent: Wednesday, April 11, 2012 12:08:29 AM > Subject: [dhcwg] Requesting adoption of > draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 > Hello Ted, > DHC wg was in favor of adopting > draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 as a WG item at ietf83 > Paris. > I kindly request that we adopt this document as a DHC WG work item. > Thanks, > Shwetha > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=_0acd3024-8496-400c-9ecc-b1e362e74075 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Andale Mono; font-size: 10pt; color: #000000'>I v= ery much support adopting draft-halwasia-dhc-dhcpv6-hardware-addr-opt-= 01 as a WG item


    From: "shwethab" = <shwethab@cisco.com>
    To: "Ted Lemon" <Ted.Lemon@nominum.= com>
    Cc: "DHC WG" <dhcwg@ietf.org>
    Sent: Wedne= sday, April 11, 2012 12:08:29 AM
    Subject: [dhcwg] Requesting adop= tion of draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01

    Hello Ted,
    DHC wg was in favor of adopting
    draft-halwasia-dhc-dhcpv6-hardware-= addr-opt-01 as a WG item at ietf83 Paris.
    I kindly request that we adopt= this document as a DHC WG work item.

    Thanks,
    Shwetha
     
    _______________________________________________
    dhcwg mailing list=
    dhcwg@ietf.org
    https://www.ietf.org/mailman/listinfo/dhcwg


    --=_0acd3024-8496-400c-9ecc-b1e362e74075-- From sunqi.thu@gmail.com Wed Apr 11 06:30:49 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACD711E80A3 for ; Wed, 11 Apr 2012 06:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.179 X-Spam-Level: X-Spam-Status: No, score=-0.179 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_IP_218085=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSLiAtBQqAqO for ; Wed, 11 Apr 2012 06:30:48 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDB611E8122 for ; Wed, 11 Apr 2012 06:30:48 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1243251pbb.31 for ; Wed, 11 Apr 2012 06:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-mailer:mime-version:message-id:content-type; bh=uCR/rO+nlJ/zX7k4qKc2/HZ7WWwAlOtS9CAOdr8sZSk=; b=IFilVVR6kcepQUTBlDUBSgqUT/AG5v7M+dxVcdyyMeM+ThWvKqiXwUe2YmZIh+pWL5 1lCFopz5BV2G43b1vR96FwqutBJ3q2u5+fXpIVqw+9YYqK/KKb82upPWYv0tibLqBMYi jHvvIfjAtAWvRGOsfuCtiI5FNKwRHDHadMT78aPoBYKHmIdkuhT/qP+csG19qeG5ILl1 6/6Xpt4bZRvvA1/MgT1/xQJpt/EWTEQpooy0e5wOpPbh8l0a/SNrqGYG6H6fLHO0jvTx yBkh8Def9ideW/XfSYm0oFbgs0kdfrtdLd5vZj1cm8JWSDXpe9Dhc1PTU34aJGrkqQ8h Zc8g== Received: by 10.68.217.67 with SMTP id ow3mr38755538pbc.16.1334151047829; Wed, 11 Apr 2012 06:30:47 -0700 (PDT) Received: from sunqi ([218.86.7.100]) by mx.google.com with ESMTPS id l1sm2908235pbs.34.2012.04.11.06.30.36 (version=SSLv3 cipher=OTHER); Wed, 11 Apr 2012 06:30:47 -0700 (PDT) Date: Wed, 11 Apr 2012 21:30:28 +0800 From: "Qi Sun" To: "Francis Dupont" , "Dmitry Anipko" References: <201204111239.q3BCde0k050505@givry.fdupont.fr> X-Priority: 3 X-GUID: FE196462-D142-44C2-AC98-BBDB0F0EDE63 X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <2012041121302844224623@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart226332383377_=----" Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.thu" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:30:49 -0000 This is a multi-part message in MIME format. ------=_001_NextPart226332383377_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBGcmFuY2lzIGFuZCBEbWl0cnksDQogICAgDQogICAgICAgIEFzIGEgcHJvY2VzcyBvZiBE SENQLCBpdCBpcyBncmVhdCB0byBrZWVwIGl0IHNpbXBsZSByYXRoZXIgdGhhbiB0byBwZXJwbGV4 IGl0LiBOb3cgdGhhdCB0aGVyZSBpcyBhIHNhbWUgc2l0dWF0aW9uIGluIERIQ1B2NCBwcm9jZXNz LCBESENQdjQgb3ZlciBJUHY2IGNvdWxkIHVzZSBhIHNpbWlsYXIgc29sdXRpb24sIGp1c3QgYXMg RnJhbmNpcyBzdGF0ZWQuIENvbnNpZGVyaW5nIG11bHRpcGxlLWludGVyZmFjZXMgYSBzcGVjaWFs IGNhc2UgZm9yIHRoZSBESENQdjQgb3ZlciBJUHY2IG1lY2hhbmlzbSwgSU1ITyBhIG1vcmUgcHJv cGVyIHdheSBpcyB0byBtYWtlIGl0IGNsZWFyIGluIHRoZSBkcmFmdCB3aXRoIG9uZSBzb2x1dGlv bi4NCg0KQmVzdCBSZWdhcmRzIQ0KDQoNCg0KDQpRaSBTdW4NCg0KRnJvbTogRnJhbmNpcyBEdXBv bnQNCkRhdGU6IDIwMTItMDQtMTEgMjA6MzkNClRvOiBEbWl0cnkgQW5pcGtvDQpDQzogZGhjd2dA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZGhjd2ddIGRyYWZ0LWlldGYtZGhjLWRoY3B2NC1vdmVy LWlwdjYtMDIgLyBtdWx0aXBsZSBpcHY0IGludGVyZmFjZXMNCiBJbiB5b3VyIHByZXZpb3VzIG1h aWwgeW91IHdyb3RlOg0KDQo+IGR1cmluZyB0aGUgV0cgbWVldGluZyBpbiBQYXJpcywgdGhlcmUg d2FzIGEgYnJpZWYgZGlzY3Vzc2lvbiBhcm91bmQNCj4gdGhlIHN1YmplY3QgYW5kIHRoZSBhdXRo b3JzIGFza2VkIG1lIHRvIHRha2UgaXQgdG8gdGhlIGxpc3QuDQoNCj0+IHllcywgdGhlIGF1dGhv cnMgd2FudCB0byBtYWtlIHRoZSBJLUQgcmVhZHkgZm9yIGEgV0dMQyBzbw0KYW55IHBlbmRpbmcg cXVlc3Rpb25zIGFyZSB3ZWxsY29tZSBub3cuDQoNCj4gRm9yIGNvbnRleHQ6IHRoZSBDUkEgYmVo YXZpb3IgaW4gc2VjdGlvbiA2IGltcGxpZXMgdGhhdCBzb21laG93IENSQQ0KPiAga25vd3MgMTox IG1hcHBpbmcgYmV0d2VlbiBzZXJ2ZXIgcmVzcG9uc2VzLCByZWNlaXZlZCBvdmVyIElQdjYsIGFu ZA0KPiAgSVB2NCBpbnRlcmZhY2VzIHdoZXJlIGRlY2Fwc3VsYXRlZCBESENQdjQgcGFja2V0cyBz aG91bGQgYmUNCj4gIGluZGljYXRlZC4gIFRoZSBtZWNoYW5pc20gaG93IENSQSBrbm93cyB0aGF0 IGlzIHVuY2xlYXIgaW4gY2FzZQ0KPiAgdGhlcmUgYXJlIG11bHRpcGxlIElQdjQgaW50ZXJmYWNl cyBvbiB0aGUgaG9zdC4NCg0KPT4gYXMgSSAodG9vIGJyaWVmbHkpIGV4cGxhaW5lZCBhdCB0aGUg bWVldGluZyB0aGlzIGlzIGEgcXVlc3Rpb24gSSBnb3QNCndoZW4gSSB3cm90ZSB0aGUgQ1JBIGNv ZGU6IEkgc3RhcnRlZCBmcm9tIGEgcGxhaW4gREhDUHY0L0RIQ1B2NiByZWxheQ0KYW5kIEkgcmVt b3ZlZCBhbGwgdGhlIHVzZWxlc3MgZmVhdHVyZXMgKGUuZy4sIERIQ1B2NikgYnV0IHdoZW4gSSBy ZWFjaGVkDQp0aGUgbXVsdGlwbGUgaW50ZXJmYWNlIG9uZSBJIHN0b3BwZWQgYSBiaXQgSSB0cmll ZCB0byB1bmRlcnN0YW5kIHRoZQ0KY29uc2VxdWVuY2VzOiBjbGVhcmx5IHRoZSBDUkEgaXMgdG9v IHNpbXBsZSB0byBoYW5kbGUgbXVsdGlwbGUgaW50ZXJmYWNlcywNCmZvciBpbnN0YW5jZSB0aGVy ZSBpcyBubyB3YXkgdG8gYXNzaWduIGEgcmVjZWl2ZWQgYW5zd2VyIHRvIGFuIGludGVyZmFjZS4N Cg0KU28gdGhlIGNob2ljZSB3YXMgYmV0d2VlbiBsb29raW5nIHdoYXQgdG8gYWRkIGluIHRoZSBD UkEgc3BlYyBvciBsb29raW5nDQp3aGV0aGVyIGl0IGNvdWxkIGJlIGEgcHJvYmxlbS4gTm90ZSBE SENQdjQgY2xpZW50cyB1c3VhbGx5IGhhdmUgdGhlDQpzYW1lIGNvbnN0cmFpbnQ6IGEgY2xpZW50 IHByb2Nlc3MgbWFuYWdlcyBvbmx5IG9uZSBpbnRlcmZhY2UgYW5kIHdoZW4NCmEgaG9zdCBoYXZl IG11bHRpcGxlIGludGVyZmFjZXMgbXVsdGlwbGUgY2xpZW50IHByb2Nlc3NlcyAob25lIHBlcg0K aW50ZXJmYWNlKSBhcmUgdXNlZC4NCg0KQWNjb3JkaW5nIHRvIHRoZSBESENQdjQgb3ZlciBJUHY2 IGFyY2hpdGVjdHVyZSAoZS5nLiwgdGhlIGNvLWxvY2F0aW9uDQpiZXR3ZWVuIGNsaWVudCBhbmQg Q1JBKSBhIHNpbWlsYXIgc29sdXRpb24gY291bGQgYmUgYXBwbGllZDogYSBDUkEgcHJvY2Vzcw0K cGVyIGludGVyZmFjZS4gSSBjaGVja2VkIGlmIHRoaXMgcmVtb3ZlcyBhbnkgZmVhdHVyZTogdGhl IG9ubHkgY29uc3RyYWludA0KaXMgZm9yIHRoZSBDUkEgcHJvY2Vzc2VzIHRvIHVzZSBhIGRpZmZl cmVudCBJUHY2IGFkZHJlc3MuIElNSE8gdGhpcyBpcw0KYSB2ZXJ5IGFjY2VwdGFibGUgY29uc3Ry YWludC4NCg0KPiBJdCB3b3VsZCBiZSB1c2VmdWwgdG8gYWRkIHRleHQsIHRoYXQgZGlzY3Vzc2Vz IHdoZXRoZXIgbXVsdGlwbGUgSVBWNA0KPiBpbnRlcmZhY2VzIGFyZSBpbiBzY29wZSwgYW5kIGlm IHRoZXkgYXJlIC0gd2hhdCBhcmUgdGhlIHBvc3NpYmxlDQo+IHdheXMgaG93IHRoZXkgY2FuIGJl IGhhbmRsZWQsIGFuZCB3aGF0J3MgdGhlIHJlY29tbWVuZGVkIHdheS4NCg0KPT4gaXQgaXMgZmFy IGJldHRlciB0byBhZGQgYSBzdGF0ZW1lbnQgZXhwbGFpbmluZyB0aGUgcHJvcG9zZWQgc29sdXRp b24NCnRoYW4gdG8gbWFrZSB0aGUgQ1JBIG1vcmUgY29tcGxleC4NCg0KPiBJZiB0aGVyZSBhcmUg bXVsdGlwbGUgd2F5cyBhbmQgYWxsIG9mIHRoZW0gYXJlIGVxdWFsbHkgcHJlZmVycmFibGUNCj4g YW5kIHdvbid0IGFmZmVjdCBpbnRlcm9wZXJhYmlsaXR5LCBoYXZpbmcgc3VjaCBhbmFseXNpcyZs YW5ndWFnZQ0KPiB3b3VsZCBiZSBoZWxwZnVsIHRvby4NCg0KPT4gSSBhbSBhZnJhaWQgSSBkaWRu J3QgbG9vayBmb3IgYW5vdGhlciBzb2x1dGlvbiAob3RoZXIgdGhhbiB0bw0KY29tcGxleGlmeSB0 aGUgQ1JBKS4gQlRXIHRoZSBJUHY2IGFkZHJlc3MgaXMgdXNlZCBieSB0aGUgc2VydmVyDQooVFNW IG9yIGEgc3RhbmRhcmQgREhDUHY0IGJlaGluZCBhIFRTQSkgdG8gImxvY2FsaXplIiAoaS5lLiwg dG8NCmFzc29jaWF0ZSB0byBhIGNvbmZpZ3VyZWQgbGluaykgdGhlIGNsaWVudCBzbyBJTUhPIG90 aGVyIHNvbHV0aW9ucw0Kc2hvdWxkIG1ha2UgdGhlIHdob2xlIERIQ1B2NCBvdmVyIElQdjYgbW9y ZSBjb21wbGV4Lg0KDQpUaGFua3MNCg0KRnJhbmNpcy5EdXBvbnRAZmR1cG9udC5mcg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRoY3dnIG1haWxpbmcg bGlzdA0KZGhjd2dAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZGhjd2c= ------=_001_NextPart226332383377_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
    Dear Francis and Dmitry,
       
            As a process of DHCP, it i= s=20 great to keep it simple rather than to perplex it. Now that there is = a same=20 situation in DHCPv4 process, DHCPv4 over IPv6 could use a similar solution= , just=20 as Francis stated. Considering multiple-interfaces a special case for= the=20 DHCPv4 over IPv6 mechanism, IMHO a more proper way is to make it clear in = the=20 draft with one solution.
     
    Best Regards!
     
    Qi Sun
     
    Date: 2012-04-11 20:39
    CC: dhcwg@ietf.org<= /DIV>
    Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 /= =20 multiple ipv4 interfaces
     In your previous mail you wrote:
     
    > during the WG meeting in Paris,&nb= sp;there was a brief discussion around
    > the subject and the authors asked&= nbsp;me to take it to the list.
     
    =3D> yes, the authors want to make&n= bsp;the I-D ready for a WGLC so
    any pending questions are wellcome now.
     
    > For context: the CRA behavior in&n= bsp;section 6 implies that somehow CRA
    >  knows 1:1 mapping between server&= nbsp;responses, received over IPv6, and
    >  IPv4 interfaces where decapsulated&nbs= p;DHCPv4 packets should be
    >  indicated.  The mechanism how&nbs= p;CRA knows that is unclear in case
    >  there are multiple IPv4 interface= s on the host.
     
    =3D> as I (too briefly) explained at=  the meeting this is a question I = got
    when I wrote the CRA code: I start= ed from a plain DHCPv4/DHCPv6 relay
    and I removed all the useless features&= nbsp;(e.g., DHCPv6) but when I reached
    the multiple interface one I stopped a&= nbsp;bit I tried to understand the
    consequences: clearly the CRA is too si= mple to handle multiple interfaces,
    for instance there is no way to as= sign a received answer to an interface.
     
    So the choice was between looking what&= nbsp;to add in the CRA spec or looking<= /DIV>
    whether it could be a problem. Note&nbs= p;DHCPv4 clients usually have the
    same constraint: a client process manages&nb= sp;only one interface and when
    a host have multiple interfaces multiple&nbs= p;client processes (one per
    interface) are used.
     
    According to the DHCPv4 over IPv6 archi= tecture (e.g., the co-location
    between client and CRA) a similar solut= ion could be applied: a CRA process
    per interface. I checked if this remove= s any feature: the only constraint
    is for the CRA processes to use a&= nbsp;different IPv6 address. IMHO this is
    a very acceptable constraint.
     
    > It would be useful to add tex= t, that discusses whether multiple IPV4
    > interfaces are in scope, and if&nb= sp;they are - what are the possible
    > ways how they can be handled, = ;and what's the recommended way.
     
    =3D> it is far better to add a&= nbsp;statement explaining the proposed solution
    than to make the CRA more complex.
     
    > If there are multiple ways and&nbs= p;all of them are equally preferrable
    > and won't affect interoperability, havi= ng such analysis&language
    > would be helpful too.
     
    =3D> I am afraid I didn't look = for another solution (other than to
    complexify the CRA). BTW the IPv6 addre= ss is used by the server
    (TSV or a standard DHCPv4 behind a = ;TSA) to "localize" (i.e., to
    associate to a configured link) the cli= ent so IMHO other solutions
    should make the whole DHCPv4 over IPv6&= nbsp;more complex.
     
    Thanks
     
    Francis.Dupont@fdupont.fr
    _______________________________________________
    dhcwg mailing list
    dhcwg@ietf.org
    https://www.ietf.org/mailman/listinfo/dhcwg
    ------=_001_NextPart226332383377_=------ From tomasz.mrugalski@gmail.com Wed Apr 11 06:50:35 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7E911E8163 for ; Wed, 11 Apr 2012 06:50:35 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAeJIQdHQoVg for ; Wed, 11 Apr 2012 06:50:35 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05CEF11E8159 for ; Wed, 11 Apr 2012 06:50:34 -0700 (PDT) Received: by bkuw5 with SMTP id w5so876900bku.31 for ; Wed, 11 Apr 2012 06:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=zMyyycAsawqrL0uzR6iUO9s3m+bkw2/+A9Zvs+2PYlI=; b=0hPPOS8DklwOAJAE2Lq9DDn4HRHudCd0g+Y3IsQpu6dT+NR9JdnFSXoO5Hra8tTdi2 aE208INWQSkvlPCsfoF4o3jfR0lIvhLUzQ/kH9/1psULdCsKgzP9CBbaSzihgHlSdz7T 9K3Cam/HsALIAQnFE0roLX7VzuYvVhuQjv0yeppchSNtA2xZJh6ERR7kSOcXnDWMJojg EM7o9YLa9pFMCUtPzJ8dydda7854OGa2hVpRsH6MvumETEH63es4nO+rCo+hD+lkrgA4 ztxfBwwKtlgpDk7BW8c2MjslojLTeNYels7C1hnr7B7rc97hDSDx39bM/gg2AM2JkuyR 6NHQ== Received: by 10.204.156.216 with SMTP id y24mr6027921bkw.60.1334152234099; Wed, 11 Apr 2012 06:50:34 -0700 (PDT) Received: from tomek.local (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id c4sm5067505bkh.0.2012.04.11.06.50.33 (version=SSLv3 cipher=OTHER); Wed, 11 Apr 2012 06:50:33 -0700 (PDT) Message-ID: <4F858C25.4050706@gmail.com> Date: Wed, 11 Apr 2012 15:50:29 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dhcwg@ietf.org References: <482bdc01-9428-488d-acef-954ad5e70f45@zimbra.network1.net> In-Reply-To: <482bdc01-9428-488d-acef-954ad5e70f45@zimbra.network1.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Requesting adoption of draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:50:35 -0000 On 12-04-11 15:05, perl-list wrote: > I very much support > adopting draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 as a WG item +1 Tomek From pengwu.thu@gmail.com Wed Apr 11 08:22:20 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E805221F84F1 for ; Wed, 11 Apr 2012 08:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVHMbPOVhnFA for ; Wed, 11 Apr 2012 08:22:19 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2364F21F84DA for ; Wed, 11 Apr 2012 08:22:19 -0700 (PDT) Received: by dady13 with SMTP id y13so1872388dad.27 for ; Wed, 11 Apr 2012 08:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=sSxm2JZNp9d1tIJ79A1dYxcsGOU7TXY8QcJ2e1sn0vM=; b=YrSUHxkjWE2WhJxF8YRI5QCGVJe2G2j9dGe42LDZyY7om6sB7R1xFefDafr2c2lT7w 5qH7C13dXHHPYo+haHAJ5ijzu1+92HI0WZpVy6fHHjbN3Ri1dYvdGhnQDtffa9Q12fSn oOjjxxFyDn/awcnPne595Kc3Fdp3qyoi/uxu+l0gQQPqf4vRtuQFfj0FfUDIMZEQvLmf nJycNgYwTQkN2gnuiHI107J65p+Q3KR09Zmpn9MuvDBFMoTV/0W8cRgAnRtabnnAhxKT wkdDlHksVBtUTuITpbBAekao/7WFeqSjNqR2iinu2ACNoZSEPilvzaMUk9rkae+ewZK2 Z5EQ== MIME-Version: 1.0 Received: by 10.68.222.165 with SMTP id qn5mr38494503pbc.88.1334157733026; Wed, 11 Apr 2012 08:22:13 -0700 (PDT) Received: by 10.68.21.103 with HTTP; Wed, 11 Apr 2012 08:22:12 -0700 (PDT) In-Reply-To: <201204111239.q3BCde0k050505@givry.fdupont.fr> References: <96DD85EB136DCD49AB5CDB6DEC9639AD0458D4@CH1PRD0310MB368.namprd03.prod.outlook.com> <201204111239.q3BCde0k050505@givry.fdupont.fr> Date: Wed, 11 Apr 2012 23:22:12 +0800 Message-ID: From: Peng Wu To: Francis Dupont Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org" , Dmitry Anipko Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:22:20 -0000 Hi Francis & Dmitry, Francis's proposal is one option. The CRA per-interface is reasonable. I see RFC6334 made some similar assumption. The cost is different addresses for different CRAs, the gain is we made DHCP client clean. Another proposal(by Ted) is to use client ID options for different interfac= es. This way DHCP mssages for different interfaces can be identified. The cost is that we may need a little intellegence in the client. So if we *have to* put some text on this subject in the draft, we could go simply like: "A CRA SHOULD serve only one IPv4 interface. If it has to serve multiple interfaces, different client ID MUST be used to identify different interfaces" Agree? Now my concern is whether we should put the texts into the draft. If we put it there, we add a guidence on this specific issue; if not, we keep the draft clean. //=A0For the other guys, to eliminate the confusion, in typical scenario the IPv4 interfaces we talking about would be tunnel interfaces. From Francis.Dupont@fdupont.fr Wed Apr 11 15:18:07 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D381F11E80D9 for ; Wed, 11 Apr 2012 15:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-Y4vmWeYSrP for ; Wed, 11 Apr 2012 15:18:07 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id F0ED811E8073 for ; Wed, 11 Apr 2012 15:18:06 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3BMI4e4085852; Thu, 12 Apr 2012 00:18:04 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204112218.q3BMI4e4085852@givry.fdupont.fr> From: Francis Dupont To: Peng Wu In-reply-to: Your message of Wed, 11 Apr 2012 23:22:12 +0800. Date: Thu, 12 Apr 2012 00:18:04 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "dhcwg@ietf.org" , Dmitry Anipko Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 22:18:07 -0000 In your previous mail you wrote: > Francis's proposal is one option. The CRA per-interface is reasonable. > I see RFC6334 made some similar assumption. => any RFC about a client function makes this assumption. > Another proposal(by Ted) is to use client ID options for different interfaces. => usually it is not require as different interfaces should have different MAC addresses (yes, I know it is not universally true, so the "usually"). > This way DHCP mssages for different interfaces can be identified. > The cost is that we may need a little intellegence in the client. > > So if we *have to* put some text on this subject in the draft, we > could go simply like: > "A CRA SHOULD serve only one IPv4 interface. If it has to serve > multiple interfaces, different client ID MUST be used to identify > different interfaces" > Agree? => I disagree because the text is partly about CRA and partly about client, so the clarification is very confusing. > Now my concern is whether we should put the texts into the draft. > If we put it there, we add a guidence on this specific issue; if not, > we keep the draft clean. => IMHO a remark about the fact a CRA process can serve only one interface is enough. > //0For the other guys, to eliminate the confusion, in typical scenario > the IPv4 interfaces we talking about would be tunnel interfaces. => anyway the idea to use DHCP to configure directly virtual (vs physical) interfaces is BAD (and doesn't work, so please don't try to fix it :-). Regards Francis.Dupont@fdupont.fr PS: I put DHCP because DHCPv6 is only marginally better (less worse if you prefer). From pengwu.thu@gmail.com Thu Apr 12 01:17:09 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D217321F8495 for ; Thu, 12 Apr 2012 01:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTnqdoPKxavC for ; Thu, 12 Apr 2012 01:17:09 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA1521F8464 for ; Thu, 12 Apr 2012 01:17:09 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so181381pbb.31 for ; Thu, 12 Apr 2012 01:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QRuNQ8LRBWh7t/ObBFkbzZumDPix8WHSEZw6fbsAxBQ=; b=Lrr6rkI5YDfgOIHvahwzxTL8G6KAbnbUPFt+ub3OW0HJlCvgKip7hGHGKfcJY1WR41 3dZ4pOowa36t7w615cUvpsb1s2CNeeAvWj3SYObrVG/SR9X9ik5tNPUOCvFqcDYOwXHG s/8J0fxBnxuvTDdJuPrX5TmkO7vsw8oxDSx0fPhFwWZga5IaptUUd2f3T7DHoKklFeW4 fGssBnkUq8ky6T4zKnD3bg2DgRXHeryFtoeL3hGqq2ntFK4HT+nGoVMWbH2vBUGYH8ZV gc7K/4enJS0O+X0uO22UJ3B0zb4CkfCP4SKa4k2ISlrzfBE1nvWV222jLarWyRptDdcE Qgaw== MIME-Version: 1.0 Received: by 10.68.228.168 with SMTP id sj8mr1349679pbc.25.1334218628978; Thu, 12 Apr 2012 01:17:08 -0700 (PDT) Received: by 10.68.21.103 with HTTP; Thu, 12 Apr 2012 01:17:08 -0700 (PDT) In-Reply-To: <201204112218.q3BMI4e4085852@givry.fdupont.fr> References: <201204112218.q3BMI4e4085852@givry.fdupont.fr> Date: Thu, 12 Apr 2012 16:17:08 +0800 Message-ID: From: Peng Wu To: Francis Dupont Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org" , Dmitry Anipko Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 08:17:09 -0000 Francis, >> =A0Another proposal(by Ted) is to use client ID options for different in= terfaces. > > =3D> usually it is not require as different interfaces should have differ= ent MAC > addresses (yes, I know it is not universally true, so the "usually"). That's the exact reason we write it down in the draft, right? And it's easy to satisfy, considering the requirement we address. >> =A0So if we *have to* put some text on this subject in the draft, we >> =A0could go simply like: >> =A0 "A CRA SHOULD serve only one IPv4 interface. If it has to serve >> =A0multiple interfaces, different client ID MUST be used to identify >> =A0different interfaces" >> =A0Agree? > =3D> I disagree because the text is partly about CRA and partly about cli= ent, > so the clarification is very confusing. I can make it more precise, I was just proposing the general idea. How about "A CRA SHOULD serve only one IPv4 interface. If it has to serve multiple interfaces, DHCP client(s) MUST use different client ID for different interfaces, to distinguish DHCP messages from the CRA" > =3D> anyway the idea to use DHCP to configure directly virtual (vs physic= al) interfaces > is BAD (and doesn't work, so please don't try to fix it :-). I may have caused some confusion because of the other offline mail I sent to you. We don't have the assumption of multiple DHCP clients on multiple VIFs here. In fact we'd better not touch this in the draft, aka leave it open. From jiangsheng@huawei.com Thu Apr 12 02:20:59 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FF521F8685 for ; Thu, 12 Apr 2012 02:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND4PxK5n-wIF for ; Thu, 12 Apr 2012 02:20:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCE321F867F for ; Thu, 12 Apr 2012 02:20:57 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEV80948; Thu, 12 Apr 2012 05:20:57 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Apr 2012 02:18:17 -0700 Received: from SZXEML425-HUB.china.huawei.com (10.72.61.33) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Apr 2012 02:18:22 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.67]) by szxeml425-hub.china.huawei.com ([10.72.61.33]) with mapi id 14.01.0323.003; Thu, 12 Apr 2012 17:18:15 +0800 From: Sheng Jiang To: Ted Lemon , "john_brzozowski@cable.comcast.com" , dhc WG Thread-Topic: Adopt draft-jiang-dhc-addr-registration as WG document Thread-Index: Ac0YjS+ii/7zMWaDRk+2MW3tB81cAg== Date: Thu, 12 Apr 2012 09:18:14 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921E487831@SZXEML506-MBS.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [dhcwg] Adopt draft-jiang-dhc-addr-registration as WG document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 09:20:59 -0000 At the Paris IETF-83 DHC WG meeting, we present this draft. There was a lot= of support for (and no opposition) adopting this as a DHC WG document. I kindly request that we adopt this document as a DHC WG document. Best regards, Sheng Jiang From Francis.Dupont@fdupont.fr Thu Apr 12 04:32:49 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E58521F85E1 for ; Thu, 12 Apr 2012 04:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvSh0wsx7gHa for ; Thu, 12 Apr 2012 04:32:49 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 90C9321F84C4 for ; Thu, 12 Apr 2012 04:32:48 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3CBWkb4034269; Thu, 12 Apr 2012 13:32:46 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204121132.q3CBWkb4034269@givry.fdupont.fr> From: Francis Dupont To: Peng Wu In-reply-to: Your message of Thu, 12 Apr 2012 16:17:08 +0800. Date: Thu, 12 Apr 2012 13:32:46 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "dhcwg@ietf.org" , Dmitry Anipko Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 11:32:49 -0000 In your previous mail you wrote: > > => usually it is not required as different interfaces should have > > different MAC addresses (yes, I know it is not universally true, > > so the "usually"). > > That's the exact reason we write it down in the draft, right? => I can't see the reason: IMHO it is just over specified and out of scope. > And it's easy to satisfy, considering the requirement we address. => this is not the question. > > => I disagree because the text is partly about CRA and partly > > about client, so the clarification is very confusing. > > I can make it more precise, I was just proposing the general idea. > How about "A CRA SHOULD serve only one IPv4 interface. If it has to > serve multiple interfaces, DHCP client(s) MUST use different client ID > for different interfaces, to distinguish DHCP messages from the CRA" => worse: the MUST is both bogus (as I explained before) and out of scope (because it is about the client). IMHO if you want to keep something it should be: "A CRA serves only one interface." no SHOULD because it is a fact, no IPv4 because an interface is not a network layer only object. But if the definition of a CRA/LCRA is accurate this should be a direct consequence of the definition. So I suggest to reread the definition and to improve it if needed. And please note the client ID doesn't help: the CRA has still no way to know where is the client without keeping state, so I think this solution is just a variant of making the CRA more complex: I'd like to see it rejected. (and I don't understand why we are discussing about this: you are losing my time). Regards Francis.Dupont@fdupont.fr From Ted.Lemon@nominum.com Thu Apr 12 05:53:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387FA21F867C for ; Thu, 12 Apr 2012 05:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.463 X-Spam-Level: X-Spam-Status: No, score=-106.463 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipKhrszqA-d2 for ; Thu, 12 Apr 2012 05:53:00 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4D921F867B for ; Thu, 12 Apr 2012 05:52:59 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT4bQK23JY6LELRl8TNCIK3W++ypQK0x5@postini.com; Thu, 12 Apr 2012 05:53:00 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3BA691B833A for ; Thu, 12 Apr 2012 05:52:59 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2BECA190071; Thu, 12 Apr 2012 05:52:59 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 12 Apr 2012 05:52:53 -0700 From: Ted Lemon To: Francis Dupont Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces Thread-Index: AQHNGJ/7E6a1w+FwSKK6eT929Ok/5paXmm+A Date: Thu, 12 Apr 2012 12:52:52 +0000 Message-ID: References: <201204121132.q3CBWkb4034269@givry.fdupont.fr> In-Reply-To: <201204121132.q3CBWkb4034269@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_DB239EE5FB464233BF00ADC6D0FC8EB7nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Dmitry Anipko Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 12:53:01 -0000 --_000_DB239EE5FB464233BF00ADC6D0FC8EB7nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 12, 2012, at 7:32 AM, Francis Dupont > wrote: the CRA has still no way to know where is the client without keeping state Not so--it just broadcasts. Every client hears the response, one client s= elects it. --_000_DB239EE5FB464233BF00ADC6D0FC8EB7nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
    On Apr 12, 2012, at 7:32 AM, Francis Dupont <Francis.Dupont@fdupont.fr> wrote:
    the CRA has still
    no way to know where is the client without keeping state

    Not so--it just broadcasts.   Every client hears the response, on= e client selects it.

    --_000_DB239EE5FB464233BF00ADC6D0FC8EB7nominumcom_-- From Francis.Dupont@fdupont.fr Fri Apr 13 01:52:25 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D1B21F847B for ; Fri, 13 Apr 2012 01:52:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLzaWZZ2ib-r for ; Fri, 13 Apr 2012 01:52:24 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 2C22021F846F for ; Fri, 13 Apr 2012 01:52:23 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3D8qK4x011989; Fri, 13 Apr 2012 10:52:20 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204130852.q3D8qK4x011989@givry.fdupont.fr> From: Francis Dupont To: Ted Lemon In-reply-to: Your message of Thu, 12 Apr 2012 12:52:52 -0000. Date: Fri, 13 Apr 2012 10:52:20 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "dhcwg@ietf.org" , Dmitry Anipko Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 08:52:25 -0000 In your previous mail you wrote: > the CRA has still no way to know where is the client without keeping > state > Not so--it just broadcasts. => on which link? > Every client hears the response, one client selects it. => this works only when the CRA (LCRA) serves only one link, so today we have only two modes: CRA aka co-located, LCRA aka on link, but nothing for the multi-interface served by one CRA instance. (but it is not a problem as it can be handled by one instance per link so for me this issue is solved/closed). Thanks Francis.Dupont@fdupont.fr From laurent.thiebaut@alcatel-lucent.com Fri Apr 13 03:05:19 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92B021F867E for ; Fri, 13 Apr 2012 03:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.648 X-Spam-Level: X-Spam-Status: No, score=-7.648 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp1DAQq6QIp7 for ; Fri, 13 Apr 2012 03:05:15 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 71B0121F8669 for ; Fri, 13 Apr 2012 03:05:14 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3DA4HBF011762 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Apr 2012 12:05:09 +0200 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.37]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 13 Apr 2012 12:04:55 +0200 From: "THIEBAUT, LAURENT (LAURENT)" To: shwethab , "dhcwg@ietf.org" Date: Fri, 13 Apr 2012 12:04:54 +0200 Thread-Topic: Comments on draft-bhandari-dhc-class-based-prefix Thread-Index: Ac0TKg5fU1U46I++QVmuEChI3Dn6DwEVbbMnAHc+9UA= Message-ID: <170E8FCC2134BD42B539B47798ABF8F0133C1FAE48@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> References: <170E8FCC2134BD42B539B47798ABF8F0133B2C8BBD@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_170E8FCC2134BD42B539B47798ABF8F0133C1FAE48FRMRSSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: Sri Gundavelli Subject: Re: [dhcwg] Comments on draft-bhandari-dhc-class-based-prefix X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 10:05:19 -0000 --_000_170E8FCC2134BD42B539B47798ABF8F0133C1FAE48FRMRSSXCHMBSA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Shwetha If you want I can provide you with a written proposal for the modificatio o= f your draft. Best regards Laurent ALCATEL-LUCENT ________________________________ De : shwethab [mailto:shwethab@cisco.com] Envoy=E9 : mercredi 11 avril 2012 03:10 =C0 : THIEBAUT, LAURENT (LAURENT); dhcwg@ietf.org Cc : Sri Gundavelli Objet : Re: Comments on draft-bhandari-dhc-class-based-prefix Hello Laurent, Thanks for the comments. I agree that we need structure to Prefix class option - we could have a a t= ype and value within its content. Type would indicate whether its IETF defi= ned class or Vendor. Based on the type value can then be interpreted, may b= e from a IANA defined name space if it is IETF. I will rework on the struct= ure of the option and update the draft. Regarding including this option in Information request message: if the sema= ntics and content of configuration-information-class option would be same a= s Prefix class, we can rename the Prefix class option suitably or let the s= ame option be used to request configuration from a specific class in inform= ation request as well. Thanks, Shwetha On 4/5/12 6:16 PM, "THIEBAUT, LAURENT (LAURENT)" wrote: Hello Shwetha, hello all As a follow up of the discussion we have had in Paris, please a few comment= s on this very interesting ID 1. As opposed to the "OPTION_USER_CLASS" whose semantics is undefined a= nd whose impact to the system is loosely defined, the new "PREFIX_CLASS opt= ion" allows a well defined structure to ensure inter-operability beyond a c= orporate proprietary usage, i.e. to make sure that different organisations = cannot allocate the same value for the "PREFIX_CLASS option". Indeed the de= finition and structure and indication of usage of the "User Class Option" i= s too loose to guarantee inter-operability beyond a corporate deployment 22.15. User Class Option The User Class option is used by a client to identify the type or category = of user or applications it represents. ... The information contained in the data area of this option is contained in o= ne or more *opaque* fields that represent the user class or classes of whic= h the client is a member. A server selects configuration information for t= he client based on the classes identified in this option. For example, the= User Class option can be used to configure all clients of people in the ac= counting department with a different printer than clients of people in the = marketing department. The user class information carried in this option MUS= T be configurable on the client. ...... (The "User Class Option" can't be used in a non proprietary context as diff= erent organisations can by accident allocate the same value to this informa= tion) This comment is an =AB endorsement" of draft-bhandari-dhc-class-based-prefi= x 2. The "PREFIX_CLASS option" should allow to specify * Prefix-classes defined by IETF * Prefix classes defined by other standard fora * (proprietary) Prefix classes defined by a corporate 3. The proposed structure would be as follows * "Prefix class name space" with 2 values: "IETF" / "other organisation" * "Prefix class owner" (required in case the "Prefix class name space" i= s "other organisation", not present when "Prefix class name space" is "IETF= "). Other organisation may be another standard forum (e.g. BBF) or a corpor= ate. * "Prefix class value" whose structure depends on the "Prefix class name= space" and "Prefix class owner" 4. As the "User Class Option" does not benefit from such structure it c= annot be used beyond a corporate proprietary usage. Thus the "User Class Op= tion" cannot provide an interoperable parameter to be used when a DHCP clie= nt sends an Information-Request message to obtain (IP) configuration inform= ation. Following alternatives may be envisaged: a) Either the "PREFIX_CLASS option" is used in Information-Request. It = is agreed that the name "PREFIX_CLASS option" would then not be well suited= for usage in Information-Request and that thus the name of this option sho= uld be changed. b) Another possibility is to define a "configuration-information-class = option" whose semantics is explicitly made the same as the "PREFIX_CLASS op= tion" and to be used as follows: o The DHCP client puts a "configuration-information-class option"in = Information-Request to request that the IP parameters values sent by the DH= CP server are determined as the most suitable for the IP service associated= with the "configuration-information-class option" o when a DHCPv6 client sends a SOLICIT message to request both * for IA_NA address allocation from a specific prefix class * and to obtain (IP) configuration information using Option Request = option (per RFC 3315 section 22.7) it populates the SOLICIT message as follows: * within the IA_NA option, it includes the OPTION_PREFIX_CLASS reque= sting address to be allocated from a specific prefix class indicated in tha= t option * within the Option Request option (per RFC 3315 section 22.7) it in= cludes the "configuration-information-class option" requesting configuratio= n parameters sent by the DHCP server are determined as the most suitable fo= r the IP service associated with the "configuration-information-class optio= n". If these comments are felt useful, I can provide actual text for the draft. Best regards Laurent --_000_170E8FCC2134BD42B539B47798ABF8F0133C1FAE48FRMRSSXCHMBSA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Comments on draft-bhandari-dhc-class-based-prefix

     

     

    Hello Shwetha<= /span>

    If you want I can provide you with a written proposal for the modificatio of your draft.

    Best regards

    Laurent
    ALCATEL-LUCENT

    De : shwethab [mailto:shwethab@cisco.com]
    Envoy=E9 : mercredi 11 = avril 2012 03:10
    =C0 : THIEBAUT, LAURENT (LAURENT); dhcwg@ietf.org
    Cc : Sri Gundavelli
    Objet : Re: Comments on draft-bhandari-dhc-class-based-prefix

     

    Hello Laurent,

    Thanks for the comments.

    I agree that we need structure to Prefix class option – we could have= a a type and value within its content. Type would indicate whether its IETF defined class or Vendor. Based on the type value can then be interpreted, may be fr= om a IANA defined name space if it is IETF. I will rework on the structure of th= e  option and update the draft.

    Regarding including this option in Information request message:     if the semantics and content of= configuration-information-class option would= be same as Prefix class, we can rename the Prefix class option suitably or let the = same option be used to request configuration from a specific class in informatio= n request as well.

    Thanks,
    Shwetha


    On 4/5/12 6:16 PM, "THIEBAUT, LAURENT (LAURENT)" <laurent.thiebaut@alcatel-lucen= t.com> wrote:


     
    Hello Sh= wetha, hello all
    As a follow up of the discussion we have had in Paris, please a few comment= s on this very interesting ID
    1.         As opposed to the “OPTION_USER_CLASS” whose semantics is undefin= ed and whose impact to the system is loosely defined, the new “PREFIX_CLASS option” allows a= well defined structure to ensure inter-operability beyond a corporate proprietar= y usage, i.e. to make sure that different organisations cannot allocate the s= ame value for the “PREFIX_CLASS option”. Indeed the definition and structure and indication of usage of the “User Class Option” is too loose to guarantee inter-operability beyond a corporate deployment
    22.15. User Class Option
    The User Class option is used by a client to identify the type or category = of user or applications it represents.
    …
     
    The information contained in the data area of this option is contained in o= ne or more *opaque* fields that represent the user class or classes of which the client is a member.  = A server selects configuration information for the client based on the classe= s identified in this option.  For example, the User Class option can be = used to configure all clients of people in the accounting department with a different printer than clients of people in the marketing department. The u= ser class information carried in this option MUST be configurable on the client= .
       ……
    (The = 220;User Class Option” can’t be used in a non proprietary context as dif= ferent organisations can by accident allocate the same value to this information)<= br> This comment is an =AB endorsement” of draft-bhandari-dhc-class-based= -prefix
     
    2.         The “PREFIX_CLASS option” should allow to specify

    • Pre= fix-classes defined by IETF
    • Pre= fix classes defined by other standard fora <= /span>
    • (pr= oprietary) Prefix classes defined by a corporate


     
    3.         The proposed structure would be as follows=

    • = 220;Prefix class name space” with 2 values: “IETF” / “oth= er organisation”
    • = 220;Prefix class owner” (required in case the “Prefix class name spac= e” is “other organisation”, not present when “Prefix class name space&#= 8221; is “IETF”). Other organisation may be another standard forum (e.g. BBF) or a corporate.
    • = 220;Prefix class value” whose structure depends on the “Prefix class = name space” and “Prefix class owner”


     
    4.         As the “User Class Option” does not benefit from such= structure it cannot be used beyond a corporate proprietary usage. Thus the “User Class Option” = cannot provide an interoperable parameter to be used when a DHCP client sends an Information-Request message to obtain (IP) configuration information. Following alternatives may be envisaged:
    a)         Either the “PREFIX_CLASS option” is used in Information-Req= uest. It is agreed that the name “= PREFIX_CLASS option” would then not be well sui= ted for usage in Information-Request and that thus the name of this option should b= e changed.
    b)         Another possibility is to define a “= configuration-information-class option” whose semantics is explicitly made= the same as the “PREFIX_CLASS option” and to be used as follows:
    o<= /font>       The DHCP client  puts a “= configuration-information-class option”in Information-Request to request = that the IP parameters values sent by the DHCP server are determined as the most suitable for the IP service associated with the “= configuration-information-class option”
    o<= /font>       when a DHCPv6 client sends a SOLICIT message to request both<= br> =B7        for IA_NA address allocation from a specific p= refix class
    =B7        and to obtain (IP) configuration information u= sing Option Request option (per RFC 3315 section 22.7)
    it populates the SOLICIT message as follows:
    =B7        within the IA_NA option, it includes the OPTION_PREFIX_CLASS requesting address to be allocated from a specific pref= ix class indicated in that option
    =B7        within the Option Request option (per RFC 3315 section 22.7) it includes the <= span style=3D'font-size:11.0pt;font-family:Calibri'>“configuration-information-class option” requesting configuration parameter= s sent by the DHCP server are determined as the most suitable for the IP serv= ice associated with the “configuration-information-class option”.

    If these comments are felt useful, I can provide actual text for the draft.=
    Best regards

    Laurent


     

    --_000_170E8FCC2134BD42B539B47798ABF8F0133C1FAE48FRMRSSXCHMBSA_-- From volz@cisco.com Fri Apr 13 20:38:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA2A21F863D for ; Fri, 13 Apr 2012 20:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.715 X-Spam-Level: X-Spam-Status: No, score=-10.715 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a3-fLNUvcCl for ; Fri, 13 Apr 2012 20:38:30 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5AF21F863C for ; Fri, 13 Apr 2012 20:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=7779; q=dns/txt; s=iport; t=1334374710; x=1335584310; h=mime-version:subject:date:message-id:from:to:cc; bh=Splt3OrIstuPr7jcZZB5mEauvjjoOLGSuT5cVyK9Qd4=; b=h7vOPxyPUEUwkRAat9mYR2LSxJmDanDlRoh6n/O3rTYOue11C1w5/m0+ /AJHJB/iW/7xnBpNjFppcov+gl+Qh/6P97jG3kSugXsR9/BEAnsor+N78 kZwrc75+6ksi8jQi4XFvc5kC/WpIGRLG6AP9vfA1gbCDLFSRl55Pke93u Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIPwiE+tJV2d/2dsb2JhbABFgkayQ4EHggkBAQEEEgEJARADSRIBCBEEAQELBhcBByAlCQoEARIIGodeAwuZLJYUDYlTijeGL2MEiFqYS4MUgWmDBQ X-IronPort-AV: E=Sophos;i="4.75,420,1330905600"; d="scan'208,217";a="74655136" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 14 Apr 2012 03:38:30 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q3E3cUfP022276; Sat, 14 Apr 2012 03:38:30 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Apr 2012 22:38:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD19F0.0EB5C5FB" Date: Fri, 13 Apr 2012 22:38:28 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Requesting adoption ofdraft-mrugalski-dhc-dhcpv6-failover-design-01 Thread-Index: AQHNFdUOdLCpCRiXV0yWYUk8x9pa75aUkgMAgAUiXQA= From: "Bernie Volz (volz)" To: "Ted Lemon" , "Tomek Mrugalski" X-OriginalArrivalTime: 14 Apr 2012 03:38:29.0615 (UTC) FILETIME=[0EE1FFF0:01CD19F0] Cc: DHC WG Subject: Re: [dhcwg] Requesting adoptionof draft-mrugalski-dhc-dhcpv6-failover-design-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 03:38:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD19F0.0EB5C5FB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adoption of this document. =20 From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Tuesday, April 10, 2012 10:14 AM To: Tomek Mrugalski Cc: DHC WG Subject: Re: [dhcwg] Requesting adoptionof draft-mrugalski-dhc-dhcpv6-failover-design-01 =20 On Apr 8, 2012, at 6:14 PM, Tomek Mrugalski wrote: I kindly request that we adopt this document as a DHC WG work item. =20 Please consider Tomek's request an official call for adoption. If you are in favor of adopting this as a working group work item, please say so. If you are against, please say so. =20 We will evaluate consensus to adopt this draft as a working group work item on April 24. =20 =20 ------_=_NextPart_001_01CD19F0.0EB5C5FB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I support adoption of this document.

     

    From:= = dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Ted Lemon
    Sent: Tuesday, April 10, 2012 10:14 = AM
    To: Tomek Mrugalski
    Cc: DHC WG
    Subject: = Re: [dhcwg] Requesting adoptionof = draft-mrugalski-dhc-dhcpv6-failover-design-01

    =

     

    On Apr 8, 2012, at 6:14 PM, Tomek Mrugalski <tomasz.mrugalski@gmail.com= > wrote:

    I kindly request that we adopt this document as a DHC WG work = item.

     

    Please consider Tomek's request an official call for = adoption.    If you are in favor of adopting this as a working = group work item, please say so.   If you are against, please say = so.

     

    We will evaluate consensus to adopt this draft as a = working group work item on April 24.  

     

    ------_=_NextPart_001_01CD19F0.0EB5C5FB-- From pengwu.thu@gmail.com Sat Apr 14 00:24:05 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBEF21F8546 for ; Sat, 14 Apr 2012 00:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JT6h-eF+6rt9 for ; Sat, 14 Apr 2012 00:24:04 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E38221F853F for ; Sat, 14 Apr 2012 00:24:04 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2476161pbb.31 for ; Sat, 14 Apr 2012 00:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hLJFKEYLMUdX1F+Keuo2xjOYv3S9dVBzoCPWuWG7/r4=; b=HSoVJPStQ1ciByLpLiLXMvDMp1Zc0TT1VK5C3wMJ26ZHUWEjanu9JfHto3IzyVnQaG aQYQRDTd/WO3h1xdrWZQGPGgjU0zBTacvwBR1h23RHYpBXtuXMj/Wm4SKuFtXkNAqlgk hYrowniNc1MeD1MYeVKJxLCT8w6FQ0BHtjZv5wQXgEn4PUuYE/g/zgBp9238tgyGcA3x +qsfaVh667jm+EmGHdF7oTdsEjtcKbxMHjkfSGl9EppxA7EeCoJLWMWCNQ6e75x3K1in qjoJPxoeMzfKW8qb2eGmXBTZ+c0wW7x1Z17J3vCiL+dGvpSmN/IsHJMfGT34BHlcWS5d tvIg== MIME-Version: 1.0 Received: by 10.68.136.162 with SMTP id qb2mr10845757pbb.67.1334388244011; Sat, 14 Apr 2012 00:24:04 -0700 (PDT) Received: by 10.68.21.103 with HTTP; Sat, 14 Apr 2012 00:24:03 -0700 (PDT) In-Reply-To: <201204130852.q3D8qK4x011989@givry.fdupont.fr> References: <201204130852.q3D8qK4x011989@givry.fdupont.fr> Date: Sat, 14 Apr 2012 15:24:03 +0800 Message-ID: From: Peng Wu To: Francis Dupont Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org" , Ted Lemon , Dmitry Anipko Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 07:24:05 -0000 Francis, Francis, I was going to make my cocern on this clear, but seems we still have confusion. Let' settle this first. One CRA per-link is fine. I think we all agree. We're talking about the case where there is ONLY ONE link, but multiple tunnel endpoints on the host, relying on the SAME link as well as the SAME CRA. It's still per-link CRA (BTW, LCRA is not currently discussed). I know from Softwire perspective, this multiple tunnel on same link might seem no use cas. But the draft is a pure DHC document now so we'd better be very rigorous. Theoretically that could happen. 2012/4/13 Francis Dupont : > =A0In your previous mail you wrote: > >> the CRA has still no way to know where is the client without keeping >> =A0state > >> =A0Not so--it just broadcasts. > > =3D> on which link? > >> =A0Every client hears the response, one client selects it. > > =3D> this works only when the CRA (LCRA) serves only one link, > so today we have only two modes: CRA aka co-located, LCRA aka on link, > but nothing for the multi-interface served by one CRA instance. > (but it is not a problem as it can be handled by one instance per link > so for me this issue is solved/closed). > > Thanks > > Francis.Dupont@fdupont.fr From Ted.Lemon@nominum.com Sat Apr 14 05:55:08 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AAB21F84DD for ; Sat, 14 Apr 2012 05:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.472 X-Spam-Level: X-Spam-Status: No, score=-106.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYsES3yTBTAw for ; Sat, 14 Apr 2012 05:55:07 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3190B21F84B9 for ; Sat, 14 Apr 2012 05:55:07 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKT4lzqoyWJDWnIoaIgsJTDS7C8DYXupck@postini.com; Sat, 14 Apr 2012 05:55:07 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2A1681B8350 for ; Sat, 14 Apr 2012 05:55:06 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1CFC619006C for ; Sat, 14 Apr 2012 05:55:06 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Sat, 14 Apr 2012 05:54:59 -0700 From: Ted Lemon To: DHC WG Thread-Topic: WGLC: draft-ietf-dhc-client-id-02 Thread-Index: AQHNGj3M8A+q0iwf8kCif1zWgGUm5g== Date: Sat, 14 Apr 2012 12:54:58 +0000 Message-ID: <64B00097-8ACB-4170-9303-8F863A47C2B5@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 12:55:08 -0000 This document corrects a bug in RFC2131 that forbids the DHCP server from r= eturning a DHCP client identifier. The lack of a DHCP client identifier c= reates a problem in two cases: where the underlying transport has no link-l= ayer address, and where two clients are running on the same host, supplying= different client identifiers so as to present different network identities= . In both of these cases, insufficient information is returned from the D= HCP server to clearly identify the client that is the intended recipient of= the message. The only way to fix this is to _require_ the DHCP server to= return the client identifier if it receives it. This is what the propose= d document does. We checked for consensus in the meeting, and four people were in favor of a= dvancing the draft; nobody was against. I think this is actually pretty important work=97it's a lingering bug in th= e spec which I think will come back to bite us more and more as we start ge= tting deeper into the dual-stack transition. So if you haven't read the d= ocument, please do.=20 If you support advancing it, please signify by replying to this message and= saying that you support it. If you think it's a bad idea, please signify b= y replying to this message and explaining why. If you have comments or ch= anges to propose, please send them along, and also signify whether you are = in favor of advancement with the change, without the change, or oppose adva= ncement. We will determine consensus on April 27, based solely on responses on the m= ailing list, so please do respond. Thanks! From Francis.Dupont@fdupont.fr Sat Apr 14 13:10:56 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A5521F863F for ; Sat, 14 Apr 2012 13:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 025-ksPkVHiQ for ; Sat, 14 Apr 2012 13:10:56 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id D215521F863E for ; Sat, 14 Apr 2012 13:10:55 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3EKAqwH044161; Sat, 14 Apr 2012 22:10:52 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204142010.q3EKAqwH044161@givry.fdupont.fr> From: Francis Dupont To: Peng Wu In-reply-to: Your message of Sat, 14 Apr 2012 15:24:03 +0800. Date: Sat, 14 Apr 2012 22:10:52 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "dhcwg@ietf.org" , Ted Lemon , Dmitry Anipko Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 20:10:56 -0000 In your previous mail you wrote: > I was going to make my cocern on this clear, but seems we still have > confusion. Let' settle this first. > > One CRA per-link is fine. I think we all agree. > We're talking about the case where there is ONLY ONE link, but > multiple tunnel endpoints on the host, => I am confused: either the tunnels are links (it is a bad idea IMHO but it is not a priori impossible), or they are not links and they don't exist for DHCP. > relying on the SAME link as > well as the SAME CRA. It's still per-link CRA (BTW, LCRA is not > currently discussed). => you are clearly in the one link case so I can't see a problem. > I know from Softwire perspective, this multiple tunnel on same link => multiple tunnel on same link has no meaning, in particular with DHCP which is defined for physical interfaces (so links). > might seem no use cas. But the draft is a pure DHC document now so > we'd better be very rigorous. Theoretically that could happen. => multiple interface is possible but it means more than one link. IMHO the confusion comes from the bad idea to use DHCP to assign addresses to virtual interfaces like tunnels. If you use DHCP only for physical interfaces, it could work even with the DHCPv4 over IPv6 transport variant. Thanks Francis.Dupont@fdupont.fr PS: I reread the last version and I have some comments about it. From Ted.Lemon@nominum.com Sat Apr 14 15:53:09 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D44D21F85A8 for ; Sat, 14 Apr 2012 15:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.478 X-Spam-Level: X-Spam-Status: No, score=-106.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwmAwAR8Uk9K for ; Sat, 14 Apr 2012 15:53:08 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 46B8321F8551 for ; Sat, 14 Apr 2012 15:53:08 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKT4n/0wSUG31j9NUX2asa9BismJIdr037@postini.com; Sat, 14 Apr 2012 15:53:08 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 216CF1B835D for ; Sat, 14 Apr 2012 15:53:07 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1377619006C; Sat, 14 Apr 2012 15:53:07 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Sat, 14 Apr 2012 15:53:07 -0700 From: Ted Lemon To: Francis Dupont Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces Thread-Index: AQHNGnqwATEkr4Y99kO4fhiXxhzO0pabYxkA Date: Sat, 14 Apr 2012 22:53:06 +0000 Message-ID: References: <201204142010.q3EKAqwH044161@givry.fdupont.fr> In-Reply-To: <201204142010.q3EKAqwH044161@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_F3FC525FC3C443BBAAFDB2F68376062Bnominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Dmitry Anipko Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 22:53:09 -0000 --_000_F3FC525FC3C443BBAAFDB2F68376062Bnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 14, 2012, at 4:10 PM, Francis Dupont > wrote: I am confused: either the tunnels are links (it is a bad idea IMHO but it is not a priori impossible), or they are not links and they don't exist for DHCP. That is not the use case for this draft. The use case for this draft is t= hat a client wants IPv4 support on an IPv6-only network, and so it uses DHC= P to get an address for the tunnel endpoint. It does this by broadcasting= a DHCPv4 request on the local interface, which the CRA captures and forwar= ds to the DHCPv4 server over IPv6. Once the tunnel is established, renewa= ls are (one assumes) routed down the tunnel. But the idea, as I understan= d it at least, is to leverage the existing DHCPv4 client, not to require a = special DHCPv4 client. If we require a special DHCPv4 client, we might as= well just do all the DHCPv4 transactions over UDPv6. --_000_F3FC525FC3C443BBAAFDB2F68376062Bnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <93C6B0D5D7CAA84AB8A65941DBCDC696@nominum.com> Content-Transfer-Encoding: quoted-printable
    On Apr 14, 2012, at 4:10 PM, Francis Dupont <Francis.Dupont@fdupont.fr> wrote:
    I am confused: either the tunnels are links (it is a bad idea IMHO but it is not a priori impossible), or they are not links and they
    don't exist for DHCP.

    That is not the use case for this draft.   The use case for this = draft is that a client wants IPv4 support on an IPv6-only network, and so i= t uses DHCP to get an address for the tunnel endpoint.   It does this = by broadcasting a DHCPv4 request on the local interface, which the CRA captures and forwards to the DHCPv4 server over I= Pv6.   Once the tunnel is established, renewals are (one assumes) rout= ed down the tunnel.   But the idea, as I understand it at least, is to= leverage the existing DHCPv4 client, not to require a special DHCPv4 client.   If we require a special DHCPv4 = client, we might as well just do all the DHCPv4 transactions over UDPv6.

    --_000_F3FC525FC3C443BBAAFDB2F68376062Bnominumcom_-- From Francis.Dupont@fdupont.fr Sun Apr 15 03:21:26 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138BE21F8786 for ; Sun, 15 Apr 2012 03:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCl4RtRtiJgV for ; Sun, 15 Apr 2012 03:21:25 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 2F47921F8705 for ; Sun, 15 Apr 2012 03:21:24 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3FALMOi095862; Sun, 15 Apr 2012 12:21:22 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204151021.q3FALMOi095862@givry.fdupont.fr> From: Francis Dupont To: Ted Lemon In-reply-to: Your message of Sat, 14 Apr 2012 22:53:06 -0000. Date: Sun, 15 Apr 2012 12:21:22 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "dhcwg@ietf.org" , Dmitry Anipko Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 10:21:26 -0000 In your previous mail you wrote: > On Apr 14, 2012, at 4:10 PM, Francis Dupont wrote: > I am confused: either the tunnels are links (it is a bad idea IMHO > but it is not a priori impossible), or they are not links and they > don't exist for DHCP. > > That is not the use case for this draft. The use case for this > draft is that a client wants IPv4 support on an IPv6-only network, > and so it uses DHCP to get an address for the tunnel endpoint. => IMHO some of the confusion comes from this term "tunnel endpoint": it is both the node at this end of the tunnel and the virtual interface of the tunnel. > It does this by broadcasting a DHCPv4 request on the local > interface, which the CRA captures and forwards to the DHCPv4 server > over IPv6. => this is the first interpretation and the local interface is the physical interface used by the tunnel endpoint node to send encapsulated packets to the tunnel other end. > Once the tunnel is established, renewals are (one assumes) routed > down the tunnel. => in fact to work well either the server has to handle both the TSV function and the regular DHCPv4 over a tunnel, or a TRA is at the tunnel other end. But this doesn't change the client/CRA so is a side comment. > But the idea, as I understand it at least, is to leverage the > existing DHCPv4 client, not to require a special DHCPv4 client. => yes, this is the idea. And I tried with two very different and unmodified clients so the idea is valid. Note it is not fully true for the server side (even the I-D says it is). > If we require a special DHCPv4 client, we might aswell just do all > the DHCPv4 transactions over UDPv6. => I agree: on the client side the DHCPv4 client is unmodified and the CRA is as simple as possible. IMHO these are critical for the target deployment, i.e., low cost CPEs. Thanks Francis.Dupont@fdupont.fr From budmillwood@gmail.com Mon Apr 16 01:53:20 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B3021F8714 for ; Mon, 16 Apr 2012 01:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgVObVSJ-Iah for ; Mon, 16 Apr 2012 01:53:19 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1819521F8690 for ; Mon, 16 Apr 2012 01:53:18 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3793338vbb.31 for ; Mon, 16 Apr 2012 01:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=H7SN17AKwoqhQo6p26bcThHHXe9s41HqxDJmEc1JCLY=; b=J/GTY6ROkgjCYMxSw8ZZKRxrMuo5ErA7BoZ8sr77P7+SSbF9fjQHGL1e0PX8kiIp4/ 2MStwnk7uogiKkS4bYhBKNDv4MeHzW24Aw6p8OkoN0l3QLyXVTyHDRWt9BustTbUvg3v uF9s7NCQwrlF6nCWF2CBNBs5xum8zQqxAO1xcI3RgrUOXQHPgA9r16WCjnRKJvn9uK8+ qnWWRtt/ByYuoyaOsgzwBPOqX4VDSqXUtivG1a0uCasJPP3N8uLkOD8A6gPj+kqcNAl4 LES1u5kwRMXF1Z+PqJHuMkCyBFKqe9ZoHN3dADoywKlvxIYDBIo3m/fORMDsuOKGV1XQ 3gZg== MIME-Version: 1.0 Received: by 10.220.140.18 with SMTP id g18mr5615474vcu.37.1334566398491; Mon, 16 Apr 2012 01:53:18 -0700 (PDT) Received: by 10.52.110.35 with HTTP; Mon, 16 Apr 2012 01:53:18 -0700 (PDT) In-Reply-To: <64B00097-8ACB-4170-9303-8F863A47C2B5@nominum.com> References: <64B00097-8ACB-4170-9303-8F863A47C2B5@nominum.com> Date: Mon, 16 Apr 2012 10:53:18 +0200 Message-ID: From: Bud Millwood To: Ted Lemon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: DHC WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 08:53:20 -0000 Hi Ted: We'll support this. My approach is going to be to make it optional, but I'm leaning towards having it disabled by default in our software. Is there any real-world analysis of how various devices will handle this change? After all, it is explicitly breaking the existing DHCP protocol. - Bud On Sat, Apr 14, 2012 at 2:54 PM, Ted Lemon wrote: > This document corrects a bug in RFC2131 that forbids the DHCP server from= returning a DHCP client identifier. =A0 The lack of a DHCP client identifi= er creates a problem in two cases: where the underlying transport has no li= nk-layer address, and where two clients are running on the same host, suppl= ying different client identifiers so as to present different network identi= ties. =A0 In both of these cases, insufficient information is returned from= the DHCP server to clearly identify the client that is the intended recipi= ent of the message. =A0 The only way to fix this is to _require_ the DHCP s= erver to return the client identifier if it receives it. =A0 This is what t= he proposed document does. > > We checked for consensus in the meeting, and four people were in favor of= advancing the draft; nobody was against. > > I think this is actually pretty important work=97it's a lingering bug in = the spec which I think will come back to bite us more and more as we start = getting deeper into the dual-stack transition. =A0 So if you haven't read t= he document, please do. > > If you support advancing it, please signify by replying to this message a= nd saying that you support it. If you think it's a bad idea, please signify= by replying to this message and explaining why. =A0 If you have comments o= r changes to propose, please send them along, and also signify whether you = are in favor of advancement with the change, without the change, or oppose = advancement. > > We will determine consensus on April 27, based solely on responses on the= mailing list, so please do respond. > > Thanks! > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From budmillwood@gmail.com Mon Apr 16 02:21:39 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E9A21F8766 for ; Mon, 16 Apr 2012 02:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoznsyU7NU4X for ; Mon, 16 Apr 2012 02:21:39 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0472E21F8758 for ; Mon, 16 Apr 2012 02:21:38 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3808399vbb.31 for ; Mon, 16 Apr 2012 02:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oTfPHV+vg4E9kvRmHBhUax2nbjDYlP54TB8zau4DT88=; b=u63X4V0zXd+3uSCZOCIQm7JFpxaYsHKFhQfU7qrQ05a/Lhsb7490EY/8dURFaKp0J6 S2j3Svi7EAI2oLAdjUzfkuIXj773JjslK/3Wb5lzlCnG+LEgASOK35w0CUYZ1200DrwJ 6NCX1YwmSONY+VoLy2WXzzz3QNF2TgMvVWOTEQV750RtMj5Zu6oJkrDLp4yH4Pxl3x0O XDWgs4N5eZNAd+fWHxnrfnRA+LbQqdIS3hjXJN6RjIMp+AQvfio7CvXlOOkGgsggRCTc y7p/Hy8BMWA/hYgDWohAR93AOxFPHDGp5za7d/aCTI4vuI4DPA+tb18xMNm0l2rbnfMr 6Spg== MIME-Version: 1.0 Received: by 10.220.140.200 with SMTP id j8mr5661858vcu.17.1334568098512; Mon, 16 Apr 2012 02:21:38 -0700 (PDT) Received: by 10.52.110.35 with HTTP; Mon, 16 Apr 2012 02:21:38 -0700 (PDT) In-Reply-To: References: <4F81BA73.4000400@gmail.com> <4F8212EC.5020706@gmail.com> Date: Mon, 16 Apr 2012 11:21:38 +0200 Message-ID: From: Bud Millwood To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Ole Troan Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 09:21:40 -0000 > Note also that I believe that the REBIND behavior as specified today is > BROKEN for failover. Consider the case Server A gives out a lease but > goes down before updating its partner, Server B. Server B now gets the > REBIND at T2. It would send back NoBinding as it has no record of the > client and/or bindings. This needs to change too for failover to work - > at least if we want to be consistent with the way we handle this in v4 > failover. RFC 3315, 18.1.8 says that if the client receives a 'NoBinding' in response to its Rebind, it should send a Request. Does anyone know the reasoning behind that? Does 'NoBinding' in DHCPv6 explicitly override an existing contract for a lease? Can the client not continue to use its lease? - Bud > I don't think the RENEW (or REBIND) is damaged by allowing new bindings. > The client is still asking to renew leases but to also get new ones. Why > is that so bad? The addresses (or prefix) can change in a > Renew/Rebinding, so why not allow new bindings? > > Note that we are NEVER saying a client can send a RENEW or REBIND > without having at least one valid lease. It must at least have one > binding & lease. > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Tomek Mrugalski > Sent: Sunday, April 08, 2012 6:36 PM > To: Bernie Volz (volz) > Cc: dhcwg@ietf.org; Ole Troan > Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as > WG item > > On 12-04-08 23:26, Bernie Volz (volz) wrote: >> Regarding 0, no. This work would be folded into 3315bis but it should >> proceed separately. Primarily because it is needed "now" and the >> 3315bis work will probably be at a much slower pace. >> ... >> This work is really related to 6204bis and the fact that the cable >> market needs the router behavior to be clarified. > Sure. In that case pick only those of my comments that you think are > useful in 6204bis context and we can get back to the other ones later > during 3315bis work. > >> back to Solicit, this allows the client the ability to RENEW the IA_PD > >> and include the IA_NA to get a new address (that hopefully won't have >> the DAD or other conflict). Note that in this RENEW, the IA_NA would >> not have an IA_ADDR option (or if it does, it would be the unspecified > >> address). > Ok, that is less scary than it initially looked. Nevertheless, I still > don't like it much. Using RENEW to request new addresses or prefixes is > wrong and will not work. It is true that to some extent REQUEST and > RENEW work in similar manner, but they were kept separated for a reason. > I would prefer to send a separate REQUEST for requesting new > allocations. > > Also, the idea to use RENEW to get new address/prefix will not work with > conformant implementations. Servers will send back IA, but with status > code set to NoBinding. Here's appropriate part of 3315, section 18.2.3: > > =A0 If the server cannot find a client entry for the IA the server > =A0 returns the IA containing no addresses with a Status Code option set > =A0 to NoBinding in the Reply message. > > So no, don't request anything new in RENEW. That's what REQUEST is for. > > Tomek > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From budmillwood@gmail.com Mon Apr 16 03:01:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A2921F8664 for ; Mon, 16 Apr 2012 03:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfVUH3aEIIs3 for ; Mon, 16 Apr 2012 03:01:09 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A66A21F8658 for ; Mon, 16 Apr 2012 03:01:09 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so3848943vcb.31 for ; Mon, 16 Apr 2012 03:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/RAm9en87HS7PoePALKnOqzlSuGI9SmER+zEnxoe88Q=; b=pMuqcoenb3gpPS8gsOkeESNgPGoRJndPyYn1HMP1b9m5/QlWlpQ4UCdyNcEa5Fs4J0 STddk7+P9YBcAuZ/Mn0WobvnfkjLVplk4DJEI0BvU675zPz830n/zzvkeU/Pg6dhwCox uXatVBqLUvy/BPDPbWIu+gTHvffd0BcnN4iADoCg2KoCS5qIepwNa+DVEP91lQchfy+4 S/xFe1hre1q1w5eMOXORgucWEDumo7mdbSNN78JWTkFt3m+GaiavN9m5jM8jGU0r/na9 FEhC+DA/TqD3LQ57w49ATRQI/qxPOC1LP2tmdEEp3kPgu2+JYAa4skKmcZPrC/A59mqe Gphg== MIME-Version: 1.0 Received: by 10.220.180.199 with SMTP id bv7mr5712932vcb.7.1334570469090; Mon, 16 Apr 2012 03:01:09 -0700 (PDT) Received: by 10.52.110.35 with HTTP; Mon, 16 Apr 2012 03:01:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Apr 2012 12:01:09 +0200 Message-ID: From: Bud Millwood To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DHC WG , Ted Lemon Subject: Re: [dhcwg] Requesting adoptionof draft-mrugalski-dhc-dhcpv6-failover-design-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 10:01:10 -0000 We support this as well. On Sat, Apr 14, 2012 at 5:38 AM, Bernie Volz (volz) wrote: > I support adoption of this document. > > > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Ted Lemon > Sent: Tuesday, April 10, 2012 10:14 AM > To: Tomek Mrugalski > Cc: DHC WG > Subject: Re: [dhcwg] Requesting adoptionof > draft-mrugalski-dhc-dhcpv6-failover-design-01 > > > > On Apr 8, 2012, at 6:14 PM, Tomek Mrugalski > wrote: > > I kindly request that we adopt this document as a DHC WG work item. > > > > Please consider Tomek's request an official call for adoption. =A0 =A0If = you are > in favor of adopting this as a working group work item, please say so. = =A0 If > you are against, please say so. > > > > We will evaluate consensus to adopt this draft as a working group work it= em > on April 24. > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From pengwu.thu@gmail.com Mon Apr 16 03:25:39 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069A221F870E for ; Mon, 16 Apr 2012 03:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQE+Ugh64Ees for ; Mon, 16 Apr 2012 03:25:38 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3D921F8709 for ; Mon, 16 Apr 2012 03:25:38 -0700 (PDT) Received: by dady13 with SMTP id y13so9267651dad.27 for ; Mon, 16 Apr 2012 03:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lUNoluKuSjD9umwmQhxiuyOl6Z4lW2ac6AKap+cUPKY=; b=CSQIDjhhv5VAb+sI4D327j/sRmJP96P7U/jC3R/qQ8tIyXz5qNEGVqHUefyDpY8bYD 8WfM+M9fHgsqnEmtuCSdY0KPnC8ekyOjMuKcRCaDX2U+gf9N9AFH8mpRiQBtEkj5taXs mL65j2jj4mxzDh7lDl1T2Xi8U8Sh4wlfp4aL+EVr6Provoqer8HR1BkaqlMtUEmRS20a wvjXajo4fEKZkZBuyX8fBmaLZvDPTjqzzqN0HnIKyomS6z3kSlKgOgeP8n4yaIqXRUpb 63nF+S0iCnjghQ4poRMLn/QbkVNX8XgnthUhalA3pIcLj+bl+wk1eg/VlwpLKFXhmD19 HDAA== MIME-Version: 1.0 Received: by 10.68.203.9 with SMTP id km9mr24355831pbc.94.1334571938039; Mon, 16 Apr 2012 03:25:38 -0700 (PDT) Received: by 10.68.21.103 with HTTP; Mon, 16 Apr 2012 03:25:37 -0700 (PDT) In-Reply-To: <201204151021.q3FALMOi095862@givry.fdupont.fr> References: <201204151021.q3FALMOi095862@givry.fdupont.fr> Date: Mon, 16 Apr 2012 18:25:37 +0800 Message-ID: From: Peng Wu To: Francis Dupont Content-Type: text/plain; charset=ISO-8859-1 Cc: "dhcwg@ietf.org" , Ted Lemon , Dmitry Anipko Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 10:25:39 -0000 Francis, >> Once the tunnel is established, renewals are (one assumes) routed >> down the tunnel. > => in fact to work well either the server has to handle both the TSV > function and the regular DHCPv4 over a tunnel, or a TRA is at the > tunnel other end. But this doesn't change the client/CRA so is a side > comment. The server could have native IPv4 access, used for receiving unicast message to server id. If we want to address this, we could add a RECOMMANDED setense. > >> If we require a special DHCPv4 client, we might aswell just do all >> the DHCPv4 transactions over UDPv6. > > => I agree: on the client side the DHCPv4 client is unmodified and > the CRA is as simple as possible. IMHO these are critical for the > target deployment, i.e., low cost CPEs. I agree this is critical. The only case we may break that is if we want to solve the problem in this thread when multiple CRAs with different addresses is unavailable. The reason I insist on the DHCP client for multiple tunnel endpoints with client IDs is because we would leave a question mark in the draft if we raise this problem but only mandate the multiple CRA solution(i.e., what if multiple v6 address unavailable) From Francis.Dupont@fdupont.fr Mon Apr 16 05:09:04 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0F321F86FD for ; Mon, 16 Apr 2012 05:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T-OyZvgm5bI for ; Mon, 16 Apr 2012 05:09:03 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 87B6A21F8672 for ; Mon, 16 Apr 2012 05:09:03 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3GC90RH089072; Mon, 16 Apr 2012 14:09:00 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204161209.q3GC90RH089072@givry.fdupont.fr> From: Francis Dupont To: Peng Wu In-reply-to: Your message of Mon, 16 Apr 2012 18:25:37 +0800. Date: Mon, 16 Apr 2012 14:09:00 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "dhcwg@ietf.org" , Ted Lemon , Dmitry Anipko Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 12:09:04 -0000 In your previous mail you wrote: > The server could have native IPv4 access, used for receiving unicast > message to server id. => according to my experiments it works only with a physical interface where renews are received, so it can put a constraint on the topology. But I tried only one server and not very hard. > If we want to address this, we could add a RECOMMANDED setense. => RECOMMENDED sentense? Today I am fine with the current wording even I know it won't be always followed in the real world (but the non-compliance is with RFC 2131 so please keep the can of worms closed :-). > I agree this is critical. The only case we may break that is if we > want to solve the problem in this thread when multiple CRAs with > different addresses is unavailable. => different addresses in IPv6 is pretty unlikely, even without multi-interface, so IMHO it is a problem which doesn't need to be addressed. > The reason I insist on the DHCP client for multiple tunnel endpoints > with client IDs => if endpoint stands for a node then there is one client with one interface, so no issue. If it stands for an interface please don't try to assign addresses to virtual interfaces using DHCP. > ... is because we would leave a question mark in the draft > if we raise this problem but only mandate the multiple CRA > solution (i.e., what if multiple v6 address unavailable) => I am not even convinced whether we should have a word about the problem, so of course I strongly object to put more. Regards Francis.Dupont@fdupont.fr PS: I have the draft with some editorial comments in front of me. From Ted.Lemon@nominum.com Mon Apr 16 05:33:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A684221F85E4 for ; Mon, 16 Apr 2012 05:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.485 X-Spam-Level: X-Spam-Status: No, score=-106.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKcSYEgqBk5g for ; Mon, 16 Apr 2012 05:33:23 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id ACAB621F85F9 for ; Mon, 16 Apr 2012 05:33:13 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT4wRiFDAfad0nX4nMb+eN8UlSlubIpRU@postini.com; Mon, 16 Apr 2012 05:33:13 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 50B181B83BD for ; Mon, 16 Apr 2012 05:33:12 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 455E619006C; Mon, 16 Apr 2012 05:33:12 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Mon, 16 Apr 2012 05:33:12 -0700 From: Ted Lemon To: Bud Millwood Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 Thread-Index: AQHNGj3M8A+q0iwf8kCif1zWgGUm5padnZkAgAA9b4A= Date: Mon, 16 Apr 2012 12:33:11 +0000 Message-ID: <21F1CED2-9B1E-4BBA-9CCB-66A1367465F4@nominum.com> References: <64B00097-8ACB-4170-9303-8F863A47C2B5@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <841506E5E1AC764C8B940E7D221EDC4F@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DHC WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 12:33:24 -0000 It is nearly inconceivable to me that some device out in the wild will chec= k for the client identifier and drop the packet if it's there. Anything's= possible, I guess, but I really don't think this is likely. Still, there is only one way to find out. I think making it an administra= tively-configured option is a valid risk-management strategy. From Francis.Dupont@fdupont.fr Mon Apr 16 06:01:57 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A356221F86B7 for ; Mon, 16 Apr 2012 06:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX386HUcrjd8 for ; Mon, 16 Apr 2012 06:01:57 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD6821F86A4 for ; Mon, 16 Apr 2012 06:01:56 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3GD1tXK092227; Mon, 16 Apr 2012 15:01:55 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204161301.q3GD1tXK092227@givry.fdupont.fr> From: Francis Dupont To: draft-ietf-dhc-dhcpv4-over-ipv6.all@tools.ietf.org Date: Mon, 16 Apr 2012 15:01:55 +0200 Sender: Francis.Dupont@fdupont.fr Cc: dhcwg@ietf.org Subject: [dhcwg] review of draft-ietf-dhc-dhcpv4-over-ipv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 13:01:57 -0000 Some editorial comments about draft-ietf-dhc-dhcpv4-over-ipv6-02.txt: - Abstract page 1: IMHO the abstract is not accurate (or was written far before protocol developments), for instance the "extending DHCP client and server behavior" is clearly wrong. - 1 page 3: perhaps you should add an appendix about usage scenarios (I can provide a real one for Stateless Deterministic NAT in DS-Lite mode if you want). - 3 page 4: I prefer the term "proxy" over the term "bridge" (because bridge is very layer 2 oriented, of course all of them are instance of the more generic "gateway") - 3 page 4: On-link -> On-Link (upper case L for the LCRA abbrev) - 3 page 4: if you really want to add something about multi-interface, the right place is in the LCRA definition, for example: "Note a LCRA serves only one link, e.g., the multiple link case is handled by multiple LCRA instances." - 2 page 4: TSV can listen -> TSV listens - 4 page 5: UDP(figure 2(a)). -> UDP (figure 2(a)). - 4 page 5: "TRA also communicates with a regular DHCPv4 server" is not fully true. The DHCPv4 server needs to handle CRA6ADDR suboptions, but note: * it is possible some DHCPv4 server provides a config hook for unknown RAI suboption, in this case the server code is not changed * I don't believe too much in the previous item because an IPv6 address is not an opaque string of 16 bytes, i.e., there is an easy update to the server code which makes it suitable to handle CRA6ADDR suboptions... I don't know what to put here. Perhaps the current text is the best? - 4 page 5: Option(Option 82) -> Option (Option 82) or (better) Option (Option code 82) - 5 page 6: I can't get the intended meaning of "extract the semantic of IPv6 address". Perhaps it should be: "extract the IPv6 address"? - 6 page 7: I am not sure the MUST for the global address is really required, perhaps a SHOULD is enough? BTW you don't require any thing about the server/agent configured addresses... - 6 page 7: if it has onbe. -> if it has one. - 6 page 7: I don't buy the coexistence of a LCRA and a TRA because in this case it is far simpler to use a plain DHCPv4 relay. Note without a good reason to keep it the SHOULD fro LCRA could be upgraded to a MUST. - 6 page 7: the LCRA MUST serve any client on the link -> SHOULD (note the RFC 2131 doesn't require something to a relay :-) - 6 page 7: in the last sentence of 6 I'd like to get Tomasz's (Tomasza) idea: a CRA MUST be configured to serve either as a CRA or a LCRA, i.e., there is a configuration knob with no default. - 6 page 7: about: A TSV can also listen on IPv4 UDP port 67 like a normal DHCPv4 server, and process normally when receives IPv4 DHCPv4 message. I coded this (i.e., a server which can support both standard DHCPv4, including of course behind a TRA, and the TSV function). So perhaps it is the time for a more visible MAY? - 7 page 8: if I have no concern about the "regular" in 4, this: This document places no new requirements on DHCPv4 servers that do not listen on UDPv6--in order to use an IPv4-only DHCPv4 server through an IPv6 connection, a TRA is required. is wrong. I suggest to add "other than to support the CRA6ADDR sub-option [section 5]" - 11 page 9: please ask Tomasz if he prefers Tomasz over the diminutive Tomek. - 12 page 9: the pagination is a disaster... Thanks Francis.Dupont@fdupont.fr PS: I found in RFC 2131 this very interesting section: 3.6 Use of DHCP in clients with multiple interfaces A client with multiple network interfaces must use DHCP through each interface independently to obtain configuration information parameters for those separate interfaces. From Ted.Lemon@nominum.com Mon Apr 16 08:24:28 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D347521F8653 for ; Mon, 16 Apr 2012 08:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.49 X-Spam-Level: X-Spam-Status: No, score=-106.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33EVO2XaP4In for ; Mon, 16 Apr 2012 08:24:27 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5D521F8650 for ; Mon, 16 Apr 2012 08:24:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKT4w5obp9HgSvnywG7gfjQ7OHM8K0Rqyx@postini.com; Mon, 16 Apr 2012 08:24:20 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DF80B1B839A for ; Mon, 16 Apr 2012 08:24:16 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D64FB190064 for ; Mon, 16 Apr 2012 08:24:16 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Mon, 16 Apr 2012 08:24:16 -0700 From: Ted Lemon To: DHC WG Thread-Topic: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item Thread-Index: AQHNE1Jkl7tgtOxKmkWYH3w2Igkw0Q== Date: Mon, 16 Apr 2012 15:24:16 +0000 Message-ID: <0DB4E514-A0A0-4F15-ACD2-BD5C6F7477BE@nominum.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_0DB4E514A0A04F15ACD2BD5C6F7477BEnominumcom_" MIME-Version: 1.0 Subject: [dhcwg] Fwd: Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 15:24:29 -0000 --_000_0DB4E514A0A04F15ACD2BD5C6F7477BEnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reminder, we're halfway through the last call period for this document. W= e've gotten a good response, so there's no need to respond if you aren't th= at interested, but if you are interested and haven't responded, please do. Begin forwarded message: From: Ted Lemon > Subject: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-= 00 as WG item Date: April 5, 2012 1:34:46 PM EDT To: "dhcwg@ietf.org WG" > On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) > wrote: At the Paris IETF-83 DHC WG meeting there was a lot of support for (and I b= elieve no opposition) adopting this as a DHC WG item. I kindly request that we adopt this document as a DHC WG work item. This draft documents issues that have come up involving interactions betwee= n prefix delegation and regular IP address allocation in practice. If you= would like the working group to work on documenting this, please signify b= y responding to this message in the affirmative. If you don't think we sh= ould work on it, please respond in the negative. If you have no opinion, = please do not respond. We will determine consensus on Thursday, April 19. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_0DB4E514A0A04F15ACD2BD5C6F7477BEnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8A77EE327A2B534F8C398182BED120B3@nominum.com> Content-Transfer-Encoding: quoted-printable Reminder, we're halfway through the last call period for this document. &nb= sp; We've gotten a good response, so there's no need to respond if you aren= 't that interested, but if you are interested and haven't responded, please= do.


    Begin forwarded message:

    From: Ted L= emon <Ted.Lemon@nominum.com= >
    Subject: [d= hcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG it= em
    Date: April= 5, 2012 1:34:46 PM EDT

    On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
    At the Paris IETF-83 DHC WG meeting there was a lot of support for (and I b= elieve no opposition) adopting this as a DHC WG item.
     
    I kindly request that we adopt this document as a DHC WG work item.

    This draft documents issues that have come up involving interactions b= etween prefix delegation and regular IP address allocation in practice. &nb= sp; If you would like the working group to work on documenting this, please= signify by responding to this message in the affirmative.   If you don't think we should work on it, please= respond in the negative.   If you have no opinion, please do not resp= ond.

    We will determine consensus on Thursday, April 19. 

    _______________________________________________
    dhcwg mailing list
    dhcwg@ietf.org
    https://www.ietf.org/mailman/listinfo/dhcwg

    --_000_0DB4E514A0A04F15ACD2BD5C6F7477BEnominumcom_-- From jason.weil@twcable.com Mon Apr 16 11:13:33 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3702E11E80AB for ; Mon, 16 Apr 2012 11:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.027 X-Spam-Level: X-Spam-Status: No, score=0.027 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 174smpuMmbLb for ; Mon, 16 Apr 2012 11:13:32 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4168011E80DB for ; Mon, 16 Apr 2012 11:13:32 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,429,1330923600"; d="scan'208,217";a="368330197" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 16 Apr 2012 14:05:46 -0400 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.44]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 16 Apr 2012 14:06:27 -0400 From: "Weil, Jason" To: Ted Lemon , DHC WG Date: Mon, 16 Apr 2012 14:06:25 -0400 Thread-Topic: [dhcwg] Fwd: Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item Thread-Index: Ac0b+6RVrry1k6sVRUGNfb94RRbqhA== Message-ID: In-Reply-To: <0DB4E514-A0A0-4F15-ACD2-BD5C6F7477BE@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBB1D7601542Bjasonweiltwcablecom_" MIME-Version: 1.0 Subject: Re: [dhcwg] Fwd: Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 18:13:33 -0000 --_000_CBB1D7601542Bjasonweiltwcablecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am definitely interested in seeing this move forward especially for all t= hose working on client implementations out there in the world. Thanks, Jason From: Ted Lemon > Date: Mon, 16 Apr 2012 11:24:16 -0400 To: DHC WG > Subject: [dhcwg] Fwd: Call for Adoption, draft-troan-dhc-dhcpv6-stateful-is= sues-00 as WG item Reminder, we're halfway through the last call period for this document. W= e've gotten a good response, so there's no need to respond if you aren't th= at interested, but if you are interested and haven't responded, please do. Begin forwarded message: From: Ted Lemon > Subject: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-= 00 as WG item Date: April 5, 2012 1:34:46 PM EDT To: "dhcwg@ietf.org WG" > On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) > wrote: At the Paris IETF-83 DHC WG meeting there was a lot of support for (and I b= elieve no opposition) adopting this as a DHC WG item. I kindly request that we adopt this document as a DHC WG work item. This draft documents issues that have come up involving interactions betwee= n prefix delegation and regular IP address allocation in practice. If you= would like the working group to work on documenting this, please signify b= y responding to this message in the affirmative. If you don't think we sh= ould work on it, please respond in the negative. If you have no opinion, = please do not respond. We will determine consensus on Thursday, April 19. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_CBB1D7601542Bjasonweiltwcablecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    I am definitely interested in seeing this move forward especially for = all those working on client implementations out there in the world.

    Thanks,

    Jason

    From: Ted Lemon <Ted.Lemon@nominum.com>
    Date: Mon, 16 Apr 2012 11:24:16 -04= 00
    To: DHC WG <dhcwg@ietf.org>
    Subject: [dhcwg] Fwd: Call for Adop= tion, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item

    Reminder, we're halfway through the last call period for this document. &nb= sp; We've gotten a good response, so there's no need to respond if you aren= 't that interested, but if you are interested and haven't responded, please= do.


    Begin forwarded message:

    From: Ted L= emon <Ted.Lemon@nominum.com= >
    Subject: [d= hcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG it= em
    Date: April= 5, 2012 1:34:46 PM EDT

    On Apr 5, 2012, at 1:25 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
    At the Paris IETF-83 DHC WG meeting there was a lot of support for (and I b= elieve no opposition) adopting this as a DHC WG item.
     
    I kindly request that we adopt this document as a DHC WG work item.

    This draft documents issues that have come up involving interactions b= etween prefix delegation and regular IP address allocation in practice. &nb= sp; If you would like the working group to work on documenting this, please= signify by responding to this message in the affirmative.   If you don't think we should work on it, please= respond in the negative.   If you have no opinion, please do not resp= ond.

    We will determine consensus on Thursday, April 19. 

    _______________________________________________
    dhcwg mailing list
    dhcwg@ietf.org
    https://www.ietf.or= g/mailman/listinfo/dhcwg


    This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
     --_000_CBB1D7601542Bjasonweiltwcablecom_-- From akostur@incognito.com Mon Apr 16 15:34:07 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6431F21F85C0 for ; Mon, 16 Apr 2012 15:34:07 -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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+IPSxZH58Ec for ; Mon, 16 Apr 2012 15:34:06 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with SMTP id 319E521F85BB for ; Mon, 16 Apr 2012 15:34:05 -0700 (PDT) Received: from mail-lpp01m010-f43.google.com ([209.85.215.43]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKT4yeXSOVC/VA+aUkBtQmtUz20nPci2O5@postini.com; Mon, 16 Apr 2012 15:34:06 PDT Received: by lagr15 with SMTP id r15so4568722lag.30 for ; Mon, 16 Apr 2012 15:34:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=zzjTf4GqbuJ+/V0k58XyVTfEhBCKlsZNEOir6mPWNg0=; b=XQZVz1hKy6gi4rZFa3X9xZ6IBVTn7gvVfSS+1vhaKr+09cdUbQp64cAq7dk/LwqaU/ p74N1NsbHoD4ns1QrNB4lPPsDd8tQCvcN1U2knewNs4ZFl8tlsPRVreeLMnRybq+yyKm eEmqaGlK6hPnrbv8+dtyldhXYmAfLWw3yqtFJMMENZCCqxnpn0Okwvw09LCx7YMNGZht FEXVMU9dkseVQsazc4CVo4mkSWviQSrWupZMqP0sqMHXO4+uv57wQ6Dr9Xx/kCVQKY3C RGo2twU70knXOz+3y7H9BB0Yjk5ZedG+gDJbGnxSg6ae/I8ea/GfH86uyC84KLAW4yGe CgGA== MIME-Version: 1.0 Received: by 10.152.127.136 with SMTP id ng8mr12051244lab.16.1334615643540; Mon, 16 Apr 2012 15:34:03 -0700 (PDT) Received: by 10.112.28.195 with HTTP; Mon, 16 Apr 2012 15:34:03 -0700 (PDT) In-Reply-To: <21F1CED2-9B1E-4BBA-9CCB-66A1367465F4@nominum.com> References: <64B00097-8ACB-4170-9303-8F863A47C2B5@nominum.com> <21F1CED2-9B1E-4BBA-9CCB-66A1367465F4@nominum.com> Date: Mon, 16 Apr 2012 15:34:03 -0700 Message-ID: From: Andre Kostur To: Ted Lemon Content-Type: multipart/alternative; boundary=f46d042c5f83584ca804bdd36bd4 X-Gm-Message-State: ALoCoQluLxNkIIMVzcLQ5Yl3uiq2uM1gTAmw9O5Z9OOIbqRBfvniedhnlmuFbNCitLnUu2oBEGwS Cc: DHC WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 22:34:07 -0000 --f46d042c5f83584ca804bdd36bd4 Content-Type: text/plain; charset=ISO-8859-1 I support this draft. On Mon, Apr 16, 2012 at 05:33, Ted Lemon wrote: > It is nearly inconceivable to me that some device out in the wild will > check for the client identifier and drop the packet if it's there. > Anything's possible, I guess, but I really don't think this is likely. > > Still, there is only one way to find out. I think making it an > administratively-configured option is a valid risk-management strategy. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > -- *Andre Kostur* --f46d042c5f83584ca804bdd36bd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    I support this draft.

    On= Mon, Apr 16, 2012 at 05:33, Ted Lemon <Ted.Lemon@nominum.com> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> It is nearly inconceivable to me that some device out in the wild will chec= k for the client identifier and drop the packet if it's there. =A0 Anyt= hing's possible, I guess, but I really don't think this is likely.<= br>
    Still, there is only one way to find out. =A0 I think making it an administ= ratively-configured option is a valid risk-management strategy.

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



    --
    =
    Andre= Kostur
    --f46d042c5f83584ca804bdd36bd4-- From prashanth.r@gmail.com Mon Apr 16 21:10:37 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C002811E809F for ; Mon, 16 Apr 2012 21:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gd6PCaHbJOJP for ; Mon, 16 Apr 2012 21:10:33 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A339611E8081 for ; Mon, 16 Apr 2012 21:10:33 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so5074086pbb.31 for ; Mon, 16 Apr 2012 21:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IwDx2d/8RVk9k6f0iwT9YnjLDc9gRBjSu2OYZdEQ8VU=; b=RjhhHlTBRlDn9sJcPocOW19Gq7MTD+xhefoVTdGXr70Jg84OPHsHpxixN8nUb0zp3e mcS801s0FP9dtuaSuxOsc8ERdzF3NaH/8jae9VTt/Eqnq35Mny7G0DQ9K1d7HmXAjxlu 7gUy2dkre2VC0hbgYs79IsMKzFfPGSqnhXJuDVSgT/tvB52KazeYzNO1XWhlHcJF4k8x RezGSiSUhxa/z30Kpjzhq3DNOt8ckXguyZz+Ugpk2BjpROly/VT8TPvvGjaUnaU7z98e zw6MlzAwzTwogeRmO30ZaBj7rEnno2VtZhK0T9v8AJwI0/etmdZEanTzxrvB9ZDZagBo DHww== MIME-Version: 1.0 Received: by 10.68.131.69 with SMTP id ok5mr8232815pbb.2.1334635833485; Mon, 16 Apr 2012 21:10:33 -0700 (PDT) Received: by 10.143.138.10 with HTTP; Mon, 16 Apr 2012 21:10:33 -0700 (PDT) In-Reply-To: <64B00097-8ACB-4170-9303-8F863A47C2B5@nominum.com> References: <64B00097-8ACB-4170-9303-8F863A47C2B5@nominum.com> Date: Tue, 17 Apr 2012 09:40:33 +0530 Message-ID: From: Prashanth R To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b15a819c2679d04bdd81eed Cc: DHC WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 04:10:37 -0000 --047d7b15a819c2679d04bdd81eed Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ted, I am in favour of supporting this draft. I have a couple of suggestions: 1) Can we add a section which would say what SHOULD be the behaviour on the client when it receives a packet with the client-id set. 2) Can a clarification be added on what the server SHOULD do when it receives a DHCP packet with 0 mac-addr and no client-id. Thanks, Prashanth. On Sat, Apr 14, 2012 at 6:24 PM, Ted Lemon wrote: > This document corrects a bug in RFC2131 that forbids the DHCP server from > returning a DHCP client identifier. The lack of a DHCP client identifie= r > creates a problem in two cases: where the underlying transport has no > link-layer address, and where two clients are running on the same host, > supplying different client identifiers so as to present different network > identities. In both of these cases, insufficient information is returne= d > from the DHCP server to clearly identify the client that is the intended > recipient of the message. The only way to fix this is to _require_ the > DHCP server to return the client identifier if it receives it. This is > what the proposed document does. > > We checked for consensus in the meeting, and four people were in favor of > advancing the draft; nobody was against. > > I think this is actually pretty important work=97it's a lingering bug in = the > spec which I think will come back to bite us more and more as we start > getting deeper into the dual-stack transition. So if you haven't read t= he > document, please do. > > If you support advancing it, please signify by replying to this message > and saying that you support it. If you think it's a bad idea, please > signify by replying to this message and explaining why. If you have > comments or changes to propose, please send them along, and also signify > whether you are in favor of advancement with the change, without the > change, or oppose advancement. > > We will determine consensus on April 27, based solely on responses on the > mailing list, so please do respond. > > Thanks! > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --047d7b15a819c2679d04bdd81eed Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ted,

    I am in favour of supporting this draft.

    I have a co= uple of suggestions:

    1) Can we add a section which would say what S= HOULD be the behaviour on the client when it receives a packet with the cli= ent-id set.
    2) Can a clarification be added on what the server SHOULD do when it receiv= es a DHCP packet with 0 mac-addr and no client-id.

    Thanks,
    Prash= anth.

    On Sat, Apr 14, 2012 at 6:24 PM, T= ed Lemon <Ted= .Lemon@nominum.com> wrote:
    This document corrects a bug in RFC2131 that= forbids the DHCP server from returning a DHCP client identifier. =A0 The l= ack of a DHCP client identifier creates a problem in two cases: where the u= nderlying transport has no link-layer address, and where two clients are ru= nning on the same host, supplying different client identifiers so as to pre= sent different network identities. =A0 In both of these cases, insufficient= information is returned from the DHCP server to clearly identify the clien= t that is the intended recipient of the message. =A0 The only way to fix th= is is to _require_ the DHCP server to return the client identifier if it re= ceives it. =A0 This is what the proposed document does.

    We checked for consensus in the meeting, and four people were in favor of a= dvancing the draft; nobody was against.

    I think this is actually pretty important work=97it's a lingering bug i= n the spec which I think will come back to bite us more and more as we star= t getting deeper into the dual-stack transition. =A0 So if you haven't = read the document, please do.

    If you support advancing it, please signify by replying to this message and= saying that you support it. If you think it's a bad idea, please signi= fy by replying to this message and explaining why. =A0 If you have comments= or changes to propose, please send them along, and also signify whether yo= u are in favor of advancement with the change, without the change, or oppos= e advancement.

    We will determine consensus on April 27, based solely on responses on the m= ailing list, so please do respond.

    Thanks!

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

    --047d7b15a819c2679d04bdd81eed-- From sunqi.thu@gmail.com Tue Apr 17 00:58:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171AA21F85A2 for ; Tue, 17 Apr 2012 00:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_66=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cgbi2fQdgWv for ; Tue, 17 Apr 2012 00:58:27 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D83121F853F for ; Tue, 17 Apr 2012 00:58:27 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so5272999pbb.31 for ; Tue, 17 Apr 2012 00:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-mailer:mime-version:message-id:content-type; bh=h8r3zuHs3ztDq2hDmczxb6K5gPbd/0DpDXkdzmkg+PA=; b=AIhbN4OfB0Ss/HpHORSV3CK3DlpCBN8810qiugguQVZ7H0w+DuHVveMMkaBdJs0Bh9 rNNVFYwNnGk9S0Xb07NRf2urIIRvwRshLegePoNFvcRLGfR78ZxdAHVSu24QbUzIwajT dIp/SfF8SnyQ1uKvZZZimtFOQ3cWpbIWZGC7qtWAf92DhUJkjhGSIGCQyv9Sp8u4b2Po j6tkIIPBYqIP5AWD8e6dRup5V56DkPgNFgTm3Jl18/iDwynoKxy0XrKywm9tCyGfk/Dq QWE6MYYYJ0UPA6acUaslzJthgOqAYuzKewaIj75tTqgNU0yiEsraDK/PPoJOhoQIX84t qnbQ== Received: by 10.68.240.42 with SMTP id vx10mr34622585pbc.21.1334649506859; Tue, 17 Apr 2012 00:58:26 -0700 (PDT) Received: from sunqi ([166.111.68.231]) by mx.google.com with ESMTPS id i8sm20040447pbi.47.2012.04.17.00.58.22 (version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 00:58:26 -0700 (PDT) Date: Tue, 17 Apr 2012 15:58:19 +0800 From: "Qi Sun" To: "Francis Dupont" , draft-ietf-dhc-dhcpv4-over-ipv6.all References: <201204161301.q3GD1tXK092227@givry.fdupont.fr> X-Priority: 3 X-GUID: 6DB7BEB4-94C1-4EA1-BAB0-828266387FDE X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <201204171558195492704@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart358161457038_=----" Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] review of draft-ietf-dhc-dhcpv4-over-ipv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.thu" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 07:58:31 -0000 This is a multi-part message in MIME format. ------=_001_NextPart358161457038_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRnJhbmNpcywNCg0KSW4geW91ciBwcmV2aW91cyBtYWlsLCB5b3Ugd3JvdGU6IA0KDQogLSAz IHBhZ2UgNDogSSBwcmVmZXIgdGhlIHRlcm0gInByb3h5IiBvdmVyIHRoZSB0ZXJtICJicmlkZ2Ui IChiZWNhdXNlDQogIGJyaWRnZSBpcyB2ZXJ5IGxheWVyIDIgb3JpZW50ZWQsIG9mIGNvdXJzZSBh bGwgb2YgdGhlbSBhcmUgaW5zdGFuY2UNCiAgb2YgdGhlIG1vcmUgZ2VuZXJpYyAiZ2F0ZXdheSIp DQoNCltRaV0gSU1ITyB0aGUgdGVybSChsHByb3h5obEgY2FuIG1pc2xlYWQgdGhlIHJlYWRlcnMg dG8gdGFrZSB0aGUgQ1JBIGFzIGEgobBwcm94eaGxLCB3aGljaCBhY3R1YWxseSBpc26hr3QuIA0K ICAgICAgICBTbyBJIHdvdWxkIHByZWZlciB0aGUgdGVybSChsGJyaWRnZaGxLiBUaGUgobBicmlk Z2WhsSBoZXJlIGlzIGp1c3QgbWV0YXBob3JpY2FsLg0KDQpCZXN0IFJlZ2FyZHMNCg0KDQoNCg0K UWkgU3VuDQoNCkZyb206IEZyYW5jaXMgRHVwb250DQpEYXRlOiAyMDEyLTA0LTE2IDIxOjAxDQpU bzogZHJhZnQtaWV0Zi1kaGMtZGhjcHY0LW92ZXItaXB2Ni5hbGwNCkNDOiBkaGN3Zw0KU3ViamVj dDogW2RoY3dnXSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kaGMtZGhjcHY0LW92ZXItaXB2Ni0wMi50 eHQNClNvbWUgZWRpdG9yaWFsIGNvbW1lbnRzIGFib3V0IGRyYWZ0LWlldGYtZGhjLWRoY3B2NC1v dmVyLWlwdjYtMDIudHh0Og0KDQogLSBBYnN0cmFjdCBwYWdlIDE6IElNSE8gdGhlIGFic3RyYWN0 IGlzIG5vdCBhY2N1cmF0ZSAob3Igd2FzIHdyaXR0ZW4NCiAgIGZhciBiZWZvcmUgcHJvdG9jb2wg ZGV2ZWxvcG1lbnRzKSwgZm9yIGluc3RhbmNlIHRoZSAiZXh0ZW5kaW5nIERIQ1ANCiAgIGNsaWVu dCBhbmQgc2VydmVyIGJlaGF2aW9yIiBpcyBjbGVhcmx5IHdyb25nLg0KDQogLSAxIHBhZ2UgMzog cGVyaGFwcyB5b3Ugc2hvdWxkIGFkZCBhbiBhcHBlbmRpeCBhYm91dCB1c2FnZSBzY2VuYXJpb3MN CiAgKEkgY2FuIHByb3ZpZGUgYSByZWFsIG9uZSBmb3IgU3RhdGVsZXNzIERldGVybWluaXN0aWMg TkFUIGluIERTLUxpdGUNCiAgbW9kZSBpZiB5b3Ugd2FudCkuDQoNCiAtIDMgcGFnZSA0OiBJIHBy ZWZlciB0aGUgdGVybSAicHJveHkiIG92ZXIgdGhlIHRlcm0gImJyaWRnZSIgKGJlY2F1c2UNCiAg YnJpZGdlIGlzIHZlcnkgbGF5ZXIgMiBvcmllbnRlZCwgb2YgY291cnNlIGFsbCBvZiB0aGVtIGFy ZSBpbnN0YW5jZQ0KICBvZiB0aGUgbW9yZSBnZW5lcmljICJnYXRld2F5IikNCg0KIC0gMyBwYWdl IDQ6IE9uLWxpbmsgLT4gT24tTGluayAodXBwZXIgY2FzZSBMIGZvciB0aGUgTENSQSBhYmJyZXYp DQoNCiAtIDMgcGFnZSA0OiBpZiB5b3UgcmVhbGx5IHdhbnQgdG8gYWRkIHNvbWV0aGluZyBhYm91 dCBtdWx0aS1pbnRlcmZhY2UsDQogIHRoZSByaWdodCBwbGFjZSBpcyBpbiB0aGUgTENSQSBkZWZp bml0aW9uLCBmb3IgZXhhbXBsZToNCiAgIk5vdGUgYSBMQ1JBIHNlcnZlcyBvbmx5IG9uZSBsaW5r LCBlLmcuLCB0aGUgbXVsdGlwbGUgbGluayBjYXNlIGlzDQogICBoYW5kbGVkIGJ5IG11bHRpcGxl IExDUkEgaW5zdGFuY2VzLiINCg0KIC0gMiBwYWdlIDQ6IFRTViBjYW4gbGlzdGVuIC0+IFRTViBs aXN0ZW5zDQoNCiAtIDQgcGFnZSA1OiBVRFAoZmlndXJlIDIoYSkpLiAtPiBVRFAgKGZpZ3VyZSAy KGEpKS4NCg0KIC0gNCBwYWdlIDU6ICJUUkEgYWxzbyBjb21tdW5pY2F0ZXMgd2l0aCBhIHJlZ3Vs YXIgREhDUHY0IHNlcnZlciIgaXMNCiAgIG5vdCBmdWxseSB0cnVlLiBUaGUgREhDUHY0IHNlcnZl ciBuZWVkcyB0byBoYW5kbGUgQ1JBNkFERFINCiAgIHN1Ym9wdGlvbnMsIGJ1dCBub3RlOg0KICAg KiBpdCBpcyBwb3NzaWJsZSBzb21lIERIQ1B2NCBzZXJ2ZXIgcHJvdmlkZXMgYSBjb25maWcgaG9v ayBmb3INCiAgICAgdW5rbm93biBSQUkgc3Vib3B0aW9uLCBpbiB0aGlzIGNhc2UgdGhlIHNlcnZl ciBjb2RlIGlzIG5vdA0KICAgICBjaGFuZ2VkDQogICAqIEkgZG9uJ3QgYmVsaWV2ZSB0b28gbXVj aCBpbiB0aGUgcHJldmlvdXMgaXRlbSBiZWNhdXNlIGFuIElQdjYNCiAgICAgYWRkcmVzcyBpcyBu b3QgYW4gb3BhcXVlIHN0cmluZyBvZiAxNiBieXRlcywgaS5lLiwgdGhlcmUgaXMgYW4NCiAgICAg ZWFzeSB1cGRhdGUgdG8gdGhlIHNlcnZlciBjb2RlIHdoaWNoIG1ha2VzIGl0IHN1aXRhYmxlIHRv IGhhbmRsZQ0KICAgICBDUkE2QUREUiBzdWJvcHRpb25zLi4uDQogICBJIGRvbid0IGtub3cgd2hh dCB0byBwdXQgaGVyZS4gUGVyaGFwcyB0aGUgY3VycmVudCB0ZXh0IGlzIHRoZQ0KICAgYmVzdD8N Cg0KIC0gNCBwYWdlIDU6IE9wdGlvbihPcHRpb24gODIpIC0+IE9wdGlvbiAoT3B0aW9uIDgyKSBv ciAoYmV0dGVyKQ0KICBPcHRpb24gKE9wdGlvbiBjb2RlIDgyKQ0KDQogLSA1IHBhZ2UgNjogSSBj YW4ndCBnZXQgdGhlIGludGVuZGVkIG1lYW5pbmcgb2YNCiAgImV4dHJhY3QgdGhlIHNlbWFudGlj IG9mIElQdjYgYWRkcmVzcyIuIFBlcmhhcHMgaXQgc2hvdWxkIGJlOg0KICAiZXh0cmFjdCB0aGUg SVB2NiBhZGRyZXNzIj8NCg0KIC0gNiBwYWdlIDc6IEkgYW0gbm90IHN1cmUgdGhlIE1VU1QgZm9y IHRoZSBnbG9iYWwgYWRkcmVzcyBpcw0KICByZWFsbHkgcmVxdWlyZWQsIHBlcmhhcHMgYSBTSE9V TEQgaXMgZW5vdWdoPyBCVFcgeW91IGRvbid0IHJlcXVpcmUNCiAgYW55IHRoaW5nIGFib3V0IHRo ZSBzZXJ2ZXIvYWdlbnQgY29uZmlndXJlZCBhZGRyZXNzZXMuLi4NCg0KIC0gNiBwYWdlIDc6IGlm IGl0IGhhcyBvbmJlLiAtPiBpZiBpdCBoYXMgb25lLg0KDQogLSA2IHBhZ2UgNzogSSBkb24ndCBi dXkgdGhlIGNvZXhpc3RlbmNlIG9mIGEgTENSQSBhbmQgYSBUUkEgYmVjYXVzZQ0KICBpbiB0aGlz IGNhc2UgaXQgaXMgZmFyIHNpbXBsZXIgdG8gdXNlIGEgcGxhaW4gREhDUHY0IHJlbGF5LiBOb3Rl DQogIHdpdGhvdXQgYSBnb29kIHJlYXNvbiB0byBrZWVwIGl0IHRoZSBTSE9VTEQgZnJvIExDUkEg Y291bGQgYmUNCiAgdXBncmFkZWQgdG8gYSBNVVNULg0KDQogLSA2IHBhZ2UgNzogdGhlIExDUkEg TVVTVCBzZXJ2ZSBhbnkgY2xpZW50IG9uIHRoZSBsaW5rIC0+IFNIT1VMRA0KICAobm90ZSB0aGUg UkZDIDIxMzEgZG9lc24ndCByZXF1aXJlIHNvbWV0aGluZyB0byBhIHJlbGF5IDotKQ0KDQogLSA2 IHBhZ2UgNzogaW4gdGhlIGxhc3Qgc2VudGVuY2Ugb2YgNiBJJ2QgbGlrZSB0byBnZXQgVG9tYXN6 J3MNCiAgKFRvbWFzemEpIGlkZWE6IGEgQ1JBIE1VU1QgYmUgY29uZmlndXJlZCB0byBzZXJ2ZSBl aXRoZXIgYXMgYSBDUkEgb3INCiAgYSBMQ1JBLCBpLmUuLCB0aGVyZSBpcyBhIGNvbmZpZ3VyYXRp b24ga25vYiB3aXRoIG5vIGRlZmF1bHQuDQoNCiAtIDYgcGFnZSA3OiBhYm91dDoNCg0KICAgQSBU U1YgY2FuIGFsc28gbGlzdGVuIG9uIElQdjQgVURQIHBvcnQgNjcgbGlrZSBhDQogICBub3JtYWwg REhDUHY0IHNlcnZlciwgYW5kIHByb2Nlc3Mgbm9ybWFsbHkgd2hlbiByZWNlaXZlcyBJUHY0IERI Q1B2NA0KICAgbWVzc2FnZS4NCg0KICAgSSBjb2RlZCB0aGlzIChpLmUuLCBhIHNlcnZlciB3aGlj aCBjYW4gc3VwcG9ydCBib3RoIHN0YW5kYXJkIERIQ1B2NCwNCiAgIGluY2x1ZGluZyBvZiBjb3Vy c2UgYmVoaW5kIGEgVFJBLCBhbmQgdGhlIFRTViBmdW5jdGlvbikuIFNvIHBlcmhhcHMNCiAgIGl0 IGlzIHRoZSB0aW1lIGZvciBhIG1vcmUgdmlzaWJsZSBNQVk/DQoNCiAtIDcgcGFnZSA4OiBpZiBJ IGhhdmUgbm8gY29uY2VybiBhYm91dCB0aGUgInJlZ3VsYXIiIGluIDQsIHRoaXM6DQoNCiAgIFRo aXMgZG9jdW1lbnQgcGxhY2VzIG5vIG5ldyByZXF1aXJlbWVudHMgb24gREhDUHY0IHNlcnZlcnMg dGhhdCBkbw0KICAgbm90IGxpc3RlbiBvbiBVRFB2Ni0taW4gb3JkZXIgdG8gdXNlIGFuIElQdjQt b25seSBESENQdjQgc2VydmVyDQogICB0aHJvdWdoIGFuIElQdjYgY29ubmVjdGlvbiwgYSBUUkEg aXMgcmVxdWlyZWQuDQoNCiAgaXMgd3JvbmcuIEkgc3VnZ2VzdCB0byBhZGQgIm90aGVyIHRoYW4g dG8gc3VwcG9ydCB0aGUgQ1JBNkFERFINCiAgc3ViLW9wdGlvbiBbc2VjdGlvbiA1XSINCg0KIC0g MTEgcGFnZSA5OiBwbGVhc2UgYXNrIFRvbWFzeiBpZiBoZSBwcmVmZXJzIFRvbWFzeiBvdmVyIHRo ZQ0KICAgZGltaW51dGl2ZSBUb21lay4NCg0KIC0gMTIgcGFnZSA5OiB0aGUgcGFnaW5hdGlvbiBp cyBhIGRpc2FzdGVyLi4uDQoNClRoYW5rcw0KDQpGcmFuY2lzLkR1cG9udEBmZHVwb250LmZyDQoN ClBTOiBJIGZvdW5kIGluIFJGQyAyMTMxIHRoaXMgdmVyeSBpbnRlcmVzdGluZyBzZWN0aW9uOg0K DQozLjYgVXNlIG9mIERIQ1AgaW4gY2xpZW50cyB3aXRoIG11bHRpcGxlIGludGVyZmFjZXMNCg0K ICAgQSBjbGllbnQgd2l0aCBtdWx0aXBsZSBuZXR3b3JrIGludGVyZmFjZXMgbXVzdCB1c2UgREhD UCB0aHJvdWdoIGVhY2gNCiAgIGludGVyZmFjZSBpbmRlcGVuZGVudGx5IHRvIG9idGFpbiBjb25m aWd1cmF0aW9uIGluZm9ybWF0aW9uDQogICBwYXJhbWV0ZXJzIGZvciB0aG9zZSBzZXBhcmF0ZSBp bnRlcmZhY2VzLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KZGhjd2cgbWFpbGluZyBsaXN0DQpkaGN3Z0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw== ------=_001_NextPart358161457038_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
    Hi Francis,
     
    In your previous mail, you wrote:
     
     - 3 page 4: I prefer the ter= m "proxy" over the term "bridge" (because
      bridge is very layer 2 oriented,=  of course all of them are instance
      of the more generic "gateway")
     
    [Qi] IM= HO the term=20 =A1=B0proxy=A1=B1 can mislead the readers to take the CRA as a =A1=B0proxy= =A1=B1, which actually=20 isn=A1=AFt.

          &= nbsp; So I=20 would prefer the term =A1=B0bridge=A1=B1. The =A1=B0bridge=A1=B1 here is j= ust=20 metaphorical.

     
    Best Regards
     
    Qi Sun
     
    Date: 2012-04-16 21:01
    To: draft-i= etf-dhc-dhcpv4-over-ipv6.all
    CC: dhcwg
    Subject: [dhcwg] review of=20 draft-ietf-dhc-dhcpv4-over-ipv6-02.txt
    Some editorial comments about draft-ietf-dhc-dhcp= v4-over-ipv6-02.txt:
     
     - Abstract page 1: IMHO the abstr= act is not accurate (or was written
       far before protocol developments),&n= bsp;for instance the "extending DHCP
       client and server behavior" is&= nbsp;clearly wrong.
     
     - 1 page 3: perhaps you should&nb= sp;add an appendix about usage scenarios
      (I can provide a real one f= or Stateless Deterministic NAT in DS-Lite
      mode if you want).
     
     - 3 page 4: I prefer the ter= m "proxy" over the term "bridge" (because
      bridge is very layer 2 oriented,=  of course all of them are instance
      of the more generic "gateway")
     
     - 3 page 4: On-link -> On-Link=  (upper case L for the LCRA abbrev)
     
     - 3 page 4: if you really wa= nt to add something about multi-interface,
      the right place is in the L= CRA definition, for example:
      "Note a LCRA serves only one&nbs= p;link, e.g., the multiple link case is
       handled by multiple LCRA instan= ces."
     
     - 2 page 4: TSV can listen -= > TSV listens
     
     - 4 page 5: UDP(figure 2(a)). -&g= t; UDP (figure 2(a)).
     
     - 4 page 5: "TRA also communicate= s with a regular DHCPv4 server" is
       not fully true. The DHCPv4 = ;server needs to handle CRA6ADDR
       suboptions, but note:
       * it is possible some DHCP= v4 server provides a config hook for
         unknown RAI suboption, i= n this case the server code is not
         changed
       * I don't believe too much=  in the previous item because an IPv6
         address is not an o= paque string of 16 bytes, i.e., there i= s an
         easy update to the = server code which makes it suitable to = handle
         CRA6ADDR suboptions...
       I don't know what to put&n= bsp;here. Perhaps the current text is the
       best?
     
     - 4 page 5: Option(Option 82) -&g= t; Option (Option 82) or (better)
      Option (Option code 82)
     
     - 5 page 6: I can't get the&= nbsp;intended meaning of
      "extract the semantic of IPv6 ad= dress". Perhaps it should be:
      "extract the IPv6 address"?
     
     - 6 page 7: I am not sure&nb= sp;the MUST for the global address is
      really required, perhaps a SHOULD&nbs= p;is enough? BTW you don't require
      any thing about the server/agent = ;configured addresses...
     
     - 6 page 7: if it has onbe.&= nbsp;-> if it has one.
     
     - 6 page 7: I don't buy the&= nbsp;coexistence of a LCRA and a TRA be= cause
      in this case it is far simp= ler to use a plain DHCPv4 relay. Note
      without a good reason to keep&nb= sp;it the SHOULD fro LCRA could be
      upgraded to a MUST.
     
     - 6 page 7: the LCRA MUST se= rve any client on the link -> SHOULD=
      (note the RFC 2131 doesn't requi= re something to a relay :-)
     
     - 6 page 7: in the last sent= ence of 6 I'd like to get Tomasz's
      (Tomasza) idea: a CRA MUST be&nb= sp;configured to serve either as a CRA = or
      a LCRA, i.e., there is a co= nfiguration knob with no default.
     
     - 6 page 7: about:
     
       A TSV can also listen on&n= bsp;IPv4 UDP port 67 like a
       normal DHCPv4 server, and proce= ss normally when receives IPv4 DHCPv4
       message.
     
       I coded this (i.e., a serv= er which can support both standard DHCPv4,
       including of course behind a&nb= sp;TRA, and the TSV function). So perhaps
       it is the time for a = more visible MAY?
     
     - 7 page 8: if I have no&nbs= p;concern about the "regular" in 4, this:
     
       This document places no new&nbs= p;requirements on DHCPv4 servers that do
       not listen on UDPv6--in order&n= bsp;to use an IPv4-only DHCPv4 server
       through an IPv6 connection, a&n= bsp;TRA is required.
     
      is wrong. I suggest to add = "other than to support the CRA6ADDR
      sub-option [section 5]"
     
     - 11 page 9: please ask Tomasz&nb= sp;if he prefers Tomasz over the
       diminutive Tomek.
     
     - 12 page 9: the pagination is&nb= sp;a disaster...
     
    Thanks
     
    Francis.Dupont@fdupont.fr
     
    PS: I found in RFC 2131 this very&= nbsp;interesting section:
     
    3.6 Use of DHCP in clients with mu= ltiple interfaces
     
       A client with multiple network&= nbsp;interfaces must use DHCP through each
       interface independently to obtain&nb= sp;configuration information
       parameters for those separate i= nterfaces.
     
    _______________________________________________
    dhcwg mailing list
    dhcwg@ietf.org
    https://www.ietf.org/mailman/listinfo/dhcwg
    ------=_001_NextPart358161457038_=------ From Ted.Lemon@nominum.com Tue Apr 17 08:56:33 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC5F21F852C for ; Tue, 17 Apr 2012 08:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.504 X-Spam-Level: X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFVO5NpxnaQ3 for ; Tue, 17 Apr 2012 08:56:32 -0700 (PDT) Received: from chip3og119.obsmtp.com (chip3og119.obsmtp.com [64.18.14.87]) by ietfa.amsl.com (Postfix) with ESMTP id 563BC21F8527 for ; Tue, 17 Apr 2012 08:56:32 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by chip3ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKT42Sr/8PA9ISjhuoXoRZs8J9nuDHasLK@postini.com; Tue, 17 Apr 2012 08:56:32 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E3FAE1B835F for ; Tue, 17 Apr 2012 08:56:30 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C1364190064 for ; Tue, 17 Apr 2012 08:56:30 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 17 Apr 2012 08:56:30 -0700 From: Ted Lemon To: DHC WG Thread-Topic: [dhcwg] Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-design-01 Thread-Index: AQHNFdUOdLCpCRiXV0yWYUk8x9pa7w== Date: Tue, 17 Apr 2012 15:56:30 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_A6860A007B104992AFD4363AC1BAB525nominumcom_" MIME-Version: 1.0 Subject: [dhcwg] Fwd: Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-design-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 15:56:33 -0000 --_000_A6860A007B104992AFD4363AC1BAB525nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a reminder, we will determine consensus to adopt this draft on the 24t= h of April. If you want to see it adopted, and haven't said so already, p= lease do. If you don't think the wg should work on it and haven't said so= , please do. Begin forwarded message: From: Ted Lemon > Subject: Re: [dhcwg] Requesting adoption of draft-mrugalski-dhc-dhcpv6-fail= over-design-01 Date: April 10, 2012 10:13:56 AM EDT To: Tomek Mrugalski > Cc: DHC WG > On Apr 8, 2012, at 6:14 PM, Tomek Mrugalski > wrote: I kindly request that we adopt this document as a DHC WG work item. Please consider Tomek's request an official call for adoption. If you ar= e in favor of adopting this as a working group work item, please say so. = If you are against, please say so. We will evaluate consensus to adopt this draft as a working group work item= on April 24. --_000_A6860A007B104992AFD4363AC1BAB525nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <58D83875CAFFDC4B93690E632D53A8A8@nominum.com> Content-Transfer-Encoding: quoted-printable Just a reminder, we will determine consensus to adopt this draft on the 24t= h of April.   If you want to see it adopted, and haven't said so alrea= dy, please do.   If you don't think the wg should work on it and haven= 't said so, please do.

    Begin forwarded message:

    From: Ted L= emon <Ted.Lemon@nominum.com= >
    Subject: Re= : [dhcwg] Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-design= -01
    Date: April= 10, 2012 10:13:56 AM EDT
    To: Tomek= Mrugalski <tomasz.mrugals= ki@gmail.com>
    Cc: DHC W= G <dhcwg@ietf.org>

    On Apr 8, 2012, at 6:14 PM, Tomek Mrugalski <tomasz.mrugalski@gmail.com> wrote:
    I kindly request that we adopt this document as a DHC WG work item.

    Please consider Tomek's request an official call for adoption.   =  If you are in favor of adopting this as a working group work item, pl= ease say so.   If you are against, please say so.

    We will evaluate consensus to adopt this draft as a working group work= item on April 24.  


    --_000_A6860A007B104992AFD4363AC1BAB525nominumcom_-- From kkinnear@cisco.com Tue Apr 17 09:15:23 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4472611E80A3 for ; Tue, 17 Apr 2012 09:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igaha1FYa0o8 for ; Tue, 17 Apr 2012 09:15:19 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E70EE11E8088 for ; Tue, 17 Apr 2012 09:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kkinnear@cisco.com; l=1474; q=dns/txt; s=iport; t=1334679319; x=1335888919; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Ae4D1BB8lb5uvJD9S1shtWN3ZwO2syuuuOtmWAkpIc4=; b=BxdYAh0m3Hb6kkdV+1Q/vcWvvF+tk5hO1GuaZEW/XLM6i7cuRMqRfrS+ mznbn4tiKbIvqHDPhw7ezOVUM+uJ+Xe9ISei39e5fRGVNFYr5gdMs8yCI JyzCeW9pjupacTf6Lm531HzJKlKDIAqOuCguFb5koXPmu1MeTgbv2tSqO I=; X-IronPort-AV: E=Sophos;i="4.75,436,1330905600"; d="scan'208";a="75419197" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 17 Apr 2012 16:15:18 +0000 Received: from [161.44.65.102] ([161.44.65.102]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3HGF3bF032128; Tue, 17 Apr 2012 16:15:04 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Kim Kinnear In-Reply-To: Date: Tue, 17 Apr 2012 12:15:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0E790F85-E713-411D-B8F7-FA9AD227A725@cisco.com> References: To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: DHC WG , Kim Kinnear Subject: Re: [dhcwg] Fwd: Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-design-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:15:23 -0000 I would like to see this adopted as a work item of the DHC WG. I'm always uncertain as to whether to chime in on these things when I'm a co-author of a draft, but I think I was told that doing so is a good idea. Regards -- Kim On Apr 17, 2012, at 11:56 AM, Ted Lemon wrote: > Just a reminder, we will determine consensus to adopt this draft on = the 24th of April. If you want to see it adopted, and haven't said so = already, please do. If you don't think the wg should work on it and = haven't said so, please do. >=20 > Begin forwarded message: >=20 >> From: Ted Lemon >> Subject: Re: [dhcwg] Requesting adoption of = draft-mrugalski-dhc-dhcpv6-failover-design-01 >> Date: April 10, 2012 10:13:56 AM EDT >> To: Tomek Mrugalski >> Cc: DHC WG >>=20 >> On Apr 8, 2012, at 6:14 PM, Tomek Mrugalski = wrote: >>> I kindly request that we adopt this document as a DHC WG work item. >>=20 >> Please consider Tomek's request an official call for adoption. If = you are in favor of adopting this as a working group work item, please = say so. If you are against, please say so. >>=20 >> We will evaluate consensus to adopt this draft as a working group = work item on April 24. =20 >>=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Tue Apr 17 09:19:56 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0497921F845D for ; Tue, 17 Apr 2012 09:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.508 X-Spam-Level: X-Spam-Status: No, score=-106.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4JQLzRWFLah for ; Tue, 17 Apr 2012 09:19:55 -0700 (PDT) Received: from chip3og119.obsmtp.com (chip3og119.obsmtp.com [64.18.14.87]) by ietfa.amsl.com (Postfix) with ESMTP id 0D05F21F845C for ; Tue, 17 Apr 2012 09:19:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by chip3ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKT42YKkXGaHgT2vY0W1OJO7M6SC5o7ibZ@postini.com; Tue, 17 Apr 2012 09:19:55 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 342A01B8352 for ; Tue, 17 Apr 2012 09:19:54 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2BE08190064; Tue, 17 Apr 2012 09:19:54 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 17 Apr 2012 09:19:54 -0700 From: Ted Lemon To: Kim Kinnear Thread-Topic: [dhcwg] Fwd: Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-design-01 Thread-Index: AQHNHLVOvHpilgTHKECzOh/scZgDF5afp8QA Date: Tue, 17 Apr 2012 16:19:53 +0000 Message-ID: <3EDFBB28-0DC4-4E6F-BFD8-315064ED9A1E@nominum.com> References: <0E790F85-E713-411D-B8F7-FA9AD227A725@cisco.com> In-Reply-To: <0E790F85-E713-411D-B8F7-FA9AD227A725@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_3EDFBB280DC44E6FBFD8315064ED9A1Enominumcom_" MIME-Version: 1.0 Cc: DHC WG Subject: Re: [dhcwg] Fwd: Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-design-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:19:56 -0000 --_000_3EDFBB280DC44E6FBFD8315064ED9A1Enominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 17, 2012, at 12:15 PM, Kim Kinnear > wrote: I'm always uncertain as to whether to chime in on these things when I'm a co-author of a draft, but I think I was told that doing so is a good idea. Yes, please. It's a lot of extra work for us to count the authors differe= ntly than other wg participants. --_000_3EDFBB280DC44E6FBFD8315064ED9A1Enominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <708CD08B4F78944D89A25C1FBD0459F8@nominum.com> Content-Transfer-Encoding: quoted-printable
    On Apr 17, 2012, at 12:15 PM, Kim Kinnear <kkinnear@cisco.com>
     wrote:
    I'm always uncertain as to whether to chime in on these things
    when I'm a co-author of a draft, but I think I was told that
    doing so is a good idea.

    Yes, please.   It's a lot of extra work for us to count the autho= rs differently than other wg participants.

    --_000_3EDFBB280DC44E6FBFD8315064ED9A1Enominumcom_-- From Ted.Lemon@nominum.com Tue Apr 17 18:40:21 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED0321F858F for ; Tue, 17 Apr 2012 18:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.512 X-Spam-Level: X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qITpAAeoIRqD for ; Tue, 17 Apr 2012 18:40:21 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id B77BD21F858D for ; Tue, 17 Apr 2012 18:40:19 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKT44bg/cNWfQny4RpQMok7X1G1Z3Mb+0f@postini.com; Tue, 17 Apr 2012 18:40:19 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B3DF91B8360 for ; Tue, 17 Apr 2012 18:40:18 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A98BD190064 for ; Tue, 17 Apr 2012 18:40:18 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 17 Apr 2012 18:40:12 -0700 From: Ted Lemon To: DHC WG Thread-Topic: Call for adoption: draft-jiang-addr-registration Thread-Index: AQHNHQQyZiojdrZahUGpIG8DE28dmg== Date: Wed, 18 Apr 2012 01:40:12 +0000 Message-ID: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3BC52460317DFC449401742C9EB1154E@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] Call for adoption: draft-jiang-addr-registration X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 01:40:22 -0000 (We tentatively adopted quite a few drafts in the meeting, so we're trying = to space out the calls for adoption and last calls a bit=97I hope the autho= rs will bear with us.) The addr-registration draft proposes a mechanism for allowing clients to au= toconfigure their address and then register that address with the DHCP serv= er. At the meeting in Paris, there was strong consensus to adopt this as = a working group item. One of the authors has requested a call for adoptio= n to the mailing list. We already had sufficient consensus in Paris to adopt, but it's possible th= at there are people on the mailing list who were not present in Paris who m= ight object. So for this reason, if you are in favor of adopting the draf= t, even if you raised your hand in Paris, please signify in a reply to this= message. If you are against adopting the draft, please signify as well. We will determine consensus on May 1, 2012. From Dmitry.Anipko@microsoft.com Tue Apr 17 20:29:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E8711E80D3 for ; Tue, 17 Apr 2012 20:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqnkhuX176Fx for ; Tue, 17 Apr 2012 20:29:13 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4999511E80E7 for ; Tue, 17 Apr 2012 20:29:13 -0700 (PDT) Received: from mail33-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Apr 2012 03:29:12 +0000 Received: from mail33-tx2 (localhost [127.0.0.1]) by mail33-tx2-R.bigfish.com (Postfix) with ESMTP id A42D060441 for ; Wed, 18 Apr 2012 03:29:12 +0000 (UTC) X-SpamScore: -24 X-BigFish: VS-24(zz9371Ic85fh98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail33-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail33-tx2 (localhost.localdomain [127.0.0.1]) by mail33-tx2 (MessageSwitch) id 1334719749872200_29521; Wed, 18 Apr 2012 03:29:09 +0000 (UTC) Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.244]) by mail33-tx2.bigfish.com (Postfix) with ESMTP id C4BF5160043 for ; Wed, 18 Apr 2012 03:29:09 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Apr 2012 03:29:08 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 18 Apr 2012 03:29:07 +0000 Received: from mail78-am1-R.bigfish.com (10.3.201.232) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Apr 2012 03:14:24 +0000 Received: from mail78-am1 (localhost [127.0.0.1]) by mail78-am1-R.bigfish.com (Postfix) with ESMTP id 797B142053E for ; Wed, 18 Apr 2012 03:14:24 +0000 (UTC) Received: from mail78-am1 (localhost.localdomain [127.0.0.1]) by mail78-am1 (MessageSwitch) id 1334718862364059_20037; Wed, 18 Apr 2012 03:14:22 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.238]) by mail78-am1.bigfish.com (Postfix) with ESMTP id 545F280049; Wed, 18 Apr 2012 03:14:22 +0000 (UTC) Received: from CH1PRD0310HT001.namprd03.prod.outlook.com (157.56.244.37) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Apr 2012 03:14:22 +0000 Received: from CH1PRD0310MB368.namprd03.prod.outlook.com ([169.254.8.124]) by CH1PRD0310HT001.namprd03.prod.outlook.com ([10.255.137.36]) with mapi id 14.16.0143.004; Wed, 18 Apr 2012 03:14:17 +0000 From: Dmitry Anipko To: Ted Lemon , Francis Dupont Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces Thread-Index: AQHNGnqwWCIjJGLOME2TQFouXNHespaa7cAAgAT/ScA= Date: Wed, 18 Apr 2012 03:14:16 +0000 Message-ID: <96DD85EB136DCD49AB5CDB6DEC9639AD0584DAEC@CH1PRD0310MB368.namprd03.prod.outlook.com> References: <201204142010.q3EKAqwH044161@givry.fdupont.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.100] Content-Type: multipart/alternative; boundary="_000_96DD85EB136DCD49AB5CDB6DEC9639AD0584DAECCH1PRD0310MB368_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NOMINUM.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%FDUPONT.FR$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 03:29:14 -0000 --_000_96DD85EB136DCD49AB5CDB6DEC9639AD0584DAECCH1PRD0310MB368_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >> It does this by broadcasting a DHCPv4 request on the local interface, wh= ich the CRA captures and forwards to the DHCPv4 server over IPv6. Once th= e tunnel is established, renewals are (one assumes) routed down the tunnel. What section of the I-D describes that only the original request goes over = CRA, while renewals are routed to the tunnel? From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Saturday, April 14, 2012 3:53 PM To: Francis Dupont Cc: Peng Wu; dhcwg@ietf.org; Dmitry Anipko Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 int= erfaces On Apr 14, 2012, at 4:10 PM, Francis Dupont > wrote: I am confused: either the tunnels are links (it is a bad idea IMHO but it is not a priori impossible), or they are not links and they don't exist for DHCP. That is not the use case for this draft. The use case for this draft is t= hat a client wants IPv4 support on an IPv6-only network, and so it uses DHC= P to get an address for the tunnel endpoint. It does this by broadcasting= a DHCPv4 request on the local interface, which the CRA captures and forwar= ds to the DHCPv4 server over IPv6. Once the tunnel is established, renewa= ls are (one assumes) routed down the tunnel. But the idea, as I understan= d it at least, is to leverage the existing DHCPv4 client, not to require a = special DHCPv4 client. If we require a special DHCPv4 client, we might as= well just do all the DHCPv4 transactions over UDPv6. --_000_96DD85EB136DCD49AB5CDB6DEC9639AD0584DAECCH1PRD0310MB368_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    >> It does this by broadcasting a DHCPv4 reques= t on the local interface, which the CRA captures and forwards to the DHCPv4= server over IPv6.   Once the tunnel is established, renewals are (one assumes) routed down the tunn= el.

     

    What section of the I-D describes that only the orig= inal request goes over CRA, while renewals are routed to the tunnel?

     

    From: Ted Lemo= n [mailto:Ted.Lemon@nominum.com]
    Sent: Saturday, April 14, 2012 3:53 PM
    To: Francis Dupont
    Cc: Peng Wu; dhcwg@ietf.org; Dmitry Anipko
    Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple i= pv4 interfaces

     

    On Apr 14, 2012, at 4:10 PM, Francis Dupont <Francis.Dupont@fdupont.fr> = wrote:

    I am confused: either the tunnels are= links (it is a bad idea IMHO
    but it is not a priori impossible), or they are not links and they
    don't exist for DHCP.

     

    That is not the use case for this draft.   The = use case for this draft is that a client wants IPv4 support on an IPv6-only= network, and so it uses DHCP to get an address for the tunnel endpoint. &n= bsp; It does this by broadcasting a DHCPv4 request on the local interface, which the CRA captures and forwards to the DHCPv4 = server over IPv6.   Once the tunnel is established, renewals are (one = assumes) routed down the tunnel.   But the idea, as I understand it at= least, is to leverage the existing DHCPv4 client, not to require a special DHCPv4 client.   If we require a spe= cial DHCPv4 client, we might as well just do all the DHCPv4 transactions ov= er UDPv6.

     

    --_000_96DD85EB136DCD49AB5CDB6DEC9639AD0584DAECCH1PRD0310MB368_-- From Dmitry.Anipko@microsoft.com Tue Apr 17 21:25:52 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A3921F846E for ; Tue, 17 Apr 2012 21:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDCy3WpEJ4SS for ; Tue, 17 Apr 2012 21:25:48 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 66D0F21F8469 for ; Tue, 17 Apr 2012 21:25:47 -0700 (PDT) Received: from mail38-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Apr 2012 04:25:46 +0000 Received: from mail38-db3 (localhost [127.0.0.1]) by mail38-db3-R.bigfish.com (Postfix) with ESMTP id 704F324042B for ; Wed, 18 Apr 2012 04:25:46 +0000 (UTC) X-SpamScore: -29 X-BigFish: VS-29(zz9371I542M98dKzz1202hzz1033IL8275dhz2fh2a8h683h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail38-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail38-db3 (localhost.localdomain [127.0.0.1]) by mail38-db3 (MessageSwitch) id 1334723144788972_27233; Wed, 18 Apr 2012 04:25:44 +0000 (UTC) Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.230]) by mail38-db3.bigfish.com (Postfix) with ESMTP id B270460049 for ; Wed, 18 Apr 2012 04:25:44 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Apr 2012 04:25:44 +0000 Received: from db3outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 18 Apr 2012 04:25:41 +0000 Received: from mail75-db3-R.bigfish.com (10.3.81.238) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Apr 2012 04:09:19 +0000 Received: from mail75-db3 (localhost [127.0.0.1]) by mail75-db3-R.bigfish.com (Postfix) with ESMTP id 4EFE21E0141 for ; Wed, 18 Apr 2012 04:09:19 +0000 (UTC) Received: from mail75-db3 (localhost.localdomain [127.0.0.1]) by mail75-db3 (MessageSwitch) id 1334722157798053_8589; Wed, 18 Apr 2012 04:09:17 +0000 (UTC) Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.227]) by mail75-db3.bigfish.com (Postfix) with ESMTP id BFFDCA0328; Wed, 18 Apr 2012 04:09:17 +0000 (UTC) Received: from CH1PRD0310HT002.namprd03.prod.outlook.com (157.56.244.37) by DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Apr 2012 04:09:17 +0000 Received: from CH1PRD0310MB368.namprd03.prod.outlook.com ([169.254.8.124]) by CH1PRD0310HT002.namprd03.prod.outlook.com ([10.255.137.37]) with mapi id 14.16.0143.004; Wed, 18 Apr 2012 04:09:01 +0000 From: Dmitry Anipko To: Francis Dupont , Peng Wu Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces Thread-Index: AQHNG8m0Qh2ivqZkj06nZAjPJcB1Npaf96eA Date: Wed, 18 Apr 2012 04:09:01 +0000 Message-ID: <96DD85EB136DCD49AB5CDB6DEC9639AD0584DBA9@CH1PRD0310MB368.namprd03.prod.outlook.com> References: Your message of Mon, 16 Apr 2012 18:25:37 +0800. <201204161209.q3GC90RH089072@givry.fdupont.fr> In-Reply-To: <201204161209.q3GC90RH089072@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%FDUPONT.FR$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NOMINUM.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 04:25:52 -0000 Peng, it seemed to me at some point there was a consensus between Francis &= you regarding adding clarification that CRA serves only one tunnel interfa= ce and requires a dedicated 4over6 IPv6 address. If that's the case, can su= ch clarification be added to the CRA definition? IMO, that would address the question from the prospective of this I-D. Ther= e would be still question for draft-ietf-softwire-public-4over6, whether sc= enario with multiple 4over6 IPv6 addresses on the same IPv6 interface are s= upported, and if yes - how are they provisioned.=20 draft-ietf-softwire-public-4over6 could also declare such scenario out of s= cope - but having CRA definition clarification in draft-ietf-dhc-dhcpv4-ove= r-ipv6 is still useful, because then draft-ietf-dhc-dhcpv4-over-ipv6 would = not have to change in future should draft-ietf-softwire-public-4over6 defin= e some method for allocation of multiple 4over6 IPv6 addresses. -Dmitry -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of F= rancis Dupont Sent: Monday, April 16, 2012 5:09 AM To: Peng Wu Cc: dhcwg@ietf.org; Ted Lemon; Dmitry Anipko Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 int= erfaces In your previous mail you wrote: > The server could have native IPv4 access, used for receiving unicast > message to server id. =3D> according to my experiments it works only with a physical interface where renews are received, so it can put a constraint on the topology. But I tried only one server and not very hard. > If we want to address this, we could add a RECOMMANDED setense. =3D> RECOMMENDED sentense? Today I am fine with the current wording even I know it won't be always followed in the real world (but the non-compliance is with RFC 2131 so please keep the can of worms closed :-). > I agree this is critical. The only case we may break that is if we > want to solve the problem in this thread when multiple CRAs with > different addresses is unavailable. =3D> different addresses in IPv6 is pretty unlikely, even without multi-interface, so IMHO it is a problem which doesn't need to be addressed. > The reason I insist on the DHCP client for multiple tunnel endpoints > with client IDs =3D> if endpoint stands for a node then there is one client with one interface, so no issue. If it stands for an interface please don't try to assign addresses to virtual interfaces using DHCP. > ... is because we would leave a question mark in the draft > if we raise this problem but only mandate the multiple CRA > solution (i.e., what if multiple v6 address unavailable) =3D> I am not even convinced whether we should have a word about the problem, so of course I strongly object to put more. Regards Francis.Dupont@fdupont.fr PS: I have the draft with some editorial comments in front of me. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From pengwu.thu@gmail.com Tue Apr 17 22:02:05 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F238A21F8484 for ; Tue, 17 Apr 2012 22:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGf2CUSZRAZQ for ; Tue, 17 Apr 2012 22:02:04 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBA021F846A for ; Tue, 17 Apr 2012 22:02:04 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so6411038pbb.31 for ; Tue, 17 Apr 2012 22:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3IlyhPiB0OX3J9tf8qvtKM7rRcmoMr6xsSUSITHxJYs=; b=I3KkzkEy+qGUeU+5+L0Q5shSb8JebtAB9l4mkCuiShmSfaf8sWm2WRvkRSVpYf5l0c 2EWA8//GLa36Ro1CKVYZG5xkTtEaC9QTdvkx2FUH8NYjZ6hGgdSwh86CW0NONGZzN/sW PHMH9i1R8Y31j7KMgw0dg0HE5qCFZmi6qOuhL5iWZOzqSllusppsTeSWJQrriJY3z0d8 dh9EVK3LuU214LYUc7ieWsjpEyIna4KnGtjqHjBsb1LE65JBn20bAceiCyt9CGmqDxhv Dh3QJ66UCCSyqZtO3H/81TLYQPl84GWvSNynNu64tFyb/6XRr6n6ZZIj8An7FxEj2qqP QGOQ== MIME-Version: 1.0 Received: by 10.68.194.136 with SMTP id hw8mr3362432pbc.10.1334725324206; Tue, 17 Apr 2012 22:02:04 -0700 (PDT) Received: by 10.68.213.129 with HTTP; Tue, 17 Apr 2012 22:02:04 -0700 (PDT) In-Reply-To: <96DD85EB136DCD49AB5CDB6DEC9639AD0584DAEC@CH1PRD0310MB368.namprd03.prod.outlook.com> References: <201204142010.q3EKAqwH044161@givry.fdupont.fr> <96DD85EB136DCD49AB5CDB6DEC9639AD0584DAEC@CH1PRD0310MB368.namprd03.prod.outlook.com> Date: Wed, 18 Apr 2012 13:02:04 +0800 Message-ID: From: Peng Wu To: Dmitry Anipko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org" , Francis Dupont , Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 05:02:05 -0000 That would be a result of the server id related texts in section 7. "When filling in the server id option of DHCP replies, the TSV MUST choose an IPv4 address which is reachable from the client once the residual IPv4 serivice is set up." 2012/4/18 Dmitry Anipko : >>> It does this by broadcasting a DHCPv4 request on the local interface, >>> which the CRA captures and forwards to the DHCPv4 server over IPv6. =A0= Once >>> the tunnel is established, renewals are (one assumes) routed down the >>> tunnel. > > > > What section of the I-D describes that only the original request goes ove= r > CRA, while renewals are routed to the tunnel? > > > > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Saturday, April 14, 2012 3:53 PM > To: Francis Dupont > Cc: Peng Wu; dhcwg@ietf.org; Dmitry Anipko > > > Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 > interfaces > > > > On Apr 14, 2012, at 4:10 PM, Francis Dupont > wrote: > > I am confused: either the tunnels are links (it is a bad idea IMHO > but it is not a priori impossible), or they are not links and they > don't exist for DHCP. > > > > That is not the use case for this draft. =A0 The use case for this draft = is > that a client wants IPv4 support on an IPv6-only network, and so it uses > DHCP to get an address for the tunnel endpoint. =A0 It does this by > broadcasting a DHCPv4 request on the local interface, which the CRA captu= res > and forwards to the DHCPv4 server over IPv6. =A0 Once the tunnel is > established, renewals are (one assumes) routed down the tunnel. =A0 But t= he > idea, as I understand it at least, is to leverage the existing DHCPv4 > client, not to require a special DHCPv4 client. =A0 If we require a speci= al > DHCPv4 client, we might as well just do all the DHCPv4 transactions over > UDPv6. > > From pengwu.thu@gmail.com Tue Apr 17 22:31:16 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63CE21F856A for ; Tue, 17 Apr 2012 22:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rja7zhc9p6Hi for ; Tue, 17 Apr 2012 22:31:16 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA9921F8533 for ; Tue, 17 Apr 2012 22:31:16 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so6434622pbb.31 for ; Tue, 17 Apr 2012 22:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FpxZKx+/7xqAXhKLRD5+pRATFDEZV4tWe3A/5zQbdqM=; b=i8QibD/2j22yBce/wosROYLyd6oiyYrrBkjQ7A+YnD/BNYXcl3jRWjbBs+zQYkrBvY sqQ6CBC380Lm038u6ZRgTDT2qErHNPFCqmmgw1NGybZjeye4o0tbCa/62keWqBuJXMu2 m4bOtAOs+DNEc/UjresAh3F6c8FVAfNuI694gwPjKgFUSC1Mj1GZV58wuEHvOLcsNFyY n7Pxw1BpIKtMRqHe2OQAWTYMVLLHGeHZa9nq6hrUVwF/1XNDCSQ+uED3IBoFzrHvkNEy p7x2O61yDTrQGy+N2ISyWDW4Gd8eAVdA2mrq4el4aCGe8bUiO2TxPTMEIDC1ZDOQLOak IQvQ== MIME-Version: 1.0 Received: by 10.68.192.10 with SMTP id hc10mr3509018pbc.31.1334727076043; Tue, 17 Apr 2012 22:31:16 -0700 (PDT) Received: by 10.68.213.129 with HTTP; Tue, 17 Apr 2012 22:31:15 -0700 (PDT) In-Reply-To: <96DD85EB136DCD49AB5CDB6DEC9639AD0584DBA9@CH1PRD0310MB368.namprd03.prod.outlook.com> References: <201204161209.q3GC90RH089072@givry.fdupont.fr> <96DD85EB136DCD49AB5CDB6DEC9639AD0584DBA9@CH1PRD0310MB368.namprd03.prod.outlook.com> Date: Wed, 18 Apr 2012 13:31:15 +0800 Message-ID: From: Peng Wu To: Dmitry Anipko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org" , Francis Dupont , Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 05:31:17 -0000 Dimitry, > Peng, it seemed to me at some point there was a consensus between Francis= & you regarding adding clarification that CRA serves only one tunnel inter= face and requires a dedicated 4over6 IPv6 address. If that's the case, can = such clarification be added to the CRA definition? [Peng]I think we all agree that's the recommanded case. Ted wrote some texts about the solution of modified client with multiple client ID & multiple state machines, to serve mutliple tunnel interfaces (or let's say, to manage multiple address retrieving). It's a detailed description of the corresponding solution discussed in this thread. From technical perspective it can work. The divergence now is, whether to include it in the draft. What's your opinion? > > IMO, that would address the question from the prospective of this I-D. Th= ere would be still question for draft-ietf-softwire-public-4over6, whether = scenario with multiple 4over6 IPv6 addresses on the same IPv6 interface are= supported, and if yes - how are they provisioned. [Peng] In public 4over6, we assume there is only one tunnel on the initiator(as is the same with other 4-over-6 mechanisms). And, if the initiator retrieve the address through DHCP, there would be only one IPv4 address. That's not different from regular DHCP. The problem we have in this thread is caused by multiple tunnel on the device. Thanks for bring it up. I'll state that the 4over6 initiator only run one tunnel/public 4over6 instance in the possible revision. > > draft-ietf-softwire-public-4over6 could also declare such scenario out of= scope - but having CRA definition clarification in draft-ietf-dhc-dhcpv4-o= ver-ipv6 is still useful, because then draft-ietf-dhc-dhcpv4-over-ipv6 woul= d not have to change in future should draft-ietf-softwire-public-4over6 def= ine some method for allocation of multiple 4over6 IPv6 addresses. [Peng]I agree. From tomasz.mrugalski@gmail.com Wed Apr 18 00:25:45 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B73621F85E3 for ; Wed, 18 Apr 2012 00:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEJiUxfI5czq for ; Wed, 18 Apr 2012 00:25:44 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8584721F84F3 for ; Wed, 18 Apr 2012 00:25:44 -0700 (PDT) Received: by bkuw5 with SMTP id w5so6462139bku.31 for ; Wed, 18 Apr 2012 00:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=RFqn7SVYwEiFfCeF4ngs4Ns56dGvS/joLcDE2hrwPjI=; b=ndonrQxWGtsAvCaqs7AiC+GkazIZZ8eMrN/6qnjgMgBXUVZqBvafy8ce7oBDCzsrxJ 8B0EQOwPhzuljiBZk7jTT+1WTa04t03sII7Q/ZP3FFCVuu/Y+eoBHKO92rtFkIiA4NbF ixemwocjpSCt7vB442FewSPaJ30v/jV02GuqpGZVFb07mmTPmffspAAfsSKK6c19XV4X 7Xa+C4mI2xEWmB03pGHvPgR0odsZNIVvK/DX29RPlq01zZ6nNAJukibgnbhYToHVSNMB iSBexUOuQvSmNxvZq1Iv8uT+muMFw/ZkHKK6/9m3geumo4J9Ce3STbpiVvM0sRr4Bqqb LRug== Received: by 10.204.150.78 with SMTP id x14mr321422bkv.114.1334733943630; Wed, 18 Apr 2012 00:25:43 -0700 (PDT) Received: from tomek.local ([178.19.56.23]) by mx.google.com with ESMTPS id iv11sm42139936bkc.16.2012.04.18.00.25.41 (version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 00:25:42 -0700 (PDT) Message-ID: <4F8E6C74.8070109@gmail.com> Date: Wed, 18 Apr 2012 07:25:40 +0000 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ted Lemon References: <0E790F85-E713-411D-B8F7-FA9AD227A725@cisco.com> <3EDFBB28-0DC4-4E6F-BFD8-315064ED9A1E@nominum.com> In-Reply-To: <3EDFBB28-0DC4-4E6F-BFD8-315064ED9A1E@nominum.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: DHC WG , Kim Kinnear Subject: Re: [dhcwg] Fwd: Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-design-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 07:25:45 -0000 On 12-04-17 16:19, Ted Lemon wrote: > Yes, please. It's a lot of extra work for us to count the authors > differently than other wg participants. In that case I support this work as well. Tomek co-author From Francis.Dupont@fdupont.fr Wed Apr 18 00:50:21 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D3321F864E for ; Wed, 18 Apr 2012 00:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5c-jof6k3QrO for ; Wed, 18 Apr 2012 00:50:21 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id E255E21F85E7 for ; Wed, 18 Apr 2012 00:50:18 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3I7oGGS051173; Wed, 18 Apr 2012 09:50:16 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204180750.q3I7oGGS051173@givry.fdupont.fr> From: Francis Dupont To: Dmitry Anipko In-reply-to: Your message of Wed, 18 Apr 2012 03:14:16 -0000. <96DD85EB136DCD49AB5CDB6DEC9639AD0584DAEC@CH1PRD0310MB368.namprd03.prod.outlook.com> Date: Wed, 18 Apr 2012 09:50:16 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 07:50:21 -0000 In your previous mail you wrote: > >> It does this by broadcasting a DHCPv4 request on the local > >> interface, which the CRA captures and forwards to the DHCPv4 > >> server over IPv6. Once the tunnel is established, renewals are > >> (one assumes) routed down the tunnel. > > What section of the I-D describes that only the original request > goes over CRA, while renewals are routed to the tunnel? => none in the I-D but it is the way DHCPv6 works according to RFC 2131, and the text about the DHCPv4 client which stays unmodified. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Wed Apr 18 00:58:49 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D68721F861F for ; Wed, 18 Apr 2012 00:58:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHlAQgDMpLGS for ; Wed, 18 Apr 2012 00:58:49 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 95C5121F850C for ; Wed, 18 Apr 2012 00:58:48 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3I7wkLB051662; Wed, 18 Apr 2012 09:58:46 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204180758.q3I7wkLB051662@givry.fdupont.fr> From: Francis Dupont To: Dmitry Anipko In-reply-to: Your message of Wed, 18 Apr 2012 04:09:01 -0000. <96DD85EB136DCD49AB5CDB6DEC9639AD0584DBA9@CH1PRD0310MB368.namprd03.prod.outlook.com> Date: Wed, 18 Apr 2012 09:58:46 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 07:58:49 -0000 In your previous mail you wrote: > Peng, it seemed to me at some point there was a consensus between > Francis & you regarding adding clarification that CRA serves only > one tunnel interface => no, it serves at most the physical link where tunnel interfaces are seated. Regards Francis.Dupont@fdupont.fr From laurent.thiebaut@alcatel-lucent.com Wed Apr 18 02:32:41 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4E821F8606 for ; Wed, 18 Apr 2012 02:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.648 X-Spam-Level: X-Spam-Status: No, score=-8.648 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kW6gX-1Ouny for ; Wed, 18 Apr 2012 02:32:37 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 663C021F85FD for ; Wed, 18 Apr 2012 02:32:37 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3I9VHai032542 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 18 Apr 2012 11:32:34 +0200 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.37]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 18 Apr 2012 11:32:23 +0200 From: "THIEBAUT, LAURENT (LAURENT)" To: shwethab , "dhcwg@ietf.org" Date: Wed, 18 Apr 2012 11:32:21 +0200 Thread-Topic: Comments on draft-bhandari-dhc-class-based-prefix Thread-Index: Ac0TKg5fU1U46I++QVmuEChI3Dn6DwEVbbMnAHc+9UAA+lSE4A== Message-ID: <170E8FCC2134BD42B539B47798ABF8F0133C417711@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> References: <170E8FCC2134BD42B539B47798ABF8F0133B2C8BBD@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_170E8FCC2134BD42B539B47798ABF8F0133C417711FRMRSSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: Sri Gundavelli Subject: Re: [dhcwg] Comments on draft-bhandari-dhc-class-based-prefix X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 09:32:42 -0000 --_000_170E8FCC2134BD42B539B47798ABF8F0133C417711FRMRSSXCHMBSA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Shwetha any answer? are you interested? Best regards Laurent ALCATEL-LUCENT ________________________________ De : THIEBAUT, LAURENT (LAURENT) Envoy=E9 : vendredi 13 avril 2012 12:05 =C0 : 'shwethab'; dhcwg@ietf.org Cc : Sri Gundavelli Objet : RE: Comments on draft-bhandari-dhc-class-based-prefix Hello Shwetha If you want I can provide you with a written proposal for the modificatio o= f your draft. Best regards Laurent ALCATEL-LUCENT ________________________________ De : shwethab [mailto:shwethab@cisco.com] Envoy=E9 : mercredi 11 avril 2012 03:10 =C0 : THIEBAUT, LAURENT (LAURENT); dhcwg@ietf.org Cc : Sri Gundavelli Objet : Re: Comments on draft-bhandari-dhc-class-based-prefix Hello Laurent, Thanks for the comments. I agree that we need structure to Prefix class option - we could have a a t= ype and value within its content. Type would indicate whether its IETF defi= ned class or Vendor. Based on the type value can then be interpreted, may b= e from a IANA defined name space if it is IETF. I will rework on the struct= ure of the option and update the draft. Regarding including this option in Information request message: if the sema= ntics and content of configuration-information-class option would be same a= s Prefix class, we can rename the Prefix class option suitably or let the s= ame option be used to request configuration from a specific class in inform= ation request as well. Thanks, Shwetha On 4/5/12 6:16 PM, "THIEBAUT, LAURENT (LAURENT)" wrote: Hello Shwetha, hello all As a follow up of the discussion we have had in Paris, please a few comment= s on this very interesting ID 1. As opposed to the "OPTION_USER_CLASS" whose semantics is undefined a= nd whose impact to the system is loosely defined, the new "PREFIX_CLASS opt= ion" allows a well defined structure to ensure inter-operability beyond a c= orporate proprietary usage, i.e. to make sure that different organisations = cannot allocate the same value for the "PREFIX_CLASS option". Indeed the de= finition and structure and indication of usage of the "User Class Option" i= s too loose to guarantee inter-operability beyond a corporate deployment 22.15. User Class Option The User Class option is used by a client to identify the type or category = of user or applications it represents. ... The information contained in the data area of this option is contained in o= ne or more *opaque* fields that represent the user class or classes of whic= h the client is a member. A server selects configuration information for t= he client based on the classes identified in this option. For example, the= User Class option can be used to configure all clients of people in the ac= counting department with a different printer than clients of people in the = marketing department. The user class information carried in this option MUS= T be configurable on the client. ...... (The "User Class Option" can't be used in a non proprietary context as diff= erent organisations can by accident allocate the same value to this informa= tion) This comment is an =AB endorsement" of draft-bhandari-dhc-class-based-prefi= x 2. The "PREFIX_CLASS option" should allow to specify * Prefix-classes defined by IETF * Prefix classes defined by other standard fora * (proprietary) Prefix classes defined by a corporate 3. The proposed structure would be as follows * "Prefix class name space" with 2 values: "IETF" / "other organisation" * "Prefix class owner" (required in case the "Prefix class name space" i= s "other organisation", not present when "Prefix class name space" is "IETF= "). Other organisation may be another standard forum (e.g. BBF) or a corpor= ate. * "Prefix class value" whose structure depends on the "Prefix class name= space" and "Prefix class owner" 4. As the "User Class Option" does not benefit from such structure it c= annot be used beyond a corporate proprietary usage. Thus the "User Class Op= tion" cannot provide an interoperable parameter to be used when a DHCP clie= nt sends an Information-Request message to obtain (IP) configuration inform= ation. Following alternatives may be envisaged: a) Either the "PREFIX_CLASS option" is used in Information-Request. It = is agreed that the name "PREFIX_CLASS option" would then not be well suited= for usage in Information-Request and that thus the name of this option sho= uld be changed. b) Another possibility is to define a "configuration-information-class = option" whose semantics is explicitly made the same as the "PREFIX_CLASS op= tion" and to be used as follows: o The DHCP client puts a "configuration-information-class option"in = Information-Request to request that the IP parameters values sent by the DH= CP server are determined as the most suitable for the IP service associated= with the "configuration-information-class option" o when a DHCPv6 client sends a SOLICIT message to request both * for IA_NA address allocation from a specific prefix class * and to obtain (IP) configuration information using Option Request = option (per RFC 3315 section 22.7) it populates the SOLICIT message as follows: * within the IA_NA option, it includes the OPTION_PREFIX_CLASS reque= sting address to be allocated from a specific prefix class indicated in tha= t option * within the Option Request option (per RFC 3315 section 22.7) it in= cludes the "configuration-information-class option" requesting configuratio= n parameters sent by the DHCP server are determined as the most suitable fo= r the IP service associated with the "configuration-information-class optio= n". If these comments are felt useful, I can provide actual text for the draft. Best regards Laurent --_000_170E8FCC2134BD42B539B47798ABF8F0133C417711FRMRSSXCHMBSA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Comments on draft-bhandari-dhc-class-based-prefix

     

     

    Hello Shwetha

    any answer? are you interested?

    Best regards

    Laurent
    ALCATEL-LUCENT

    De : THIEBAUT= , LAURENT (LAURENT)
    Envoy=E9 : vendredi 13 = avril 2012 12:05
    =C0 : 'shwethab'; dhcwg@ietf.org
    Cc : Sri Gundavelli
    Objet : RE: Comments on draft-bhandari-dhc-class-based-prefix

     

     

     

    Hello Shwetha<= /span>

    If you want I can provide you with a written proposal for the modificatio of your draft.

    Best regards

    Laurent
    ALCATEL-LUCENT

    De : shwethab [mailto:shwethab@cisco.com]
    Envoy=E9 : mercredi 11 = avril 2012 03:10
    =C0 : THIEBAUT, LAURENT (LAURENT); dhcwg@ietf.org
    Cc : Sri Gundavelli
    Objet : Re: Comments on draft-bhandari-dhc-class-based-prefix

     

    Hello Laurent,

    Thanks for the comments.

    I agree that we need structure to Prefix class option – we could have= a a type and value within its content. Type would indicate whether its IETF def= ined class or Vendor. Based on the type value can then be interpreted, may be fr= om a IANA defined name space if it is IETF. I will rework on the structure of th= e  option and update the draft.

    Regarding including this option in Information request message:     if the semantics and content of= configuration-information-class option would= be same as Prefix class, we can rename the Prefix class option suitably or let the = same option be used to request configuration from a specific class in informatio= n request as well.

    Thanks,
    Shwetha


    On 4/5/12 6:16 PM, "THIEBAUT, LAURENT (LAURENT)" <laurent.thiebaut@alcatel-lucen= t.com> wrote:


     
    Hello Sh= wetha, hello all
    As a follow up of the discussion we have had in Paris, please a few comment= s on this very interesting ID
    1.         As opposed to the “OPTION_USER_CLASS” whose semantics is undefin= ed and whose impact to the system is loosely defined, the new “PREFIX_CLASS option” allows a= well defined structure to ensure inter-operability beyond a corporate proprietar= y usage, i.e. to make sure that different organisations cannot allocate the s= ame value for the “PREFIX_CLASS option”. Indeed the definition and struct= ure and indication of usage of the “User Class Option” is too loose to guarantee inter-operability beyond a corporate deployment
    22.15. User Class Option
    The User Class option is used by a client to identify the type or category = of user or applications it represents.
    …
     
    The information contained in the data area of this option is contained in o= ne or more *opaque* fields that represent the user class or classes of which the client is a member.  = A server selects configuration information for the client based on the classe= s identified in this option.  For example, the User Class option can be = used to configure all clients of people in the accounting department with a different printer than clients of people in the marketing department. The u= ser class information carried in this option MUST be configurable on the client= .
       ……
    (The “User Class Option” can’t be used in a non proprietary context as different organisations can by accident allocate the same value = to this information)
    This comment is an =AB endorsement” of draft-bhandari-dhc-class-based-prefix
     
    2.         The “PREFIX_CLASS option” should allow to specify

    • Pre= fix-classes defined by IETF
    • Pre= fix classes defined by other standard fora <= /span>
    • (pr= oprietary) Prefix classes defined by a corporate


     
    3.         The proposed structure would be as follows=

    • = 220;Prefix class name space” with 2 values: “IETF” / “oth= er organisation”
    • = 220;Prefix class owner” (required in case the “Prefix class name space” is “other organisation”, not present when “Prefix class name space” is “IETF”). Other organisation may be another standard forum (e.g. BBF) or a corporate.<= /span>
    • = 220;Prefix class value” whose structure depends on the “Prefix class = name space” and “Prefix class owner”


     
    4.         As the “User Class Option” does not benefit from such structure it cannot be used beyond a corporate proprietary usage. Thus the “User Class Option” cannot provide an interoperable parameter to be used = when a DHCP client sends an Information-Request message to obtain (IP) configura= tion information. Following alternatives may be envisaged:
    a)         Either the “PREFIX_CLASS option” is used in Information-Request. It is agreed that the name “PREFIX_CLASS option” = would then not be well suited for usage in Information-Request and that thus the = name of this option should be changed.
    b)         Another possibility is to define a “= configuration-information-class option” whose semantics is explicitly made= the same as the “PREFIX_CLASS option” and to be used as follows:=
    o<= /font>       The DHCP client  puts a “= configuration-information-class option”in Information-Request to request = that the IP parameters values sent by the DHCP server are determined as the most suitable for the IP service associated with the “= configuration-information-class option”
    o<= /font>       when a DHCPv6 client sends a SOLICIT message to request both<= br> =B7        for IA_NA address allocation from a specific prefix class
    =B7        and to obtain (IP) configuration information u= sing Option Request option (per RFC 3315 section 22.7)
    it populates the SOLICIT message as follows:
    =B7        within the IA_NA option, it includes the OPTION_PREFIX_CLASS requesting address to be allocated from a specific pref= ix class indicated in that option
    =B7        within the Option Request option (per RFC 3315 section 22.7) it includes the <= span style=3D'font-size:11.0pt;font-family:Calibri'>“configuration-information-class option” requesting configuration parameter= s sent by the DHCP server are determined as the most suitable for the IP serv= ice associated with the “configuration-information-class option”.

    If these comments are felt useful, I can provide actual text for the draft.=
    Best regards

    Laurent


     

    --_000_170E8FCC2134BD42B539B47798ABF8F0133C417711FRMRSSXCHMBSA_-- From shwethab@cisco.com Wed Apr 18 02:47:34 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAB721F85F1 for ; Wed, 18 Apr 2012 02:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.833 X-Spam-Level: X-Spam-Status: No, score=-7.833 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtxdelRmk7lm for ; Wed, 18 Apr 2012 02:47:30 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 696AF21F85A0 for ; Wed, 18 Apr 2012 02:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shwethab@cisco.com; l=27668; q=dns/txt; s=iport; t=1334742448; x=1335952048; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=W8qxPw+Ejl/bff/gLl/JOGYSxHzbcxxwhbWwOuuBgdA=; b=XQtT1UiwYBLgVKPBdRPUMK3p+Lyurgtek9ZtrcrBD/0H5KQ4KUDSL6OT frCEcRqsayhxwLJyIqQIhU+an3K9+L7gEzcePTiLgJg4BfZOF8j3Sq0Qx 2WkvpiATLUWeK6iM4D/64vI8srKjAxrmESfQvLNLWtiJazfkvV9xbhbZu k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUGALGMjk9Io8UY/2dsb2JhbAA6CoJGh2OmIXGBCYIJAQEBBBIBKioIChIBCAkPIAdNEQEBBAEKAwUih22ZZKAkimCGCASIKTGFLodnjlAngUKCbw X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208,217";a="10343153" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 18 Apr 2012 09:47:26 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3I9l9VE032411; Wed, 18 Apr 2012 09:47:25 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Apr 2012 15:17:18 +0530 Received: from 173.39.64.24 ([173.39.64.24]) by XMB-BGL-417.cisco.com ([72.163.129.213]) with Microsoft Exchange Server HTTP-DAV ; Wed, 18 Apr 2012 09:47:17 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 18 Apr 2012 15:21:58 +0530 From: shwethab To: "THIEBAUT, LAURENT (LAURENT)" , "dhcwg@ietf.org" Message-ID: Thread-Topic: Comments on draft-bhandari-dhc-class-based-prefix Thread-Index: Ac0TKg5fU1U46I++QVmuEChI3Dn6DwEVbbMnAHc+9UAA+lSE4AAAtHr1 In-Reply-To: <170E8FCC2134BD42B539B47798ABF8F0133C417711@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3417607319_1607614" X-OriginalArrivalTime: 18 Apr 2012 09:47:18.0001 (UTC) FILETIME=[3E14BE10:01CD1D48] Cc: Sri Gundavelli Subject: Re: [dhcwg] Comments on draft-bhandari-dhc-class-based-prefix X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 09:47:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3417607319_1607614 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hello Laurent, Sure, I am working on some of the issues discussed here in the new version. I will be happy to consider your proposed text in the next revision of the draft.=20 Thanks, Shwetha On 4/18/12 3:02 PM, "THIEBAUT, LAURENT (LAURENT)" wrote: > =20 > =20 >=20 > Hello Shwetha >=20 > any answer? are you interested? >=20 > Best regards=20 >=20 > Laurent=20 > ALCATEL-LUCENT=20 >=20 >=20 > De : THIEBAUT, LAURENT (LAURENT) > Envoy=E9 : vendredi 13 avril 2012 12:05 > =C0 : 'shwethab'; dhcwg@ietf.org > Cc : Sri Gundavelli > Objet : RE: Comments on draft-bhandari-dhc-class-based-prefix > =20 > =20 > =20 >=20 > Hello Shwetha >=20 > If you want I can provide you with a written proposal for the modificatio= of > your draft. >=20 > Best regards=20 >=20 > Laurent=20 > ALCATEL-LUCENT=20 >=20 >=20 > De : shwethab [mailto:shwethab@cisco.com] > Envoy=E9 : mercredi 11 avril 2012 03:10 > =C0 : THIEBAUT, LAURENT (LAURENT); dhcwg@ietf.org > Cc : Sri Gundavelli > Objet : Re: Comments on draft-bhandari-dhc-class-based-prefix > =20 > Hello Laurent, >=20 > Thanks for the comments. >=20 > I agree that we need structure to Prefix class option =AD we could have a a= type > and value within its content. Type would indicate whether its IETF define= d > class or Vendor. Based on the type value can then be interpreted, may be = from > a IANA defined name space if it is IETF. I will rework on the structure o= f the > option and update the draft. >=20 > Regarding including this option in Information request message: if the > semantics and content of configuration-information-class option would be = same > as Prefix class, we can rename the Prefix class option suitably or let th= e > same option be used to request configuration from a specific class in > information request as well. >=20 > Thanks, > Shwetha >=20 >=20 > On 4/5/12 6:16 PM, "THIEBAUT, LAURENT (LAURENT)" > wrote: >=20 > =20 > Hello Shwetha, hello all > As a follow up of the discussion we have had in Paris, please a few comme= nts > on this very interesting ID > 1. As opposed to the =B3OPTION_USER_CLASS=B2 whose semantics is undefined= and > whose impact to the system is loosely defined, the new =B3PREFIX_CLASS opti= on=B2 > allows a well defined structure to ensure inter-operability beyond a corp= orate > proprietary usage, i.e. to make sure that different organisations cannot > allocate the same value for the =B3PREFIX_CLASS option=B2. Indeed the definit= ion > and structure and indication of usage of the =B3User Class Option=B2 is too l= oose > to guarantee inter-operability beyond a corporate deployment > 22.15. User Class Option > The User Class option is used by a client to identify the type or categor= y of > user or applications it represents. > =8A > =20 > The information contained in the data area of this option is contained in= one > or more *opaque* fields that represent the user class or classes of which= the > client is a member. A server selects configuration information for the c= lient > based on the classes identified in this option. For example, the User Cl= ass > option can be used to configure all clients of people in the accounting > department with a different printer than clients of people in the marketi= ng > department. The user class information carried in this option MUST be > configurable on the client. > =8A=8A > (The =B3User Class Option=B2 can=B9t be used in a non proprietary context as > different organisations can by accident allocate the same value to this > information) > This comment is an =AB endorsement=B2 of draft-bhandari-dhc-class-based-prefi= x > =20 > 2. The =B3PREFIX_CLASS option=B2 should allow to specify > * Prefix-classes defined by IETF > * Prefix classes defined by other standard fora > * (proprietary) Prefix classes defined by a corporate >=20 > =20 > 3. The proposed structure would be as follows > * =B3Prefix class name space=B2 with 2 values: =B3IETF=B2 / =B3other organisation=B2 > * =B3Prefix class owner=B2 (required in case the =B3Prefix class name space=B2 is > =B3other organisation=B2, not present when =B3Prefix class name space=B2 is =B3IETF= =B2). > Other organisation may be another standard forum (e.g. BBF) or a corporat= e. > * =B3Prefix class value=B2 whose structure depends on the =B3Prefix class name > space=B2 and =B3Prefix class owner=B2 >=20 > =20 > 4. As the =B3User Class Option=B2 does not benefit from such structure it > cannot be used beyond a corporate proprietary usage. Thus the =B3User Class > Option=B2 cannot provide an interoperable parameter to be used when a DHCP > client sends an Information-Request message to obtain (IP) configuration > information. Following alternatives may be envisaged: > a) Either the =B3PREFIX_CLASS option=B2 is used in Information-Request. I= t is > agreed that the name =B3PREFIX_CLASS option=B2 would then not be well suited = for > usage in Information-Request and that thus the name of this option should= be > changed.=20 > b) Another possibility is to define a =B3configuration-information-clas= s > option=B2 whose semantics is explicitly made the same as the =B3PREFIX_CLASS > option=B2 and to be used as follows: > o The DHCP client puts a =B3configuration-information-class option=B2i= n > Information-Request to request that the IP parameters values sent by the = DHCP > server are determined as the most suitable for the IP service associated = with > the =B3configuration-information-class option=B2 > o when a DHCPv6 client sends a SOLICIT message to request both > =B7 for IA_NA address allocation from a specific prefix class > =B7 and to obtain (IP) configuration information using Option Reques= t > option (per RFC 3315 section 22.7) > it populates the SOLICIT message as follows: > =B7 within the IA_NA option, it includes the OPTION_PREFIX_CLASS > requesting address to be allocated from a specific prefix class indicated= in > that option > =B7 within the Option Request option (per RFC 3315 section 22.7) it > includes the =B3configuration-information-class option=B2 requesting configur= ation > parameters sent by the DHCP server are determined as the most suitable fo= r the > IP service associated with the =B3configuration-information-class option=B2. >=20 > If these comments are felt useful, I can provide actual text for the draf= t. > Best regards=20 >=20 > Laurent=20 >=20 >=20 > =20 >=20 --B_3417607319_1607614 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Comments on draft-bhandari-dhc-class-based-prefix Hello Laurent,

    Sure, I am working on some of the issues discussed here in the new version.= I will be happy to consider your proposed text in the next revision of the = draft.

    Thanks,
    Shwetha

    On 4/18/12 3:02 PM, "THIEBAUT, LAURENT (LAURENT)" <laurent.thiebaut@alcatel-lucent.com&g= t; wrote:


     

    Hello Shwetha

    any answer? are you inte= rested?

    Best regards

    Laurent
    ALCATEL-LUCENT

    De : THIEBAUT, LAURENT (LAURENT)
    Envoyé : vendredi 13 avril 2012 12:05
    À : 'shwethab'; dhcwg@ietf.org Cc : Sri Gundavelli
    Objet : RE: Comments on draft-bhandari-dhc-class-based-prefix

     

    Hello Shwetha

    If you want I can provid= e you with a written proposal for the modificatio of your draft.

    Best regards

    Laurent
    ALCATEL-LUCENT

    De : shwethab [ma= ilto:shwethab@cisco.com]
    Envoyé : mercredi 11 avril 2012 03:10
    À : THIEBAUT, LAURENT (LAURENT); dhc= wg@ietf.org
    Cc : Sri Gundavelli
    Objet : Re: Comments on draft-bhandari-dhc-class-based-prefix
    Hello Laurent,

    Thanks for the comments.

    I agree that we need structure to Prefix class option – we could have= a a type and value within its content. Type would indicate whether its IETF= defined class or Vendor. Based on the type value can then be interpreted, m= ay be from a IANA defined name space if it is IETF. I will rework on the str= ucture of the  option and update the draft.

    Regarding including this option in Information request message:     if = the semantics and content of configuration-inf= ormation-class option would be same as Prefix c= lass, we can rename the Prefix class option suitably or let the same option = be used to request configuration from a specific class in information reques= t as well.

    Thanks,
    Shwetha


    On 4/5/12 6:16 PM, "THIEBAUT, LAURENT (LAURENT)" <laurent.thiebaut@alcatel-lucent.com>= ; wrote:

     
    Hello Shwetha, hello all
    As a follow up of the discussion we have had in Paris, please a few comment= s on this very interesting ID
    1.         As opposed to the “    OPTION_USER_CLASS” whose semantics is undefined and whose impact to the s= ystem is loosely defined, the new “PREFIX_CLASS option” allows a well defined structure to ensure inter-operabili= ty beyond a corporate proprietary usage, i.e. to make sure that different or= ganisations cannot allocate the same value for the “PREFIX_CLASS option”    . Indeed the definition and structure and= indication of usage of the “    User Class O= ption” is too loose to guarantee inter-o= perability beyond a corporate deployment
    22.15. User Class Option
    The User Class option is used by a client to identify the type or category = of user or applications it represents.
    …
     
    The information contained in the data area of this option is contained in o= ne or more *opaque* fields that represent the user class or classes o= f which the client is a member.  A server selects configuration informa= tion for the client based on the classes identified in this option.  Fo= r example, the User Class option can be used to configure all clients of peo= ple in the accounting department with a different printer than clients of pe= ople in the marketing department. The user class information carried in this= option MUST be configurable on the client.
       ……
    (The “User Cla= ss Option” can’t be used in a non proprietary context as differe= nt organisations can by accident allocate the same value to this information= )
    This comment is an « endorsement” of draft-bhandari-dhc-class-b= ased-prefix
     
    2.         The “    PREFIX_CLASS optionPrefix-classes defined = by IETF=20

  • Prefix classes defined by other standard = fora=20
  • (proprietary) Prefix classes defined by a= corporate

     
    3.     =     The proposed struct= ure would be as follows
    • “Prefix class nam= e space” with 2 values: “IETF” / “other organisation= ”=20
    • “Prefix class owner” (require= d in case the “Prefix class name space” is “other organisa= tion”, not present when “Prefix class name space” is ̶= 0;IETF”). Other organisation may be another standard forum (e.g. BBF) = or a corporate.=20
    • “Prefix class value” whose st= ructure depends on the “Prefix class name space” and “Pref= ix class owner”

     
    4.     =     As the “    User Class Option̶= 1; does not benefit from such structure it cannot be used beyond a corporate= proprietary usage. Thus the “User Class = Option” cannot provide an interoperable = parameter to be used when a DHCP client sends an Information-Request message= to obtain (IP) configuration information. Following alternatives may be envisaged:
    a)     =     Either the “<= /FONT>    PREFIX_CLASS option” is used in Information-Request. It is agr= eed that the name “PRE= FIX_CLASS option̶= 1; would then not be well suited for usage in Information-Request and that t= hus the name of this option should be changed.
    b)         Another possibility is to define a     “configuration-information-class option” w= hose semantics is explicitly made the same as the “PREFIX= _CLASS option” = and to be used as follows:
    o  = ;     The DHCP cli= ent  puts a     “configuration-i= nformation-class option&#= 8221;    in Information-Request to request that th= e IP parameters values sent by the DHCP server are determined as the most su= itable for the IP service associated with the &= #8220;    configuration-information-class o= ption”
    o       when a DHCPv6 client sends a SOLICIT message to request= both
    · &nb= sp;      for = IA_NA address allocation from a specific prefix class
    · &nb= sp;      and = to obtain (IP) configuration information using Option Request option (per RF= C 3315 section 22.7)
    it populates the SOLICIT message as follows:
    · &nb= sp;      with= in the IA_NA option, it includes the OPTION_PREFIX_CLASS requesting address = to be allocated from a specific prefix class indicated in that option
    · &nb= sp;      with= in the Option Request option (per RFC 3315 section 22.7) it includes the     “configuration-information-class option    ” = requesting configuration parameters sent by the DHCP server = are determined as the most suitable for the IP service associated with the <= /SPAN><= SPAN STYLE=3D'font-size:11pt'>“configuration-information-class option    ”.
    Best regar= ds

    Laurent


     

    • --B_3417607319_1607614-- From Ted.Lemon@nominum.com Wed Apr 18 05:48:50 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D485721F8570 for ; Wed, 18 Apr 2012 05:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.515 X-Spam-Level: X-Spam-Status: No, score=-106.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nyp6+13xvzPr for ; Wed, 18 Apr 2012 05:48:50 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id F0EF621F8542 for ; Wed, 18 Apr 2012 05:48:49 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKT464MT4RojgN3FfNstvZo/YCzYOyrIPZ@postini.com; Wed, 18 Apr 2012 05:48:50 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D133F1B833F for ; Wed, 18 Apr 2012 05:48:48 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id BFDBA190064; Wed, 18 Apr 2012 05:48:48 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Wed, 18 Apr 2012 05:48:48 -0700 From: Ted Lemon To: Dmitry Anipko Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces Thread-Index: AQHNGnqwATEkr4Y99kO4fhiXxhzO0pabYxkAgAT/9gCAAKCFgA== Date: Wed, 18 Apr 2012 12:48:48 +0000 Message-ID: References: <201204142010.q3EKAqwH044161@givry.fdupont.fr> <96DD85EB136DCD49AB5CDB6DEC9639AD0584DAEC@CH1PRD0310MB368.namprd03.prod.outlook.com> In-Reply-To: <96DD85EB136DCD49AB5CDB6DEC9639AD0584DAEC@CH1PRD0310MB368.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_C13EA6E0D53E4EBEBE1ED1D1228E2602nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Francis Dupont Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 12:48:50 -0000 --_000_C13EA6E0D53E4EBEBE1ED1D1228E2602nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Apr 17, 2012, at 11:14 PM, Dmitry Anipko > wrote: What section of the I-D describes that only the original request goes over = CRA, while renewals are routed to the tunnel? I don't think that's ever stated. That's just how DHCP works=97broadcast = messages are relayed; unicast messages are routed. --_000_C13EA6E0D53E4EBEBE1ED1D1228E2602nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2A79172E7DE05E40AC7D1F493FE3F559@nominum.com> Content-Transfer-Encoding: quoted-printable
    On Apr 17, 2012, at 11:14 PM, Dmitry Anipko <Dmitry.Anipko@microsoft.com> wrote:
    To: "THIEBAUT, LAURENT (LAURENT)" , shwethab , "dhcwg@ietf.org" Message-ID: Thread-Topic: Comments on draft-bhandari-dhc-class-based-prefix Thread-Index: Ac0TKg5fU1U46I++QVmuEChI3Dn6DwEVbbMnAHc+9UAA+lSE4AAKtMvV In-Reply-To: <170E8FCC2134BD42B539B47798ABF8F0133C417711@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3417579503_100083419" X-OriginalArrivalTime: 18 Apr 2012 14:38:39.0784 (UTC) FILETIME=[F2092280:01CD1D70] Subject: Re: [dhcwg] Comments on draft-bhandari-dhc-class-based-prefix X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:38:45 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3417579503_100083419 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Laurant, Thanks for your response and also review of the document. We will go over this comments and update/respond. Best Regards Sri On 4/18/12 2:32 AM, "THIEBAUT, LAURENT (LAURENT)" wrote: > =20 > =20 >=20 > Hello Shwetha >=20 > any answer? are you interested? >=20 > Best regards=20 >=20 > Laurent=20 > ALCATEL-LUCENT=20 >=20 >=20 > De : THIEBAUT, LAURENT (LAURENT) > Envoy=E9 : vendredi 13 avril 2012 12:05 > =C0 : 'shwethab'; dhcwg@ietf.org > Cc : Sri Gundavelli > Objet : RE: Comments on draft-bhandari-dhc-class-based-prefix > =20 > =20 > =20 >=20 > Hello Shwetha >=20 > If you want I can provide you with a written proposal for the modificatio= of > your draft. >=20 > Best regards=20 >=20 > Laurent=20 > ALCATEL-LUCENT=20 >=20 >=20 > De : shwethab [mailto:shwethab@cisco.com] > Envoy=E9 : mercredi 11 avril 2012 03:10 > =C0 : THIEBAUT, LAURENT (LAURENT); dhcwg@ietf.org > Cc : Sri Gundavelli > Objet : Re: Comments on draft-bhandari-dhc-class-based-prefix > =20 > Hello Laurent, >=20 > Thanks for the comments. >=20 > I agree that we need structure to Prefix class option =AD we could have a a= type > and value within its content. Type would indicate whether its IETF define= d > class or Vendor. Based on the type value can then be interpreted, may be = from > a IANA defined name space if it is IETF. I will rework on the structure o= f the > option and update the draft. >=20 > Regarding including this option in Information request message: if the > semantics and content of configuration-information-class option would be = same > as Prefix class, we can rename the Prefix class option suitably or let th= e > same option be used to request configuration from a specific class in > information request as well. >=20 > Thanks, > Shwetha >=20 >=20 > On 4/5/12 6:16 PM, "THIEBAUT, LAURENT (LAURENT)" > wrote: >=20 > =20 > Hello Shwetha, hello all > As a follow up of the discussion we have had in Paris, please a few comme= nts > on this very interesting ID > 1. As opposed to the =B3OPTION_USER_CLASS=B2 whose semantics is undefined= and > whose impact to the system is loosely defined, the new =B3PREFIX_CLASS opti= on=B2 > allows a well defined structure to ensure inter-operability beyond a corp= orate > proprietary usage, i.e. to make sure that different organisations cannot > allocate the same value for the =B3PREFIX_CLASS option=B2. Indeed the definit= ion > and structure and indication of usage of the =B3User Class Option=B2 is too l= oose > to guarantee inter-operability beyond a corporate deployment > 22.15. User Class Option > The User Class option is used by a client to identify the type or categor= y of > user or applications it represents. > =8A > =20 > The information contained in the data area of this option is contained in= one > or more *opaque* fields that represent the user class or classes of which= the > client is a member. A server selects configuration information for the c= lient > based on the classes identified in this option. For example, the User Cl= ass > option can be used to configure all clients of people in the accounting > department with a different printer than clients of people in the marketi= ng > department. The user class information carried in this option MUST be > configurable on the client. > =8A=8A > (The =B3User Class Option=B2 can=B9t be used in a non proprietary context as > different organisations can by accident allocate the same value to this > information) > This comment is an =AB endorsement=B2 of draft-bhandari-dhc-class-based-prefi= x > =20 > 2. The =B3PREFIX_CLASS option=B2 should allow to specify > * Prefix-classes defined by IETF > * Prefix classes defined by other standard fora > * (proprietary) Prefix classes defined by a corporate >=20 > =20 > 3. The proposed structure would be as follows > * =B3Prefix class name space=B2 with 2 values: =B3IETF=B2 / =B3other organisation=B2 > * =B3Prefix class owner=B2 (required in case the =B3Prefix class name space=B2 is > =B3other organisation=B2, not present when =B3Prefix class name space=B2 is =B3IETF= =B2). > Other organisation may be another standard forum (e.g. BBF) or a corporat= e. > * =B3Prefix class value=B2 whose structure depends on the =B3Prefix class name > space=B2 and =B3Prefix class owner=B2 >=20 > =20 > 4. As the =B3User Class Option=B2 does not benefit from such structure it > cannot be used beyond a corporate proprietary usage. Thus the =B3User Class > Option=B2 cannot provide an interoperable parameter to be used when a DHCP > client sends an Information-Request message to obtain (IP) configuration > information. Following alternatives may be envisaged: > a) Either the =B3PREFIX_CLASS option=B2 is used in Information-Request. I= t is > agreed that the name =B3PREFIX_CLASS option=B2 would then not be well suited = for > usage in Information-Request and that thus the name of this option should= be > changed.=20 > b) Another possibility is to define a =B3configuration-information-clas= s > option=B2 whose semantics is explicitly made the same as the =B3PREFIX_CLASS > option=B2 and to be used as follows: > o The DHCP client puts a =B3configuration-information-class option=B2i= n > Information-Request to request that the IP parameters values sent by the = DHCP > server are determined as the most suitable for the IP service associated = with > the =B3configuration-information-class option=B2 > o when a DHCPv6 client sends a SOLICIT message to request both > =B7 for IA_NA address allocation from a specific prefix class > =B7 and to obtain (IP) configuration information using Option Reques= t > option (per RFC 3315 section 22.7) > it populates the SOLICIT message as follows: > =B7 within the IA_NA option, it includes the OPTION_PREFIX_CLASS > requesting address to be allocated from a specific prefix class indicated= in > that option > =B7 within the Option Request option (per RFC 3315 section 22.7) it > includes the =B3configuration-information-class option=B2 requesting configur= ation > parameters sent by the DHCP server are determined as the most suitable fo= r the > IP service associated with the =B3configuration-information-class option=B2. >=20 > If these comments are felt useful, I can provide actual text for the draf= t. > Best regards=20 >=20 > Laurent=20 >=20 >=20 > =20 >=20 --B_3417579503_100083419 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Comments on draft-bhandari-dhc-class-based-prefix Hi Laurant,

    Thanks for your response and also review of the document. We will go over t= his comments and update/respond.


    Best Regards
    Sri



    On 4/18/12 2:32 AM, "THIEBAUT, LAURENT (LAURENT)" <laurent.thiebaut@alcatel-lucent.com&g= t; wrote:


     

    Hello Shwetha

    any answer? are you inte= rested?

    Best regards

    Laurent
    ALCATEL-LUCENT

    De : THIEBAUT, LAURENT (LAURENT)
    Envoyé : vendredi 13 avril 2012 12:05
    À : 'shwethab'; dhcwg@ietf.org Cc : Sri Gundavelli
    Objet : RE: Comments on draft-bhandari-dhc-class-based-prefix

     

    Hello Shwetha

    If you want I can provid= e you with a written proposal for the modificatio of your draft.

    Best regards

    Laurent
    ALCATEL-LUCENT

    De : shwethab [ma= ilto:shwethab@cisco.com]
    Envoyé : mercredi 11 avril 2012 03:10
    À : THIEBAUT, LAURENT (LAURENT); dhc= wg@ietf.org
    Cc : Sri Gundavelli
    Objet : Re: Comments on draft-bhandari-dhc-class-based-prefix
    Hello Laurent,

    Thanks for the comments.

    I agree that we need structure to Prefix class option – we could have= a a type and value within its content. Type would indicate whether its IETF= defined class or Vendor. Based on the type value can then be interpreted, m= ay be from a IANA defined name space if it is IETF. I will rework on the str= ucture of the  option and update the draft.

    Regarding including this option in Information request message:     if = the semantics and content of configuration-inf= ormation-class option would be same as Prefix c= lass, we can rename the Prefix class option suitably or let the same option = be used to request configuration from a specific class in information reques= t as well.

    Thanks,
    Shwetha


    On 4/5/12 6:16 PM, "THIEBAUT, LAURENT (LAURENT)" <laurent.thiebaut@alcatel-lucent.com>= ; wrote:

     
    Hello Shwetha, hello all
    As a follow up of the discussion we have had in Paris, please a few comment= s on this very interesting ID
    1.         As opposed to the “    OPTION_USER_CLASS” whose semantics is undefined and whose impact to the s= ystem is loosely defined, the new “PREFIX_CLASS option” allows a well defined structure to ensure inter-operabili= ty beyond a corporate proprietary usage, i.e. to make sure that different or= ganisations cannot allocate the same value for the “PREFIX_CLASS option”    . Indeed the definition and structure and= indication of usage of the “    User Class O= ption” is too loose to guarantee inter-o= perability beyond a corporate deployment
    22.15. User Class Option
    The User Class option is used by a client to identify the type or category = of user or applications it represents.
    …
     
    The information contained in the data area of this option is contained in o= ne or more *opaque* fields that represent the user class or classes o= f which the client is a member.  A server selects configuration informa= tion for the client based on the classes identified in this option.  Fo= r example, the User Class option can be used to configure all clients of peo= ple in the accounting department with a different printer than clients of pe= ople in the marketing department. The user class information carried in this= option MUST be configurable on the client.
       ……
    (The “User Cla= ss Option” can’t be used in a non proprietary context as differe= nt organisations can by accident allocate the same value to this information= )
    This comment is an « endorsement” of draft-bhandari-dhc-class-b= ased-prefix
     
    2.         The “    PREFIX_CLASS optionPrefix-classes defined = by IETF=20

  • Prefix classes defined by other standard = fora=20
  • (proprietary) Prefix classes defined by a= corporate

     
    3.     =     The proposed struct= ure would be as follows
    • “Prefix class nam= e space” with 2 values: “IETF” / “other organisation= ”=20
    • “Prefix class owner” (require= d in case the “Prefix class name space” is “other organisa= tion”, not present when “Prefix class name space” is ̶= 0;IETF”). Other organisation may be another standard forum (e.g. BBF) = or a corporate.=20
    • “Prefix class value” whose st= ructure depends on the “Prefix class name space” and “Pref= ix class owner”

     
    4.     =     As the “    User Class Option̶= 1; does not benefit from such structure it cannot be used beyond a corporate= proprietary usage. Thus the “User Class = Option” cannot provide an interoperable = parameter to be used when a DHCP client sends an Information-Request message= to obtain (IP) configuration information. Following alternatives may be envisaged:
    a)     =     Either the “<= /FONT>    PREFIX_CLASS option” is used in Information-Request. It is agr= eed that the name “PRE= FIX_CLASS option̶= 1; would then not be well suited for usage in Information-Request and that t= hus the name of this option should be changed.
    b)         Another possibility is to define a     “configuration-information-class option” w= hose semantics is explicitly made the same as the “PREFIX= _CLASS option” = and to be used as follows:
    o  = ;     The DHCP cli= ent  puts a     “configuration-i= nformation-class option&#= 8221;    in Information-Request to request that th= e IP parameters values sent by the DHCP server are determined as the most su= itable for the IP service associated with the &= #8220;    configuration-information-class o= ption”
    o       when a DHCPv6 client sends a SOLICIT message to request= both
    · &nb= sp;      for = IA_NA address allocation from a specific prefix class
    · &nb= sp;      and = to obtain (IP) configuration information using Option Request option (per RF= C 3315 section 22.7)
    it populates the SOLICIT message as follows:
    · &nb= sp;      with= in the IA_NA option, it includes the OPTION_PREFIX_CLASS requesting address = to be allocated from a specific prefix class indicated in that option
    · &nb= sp;      with= in the Option Request option (per RFC 3315 section 22.7) it includes the     “configuration-information-class option    ” = requesting configuration parameters sent by the DHCP server = are determined as the most suitable for the IP service associated with the <= /SPAN><= SPAN STYLE=3D'font-size:11pt'>“configuration-information-class option    ”.
    Best regar= ds

    Laurent


     

    • --B_3417579503_100083419-- From Dmitry.Anipko@microsoft.com Wed Apr 18 15:23:03 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D3711E809F for ; Wed, 18 Apr 2012 15:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO9iMS4gBTTX for ; Wed, 18 Apr 2012 15:23:03 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id A94FD11E809D for ; Wed, 18 Apr 2012 15:23:02 -0700 (PDT) Received: from mail24-am1-R.bigfish.com (10.3.201.234) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Apr 2012 22:23:01 +0000 Received: from mail24-am1 (localhost [127.0.0.1]) by mail24-am1-R.bigfish.com (Postfix) with ESMTP id 58FA71806CF for ; Wed, 18 Apr 2012 22:23:01 +0000 (UTC) X-SpamScore: -29 X-BigFish: VS-29(zz9371I542M98dKzz1202hzz1033ILz2fh2a8h683h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail24-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail24-am1 (localhost.localdomain [127.0.0.1]) by mail24-am1 (MessageSwitch) id 1334787771931765_32243; Wed, 18 Apr 2012 22:22:51 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.251]) by mail24-am1.bigfish.com (Postfix) with ESMTP id DD3EB36034B for ; Wed, 18 Apr 2012 22:22:51 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Apr 2012 22:22:50 +0000 Received: from CH1EHSOBE011.bigfish.com (157.54.51.80) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 18 Apr 2012 22:22:34 +0000 Received: from mail194-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Apr 2012 22:21:56 +0000 Received: from mail194-ch1 (localhost [127.0.0.1]) by mail194-ch1-R.bigfish.com (Postfix) with ESMTP id 333D23C0453 for ; Wed, 18 Apr 2012 22:21:56 +0000 (UTC) Received: from mail194-ch1 (localhost.localdomain [127.0.0.1]) by mail194-ch1 (MessageSwitch) id 1334787713872187_11030; Wed, 18 Apr 2012 22:21:53 +0000 (UTC) Received: from CH1EHSMHS005.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail194-ch1.bigfish.com (Postfix) with ESMTP id C6F64A008C; Wed, 18 Apr 2012 22:21:53 +0000 (UTC) Received: from CH1PRD0310HT002.namprd03.prod.outlook.com (157.56.244.37) by CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Apr 2012 22:21:53 +0000 Received: from CH1PRD0310MB368.namprd03.prod.outlook.com ([169.254.8.5]) by CH1PRD0310HT002.namprd03.prod.outlook.com ([10.255.137.37]) with mapi id 14.16.0143.004; Wed, 18 Apr 2012 22:21:52 +0000 From: Dmitry Anipko To: "Francis.Dupont@fdupont.fr" Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces Thread-Index: AQHNHTkUWCIjJGLOME2TQFouXNHespahJvXQ Date: Wed, 18 Apr 2012 22:21:52 +0000 Message-ID: <96DD85EB136DCD49AB5CDB6DEC9639AD058503A1@CH1PRD0310MB368.namprd03.prod.outlook.com> References: Your message of Wed, 18 Apr 2012 04:09:01 -0000. <96DD85EB136DCD49AB5CDB6DEC9639AD0584DBA9@CH1PRD0310MB368.namprd03.prod.outlook.com> <201204180758.q3I7wkLB051662@givry.fdupont.fr> In-Reply-To: <201204180758.q3I7wkLB051662@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%FDUPONT.FR$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NOMINUM.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 22:23:03 -0000 Per the definitions in the latest draft: "Client Relay Agent(CRA) - sits on the same, IPv6-accessable host with the = DHCPv4 client" " (LCRA): a CRA sits on the link of the host rather then inside the host". I specifically was referring to this CRA definition, where CRA serves the D= HCPv4 client of the host (and that DHCPv4, I assumed, acts on a tunnel inte= rface).=20 If you want the proposed definition to read as "CRA can serve no more than = one tunnel interface", while "LCRA can serve no more than one link", that's= fine with me. -Dmitry -----Original Message----- From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20 Sent: Wednesday, April 18, 2012 12:59 AM To: Dmitry Anipko Cc: Peng Wu; dhcwg@ietf.org; Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 int= erfaces=20 In your previous mail you wrote: > Peng, it seemed to me at some point there was a consensus between > Francis & you regarding adding clarification that CRA serves only > one tunnel interface =3D> no, it serves at most the physical link where tunnel interfaces are seated. Regards Francis.Dupont@fdupont.fr From tomasz.mrugalski@gmail.com Wed Apr 18 16:38:46 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE25D11E808C for ; Wed, 18 Apr 2012 16:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0KeS62yFDn5 for ; Wed, 18 Apr 2012 16:38:46 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC0621F84AA for ; Wed, 18 Apr 2012 16:38:45 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so5441417wgb.13 for ; Wed, 18 Apr 2012 16:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=qyGzFaYgnOIRPAUPFI4RAL9MAhv0xZbJrXUKGiXpRYc=; b=y2g6o9jyNVJCul17X6H/JCsmJg7+iWJNGrvV9SV2/d5IBsv+ITwejjpN7ZR8PXGiuG D+PLIsFeNj4s56J49XQoeT4/Hp7nYAXrDHLZdNCjOW36Kt/Qhpd9BEkUfWRhUEbFybVy a40HD4f8uue3N5KOX9xsk19lplv9XQW+/D1Kj4Fxt5L+o789ITdlVidAIPirrOZ9EYUp P19qdvSd3IT93MpyFFYyNhejPSYTHkKmWLLPJQGzNV2HIiNvoFI7bJgcTeRad1Jkc/0d NspmjITYQOGc1mVkkoYwZkS1nB6bqjRix40tz5VYOOniIhchOBmOFyqcVezp9Aw6U9hl lt4g== Received: by 10.180.81.135 with SMTP id a7mr21158020wiy.16.1334792325274; Wed, 18 Apr 2012 16:38:45 -0700 (PDT) Received: from tomek.local (pool1.hatidni.is. [212.30.216.30]) by mx.google.com with ESMTPS id gg2sm1514415wib.7.2012.04.18.16.38.43 (version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 16:38:44 -0700 (PDT) Message-ID: <4F8F5082.8090804@gmail.com> Date: Wed, 18 Apr 2012 23:38:42 +0000 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dhcwg@ietf.org References: <0DB4E514-A0A0-4F15-ACD2-BD5C6F7477BE@nominum.com> In-Reply-To: <0DB4E514-A0A0-4F15-ACD2-BD5C6F7477BE@nominum.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Fwd: Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 23:38:47 -0000 On 12-04-16 15:24, Ted Lemon wrote: > Reminder, we're halfway through the last call period for this document. > We've gotten a good response, so there's no need to respond if you > aren't that interested, but if you are interested and haven't responded, > please do. Ted, I would love to see this document progress fast, but I thought that we are in the process of adoption, not last call. Tomek From internet-drafts@ietf.org Wed Apr 18 18:50:53 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FF111E80AF; Wed, 18 Apr 2012 18:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLcIQAv-N-C7; Wed, 18 Apr 2012 18:50:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AEA21F844B; Wed, 18 Apr 2012 18:50:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120419015048.15731.74537.idtracker@ietfa.amsl.com> Date: Wed, 18 Apr 2012 18:50:48 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-reconfigure-rebind-10.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 01:50:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : Rebind Capability in DHCPv6 Reconfigure Messages Author(s) : D. R. Evans Ralph Droms Sheng Jiang Filename : draft-ietf-dhc-dhcpv6-reconfigure-rebind-10.txt Pages : 11 Date : 2012-04-18 This document updates RFC 3315 (DHCPv6) to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message. It extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebin= d-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebind= -10.txt From Ted.Lemon@nominum.com Wed Apr 18 19:35:09 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7BA11E80B7 for ; Wed, 18 Apr 2012 19:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YP1n9XxMPh-x for ; Wed, 18 Apr 2012 19:35:09 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id D7A6911E80B5 for ; Wed, 18 Apr 2012 19:35:08 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKT4953EAavPvu30+dPfOQ0QAaBwKLdDhJ@postini.com; Wed, 18 Apr 2012 19:35:08 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A38BC1B8328 for ; Wed, 18 Apr 2012 19:35:07 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 968B919006D; Wed, 18 Apr 2012 19:35:07 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Wed, 18 Apr 2012 19:35:07 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [dhcwg] Fwd: Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item Thread-Index: AQHNHbxqsJ6s/hzD+EyPMPLDnQW0v5ah4+6A Date: Thu, 19 Apr 2012 02:35:06 +0000 Message-ID: References: <0DB4E514-A0A0-4F15-ACD2-BD5C6F7477BE@nominum.com> <4F8F5082.8090804@gmail.com> In-Reply-To: <4F8F5082.8090804@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_AE66AE70D26D4ED481F661C1FF87DCF0nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Fwd: Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 02:35:10 -0000 --_000_AE66AE70D26D4ED481F661C1FF87DCF0nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 18, 2012, at 7:38 PM, Tomek Mrugalski > wrote: I would love to see this document progress fast, but I thought that we are in the process of adoption, not last call. Oops, yes, sorry. --_000_AE66AE70D26D4ED481F661C1FF87DCF0nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <97FB4C4CE9936144B1AE56DD1580FBE9@nominum.com> Content-Transfer-Encoding: quoted-printable
    On Apr 18, 2012, at 7:38 PM, Tomek Mrugalski <tomasz.mrugalski@gmail.com> wrote:
    I would love to see this document progress fast, but I thought that we
    are in the process of adoption, not last call.

    Oops, yes, sorry.

    --_000_AE66AE70D26D4ED481F661C1FF87DCF0nominumcom_-- From pengwu.thu@gmail.com Wed Apr 18 21:03:04 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A2911E80B5 for ; Wed, 18 Apr 2012 21:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQNvw1hdb+iV for ; Wed, 18 Apr 2012 21:03:00 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A10AC11E807F for ; Wed, 18 Apr 2012 21:03:00 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so7673158pbb.31 for ; Wed, 18 Apr 2012 21:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=JBdLOwq4RsjQV2WqLkUCgnsUwoOPFsZLU25GWdwdw44=; b=X5cYUdAL2HMvTLrocefoesTrYAF03lwY+4M6cKZDUHAFv0nwRHpUYFTeiMo+W/EtaQ kPzGIBBjCn2B/iIxT2LJd/cFsPXNLuDJhvK9Z8oTjUdrSk5l0TZAMRBQh87Kmtemkk20 NufD8LnOlO6xxhDQqb9oQQObndjfewWVNSgi87OXRM4up1FlSPtQ5t2yEsJ9LG/eOIq0 dWRKrR3R0fZDLXLxa6MGMX1/FHb3iqvtnyib439UbpyRO7rxd5m15BY4onrre9fBaz9U OBUs7LdLua6Yx8tTQbSGao2lVE6+t+IjGoIvys0xTBQF6J1qLnEGWrS8aSycGyzFFEUS ZqGA== MIME-Version: 1.0 Received: by 10.68.202.234 with SMTP id kl10mr1709398pbc.52.1334808180294; Wed, 18 Apr 2012 21:03:00 -0700 (PDT) Received: by 10.68.213.129 with HTTP; Wed, 18 Apr 2012 21:03:00 -0700 (PDT) In-Reply-To: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> References: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> Date: Thu, 19 Apr 2012 12:03:00 +0800 Message-ID: From: Peng Wu To: DHC WG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [dhcwg] Call for adoption: draft-jiang-addr-registration X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 04:03:04 -0000 I'm in favor of adopting this document. 2012/4/18 Ted Lemon : > (We tentatively adopted quite a few drafts in the meeting, so we're tryin= g to space out the calls for adoption and last calls a bit=97I hope the aut= hors will bear with us.) > > The addr-registration draft proposes a mechanism for allowing clients to = autoconfigure their address and then register that address with the DHCP se= rver. =A0 At the meeting in Paris, there was strong consensus to adopt this= as a working group item. =A0 One of the authors has requested a call for a= doption to the mailing list. > > We already had sufficient consensus in Paris to adopt, but it's possible = that there are people on the mailing list who were not present in Paris who= might object. =A0 So for this reason, if you are in favor of adopting the = draft, even if you raised your hand in Paris, please signify in a reply to = this message. =A0 If you are against adopting the draft, please signify as = well. > > We will determine consensus on May 1, 2012. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From sunqi.thu@gmail.com Wed Apr 18 21:37:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6668521F845D for ; Wed, 18 Apr 2012 21:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCx14C5cD0n7 for ; Wed, 18 Apr 2012 21:37:20 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B6C9421F845C for ; Wed, 18 Apr 2012 21:37:19 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so7700201pbb.31 for ; Wed, 18 Apr 2012 21:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:reply-to:subject:references:x-priority:x-guid:x-mailer :mime-version:message-id:content-type; bh=icrqhPfJiPfpw3/ktPiJ7Mugvz/njvDVRKjNKcBhCq8=; b=mi/saiwMtngbUam6bF4YaHF8r9JEvD15nOiEP2SoUp4uKeRvl3oiTD0gaUM9gawBsL DXC0l1SW3bgeMcoHRefyVxdXI5lGWu5fIakVmDWUHeeNCq+e6K4cr+gZiwhE4UQM1mK+ Fm3EsMDjGoXIWQz08eSR6KKxdl8rhrx7wrkJwA/jN65Y75Gg531qbfENLXroqKQZnlTO gRS72DfcxkkfIitk3nz/yTmhL4jzOEr/G/ddcfbKOP72nZYN2FnNP4FSIaskxV/P5l96 Imw0fRRBl97m4K/p8IeLOAfdXsqgYPq8bW+ljHhCCju2R/RFoLh8FOS2TUwgPuHguHRl KZ9Q== Received: by 10.68.191.4 with SMTP id gu4mr1829011pbc.125.1334810239426; Wed, 18 Apr 2012 21:37:19 -0700 (PDT) Received: from sunqi ([203.91.121.133]) by mx.google.com with ESMTPS id it8sm1106152pbc.56.2012.04.18.21.37.17 (version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 21:37:19 -0700 (PDT) Date: Thu, 19 Apr 2012 12:37:14 +0800 From: "Qi Sun" To: "dhcwg@ietf.org" References: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> X-Priority: 3 X-GUID: 405F2B07-1ED6-44F2-A148-E5FBF24123AA X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <201204191237142241510@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart547267088720_=----" Subject: Re: [dhcwg] Call for adoption: draft-jiang-addr-registratio-dhcpv6-failover-design-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.thu" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 04:37:24 -0000 This is a multi-part message in MIME format. ------=_001_NextPart547267088720_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 KzEgZm9yIGFkb3B0aW9uIG9mIHRoZSBkcmFmdA0KDQoNCg0KDQpRaSBTdW4NCg0KRnJvbTogVGVk IExlbW9uDQpEYXRlOiAyMDEyLTA0LTE4IDA5OjQwDQpUbzogREhDIFdHDQpTdWJqZWN0OiBbZGhj d2ddIENhbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC1qaWFuZy1hZGRyLXJlZ2lzdHJhdGlvLWRoY3B2 Ni1mYWlsb3Zlci1kZXNpZ24tMDENCihXZSB0ZW50YXRpdmVseSBhZG9wdGVkIHF1aXRlIGEgZmV3 IGRyYWZ0cyBpbiB0aGUgbWVldGluZywgc28gd2UncmUgdHJ5aW5nIHRvIHNwYWNlIG91dCB0aGUg Y2FsbHMgZm9yIGFkb3B0aW9uIGFuZCBsYXN0IGNhbGxzIGEgYml0l0kgaG9wZSB0aGUgYXV0aG9y cyB3aWxsIGJlYXIgd2l0aCB1cy4pDQoNClRoZSBhZGRyLXJlZ2lzdHJhdGlvbiBkcmFmdCBwcm9w b3NlcyBhIG1lY2hhbmlzbSBmb3IgYWxsb3dpbmcgY2xpZW50cyB0byBhdXRvY29uZmlndXJlIHRo ZWlyIGFkZHJlc3MgYW5kIHRoZW4gcmVnaXN0ZXIgdGhhdCBhZGRyZXNzIHdpdGggdGhlIERIQ1Ag c2VydmVyLiAgIEF0IHRoZSBtZWV0aW5nIGluIFBhcmlzLCB0aGVyZSB3YXMgc3Ryb25nIGNvbnNl bnN1cyB0byBhZG9wdCB0aGlzIGFzIGEgd29ya2luZyBncm91cCBpdGVtLiAgIE9uZSBvZiB0aGUg YXV0aG9ycyBoYXMgcmVxdWVzdGVkIGEgY2FsbCBmb3IgYWRvcHRpb24gdG8gdGhlIG1haWxpbmcg bGlzdC4NCg0KV2UgYWxyZWFkeSBoYWQgc3VmZmljaWVudCBjb25zZW5zdXMgaW4gUGFyaXMgdG8g YWRvcHQsIGJ1dCBpdCdzIHBvc3NpYmxlIHRoYXQgdGhlcmUgYXJlIHBlb3BsZSBvbiB0aGUgbWFp bGluZyBsaXN0IHdobyB3ZXJlIG5vdCBwcmVzZW50IGluIFBhcmlzIHdobyBtaWdodCBvYmplY3Qu ICAgU28gZm9yIHRoaXMgcmVhc29uLCBpZiB5b3UgYXJlIGluIGZhdm9yIG9mIGFkb3B0aW5nIHRo ZSBkcmFmdCwgZXZlbiBpZiB5b3UgcmFpc2VkIHlvdXIgaGFuZCBpbiBQYXJpcywgcGxlYXNlIHNp Z25pZnkgaW4gYSByZXBseSB0byB0aGlzIG1lc3NhZ2UuICAgSWYgeW91IGFyZSBhZ2FpbnN0IGFk b3B0aW5nIHRoZSBkcmFmdCwgcGxlYXNlIHNpZ25pZnkgYXMgd2VsbC4NCg0KV2Ugd2lsbCBkZXRl cm1pbmUgY29uc2Vuc3VzIG9uIE1heSAxLCAyMDEyLg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KZGhjd2cgbWFpbGluZyBsaXN0DQpkaGN3Z0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw== ------=_001_NextPart547267088720_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
    +1 for adoption of the draft
     
    Qi Sun
     
    Date: 2012-04-18 09:40
    To: DHC WG
    Subject: [dhcwg] Call for adoption:=20 draft-jiang-addr-registratio-dhcpv6-failover-design-01
    (We tentatively adopted quite a few dra= fts in the meeting, so we're trying to&= nbsp;space out the calls for adoption and&nb= sp;last calls a bit=97I hope the authors&nbs= p;will bear with us.)
     
    The addr-registration draft proposes a mecha= nism for allowing clients to autoconfigure t= heir address and then register that address&= nbsp;with the DHCP server.   At the&nbs= p;meeting in Paris, there was strong consens= us to adopt this as a working group&nbs= p;item.   One of the authors has r= equested a call for adoption to the mai= ling list.
     
    We already had sufficient consensus in = Paris to adopt, but it's possible that = there are people on the mailing list wh= o were not present in Paris who might&n= bsp;object.   So for this reason, if&nb= sp;you are in favor of adopting the dra= ft, even if you raised your hand in&nbs= p;Paris, please signify in a reply to t= his message.   If you are against = adopting the draft, please signify as well.<= /DIV>
     
    We will determine consensus on May 1,&n= bsp;2012.
     
    _______________________________________________
    dhcwg mailing list
    dhcwg@ietf.org
    https://www.ietf.org/mailman/listinfo/dhcwg
    ------=_001_NextPart547267088720_=------ From eleven.fuyu@huawei.com Wed Apr 18 21:52:05 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE41C21F8483 for ; Wed, 18 Apr 2012 21:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODs0ozz8vBUJ for ; Wed, 18 Apr 2012 21:52:01 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5725321F847B for ; Wed, 18 Apr 2012 21:52:01 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFA61280; Thu, 19 Apr 2012 00:52:01 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 21:46:55 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 21:46:53 -0700 Received: from SZXEML512-MBS.china.huawei.com ([169.254.6.169]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 19 Apr 2012 12:46:49 +0800 From: "Fuyu (Eleven)" To: Ted Lemon Thread-Topic: Call for adoption: draft-jiang-addr-registration Thread-Index: AQHNHQQyZiojdrZahUGpIG8DE28dmpahdtZQ Date: Thu, 19 Apr 2012 04:46:48 +0000 Message-ID: References: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> In-Reply-To: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.119] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: DHC WG Subject: Re: [dhcwg] Call for adoption: draft-jiang-addr-registration X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 04:52:06 -0000 +1 support for adoption this draft as WG item. Cheers Yu -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Wednesday, April 18, 2012 9:40 AM To: DHC WG Subject: [dhcwg] Call for adoption: draft-jiang-addr-registration (We tentatively adopted quite a few drafts in the meeting, so we're trying = to space out the calls for adoption and last calls a bit=97I hope the autho= rs will bear with us.) The addr-registration draft proposes a mechanism for allowing clients to au= toconfigure their address and then register that address with the DHCP serv= er. At the meeting in Paris, there was strong consensus to adopt this as = a working group item. One of the authors has requested a call for adoptio= n to the mailing list. We already had sufficient consensus in Paris to adopt, but it's possible th= at there are people on the mailing list who were not present in Paris who m= ight object. So for this reason, if you are in favor of adopting the draf= t, even if you raised your hand in Paris, please signify in a reply to this= message. If you are against adopting the draft, please signify as well. We will determine consensus on May 1, 2012. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Dmitry.Anipko@microsoft.com Wed Apr 18 21:59:22 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653C221F84CD for ; Wed, 18 Apr 2012 21:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.667 X-Spam-Level: X-Spam-Status: No, score=-0.667 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OAcDvt3nr9h for ; Wed, 18 Apr 2012 21:59:21 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 79C9121F84C2 for ; Wed, 18 Apr 2012 21:59:20 -0700 (PDT) Received: from mail132-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 04:59:19 +0000 Received: from mail132-va3 (localhost [127.0.0.1]) by mail132-va3-R.bigfish.com (Postfix) with ESMTP id 88FCE1602C7 for ; Thu, 19 Apr 2012 04:59:19 +0000 (UTC) X-SpamScore: -37 X-BigFish: VS-37(zz9371I542M1432N148cMzz1202hzz1033ILz2fh2a8h683h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail132-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail132-va3 (localhost.localdomain [127.0.0.1]) by mail132-va3 (MessageSwitch) id 1334811557195135_22728; Thu, 19 Apr 2012 04:59:17 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.252]) by mail132-va3.bigfish.com (Postfix) with ESMTP id 20684140046 for ; Thu, 19 Apr 2012 04:59:17 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 04:59:14 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 19 Apr 2012 04:59:13 +0000 Received: from mail5-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 04:59:12 +0000 Received: from mail5-va3 (localhost [127.0.0.1]) by mail5-va3-R.bigfish.com (Postfix) with ESMTP id 50BF9360243 for ; Thu, 19 Apr 2012 04:59:12 +0000 (UTC) Received: from mail5-va3 (localhost.localdomain [127.0.0.1]) by mail5-va3 (MessageSwitch) id 1334811549377992_13985; Thu, 19 Apr 2012 04:59:09 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.242]) by mail5-va3.bigfish.com (Postfix) with ESMTP id 5641A300046; Thu, 19 Apr 2012 04:59:09 +0000 (UTC) Received: from CH1PRD0310HT003.namprd03.prod.outlook.com (157.56.244.37) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 04:59:09 +0000 Received: from CH1PRD0310MB368.namprd03.prod.outlook.com ([169.254.8.5]) by CH1PRD0310HT003.namprd03.prod.outlook.com ([10.255.137.38]) with mapi id 14.16.0143.004; Thu, 19 Apr 2012 04:59:07 +0000 From: Dmitry Anipko To: Peng Wu Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces Thread-Index: AQHNHSSLRzTBf+Nc20mYBKCZuRJ2F5ahlZaQ Date: Thu, 19 Apr 2012 04:59:07 +0000 Message-ID: <96DD85EB136DCD49AB5CDB6DEC9639AD05851197@CH1PRD0310MB368.namprd03.prod.outlook.com> References: <201204161209.q3GC90RH089072@givry.fdupont.fr> <96DD85EB136DCD49AB5CDB6DEC9639AD0584DBA9@CH1PRD0310MB368.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%FDUPONT.FR$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NOMINUM.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "dhcwg@ietf.org" , Francis Dupont , Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 04:59:22 -0000 >> From technical perspective it can work. The divergence now is, whether to include it in the draft. What's your opinion? If client-ids is something that is currently not widely implemented in exis= ting DHCP clients, I'm not sure that inclusion of this option in the text w= ould be practically useful at this time. And then, if it is easier to reach= agreement without including this option, I'd say don't include it. -----Original Message----- From: Peng Wu [mailto:pengwu.thu@gmail.com]=20 Sent: Tuesday, April 17, 2012 10:31 PM To: Dmitry Anipko Cc: Francis Dupont; dhcwg@ietf.org; Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 int= erfaces Dimitry, > Peng, it seemed to me at some point there was a consensus between Francis= & you regarding adding clarification that CRA serves only one tunnel inter= face and requires a dedicated 4over6 IPv6 address. If that's the case, can = such clarification be added to the CRA definition? [Peng]I think we all agree that's the recommanded case. Ted wrote some texts about the solution of modified client with multiple client ID & multiple state machines, to serve mutliple tunnel interfaces (or let's say, to manage multiple address retrieving). It's a detailed description of the corresponding solution discussed in this thread. From technical perspective it can work. The divergence now is, whether to include it in the draft. What's your opinion? > > IMO, that would address the question from the prospective of this I-D. Th= ere would be still question for draft-ietf-softwire-public-4over6, whether = scenario with multiple 4over6 IPv6 addresses on the same IPv6 interface are= supported, and if yes - how are they provisioned. [Peng] In public 4over6, we assume there is only one tunnel on the initiator(as is the same with other 4-over-6 mechanisms). And, if the initiator retrieve the address through DHCP, there would be only one IPv4 address. That's not different from regular DHCP. The problem we have in this thread is caused by multiple tunnel on the device. Thanks for bring it up. I'll state that the 4over6 initiator only run one tunnel/public 4over6 instance in the possible revision. > > draft-ietf-softwire-public-4over6 could also declare such scenario out of= scope - but having CRA definition clarification in draft-ietf-dhc-dhcpv4-o= ver-ipv6 is still useful, because then draft-ietf-dhc-dhcpv4-over-ipv6 woul= d not have to change in future should draft-ietf-softwire-public-4over6 def= ine some method for allocation of multiple 4over6 IPv6 addresses. [Peng]I agree. From pjhingra@cisco.com Wed Apr 18 22:10:06 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC1921F84E2 for ; Wed, 18 Apr 2012 22:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qYQCErQvfvq for ; Wed, 18 Apr 2012 22:10:02 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id BBF8321F8499 for ; Wed, 18 Apr 2012 22:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pjhingra@cisco.com; l=10857; q=dns/txt; s=iport; t=1334812201; x=1336021801; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=+d6hAGGxe00ReoM2RhTbSGF6pugTXDSDu0aE3PEKy/Q=; b=SZroIpshIYjKtNT6Ft4jmw63RKsJkgpNyVd7Z7rFHZWQi0u9Qjny6Jqe WzlyKLh6EvtY55FMBuop3E1Y036bDGO3jLAd9U3fdz1yE2BsnoLaPQPc2 Z61KUn/1KvoKZvSWabb8Kh+2a/0nXAFG5sW7pXnDpPZYkb8NUVqkKgAyh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAM6dj09Io8UY/2dsb2JhbAA5CoJGsAqCCQEBAQQBAQEPAQkRAz4LEAIBCBEEAQELBhcBBgEmHwkIAQEEAQoICBqHbQuaIaAtBIpghHJjBIham2aBaYJv X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208,217";a="10403444" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 19 Apr 2012 05:09:50 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3J59o77018091; Thu, 19 Apr 2012 05:09:50 GMT Received: from xmb-bgl-413.cisco.com ([72.163.129.209]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Apr 2012 10:39:49 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1DEA.A510B051" Date: Thu, 19 Apr 2012 10:39:48 +0530 Message-ID: <0C34754A9045B3419FB531A8C716E249080EA9EE@XMB-BGL-413.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 Thread-Index: Ac0cUBGpo7x2/cHbSBGT9/zlCSLLfgBmmUxw References: <64B00097-8ACB-4170-9303-8F863A47C2B5@nominum.com> From: "Prashant Jhingran (pjhingra)" To: "Prashanth R" , "Ted Lemon" X-OriginalArrivalTime: 19 Apr 2012 05:09:49.0830 (UTC) FILETIME=[A5693260:01CD1DEA] Cc: DHC WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 05:10:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1DEA.A510B051 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Prashanth, =20 Thanks for supporting this draft.=20 =20 As mentioned in the draft, "[RFC2131] specifies that a combination of 'client identifier' or 'chaddr' and assigned network address constitute a unique identifier for the client's lease and are used by both the client and server to identify a lease referred in any DHCP messages". How would a server allocate and keep track of clients when both "DHCP packet with 0 mac-addr and no client-id.". So its implicit that server would drop such packets. =20 The client behavior is out of scope of this draft, this draft only focuses on server behavior.=20 =20 - Regards, Prashant Jhingran =20 =20 From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Prashanth R Sent: Tuesday, April 17, 2012 9:41 AM To: Ted Lemon Cc: DHC WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 =20 Hi Ted, I am in favour of supporting this draft.=20 I have a couple of suggestions:=20 1) Can we add a section which would say what SHOULD be the behaviour on the client when it receives a packet with the client-id set.=20 2) Can a clarification be added on what the server SHOULD do when it receives a DHCP packet with 0 mac-addr and no client-id.=20 Thanks, Prashanth.=20 On Sat, Apr 14, 2012 at 6:24 PM, Ted Lemon wrote: This document corrects a bug in RFC2131 that forbids the DHCP server from returning a DHCP client identifier. The lack of a DHCP client identifier creates a problem in two cases: where the underlying transport has no link-layer address, and where two clients are running on the same host, supplying different client identifiers so as to present different network identities. In both of these cases, insufficient information is returned from the DHCP server to clearly identify the client that is the intended recipient of the message. The only way to fix this is to _require_ the DHCP server to return the client identifier if it receives it. This is what the proposed document does. We checked for consensus in the meeting, and four people were in favor of advancing the draft; nobody was against. I think this is actually pretty important work-it's a lingering bug in the spec which I think will come back to bite us more and more as we start getting deeper into the dual-stack transition. So if you haven't read the document, please do. If you support advancing it, please signify by replying to this message and saying that you support it. If you think it's a bad idea, please signify by replying to this message and explaining why. If you have comments or changes to propose, please send them along, and also signify whether you are in favor of advancement with the change, without the change, or oppose advancement. We will determine consensus on April 27, based solely on responses on the mailing list, so please do respond. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg =20 ------_=_NextPart_001_01CD1DEA.A510B051 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Prashanth,

     

    Thanks for supporting this draft.

     

    As mentioned in the draft, “[RFC2131] specifies that a = combination of 'client identifier' or 'chaddr' and assigned network = address constitute a unique identifier for the client's lease and are = used by both the client and server to identify a lease referred in any = DHCP messages”. How would a server allocate and keep track of = clients when both “DHCP packet with 0 mac-addr and no = client-id.”. So its implicit that server would drop such = packets.

     

    The client behavior is out of scope of this draft, this draft only = focuses on server behavior.

     

    -

    Regards,

    Prashant = Jhingran

     

     

    From:= = dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Prashanth R
    Sent: Tuesday, April 17, 2012 9:41 = AM
    To: Ted Lemon
    Cc: DHC WG
    Subject: Re: = [dhcwg] WGLC: draft-ietf-dhc-client-id-02

     

    Hi Ted,

    I am in favour of = supporting this draft.

    I have a couple of suggestions: =

    1) Can we add a section which would say what SHOULD be the = behaviour on the client when it receives a packet with the client-id = set.
    2) Can a clarification be added on what the server SHOULD do = when it receives a DHCP packet with 0 mac-addr and no client-id. =

    Thanks,
    Prashanth.

    On Sat, Apr 14, 2012 at 6:24 PM, Ted Lemon <Ted.Lemon@nominum.com> = wrote:

    This document corrects a bug = in RFC2131 that forbids the DHCP server from returning a DHCP client = identifier.   The lack of a DHCP client identifier creates a = problem in two cases: where the underlying transport has no link-layer = address, and where two clients are running on the same host, supplying = different client identifiers so as to present different network = identities.   In both of these cases, insufficient information is = returned from the DHCP server to clearly identify the client that is the = intended recipient of the message.   The only way to fix this is to = _require_ the DHCP server to return the client identifier if it receives = it.   This is what the proposed document does.

    We checked = for consensus in the meeting, and four people were in favor of advancing = the draft; nobody was against.

    I think this is actually pretty = important work—it's a lingering bug in the spec which I think will = come back to bite us more and more as we start getting deeper into the = dual-stack transition.   So if you haven't read the document, = please do.

    If you support advancing it, please signify by = replying to this message and saying that you support it. If you think = it's a bad idea, please signify by replying to this message and = explaining why.   If you have comments or changes to propose, = please send them along, and also signify whether you are in favor of = advancement with the change, without the change, or oppose = advancement.

    We will determine consensus on April 27, based = solely on responses on the mailing list, so please do = respond.

    Thanks!

    __________________________________________= _____
    dhcwg mailing list
    dhcwg@ietf.org
    https://www.ietf.org/mailman/listinfo/dhcwg

     

    ------_=_NextPart_001_01CD1DEA.A510B051-- From Tina.Tsou.Zouting@huawei.com Wed Apr 18 22:40:16 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E4421F8533 for ; Wed, 18 Apr 2012 22:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQFLab3qA2rj for ; Wed, 18 Apr 2012 22:40:12 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5E221F84DF for ; Wed, 18 Apr 2012 22:40:12 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFI65913; Thu, 19 Apr 2012 01:40:12 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 22:36:48 -0700 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 22:35:47 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.22]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Thu, 19 Apr 2012 13:36:37 +0800 From: Tina TSOU To: "Fuyu (Eleven)" , Ted Lemon Thread-Topic: Call for adoption: draft-jiang-addr-registration Thread-Index: AQHNHQQyZiojdrZahUGpIG8DE28dmpahdtZQgAAr1rA= Date: Thu, 19 Apr 2012 05:36:37 +0000 Message-ID: References: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: DHC WG Subject: Re: [dhcwg] Call for adoption: draft-jiang-addr-registration X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 05:40:16 -0000 Support. Tina > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Fuyu (Eleven) > Sent: Wednesday, April 18, 2012 9:47 PM > To: Ted Lemon > Cc: DHC WG > Subject: Re: [dhcwg] Call for adoption: draft-jiang-addr-registration >=20 > +1 support for adoption this draft as WG item. >=20 > Cheers > Yu >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Ted Lemon > Sent: Wednesday, April 18, 2012 9:40 AM > To: DHC WG > Subject: [dhcwg] Call for adoption: draft-jiang-addr-registration >=20 > (We tentatively adopted quite a few drafts in the meeting, so we're tryin= g > to space out the calls for adoption and last calls a bit-I hope the > authors will bear with us.) >=20 > The addr-registration draft proposes a mechanism for allowing clients to > autoconfigure their address and then register that address with the DHCP > server. At the meeting in Paris, there was strong consensus to adopt > this as a working group item. One of the authors has requested a call > for adoption to the mailing list. >=20 > We already had sufficient consensus in Paris to adopt, but it's possible > that there are people on the mailing list who were not present in Paris > who might object. So for this reason, if you are in favor of adopting > the draft, even if you raised your hand in Paris, please signify in a > reply to this message. If you are against adopting the draft, please > signify as well. >=20 > We will determine consensus on May 1, 2012. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From pengwu.thu@gmail.com Wed Apr 18 22:47:02 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B3E21F8533 for ; Wed, 18 Apr 2012 22:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62IXsr+yNmNj for ; Wed, 18 Apr 2012 22:46:58 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id DA19C21F84DF for ; Wed, 18 Apr 2012 22:46:57 -0700 (PDT) Received: by dady13 with SMTP id y13so14925355dad.27 for ; Wed, 18 Apr 2012 22:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=QuZZUV0h85tD+ZNvGuA6RxngSk3hX+SohxbibX6w11E=; b=LA1zI3o+ojvgApNJPGI6dGHkjodR3PNzwC/1HJ79V0jevLQDdhknbDd6sxwgkcdnhQ yMS59fU4ojv9JgSBgKH82KFFjZNcygC22fPf/7ZFeAT8pdZVU/TCpHBFmzg/Ggi1Pu4a tYcLIkRkeJ4RQixeJJ04f4OCYVYyUkfEGtDJ5d14qTRStHTSLd554xUukUFk1frWRCdN nf+ZQGk4aj3kFQ7gLCXQ5ZSYf9dHDkr65ywN492kowLHoYqr33jEMgh3Ag43tTs//GMg LR92rdfSkDr1qx4ARCvfdb8FHNB+gemOORs2Jd20dh7lFObxTUO5YV+T0vWHjLnZUKmb ZqpQ== MIME-Version: 1.0 Received: by 10.68.217.201 with SMTP id pa9mr2343409pbc.73.1334814417457; Wed, 18 Apr 2012 22:46:57 -0700 (PDT) Received: by 10.68.213.129 with HTTP; Wed, 18 Apr 2012 22:46:57 -0700 (PDT) In-Reply-To: <64B00097-8ACB-4170-9303-8F863A47C2B5@nominum.com> References: <64B00097-8ACB-4170-9303-8F863A47C2B5@nominum.com> Date: Thu, 19 Apr 2012 13:46:57 +0800 Message-ID: From: Peng Wu To: DHC WG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 05:47:02 -0000 I also support this draft and would like to see it moving forward. Cheers~ 2012/4/14 Ted Lemon : > This document corrects a bug in RFC2131 that forbids the DHCP server from= returning a DHCP client identifier. =A0 The lack of a DHCP client identifi= er creates a problem in two cases: where the underlying transport has no li= nk-layer address, and where two clients are running on the same host, suppl= ying different client identifiers so as to present different network identi= ties. =A0 In both of these cases, insufficient information is returned from= the DHCP server to clearly identify the client that is the intended recipi= ent of the message. =A0 The only way to fix this is to _require_ the DHCP s= erver to return the client identifier if it receives it. =A0 This is what t= he proposed document does. > > We checked for consensus in the meeting, and four people were in favor of= advancing the draft; nobody was against. > > I think this is actually pretty important work=97it's a lingering bug in = the spec which I think will come back to bite us more and more as we start = getting deeper into the dual-stack transition. =A0 So if you haven't read t= he document, please do. > > If you support advancing it, please signify by replying to this message a= nd saying that you support it. If you think it's a bad idea, please signify= by replying to this message and explaining why. =A0 If you have comments o= r changes to propose, please send them along, and also signify whether you = are in favor of advancement with the change, without the change, or oppose = advancement. > > We will determine consensus on April 27, based solely on responses on the= mailing list, so please do respond. > > Thanks! > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From shwethab@cisco.com Wed Apr 18 23:58:59 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A129621F84BD for ; Wed, 18 Apr 2012 23:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.995 X-Spam-Level: X-Spam-Status: No, score=-7.995 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPTe7bRTSAZX for ; Wed, 18 Apr 2012 23:58:55 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id CBF7221F84C4 for ; Wed, 18 Apr 2012 23:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shwethab@cisco.com; l=2170; q=dns/txt; s=iport; t=1334818735; x=1336028335; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=4x2+w5jyDqKgYqudWmiNBiPm0MHBiUsNhkYTIdH7cB8=; b=YVgxxEBByPXOpwDor5s0ha591K/cX32ijtikIWswNfHk62XJHh/bIGWj MbXw0ls9//oui2uj8N7PpqJrcZt4XdWfvLpwMeJqnleRs0qvpMpfjRPxo OKmzSaz0UY0MILSQaaC7RxrDGbqbAygISv5mTApoRwJFw4vXfuDdlnYKw Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAGO3j09Io8UY/2dsb2JhbAA5CrJRggsBBAEBAQ8BKQExHQEICWQwAQEEAQoIIodtC5otoDEEimCFVQSIKTGFLodnjlGBaYJv X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="10409963" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 19 Apr 2012 06:58:34 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3J6wYMq021365; Thu, 19 Apr 2012 06:58:34 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Apr 2012 12:28:34 +0530 Received: from 10.65.71.115 ([10.65.71.115]) by XMB-BGL-417.cisco.com ([72.163.129.213]) with Microsoft Exchange Server HTTP-DAV ; Thu, 19 Apr 2012 06:58:33 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 19 Apr 2012 12:33:15 +0530 From: shwethab To: Peng Wu , DHC WG Message-ID: Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 Thread-Index: Ac0d+n2bvZQUxTD3k0eDXtwAD/k6NQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 19 Apr 2012 06:58:34.0127 (UTC) FILETIME=[D631E9F0:01CD1DF9] Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 06:58:59 -0000 I also support this draft and would like to see it moving forward. +1 >=20 > Cheers~ >=20 > 2012/4/14 Ted Lemon : >> This document corrects a bug in RFC2131 that forbids the DHCP server fro= m >> returning a DHCP client identifier. =A0 The lack of a DHCP client identifi= er >> creates a problem in two cases: where the underlying transport has no >> link-layer address, and where two clients are running on the same host, >> supplying different client identifiers so as to present different networ= k >> identities. =A0 In both of these cases, insufficient information is return= ed >> from the DHCP server to clearly identify the client that is the intended >> recipient of the message. =A0 The only way to fix this is to _require_ the= DHCP >> server to return the client identifier if it receives it. =A0 This is what= the >> proposed document does. >>=20 >> We checked for consensus in the meeting, and four people were in favor o= f >> advancing the draft; nobody was against. >>=20 >> I think this is actually pretty important work=8Bit's a lingering bug in t= he >> spec which I think will come back to bite us more and more as we start >> getting deeper into the dual-stack transition. =A0 So if you haven't read = the >> document, please do. >>=20 >> If you support advancing it, please signify by replying to this message = and >> saying that you support it. If you think it's a bad idea, please signify= by >> replying to this message and explaining why. =A0 If you have comments or >> changes to propose, please send them along, and also signify whether you= are >> in favor of advancement with the change, without the change, or oppose >> advancement. >>=20 >> We will determine consensus on April 27, based solely on responses on th= e >> mailing list, so please do respond. >>=20 >> Thanks! >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From leo.liubing@huawei.com Thu Apr 19 01:35:08 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501DB21F85B4 for ; Thu, 19 Apr 2012 01:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id II32bBewhAde for ; Thu, 19 Apr 2012 01:35:04 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 284C121F85C7 for ; Thu, 19 Apr 2012 01:35:04 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFA73258; Thu, 19 Apr 2012 04:35:03 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Apr 2012 01:32:13 -0700 Received: from SZXEML425-HUB.china.huawei.com (10.72.61.33) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Apr 2012 01:32:18 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml425-hub.china.huawei.com ([10.72.61.33]) with mapi id 14.01.0323.003; Thu, 19 Apr 2012 16:32:11 +0800 From: "Liubing (Leo)" To: Ted Lemon , DHC WG Thread-Topic: Call for adoption: draft-jiang-addr-registration Thread-Index: AQHNHQQyZiojdrZahUGpIG8DE28dmpah01kg Date: Thu, 19 Apr 2012 08:32:11 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45292A29A0@szxeml509-mbs> References: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> In-Reply-To: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] Call for adoption: draft-jiang-addr-registration X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 08:35:08 -0000 +1 support=20 (I was in Paris raising my hand to support) > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Ted Lemon > Sent: Wednesday, April 18, 2012 9:40 AM > To: DHC WG > Subject: [dhcwg] Call for adoption: draft-jiang-addr-registration >=20 > (We tentatively adopted quite a few drafts in the meeting, so we're tryin= g to > space out the calls for adoption and last calls a bit-I hope the authors = will bear > with us.) >=20 > The addr-registration draft proposes a mechanism for allowing clients to > autoconfigure their address and then register that address with the DHCP > server. At the meeting in Paris, there was strong consensus to adopt th= is as a > working group item. One of the authors has requested a call for adoptio= n to > the mailing list. >=20 > We already had sufficient consensus in Paris to adopt, but it's possible = that there > are people on the mailing list who were not present in Paris who might ob= ject. > So for this reason, if you are in favor of adopting the draft, even if yo= u raised > your hand in Paris, please signify in a reply to this message. If you a= re against > adopting the draft, please signify as well. >=20 > We will determine consensus on May 1, 2012. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From leaf.y.yeh@huawei.com Thu Apr 19 05:10:49 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD0321F8460 for ; Thu, 19 Apr 2012 05:10:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvIejdfq6qva for ; Thu, 19 Apr 2012 05:10:44 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C065021F85F7 for ; Thu, 19 Apr 2012 05:10:44 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFA84644; Thu, 19 Apr 2012 08:10:44 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Apr 2012 05:07:43 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Apr 2012 05:07:48 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.29]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Thu, 19 Apr 2012 20:07:19 +0800 From: Leaf yeh To: Ted Lemon , DHC WG Thread-Topic: [dhcwg] Fwd: Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item Thread-Index: AQHNG+ULtLoQOEt2W0ezjuOXYBKwvJaiAuLQ Date: Thu, 19 Apr 2012 12:07:19 +0000 Message-ID: References: <0DB4E514-A0A0-4F15-ACD2-BD5C6F7477BE@nominum.com> In-Reply-To: <0DB4E514-A0A0-4F15-ACD2-BD5C6F7477BE@nominum.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.39.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Bernie Volz Subject: Re: [dhcwg] Fwd: Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 12:10:49 -0000 SSd2ZSByZWFkIHRocm91Z2ggdGhpcyBpbmZvcm1hdGlvbmFsIGRvY3VtZW50IGFuZCBhbSBpbnRl cmVzdGVkIGluIGl0cyBwcm9ncmVzcyBpbiB0aGUgV0cuICsxIGZvciB0aGUgYWRvcHRpb24uIEkg YmVsaWV2ZSB0aGUgbnVtYmVyZWQgKFdBTiBtb2RlbCkgQ1BFIGlzIGEgd2VsbC1rbm93biBhbmQg bmVjZXNzYXJ5IGNhc2UgaW4gYnJvYWRiYW5kIGFjY2VzcyAocmVmZXJyZWQgdG8gQkJGIFRSLTE3 NyksIHdoaWNoIG5lZWRzIHRoZSBzdXBwb3J0IG9mIG11bHRpcGxlIHN0YXRlZnVsIG9wdGlvbnMg KGVnLiAxeCBJQV9OQSBmb3IgaXRzIFdBTiBpbnRlcmZhY2UgJiAxeCBJQV9QRCBmb3IgdGhlIHN1 YnNjcmliZXIgbmV0d29yaykgaW4gREhDUHY2Lg0KDQpDb21tZW50cyBhbmQgcXVlc3Rpb25zOg0K DQoxLiBUaGUgZG9jdW1lbnQgc291bmRzIG5lZWQgbW9yZSB0ZXh0IG9uIHRoZSBzY29wZSBvZiB0 aGUgc3RhdHVzIGNvZGVzLiAoU2VjdGlvbiAzLjIsIHNlY3Rpb24gMy42KQ0KPHF1b3RlPkluIEFk dmVydGlzZW1lbnQgbWVzc2FnZXMgdGhlIFN0YXR1cyBjb2RlIG9wdGlvbiB3aXRoIHRoZSBOb0Fk ZHJzQXZhaWwgY29kZSBpcyBpbiB0aGUgImdsb2JhbCIgc2NvcGUuPC9xdW90ZT4g4oCTIEdsb2Jl Pw0KPHF1b3RlPk5vUHJlZml4QXZhaWwgaXMgb25seSBhcHBsaWNhYmxlIHRvIElBX1BELCBhbmQg Tm9BZGRyc0F2YWlsIGlzIG9ubHkgYXBwbGljYWJsZSB0byBJQV9OQS9JQV9UQSwgaXQgbWF5IGJl IHByb2JsZW1hdGljIHRvIG1ha2UgdGhpcyBhc3N1bXB0aW9uIGZvciBhbGwgc3RhdHVzIGNvZGVz LiA8L3F1b3RlPiAgLSBXaGF0IGRvZXMgdGhlICdwcm9ibGVtYXRpYycgbWVhbnMgaGVyZT8NCjxx dW90ZT5Gb3IgYmFja3dhcmRzIGNvbXBhdGliaWxpdHksIHRoZSBJQV9OQSBzdGF0dXMgY29kZSBj YW4gYmUga2VwdCBpbiB0aGUgZ2xvYmFsIHNjb3BlLiA8L3F1b3RlPiAtIEdsb2JlPw0KPHF1b3Rl PkZvciB0aGUgSUFzIHRoYXQgdGhlIHNlcnZlciBoYXMgbm8gYmluZGluZyBmb3IsIGl0IG11c3Qg cmVwbHkgdXNpbmcgdGhlIHNhbWUgYmVoYXZpb3VyIGFzIGZvciBhIFJlcXVlc3QgbWVzc2FnZS4g VGhhdCBpcyB3aXRoIGEgIk5vQWRkcnNBdmFpbCIgc3RhdHVzLiAoQXMgb3Bwb3NlZCB0byB0aGUg Y3VycmVudGx5IHNwZWNpZmllZCBOb0JpbmRpbmcpLiA8L3F1b3RlPiAtIFN0YXR1cyBjb2RlIGNo YW5nZSBoZXJlPw0KDQoyLiBDb25maXJtIG1lc3NhZ2UgKHNlY3Rpb24gMy40KQ0KPHF1b3RlPkl0 IGlzIGVuY291cmFnZWQgdG8gdXNlIFJlbmV3IGluc3RlYWQgb2YgQ29uZmlybS4gPC9xdW90ZT4g UGVyIFJGQzM2MzMsIERIQ1B2NiBkb24ndCB1c2UgQ29uZmlybSAmIERlY2xpbmUgbWVzc2FnZSBp biBQRCBwcm9jZXNzLiBXaWxsIHdlIHRyeSB0byBhZG9wdCB0aGVzZSBtZXNzYWdlcyBiYWNrIGFn YWluPw0KDQozLiBEZWNsaW5lIG1lc3NhZ2UgKHNlY3Rpb24gMy41KQ0KTm8gdGV4dCBhYm91dCBE ZWNsaW5lIG1lc3NhZ2UgaW4gc2VjdGlvbiAzLjUgeWV0Lg0KDQoNCkJlc3QgUmVnYXJkcywNCkxl YWYNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpGcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBMZW1vbg0KU2VudDogTW9uZGF5LCBBcHJpbCAx NiwgMjAxMiAxMToyNCBQTQ0KVG86IERIQyBXRw0KU3ViamVjdDogW2RoY3dnXSBGd2Q6IENhbGwg Zm9yIEFkb3B0aW9uLCBkcmFmdC10cm9hbi1kaGMtZGhjcHY2LXN0YXRlZnVsLWlzc3Vlcy0wMCBh cyBXRyBpdGVtDQoNClJlbWluZGVyLCB3ZSdyZSBoYWxmd2F5IHRocm91Z2ggdGhlIGxhc3QgY2Fs bCBwZXJpb2QgZm9yIHRoaXMgZG9jdW1lbnQuIMKgIFdlJ3ZlIGdvdHRlbiBhIGdvb2QgcmVzcG9u c2UsIHNvIHRoZXJlJ3Mgbm8gbmVlZCB0byByZXNwb25kIGlmIHlvdSBhcmVuJ3QgdGhhdCBpbnRl cmVzdGVkLCBidXQgaWYgeW91IGFyZSBpbnRlcmVzdGVkIGFuZCBoYXZlbid0IHJlc3BvbmRlZCwg cGxlYXNlIGRvLiANCg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCg0KDQpGcm9tOiBUZWQg TGVtb24gPFRlZC5MZW1vbkBub21pbnVtLmNvbT4NClN1YmplY3Q6IFtkaGN3Z10gQ2FsbCBmb3Ig QWRvcHRpb24sIGRyYWZ0LXRyb2FuLWRoYy1kaGNwdjYtc3RhdGVmdWwtaXNzdWVzLTAwIGFzIFdH IGl0ZW0NCkRhdGU6IEFwcmlsIDUsIDIwMTIgMTozNDo0NiBQTSBFRFQNClRvOiAiZGhjd2dAaWV0 Zi5vcmcgV0ciIDxkaGN3Z0BpZXRmLm9yZz4NCg0KT24gQXByIDUsIDIwMTIsIGF0IDE6MjUgUE0s IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb20+IHdyb3RlOg0KQXQgdGhlIFBhcmlz IElFVEYtODMgREhDIFdHIG1lZXRpbmcgdGhlcmUgd2FzIGEgbG90IG9mIHN1cHBvcnQgZm9yIChh bmQgSSBiZWxpZXZlIG5vIG9wcG9zaXRpb24pIGFkb3B0aW5nIHRoaXMgYXMgYSBESEMgV0cgaXRl bS4NCsKgDQpJIGtpbmRseSByZXF1ZXN0IHRoYXQgd2UgYWRvcHQgdGhpcyBkb2N1bWVudCBhcyBh IERIQyBXRyB3b3JrIGl0ZW0uDQoNClRoaXMgZHJhZnQgZG9jdW1lbnRzIGlzc3VlcyB0aGF0IGhh dmUgY29tZSB1cCBpbnZvbHZpbmcgaW50ZXJhY3Rpb25zIGJldHdlZW4gcHJlZml4IGRlbGVnYXRp b24gYW5kIHJlZ3VsYXIgSVAgYWRkcmVzcyBhbGxvY2F0aW9uIGluIHByYWN0aWNlLiDCoCBJZiB5 b3Ugd291bGQgbGlrZSB0aGUgd29ya2luZyBncm91cCB0byB3b3JrIG9uIGRvY3VtZW50aW5nIHRo aXMsIHBsZWFzZSBzaWduaWZ5IGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBtZXNzYWdlIGluIHRoZSBh ZmZpcm1hdGl2ZS4gwqAgSWYgeW91IGRvbid0IHRoaW5rIHdlIHNob3VsZCB3b3JrIG9uIGl0LCBw bGVhc2UgcmVzcG9uZCBpbiB0aGUgbmVnYXRpdmUuIMKgIElmIHlvdSBoYXZlIG5vIG9waW5pb24s IHBsZWFzZSBkbyBub3QgcmVzcG9uZC4NCg0KV2Ugd2lsbCBkZXRlcm1pbmUgY29uc2Vuc3VzIG9u IFRodXJzZGF5LCBBcHJpbCAxOS7CoA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KZGhjd2cgbWFpbGluZyBsaXN0DQpkaGN3Z0BpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KDQo= From jiangdong345@gmail.com Thu Apr 19 06:02:06 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7C321F85F7 for ; Thu, 19 Apr 2012 06:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.945 X-Spam-Level: X-Spam-Status: No, score=-0.945 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sfIZmN1ENK2 for ; Thu, 19 Apr 2012 06:02:04 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D42421F85E7 for ; Thu, 19 Apr 2012 06:02:04 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so8170460pbb.31 for ; Thu, 19 Apr 2012 06:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=C+nOJD6FwiqAxFfpP+xwjhL3qWS7nYPvo6q/1JqvyE0=; b=fGrrMcPC/My8VgzoY4nFpsd3SOmaY1/665mhuLqB5MY7mWugKbELO0TNXBi77on9N/ E7qjXYr1YPy1tfYktvaeRb96nO9gLA1ygMmX9vdKL3yPttD0LXpcg1UUBrl6jU6RGBN2 Mb+XbFuW2uiKpf0Opu2oVy4yRWv3BTEcbdd4GYnhlEJ18oEBYwUZ0aNyM+1zh8j18WHH a6QBMzxC/W4E900AcGu2qiHhm0mPALVxuJ5wIGgzonHy8iNmSChmE26REmaA2kh7QSDN s57PwV124lzuh1BPbx44c2pPPdATNzYtbEQLexUE/RUVgLwiolosQ50xXzQecCX/HL6S NhNA== Received: by 10.68.229.33 with SMTP id sn1mr4763406pbc.59.1334840523948; Thu, 19 Apr 2012 06:02:03 -0700 (PDT) Received: from John-PC ([166.111.68.231]) by mx.google.com with ESMTPS id pg1sm2213669pbc.21.2012.04.19.06.02.00 (version=SSLv3 cipher=OTHER); Thu, 19 Apr 2012 06:02:03 -0700 (PDT) Date: Thu, 19 Apr 2012 21:02:05 +0800 From: "Jiang Dong" To: "Ted Lemon" , "DHC WG" References: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> X-Priority: 3 X-GUID: CC2C5F4E-A8B8-4912-BF4C-768AD6E40009 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.86[cn] Mime-Version: 1.0 Message-ID: <2012041921020232706944@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart742710451888_=----" Subject: Re: [dhcwg] Call for adoption: draft-jiang-addr-registration X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jiangdong345 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 13:02:06 -0000 This is a multi-part message in MIME format. ------=_001_NextPart742710451888_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgLA0KDQorMSBzdXBwb3J0IGFkb3B0aW5nIHRoaXMgZHJhZnQuDQoNClJlZ2FyZHMhDQpKaWFu ZyBEb25nDQoyMDEyLTA0LTE5DQoNCkZyb206IFRlZCBMZW1vbg0KRGF0ZTogMjAxMi0wNC0xOCAw OTo0MA0KVG86IERIQyBXRw0KU3ViamVjdDogW2RoY3dnXSBDYWxsIGZvciBhZG9wdGlvbjogZHJh ZnQtamlhbmctYWRkci1yZWdpc3RyYXRpb24NCihXZSB0ZW50YXRpdmVseSBhZG9wdGVkIHF1aXRl IGEgZmV3IGRyYWZ0cyBpbiB0aGUgbWVldGluZywgc28gd2UncmUgdHJ5aW5nIHRvIHNwYWNlIG91 dCB0aGUgY2FsbHMgZm9yIGFkb3B0aW9uIGFuZCBsYXN0IGNhbGxzIGEgYml0l0kgaG9wZSB0aGUg YXV0aG9ycyB3aWxsIGJlYXIgd2l0aCB1cy4pDQoNClRoZSBhZGRyLXJlZ2lzdHJhdGlvbiBkcmFm dCBwcm9wb3NlcyBhIG1lY2hhbmlzbSBmb3IgYWxsb3dpbmcgY2xpZW50cyB0byBhdXRvY29uZmln dXJlIHRoZWlyIGFkZHJlc3MgYW5kIHRoZW4gcmVnaXN0ZXIgdGhhdCBhZGRyZXNzIHdpdGggdGhl IERIQ1Agc2VydmVyLiAgIEF0IHRoZSBtZWV0aW5nIGluIFBhcmlzLCB0aGVyZSB3YXMgc3Ryb25n IGNvbnNlbnN1cyB0byBhZG9wdCB0aGlzIGFzIGEgd29ya2luZyBncm91cCBpdGVtLiAgIE9uZSBv ZiB0aGUgYXV0aG9ycyBoYXMgcmVxdWVzdGVkIGEgY2FsbCBmb3IgYWRvcHRpb24gdG8gdGhlIG1h aWxpbmcgbGlzdC4NCg0KV2UgYWxyZWFkeSBoYWQgc3VmZmljaWVudCBjb25zZW5zdXMgaW4gUGFy aXMgdG8gYWRvcHQsIGJ1dCBpdCdzIHBvc3NpYmxlIHRoYXQgdGhlcmUgYXJlIHBlb3BsZSBvbiB0 aGUgbWFpbGluZyBsaXN0IHdobyB3ZXJlIG5vdCBwcmVzZW50IGluIFBhcmlzIHdobyBtaWdodCBv YmplY3QuICAgU28gZm9yIHRoaXMgcmVhc29uLCBpZiB5b3UgYXJlIGluIGZhdm9yIG9mIGFkb3B0 aW5nIHRoZSBkcmFmdCwgZXZlbiBpZiB5b3UgcmFpc2VkIHlvdXIgaGFuZCBpbiBQYXJpcywgcGxl YXNlIHNpZ25pZnkgaW4gYSByZXBseSB0byB0aGlzIG1lc3NhZ2UuICAgSWYgeW91IGFyZSBhZ2Fp bnN0IGFkb3B0aW5nIHRoZSBkcmFmdCwgcGxlYXNlIHNpZ25pZnkgYXMgd2VsbC4NCg0KV2Ugd2ls bCBkZXRlcm1pbmUgY29uc2Vuc3VzIG9uIE1heSAxLCAyMDEyLg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZGhjd2cgbWFpbGluZyBsaXN0DQpkaGN3 Z0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw== ------=_001_NextPart742710451888_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
    Hi ,
     
    +1 support=20 adopting this draft.
     
    Regards!
    Jiang Dong 2012-04-19
     
    Date: 2012-04-18 09:40
    To: DHC WG
    Subject: [dhcwg] Call for adoption:=20 draft-jiang-addr-registration
    (We tentatively adopted quite a few dra= fts in the meeting, so we're trying to&= nbsp;space out the calls for adoption and&nb= sp;last calls a bit=97I hope the authors&nbs= p;will bear with us.)
     
    The addr-registration draft proposes a mecha= nism for allowing clients to autoconfigure t= heir address and then register that address&= nbsp;with the DHCP server.   At the&nbs= p;meeting in Paris, there was strong consens= us to adopt this as a working group&nbs= p;item.   One of the authors has r= equested a call for adoption to the mai= ling list.
     
    We already had sufficient consensus in = Paris to adopt, but it's possible that = there are people on the mailing list wh= o were not present in Paris who might&n= bsp;object.   So for this reason, if&nb= sp;you are in favor of adopting the dra= ft, even if you raised your hand in&nbs= p;Paris, please signify in a reply to t= his message.   If you are against = adopting the draft, please signify as well.<= /DIV>
     
    We will determine consensus on May 1,&n= bsp;2012.
     
    _______________________________________________
    dhcwg mailing list
    dhcwg@ietf.org
    https://www.ietf.org/mailman/listinfo/dhcwg
    ------=_001_NextPart742710451888_=------ From Ted.Lemon@nominum.com Thu Apr 19 06:48:45 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA5F21F85A3 for ; Thu, 19 Apr 2012 06:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.521 X-Spam-Level: X-Spam-Status: No, score=-106.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KDiLhY64beC for ; Thu, 19 Apr 2012 06:48:44 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id DA9DB21F85A2 for ; Thu, 19 Apr 2012 06:48:43 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT5AXu7wsO0nLcGs1pqlleKnf6NPKHXdJ@postini.com; Thu, 19 Apr 2012 06:48:43 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E20861B8334 for ; Thu, 19 Apr 2012 06:48:42 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D269319006D; Thu, 19 Apr 2012 06:48:42 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 19 Apr 2012 06:48:43 -0700 From: Ted Lemon To: Dmitry Anipko Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces Thread-Index: AQHNHSR7G+dtbB5bOEOAzgN/vVWqLJaiDVyAgACT9wA= Date: Thu, 19 Apr 2012 13:48:42 +0000 Message-ID: <99591DAE-D8CD-4F06-BEFE-9679D3A36A78@nominum.com> References: <201204161209.q3GC90RH089072@givry.fdupont.fr> <96DD85EB136DCD49AB5CDB6DEC9639AD0584DBA9@CH1PRD0310MB368.namprd03.prod.outlook.com> <96DD85EB136DCD49AB5CDB6DEC9639AD05851197@CH1PRD0310MB368.namprd03.prod.outlook.com> In-Reply-To: <96DD85EB136DCD49AB5CDB6DEC9639AD05851197@CH1PRD0310MB368.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_99591DAED8CD4F06BEFE9679D3A36A78nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Francis Dupont Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 13:48:45 -0000 --_000_99591DAED8CD4F06BEFE9679D3A36A78nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 19, 2012, at 12:59 AM, Dmitry Anipko > wrote: If client-ids is something that is currently not widely implemented in exis= ting DHCP clients, I'm not sure that inclusion of this option in the text w= ould be practically useful at this time. And then, if it is easier to reach= agreement without including this option, I'd say don't include it. In order for a client to configure multiple tunnel endpoints using the same= CRA, there is _no choice_ but to use different client identifiers. That = is to say, there is _no choice_ but to modify the client. So specifying t= he client identifier is okay. --_000_99591DAED8CD4F06BEFE9679D3A36A78nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
    On Apr 19, 2012, at 12:59 AM, Dmitry Anipko <Dmitry.Anipko@microsoft.com> wrote:
    If client-ids is something that is currently not widely implemented in existi= ng DHCP clients, I'm not sure that inclusion of this option in the text wou= ld be practically useful at this time. And then, if it is easier to reach a= greement without including this option, I'd say don't include it.

    In order for a client to configure multiple tunnel endpoints using the= same CRA, there is _no choice_ but to use different client identifiers. &n= bsp; That is to say, there is _no choice_ but to modify the client.   = So specifying the client identifier is okay.

    --_000_99591DAED8CD4F06BEFE9679D3A36A78nominumcom_-- From Ted.Lemon@nominum.com Thu Apr 19 06:58:57 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D9A21F85A5 for ; Thu, 19 Apr 2012 06:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMqA2ospt-sx for ; Thu, 19 Apr 2012 06:58:56 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 88B0521F85A2 for ; Thu, 19 Apr 2012 06:58:56 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT5AaIFEmCxX98kIp4dXswOUQwiSJHU9f@postini.com; Thu, 19 Apr 2012 06:58:56 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BA8601B8333 for ; Thu, 19 Apr 2012 06:58:55 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B218519006D for ; Thu, 19 Apr 2012 06:58:55 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 19 Apr 2012 06:58:49 -0700 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item Thread-Index: AQHNE1Jkl7tgtOxKmkWYH3w2Igkw0Zait8kA Date: Thu, 19 Apr 2012 13:58:48 +0000 Message-ID: <67C32110-F782-4BD4-9167-0E5F6C786E88@nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_67C32110F7824BD491670E5F6C786E88nominumcom_" MIME-Version: 1.0 Subject: Re: [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 13:58:57 -0000 --_000_67C32110F7824BD491670E5F6C786E88nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 5, 2012, at 1:34 PM, Ted Lemon > wrote: This draft documents issues that have come up involving interactions betwee= n prefix delegation and regular IP address allocation in practice. If you= would like the working group to work on documenting this, please signify b= y responding to this message in the affirmative. If you don't think we sh= ould work on it, please respond in the negative. If you have no opinion, = please do not respond. We will determine consensus on Thursday, April 19. Thirteen participants spoke in favor of adopting the document, and none opp= osed it, so it's officially adopted as a working group item. Would the au= thors please submit a new version (perhaps with edits as a result of Leaf's= , Tomek's, Bud's and Bernie's comments? --_000_67C32110F7824BD491670E5F6C786E88nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <114064101C534E4FB51B1AB2968C2CC2@nominum.com> Content-Transfer-Encoding: quoted-printable
    On Apr 5, 2012, at 1:34 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
    This draft documents issues that have come up involving interactions betwee= n prefix delegation and regular IP address allocation in practice.   I= f you would like the working group to work on documenting this, please sign= ify by responding to this message in the affirmative.   If you don't think we should work on it, please re= spond in the negative.   If you have no opinion, please do not respond= .

    We will determine consensus on Thursday, April 19. 

    Thirteen participants spoke in favor of adopting the document, and non= e opposed it, so it's officially adopted as a working group item.   Wo= uld the authors please submit a new version (perhaps with edits as a result= of Leaf's, Tomek's, Bud's and Bernie's comments?

    --_000_67C32110F7824BD491670E5F6C786E88nominumcom_-- From maxpassion@gmail.com Thu Apr 19 19:32:09 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4CE11E80AC for ; Thu, 19 Apr 2012 19:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L+VRPG9ijHp for ; Thu, 19 Apr 2012 19:32:08 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8161C11E80AA for ; Thu, 19 Apr 2012 19:32:08 -0700 (PDT) Received: by iazz13 with SMTP id z13so15509704iaz.31 for ; Thu, 19 Apr 2012 19:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zTtYltqh8sV0IfW81sFThIqk9SpBNjKkjefPYaQ5MwY=; b=eEKTacsKET2Ml2ywznko8eCaB4jzY0JAjErcR0hZHsU2lHF4/ZBwc8YsmEHgWa36Q2 McaNn1atjUHJ7X9P1b6jMIWGx5aIRKF2NQlqWipzJsrXykfYrcDRpHUqhQnZqQQgupAV bbZF3Jq+67bvLgGIM1TNsPBN/NATeVQNjmYF4puafOnQcQy160c9IyP21ry2e1dxEEga IkES0iRdUIqc10sk4AKWjA2zapk2LuCDJhiSazI/abnKhv4A3kVW9hcUnvmd0/579i6p vc7FXgk1OJTE2KITmatBvoJojIpa2oLFKhEkhLr6APSfHoyhldiv4oUcLRTnkHXasaE4 O9UQ== MIME-Version: 1.0 Received: by 10.50.217.137 with SMTP id oy9mr4445954igc.31.1334889128201; Thu, 19 Apr 2012 19:32:08 -0700 (PDT) Received: by 10.42.9.209 with HTTP; Thu, 19 Apr 2012 19:32:08 -0700 (PDT) In-Reply-To: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> References: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> Date: Fri, 20 Apr 2012 10:32:08 +0800 Message-ID: From: liu dapeng To: Ted Lemon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: DHC WG Subject: Re: [dhcwg] Call for adoption: draft-jiang-addr-registration X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 02:32:09 -0000 +1 Regards, -Dapeng 2012/4/18, Ted Lemon : > (We tentatively adopted quite a few drafts in the meeting, so we're tryin= g > to space out the calls for adoption and last calls a bit=97I hope the aut= hors > will bear with us.) > > The addr-registration draft proposes a mechanism for allowing clients to > autoconfigure their address and then register that address with the DHCP > server. At the meeting in Paris, there was strong consensus to adopt th= is > as a working group item. One of the authors has requested a call for > adoption to the mailing list. > > We already had sufficient consensus in Paris to adopt, but it's possible > that there are people on the mailing list who were not present in Paris w= ho > might object. So for this reason, if you are in favor of adopting the > draft, even if you raised your hand in Paris, please signify in a reply t= o > this message. If you are against adopting the draft, please signify as > well. > > We will determine consensus on May 1, 2012. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --=20 ------ Best Regards, Dapeng Liu From Dmitry.Anipko@microsoft.com Thu Apr 19 19:56:45 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A804221F858D for ; Thu, 19 Apr 2012 19:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae3VNwsUqd3h for ; Thu, 19 Apr 2012 19:56:44 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0664121F848E for ; Thu, 19 Apr 2012 19:56:43 -0700 (PDT) Received: from mail55-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Apr 2012 02:56:43 +0000 Received: from mail55-tx2 (localhost [127.0.0.1]) by mail55-tx2-R.bigfish.com (Postfix) with ESMTP id 410F82C02AA for ; Fri, 20 Apr 2012 02:56:43 +0000 (UTC) X-SpamScore: -24 X-BigFish: VS-24(zz9371Ic85fh98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail55-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail55-tx2 (localhost.localdomain [127.0.0.1]) by mail55-tx2 (MessageSwitch) id 1334890602295196_32650; Fri, 20 Apr 2012 02:56:42 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.252]) by mail55-tx2.bigfish.com (Postfix) with ESMTP id 4242B3000D2 for ; Fri, 20 Apr 2012 02:56:42 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Apr 2012 02:56:41 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.283.4; Fri, 20 Apr 2012 02:56:40 +0000 Received: from mail22-am1-R.bigfish.com (10.3.201.229) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Apr 2012 02:56:38 +0000 Received: from mail22-am1 (localhost [127.0.0.1]) by mail22-am1-R.bigfish.com (Postfix) with ESMTP id C2352400205 for ; Fri, 20 Apr 2012 02:56:38 +0000 (UTC) Received: from mail22-am1 (localhost.localdomain [127.0.0.1]) by mail22-am1 (MessageSwitch) id 1334890596494157_13208; Fri, 20 Apr 2012 02:56:36 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.243]) by mail22-am1.bigfish.com (Postfix) with ESMTP id 737A7A0046; Fri, 20 Apr 2012 02:56:36 +0000 (UTC) Received: from CH1PRD0310HT005.namprd03.prod.outlook.com (157.56.244.37) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Apr 2012 02:56:35 +0000 Received: from CH1PRD0310MB368.namprd03.prod.outlook.com ([169.254.8.94]) by CH1PRD0310HT005.namprd03.prod.outlook.com ([10.255.137.40]) with mapi id 14.16.0143.004; Fri, 20 Apr 2012 02:55:37 +0000 From: Dmitry Anipko To: Ted Lemon Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces Thread-Index: AQHNHSSLRzTBf+Nc20mYBKCZuRJ2F5ahlZaQgACWZACAANkkoA== Date: Fri, 20 Apr 2012 02:55:36 +0000 Message-ID: <96DD85EB136DCD49AB5CDB6DEC9639AD058565F0@CH1PRD0310MB368.namprd03.prod.outlook.com> References: <201204161209.q3GC90RH089072@givry.fdupont.fr> <96DD85EB136DCD49AB5CDB6DEC9639AD0584DBA9@CH1PRD0310MB368.namprd03.prod.outlook.com> <96DD85EB136DCD49AB5CDB6DEC9639AD05851197@CH1PRD0310MB368.namprd03.prod.outlook.com> <99591DAE-D8CD-4F06-BEFE-9679D3A36A78@nominum.com> In-Reply-To: <99591DAE-D8CD-4F06-BEFE-9679D3A36A78@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.100] Content-Type: multipart/alternative; boundary="_000_96DD85EB136DCD49AB5CDB6DEC9639AD058565F0CH1PRD0310MB368_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT005.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NOMINUM.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%FDUPONT.FR$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "dhcwg@ietf.org" , Francis Dupont Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 02:56:45 -0000 --_000_96DD85EB136DCD49AB5CDB6DEC9639AD058565F0CH1PRD0310MB368_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >>In order for a client to configure multiple tunnel endpoints using the sa= me CRA My reading of Peng's question was as to whether a specific requirement (sam= e CRA used by multiple tunnel endpoints) and a solution addressing this req= uirement shall be included in the text, and I commented on that question. As I understand, your comment rather relates to "assuming this specific req= uirement (same CRA used by multiple tunnel endpoints) must be included in t= he text, what the solution is". That's a different question, which only app= ears if there is a requirement for same CRA to serve multiple tunnel endpoi= nts (as opposed to e.g. having per tunnel endpoint CRA). Are there reasons = to have that as a requirement? From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Thursday, April 19, 2012 6:49 AM To: Dmitry Anipko Cc: dhcwg@ietf.org; Francis Dupont Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 int= erfaces On Apr 19, 2012, at 12:59 AM, Dmitry Anipko > wrote: If client-ids is something that is currently not widely implemented in exis= ting DHCP clients, I'm not sure that inclusion of this option in the text w= ould be practically useful at this time. And then, if it is easier to reach= agreement without including this option, I'd say don't include it. In order for a client to configure multiple tunnel endpoints using the same= CRA, there is _no choice_ but to use different client identifiers. That = is to say, there is _no choice_ but to modify the client. So specifying t= he client identifier is okay. --_000_96DD85EB136DCD49AB5CDB6DEC9639AD058565F0CH1PRD0310MB368_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    >>In order for a client to configure multiple t= unnel endpoints using the same CRA

     

    My reading of Peng’s question was as to whethe= r a specific requirement (same CRA used by multiple tunnel endpoints) and a= solution addressing this requirement shall be included in the text, and I = commented on that question.

     

    As I understand, your comment rather relates to R= 20;assuming this specific requirement (same CRA used by multiple tunnel end= points) must be included in the text, what the solution is”. ThatR= 17;s a different question, which only appears if there is a requirement for same CRA to serve multiple tunnel endpoints (as oppos= ed to e.g. having per tunnel endpoint CRA). Are there reasons to have that = as a requirement?

     

    From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon
    Sent: Thursday, April 19, 2012 6:49 AM
    To: Dmitry Anipko
    Cc: dhcwg@ietf.org; Francis Dupont
    Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple i= pv4 interfaces

     

    On Apr 19, 2012, at 12:59 AM, Dmitry Anipko <Dmitry.Anipko@microsoft.com&= gt; wrote:

    If client-ids is something that is cu= rrently not widely implemented in existing DHCP clients, I'm not sure that = inclusion of this option in the text would be practically useful at this time. And then, if it is easier to reach agreement without = including this option, I'd say don't include it.

     

    In order for a client to configure multiple tunnel e= ndpoints using the same CRA, there is _no choice_ but to use different clie= nt identifiers.   That is to say, there is _no choice_ but to modify t= he client.   So specifying the client identifier is okay.

     

    --_000_96DD85EB136DCD49AB5CDB6DEC9639AD058565F0CH1PRD0310MB368_-- From Ted.Lemon@nominum.com Thu Apr 19 20:35:09 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A03921F8542 for ; Thu, 19 Apr 2012 20:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.526 X-Spam-Level: X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84Gs8n-LX7n0 for ; Thu, 19 Apr 2012 20:35:08 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 658E921F84F3 for ; Thu, 19 Apr 2012 20:35:08 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT5DZa6zq5ngb7LBclAhy+f4VtSf6eKRf@postini.com; Thu, 19 Apr 2012 20:35:08 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 55C851B82A5 for ; Thu, 19 Apr 2012 20:35:07 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 414A219006D; Thu, 19 Apr 2012 20:35:07 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 19 Apr 2012 20:35:07 -0700 From: Ted Lemon To: Dmitry Anipko Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces Thread-Index: AQHNHSR7G+dtbB5bOEOAzgN/vVWqLJaiDVyAgACT9wCAANvbAIAACwkA Date: Fri, 20 Apr 2012 03:35:07 +0000 Message-ID: <74146A02-B37E-4BF6-877C-054542530089@nominum.com> References: <201204161209.q3GC90RH089072@givry.fdupont.fr> <96DD85EB136DCD49AB5CDB6DEC9639AD0584DBA9@CH1PRD0310MB368.namprd03.prod.outlook.com> <96DD85EB136DCD49AB5CDB6DEC9639AD05851197@CH1PRD0310MB368.namprd03.prod.outlook.com> <99591DAE-D8CD-4F06-BEFE-9679D3A36A78@nominum.com> <96DD85EB136DCD49AB5CDB6DEC9639AD058565F0@CH1PRD0310MB368.namprd03.prod.outlook.com> In-Reply-To: <96DD85EB136DCD49AB5CDB6DEC9639AD058565F0@CH1PRD0310MB368.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_74146A02B37E4BF6877C054542530089nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Francis Dupont Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 03:35:09 -0000 --_000_74146A02B37E4BF6877C054542530089nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Apr 19, 2012, at 10:55 PM, Dmitry Anipko > wrote: That=92s a different question, which only appears if there is a requirement= for same CRA to serve multiple tunnel endpoints (as opposed to e.g. having= per tunnel endpoint CRA). Are there reasons to have that as a requirement? I don't think so, no. The suggestion that there should be such a requirem= ent was raised by someone else; I thought it was you, but maybe you were ju= st raising a question that had been raised by someone else in softwires? --_000_74146A02B37E4BF6877C054542530089nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
    On Apr 19, 2012, at 10:55 PM, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
     wrote:
    That=92s a different question, which only appears if there is a requirement for sam= e CRA to serve multiple tunnel endpoints (as opposed to e.g. having per tun= nel endpoint CRA). Are there reasons to have that as a requirement?<= /blockquote>

    I don't think so, no.   The suggestion that there should be such = a requirement was raised by someone else; I thought it was you, but maybe y= ou were just raising a question that had been raised by someone else in sof= twires?

    --_000_74146A02B37E4BF6877C054542530089nominumcom_-- From zehn.cao@gmail.com Thu Apr 19 22:48:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3CA21F8731 for ; Thu, 19 Apr 2012 22:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isBUnGC2qF7p for ; Thu, 19 Apr 2012 22:48:01 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06BA721F8730 for ; Thu, 19 Apr 2012 22:48:00 -0700 (PDT) Received: by iazz13 with SMTP id z13so15733189iaz.31 for ; Thu, 19 Apr 2012 22:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=iefbgohvolVH/WEEs9R3lEALPpaUBVxDxPncMMWlF+c=; b=XnwraWDNdD1MpncfG01RuDU1zOEB06ME5CKY331/ojb3KJQVkPUlnNUzOyBrAkDmKa GLsZvTK6eUMUXzdDSYBPCOSgX27BcUOMDaokJT2Sri5ehk0kc3pmQtbUDPUqA/Gv9bHa AkFjIzrC0fBmZdobW1xCZHSfYN6Zu6KaEQqxXMutJKb5PVyaV7QKtmudL3EcNSdyPGWt ZIbgDzKnpj/N1sbBiIcEUbUHTbZwcA2TkgdayJsX7uSS++Dco0/P/H0H1PNAfQHIApJY DBZtvvUbphg3xS8jWMqI0hRkYRvB1QkUMc3DnGLmGAtOzoN0M20fWn675kohjDOUZkiP QrLw== MIME-Version: 1.0 Received: by 10.50.40.228 with SMTP id a4mr5394199igl.60.1334900880458; Thu, 19 Apr 2012 22:48:00 -0700 (PDT) Received: by 10.42.76.72 with HTTP; Thu, 19 Apr 2012 22:48:00 -0700 (PDT) In-Reply-To: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> References: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> Date: Fri, 20 Apr 2012 13:48:00 +0800 Message-ID: From: Zhen Cao To: Ted Lemon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: DHC WG Subject: Re: [dhcwg] Call for adoption: draft-jiang-addr-registration X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 05:48:01 -0000 This draft is in a good shape and I support. On Wed, Apr 18, 2012 at 9:40 AM, Ted Lemon wrote: > (We tentatively adopted quite a few drafts in the meeting, so we're tryin= g to space out the calls for adoption and last calls a bit=97I hope the aut= hors will bear with us.) > > The addr-registration draft proposes a mechanism for allowing clients to = autoconfigure their address and then register that address with the DHCP se= rver. =A0 At the meeting in Paris, there was strong consensus to adopt this= as a working group item. =A0 One of the authors has requested a call for a= doption to the mailing list. > > We already had sufficient consensus in Paris to adopt, but it's possible = that there are people on the mailing list who were not present in Paris who= might object. =A0 So for this reason, if you are in favor of adopting the = draft, even if you raised your hand in Paris, please signify in a reply to = this message. =A0 If you are against adopting the draft, please signify as = well. > > We will determine consensus on May 1, 2012. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=20 Best regards, Zhen From pengwu.thu@gmail.com Fri Apr 20 02:52:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FCC21F8744 for ; Fri, 20 Apr 2012 02:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9A-Tbza7mCy for ; Fri, 20 Apr 2012 02:52:35 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D93EF21F8738 for ; Fri, 20 Apr 2012 02:52:35 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so883179pbb.31 for ; Fri, 20 Apr 2012 02:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vZFhybqQoYRAt/PtyuAPoNKBIzvfhvE1A+oQhyHyzzs=; b=zcRdma6bJYScnVz2wzf3jSaB0fhaSoNPhG/TfRNLHoP/4ldQlOYar11D/Sbek35MGP Dorv143oRyncDdPCoyoEbC9HI2l/0z0kcb3HyKKCw+1hcgVM7M3ghSxALZUnS1iJ++Q8 1fhfXIcmVuEsvbk9jGk9CAct4pdPmbBLbronyHa4kbcmaEqh1r04BD5RJJKjllBDabZB 7KvLeEPOcoTQhrBnNI3hMpqIDP4n1/eMUSkxsnvAStjETDnBqiA6iJ+pu6OKUAmIbhwq aXuFtPEIrMEiZoBs3iDWlE7daNjHbx4TKhlsWO2mu9FW0hweZrWP44u6ZgNIfnfFOCL9 qc4A== MIME-Version: 1.0 Received: by 10.68.217.201 with SMTP id pa9mr11979952pbc.73.1334915555703; Fri, 20 Apr 2012 02:52:35 -0700 (PDT) Received: by 10.68.213.129 with HTTP; Fri, 20 Apr 2012 02:52:35 -0700 (PDT) In-Reply-To: <96DD85EB136DCD49AB5CDB6DEC9639AD058565F0@CH1PRD0310MB368.namprd03.prod.outlook.com> References: <201204161209.q3GC90RH089072@givry.fdupont.fr> <96DD85EB136DCD49AB5CDB6DEC9639AD0584DBA9@CH1PRD0310MB368.namprd03.prod.outlook.com> <96DD85EB136DCD49AB5CDB6DEC9639AD05851197@CH1PRD0310MB368.namprd03.prod.outlook.com> <99591DAE-D8CD-4F06-BEFE-9679D3A36A78@nominum.com> <96DD85EB136DCD49AB5CDB6DEC9639AD058565F0@CH1PRD0310MB368.namprd03.prod.outlook.com> Date: Fri, 20 Apr 2012 17:52:35 +0800 Message-ID: From: Peng Wu To: Dmitry Anipko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org" , Francis Dupont , Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 09:52:36 -0000 Dmitry, > As I understand, your comment rather relates to =93assuming this specific > requirement (same CRA used by multiple tunnel endpoints) must be included= in > the text, what the solution is=94. That=92s a different question, which o= nly > appears if there is a requirement for same CRA to serve multiple tunnel > endpoints (as opposed to e.g. having per tunnel endpoint CRA). Are there > reasons to have that as a requirement? I think it somehow reflects your original concern. Because in some cases we cannot simply require multiple IPv6 addresses to satisfy multiple CRAs. BTW, I think about this again and find that , even if we can require multiple IPv6 addresses since all the DHCP messages are broadcasted on the same link, we may still require different client IDs to clarify which CRA to serve which messages. So it's really about request multiple addresses through ONE link with broadcast. My answer to this is, from Softwire perspective, we currently don't have use case for that. One tunnel, one CRA, one client, that's all. >From DHC perspective, it's reasonable to raise the doubt that, now that a relay is put inside the host, and if the host have multiple tunnels which requires one IPv4 address each, how does the relay behave ( as you've raised in Paris). About the solution, I'm starting to think that AS LONG AS we require multiple IPv4 addresses on ONE link with broadcast, we need multiple client IDs. If we have a *one-for-all* client runs on the physical interface, it will need multiple state machines. If we have multiple clients run on different VIFs (which Francis emphasised is not a good idea), we need some extra implementation effort to achieve the message "transmission" between the VIF and the physical interface. In the first case, multiple CRAs won't help; in the second case, the message can be "transmitted" to different CRAs directly inside the host, so we won't need the aid from client id (at the cost of extra implemenation). What do you guys think? If we settle this, I think we should make a fast revision (Francis has aleady raised some review inputs on the other thread) and try to request WGLC. From daryl.tanner@blueyonder.co.uk Fri Apr 20 06:08:43 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0302D21F86D5 for ; Fri, 20 Apr 2012 06:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9NdkVOg7ZsV for ; Fri, 20 Apr 2012 06:08:42 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6610721F86D6 for ; Fri, 20 Apr 2012 06:08:42 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so9410567obb.31 for ; Fri, 20 Apr 2012 06:08:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=VUXhnqHOrHFcsyptNnjzq2DCbdOYW1+ZaX+21jU7JPw=; b=gny20IZTH5DM6rRpl5Rtw3yXn/ClaU5eFIVm+79yt9CA8xxxJpMOvOzzMGjWveh/kv 7v+IojrhLNl60lBKbBW0EEX3eVq869XfZ0og6mNzstMVkcxfKa6bp4Q9pO69TflGpNMA oZDQ3aEkLZ7HloMMdpVMN0DigeSIOdRyXejOWdmV4Zk9hs0ESkxc8vVnJ8Ejwq5yXDtM gRlRT3PNqr9oJUSvvcdC+ajloiyV5324HpFK1a6GPDUhBZpwGI55Ro7VX1h3kYMlB5ar hghLLH8mn3TDXuVRvbHmgvvHTxfayygBQHUe+0TfhQx4hevPrG9cXA5AsOZxJGuzh9bh zLNA== MIME-Version: 1.0 Received: by 10.182.74.42 with SMTP id q10mr844472obv.52.1334927321777; Fri, 20 Apr 2012 06:08:41 -0700 (PDT) Received: by 10.60.119.97 with HTTP; Fri, 20 Apr 2012 06:08:41 -0700 (PDT) X-Originating-IP: [92.239.43.71] In-Reply-To: <4F8E6C74.8070109@gmail.com> References: <0E790F85-E713-411D-B8F7-FA9AD227A725@cisco.com> <3EDFBB28-0DC4-4E6F-BFD8-315064ED9A1E@nominum.com> <4F8E6C74.8070109@gmail.com> Date: Fri, 20 Apr 2012 14:08:41 +0100 Message-ID: From: Daryl Tanner To: Tomek Mrugalski Content-Type: multipart/alternative; boundary=f46d04447129d0c72104be1bfc6c X-Gm-Message-State: ALoCoQk4FD/Bm6LwDTZa3tU1RyuvbmjF+vMQ4q/lIWmJK2Dwe2pmFJECb7p1jQqZ3DExDJTxFuai Cc: DHC WG , Ted Lemon , Kim Kinnear Subject: Re: [dhcwg] Fwd: Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-design-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 13:08:43 -0000 --f46d04447129d0c72104be1bfc6c Content-Type: text/plain; charset=ISO-8859-1 I also support the adoption of this draft as a DHC WG work item. Thanks Daryl On 18 April 2012 08:25, Tomek Mrugalski wrote: > On 12-04-17 16:19, Ted Lemon wrote: > > Yes, please. It's a lot of extra work for us to count the authors > > differently than other wg participants. > In that case I support this work as well. > > Tomek > co-author > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --f46d04447129d0c72104be1bfc6c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I also support the adoption of this draft as a DHC WG work item.

    Tha= nks
    Daryl

    On 18 April 2012 08:25, Tome= k Mrugalski <tomasz.mrugalski@gmail.com> wrote:
    On 12-04-17 16:19, Ted Lem= on wrote:
    > Yes, please. =A0 It's a lot of extra work for us to count the auth= ors
    > differently than other wg participants.
    In that case I support this work as well.

    Tomek
    co-author
    ___________________________________= ____________
    dhcwg mailing list
    dhcwg@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/dhcwg

    --f46d04447129d0c72104be1bfc6c-- From Dmitry.Anipko@microsoft.com Fri Apr 20 14:41:08 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76C321E801C for ; Fri, 20 Apr 2012 14:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.007 X-Spam-Level: X-Spam-Status: No, score=-1.007 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tIYA7xkleZr for ; Fri, 20 Apr 2012 14:41:08 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADB411E8074 for ; Fri, 20 Apr 2012 14:41:08 -0700 (PDT) Received: from mail94-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Apr 2012 21:41:07 +0000 Received: from mail94-va3 (localhost [127.0.0.1]) by mail94-va3-R.bigfish.com (Postfix) with ESMTP id A00F4402F9 for ; Fri, 20 Apr 2012 21:41:07 +0000 (UTC) X-SpamScore: -25 X-BigFish: VS-25(zz9371I1418I98dKzz1202hzz1033IL8275bhz2fh2a8h683h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail94-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail94-va3 (localhost.localdomain [127.0.0.1]) by mail94-va3 (MessageSwitch) id 1334958065523610_12337; Fri, 20 Apr 2012 21:41:05 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.254]) by mail94-va3.bigfish.com (Postfix) with ESMTP id 7C10C320045 for ; Fri, 20 Apr 2012 21:41:05 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Apr 2012 21:41:05 +0000 Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.283.4; Fri, 20 Apr 2012 21:41:04 +0000 Received: from mail39-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Apr 2012 21:40:31 +0000 Received: from mail39-tx2 (localhost [127.0.0.1]) by mail39-tx2-R.bigfish.com (Postfix) with ESMTP id 3FA9F3E01EA for ; Fri, 20 Apr 2012 21:40:31 +0000 (UTC) Received: from mail39-tx2 (localhost.localdomain [127.0.0.1]) by mail39-tx2 (MessageSwitch) id 1334958029206845_27949; Fri, 20 Apr 2012 21:40:29 +0000 (UTC) Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.249]) by mail39-tx2.bigfish.com (Postfix) with ESMTP id 2BEE080050; Fri, 20 Apr 2012 21:40:29 +0000 (UTC) Received: from CH1PRD0310HT001.namprd03.prod.outlook.com (157.56.244.37) by TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Apr 2012 21:40:28 +0000 Received: from CH1PRD0310MB368.namprd03.prod.outlook.com ([169.254.8.184]) by CH1PRD0310HT001.namprd03.prod.outlook.com ([10.255.137.36]) with mapi id 14.16.0152.000; Fri, 20 Apr 2012 21:40:24 +0000 From: Dmitry Anipko To: Ted Lemon Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces Thread-Index: AQHNHSSLRzTBf+Nc20mYBKCZuRJ2F5ahlZaQgACWZACAANkkoIAADcKAgAEr2XA= Date: Fri, 20 Apr 2012 21:40:24 +0000 Message-ID: <96DD85EB136DCD49AB5CDB6DEC9639AD0585B13D@CH1PRD0310MB368.namprd03.prod.outlook.com> References: <201204161209.q3GC90RH089072@givry.fdupont.fr> <96DD85EB136DCD49AB5CDB6DEC9639AD0584DBA9@CH1PRD0310MB368.namprd03.prod.outlook.com> <96DD85EB136DCD49AB5CDB6DEC9639AD05851197@CH1PRD0310MB368.namprd03.prod.outlook.com> <99591DAE-D8CD-4F06-BEFE-9679D3A36A78@nominum.com> <96DD85EB136DCD49AB5CDB6DEC9639AD058565F0@CH1PRD0310MB368.namprd03.prod.outlook.com> <74146A02-B37E-4BF6-877C-054542530089@nominum.com> In-Reply-To: <74146A02-B37E-4BF6-877C-054542530089@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NOMINUM.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%FDUPONT.FR$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "dhcwg@ietf.org" , Francis Dupont Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 21:41:09 -0000 >> The suggestion that there should be such a requirement was raised by som= eone else Sorry if there was miscommunication, that's not what I meant. My comment on= the list (and I believe, at the meeting) was: "... discusses whether multi= ple IPV4 interfaces are in scope, and if they are - what are the possible w= ays how they can be handled, and what's the recommended way.".=20 Having single CRA to serve multiple tunnel interfaces is one way to handle = such scenario, but may be not the only one, and it is also possible to decl= are scenario not supported/out of scope.=20 All I meant to say, if I didn't communicate clearly, was that the current d= raft is not fully clear about what's supported in this case, and if somethi= ng is supported, how an implementation should support it in terms of CRA/tu= nnel mapping. E.g. if the authors prefer to declare scenario out of scope,= and implementers are fine with it, I think that's a fine option. From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Thursday, April 19, 2012 8:35 PM To: Dmitry Anipko Cc: dhcwg@ietf.org; Francis Dupont Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 int= erfaces On Apr 19, 2012, at 10:55 PM, Dmitry Anipko =A0wrote: That's a different question, which only appears if there is a requirement f= or same CRA to serve multiple tunnel endpoints (as opposed to e.g. having p= er tunnel endpoint CRA). Are there reasons to have that as a requirement? I don't think so, no. =A0 The suggestion that there should be such a requir= ement was raised by someone else; I thought it was you, but maybe you were = just raising a question that had been raised by someone else in softwires? From leaf.y.yeh@huawei.com Sat Apr 21 03:06:49 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C08A21F8603 for ; Sat, 21 Apr 2012 03:06:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWxq1Ulco5jM for ; Sat, 21 Apr 2012 03:06:44 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 59D0D21F85FF for ; Sat, 21 Apr 2012 03:06:44 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFK27555; Sat, 21 Apr 2012 06:06:44 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 21 Apr 2012 03:06:13 -0700 Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 21 Apr 2012 03:06:10 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.29]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Sat, 21 Apr 2012 18:06:03 +0800 From: Leaf yeh To: Tomek Mrugalski , DHC WG Thread-Topic: [dhcwg] Comments on draft-yeh-dhc-dhcpv6-authorization-opt-00 Thread-Index: AQHNFdPr5k96sli/tU2T9ZwO7CstHpak5ycA Date: Sat, 21 Apr 2012 10:06:02 +0000 Message-ID: References: <4F820BF0.60707@gmail.com> In-Reply-To: <4F820BF0.60707@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.39.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] Comments on draft-yeh-dhc-dhcpv6-authorization-opt-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2012 10:06:49 -0000 SGkgVG9tZWssIA0KDQpGaXJzdCBhbmQgZm9yZW1vc3QsIHRoYW5rcyBmb3IgeW91ciBjb25zdHJ1 Y3RpdmUgY29tbWVudHMgaW4gZGV0YWlsLiBSZWFsbHkgYXBwcmVjaWF0ZWQuDQoNClRoZSBmb2xs b3dpbmcgYXJlIHRoZSByZXBseSB0byB5b3VyIGNvbW1lbnRzLg0KDQpUb21lay0gSSBhZ3JlZSB3 aXRoIFRlZCdzIGFuZCBCZXJuaWUncyBjb21tZW50cy4gUGxlYXNlIHBpY2sgZGVzaWduIDIgYW5k IG1ha2UgdGhpcyBhIHNpbmdsZSBvcHRpb24gdGhhdCBpcyBhIGNvbnRhaW5lciBmb3IgYW55IFJh ZGl1cyBvcHRpb25zLg0KDQpEZXNpZ24tMiAoc2FtZSBhcyBSRkM0MDE0KSBzb3VuZHMgYSBzaW1w bGVyIHNlbGVjdGlvbiBmb3IgdXMgaW4gdGhlIGRlc2lnbiwgYnV0IGl0IHdpbGwgY291cGxlIHdp dGggdGhlIFJBRElVUyBhdHRyaWJ1dGVzIChvciBwcm90b2NvbCksIGJlY2F1c2UgdGhlIERIQ1B2 NiBzZXJ2ZXIgd2lsbCB0YWtlIHJlc3BvbnNpYmlsaXR5IHRvIGludGVycHJldCB0aGVzZSBSQURJ VVMgYXR0cmlidXRlcy4gUkFESVVTIGF0dHJpYnV0ZXMgKG9yIHByb3RvY29sKSB3aWxsIGV4dGVu ZCB0byBoYXZlIHNvbWUgbmV3IGtpbmQgb2YgJ2Jhc2ljIGRhdGEgdHlwZScsIGUuZy4gbmVzdGlu ZyBUTFYsIHBlciBkcmFmdC1pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5zaW9ucywgYmVjYXVzZSB0 aGUgdW5hc3NpZ25lZCBzdGFuZGFyZCB0eXBlIHNwYWNlICgxNjEtMTkwKSB3aWxsIHNvb24gZXho YXVzdGVkLiBESENQdjYgb3B0aW9ucyBzdXBwb3J0IG11bHRpLWZpZWxkcyBkZXNpZ24gbmF0aXZl bHksIGJ1dCBSQURJVVMgZG9lcyBub3QgYmVmb3JlLiBTdXBwb3NlZCBJU0MgJiBDaXNjbyBtaWdo dCBhbHJlYWR5IHN1cHBvcnQgUkZDNDAxNCwgYW5kIHRoYXQgbWFrZSB5b3UgdGVuZCB0byBwcmVm ZXIgZGVzaWduLTIuIEJ1dCBhcyBhIG5hdGl2ZSBESEMgZ3V5LCBJIHByZWZlcnJlZCBkZXNpZ24t MSBiZWZvcmUuIA0KDQpBbnl3YXksIEkgd2lsbCBmb2xsb3cgeW91ciAoQmVybmllICYgeW91KSBj b21tZW50cyB0byB1c2UgRGVzaWduLTIgaW4gZHJhZnQteWVoLTAxIGZvciB0aGUgZnVydGhlciBz dGVwICYgZGlzY3Vzc2lvbi4NCg0KVG9tZWsgLSBGb3Igc3BlY2lmaWMgdXNlIGNhc2VzIGF1dGhv ciBjaG9zZSAyIG9wdGlvbnM6IHBvb2wgbmFtZSBhbmQgcHJlZml4IGF1dGgsIGJ1dCBJJ20gc3Vy ZSB0aGVyZSBhcmUgY2FzZXMgd2hlbiBvdGhlciBSYWRpdXMgYXR0cmlidXRlcyBtYXkgYmUgdXNl ZnVsLiBUaGVyZSBhcmUgMTYwDQpSYWRpdXMgYXR0cmlidXRlcyBkZWZpbmVkIHNvIGZhci4NCg0K V2hlbiBJIHBpY2sgYSBsaXN0IG9mIElQdjYgUkFESVVTIGF0dHJpYnV0ZXMgZnJvbSBodHRwOi8v d3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3JhZGl1cy10eXBlcy9yYWRpdXMtdHlwZXMueG1sI3Jh ZGl1cy10eXBlcy0xIGFzIFJGQzQwMTQgZGlkIGJlZm9yZSwgKHdoaWNoIG9ubHkgcGlja2VkIDYg UkFESVVTIGF0dHJpYnV0ZXMpLCBvbmx5IHRoZSBmb2xsb3dpbmcgbGltaXRlZCBjb2RlIG51bWJl cnMgYXJlIGludm9sdmVkIGluIHRoZSBkcmFmdC15ZWgtMDEuDQoNClR5cGUgQ29kZSAgICBBdHRy aWJ1dGUgICAgICAgICAgICAgICAgICAgICBSZWZlcmVuY2UNCjI2ICAgICAgICAgICBWZW5kb3It U3BlY2lmaWMgICAgICAgICAgICAgICBSRkMyODY1DQo4OCAgICAgICAgICAgRnJhbWVkLVBvb2wg ICAgICAgICAgICAgICAgICAgUkZDMjg2OQ0KMTIzICAgICAgICAgIERlbGVnYXRlZC1JUHY2LVBy ZWZpeCAgICAgICAgIFJGQzQ4MTgNClRCRCAgICAgICAgICBGcmFtZWQtSVB2Ni1BZGRyZXNzICAg ICAgICAgICBpZXRmLXJhZGV4dC1pcHY2LWFjY2Vzcy0wNg0KDQpIb3BlIHdlIGNvdWxkIGZpbmQg bW9yZS4gSSBjYW4ndCBldmVuIGZpbmQgUkFESVVTIGF0dHJpYnV0ZSBhc3NvY2lhdGVkIHdpdGgg RE5TIGluIHRoZSBhc3NpZ25lZCBzdGFuZGFyZCBzcGFjZSwgdGhvdWdoIEh1YXdlaS1WU0EgKDI2 KSBoYXMgc3VwcG9ydGVkIGl0Lg0KDQpUb21layAtIDEuIEludHJvZHVjdGlvbiAtIEknbSBub3Qg c3VyZSBpZiBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoIGFib3V0IERIQ1B2NiB3aXRoIGFsbCByZWZl cmVuY2VzIHRvIGFsbCB0aG9zZSBSRkNzIGlzIG5lZWRlZC4gSWYgeW91IHRoaW5rIHRoYXQgaXMg dXNlZnVsLCBhIG9uZSBzaG9ydCBzZW50ZW5jZSB3aXRoIHJlZmVyZW5jZSB0byAzMzE1IHdpbGwg ZG8gdGhlIHRyaWNrLiBJZiB5b3UgcmVhbGx5IHdhbnQgdG8ga2VlcCB0aG9zZSByZWZlcmVuY2Vz LCBtYWtlIG1vc3Qgb2YgdGhlbSBpbmZvcm1hdGl2ZS4gTm9ybWF0aXZlIHJlZmVyZW5jZXMgYXJl IHRoZSBvbmVzIHRoYXQgYXJlIHJlcXVpcmVkIHRvIHVuZGVyc3RhbmQgeW91ciBwcm9wb3NhbC4g SW4gdGhpcyBjb250ZXh0IFJGQzM2NDYgaXMgaW5mb3JtYXRpdmUgYXMgaXQgb25seSBwcm92aWRl cyBiYWNrZ3JvdW5kIGluZm9ybWF0aW9uLg0KDQpBY2NlcHRlZCBpbiBkcmFmdC15ZWgtMDEuIEkg bW92ZWQgUkZDMzE2MiwgUkZDMzYzMywgUkZDMzY0NiBpbnRvIEluZm9ybWF0aXZlIFJlZmVyZW5j ZXMgKHNlY3Rpb24gMTEuMikuDQoNClRvbWVrIC0gMi4gSSB3b3VsZCBzdHJvbmdseSBzdWdnZXN0 IHRvIHJlbmFtZSB0aGF0IG9wdGlvbiB0byBPUFRJT05fUkFESVVTLiBUaGlzIG5hbWUgd2lsbCBp bnN0YW50bHkgdGVsbCBldmVyeW9uZSB3aGF0IHRoYXQgb3B0aW9uIGNvbnZleXMuIEF1dGhvcml6 YXRpb24gbWF5IG1lYW4gbWFueSBkaWZmZXJlbnQgdGhpbmdzIGluIGRpZmZlcmVudCBjb250ZXh0 cy4NCg0KQWNjZXB0ZWQgaW4gZHJhZnQteWVoLTAxLCB0aG91Z2ggSSB0aG91Z2ggdGhlIHRoaXMg b3B0aW9uIGlzIG9ubHkgYXNzb2NpYXRlZCB0byB0aGUgMm5kIEEgaW4gdGhlIEFBQSBzZXJ2ZXIg KD1SQURJVVMgc2VydmVyKSBoZXJlLiA6LSkNCg0KVG9tZWsgLSAzLiBJbiBvcHRpb24gZm9ybWF0 IHNwZWNpZmllZCBpbiBTZWN0aW9uIDQsIG9wdGlvbiBuYW1lIGlzIHR5cGljYWxseSB3cml0dGVu IGluIGFsbCB1cHBlcmNhc2UgKE9QVElPTl9BVVRIT1JJWkFUSU9OIHJhdGhlciB0aGFuIE9wdGlv bl9BdXRob3JpemF0aW9uKS4NCg0KQWNjZXB0ZWQsIE9QVElPTl9SQURJVVMgd2lsbCBhcHBlYXIg aW4gZHJhZnQteWVoLTAxLg0KDQpUb21layAtIDQuIFNlY3Rpb24gdGhhdCBkZWZpbmVzIGFuIG9w dGlvbiBvZnRlbiBicmllZmx5IHNwZWNpZmllcyBpdCB1c2FnZS4gSXQgbWF5IGJlIHVzZWZ1bCB0 byBhZGQgY291cGxlIG9mIHNlbnRlbmNlcyB0aGVyZTogQ2xpZW50IE1VU1QgTk9UIHNlbmQgdGhp cyBvcHRpb24uIENsaWVudCBNVVNUIGlnbm9yZSB0aGlzIG9wdGlvbiBpZiByZWNlaXZlZC4gUmVs YXlzIE1BWSBpbmNsdWRlIHRoaXMgb3B0aW9uIGluIFJFTEFZLUZPUlcgbWVzc2FnZXMuIFNlcnZl ciBTSE9VTEQgTk9UL01VU1QgTk9UIGluY2x1ZGUgaXQgaW4gUkVMQVktUkVQTCBtZXNzYWdlcy4N Cg0KQWNjZXB0ZWQgaW4gZHJhZnQteWVoLTAxLg0KDQpUb21layAtIDUuIEkgd291bGQgcmV3b3Jk IGZpcnN0IHNlbnRlbmNlIGluICJSZWxheSBBZ2VudCBCZWhhdmlvciIgKHNlY3Rpb24gNikuICJU aGUgREhDUHY2IHJlbGF5IGFnZW50IG11c3QgaW5jbHVkZSBPcHRpb25fQXV0aG9yaXphdGlvbiBp biB0aGUgcmVsYXktZm9yd2FyZCAoMTIpIG1lc3NhZ2UuLi4iID0+ICJUaGUgREhDUHY2IHJlbGF5 IGFnZW50IHRoYXQgc3VwcG9ydHMgdGhpcyBtZWNoYW5pc20gU0hPVUxEIGluY2x1ZGUgT1BUSU9O X1JBRElVUyBpbiB0aGUgcmVsYXktZm9yd2FyZCBtZXNzYWdlLi4uIi4oU0hPVUxEIGluc3RlYWQg b2YgbXVzdCkuDQoNCkFjY2VwdGVkIGluIGRyYWZ0LXllaC0wMS4NCg0KVG9tZWsgLSA3LiBOZWdh dGl2ZSBjYXNlLiBJJ20gbm90IHN1cmUgaWYgSSB1bmRlcnN0YW5kIHRoYXQgY29ycmVjdGx5LCBi dXQgd2hhdCBoYXBwZW5zIGlmIGEgY2xpZW50IGlzIG5vdCBhdXRob3JpemVkIGJ5IFJhZGl1cz8g U2hvdWxkIHJlbGF5IGRyb3AgdGhlIG1lc3NhZ2U/IE9yIGRvIHlvdSB3YW50IHJlbGF5IHRvIGZv cndhcmQgY2xpZW50J3MgbWVzc2FnZSB3aXRoIHRoZSBuZWdhdGl2ZSByYWRpdXMgcmVzcG9uc2Ug YW5kIGZpbmFsbHkgc2VydmVyIGlzIGV4cGVjdGVkIHRvIG5vdCBhc3NpZ24gYWRkcmVzc2VzL3By ZWZpeGVzPyBTb21lIGtpbmQgb2YgY2xhcmlmaWNhdGlvbiBhYm91dCB0aGF0IGNvdWxkIGJlIHVz ZWZ1bC4NCg0KSSB0aGluayB0aGUgRmlnLjEgb3IgRmlnLjIgd2lsbCBhbnN3ZXIgdGhpcyBxdWVz dGlvbi4gSWYgdGhlIGF1dGhvcml6YXRpb24gdGhyb3VnaCBSQURJVVMgZmFpbHMsIHRoZW4gdGhl IG1lc3NhZ2Ugc2VxdWVuY2Ugc2hvd24gaW4gdGhlIGZpZ3VyZXMgd2lsbCBzdG9wLiBUaGUgcmVs YXkgd2lsbCBub3QgZm9yd2FyZCB0aGUgbWVzc2FnZSBmcm9tIHRoZSBjbGllbnQuIFdpbGwgY2xh cmlmaWVkIGluIHNlY3Rpb24gMyBvZiBkcmFmdC15ZWgtMDEuDQoNClRvbWVrIC0gOC4gSW4gc2Vj dGlvbiA2LiB5b3Ugc2hvdWxkIGFsc28gbWVudGlvbiB0aGF0IHJlbGF5IE1VU1QgaWdub3JlIHJl Y2VpdmVkIGluY29taW5nIE9QVElPTl9SQURJVVMgKHNlcnZlciBzaG91bGQgbm90IGVjaG8gaXQg YmFjaywgcmlnaHQ/KS4NCg0KWWVzLCB0aGUgc2VydmVyIHdpbGwgbm90IGJlIG5lY2Vzc2FyeSB0 byBlY2hvIE9QVElPTl9SQURJVVMgYmFjaywgdGhlIHJlYXNvbiBpcyB0aGUgQWNjZXNzLUFjY2Vw dCBvZiBSQURJVVMgbmVlZCBub3QgdG8gYmUgcmVwbGllZC4gQWNjZXB0ZWQgaW4gZHJhZnQteWVo LTAxLiANCg0KVG9tZWsgLSA5LiBJbiAiU2VydmVyIEJlaGF2aW9yIiBzZWN0aW9uIGl0IGlzIGJl dHRlciB0byBzYXk6ICJUaGUgREhDUHY2IHNlcnZlciBNQVkgdXNlIHJlY2VpdmVkIFJBRElVUyBv cHRpb24gdG8gcGljayBhcHByb3ByaWF0ZSBhZGRyZXNzZXMsIG9wdGlvbnMgYW5kIGRlbGVnYXRl IHByZWZpeGVzLiIuDQoNCkhvdyBhYm91dCB0aGUgZm9sbG93aW5nIHRleHQ6ICJBZnRlciB0aGUg UkVMQVktRk9SVyBtZXNzYWdlIHdpdGggT1BUSU9OX1JBRElVUyBhcnJpdmVkLCB0aGUgREhDUHY2 IHNlcnZlciBTSE9VTEQgZXh0cmFjdCBhbmQgaW50ZXJwcmV0IHRoZSBSQURJVVMgYXR0cmlidXRl cyBpbiB0aGUgT1BUSU9OX1JBRElVUywgYW5kIHVzZSB0aGF0IGluZm9ybWF0aW9uIGluIHNlbGVj dGluZyBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMgZm9yIHRoZSBjbGllbnQuIElmIHRoZSBESENQ djYgc2VydmVyIGRvZXMgbm90IHN1cHBvcnQgT1BUSU9OX1JBRElVUyB5ZXQsIHRoZSBESENQdjYg c2VydmVyIE1BWSBpZ25vcmUgdGhpcyBvcHRpb24uIj8NCg0KVG9tZWsgLSAxMC4gU29tZXRoaW5n IHRvIHRoYXQgZWZmZWN0IHNob3VsZCBiZSBhZGRlZCBpbiBTZWN0aW9uIDcuIEFsc28sIGluIEZp Zy4gMSB5b3UgY291bGQgYWRkIGV4dHJhIHNwYWNlIGJldHdlZW4gKE9wdGlvbl9BdXRob3JpemF0 aW9uKSBhbmQgUmVsYXktcmVwbHkgbGluZXMgdG8gc2hvdyB0aGF0IEF1dGhvcml6YXRpb24vUmFk aXVzIG9wdGlvbiBpcyBleHBlY3RlZCB0byBhcHBlYXIgaW4gcmVsYXktZm9yd2FyZCBtZXNzYWdl IG9ubHksIG5vdCBpbiBib3RoIHJlbGF5LWZvcndhcmQgYW5kIHJlbGF5LXJlcGx5Lg0KDQpBY2Nl cHRlZCBpbiBkcmFmdC15ZWgtMDEuDQoNClRvbWVrIC0gMTIuIEFyZSB0aGVyZSBhbnkgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgdGhhdCBhcmUgc3BlY2lmaWMgdG8gUkFESVVTPyBZb3Ugc2hvdWxk IHByb2JhYmx5IHBvaW50IHRvIGEgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpbiBz b21lIFJBRElVUyBSRkMuDQoNCkFjY2VwdGVkIGluIGRyYWZ0LXllaC0wMS4NCg0KDQpCZXN0IFJl Z2FyZHMsDQpMZWFmDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZGhj d2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBUb21layBNcnVnYWxza2kNClNlbnQ6IE1vbmRheSwgQXByaWwgMDksIDIwMTIgNjow NyBBTQ0KVG86IERIQyBXRw0KU3ViamVjdDogW2RoY3dnXSBDb21tZW50cyBvbiBkcmFmdC15ZWgt ZGhjLWRoY3B2Ni1hdXRob3JpemF0aW9uLW9wdC0wMA0KDQpIaSwNCkkgZmluYWxseSBmb3VuZCBz b21lIHRpbWUgdG8gcmVhZCB0aGUgZHJhZnQuIEkgZG8gc3VwcG9ydCB0aGlzIHdvcmsgYW5kDQpp dHMgYWRvcHRpb24gKGlmIHJlcXVlc3RlZCksIGJ1dCBJIHN1Z2dlc3Qgc2V2ZXJhbCBjaGFuZ2Vz IHRvIHRoZSB0ZXh0Lg0KDQpGaXJzdCBhbmQgZm9yZW1vc3QsIEkgYWdyZWUgd2l0aCBUZWQncyBh bmQgQmVybmllJ3MgY29tbWVudHMuIFBsZWFzZQ0KcGljayBkZXNpZ24gMiBhbmQgbWFrZSB0aGlz IGEgc2luZ2xlIG9wdGlvbiB0aGF0IGlzIGEgY29udGFpbmVyIGZvciBhbnkNClJhZGl1cyBvcHRp b25zLg0KDQpIZXJlJ3MgbXkgb3BpbmlvbiB3aHkgZGVzaWduIDEgaXMgdmVyeSBiYWQuIEZvciBz cGVjaWZpYyB1c2UgY2FzZXMNCmF1dGhvciBjaG9zZSAyIG9wdGlvbnM6IHBvb2wgbmFtZSBhbmQg cHJlZml4IGF1dGgsIGJ1dCBJJ20gc3VyZSB0aGVyZQ0KYXJlIGNhc2VzIHdoZW4gb3RoZXIgUmFk aXVzIGF0dHJpYnV0ZXMgbWF5IGJlIHVzZWZ1bC4gVGhlcmUgYXJlIDE2MA0KUmFkaXVzIGF0dHJp YnV0ZXMgZGVmaW5lZCBzbyBmYXIuIFBsZWFzZSBkbyBub3QgdHVybiB0aGlzIGludG8gb25lIHRv DQpvbmUgUmFkaXVzIHRvIERIQ1B2NiBvcHRpb24gdHJhbnNsYXRvci4gTXVjaCBiZXR0ZXIgYXBw cm9hY2ggaXMgdG8NCmRlZmluZSBhIHNpbmdsZSBjb250YWluZXIgdGhhdCBjb252ZXlzIHJlcXVp cmVkIFJhZGl1cyBhdHRyaWJ1dGVzLiBEb24ndA0Kd29ycnkgYWJvdXQgZXh0cmEgcHJvY2Vzc2lu ZyByZXF1aXJlZCBvbiBESENQdjYgc2VydmVyIHNpZGUuIE1hbnkNCnNlcnZlcnMgYXJlIHNtYXJ0 IGVub3VnaCB0byBkbyBwcm9jZXNzaW5nIG9mIHJlY2VpdmVkIG9wdGlvbnMuIEZvcg0KZXhhbXBs ZSBJU0MgREhDUCBpcyBhYmxlIHRvIHBsYXkgdmFyaW91cyB0cmlja3MgbGlrZSBmYW5jeSB0byBz dHJpbmcNCmNvbnZlcnNpb24sIHN1Yi1zdHJpbmcgc2VhcmNoIGV0Yy4gSSdtIHN1cmUgb3RoZXIg aW1wbGVtZW50YXRpb25zIGNhbiBkbw0Kc2ltaWxhciBwcm9jZXNzaW5nLg0KDQpBbHNvLCB0aGF0 IGlzIHRoZSBzYW1lIGFwcHJvYWNoIHRoYXQgd2FzIGNob3NlbiBmb3IgREhDUHY0IChhcyBkZWZp bmVkDQppbiBSRkM0MDE0KS4gSXQgd29ya3MgaW4gdjQgYW5kIHRoZSBwcmluY2lwbGVzIGFyZSB0 aGUgc2FtZSwgc28ga2VlcCBpdA0KdGhlIHNhbWUgaW4gdjYuIEhhdmluZyBvbmUgY29udGFpbmVy IG9wdGlvbiBpcyBhbHNvIGZvcndhcmQgY29tcGF0aWJsZQ0Kd2l0aCBhbnkgbmV3IHJhZGl1cyBv cHRpb25zIHRoYXQgbWF5IGJlIGRlZmluZWQgaW4gdGhlIGZ1dHVyZS4NCg0KMS4gSW50cm9kdWN0 aW9uIC0gSSdtIG5vdCBzdXJlIGlmIGludHJvZHVjdG9yeSBwYXJhZ3JhcGggYWJvdXQgREhDUHY2 DQp3aXRoIGFsbCByZWZlcmVuY2VzIHRvIGFsbCB0aG9zZSBSRkNzIGlzIG5lZWRlZC4gSWYgeW91 IHRoaW5rIHRoYXQgaXMNCnVzZWZ1bCwgYSBvbmUgc2hvcnQgc2VudGVuY2Ugd2l0aCByZWZlcmVu Y2UgdG8gMzMxNSB3aWxsIGRvIHRoZSB0cmljay4NCklmIHlvdSByZWFsbHkgd2FudCB0byBrZWVw IHRob3NlIHJlZmVyZW5jZXMsIG1ha2UgbW9zdCBvZiB0aGVtDQppbmZvcm1hdGl2ZS4gTm9ybWF0 aXZlIHJlZmVyZW5jZXMgYXJlIHRoZSBvbmVzIHRoYXQgYXJlIHJlcXVpcmVkIHRvDQp1bmRlcnN0 YW5kIHlvdXIgcHJvcG9zYWwuIEluIHRoaXMgY29udGV4dCBSRkMzNjQ2IGlzIGluZm9ybWF0aXZl IGFzIGl0DQpvbmx5IHByb3ZpZGVzIGJhY2tncm91bmQgaW5mb3JtYXRpb24uDQoNCkkgdGhpbmsg c2ltcGxlIHJlZmVyZW5jZSB0byBwcmltYXJ5IFJhZGl1cyBJUHY2IFJGQyB3aWxsIGRvIGFzIHdl bGwuIEknbQ0Kbm90IGEgUmFkaXVzIGV4cGVydCwgc28gaXQgeW91IHRoaW5rIHRoYXQga2VlcGlu ZyB0aG9zZSBkZXRhaWxlZA0KcmVmZXJlbmNlcyBhcmUgdXNlZnVsLCBJIHdvbid0IG9iamVjdC4g UGxlYXNlIGNvbnNpZGVyIGlmIGFsbCBvZiB0aGVtDQptdXN0IGJlIGtlcHQgbm9ybWF0aXZlLCB0 aG91Z2guIFBlcmhhcHMgaW5mb3JtYXRpdmUgd2lsbCBiZSBlbm91Z2guDQoNCjIuIEkgd291bGQg c3Ryb25nbHkgc3VnZ2VzdCB0byByZW5hbWUgdGhhdCBvcHRpb24gdG8gT1BUSU9OX1JBRElVUy4g VGhpcw0KbmFtZSB3aWxsIGluc3RhbnRseSB0ZWxsIGV2ZXJ5b25lIHdoYXQgdGhhdCBvcHRpb24g Y29udmV5cy4NCkF1dGhvcml6YXRpb24gbWF5IG1lYW4gbWFueSBkaWZmZXJlbnQgdGhpbmdzIGlu IGRpZmZlcmVudCBjb250ZXh0cy4NCg0KMy4gSW4gb3B0aW9uIGZvcm1hdCBzcGVjaWZpZWQgaW4g U2VjdGlvbiA0LCBvcHRpb24gbmFtZSBpcyB0eXBpY2FsbHkNCndyaXR0ZW4gaW4gYWxsIHVwcGVy Y2FzZSAoT1BUSU9OX0FVVEhPUklaQVRJT04gcmF0aGVyIHRoYW4NCk9wdGlvbl9BdXRob3JpemF0 aW9uKS4NCg0KNC4gU2VjdGlvbiB0aGF0IGRlZmluZXMgYW4gb3B0aW9uIG9mdGVuIGJyaWVmbHkg c3BlY2lmaWVzIGl0IHVzYWdlLiBJdA0KbWF5IGJlIHVzZWZ1bCB0byBhZGQgY291cGxlIG9mIHNl bnRlbmNlcyB0aGVyZTogQ2xpZW50IE1VU1QgTk9UIHNlbmQNCnRoaXMgb3B0aW9uLiBDbGllbnQg TVVTVCBpZ25vcmUgdGhpcyBvcHRpb24gaWYgcmVjZWl2ZWQuIFJlbGF5cyBNQVkNCmluY2x1ZGUg dGhpcyBvcHRpb24gaW4gUkVMQVktRk9SVyBtZXNzYWdlcy4gU2VydmVyIFNIT1VMRCBOT1QvTVVT VCBOT1QNCmluY2x1ZGUgaXQgaW4gUkVMQVktUkVQTCBtZXNzYWdlcy4NCg0KNS4gSSB3b3VsZCBy ZXdvcmQgZmlyc3Qgc2VudGVuY2UgaW4gIlJlbGF5IEFnZW50IEJlaGF2aW9yIiAoc2VjdGlvbiA2 KS4NCiJUaGUgREhDUHY2IHJlbGF5IGFnZW50IG11c3QgaW5jbHVkZSBPcHRpb25fQXV0aG9yaXph dGlvbiBpbiB0aGUNCnJlbGF5LWZvcndhcmQgKDEyKSBtZXNzYWdlLi4uIiA9PiAiVGhlIERIQ1B2 NiByZWxheSBhZ2VudCB0aGF0IHN1cHBvcnRzIHRoaXMNCm1lY2hhbmlzbSBTSE9VTEQgaW5jbHVk ZSBPUFRJT05fUkFESVVTIGluIHRoZSByZWxheS1mb3J3YXJkIG1lc3NhZ2UuLi4iLg0KKFNIT1VM RCBpbnN0ZWFkIG9mIG11c3QpLg0KDQo2LiBJdCB3b3VsZCBiZSB1c2VmdWwgdG8gc2F5IHRoYXQg cmVsYXkgZG9lcyBub3QgaGF2ZSB0byBpbmNsdWRlIGFsbA0KUkFESVVTIGF0dHJpYnV0ZXMsIGp1 c3QgdGhvc2UgdGhhdCB3b3VsZCBiZSB1c2VmdWwuDQoNCjcuIE5lZ2F0aXZlIGNhc2UuIEknbSBu b3Qgc3VyZSBpZiBJIHVuZGVyc3RhbmQgdGhhdCBjb3JyZWN0bHksIGJ1dCB3aGF0DQpoYXBwZW5z IGlmIGEgY2xpZW50IGlzIG5vdCBhdXRob3JpemVkIGJ5IFJhZGl1cz8gU2hvdWxkIHJlbGF5IGRy b3AgdGhlDQptZXNzYWdlPyBPciBkbyB5b3Ugd2FudCByZWxheSB0byBmb3J3YXJkIGNsaWVudCdz IG1lc3NhZ2Ugd2l0aCB0aGUNCm5lZ2F0aXZlIHJhZGl1cyByZXNwb25zZSBhbmQgZmluYWxseSBz ZXJ2ZXIgaXMgZXhwZWN0ZWQgdG8gbm90IGFzc2lnbg0KYWRkcmVzc2VzL3ByZWZpeGVzPyBTb21l IGtpbmQgb2YgY2xhcmlmaWNhdGlvbiBhYm91dCB0aGF0IGNvdWxkIGJlIHVzZWZ1bC4NCg0KOC4g SW4gc2VjdGlvbiA2LiB5b3Ugc2hvdWxkIGFsc28gbWVudGlvbiB0aGF0IHJlbGF5IE1VU1QgaWdu b3JlIHJlY2VpdmVkDQppbmNvbWluZyBPUFRJT05fUkFESVVTIChzZXJ2ZXIgc2hvdWxkIG5vdCBl Y2hvIGl0IGJhY2ssIHJpZ2h0PykuDQoNCjkuIEluICJTZXJ2ZXIgQmVoYXZpb3IiIHNlY3Rpb24g aXQgaXMgYmV0dGVyIHRvIHNheTogIlRoZSBESENQdjYgc2VydmVyDQpNQVkgdXNlIHJlY2VpdmVk IFJBRElVUyBvcHRpb24gdG8gcGljayBhcHByb3ByaWF0ZSBhZGRyZXNzZXMsIG9wdGlvbnMNCmFu ZCBkZWxlZ2F0ZSBwcmVmaXhlcy4iLg0KDQoxMC4gSSBhc3N1bWUgdGhhdCBzZXJ2ZXIgZG9lcyBu b3QgZWNobyBSQURJVVMgb3B0aW9uIGJhY2ssIHJpZ2h0Pw0KU29tZXRoaW5nIHRvIHRoYXQgZWZm ZWN0IHNob3VsZCBiZSBhZGRlZCBpbiBTZWN0aW9uIDcuIEFsc28sIGluIEZpZy4gMQ0KeW91IGNv dWxkIGFkZCBleHRyYSBzcGFjZSBiZXR3ZWVuIChPcHRpb25fQXV0aG9yaXphdGlvbikgYW5kIFJl bGF5LXJlcGx5DQpsaW5lcyB0byBzaG93IHRoYXQgQXV0aG9yaXphdGlvbi9SYWRpdXMgb3B0aW9u IGlzIGV4cGVjdGVkIHRvIGFwcGVhciBpbg0KcmVsYXktZm9yd2FyZCBtZXNzYWdlIG9ubHksIG5v dCBpbiBib3RoIHJlbGF5LWZvcndhcmQgYW5kIHJlbGF5LXJlcGx5Lg0KDQoxMS4gV2hpbGUgY2xp ZW50cyBhcmUgbm90IGV4cGVjdGVkIHRvIGV2ZXIgc2VlIHRoaXMgb3B0aW9uLCBpdCB3b3VsZCBi ZQ0KZXhwbGljaXRlbHkgc3RhdGUgdGhhdCB1c2luZyBub3JtYXRpdmUgbGFuZ3VhZ2UuIFNvbWV0 aGluZyBsaWtlICJDbGllbnQNCk1VU1QgTk9UIHNlbmQgUkFESVVTIG9wdGlvbi4gQ2xpZW50IE1V U1QgaWdub3JlIHJlY2VpdmVkIFJBRElVUyBvcHRpb24uIg0KDQoxMi4gQXJlIHRoZXJlIGFueSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0aGF0IGFyZSBzcGVjaWZpYyB0byBSQURJVVM/DQpZb3Ug c2hvdWxkIHByb2JhYmx5IHBvaW50IHRvIGEgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlv biBpbiBzb21lDQpSQURJVVMgUkZDLg0KDQoxMy4gQXMgYSBzb2xlIGF1dGhvciwgSSdtIG5vdCBz dXJlIGlmIHRoYXQgbWFrZXMgc2Vuc2UgdG8gbWFyayB5b3VyIHJvbGUNCmFzIGVkaXRvci4NCg0K RGVzcGl0ZSBxdWl0ZSBhIGZldyBjb21tZW50cywgSSBzdXBwb3J0IHRoaXMgd29yay4gSXQgbG9v a3MgdXNlZnVsIGFuZA0KSSdtIHF1aXRlIHN1cnByaXNlZCB0aGF0IFJBRElVUyBvcHRpb24gd2Fz IG5vdCBkZWZpbmVkIHlldC4NCg0KQ2hlZXJzLA0KVG9tZWsNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkaGN3ZyBtYWlsaW5nIGxpc3QNCmRoY3dnQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo= From phdgang@gmail.com Mon Apr 23 00:22:33 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D41D21F8566 for ; Mon, 23 Apr 2012 00:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlfKctMHWMMy for ; Mon, 23 Apr 2012 00:22:32 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C1CAA21F84EB for ; Mon, 23 Apr 2012 00:22:31 -0700 (PDT) Received: by werb10 with SMTP id b10so8931282wer.31 for ; Mon, 23 Apr 2012 00:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=iaEefcK7pqSrd9ghlrCmdKTLSDgc7w7h3Bp97wiHHN0=; b=FsRZoKhfdVkSOxiUP0EWAsEUc2MTfK3nJCW2V2hb4PEGrmhqZlpf2nIcNcdAXbeo7D pLvJnOU6ZLLjefOy9jegv5obga7AV0L1LDZBJ68H8zRI4r8DK8Kekze0mLK+A2aiZA0z 8La2y029o+S69MdQymkIHvAk+hj3+gWzmzIQ0GorRDiVz5+5KyTzXvjJ1a7leZvKJ4zi amFRITx9p8CHxh59lsu3/CoAIpCoaBNS7e8SIiJFNYR2BDdODZN6fD0+R8w1Cr9yYej+ 0CQvWYbSB94Yq0yTK03qBL8zcILBGU3BUQ/JyAQC/y9BGuUZB3e4j0Mu2PnnCnc8heZP HzLg== MIME-Version: 1.0 Received: by 10.216.133.130 with SMTP id q2mr293324wei.24.1335165750538; Mon, 23 Apr 2012 00:22:30 -0700 (PDT) Received: by 10.180.106.38 with HTTP; Mon, 23 Apr 2012 00:22:30 -0700 (PDT) In-Reply-To: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> References: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> Date: Mon, 23 Apr 2012 15:22:30 +0800 Message-ID: From: GangChen To: Ted Lemon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: DHC WG Subject: Re: [dhcwg] Call for adoption: draft-jiang-addr-registration X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 07:22:33 -0000 Supporting adoption as wg item. That is useful for operators BRs Gang 2012/4/18, Ted Lemon : > (We tentatively adopted quite a few drafts in the meeting, so we're tryin= g > to space out the calls for adoption and last calls a bit=97I hope the aut= hors > will bear with us.) > > The addr-registration draft proposes a mechanism for allowing clients to > autoconfigure their address and then register that address with the DHCP > server. At the meeting in Paris, there was strong consensus to adopt th= is > as a working group item. One of the authors has requested a call for > adoption to the mailing list. > > We already had sufficient consensus in Paris to adopt, but it's possible > that there are people on the mailing list who were not present in Paris w= ho > might object. So for this reason, if you are in favor of adopting the > draft, even if you raised your hand in Paris, please signify in a reply t= o > this message. If you are against adopting the draft, please signify as > well. > > We will determine consensus on May 1, 2012. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From iesg-secretary@ietf.org Mon Apr 23 10:21:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732EB21F86E1; Mon, 23 Apr 2012 10:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHU09AzbKFuA; Mon, 23 Apr 2012 10:21:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9160421F86F4; Mon, 23 Apr 2012 10:21:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120423172130.15590.73925.idtracker@ietfa.amsl.com> Date: Mon, 23 Apr 2012 10:21:30 -0700 Cc: dhc mailing list , dhc chair , RFC Editor Subject: [dhcwg] Protocol Action: 'Rebind Capability in DHCPv6 Reconfigure Messages' to Proposed Standard (draft-ietf-dhc-dhcpv6-reconfigure-rebind-10.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 17:21:31 -0000 The IESG has approved the following document: - 'Rebind Capability in DHCPv6 Reconfigure Messages' (draft-ietf-dhc-dhcpv6-reconfigure-rebind-10.txt) as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-reconfigure-rebind/ Technical Summary This document updates RFC 3315 to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message, which extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. Working Group Summary This document received a thorough review by the WG, and had broad support. Document Quality We are not aware of any implementations. Personnel Ted Lemon is the Document Shepherd. Brian Haberman is the Responsible AD. RFC Editor Note The last sentence of Section 7 should be changed from: OLD: Cryptographically Generated Addresses (CGA) [RFC3972], can provide source address ownership validation, message origin authentication and message integrity without requesting symmetric key pairs or supporting from any key management system. NEW: Cryptographically Generated Addresses (CGA) [RFC3972] can provide source address (for the DHCP server/relay) ownership validation, message origin authentication, and message integrity without requiring symmetric key pairs or support from a key management system. From leaf.y.yeh@huawei.com Tue Apr 24 11:34:18 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487F621E80A0 for ; Tue, 24 Apr 2012 11:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aA8MYfiQx0zm for ; Tue, 24 Apr 2012 11:34:17 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BE22621E8042 for ; Tue, 24 Apr 2012 11:34:16 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFM54500; Tue, 24 Apr 2012 14:34:16 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Apr 2012 11:32:36 -0700 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Apr 2012 11:32:16 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.29]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Wed, 25 Apr 2012 02:32:30 +0800 From: Leaf yeh To: DHC WG Thread-Topic: [dhcwg] Fwd: Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-design-01 Thread-Index: AQHNHLKyKRxtiNiTRUqW+ZigiZQ9+paqMt17gAAlB0I= Date: Tue, 24 Apr 2012 18:32:29 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.70] Content-Type: multipart/alternative; boundary="_000_D5B918C624B442E282FE43BAABAE2135mimectl_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] Fwd: Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-design-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 18:34:18 -0000 --_000_D5B918C624B442E282FE43BAABAE2135mimectl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Though the design in this document looks very complicated, the solution for= the DHCPv6 failover or server redundancy sounds very important for the ind= ustry. I am interested to see the progress of this document officially in t= he WG, and +1 for the adoption as WG item. Best Regards, Leaf ________________________________ From: dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] on behalf of Ted Lemo= n [Ted.Lemon@nominum.com] Sent: Tuesday, April 17, 2012 23:56 To: DHC WG Subject: [dhcwg] Fwd: Requesting adoption of draft-mrugalski-dhc-dhcpv6-fai= lover-design-01 Just a reminder, we will determine consensus to adopt this draft on the 24t= h of April. If you want to see it adopted, and haven't said so already, p= lease do. If you don't think the wg should work on it and haven't said so= , please do. Begin forwarded message: From: Ted Lemon > Subject: Re: [dhcwg] Requesting adoption of draft-mrugalski-dhc-dhcpv6-fail= over-design-01 Date: April 10, 2012 10:13:56 AM EDT To: Tomek Mrugalski > Cc: DHC WG > On Apr 8, 2012, at 6:14 PM, Tomek Mrugalski > wrote: I kindly request that we adopt this document as a DHC WG work item. Please consider Tomek's request an official call for adoption. If you ar= e in favor of adopting this as a working group work item, please say so. = If you are against, please say so. We will evaluate consensus to adopt this draft as a working group work item= on April 24. --_000_D5B918C624B442E282FE43BAABAE2135mimectl_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <68E0302C931488419A82E08087848B03@huawei.com> Content-Transfer-Encoding: quoted-printable

    Though the design in this document looks very complicated, the solution = for the DHCPv6 failover or server redundancy sounds very important for= the industry. I am interested to see the progress of this document officia= lly in the WG, and +1 for the adoption as WG item.

     

     

    Best Regards,

    Leaf

     

    From: dhcwg-bounces@ietf.org [dhcwg-bounce= s@ietf.org] on behalf of Ted Lemon [Ted.Lemon@nominum.com]
    Sent: Tuesday, April 17, 2012 23:56
    To: DHC WG
    Subject: [dhcwg] Fwd: Requesting adoption of draft-mrugalski-dhc-dhc= pv6-failover-design-01

    Just a reminder, we will determine consensus to adopt this draft on th= e 24th of April.   If you want to see it adopted, and haven't said so = already, please do.   If you don't think the wg should work on it and = haven't said so, please do.

    Begin forwarded message:

    From: Ted = Lemon <Ted.Le= mon@nominum.com>
    Subject: R= e: [dhcwg] Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-desig= n-01
    Date: Apri= l 10, 2012 10:13:56 AM EDT
    To: Tome= k Mrugalski <tomasz.mrugalski@gmail.com>
    Cc: DHC = WG <dhcwg@ietf.org>

    I kindly request that we adopt this document as a DHC WG work item.

    Please consider Tomek's request an official call for adoption.   =  If you are in favor of adopting this as a working group work item, pl= ease say so.   If you are against, please say so.

    We will evaluate consensus to adopt this draft as a working group work= item on April 24.  


    --_000_D5B918C624B442E282FE43BAABAE2135mimectl_-- From Ted.Lemon@nominum.com Tue Apr 24 17:47:18 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202AB11E80BB for ; Tue, 24 Apr 2012 17:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+K288DFq+Hs for ; Tue, 24 Apr 2012 17:47:17 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 56CE511E80B6 for ; Tue, 24 Apr 2012 17:47:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT5dJlFsiSsNElAhESplPS+YFmbhK3O+G@postini.com; Tue, 24 Apr 2012 17:47:17 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 38D6B1B84EB for ; Tue, 24 Apr 2012 17:47:16 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2EB0C190065 for ; Tue, 24 Apr 2012 17:47:16 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 24 Apr 2012 17:47:16 -0700 From: Ted Lemon To: DHC WG Thread-Topic: [dhcwg] Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-design-01 Thread-Index: AQHNFdUOdLCpCRiXV0yWYUk8x9pa75aUkgMAgBaxmoA= Date: Wed, 25 Apr 2012 00:47:16 +0000 Message-ID: <30932C2D-BA5F-4F90-8E14-B4EFFB7562C5@nominum.com> References: <20120312204156.30819.94209.idtracker@ietfa.amsl.com> <4F820DE1.9090907@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_30932C2DBA5F4F908E14B4EFFB7562C5nominumcom_" MIME-Version: 1.0 Subject: Re: [dhcwg] Requesting adoption of draft-mrugalski-dhc-dhcpv6-failover-design-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 00:47:18 -0000 --_000_30932C2DBA5F4F908E14B4EFFB7562C5nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 10, 2012, at 10:13 AM, Ted Lemon > wrote: On Apr 8, 2012, at 6:14 PM, Tomek Mrugalski > wrote: I kindly request that we adopt this document as a DHC WG work item. Please consider Tomek's request an official call for adoption. If you ar= e in favor of adopting this as a working group work item, please say so. = If you are against, please say so. We will evaluate consensus to adopt this draft as a working group work item= on April 24. We had seven people speak in favor of adopting this work, and none against,= so the working group consensus is to adopt. Tomasz, when you're ready, p= lease submit an official working group -00 version of the document. Thanks! --_000_30932C2DBA5F4F908E14B4EFFB7562C5nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4D20C513C6B8824196CC0618A059D33A@nominum.com> Content-Transfer-Encoding: quoted-printable
    On Apr 10, 2012, at 10:13 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
    On Apr 8, 2012, at 6:14 PM, Tomek Mrugalski <tomasz.mrugalski@gmail.com> wrote:
    I kindly request that we adopt this document as a DHC WG work item.

    Please consider Tomek's request an official call for adoption.   =  If you are in favor of adopting this as a working group work item, pl= ease say so.   If you are against, please say so.

    We will evaluate consensus to adopt this draft as a working group work= item on April 24.  

    We had seven people speak in favor of adopting this work, and none aga= inst, so the working group consensus is to adopt.   Tomasz, when you'r= e ready, please submit an official working group -00 version of the documen= t.

    Thanks!


    --_000_30932C2DBA5F4F908E14B4EFFB7562C5nominumcom_-- From leaf.y.yeh@huawei.com Wed Apr 25 02:13:26 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF54821F86E1 for ; Wed, 25 Apr 2012 02:13:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UVtMgVv14mK for ; Wed, 25 Apr 2012 02:13:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id ADB9E21F86DF for ; Wed, 25 Apr 2012 02:13:25 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFE99147; Wed, 25 Apr 2012 05:13:25 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 02:11:34 -0700 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 02:11:33 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.29]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 25 Apr 2012 17:11:26 +0800 From: Leaf yeh To: DHC WG , "mohamed.boucadair@orange.com" , Ted Lemon Thread-Topic: Requesting to adopt draft-yeh-dhc-dhcpv6-authorization-opt-01 as WG item Thread-Index: AQHNIsNjo/0htWMzjEWcl8sNbwVDLQ== Date: Wed, 25 Apr 2012 09:11:25 +0000 Message-ID: References: <20120425090633.31392.37336.idtracker@ietfa.amsl.com> In-Reply-To: <20120425090633.31392.37336.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.39.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Bernie Volz Subject: [dhcwg] Requesting to adopt draft-yeh-dhc-dhcpv6-authorization-opt-01 as WG item X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 09:13:27 -0000 SW4gdGhlIERIQyBzZXNzaW9uIG9mIElFVEY4MyBhdCBQYXJpcywgdGhlIGRyYWZ0LXllaC1kaGMt ZGhjcHY2LWF1dGhvcml6YXRpb24tb3B0LTAwIHdhcyBwcmVzZW50ZWQuIFRoZXJlIHdhcyBhIGxv dCBvZiBpbnRlcmVzdCBhbmQgc3VwcG9ydCBmb3IgKGFuZCBubyBvcHBvc2l0aW9uKSBhZG9wdGlu ZyB0aGlzIGFzIGEgREhDIFdHIGRvY3VtZW50LiAoUGxzLiByZWZlciB0byBodHRwOi8vd3d3Lmll dGYub3JnL3Byb2NlZWRpbmdzLzgzL21pbnV0ZXMvbWludXRlcy04My1kaGMudHh0ICApDQoNClRo ZSBhdXRob3JzIGhhcyB1cGRhdGVkIHRvIHRoZSBkcmFmdCB0byBiZSB2ZXIuLTAxIHBlciB0aGUg ZGlzY3Vzc2lvbiAoaW5jbHVkaW5nIGludGVyZXN0cywgY29udHJpYnV0ZWQgdGV4dHMsIGNvbnN0 cnVjdGl2ZSBjb21tZW50cywgc29sdmluZyB0aGUgcXVlc3Rpb25zICYgY29uY2VybnMpIG9uIHRo ZSBNTC4NCg0KSSBraW5kbHkgcmVxdWVzdCB0aGF0IHdlIGFkb3B0IHRoaXMgZG9jdW1lbnQgYXMg YSBESEMgV0cgd29yayBpdGVtLg0KDQoNCkJlc3QgUmVnYXJkcywNCkxlYWYgWWVoDQoNCkFkdmFu Y2VkIFJlc2VhcmNoLCBOZXR3b3JrIFByb2R1Y3QgTGluZSwgSHVhd2VpIFRlY2hub2xvZ2llcyBD by4sIEx0ZC4NClBob25lOiArODYtNzU1LTI4OTc4ODUxLCAgTW9iaWxlOiArODYtMTM2MDA0NTEw NzUsICANClBvc3RhbCBBZGRyZXNzOiBGNC0zQSwgSHVhd2VpLCBCYW50aWFuLCBMb25nZ2FuZyBE aXN0cmljdCxTaGVuemhlbiA1MTgxMjksIFAuUi5DaGluYQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI1LCAyMDEyIDU6 MDcgUE0NClRvOiBMZWFmIHllaA0KQ2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHRl ZC5sZW1vbkBub21pbnVtLmNvbQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC15ZWgtZGhjLWRoY3B2Ni1hdXRob3JpemF0aW9uLW9wdC0wMS50eHQNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXllaC1kaGMtZGhjcHY2LWF1dGhvcml6YXRpb24tb3B0LTAx LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExlYWYgWS4gWWVoIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC15ZWgtZGhj LWRoY3B2Ni1hdXRob3JpemF0aW9uLW9wdA0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgUkFESVVT IE9wdGlvbiBmb3IgREhDUHY2IFJlbGF5IEFnZW50cyBvbiBCcm9hZGJhbmQgQWNjZXNzIFNlcnZl cg0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDQtMjUNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA5DQoNCkFic3RyYWN0Og0KICAgVGhlIERIQ1B2NiBSQURJ VVMgb3B0aW9uIHByb3ZpZGVzIGEgY29tbXVuaWNhdGlvbiBtZWNoYW5pc20gYmV0d2Vlbg0KICAg cmVsYXkgYWdlbnQgYW5kIHRoZSBzZXJ2ZXIuICBUaGlzIG1lY2hhbmlzbSBjYW4gaGVscCB0aGUg Y2VudHJhbGl6ZWQNCiAgIERIQ1B2NiBzZXJ2ZXIgdG8gc2VsZWN0IHRoZSByaWdodCBjb25maWd1 cmF0aW9uIGZvciB0aGUgY2xpZW50IGJhc2VkDQogICBvbiB0aGUgYXV0aG9yaXphdGlvbiBpbmZv cm1hdGlvbiByZWNlaXZlZCBmcm9tIGEgc2VwYXJhdGUgUkFESVVTDQogICBzZXJ2ZXIgd2hpY2gg aXMgbm90IGxvY2F0ZWQgYXQgdGhlIHNhbWUgcGxhY2Ugb2YgREhDUHY2IHNlcnZlciBpbiB0aGUN CiAgIGNhc2VzIHdoZXJlIHRoZSBOQVMgYWN0cyBhcyBESENQdjYgcmVsYXkgYWdlbnQgYW5kIFJB RElVUyBjbGllbnQNCiAgIHNpbXVsdGFuZW91c2x5Lg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From Ted.Lemon@nominum.com Wed Apr 25 04:37:41 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D7521F8736 for ; Wed, 25 Apr 2012 04:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.533 X-Spam-Level: X-Spam-Status: No, score=-106.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlq2egysnotT for ; Wed, 25 Apr 2012 04:37:40 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7085C21F8710 for ; Wed, 25 Apr 2012 04:37:40 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKT5fiA7i12PCQ2NzcuJl79frg1a0P9u92@postini.com; Wed, 25 Apr 2012 04:37:40 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7139A1B8297 for ; Wed, 25 Apr 2012 04:37:39 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 65826190065 for ; Wed, 25 Apr 2012 04:37:39 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 25 Apr 2012 04:37:39 -0700 From: Ted Lemon To: DHC WG Thread-Topic: Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt Thread-Index: AQHNItfRPqNlqZKpqU+ca4CGj8EPIQ== Date: Wed, 25 Apr 2012 11:37:38 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 11:37:41 -0000 One of the authors of this draft has requested a formal call for adoption. = There was substantial support for the work in the DHC working group meeti= ng in Paris, and no objections. The idea is to have a RADIUS option for D= HCPv6, similar to the functionality present in DHCPv4. If you favor or oppose taking this on as working group work, please signify= by replying to this message. If you have comments or concerns, please ra= ise them now. We will make a determination of consensus on May 9. From marc.blanchet@viagenie.ca Wed Apr 25 06:26:07 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2B221F85BD for ; Wed, 25 Apr 2012 06:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cFmHWMt7pXR for ; Wed, 25 Apr 2012 06:26:06 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id C47B121F85B4 for ; Wed, 25 Apr 2012 06:26:06 -0700 (PDT) Received: from h99.viagenie.ca (h99.viagenie.ca [206.123.31.99]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B1C7A4135B for ; Wed, 25 Apr 2012 09:26:01 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1257) From: Marc Blanchet In-Reply-To: Date: Wed, 25 Apr 2012 09:26:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <402023E8-91FA-4BFE-89C6-E5B0A269757D@viagenie.ca> References: To: DHC WG X-Mailer: Apple Mail (2.1257) Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 13:26:07 -0000 support. Marc. Le 2012-04-25 =E0 07:37, Ted Lemon a =E9crit : > One of the authors of this draft has requested a formal call for = adoption. There was substantial support for the work in the DHC = working group meeting in Paris, and no objections. The idea is to have = a RADIUS option for DHCPv6, similar to the functionality present in = DHCPv4. >=20 > If you favor or oppose taking this on as working group work, please = signify by replying to this message. If you have comments or concerns, = please raise them now. >=20 > We will make a determination of consensus on May 9. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From tomasz.mrugalski@gmail.com Wed Apr 25 06:37:39 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB4421F8699 for ; Wed, 25 Apr 2012 06:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVRU1Dl5mEMn for ; Wed, 25 Apr 2012 06:37:39 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0EFD21F8686 for ; Wed, 25 Apr 2012 06:37:38 -0700 (PDT) Received: by bkuw5 with SMTP id w5so92516bku.31 for ; Wed, 25 Apr 2012 06:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=Iqv2BgLArTw7hIIY1l9FU0JXwEo+eVn3jaEoOk5dOQs=; b=tCbrpByQbYRaNKoFRlPegA/VlZ2mGr74ynBGq7Zha1/cfgqXhXnN5xbIui0QDFk2ci CwxFRplToi4/HMpa9TNdWOY8X9igmI4YAj3zHeYxAwdaTYA2qi40zOGMn77jD1ZifRA2 /S2mjA7YVRPicIin/qWKFKetA399a8zmGqLuT4uXeR+3xYW6Ai8FuEHRkYFcvyYdFH0z NaXYysiJT6NnQ31PlO8WPqaicKxxt+SOlGiO3zttALMZ+6CHpLr46/q1TwMKZEu3G8F7 5wMCLFazGGRpwgb2n8FeNABeXR+Os2ZOfu7Io4UFcK6TPU6GvHx7v1yMTOwAAYJ1i9hZ razQ== Received: by 10.204.155.137 with SMTP id s9mr871543bkw.103.1335361057861; Wed, 25 Apr 2012 06:37:37 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id zx16sm38609383bkb.13.2012.04.25.06.37.36 (version=SSLv3 cipher=OTHER); Wed, 25 Apr 2012 06:37:36 -0700 (PDT) Message-ID: <4F97FE19.8000103@gmail.com> Date: Wed, 25 Apr 2012 15:37:29 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: dhcwg@ietf.org References: In-Reply-To: X-TagToolbar-Keys: D20120425153729366 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 13:37:39 -0000 On 25.04.2012 13:37, Ted Lemon wrote: > If you favor or oppose taking this on as working group work, please > signify by replying to this message. If you have comments or > concerns, please raise them now. I support adoption of this draft. Once adopted, it seems reasonable to call this draft draft-ietf-dhc-dhcpv6-radius-option, rather than -authorization-. Tomek From Ted.Lemon@nominum.com Wed Apr 25 06:53:30 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3BF21F86FE for ; Wed, 25 Apr 2012 06:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.535 X-Spam-Level: X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhEAYW0kAHZi for ; Wed, 25 Apr 2012 06:53:22 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id CFDF421F86FA for ; Wed, 25 Apr 2012 06:53:18 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKT5gBzo7x2XrzA5bVNfXThUxSUw9M7NU+@postini.com; Wed, 25 Apr 2012 06:53:21 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D2D531B807A for ; Wed, 25 Apr 2012 06:53:17 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C5556190065; Wed, 25 Apr 2012 06:53:17 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Wed, 25 Apr 2012 06:53:11 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt Thread-Index: AQHNIuiZkEB6qfFDWkSISIUwEK1AgZasBQcA Date: Wed, 25 Apr 2012 13:53:10 +0000 Message-ID: <3722AE9E-6131-47B9-8646-52C51DF0824F@nominum.com> References: <4F97FE19.8000103@gmail.com> In-Reply-To: <4F97FE19.8000103@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_3722AE9E613147B9864652C51DF0824Fnominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 13:53:30 -0000 --_000_3722AE9E613147B9864652C51DF0824Fnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 25, 2012, at 9:37 AM, Tomek Mrugalski > wrote: Once adopted, it seems reasonable to call this draft draft-ietf-dhc-dhcpv6-radius-option, rather than -authorization-. Yes, I agree completely. Leaf, is that okay with you? Tomek, are you for or against adoption? (Or don't have an opinion?) --_000_3722AE9E613147B9864652C51DF0824Fnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
    On Apr 25, 2012, at 9:37 AM, Tomek Mrugalski <tomasz.mrugalski@gmail.com>
     wrote:
    Once adopted, it seems reasonable to call this draft
    draft-ietf-dhc-dhcpv6-radius-option, rather than -authorization-.

    Yes, I agree completely.   Leaf, is that okay with you?

    Tomek, are you for or against adoption?   (Or don't have an opini= on?)

    --_000_3722AE9E613147B9864652C51DF0824Fnominumcom_-- From tomasz.mrugalski@gmail.com Wed Apr 25 07:20:28 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A17421F8715 for ; Wed, 25 Apr 2012 07:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl3nZcRebyTU for ; Wed, 25 Apr 2012 07:20:27 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1542821F86E0 for ; Wed, 25 Apr 2012 07:20:26 -0700 (PDT) Received: by bkuw5 with SMTP id w5so137826bku.31 for ; Wed, 25 Apr 2012 07:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=DH1CJrHHYUlWk6vnRVVKzyjnmhSfbApVq73IK3254qs=; b=ofi7evJLTPUHYQlG2jpgm9G7HL97drY29GknZVKQ8KbAqEXfM/Z0OY4A4X/FoWjc5E EWsxF4U0m/NigNrV9aeN2kyxHOUi+TQIgKzESqrJkJJQzmbQk6el7Bx70xIJ20RjwEm9 vZeazmVk3XPJ03iwfvniGZThxfv2Gc/2pRbTvPNH13eO2T6h70DjO4NxHk06up7SxR9d D6S7ckFBLpq0nZ5GajgNPQADxfXMp2hEzRfBu8VAC80HXP0rcI5V8v9XD2BqKjdo8EZX SaCLkzGWwShKdoJ44yhgDBJjZLEhHPpk15ENvIeAzFXHLlrLzQXpALown14ab+SPaRBa Kivg== Received: by 10.204.148.80 with SMTP id o16mr990722bkv.3.1335363626154; Wed, 25 Apr 2012 07:20:26 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id s16sm38897058bkt.3.2012.04.25.07.20.24 (version=SSLv3 cipher=OTHER); Wed, 25 Apr 2012 07:20:25 -0700 (PDT) Message-ID: <4F980821.3080508@gmail.com> Date: Wed, 25 Apr 2012 16:20:17 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ted Lemon References: <4F97FE19.8000103@gmail.com> <3722AE9E-6131-47B9-8646-52C51DF0824F@nominum.com> In-Reply-To: <3722AE9E-6131-47B9-8646-52C51DF0824F@nominum.com> X-TagToolbar-Keys: D20120425162017682 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 14:20:28 -0000 On 25.04.2012 15:53, Ted Lemon wrote: > On Apr 25, 2012, at 9:37 AM, Tomek Mrugalski > > wrote: >> Once adopted, it seems reasonable to call this draft >> draft-ietf-dhc-dhcpv6-radius-option, rather than -authorization-. > > Yes, I agree completely. Leaf, is that okay with you? > > Tomek, are you for or against adoption? (Or don't have an opinion?) I'm in favor of this work and its adoption. Tomek From mohamed.boucadair@orange.com Wed Apr 25 08:10:57 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B6E21F860D for ; Wed, 25 Apr 2012 08:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e35P2P1dyzjk for ; Wed, 25 Apr 2012 08:10:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 901F121F855A for ; Wed, 25 Apr 2012 08:10:56 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 7E82A18C0CE; Wed, 25 Apr 2012 17:10:55 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 61AE035C08F; Wed, 25 Apr 2012 17:10:55 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 25 Apr 2012 17:10:55 +0200 From: To: Ted Lemon , DHC WG Date: Wed, 25 Apr 2012 17:10:54 +0200 Thread-Topic: Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt Thread-Index: AQHNItfRPqNlqZKpqU+ca4CGj8EPIZarpXfQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E295A85EA@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.25.144521 Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 15:10:57 -0000 Dear all, I support. Cheers, Med=20 >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de Ted Lemon >Envoy=E9 : mercredi 25 avril 2012 13:38 >=C0 : DHC WG >Objet : [dhcwg] Call for adoption:=20 >draft-yeh-dhc-dhcpv6-authorization-opt > >One of the authors of this draft has requested a formal call=20 >for adoption. There was substantial support for the work in=20 >the DHC working group meeting in Paris, and no objections. =20 >The idea is to have a RADIUS option for DHCPv6, similar to the=20 >functionality present in DHCPv4. > >If you favor or oppose taking this on as working group work,=20 >please signify by replying to this message. If you have=20 >comments or concerns, please raise them now. > >We will make a determination of consensus on May 9. > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >= From Olaf.Bonness@telekom.de Wed Apr 25 08:15:25 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425AC21F877D for ; Wed, 25 Apr 2012 08:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4UYD26kYxpt for ; Wed, 25 Apr 2012 08:15:24 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id E5A2C21F8736 for ; Wed, 25 Apr 2012 08:15:23 -0700 (PDT) Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 25 Apr 2012 17:15:18 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.250]) by HE101251.emea1.cds.t-internal.com ([fe80::e428:2144:dcc5:bcce%15]) with mapi; Wed, 25 Apr 2012 17:15:16 +0200 From: To: Date: Wed, 25 Apr 2012 17:15:14 +0200 Thread-Topic: Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt Thread-Index: AQHNItfRPqNlqZKpqU+ca4CGj8EPIZarppiA Message-ID: References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 15:15:25 -0000 I support this useful I-D as well. Ciao Olaf -----Urspr=FCngliche Nachricht----- Von: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] Im Auftrag von = Ted Lemon Gesendet: Mittwoch, 25. April 2012 13:38 An: DHC WG Betreff: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt One of the authors of this draft has requested a formal call for adoption. = There was substantial support for the work in the DHC working group meeti= ng in Paris, and no objections. The idea is to have a RADIUS option for D= HCPv6, similar to the functionality present in DHCPv4. If you favor or oppose taking this on as working group work, please signify= by replying to this message. If you have comments or concerns, please ra= ise them now. We will make a determination of consensus on May 9. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From raj@cisco.com Wed Apr 25 12:59:46 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5A921F892F for ; Wed, 25 Apr 2012 12:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7n2fgH1FOBLH for ; Wed, 25 Apr 2012 12:59:45 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 11D5321F8929 for ; Wed, 25 Apr 2012 12:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raj@cisco.com; l=2105; q=dns/txt; s=iport; t=1335383985; x=1336593585; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=LZG+SMsL5+60iHMo/cOOiFbXKsZXW8ycH4G/KJy+nxQ=; b=U9kT9eOZha4Spr5JVUeooHUE2jQh3cWeH5SE2CsPYNn3dQ/Llmkc+vzY i7uttUmEk3ixi/P0RVoNMr0sK70bv7BgRWWQckkCBWMoZFMspwZ0ybwMZ IQKXWz3lIm4TWOkeDCyXSo8j+bBJ8I/ETv6TBj4YkeEI8OF76J6FlYmva U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwFADhWmE9Io8UY/2dsb2JhbAA7CoMdrziCCQEBAQMBAQEBDwFbCwULC0YnMAYTIodoBQubL6AQBIlrgQmFCWMEiGONGIV0iGGBaYMJ X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="10878452" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 25 Apr 2012 19:59:42 +0000 Received: from [10.32.254.179] (stealth-10-32-254-179.cisco.com [10.32.254.179]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3PJxeUH027581; Wed, 25 Apr 2012 19:59:41 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Richard Johnson In-Reply-To: <64B00097-8ACB-4170-9303-8F863A47C2B5@nominum.com> Date: Wed, 25 Apr 2012 12:59:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0579F6EF-7CBE-456C-AFE4-756023B0D406@cisco.com> References: <64B00097-8ACB-4170-9303-8F863A47C2B5@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1257) Cc: DHC WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 19:59:46 -0000 I definitely support this draft, although I think the current = description of the problem to be solved could use quite a lot of work to = make it more clear. Your own description is quite clear, but the = document is not really. /raj On Apr 14, 2012, at 5:54 AM, Ted Lemon wrote: > This document corrects a bug in RFC2131 that forbids the DHCP server = from returning a DHCP client identifier. The lack of a DHCP client = identifier creates a problem in two cases: where the underlying = transport has no link-layer address, and where two clients are running = on the same host, supplying different client identifiers so as to = present different network identities. In both of these cases, = insufficient information is returned from the DHCP server to clearly = identify the client that is the intended recipient of the message. The = only way to fix this is to _require_ the DHCP server to return the = client identifier if it receives it. This is what the proposed = document does. >=20 > We checked for consensus in the meeting, and four people were in favor = of advancing the draft; nobody was against. >=20 > I think this is actually pretty important work=97it's a lingering bug = in the spec which I think will come back to bite us more and more as we = start getting deeper into the dual-stack transition. So if you haven't = read the document, please do.=20 >=20 > If you support advancing it, please signify by replying to this = message and saying that you support it. If you think it's a bad idea, = please signify by replying to this message and explaining why. If you = have comments or changes to propose, please send them along, and also = signify whether you are in favor of advancement with the change, without = the change, or oppose advancement. >=20 > We will determine consensus on April 27, based solely on responses on = the mailing list, so please do respond. >=20 > Thanks! >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From jiangsheng@huawei.com Wed Apr 25 16:45:41 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9613921E808F for ; Wed, 25 Apr 2012 16:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7T0BMNOP7vkN for ; Wed, 25 Apr 2012 16:45:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0202021E8082 for ; Wed, 25 Apr 2012 16:45:40 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFF50400; Wed, 25 Apr 2012 19:45:40 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 16:42:40 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 16:42:45 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.67]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Thu, 26 Apr 2012 07:42:39 +0800 From: Sheng Jiang To: Ted Lemon , DHC WG Thread-Topic: Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt Thread-Index: AQHNItfY3nqZPJ9EH0axilodhliJPJasNGQQ Date: Wed, 25 Apr 2012 23:42:38 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921E48EDCC@SZXEML506-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 23:45:41 -0000 Support adopt this draft. Sheng > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Ted Lemon > Sent: Wednesday, April 25, 2012 7:38 PM > To: DHC WG > Subject: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization- > opt >=20 > One of the authors of this draft has requested a formal call for > adoption. There was substantial support for the work in the DHC > working group meeting in Paris, and no objections. The idea is to > have a RADIUS option for DHCPv6, similar to the functionality present > in DHCPv4. >=20 > If you favor or oppose taking this on as working group work, please > signify by replying to this message. If you have comments or concerns, > please raise them now. >=20 > We will make a determination of consensus on May 9. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From leaf.y.yeh@huawei.com Wed Apr 25 18:40:30 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B83121E801E for ; Wed, 25 Apr 2012 18:40:30 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqv-wmpelrgJ for ; Wed, 25 Apr 2012 18:40:29 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9071621E801B for ; Wed, 25 Apr 2012 18:40:29 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFN58413; Wed, 25 Apr 2012 21:40:29 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 18:37:40 -0700 Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 18:37:15 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.29]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Thu, 26 Apr 2012 09:36:57 +0800 From: Leaf yeh To: Ted Lemon , Tomek Mrugalski Thread-Topic: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt Thread-Index: AQHNIur9PwNXqim7bUeivYb4cT1vZpasUVuA Date: Thu, 26 Apr 2012 01:36:56 +0000 Message-ID: References: <4F97FE19.8000103@gmail.com> <3722AE9E-6131-47B9-8646-52C51DF0824F@nominum.com> In-Reply-To: <3722AE9E-6131-47B9-8646-52C51DF0824F@nominum.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.39.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 01:40:30 -0000 VG9tZWsgLSBPbmNlIGFkb3B0ZWQsIGl0IHNlZW1zIHJlYXNvbmFibGUgdG8gY2FsbCB0aGlzIGRy YWZ0DQpkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcmFkaXVzLW9wdGlvbiwgcmF0aGVyIHRoYW4gLWF1 dGhvcml6YXRpb24tLg0KVGVkIC0gWWVzLCBJIGFncmVlIGNvbXBsZXRlbHkuICAgTGVhZiwgaXMg dGhhdCBva2F5IHdpdGggeW91PyANCg0KRllJIGFnYWluLCB0aGUgY29udGV4dCBpbmNsdWRpbmcg dGhlIHRpdGxlIG9mIGRyYWZ0ICYgdGhlIG5hbWUgb2YgdGhlIG5ldyBvcHRpb24gIGhhcyBiZWVu IHVwZGF0ZWQgdG8gdGhlICdSQURJVVMgb3B0aW9uJyBpbiB0aGUgZHJhZnQteWVoLTAxLg0KDQpZ ZXMsIEkgYW0gT0sgd2l0aCB0aGlzIHN1Z2dlc3Rpb24uDQoNCg0KQmVzdCBSZWdhcmRzLA0KTGVh Zg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCkZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVkIExlbW9uDQpTZW50OiBXZWRuZXNkYXksIEFwcmls IDI1LCAyMDEyIDk6NTMgUE0NClRvOiBUb21layBNcnVnYWxza2kNCkNjOiA8ZGhjd2dAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW2RoY3dnXSBDYWxsIGZvciBhZG9wdGlvbjogZHJhZnQteWVoLWRo Yy1kaGNwdjYtYXV0aG9yaXphdGlvbi1vcHQNCg0KT24gQXByIDI1LCAyMDEyLCBhdCA5OjM3IEFN LCBUb21layBNcnVnYWxza2kgPHRvbWFzei5tcnVnYWxza2lAZ21haWwuY29tPg0KwqB3cm90ZToN Ck9uY2UgYWRvcHRlZCwgaXQgc2VlbXMgcmVhc29uYWJsZSB0byBjYWxsIHRoaXMgZHJhZnQNCmRy YWZ0LWlldGYtZGhjLWRoY3B2Ni1yYWRpdXMtb3B0aW9uLCByYXRoZXIgdGhhbiAtYXV0aG9yaXph dGlvbi0uDQoNClllcywgSSBhZ3JlZSBjb21wbGV0ZWx5LiDCoCBMZWFmLCBpcyB0aGF0IG9rYXkg d2l0aCB5b3U/DQoNClRvbWVrLCBhcmUgeW91IGZvciBvciBhZ2FpbnN0IGFkb3B0aW9uPyDCoCAo T3IgZG9uJ3QgaGF2ZSBhbiBvcGluaW9uPykNCg0K From Tina.Tsou.Zouting@huawei.com Wed Apr 25 20:03:41 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317EC21E809E for ; Wed, 25 Apr 2012 20:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYm3212Ia-st for ; Wed, 25 Apr 2012 20:03:40 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7610D21E809D for ; Wed, 25 Apr 2012 20:03:40 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFF60269; Wed, 25 Apr 2012 23:03:40 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 19:59:56 -0700 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 20:00:01 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.22]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Thu, 26 Apr 2012 10:59:50 +0800 From: Tina TSOU To: Sheng Jiang Thread-Topic: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt Thread-Index: AQHNIz+mUhtzQl8oBUug3qJC/vi2UZar1/6A Date: Thu, 26 Apr 2012 02:59:50 +0000 Message-ID: <3CF7C125-3B76-464A-8C58-D7BDCE72B996@huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B921E48EDCC@SZXEML506-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921E48EDCC@SZXEML506-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: DHC WG , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 03:03:41 -0000 I support adoption of this draft. Sent from my iPad On Apr 25, 2012, at 5:00 PM, "Sheng Jiang" wrote: > Support adopt this draft. >=20 > Sheng >=20 >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >> Of Ted Lemon >> Sent: Wednesday, April 25, 2012 7:38 PM >> To: DHC WG >> Subject: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization- >> opt >>=20 >> One of the authors of this draft has requested a formal call for >> adoption. There was substantial support for the work in the DHC >> working group meeting in Paris, and no objections. The idea is to >> have a RADIUS option for DHCPv6, similar to the functionality present >> in DHCPv4. >>=20 >> If you favor or oppose taking this on as working group work, please >> signify by replying to this message. If you have comments or concerns, >> please raise them now. >>=20 >> We will make a determination of consensus on May 9. >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From wwwrun@rfc-editor.org Fri Apr 27 03:35:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FB121F86B7 for ; Fri, 27 Apr 2012 03:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.025 X-Spam-Level: X-Spam-Status: No, score=-102.025 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAeevpBiOSYe for ; Fri, 27 Apr 2012 03:35:30 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C94F721F85FD for ; Fri, 27 Apr 2012 03:35:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B0AE0B1E002; Fri, 27 Apr 2012 03:33:57 -0700 (PDT) To: volz@cisco.com, rdroms.ietf@gmail.com, brian@innovationslab.net, ted.lemon@nominum.com, john_brzozowski@cable.comcast.com From: RFC Errata System Message-Id: <20120427103357.B0AE0B1E002@rfc-editor.org> Date: Fri, 27 Apr 2012 03:33:57 -0700 (PDT) Cc: dhcwg@ietf.org, ah@TR-Sys.de, rfc-editor@rfc-editor.org Subject: [dhcwg] [Technical Errata Reported] RFC3942 (3204) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 10:35:31 -0000 The following errata report has been submitted for RFC3942, "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3942&eid=3204 -------------------------------------- Type: Technical Reported by: Alfred Hoenes Section: 6. IANA Cons Original Text ------------- 4. change the listing of any options listed as "Tentatively-Assigned" | to "Unavailable" 18 months from this RFC's publication date and periodically thereafter as long as there is an option listed as "Tentatively-Assigned", if no un-expired Internet-Draft exists documenting the usage. Corrected Text -------------- 4. change the listing of any options listed as "Tentatively-Assigned" | to "Unassigned" 18 months from this RFC's publication date and periodically thereafter as long as there is an option listed as "Tentatively-Assigned", if no un-expired Internet-Draft exists documenting the usage. Notes ----- The body of the RFC clearly states in Section 4, bullet 4. that the IANA action desired by the RFC is to make these code points available for assignment after the 18-month grace period. This Errata Note is tagged as "Technical" because the inconsistency between the IANA Considerations and the body of the RFC apparently has caused IANA to not follow the body and spirit of the RFC -- at the time this Errata Note is being filed, there are several entries left in the BOOTP+DHCP parameters option codes registry that should have been cleaned up and made available for assignment since the publication of RFC 3942 in November 2004. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3942 (draft-ietf-dhc-reclassify-options-01) -------------------------------------- Title : Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options Publication Date : November 2004 Author(s) : B. Volz Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From shankari.v2k6@gmail.com Fri Apr 27 06:00:00 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8833121F85CE for ; Fri, 27 Apr 2012 06:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Es8V-bBREEo for ; Fri, 27 Apr 2012 05:59:59 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 687EC21F85CC for ; Fri, 27 Apr 2012 05:59:58 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so531546lbb.31 for ; Fri, 27 Apr 2012 05:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=iJwIQ/3XxNilPJKr8JxHgaSAA8uZNYdjHw1kGRa0R6A=; b=YSFdOG1iM6ca00FU2qnJfRPTm/bP6M90ehKxXjlgAhumFDiHsICKb/78X9KPulcWgu BfevkaN6ntyexyTahtdp6f99kGIGHqJV9mpoco0x4TzXn3qnR6NSZSyq9XU9V/GuU4/r TpsjiGM3OZmh0BKwaDJUJcR8GnAGv4/dDZ/dtBbf+YZNFpIZ3k6zMUrbGRvH9/SMlFLh aiKUnnpWkN1keHtPAM6K10vwEt+RjNSViI844bTXqzBMORMIKbnfHzEaxBg5SA63hbLk 91vgmr4ZwnFobQu+zQsc9ZbKVsgjbT7BeBPq1sWQDvyowRbhiaGlO1wfuRXEPgfrgAP7 j3Wg== MIME-Version: 1.0 Received: by 10.112.8.5 with SMTP id n5mr5395727lba.48.1335531597223; Fri, 27 Apr 2012 05:59:57 -0700 (PDT) Received: by 10.112.96.167 with HTTP; Fri, 27 Apr 2012 05:59:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Apr 2012 18:29:57 +0530 Message-ID: From: Shankari Vaidyalingam To: dhcwg@ietf.org Content-Type: multipart/alternative; boundary=90e6ba30952a70597804bea8ae53 Subject: Re: [dhcwg] dhcwg Digest, Vol 96, Issue 38 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 13:00:00 -0000 --90e6ba30952a70597804bea8ae53 Content-Type: text/plain; charset=ISO-8859-1 Hi, Can you let me know where can I get this draft - draft-ietf-dhc-client-id-02. Regards, Shankari.V On Fri, Apr 27, 2012 at 12:30 AM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/dhcwg > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send dhcwg mailing list submissions to > dhcwg@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/dhcwg > or, via email, send a message with subject or body 'help' to > dhcwg-request@ietf.org > > You can reach the person managing the list at > dhcwg-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dhcwg digest..." > > > Today's Topics: > > 1. Re: WGLC: draft-ietf-dhc-client-id-02 (Richard Johnson) > 2. Re: Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt > (Sheng Jiang) > 3. Re: Call for adoption: > draft-yeh-dhc-dhcpv6-authorization-opt > (Leaf yeh) > 4. Re: Call for adoption: > draft-yeh-dhc-dhcpv6-authorization-opt > (Tina TSOU) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 25 Apr 2012 12:59:39 -0700 > From: Richard Johnson > To: Ted Lemon > Cc: DHC WG > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 > Message-ID: <0579F6EF-7CBE-456C-AFE4-756023B0D406@cisco.com> > Content-Type: text/plain; charset=windows-1252 > > I definitely support this draft, although I think the current description > of the problem to be solved could use quite a lot of work to make it more > clear. Your own description is quite clear, but the document is not really. > > /raj > > > On Apr 14, 2012, at 5:54 AM, Ted Lemon wrote: > > > This document corrects a bug in RFC2131 that forbids the DHCP server > from returning a DHCP client identifier. The lack of a DHCP client > identifier creates a problem in two cases: where the underlying transport > has no link-layer address, and where two clients are running on the same > host, supplying different client identifiers so as to present different > network identities. In both of these cases, insufficient information is > returned from the DHCP server to clearly identify the client that is the > intended recipient of the message. The only way to fix this is to > _require_ the DHCP server to return the client identifier if it receives > it. This is what the proposed document does. > > > > We checked for consensus in the meeting, and four people were in favor > of advancing the draft; nobody was against. > > > > I think this is actually pretty important work?it's a lingering bug in > the spec which I think will come back to bite us more and more as we start > getting deeper into the dual-stack transition. So if you haven't read the > document, please do. > > > > If you support advancing it, please signify by replying to this message > and saying that you support it. If you think it's a bad idea, please > signify by replying to this message and explaining why. If you have > comments or changes to propose, please send them along, and also signify > whether you are in favor of advancement with the change, without the > change, or oppose advancement. > > > > We will determine consensus on April 27, based solely on responses on > the mailing list, so please do respond. > > > > Thanks! > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > > > ------------------------------ > > Message: 2 > Date: Wed, 25 Apr 2012 23:42:38 +0000 > From: Sheng Jiang > To: Ted Lemon , DHC WG > Subject: Re: [dhcwg] Call for adoption: > draft-yeh-dhc-dhcpv6-authorization-opt > Message-ID: > < > 5D36713D8A4E7348A7E10DF7437A4B921E48EDCC@SZXEML506-MBS.china.huawei.com> > > Content-Type: text/plain; charset="us-ascii" > > Support adopt this draft. > > Sheng > > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > > Of Ted Lemon > > Sent: Wednesday, April 25, 2012 7:38 PM > > To: DHC WG > > Subject: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization- > > opt > > > > One of the authors of this draft has requested a formal call for > > adoption. There was substantial support for the work in the DHC > > working group meeting in Paris, and no objections. The idea is to > > have a RADIUS option for DHCPv6, similar to the functionality present > > in DHCPv4. > > > > If you favor or oppose taking this on as working group work, please > > signify by replying to this message. If you have comments or concerns, > > please raise them now. > > > > We will make a determination of consensus on May 9. > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > > ------------------------------ > > Message: 3 > Date: Thu, 26 Apr 2012 01:36:56 +0000 > From: Leaf yeh > To: Ted Lemon , Tomek Mrugalski > > Cc: "" > Subject: Re: [dhcwg] Call for adoption: > draft-yeh-dhc-dhcpv6-authorization-opt > Message-ID: > < > E1CE3E6E6D4E1C438B0ADC9FFFA345EA262CB99C@SZXEML510-MBS.china.huawei.com> > > Content-Type: text/plain; charset="utf-8" > > Tomek - Once adopted, it seems reasonable to call this draft > draft-ietf-dhc-dhcpv6-radius-option, rather than -authorization-. > Ted - Yes, I agree completely. Leaf, is that okay with you? > > FYI again, the context including the title of draft & the name of the new > option has been updated to the 'RADIUS option' in the draft-yeh-01. > > Yes, I am OK with this suggestion. > > > Best Regards, > Leaf > > > > ---------------------------------------------------------------------------------------------------------------- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Ted Lemon > Sent: Wednesday, April 25, 2012 9:53 PM > To: Tomek Mrugalski > Cc: > Subject: Re: [dhcwg] Call for adoption: > draft-yeh-dhc-dhcpv6-authorization-opt > > On Apr 25, 2012, at 9:37 AM, Tomek Mrugalski > ?wrote: > Once adopted, it seems reasonable to call this draft > draft-ietf-dhc-dhcpv6-radius-option, rather than -authorization-. > > Yes, I agree completely. ? Leaf, is that okay with you? > > Tomek, are you for or against adoption? ? (Or don't have an opinion?) > > > ------------------------------ > > Message: 4 > Date: Thu, 26 Apr 2012 02:59:50 +0000 > From: Tina TSOU > To: Sheng Jiang > Cc: DHC WG , Ted Lemon > Subject: Re: [dhcwg] Call for adoption: > draft-yeh-dhc-dhcpv6-authorization-opt > Message-ID: <3CF7C125-3B76-464A-8C58-D7BDCE72B996@huawei.com> > Content-Type: text/plain; charset="us-ascii" > > I support adoption of this draft. > > Sent from my iPad > > On Apr 25, 2012, at 5:00 PM, "Sheng Jiang" wrote: > > > Support adopt this draft. > > > > Sheng > > > >> -----Original Message----- > >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > >> Of Ted Lemon > >> Sent: Wednesday, April 25, 2012 7:38 PM > >> To: DHC WG > >> Subject: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization- > >> opt > >> > >> One of the authors of this draft has requested a formal call for > >> adoption. There was substantial support for the work in the DHC > >> working group meeting in Paris, and no objections. The idea is to > >> have a RADIUS option for DHCPv6, similar to the functionality present > >> in DHCPv4. > >> > >> If you favor or oppose taking this on as working group work, please > >> signify by replying to this message. If you have comments or concerns, > >> please raise them now. > >> > >> We will make a determination of consensus on May 9. > >> > >> _______________________________________________ > >> 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 > > > End of dhcwg Digest, Vol 96, Issue 38 > ************************************* > --90e6ba30952a70597804bea8ae53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    Can you let me know where can I get t= his draft - draft-ietf-dhc-client-id-02.

    Regards,
    Shankari.V
    <= br>
    On Fri, Apr 27, 2012 at 12:30 AM, <dh= cwg-request@ietf.org> wrote:
    If you have received this digest without all= the individual message
    attachments you will need to update your digest options in your list
    subscription. =A0To do so, go to

    h= ttps://www.ietf.org/mailman/listinfo/dhcwg

    Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
    MIME or Plain Text Digests?" to MIME. =A0You can set this option
    globally for all the list digests you receive at this point.



    Send dhcwg mailing list submissions to
    =A0 =A0 =A0 =A0dhcwg@ietf.org

    To subscribe or unsubscribe via the World Wide Web, visit
    =A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/dhcwg
    or, via email, send a message with subject or body 'help' to
    =A0 =A0 =A0 =A0dhcwg-request@iet= f.org

    You can reach the person managing the list at
    =A0 =A0 =A0 =A0dhcwg-owner@ietf.or= g

    When replying, please edit your Subject line so it is more specific
    than "Re: Contents of dhcwg digest..."


    Today's Topics:

    =A0 1. Re: WGLC: draft-ietf-dhc-client-id-02 (Richard Johnson)
    =A0 2. Re: Call for adoption: =A0 =A0draft-yeh-dhc-dhcpv6-authorization-op= t
    =A0 =A0 =A0(Sheng Jiang)
    =A0 3. Re: Call =A0for =A0 =A0 adoption: =A0 =A0 =A0 draft-yeh-dhc-dhcpv6-= authorization-opt
    =A0 =A0 =A0(Leaf yeh)
    =A0 4. Re: Call for =A0 =A0 =A0adoption: =A0 =A0 =A0 draft-yeh-dhc-dhcpv6-= authorization-opt
    =A0 =A0 =A0(Tina TSOU)


    ----------------------------------------------------------------------

    Message: 1
    Date: Wed, 25 Apr 2012 12:59:39 -0700
    From: Richard Johnson <raj@cisco.com>
    To: Ted Lemon <    Ted.Lemon@nominu= m.com>
    Cc: DHC WG <dhcwg@ietf.org>
    Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02
    Message-ID: <0579F6EF-7CBE-456C-AFE4-756023B0D406@cisco.com>
    Content-Type: text/plain; charset=3Dwindows-1252

    I definitely support this draft, although I think the current description o= f the problem to be solved could use quite a lot of work to make it more cl= ear. =A0Your own description is quite clear, but the document is not really= .

    /raj


    On Apr 14, 2012, at 5:54 AM, Ted Lemon wrote:

    > This document corrects a bug in RFC2131 that forbids the DHCP server f= rom returning a DHCP client identifier. =A0 The lack of a DHCP client ident= ifier creates a problem in two cases: where the underlying transport has no= link-layer address, and where two clients are running on the same host, su= pplying different client identifiers so as to present different network ide= ntities. =A0 In both of these cases, insufficient information is returned f= rom the DHCP server to clearly identify the client that is the intended rec= ipient of the message. =A0 The only way to fix this is to _require_ the DHC= P server to return the client identifier if it receives it. =A0 This is wha= t the proposed document does.
    >
    > We checked for consensus in the meeting, and four people were in favor= of advancing the draft; nobody was against.
    >
    > I think this is actually pretty important work?it's a lingering bu= g in the spec which I think will come back to bite us more and more as we s= tart getting deeper into the dual-stack transition. =A0 So if you haven'= ;t read the document, please do.
    >
    > If you support advancing it, please signify by replying to this messag= e and saying that you support it. If you think it's a bad idea, please = signify by replying to this message and explaining why. =A0 If you have com= ments or changes to propose, please send them along, and also signify wheth= er you are in favor of advancement with the change, without the change, or = oppose advancement.
    >
    > We will determine consensus on April 27, based solely on responses on = the mailing list, so please do respond.
    >
    > Thanks!
    >
    > _______________________________________________
    > dhcwg mailing list
    > dhcwg@ietf.org
    > https://www.ietf.org/mailman/listinfo/dhcwg



    ------------------------------

    Message: 2
    Date: Wed, 25 Apr 2012 23:42:38 +0000
    From: Sheng Jiang <jiangsheng@h= uawei.com>
    To: Ted Lemon <Ted.Lemon@nominu= m.com>, DHC WG <dhcwg@ietf.org<= /a>>
    Subject: Re: [dhcwg] Call for adoption:
    =A0 =A0 =A0 =A0draft-yeh-dhc-dhcpv6-authorization-opt
    Message-ID:
    =A0 =A0 =A0 =A0<    5D36713D8A4E7348A7E10DF7437A4B921E48EDC= C@SZXEML506-MBS.china.huawei.com>

    Content-Type: text/plain; charset=3D"us-ascii"

    Support adopt this draft.

    Sheng

    > -----Original Message-----
    > From: dhcwg-bounces@ietf.org= [mailto:dhcwg-bounces@ietf.o= rg] On Behalf
    > Of Ted Lemon
    > Sent: Wednesday, April 25, 2012 7:38 PM
    > To: DHC WG
    > Subject: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization= -
    > opt
    >
    > One of the authors of this draft has requested a formal call for
    > adoption. =A0 There was substantial support for the work in the DHC > working group meeting in Paris, and no objections. =A0 The idea is to<= br> > have a RADIUS option for DHCPv6, similar to the functionality present<= br> > in DHCPv4.
    >
    > If you favor or oppose taking this on as working group work, please > signify by replying to this message. =A0 If you have comments or conce= rns,
    > please raise them now.
    >
    > We will make a determination of consensus on May 9.
    >
    > _______________________________________________
    > dhcwg mailing list
    > dhcwg@ietf.org
    > https://www.ietf.org/mailman/listinfo/dhcwg


    ------------------------------

    Message: 3
    Date: Thu, 26 Apr 2012 01:36:56 +0000
    From: Leaf yeh <leaf.y.yeh@huaw= ei.com>
    To: Ted Lemon <Ted.Lemon@nominu= m.com>, Tomek Mrugalski
    =A0 =A0 =A0 =A0<tomasz.mr= ugalski@gmail.com>
    Cc: "<dhcwg@ietf.org>"= ; <dhcwg@ietf.org>
    Subject: Re: [dhcwg] Call =A0 =A0 =A0 for =A0 =A0 adoption:
    =A0 =A0 =A0 =A0draft-yeh-dhc-dhcpv6-authorization-opt
    Message-ID:
    =A0 =A0 =A0 =A0<E1CE3E6E6D4E1C438B0ADC9FFFA345EA262CB99= C@SZXEML510-MBS.china.huawei.com>

    Content-Type: text/plain; charset=3D"utf-8"

    Tomek - Once adopted, it seems reasonable to call this draft
    draft-ietf-dhc-dhcpv6-radius-option, rather than -authorization-.
    Ted - Yes, I agree completely. =A0 Leaf, is that okay with you?

    FYI again, the context including the title of draft & the name of the n= ew option =A0has been updated to the 'RADIUS option' in the draft-y= eh-01.

    Yes, I am OK with this suggestion.


    Best Regards,
    Leaf


    ---------------------------------------------------------------------------= -------------------------------------
    From: dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon
    Sent: Wednesday, April 25, 2012 9:53 PM
    To: Tomek Mrugalski
    Cc: <    dhcwg@ietf.org>
    Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-= opt

    On Apr 25, 2012, at 9:37 AM, Tomek Mrugalski <tomasz.mrugalski@gmail.com>
    ?wrote:
    Once adopted, it seems reasonable to call this draft
    draft-ietf-dhc-dhcpv6-radius-option, rather than -authorization-.

    Yes, I agree completely. ? Leaf, is that okay with you?

    Tomek, are you for or against adoption? ? (Or don't have an opinion?)

    ------------------------------

    Message: 4
    Date: Thu, 26 Apr 2012 02:59:50 +0000
    From: Tina TSOU <Tina.Ts= ou.Zouting@huawei.com>
    To: Sheng Jiang <jiangsheng@hua= wei.com>
    Cc: DHC WG <dhcwg@ietf.org>, Te= d Lemon <Ted.Lemon@nominum.com<= /a>>
    Subject: Re: [dhcwg] Call for =A0 adoption:
    =A0 =A0 =A0 =A0draft-yeh-dhc-dhcpv6-authorization-opt
    Message-ID: <    3CF7C125-3B76-464A-8C58-D7BDCE72B996@huawei.com>
    Content-Type: text/plain; charset=3D"us-ascii"

    I support adoption of this draft.

    Sent from my iPad

    On Apr 25, 2012, at 5:00 PM, "Sheng Jiang" <jiangsheng@huawei.com> wrote:

    > Support adopt this draft.
    >
    > Sheng
    >
    >> -----Original Message-----
    >> From: dhcwg-bounces@ietf= .org [mailto:dhcwg-bounces@ie= tf.org] On Behalf
    >> Of Ted Lemon
    >> Sent: Wednesday, April 25, 2012 7:38 PM
    >> To: DHC WG
    >> Subject: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authoriza= tion-
    >> opt
    >>
    >> One of the authors of this draft has requested a formal call for >> adoption. =A0 There was substantial support for the work in the DH= C
    >> working group meeting in Paris, and no objections. =A0 The idea is= to
    >> have a RADIUS option for DHCPv6, similar to the functionality pres= ent
    >> in DHCPv4.
    >>
    >> If you favor or oppose taking this on as working group work, pleas= e
    >> signify by replying to this message. =A0 If you have comments or c= oncerns,
    >> please raise them now.
    >>
    >> We will make a determination of consensus on May 9.
    >>
    >> _______________________________________________
    >> 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
    h= ttps://www.ietf.org/mailman/listinfo/dhcwg


    End of dhcwg Digest, Vol 96, Issue 38
    *************************************

    --90e6ba30952a70597804bea8ae53-- From budmillwood@gmail.com Fri Apr 27 08:09:06 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B27B21F8769 for ; Fri, 27 Apr 2012 08:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOz+TqLpjGPr for ; Fri, 27 Apr 2012 08:09:06 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD31121F8759 for ; Fri, 27 Apr 2012 08:09:05 -0700 (PDT) Received: by ghbg16 with SMTP id g16so517006ghb.31 for ; Fri, 27 Apr 2012 08:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=fwEoPOBKssbUeqA6Tk9P271G+nFhCD7iVPv3W0nYLKg=; b=xUZb1DYRIdV8d5lILQAYqkhahsbhXeSCp6TRLrax9JOGzZ9mJQDitNzcPifZEiCB+0 QD7Tti7S8Q+N8xZr0Mw7j9llpgQEc0vRLXu69dQRzjhTHB8GgcJqtuaUIi4VQW5gY50h iiae9MJaIxopZY416QBVVcp+poHhxgyRN4Z/MMG5hnLp3HWCrHLNT9fhRzRFZM4GrpKW OXzrhs78bithsyblvWsYAy7dGiXeZcItf4+W7tUCrMlh9KqyVmreESoRQhASzmXjafeL wvEe0l+Ss7xK/hFc7uQm64cNhht8M34WaEBwCnZ28IQsoBLekoFhefQO1cRSLqNyOq2v +CTg== MIME-Version: 1.0 Received: by 10.50.181.166 with SMTP id dx6mr2946548igc.61.1335539342689; Fri, 27 Apr 2012 08:09:02 -0700 (PDT) Received: by 10.64.7.133 with HTTP; Fri, 27 Apr 2012 08:09:02 -0700 (PDT) In-Reply-To: <3CF7C125-3B76-464A-8C58-D7BDCE72B996@huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B921E48EDCC@SZXEML506-MBS.china.huawei.com> <3CF7C125-3B76-464A-8C58-D7BDCE72B996@huawei.com> Date: Fri, 27 Apr 2012 17:09:02 +0200 Message-ID: From: Bud Millwood To: DHC WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 15:09:06 -0000 Support. - Bud On Thu, Apr 26, 2012 at 4:59 AM, Tina TSOU w= rote: > I support adoption of this draft. > > Sent from my iPad > > On Apr 25, 2012, at 5:00 PM, "Sheng Jiang" wrote: > >> Support adopt this draft. >> >> Sheng >> >>> -----Original Message----- >>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >>> Of Ted Lemon >>> Sent: Wednesday, April 25, 2012 7:38 PM >>> To: DHC WG >>> Subject: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization- >>> opt >>> >>> One of the authors of this draft has requested a formal call for >>> adoption. =A0 There was substantial support for the work in the DHC >>> working group meeting in Paris, and no objections. =A0 The idea is to >>> have a RADIUS option for DHCPv6, similar to the functionality present >>> in DHCPv4. >>> >>> If you favor or oppose taking this on as working group work, please >>> signify by replying to this message. =A0 If you have comments or concer= ns, >>> please raise them now. >>> >>> We will make a determination of consensus on May 9. >>> >>> _______________________________________________ >>> 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 eleven.fuyu@huawei.com Fri Apr 27 18:22:28 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8911E21F85CD for ; Fri, 27 Apr 2012 18:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzrTFGfaW9Wd for ; Fri, 27 Apr 2012 18:22:28 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0E921F8581 for ; Fri, 27 Apr 2012 18:22:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFI75343; Fri, 27 Apr 2012 21:22:24 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 27 Apr 2012 18:22:25 -0700 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 27 Apr 2012 18:22:22 -0700 Received: from SZXEML512-MBX.china.huawei.com ([169.254.5.205]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sat, 28 Apr 2012 09:22:19 +0800 From: "Fuyu (Eleven)" To: Ted Lemon Thread-Topic: Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt Thread-Index: AQHNItfZZYwu+XTN40ChAmrT+ZDKz5asWT0w Date: Sat, 28 Apr 2012 01:22:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.119] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: DHC WG Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 01:22:28 -0000 Hi all, I am in favor of adoption this draft as WG item. Cheers Yu -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Wednesday, April 25, 2012 7:38 PM To: DHC WG Subject: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt One of the authors of this draft has requested a formal call for adoption. = There was substantial support for the work in the DHC working group meeti= ng in Paris, and no objections. The idea is to have a RADIUS option for D= HCPv6, similar to the functionality present in DHCPv4. If you favor or oppose taking this on as working group work, please signify= by replying to this message. If you have comments or concerns, please ra= ise them now. We will make a determination of consensus on May 9. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Sat Apr 28 00:28:33 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D30921F85B6; Sat, 28 Apr 2012 00:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3B1HeCcaObi; Sat, 28 Apr 2012 00:28:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF54221F85AA; Sat, 28 Apr 2012 00:28:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120428072832.29680.8858.idtracker@ietfa.amsl.com> Date: Sat, 28 Apr 2012 00:28:32 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 07:28:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : DHCPv6 through Tunnels Author(s) : Ole Troan Marc Blanchet Xiaohu Xu Dayong Guo Filename : draft-ietf-dhc-dhcpv6-tunnel-01.txt Pages : 5 Date : 2012-04-28 The host configuration protocol DHCPv6 [RFC3315] relies on link-local addresses as source addresses and multicast addresses for destination addresses. However, some tunnel links (e.g., 6rd [RFC5969] ) do not have IPv6 link-local addresses and do not support IPv6 multicast addresses. Taking 6rd as an example, this document specifies how DHCPv6 is used across such tunnel links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-tunnel-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-tunnel-01.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-tunnel/ From Dmitry.Anipko@microsoft.com Sun Apr 29 23:02:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468D921F8464 for ; Sun, 29 Apr 2012 23:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.917 X-Spam-Level: X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrAG+ZJgjBj6 for ; Sun, 29 Apr 2012 23:02:13 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 0870A21F8462 for ; Sun, 29 Apr 2012 23:02:12 -0700 (PDT) Received: from mail79-am1-R.bigfish.com (10.3.201.235) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 30 Apr 2012 06:02:06 +0000 Received: from mail79-am1 (localhost [127.0.0.1]) by mail79-am1-R.bigfish.com (Postfix) with ESMTP id AD34B202A1 for ; Mon, 30 Apr 2012 06:02:06 +0000 (UTC) X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h683h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail79-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail79-am1 (localhost.localdomain [127.0.0.1]) by mail79-am1 (MessageSwitch) id 133576572419532_12992; Mon, 30 Apr 2012 06:02:04 +0000 (UTC) Received: from AM1EHSMHS007.bigfish.com (unknown [10.3.201.229]) by mail79-am1.bigfish.com (Postfix) with ESMTP id EADBC220237 for ; Mon, 30 Apr 2012 06:02:03 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS007.bigfish.com (10.3.207.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 30 Apr 2012 06:02:03 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.298.5; Mon, 30 Apr 2012 06:02:06 +0000 Received: from mail143-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 30 Apr 2012 06:02:00 +0000 Received: from mail143-va3 (localhost [127.0.0.1]) by mail143-va3-R.bigfish.com (Postfix) with ESMTP id 490B8200204 for ; Mon, 30 Apr 2012 06:02:00 +0000 (UTC) Received: from mail143-va3 (localhost.localdomain [127.0.0.1]) by mail143-va3 (MessageSwitch) id 1335765718518928_16777; Mon, 30 Apr 2012 06:01:58 +0000 (UTC) Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.249]) by mail143-va3.bigfish.com (Postfix) with ESMTP id 6EF01400C0; Mon, 30 Apr 2012 06:01:58 +0000 (UTC) Received: from CH1PRD0310HT001.namprd03.prod.outlook.com (157.56.244.37) by VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 30 Apr 2012 06:01:58 +0000 Received: from CH1PRD0310MB368.namprd03.prod.outlook.com ([169.254.8.207]) by CH1PRD0310HT001.namprd03.prod.outlook.com ([10.255.137.36]) with mapi id 14.16.0152.000; Mon, 30 Apr 2012 06:02:02 +0000 From: Dmitry Anipko To: Peng Wu Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces Thread-Index: AQHNHttcYQYOfcHHP0e26AM9IBh66Jay7lzA Date: Mon, 30 Apr 2012 06:02:02 +0000 Message-ID: <96DD85EB136DCD49AB5CDB6DEC9639AD0588F08A@CH1PRD0310MB368.namprd03.prod.outlook.com> References: <201204161209.q3GC90RH089072@givry.fdupont.fr> <96DD85EB136DCD49AB5CDB6DEC9639AD0584DBA9@CH1PRD0310MB368.namprd03.prod.outlook.com> <96DD85EB136DCD49AB5CDB6DEC9639AD05851197@CH1PRD0310MB368.namprd03.prod.outlook.com> <99591DAE-D8CD-4F06-BEFE-9679D3A36A78@nominum.com> <96DD85EB136DCD49AB5CDB6DEC9639AD058565F0@CH1PRD0310MB368.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%FDUPONT.FR$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NOMINUM.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "dhcwg@ietf.org" , Francis Dupont , Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 06:02:14 -0000 >> My answer to this is, from Softwire perspective, we currently don't have= use case for that. One tunnel, one CRA, one client, that's all. If there is no scenario for multiple tunnels, then I think it would be fine= to just say that and that the only supported configuration is with one CRA= and one tunnel interface per host.=20 In my opinion, having such addition would help to avoid different implement= ations for the multiple interfaces case, which actually would not be intero= perable with one another. -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of P= eng Wu Sent: Friday, April 20, 2012 2:53 AM To: Dmitry Anipko Cc: dhcwg@ietf.org; Francis Dupont; Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 int= erfaces Dmitry, > As I understand, your comment rather relates to "assuming this specific > requirement (same CRA used by multiple tunnel endpoints) must be included= in > the text, what the solution is". That's a different question, which only > appears if there is a requirement for same CRA to serve multiple tunnel > endpoints (as opposed to e.g. having per tunnel endpoint CRA). Are there > reasons to have that as a requirement? I think it somehow reflects your original concern. Because in some cases we cannot simply require multiple IPv6 addresses to satisfy multiple CRAs. BTW, I think about this again and find that , even if we can require multiple IPv6 addresses since all the DHCP messages are broadcasted on the same link, we may still require different client IDs to clarify which CRA to serve which messages. So it's really about request multiple addresses through ONE link with broadcast. My answer to this is, from Softwire perspective, we currently don't have use case for that. One tunnel, one CRA, one client, that's all. >From DHC perspective, it's reasonable to raise the doubt that, now that a relay is put inside the host, and if the host have multiple tunnels which requires one IPv4 address each, how does the relay behave ( as you've raised in Paris). About the solution, I'm starting to think that AS LONG AS we require multiple IPv4 addresses on ONE link with broadcast, we need multiple client IDs. If we have a *one-for-all* client runs on the physical interface, it will need multiple state machines. If we have multiple clients run on different VIFs (which Francis emphasised is not a good idea), we need some extra implementation effort to achieve the message "transmission" between the VIF and the physical interface. In the first case, multiple CRAs won't help; in the second case, the message can be "transmitted" to different CRAs directly inside the host, so we won't need the aid from client id (at the cost of extra implemenation). What do you guys think? If we settle this, I think we should make a fast revision (Francis has aleady raised some review inputs on the other thread) and try to request WGLC. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From pjhingra@cisco.com Mon Apr 30 08:32:09 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D59A21F861D for ; Mon, 30 Apr 2012 08:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.298 X-Spam-Level: X-Spam-Status: No, score=-110.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGMIeugeitud for ; Mon, 30 Apr 2012 08:32:07 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id A9F2C21F85FB for ; Mon, 30 Apr 2012 08:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pjhingra@cisco.com; l=26118; q=dns/txt; s=iport; t=1335799926; x=1337009526; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=3lfMbVaRQsAY4DVIIYcgSkXgSsUP4NpvRUpYTqeDHac=; b=hmG17z8yGh0ibhtV3roklkhAeyZv45v5ZDmBuFMU9aRud1vvVa3V7XyE Mhq/jEmbcMQFKO+rN01kmpqEkNpniiX/S07xcsFNzeGmxmUvNIxmDYWAP xW1OPdVlCZ9ycpq8suFZRGd72xGCtI7YLRQD0AgLpjtKRzljs40ScyhdT k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEADqwnk9Io8UY/2dsb2JhbAA6CoJGrQGEB4IJAQEBAwEBAQEPAQkBEAMeIBAHBAIBCBEDAQEBCwIBAxAHAQYBIAYKFQkIAQEEAQoICAEUBAGHXQMGBQuaEZYNDYlTigx3hTxjBIhimFuDGoFpgnCBVA X-IronPort-AV: E=Sophos;i="4.75,504,1330905600"; d="scan'208,217";a="11160033" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 30 Apr 2012 15:32:03 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3UFW3ak030091; Mon, 30 Apr 2012 15:32:03 GMT Received: from xmb-bgl-413.cisco.com ([72.163.129.209]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Apr 2012 21:02:03 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD26E6.64299074" Date: Mon, 30 Apr 2012 21:02:01 +0530 Message-ID: <0C34754A9045B3419FB531A8C716E24908209705@XMB-BGL-413.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhcwg Digest, Vol 96, Issue 38 Thread-Index: Ac0kdbCVNGhiRpk+Qm+eSKZjrySILACcK7aQ References: From: "Prashant Jhingran (pjhingra)" To: "Shankari Vaidyalingam" , X-OriginalArrivalTime: 30 Apr 2012 15:32:03.0389 (UTC) FILETIME=[647D76D0:01CD26E6] Subject: Re: [dhcwg] dhcwg Digest, Vol 96, Issue 38 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 15:32:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD26E6.64299074 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/id/draft-ietf-dhc-client-id-02.txt =20 - Regards, Prashant Jhingran =20 =20 From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Shankari Vaidyalingam Sent: Friday, April 27, 2012 6:30 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] dhcwg Digest, Vol 96, Issue 38 =20 Hi, Can you let me know where can I get this draft - draft-ietf-dhc-client-id-02. Regards, Shankari.V On Fri, Apr 27, 2012 at 12:30 AM, wrote: If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/dhcwg Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send dhcwg mailing list submissions to dhcwg@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/dhcwg or, via email, send a message with subject or body 'help' to dhcwg-request@ietf.org You can reach the person managing the list at dhcwg-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dhcwg digest..." Today's Topics: 1. Re: WGLC: draft-ietf-dhc-client-id-02 (Richard Johnson) 2. Re: Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt (Sheng Jiang) 3. Re: Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt (Leaf yeh) 4. Re: Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt (Tina TSOU) ---------------------------------------------------------------------- Message: 1 Date: Wed, 25 Apr 2012 12:59:39 -0700 From: Richard Johnson To: Ted Lemon Cc: DHC WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 Message-ID: <0579F6EF-7CBE-456C-AFE4-756023B0D406@cisco.com> Content-Type: text/plain; charset=3Dwindows-1252 I definitely support this draft, although I think the current description of the problem to be solved could use quite a lot of work to make it more clear. Your own description is quite clear, but the document is not really. /raj On Apr 14, 2012, at 5:54 AM, Ted Lemon wrote: > This document corrects a bug in RFC2131 that forbids the DHCP server from returning a DHCP client identifier. The lack of a DHCP client identifier creates a problem in two cases: where the underlying transport has no link-layer address, and where two clients are running on the same host, supplying different client identifiers so as to present different network identities. In both of these cases, insufficient information is returned from the DHCP server to clearly identify the client that is the intended recipient of the message. The only way to fix this is to _require_ the DHCP server to return the client identifier if it receives it. This is what the proposed document does. > > We checked for consensus in the meeting, and four people were in favor of advancing the draft; nobody was against. > > I think this is actually pretty important work?it's a lingering bug in the spec which I think will come back to bite us more and more as we start getting deeper into the dual-stack transition. So if you haven't read the document, please do. > > If you support advancing it, please signify by replying to this message and saying that you support it. If you think it's a bad idea, please signify by replying to this message and explaining why. If you have comments or changes to propose, please send them along, and also signify whether you are in favor of advancement with the change, without the change, or oppose advancement. > > We will determine consensus on April 27, based solely on responses on the mailing list, so please do respond. > > Thanks! > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg ------------------------------ Message: 2 Date: Wed, 25 Apr 2012 23:42:38 +0000 From: Sheng Jiang To: Ted Lemon , DHC WG Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt Message-ID: =20 <5D36713D8A4E7348A7E10DF7437A4B921E48EDCC@SZXEML506-MBS.china.huawei.com > Content-Type: text/plain; charset=3D"us-ascii" Support adopt this draft. Sheng > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Ted Lemon > Sent: Wednesday, April 25, 2012 7:38 PM > To: DHC WG > Subject: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization- > opt > > One of the authors of this draft has requested a formal call for > adoption. There was substantial support for the work in the DHC > working group meeting in Paris, and no objections. The idea is to > have a RADIUS option for DHCPv6, similar to the functionality present > in DHCPv4. > > If you favor or oppose taking this on as working group work, please > signify by replying to this message. If you have comments or concerns, > please raise them now. > > We will make a determination of consensus on May 9. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg ------------------------------ Message: 3 Date: Thu, 26 Apr 2012 01:36:56 +0000 From: Leaf yeh To: Ted Lemon , Tomek Mrugalski Cc: "" Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt Message-ID: =20 Content-Type: text/plain; charset=3D"utf-8" Tomek - Once adopted, it seems reasonable to call this draft draft-ietf-dhc-dhcpv6-radius-option, rather than -authorization-. Ted - Yes, I agree completely. Leaf, is that okay with you? FYI again, the context including the title of draft & the name of the new option has been updated to the 'RADIUS option' in the draft-yeh-01. Yes, I am OK with this suggestion. Best Regards, Leaf ------------------------------------------------------------------------ ---------------------------------------- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Wednesday, April 25, 2012 9:53 PM To: Tomek Mrugalski Cc: Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt On Apr 25, 2012, at 9:37 AM, Tomek Mrugalski ?wrote: Once adopted, it seems reasonable to call this draft draft-ietf-dhc-dhcpv6-radius-option, rather than -authorization-. Yes, I agree completely. ? Leaf, is that okay with you? Tomek, are you for or against adoption? ? (Or don't have an opinion?) ------------------------------ Message: 4 Date: Thu, 26 Apr 2012 02:59:50 +0000 From: Tina TSOU To: Sheng Jiang Cc: DHC WG , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt Message-ID: <3CF7C125-3B76-464A-8C58-D7BDCE72B996@huawei.com> Content-Type: text/plain; charset=3D"us-ascii" I support adoption of this draft. Sent from my iPad On Apr 25, 2012, at 5:00 PM, "Sheng Jiang" wrote: > Support adopt this draft. > > Sheng > >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >> Of Ted Lemon >> Sent: Wednesday, April 25, 2012 7:38 PM >> To: DHC WG >> Subject: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization- >> opt >> >> One of the authors of this draft has requested a formal call for >> adoption. There was substantial support for the work in the DHC >> working group meeting in Paris, and no objections. The idea is to >> have a RADIUS option for DHCPv6, similar to the functionality present >> in DHCPv4. >> >> If you favor or oppose taking this on as working group work, please >> signify by replying to this message. If you have comments or concerns, >> please raise them now. >> >> We will make a determination of consensus on May 9. >> >> _______________________________________________ >> 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 End of dhcwg Digest, Vol 96, Issue 38 ************************************* =20 ------_=_NextPart_001_01CD26E6.64299074 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    http://www.ietf.org/id/draft-ietf-dhc-client-id-02.txt

     

    -

    Regards,

    Prashant = Jhingran

     

     

    From:= = dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Shankari Vaidyalingam
    Sent: Friday, April 27, 2012 6:30 = PM
    To: dhcwg@ietf.org
    Subject: Re: [dhcwg] dhcwg = Digest, Vol 96, Issue 38

     

    Hi,

    Can you let me know where can = I get this draft - = draft-ietf-dhc-client-id-02.

    Regards,
    Shankari.V

    =

    On Fri, Apr 27, 2012 at 12:30 AM, <dhcwg-request@ietf.org> wrote:

    If you have received this digest without all the = individual message
    attachments you will need to update your digest = options in your list
    subscription.  To do so, go to

    https://www.ietf.org/mailman/listinfo/dhcwg

    = Click the 'Unsubscribe or edit options' button, log in, and set = "Get
    MIME or Plain Text Digests?" to MIME.  You can = set this option
    globally for all the list digests you receive at this = point.



    Send dhcwg mailing list submissions to
      =      dhcwg@ietf.org

    To subscribe or = unsubscribe via the World Wide Web, visit
          =  https://www.ietf.org/mailman/listinfo/dhcwg
    or, = via email, send a message with subject or body 'help' to
      =      dhcwg-request@ietf.org

    = You can reach the person managing the list at
          =  dhcwg-owner@ietf.org

    When= replying, please edit your Subject line so it is more specific
    than = "Re: Contents of dhcwg digest..."


    Today's = Topics:

      1. Re: WGLC: draft-ietf-dhc-client-id-02 (Richard = Johnson)
      2. Re: Call for adoption:   =  draft-yeh-dhc-dhcpv6-authorization-opt
        =  (Sheng Jiang)
      3. Re: Call  for     = adoption:       = draft-yeh-dhc-dhcpv6-authorization-opt
         (Leaf = yeh)
      4. Re: Call for      adoption:   =     draft-yeh-dhc-dhcpv6-authorization-opt
        =  (Tina = TSOU)


    --------------------------------------------------------= --------------

    Message: 1
    Date: Wed, 25 Apr 2012 12:59:39 = -0700
    From: Richard Johnson <raj@cisco.com>
    To: Ted Lemon = <Ted.Lemon@nominum.com>
    Cc= : DHC WG <dhcwg@ietf.org>
    Subject: Re: = [dhcwg] WGLC: draft-ietf-dhc-client-id-02
    Message-ID: <0579F6EF-7= CBE-456C-AFE4-756023B0D406@cisco.com>
    Content-Type: = text/plain; charset=3Dwindows-1252

    I definitely support this = draft, although I think the current description of the problem to be = solved could use quite a lot of work to make it more clear.  Your = own description is quite clear, but the document is not = really.

    /raj


    On Apr 14, 2012, at 5:54 AM, Ted Lemon = wrote:

    > This document corrects a bug in RFC2131 that forbids = the DHCP server from returning a DHCP client identifier.   The lack = of a DHCP client identifier creates a problem in two cases: where the = underlying transport has no link-layer address, and where two clients = are running on the same host, supplying different client identifiers so = as to present different network identities.   In both of these = cases, insufficient information is returned from the DHCP server to = clearly identify the client that is the intended recipient of the = message.   The only way to fix this is to _require_ the DHCP server = to return the client identifier if it receives it.   This is what = the proposed document does.
    >
    > We checked for consensus in = the meeting, and four people were in favor of advancing the draft; = nobody was against.
    >
    > I think this is actually pretty = important work?it's a lingering bug in the spec which I think will come = back to bite us more and more as we start getting deeper into the = dual-stack transition.   So if you haven't read the document, = please do.
    >
    > If you support advancing it, please signify = by replying to this message and saying that you support it. If you think = it's a bad idea, please signify by replying to this message and = explaining why.   If you have comments or changes to propose, = please send them along, and also signify whether you are in favor of = advancement with the change, without the change, or oppose = advancement.
    >
    > We will determine consensus on April 27, = based solely on responses on the mailing list, so please do = respond.
    >
    > Thanks!
    >
    > = _______________________________________________
    > dhcwg mailing = list
    > dhcwg@ietf.org
    > https://www.ietf.org/mailman/listinfo/dhcwg

    =

    ------------------------------

    Message: 2
    Date: Wed, = 25 Apr 2012 23:42:38 +0000
    From: Sheng Jiang <jiangsheng@huawei.com>
    To= : Ted Lemon <Ted.Lemon@nominum.com>, DHC = WG <dhcwg@ietf.org>
    Subject: Re: = [dhcwg] Call for adoption:
          =  draft-yeh-dhc-dhcpv6-authorization-opt
    Message-ID:
      =      <5D36713D8A4E7348A7E10DF7437A4B921E48EDCC@SZXEML506-MBS.chi= na.huawei.com>

    Content-Type: text/plain; = charset=3D"us-ascii"

    Support adopt this = draft.

    Sheng

    > -----Original Message-----
    > From: = dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] On = Behalf
    > Of Ted Lemon
    > Sent: Wednesday, April 25, 2012 7:38 = PM
    > To: DHC WG
    > Subject: [dhcwg] Call for adoption: = draft-yeh-dhc-dhcpv6-authorization-
    > opt
    >
    > One of = the authors of this draft has requested a formal call for
    > = adoption.   There was substantial support for the work in the = DHC
    > working group meeting in Paris, and no objections.   = The idea is to
    > have a RADIUS option for DHCPv6, similar to the = functionality present
    > in DHCPv4.
    >
    > If you favor or = oppose taking this on as working group work, please
    > signify by = replying to this message.   If you have comments or = concerns,
    > please raise them now.
    >
    > We will make a = determination of consensus on May 9.
    >
    > = _______________________________________________
    > dhcwg mailing = list
    > dhcwg@ietf.org
    > https://www.ietf.org/mailman/listinfo/dhcwg

    =
    ------------------------------

    Message: 3
    Date: Thu, 26 = Apr 2012 01:36:56 +0000
    From: Leaf yeh <leaf.y.yeh@huawei.com>
    To= : Ted Lemon <Ted.Lemon@nominum.com>, = Tomek Mrugalski
           <tomasz.mrugalski@gmail.com= >
    Cc: "<dhcwg@ietf.org>" <dhcwg@ietf.org>
    Subject: Re: = [dhcwg] Call       for     adoption:
      =     =  draft-yeh-dhc-dhcpv6-authorization-opt
    Message-ID:
      =      <E1CE3E6E6D4E1C438B0ADC9FFFA345EA262CB99C@SZXEML510-MBS.chi= na.huawei.com>

    Content-Type: text/plain; = charset=3D"utf-8"

    Tomek - Once adopted, it seems = reasonable to call this draft
    draft-ietf-dhc-dhcpv6-radius-option, = rather than -authorization-.
    Ted - Yes, I agree completely.   = Leaf, is that okay with you?

    FYI again, the context including the = title of draft & the name of the new option  has been updated = to the 'RADIUS option' in the draft-yeh-01.

    Yes, I am OK with = this suggestion.


    Best = Regards,
    Leaf


    ---------------------------------------------= -------------------------------------------------------------------
    Fr= om: dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] On = Behalf Of Ted Lemon
    Sent: Wednesday, April 25, 2012 9:53 PM
    To: = Tomek Mrugalski
    Cc: <dhcwg@ietf.org>
    Subject: Re: = [dhcwg] Call for adoption: = draft-yeh-dhc-dhcpv6-authorization-opt

    On Apr 25, 2012, at 9:37 = AM, Tomek Mrugalski <tomasz.mrugalski@gmail.com= >
    ?wrote:
    Once adopted, it seems reasonable to call this = draft
    draft-ietf-dhc-dhcpv6-radius-option, rather than = -authorization-.

    Yes, I agree completely. ? Leaf, is that okay = with you?

    Tomek, are you for or against adoption? ? (Or don't = have an = opinion?)


    ------------------------------

    Message: = 4
    Date: Thu, 26 Apr 2012 02:59:50 +0000
    From: Tina TSOU <Tina.Tsou.Zouting@huawei.com= >
    To: Sheng Jiang <jiangsheng@huawei.com>
    Cc= : DHC WG <dhcwg@ietf.org>, = Ted Lemon <Ted.Lemon@nominum.com>
    Su= bject: Re: [dhcwg] Call for   adoption:
          =  draft-yeh-dhc-dhcpv6-authorization-opt
    Message-ID: <3CF7C125-= 3B76-464A-8C58-D7BDCE72B996@huawei.com>
    Content-Type: = text/plain; charset=3D"us-ascii"

    I support adoption of = this draft.

    Sent from my iPad

    On Apr 25, 2012, at 5:00 PM, = "Sheng Jiang" <jiangsheng@huawei.com> = wrote:

    > Support adopt this draft.
    >
    > = Sheng
    >
    >> -----Original Message-----
    >> From: = dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] On = Behalf
    >> Of Ted Lemon
    >> Sent: Wednesday, April 25, = 2012 7:38 PM
    >> To: DHC WG
    >> Subject: [dhcwg] Call = for adoption: draft-yeh-dhc-dhcpv6-authorization-
    >> = opt
    >>
    >> One of the authors of this draft has = requested a formal call for
    >> adoption.   There was = substantial support for the work in the DHC
    >> working group = meeting in Paris, and no objections.   The idea is to
    >> = have a RADIUS option for DHCPv6, similar to the functionality = present
    >> in DHCPv4.
    >>
    >> If you favor or = oppose taking this on as working group work, please
    >> signify = by replying to this message.   If you have comments or = concerns,
    >> please raise them now.
    >>
    >> We = will make a determination of consensus on May 9.
    >>
    >> = _______________________________________________
    >> 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

    =
    End of dhcwg Digest, Vol 96, Issue = 38
    *************************************

     

    ------_=_NextPart_001_01CD26E6.64299074-- From pengwu.thu@gmail.com Mon Apr 30 09:20:29 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B5721F8753 for ; Mon, 30 Apr 2012 09:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svff84z+nhLj for ; Mon, 30 Apr 2012 09:20:28 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0545321F8752 for ; Mon, 30 Apr 2012 09:20:27 -0700 (PDT) Received: by dady13 with SMTP id y13so5709029dad.27 for ; Mon, 30 Apr 2012 09:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G2L3mv1omaZakZjdMAOQySd58TyG2jQompkPNM5kWzw=; b=fYmkwHTqvJcmZ++kmYP/9H9avDPydsC00yx0i4JUeKhL+elzYgZnHDKHpq0qnX3BtN HbxPWHQADCiPNU5XOPSQ4NzkTKJHN3J+uMIB7JoPjG6AJtIesn6dBkLoUBUK1OWANKlR M5+tqTnMjaq9T0/YCaFfti5oHpTJ0nP3tCyrW6x+GKCMtY22KpbUCC0JmHoWgoWEwFl5 YzeAKnOgtgUWMwOxuM+w/H8nil4oTeBWpcilRoN6Kx/l8O9fw29wMcmRZtRUta04IIl6 UUMy31zGZE3ZZ2adPF9xPWhAk+KZ4B6/bCDrSemX+ACygdGCrOc0lrLL+M/VOA0M1FWE U1WQ== MIME-Version: 1.0 Received: by 10.68.236.165 with SMTP id uv5mr8363180pbc.37.1335802827696; Mon, 30 Apr 2012 09:20:27 -0700 (PDT) Received: by 10.68.218.4 with HTTP; Mon, 30 Apr 2012 09:20:27 -0700 (PDT) In-Reply-To: <96DD85EB136DCD49AB5CDB6DEC9639AD0588F08A@CH1PRD0310MB368.namprd03.prod.outlook.com> References: <201204161209.q3GC90RH089072@givry.fdupont.fr> <96DD85EB136DCD49AB5CDB6DEC9639AD0584DBA9@CH1PRD0310MB368.namprd03.prod.outlook.com> <96DD85EB136DCD49AB5CDB6DEC9639AD05851197@CH1PRD0310MB368.namprd03.prod.outlook.com> <99591DAE-D8CD-4F06-BEFE-9679D3A36A78@nominum.com> <96DD85EB136DCD49AB5CDB6DEC9639AD058565F0@CH1PRD0310MB368.namprd03.prod.outlook.com> <96DD85EB136DCD49AB5CDB6DEC9639AD0588F08A@CH1PRD0310MB368.namprd03.prod.outlook.com> Date: Tue, 1 May 2012 00:20:27 +0800 Message-ID: From: Peng Wu To: Dmitry Anipko Content-Type: multipart/alternative; boundary=047d7b33d6ee08ebbe04bee7d5f7 Cc: "dhcwg@ietf.org" , Francis Dupont , Ted Lemon Subject: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 16:20:29 -0000 --047d7b33d6ee08ebbe04bee7d5f7 Content-Type: text/plain; charset=ISO-8859-1 Dmitry, On Monday, April 30, 2012, Dmitry Anipko wrote: > >> My answer to this is, from Softwire perspective, we currently don't > have use case for that. One tunnel, one CRA, one client, that's all. > > If there is no scenario for multiple tunnels, then I think it would be > fine to just say that and that the only supported configuration is with one > CRA and one tunnel interface per host. > > In my opinion, having such addition would help to avoid different > implementations for the multiple interfaces case, which actually would not > be interoperable with one another I agree with you. I propose we keep one CRA and one tunnel per host as the default case in the draft, and put an appendix section to discuss the multi tunnel case. In this way we can be precise on this issue. I'll come up with a new version soon to address this. Thanks. --047d7b33d6ee08ebbe04bee7d5f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dmitry,

    On Monday, April 30, 2012, Dmitry Anipko wrote:
    >> My answer to this is, from Softwire perspec= tive, we currently don't have use case for that. One tunnel, one CRA, o= ne client, that's all.

    If there is no scenario for multiple tunnels, then I think it would be fine= to just say that and that the only supported configuration is with one CRA= and one tunnel interface per host.

    In my opinion, having such addition would help to avoid different implement= ations for the multiple interfaces case, which actually would not be intero= perable with one another
    =A0I agree with you.
    I propose we keep one CRA and one tunnel per host as the default case in th= e draft, and put an appendix section to discuss the multi tunnel case. In t= his way we can be precise on this issue.
    I'll come up with a = new version soon to address this. Thanks.
    --047d7b33d6ee08ebbe04bee7d5f7-- From wwwrun@rfc-editor.org Mon Apr 30 10:52:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798C321F88B8; Mon, 30 Apr 2012 10:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.571 X-Spam-Level: X-Spam-Status: No, score=-104.571 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16zh91s16Jp5; Mon, 30 Apr 2012 10:52:11 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAE121F88B6; Mon, 30 Apr 2012 10:52:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 706BFB1E007; Mon, 30 Apr 2012 10:50:26 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120430175026.706BFB1E007@rfc-editor.org> Date: Mon, 30 Apr 2012 10:50:26 -0700 (PDT) Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 6607 on Virtual Subnet Selection Options for DHCPv4 and DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 17:52:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6607 Title: Virtual Subnet Selection Options for DHCPv4 and DHCPv6 Author: K. Kinnear, R. Johnson, M. Stapp Status: Standards Track Stream: IETF Date: April 2012 Mailbox: kkinnear@cisco.com, raj@cisco.com, mjs@cisco.com Pages: 26 Characters: 60312 Updates: RFC3046 I-D Tag: draft-ietf-dhc-vpn-option-15.txt URL: http://www.rfc-editor.org/rfc/rfc6607.txt This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC