David W. Hankins

SRE - Systems Engineer

Google, Inc.

--0016e64716061a940604a8e98a0b-- From tomasz.mrugalski@gmail.com Mon Jul 25 15:02:18 2011 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 8900021F8A80 for ; Mon, 25 Jul 2011 15:02:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-ukyel9xqi8 for ; Mon, 25 Jul 2011 15:02:17 -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 971E521F8A7E for ; Mon, 25 Jul 2011 15:02:17 -0700 (PDT) Received: by gyd5 with SMTP id 5so2922244gyd.31 for ; Mon, 25 Jul 2011 15:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yYzgtmC/4ZoZAZE9+nBmGUa3a+iS+BsPJaBLgDuuook=; b=gzRCs7vJBoXIfZeYjcZY28kj6u1CrkpG+8LeO2KKksGSfO+vn5pzhS152k8ILIQ3Fh azgqCpBVpMiPxcRz6lfeyC4QiPgdQhAIIINwevyGhrgk58BASUDRJ3HmU9NQvsmwmgXI 127wlzo1NPXQJwHIM5q7WfGLVuzKjSKpYxYI4= Received: by 10.142.142.21 with SMTP id p21mr2171343wfd.265.1311631336711; Mon, 25 Jul 2011 15:02:16 -0700 (PDT) Received: from dhcp-158e.meeting.ietf.org (dhcp-158e.meeting.ietf.org [130.129.21.142]) by mx.google.com with ESMTPS id a14sm1085181wfg.19.2011.07.25.15.02.15 (version=SSLv3 cipher=OTHER); Mon, 25 Jul 2011 15:02:16 -0700 (PDT) Message-ID: <4E2DE7E5.1050600@gmail.com> Date: Mon, 25 Jul 2011 18:02:13 -0400 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: jouni korhonen References: <4E2C7836.5090404@gmail.com> <8028E635-78F5-4979-8DF5-1F329317B90D@gmail.com> In-Reply-To: <8028E635-78F5-4979-8DF5-1F329317B90D@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: DHC WG Subject: Re: [dhcwg] Comments on draft-ietf-dhc-pd-exclude-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, 25 Jul 2011 22:02:18 -0000 On 11-07-25 14:07, jouni korhonen wrote: > Hi Tomasz, >> 1. Section 5.1 describes SOLICIT-ADVERTISE exchange and concludes >> that received PD_EXCLUDE may be used to select best server. You may >> want to add a single sentence similar to "Requesting router MUST >> proceed to Prefix Delegation procedure described in section 6.1". > > Makes sense. Great. > >> 2. Section 5.1 describes 4 message exchange. What if delegating >> router wants to use rapid-commit (SOLICIT-REPLY)? You should add a >> clarification that requesting router MUST use received values in >> REPLY if rapid-commit option was sent in SOLICIT (recommended). >> Alternatively, you may say that rapid-commit is not allowed with >> PD_EXCLUDE (that would be unnecessary restriction, so it is not >> recommended). > > Hmm.. restricting rapid-commit wouldn't make sense, agree. However, > the current wording is like it is now due trying to be align with > RFC3633, which has the following text in Section 11.1: > > ... 3315. The requesting router MAY choose to consider the presence > of advertised prefixes in its decision about which delegating router > to respond to. It is MAY, not MUST. Requesting router may choose not to do it. My understanding is that requesting router may use rapid-commit and then it MUST use whatever is required. On the other hand, the use case for router doing rapid-commit is really a minor use case. > The above implies me also a 4 message exchange. How about: > > Once receiving Advertise message, the requesting router uses the > prefix(es) received in OPTION_PD_EXCLUDE in addition to the > advertised prefixes to choose the delegating router. Requesting > router MUST proceed to Prefix Delegation procedure described in > Section 6.1. If Advertise message did not include OPTION_PD_EXCLUDE > option, then the requesting router MUST fall back to normal [RFC3633] > Section 11.1 behavior. Sounds good. As for the rapid-commit, maybe something along the following lines would do the trick: "Requesting router MAY use rapid-commit. Requesting router that sent SOLICIT message with rapid-commit option, MUST use received prefix, regardless if PD_EXCLUDE option was provided or not." It should be noted that rapid-commit benefits for routers are rather small at this time, but mobile routers avialability is expected to rise sharply. You may also put a comment about trade-offs between 4 message exchange and rapid-commit: 4 message is slower, but client is allowed to choose best server. 2 message is faster, but you have to use what you get first. >> Ok, that was the last time I tried to convince you to use ORO >> suboption. Regardless of your decision, I strongly support your >> draft. > > I understand this. My issue is more of the lack of clear text for > this type of OPTION_ORO usage in RFC3315. I can see it mentioned in That's the whole reason for my draft. RFC3315 is completely silent about requesting suboptions. I want to clarify that. I'm not lobbying for any particular way of doing that. I just strongly feel that we should agree on one way and stick to it. That will be the key message of my presentation on Thursday. If the WG recommendation is to stick with a single, top-level ORO, I'm fine with it. dhcpv6-suboptions draft will just get much simpler. > Appendix B table but that is all. In order to provide unambiguous > solution I would most probably add all required text in this I-D as > standalone or reference to draft-mrugalski (apparently it the should > be a normative reference, with normative language). I don't find > either of these as a good approach. Yes, I see your point. If you put normative reference, it may hold back publication if pd-exclude until dhcpv6-suboptions is published. I'm not sure if that is something that can be avoided. Tomek From jouni.nospam@gmail.com Mon Jul 25 16:26:14 2011 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 0B60B11E80D7 for ; Mon, 25 Jul 2011 16:26:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LotTUHBIGzoX for ; Mon, 25 Jul 2011 16:26:13 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF6011E80B1 for ; Mon, 25 Jul 2011 16:26:13 -0700 (PDT) Received: by pzk6 with SMTP id 6so8840582pzk.26 for ; Mon, 25 Jul 2011 16:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dLWcKrSI2iGfzSVzY1BbUMHAKnMuY2F9XoErgkrTAsU=; b=EmIQzCmbiY72BG8O57qE5s42JlNJQZTQ7kHN2UUJ57QK8tsKU7Nnf3P9bybFDAp3+3 3dxtlT40r5jxVNMSgrb/9B6vDfRyUkP8GGCWwGEIc9nTmTczf/1G02QPWREczi4Zfa2M nvXUx5fGbtaAcotWapzolhK/6iTLrsVnM246g= Received: by 10.68.36.135 with SMTP id q7mr5079478pbj.222.1311636373125; Mon, 25 Jul 2011 16:26:13 -0700 (PDT) Received: from dhcp-4052.meeting.ietf.org (dhcp-4052.meeting.ietf.org [130.129.64.82]) by mx.google.com with ESMTPS id z6sm5028057pbc.94.2011.07.25.16.26.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jul 2011 16:26:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4E2DE7E5.1050600@gmail.com> Date: Tue, 26 Jul 2011 02:26:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E2C7836.5090404@gmail.com> <8028E635-78F5-4979-8DF5-1F329317B90D@gmail.com> <4E2DE7E5.1050600@gmail.com> To: Tomasz Mrugalski X-Mailer: Apple Mail (2.1084) Cc: DHC WG Subject: Re: [dhcwg] Comments on draft-ietf-dhc-pd-exclude-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, 25 Jul 2011 23:26:14 -0000 On Jul 26, 2011, at 1:02 AM, Tomasz Mrugalski wrote: [snip] >>=20 >>=20 >> Once receiving Advertise message, the requesting router uses the=20 >> prefix(es) received in OPTION_PD_EXCLUDE in addition to the=20 >> advertised prefixes to choose the delegating router. Requesting=20 >> router MUST proceed to Prefix Delegation procedure described in=20 >> Section 6.1. If Advertise message did not include OPTION_PD_EXCLUDE >> option, then the requesting router MUST fall back to normal [RFC3633] >> Section 11.1 behavior. > Sounds good. >=20 > As for the rapid-commit, maybe something along the following lines = would > do the trick: "Requesting router MAY use rapid-commit. Requesting = router > that sent SOLICIT message with rapid-commit option, MUST use received > prefix, regardless if PD_EXCLUDE option was provided or not." I think there is no need to explicitly mention rapid commit. However, a = closer alignment with RFC3633 would be like below: Once receiving Advertise message, the requesting router MAY use the prefix(es) received in OPTION_PD_EXCLUDE in addition to the=20 advertised prefixes to choose the delegating router. Requesting=20 ... >=20 > It should be noted that rapid-commit benefits for routers are rather > small at this time, but mobile routers avialability is expected to = rise > sharply. You may also put a comment about trade-offs between 4 message > exchange and rapid-commit: 4 message is slower, but client is allowed = to > choose best server. 2 message is faster, but you have to use what you > get first. Hmm.. rapid commit is something that is in RFC3315 and folks know its = benefits. I don't think we need to explore that further in this = document. >=20 >>> Ok, that was the last time I tried to convince you to use ORO >>> suboption. Regardless of your decision, I strongly support your >>> draft. >>=20 >> I understand this. My issue is more of the lack of clear text for >> this type of OPTION_ORO usage in RFC3315. I can see it mentioned in > That's the whole reason for my draft. RFC3315 is completely silent = about > requesting suboptions. I want to clarify that. I'm not lobbying for = any > particular way of doing that. I just strongly feel that we should = agree > on one way and stick to it. That will be the key message of my > presentation on Thursday. If the WG recommendation is to stick with a > single, top-level ORO, I'm fine with it. dhcpv6-suboptions draft will > just get much simpler. >=20 >> Appendix B table but that is all. In order to provide unambiguous >> solution I would most probably add all required text in this I-D as >> standalone or reference to draft-mrugalski (apparently it the should >> be a normative reference, with normative language). I don't find >> either of these as a good approach. > Yes, I see your point. If you put normative reference, it may hold = back > publication if pd-exclude until dhcpv6-suboptions is published. I'm = not > sure if that is something that can be avoided. Imho better just leave it out of this document. - Jouni >=20 > Tomek From Maximilien.MOUTON@cea.fr Tue Jul 26 05:23:53 2011 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 8CC7A21F8AF3 for ; Tue, 26 Jul 2011 05:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyxvaVBbX5iO for ; Tue, 26 Jul 2011 05:23:53 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id C416D21F8AF0 for ; Tue, 26 Jul 2011 05:23:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p6QCNoIB020726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Jul 2011 14:23:50 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p6QCNorP008091; Tue, 26 Jul 2011 14:23:50 +0200 (envelope-from Maximilien.MOUTON@cea.fr) Received: from EXCAH-B3.intra.cea.fr (excah-b3.intra.cea.fr [132.166.88.88]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p6QCNojn011691; Tue, 26 Jul 2011 14:23:50 +0200 Received: from EXDAG0-A3.intra.cea.fr ([fe80::25a1:c396:2106:4c5b]) by EXCAH-B3.intra.cea.fr ([fe80::947a:e02d:e083:3de0%11]) with mapi id 14.01.0270.001; Tue, 26 Jul 2011 14:23:49 +0200 From: MOUTON Maximilien To: Mikael Abrahamsson , Alexandru Petrescu Thread-Topic: [dhcwg] comment on default route of draft-ietf-mif-dhcpv6-route-option-01 (was: UPDATED - IETF81 dhcwg agenda) Thread-Index: AQHMSmp5OYMFwuDBj0+n11WR2t5/DZT8areAgAIbt2A= Date: Tue, 26 Jul 2011 12:23:49 +0000 Message-ID: References: <4E2CC731.40506@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.105] x-tm-as-product-ver: SMEX-10.0.0.4152-6.500.1024-18284.002 x-tm-as-result: No--47.551800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] comment on default route of draft-ietf-mif-dhcpv6-route-option-01 (was: UPDATED - IETF81 dhcwg agenda) 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, 26 Jul 2011 12:23:53 -0000 M. Abrahamsson, =20 See my comments inline. >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part de = Mikael Abrahamsson >Envoy=E9 : lundi 25 juillet 2011 08:03 >=C0 : Alexandru Petrescu >Cc : dhcwg@ietf.org >Objet : Re: [dhcwg] comment on default route of draft-ietf-mif-dhcpv6-rout= e-option-01 (was: UPDATED - IETF81 dhcwg >agenda) > >On Mon, 25 Jul 2011, Alexandru Petrescu wrote: > >> But, were it to have this specific goal of communicating default routes= =20 >> - I believe it could be improved with lifetime and MAC address aspects,= =20 >> and more. > >I would like to include a source address field as well. In some deployment= =20 >scenarios one wants different default gateways depending on what source=20 >address the packet has (think multiple ISPs, multiple on-link networks in= =20 >combination with antispoofing). It would be short sighted to not include=20 >support for this when designing route handout via DHCPv6. Can you clarify how you intend to use the source address field? In one scenario you mentioned multiple ISPs and multiple on-link networks m= eaning that the client is connected to multiple links over one or several i= nterfaces. My question is then how the source address can influence the choice of the = default gateway? I would expect that if the client wants to send a packet, = with one of its addresses, it should be sent through a default gateway of t= he link the source address belongs. >From my point of view I think this field can be useful if there are several= default gateways available on the same link and the client has several add= resses on it. >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From shemant@cisco.com Tue Jul 26 10:33:34 2011 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 8AFDE11E8104 for ; Tue, 26 Jul 2011 10:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6Es7dwL88pg for ; Tue, 26 Jul 2011 10:33:33 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0B53011E80FD for ; Tue, 26 Jul 2011 10:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=8096; q=dns/txt; s=iport; t=1311701613; x=1312911213; h=mime-version:subject:date:message-id:from:to; bh=+QqYOJf/wfkgkh1LsxelLd1anIICqnO2uiv8syd6lMs=; b=llZwZBiyCPJbMv3kmLFOdZx6sxsPwWko466e0r3SMwD3N7sKIivYVaAA hd+6bTP4A7xS+BlciUnPZWxY83cWFBDxa/WrEv4ec7zr6K4L7ke2YxK6D qXsjCcGgNxWAUiZREyWAUPUgws4XKJnkcmOrsKpr32CM8TbYZX2g0jeG4 I=; X-Files: ATT72384192.txt : 130 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8BAMj5Lk6tJV2d/2dsb2JhbAArCwEBAQEDAQEBEQEMEgNEHgEJEQQBAQsGIwEHARIYIwwBAQUEAQUXDAYVgjaVF0SPFneJAKFbgSOeaYVhXwSCT4UIhiGKCotu X-IronPort-AV: E=Sophos;i="4.67,270,1309737600"; d="txt'?scan'208,217";a="6569392" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 26 Jul 2011 17:33:32 +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 p6QHXWJa011007 for ; Tue, 26 Jul 2011 17:33:32 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 12:33:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC4BBA.236D69C6" Date: Tue, 26 Jul 2011 12:33:30 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C302589B66@XMB-RCD-109.cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [v6ops] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc Thread-Index: AcxLuKzKq0shWdzUS/uvVfJ9gcyG8gAAW+rw From: "Hemant Singh (shemant)" To: X-OriginalArrivalTime: 26 Jul 2011 17:33:31.0833 (UTC) FILETIME=[237D8290:01CC4BBA] Subject: [dhcwg] FW: [v6ops] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc 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, 26 Jul 2011 17:33:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4BBA.236D69C6 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC4BBA.236D69C6" ------_=_NextPart_002_01CC4BBA.236D69C6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Tuesday, July 26, 2011 1:23 PM To: Ted Lemon Cc: IPv6 Operations Subject: [v6ops] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc =20 Hi Ted, =20 In the latest version of the document which is =20 http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router-bis/?in clude_text=3D1 =20 Please note this new section which is something we'd like to socialize with the DHC folks. The idea is since DHC tries forever, if a client send the first SOLiCIT with say, two options, such as the IA_NA and the IA_PD options, then if the server replied to the first SOLICIT having served only a IA_NA IA_Address and error for the IA_PD (due to server mis-configuration), then if the client sends a SOLICIT at another time, the client should not just include the IA_PD but send both the options as in the first SOLiCIT. The reason is what if the server has changed provisioning for the IA_NA in the meantime.=20 =20 5.7. Additional DHCPv6 WAN Requirement =20 When the WAN interface sends a DHCPV6 SOLICIT message, the CE router SHOULD request all mandatory information (IA_NA and IA_PD options) in the SOLICIT regardless of whether any partial information was received in response to previous SOLICITs. =20 =20 Thanks, =20 Hemant =20 =20 ------_=_NextPart_002_01CC4BBA.236D69C6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI

From:= v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Hemant Singh (shemant)
Sent: Tuesday, July 26, 2011 1:23 PM
To: Ted Lemon
Cc: IPv6 Operations
Subject: [v6ops] socializing new DHCPV6 req in the IETF IPV6 CE = rtr bis doc

Hi Ted,

In the latest version of the document which = is

http://datatracker.ietf.org/doc/draft-ietf-v6ops-i= pv6-cpe-router-bis/?include_text=3D1

Please note this new section which is something = we’d like to socialize with the DHC folks. The idea is since DHC = tries forever, if a client send the first SOLiCIT with say, two options, such = as the IA_NA and the IA_PD options, then if the server replied to the = first SOLICIT having served only a IA_NA IA_Address and error for the IA_PD = (due to server mis-configuration), then if the client sends a SOLICIT at another = time, the client should not just include the IA_PD but send both the = options as in the first SOLiCIT. The reason is what if the server has = changed provisioning for the IA_NA in the meantime.

5.7. Additional DHCPv6 WAN = Requirement

When the WAN interface sends a = DHCPV6 SOLICIT message, the CE router

SHOULD request all mandatory information (IA_NA and IA_PD options) in

the SOLICIT regardless of = whether any partial information was

received in response to previous SOLICITs.

Thanks,

Hemant

------_=_NextPart_002_01CC4BBA.236D69C6-- ------_=_NextPart_001_01CC4BBA.236D69C6 Content-Type: text/plain; name="ATT72384192.txt" Content-Transfer-Encoding: base64 Content-Description: ATT72384192.txt Content-Disposition: inline; filename="ATT72384192.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1h aWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZvcHMNCg== ------_=_NextPart_001_01CC4BBA.236D69C6-- From Ted.Lemon@nominum.com Tue Jul 26 10:40:46 2011 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 ABA5611E8075 for ; Tue, 26 Jul 2011 10:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJU4TLMTihOu for ; Tue, 26 Jul 2011 10:40:46 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 9A37711E8073 for ; Tue, 26 Jul 2011 10:40:40 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTi78FvA01LsaSUqOXZF/XKxdHaYkrlAo@postini.com; Tue, 26 Jul 2011 10:40: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 37FF91B8199 for ; Tue, 26 Jul 2011 10:40:38 -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 23FB5190059; Tue, 26 Jul 2011 10:40:38 -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.01.0289.001; Tue, 26 Jul 2011 10:40:38 -0700 From: Ted Lemon To: "Hemant Singh (shemant)" Thread-Topic: [dhcwg] [v6ops] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc Thread-Index: AQHMS7shSpTnL0SzeU+o7vUEpNievw== Date: Tue, 26 Jul 2011 17:40:37 +0000 Message-ID: References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589B66@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C302589B66@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.83.76] Content-Type: multipart/alternative; boundary="_000_E827C7B871644D8D8B5988168D618F76nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] [v6ops] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc 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, 26 Jul 2011 17:40:46 -0000 --_000_E827C7B871644D8D8B5988168D618F76nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jul 26, 2011, at 1:33 PM, Hemant Singh (shemant) wrote: Please note this new section which is something we=92d like to socialize wi= th the DHC folks. The idea is since DHC tries forever, if a client send t= he first SOLiCIT with say, two options, such as the IA_NA and the IA_PD opt= ions, then if the server replied to the first SOLICIT having served only a= IA_NA IA_Address and error for the IA_PD (due to server mis-configuration)= , then if the client sends a SOLICIT at another time, the client should not= just include the IA_PD but send both the options as in the first SOLiCIT.= The reason is what if the server has changed provisioning for the IA_NA = in the meantime. Why are Reconfigure and regular old lease timeout not sufficient in this ca= se? --_000_E827C7B871644D8D8B5988168D618F76nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

On Jul 26, 2011, at 1:33 PM, Hemant Singh (shemant) wrote:

Please note this new section which is something we=92d like to socialize wi= th the DHC folks. The idea is since DHC tries forever, if a cli= ent send the first SOLiCIT with say, two options, such as the IA_NA and the= IA_PD options, then if the server replied to the first SOLICIT having served only a IA_NA IA_Address and error for t= he IA_PD (due to server mis-configuration), then if the client sends a SOLI= CIT at another time, the client should not just include the IA_PD but = ;send both the options as in the first SOLiCIT. The reason is what if the server has changed provisio= ning for the IA_NA in the meantime.

Why are Reconfigure and regular old lease timeout not sufficient in this ca= se?

--_000_E827C7B871644D8D8B5988168D618F76nominumcom_-- From swmike@swm.pp.se Tue Jul 26 11:53:41 2011 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 C1BE111E812A for ; Tue, 26 Jul 2011 11:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNm-VKT2Yq5v for ; Tue, 26 Jul 2011 11:53:41 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 1C04711E808C for ; Tue, 26 Jul 2011 11:53:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 395DA9C; Tue, 26 Jul 2011 20:53:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3711E9A; Tue, 26 Jul 2011 20:53:39 +0200 (CEST) Date: Tue, 26 Jul 2011 20:53:39 +0200 (CEST) From: Mikael Abrahamsson To: MOUTON Maximilien In-Reply-To: Message-ID: References: <4E2CC731.40506@gmail.com>

User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dhcwg@ietf.org" , Alexandru Petrescu Subject: Re: [dhcwg] comment on default route of draft-ietf-mif-dhcpv6-route-option-01 (was: UPDATED - IETF81 dhcwg agenda) 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, 26 Jul 2011 18:53:41 -0000 On Tue, 26 Jul 2011, MOUTON Maximilien wrote: >> I would like to include a source address field as well. In some deployment >> scenarios one wants different default gateways depending on what source >> address the packet has (think multiple ISPs, multiple on-link networks in >> combination with antispoofing). It would be short sighted to not include >> support for this when designing route handout via DHCPv6. > > Can you clarify how you intend to use the source address field? In one > scenario you mentioned multiple ISPs and multiple on-link networks > meaning that the client is connected to multiple links over one or > several interfaces. My question is then how the source address can > influence the choice of the default gateway? I would expect that if the > client wants to send a packet, with one of its addresses, it should be > sent through a default gateway of the link the source address belongs. On NIC1 there is /64 for ISP1 and another /64 from ISP2. I want packets sourced from IP addresses from ISP1 to go out thru the CPE for ISP1, and packet sourced from ISP2 addresses to go thru ISP2 CPE. And what you describe today typically doesn't happen, the host will choose a single best default gw and send all packets out thru it (afaik), regardless of what IP address is used as source for the packet. -- Mikael Abrahamsson email: swmike@swm.pp.se From shemant@cisco.com Tue Jul 26 13:39:00 2011 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 D27F311E8097; Tue, 26 Jul 2011 13:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9jeavjJLfjV; Tue, 26 Jul 2011 13:39:00 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFBF11E80AF; Tue, 26 Jul 2011 13:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1320; q=dns/txt; s=iport; t=1311712740; x=1312922340; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=0WZFizF229JSrn5GU0sgfnQvLC3ACGyMyQzv1/tCuGw=; b=dbMcDctHoKMJ1lq7jPNCd9NgZn3WYg9M+tkg37MciY9MyZHfI7JUso02 n2YPgaHMaEM2I1PqQwZ1q3OPQ9j3THhmTzVVJv/UGV700vl1xAc/3lAkK UJi9cP1zsShX7y+pMo/5/no07OMGHXjIUrCyVX0K9OIXLEpi0d/dsrEZ4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYAABIlL06tJV2c/2dsb2JhbAAqCwEBAQEDFAEhChAqCwwFAgEJEQQBAQsGIwEGARM7DggBAQUXDBuXTo9cd6wykF6Nd4VhXwSHV5Ari24 X-IronPort-AV: E=Sophos;i="4.67,271,1309737600"; d="scan'208";a="6639470" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 26 Jul 2011 20:39:00 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6QKcxm1027685; Tue, 26 Jul 2011 20:38:59 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 15:38:59 -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: Tue, 26 Jul 2011 15:38:57 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C302589C62@XMB-RCD-109.cisco.com> In-Reply-To: <3946F646-0B16-49A4-A146-A93CFF26C21F@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc Thread-Index: AcxLuKzKq0shWdzUS/uvVfJ9gcyG8gAO13iAAAiR8aA= References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589B59@XMB-RCD-109.cisco.com> <3946F646-0B16-49A4-A146-A93CFF26C21F@nominum.com> From: "Hemant Singh (shemant)" To: "Ted Lemon" X-OriginalArrivalTime: 26 Jul 2011 20:38:59.0049 (UTC) FILETIME=[0BD3ED90:01CC4BD4] Cc: dhcwg@ietf.org, IPv6 Operations Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc 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, 26 Jul 2011 20:39:00 -0000 -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Tuesday, July 26, 2011 1:28 PM To: Hemant Singh (shemant) Cc: IPv6 Operations Subject: Re: socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc >You should raise this on the DHCP mailing list. =20 Done - thanks. >The questions I'd want to see answered are why just waiting for the IA_NA to time out doesn't work, and why Reconfigure doesn't work. The IPv6 CE router DHC6 client sent its first SOLICIT with IA_NA and IA_PD options and the server replied back with a valid IA_NA but failure for the IA_PD (due to a mis-configured server for IA_PD). So if the client waits for the IA_NA to timeout before the client sends any subsequent SOLICIT for both IA_NA and IA_PD. The IA_NA IA_Address Valid Lifetime is one week and thus the home LAN has no PD assigned for a week. Note also that if a server is mis-configured for IA_PD, when the mis-configuration is fixed, the IA_NA is may change as well. Thus it makes sense to send both IA_NA and the IA_PD options is subsequent SOLICITs. Agreed, when the IA_NA changes a Reconfigure can be sent from the server to the client. But there is no automated means to detect the mis-configuration and when does the server send the Reconfigure? =20 Hemant=20 From akostur@incognito.com Tue Jul 26 13:54:57 2011 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 69B2221F8A56; Tue, 26 Jul 2011 13:54:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2BraZ2jAzyH; Tue, 26 Jul 2011 13:54:56 -0700 (PDT) Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with SMTP id 163A021F8A4B; Tue, 26 Jul 2011 13:54:55 -0700 (PDT) Received: from mail-gw0-f41.google.com ([74.125.83.41]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKTi8pnsQgEOl8ORjJv5mMAULPif3hjAcv@postini.com; Tue, 26 Jul 2011 13:54:56 PDT Received: by mail-gw0-f41.google.com with SMTP id a12so772092gwa.14 for ; Tue, 26 Jul 2011 13:54:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.173.41 with SMTP id u29mr8065626yhl.463.1311713694657; Tue, 26 Jul 2011 13:54:54 -0700 (PDT) Received: by 10.236.170.34 with HTTP; Tue, 26 Jul 2011 13:54:54 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C302589C62@XMB-RCD-109.cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589B59@XMB-RCD-109.cisco.com> <3946F646-0B16-49A4-A146-A93CFF26C21F@nominum.com> <5B6B2B64C9FE2A489045EEEADDAFF2C302589C62@XMB-RCD-109.cisco.com> Date: Tue, 26 Jul 2011 13:54:54 -0700 Message-ID: From: Andre Kostur To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=20cf305e2567d12cbb04a8ff2477 Cc: dhcwg@ietf.org, IPv6 Operations , Ted Lemon Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc 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, 26 Jul 2011 20:54:57 -0000 --20cf305e2567d12cbb04a8ff2477 Content-Type: text/plain; charset=ISO-8859-1 Why would the server necessarily wait for the IA_NA to expire before talking about the IA_PD again? Those two should be on separate timers. The preferred/valid/T1/T2 timers are all per IA, and the IA_NA is separate from the IA_PD. On Tue, Jul 26, 2011 at 13:38, Hemant Singh (shemant) wrote: > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Tuesday, July 26, 2011 1:28 PM > To: Hemant Singh (shemant) > Cc: IPv6 Operations > Subject: Re: socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc > > >You should raise this on the DHCP mailing list. > > Done - thanks. > > >The questions I'd want to see answered are why just waiting for the > IA_NA to time out doesn't work, and why Reconfigure doesn't work. > > The IPv6 CE router DHC6 client sent its first SOLICIT with IA_NA and > IA_PD options and the server replied back with a valid IA_NA but failure > for the IA_PD (due to a mis-configured server for IA_PD). So if the > client waits for the IA_NA to timeout before the client sends any > subsequent SOLICIT for both IA_NA and IA_PD. The IA_NA IA_Address Valid > Lifetime is one week and thus the home LAN has no PD assigned for a > week. Note also that if a server is mis-configured for IA_PD, when the > mis-configuration is fixed, the IA_NA is may change as well. Thus it > makes sense to send both IA_NA and the IA_PD options is subsequent > SOLICITs. Agreed, when the IA_NA changes a Reconfigure can be sent from > the server to the client. But there is no automated means to detect the > mis-configuration and when does the server send the Reconfigure? > > Hemant > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > -- Andre Kostur Senior Software Design Engineer P: 604-678-2864 SIP: 864@incognito.com --20cf305e2567d12cbb04a8ff2477 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Why would the server necessarily wait for the IA_NA to exp= ire before talking about the IA_PD again? =A0Those two should be on separat= e timers. =A0The preferred/valid/T1/T2 timers are all per IA, and the IA_NA= is separate from the IA_PD.

On Tue, Jul 26, 2011 at 13:38, Hemant Singh = (shemant) <sheman= t@cisco.com> wrote:

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@= nominum.com]
Sent: Tuesday, July 26, 2011 1:28 PM
To: Hemant Singh (shemant)
Cc: IPv6 Operations
Subject: Re: socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc

>You should raise this on the DHCP mailing list.

Done - thanks.

>The questions I'd want to see answered are why just waiting for the=
IA_NA to time out doesn't work, and why Reconfigure doesn't work.
The IPv6 CE router DHC6 client sent its first SOLICIT with IA_NA and
IA_PD options and the server replied back with a valid IA_NA but failure for the IA_PD (due to a mis-configured server for IA_PD). So if the
client waits for the IA_NA to timeout before the client sends any
subsequent SOLICIT for both IA_NA and IA_PD. =A0The IA_NA IA_Address Valid<= br> Lifetime is one week and thus the home LAN has no PD assigned for a
week. =A0Note also that if a server is mis-configured for IA_PD, when the mis-configuration is fixed, the IA_NA is may change as well. Thus it
makes sense to send both IA_NA and the IA_PD options is subsequent
SOLICITs. =A0Agreed, when the IA_NA changes a Reconfigure can be sent from<= br> the server to the client. =A0But there is no automated means to detect the<= br> mis-configuration and when does the server send the Reconfigure?

Hemant

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

Andre Kostur
Senior Softwa= re Design Engineer

P: 604-678-2864
SIP:=A0864@incognito.com

--20cf305e2567d12cbb04a8ff2477-- From tomasz.mrugalski@gmail.com Tue Jul 26 21:20:08 2011 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 EDFF411E8074; Tue, 26 Jul 2011 21:20:08 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kP8MtZdGQzVz; Tue, 26 Jul 2011 21:20:08 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C218311E8070; Tue, 26 Jul 2011 21:20:07 -0700 (PDT) Received: by qwc23 with SMTP id 23so804029qwc.31 for ; Tue, 26 Jul 2011 21:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=L13MHbiW/o1aTWvRAlHr1h0xokebYzFQ9zUnLixyio0=; b=q3GsiXEF66LnIVjKPkc876Y/Q5D50Oa7cF3a7w0q9+l0K3jx/Jm3fZhv69n1DbdmNS kPVV+dY9gkpUu+A3tPbkMcJOgVSjFS8ZSnotxUgwtPxgZ+M3okdKEdaz6dswlvxp3egA H2B+IHpD7stY6FMd4OD7+6YZboeHuiqTjUc9s= Received: by 10.224.9.70 with SMTP id k6mr5172179qak.230.1311740406964; Tue, 26 Jul 2011 21:20:06 -0700 (PDT) Received: from MacBook-Tomasz-Mrugalski.local ([70.25.120.2]) by mx.google.com with ESMTPS id cd4sm586869qab.4.2011.07.26.21.20.02 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 21:20:04 -0700 (PDT) Message-ID: <4E2F91F0.7020002@gmail.com> Date: Wed, 27 Jul 2011 00:20:00 -0400 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: DHC WG , mif@ietf.org References: <20110727035812.29266.50610.idtracker@ietfa.amsl.com> In-Reply-To: <20110727035812.29266.50610.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] [mif] I-D Action: draft-ietf-mif-dhcpv6-route-option-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, 27 Jul 2011 04:20:09 -0000 On 11-07-26 23:58, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple Interfaces Working Group of the IETF. > > > Title : DHCPv6 Route Options > Author(s) : Wojciech Dec > Tomasz Mrugalski > Tao Sun > Behcet Sarikaya > Filename : draft-ietf-mif-dhcpv6-route-option-02.txt > Pages : 12 > Date : 2011-07-26 > > This document describes DHCPv6 Route Options for provisioning IPv6 > routes on DHCPv6 client nodes. This is expected to improve the > ability of an operator to configure and influence a nodes' ability to > pick an appropriate route to a destination when this node is multi- > homed and where other means of route configuration may be > impractical. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mif-dhcpv6-route-option-02.txt Dear groups, New version of the draft-ietf-mif-dhcpv6-route-option draft has been uploaded. The only significant change is addition of a verification mechanism before client is allowed to use configured routes. NUD should be used to detect if provided routers are indeed available. Lack of such mechanism was pointed out by Joel Halpern from RtgDir. Thank you for the review and for pointing that out. Minor changes include: - clarification that 2 NEXT_HOP options must be unique. - change of affiliation - name change (DHCPv6 options, not option) This draft is going to be presented in DHC. Possibly short update in MIF may be useful as well. Regards, Tomek From shemant@cisco.com Wed Jul 27 06:05:27 2011 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 D7E1B21F852E; Wed, 27 Jul 2011 06:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgQ8OkhVEjRs; Wed, 27 Jul 2011 06:05:26 -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 61CF921F850E; Wed, 27 Jul 2011 06:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=4848; q=dns/txt; s=iport; t=1311771926; x=1312981526; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=zP20pfgAQuZJfS6rJFcAfbHc53O7S5yXAXqRvZBf4wk=; b=FAp2kajnuYNKrR2y99wqSdOD/9UZ2iZ7P/fXIWklSKOA26i79FT7qChm +qQp3vfVddSnfTEyM8nNQpxje0kvRiEPLB4c5hxjipPvUsajTgUIoNLLZ P0qems1Bin/YtWbQUcaxSZWNvmVZsLRgqhUHcK9yWei6RAVPYwzQLAyNd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAGUMME6tJXG9/2dsb2JhbAA1AQEBAQMUAQwSA08RAgEJDgMEAQELBiMBBgETOw4IAQEFFwwbgjaVGo9Hd6sDnmCFYV8Eh1eQLotw X-IronPort-AV: E=Sophos;i="4.67,276,1309737600"; d="scan'208,217";a="6952449" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 27 Jul 2011 13:05:25 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6RD5PDv028793; Wed, 27 Jul 2011 13:05:25 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jul 2011 08:05:25 -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_01CC4C5D.D9481194" Date: Wed, 27 Jul 2011 08:04:01 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C302589DA4@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc Thread-Index: AcxL1ke6QeSpMOOVQ5yJeHkwEIDwegAhUNwg References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589B59@XMB-RCD-109.cisco.com><3946F646-0B16-49A4-A146-A93CFF26C21F@nominum.com><5B6B2B64C9FE2A489045EEEADDAFF2C302589C62@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Andre Kostur" X-OriginalArrivalTime: 27 Jul 2011 13:05:25.0804 (UTC) FILETIME=[D9E206C0:01CC4C5D] Cc: dhcwg@ietf.org, IPv6 Operations Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc 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, 27 Jul 2011 13:05:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4C5D.D9481194 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: Andre Kostur [mailto:akostur@incognito.com]=20 Sent: Tuesday, July 26, 2011 4:55 PM To: Hemant Singh (shemant) Cc: Ted Lemon; dhcwg@ietf.org; IPv6 Operations Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc =20 >Why would the server necessarily wait for the IA_NA to expire before talking about the IA_PD again? Those two should be on separate timers. The preferred/valid/T1/T2 timers are all per IA, and the IA_NA is separate from the IA_PD. I am discussing the client since Ted asked why not wait for the IA_NA to timeout. If a CPE router has failed IA_PD acquisition, the IA_NA is not much use for the CPE and then CPE should try DHCPv6 forever to get both an IA_NA and IA_PD. The CPE router DHCv6 client hasn't even completed DHCPv6 to consider a client renewal/rebind or the server to send a Reconfigure. =20 Hemant ------_=_NextPart_001_01CC4C5D.D9481194 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From:= Andre = Kostur [mailto:akostur@incognito.com]
Sent: Tuesday, July 26, 2011 4:55 PM
To: Hemant Singh (shemant)
Cc: Ted Lemon; dhcwg@ietf.org; IPv6 Operations
Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 = CE rtr bis doc

>Why would the server necessarily wait for the IA_NA to expire before talking = about the IA_PD again? Those two should be on separate timers. The preferred/valid/T1/T2 timers are all per IA, and the IA_NA is separate = from the IA_PD.

I am discussing the = client since Ted asked why not wait for the IA_NA to timeout. If a CPE = router has failed IA_PD acquisition, the IA_NA is not much use for the CPE and = then CPE should try DHCPv6 forever to get both an IA_NA and IA_PD. The = CPE router DHCv6 client hasn’t even completed DHCPv6 to consider a = client renewal/rebind or the server to send a = Reconfigure.

Hemant

------_=_NextPart_001_01CC4C5D.D9481194-- From akostur@incognito.com Wed Jul 27 08:32:16 2011 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 5E52A21F8880; Wed, 27 Jul 2011 08:32:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRXTBjlcn996; Wed, 27 Jul 2011 08:32:15 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with SMTP id A385E21F84F2; Wed, 27 Jul 2011 08:32:14 -0700 (PDT) Received: from mail-yi0-f51.google.com ([209.85.218.51]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKTjAvff/bCyszj+ywGZzcGYK+UGgqXVKR@postini.com; Wed, 27 Jul 2011 08:32:15 PDT Received: by yib2 with SMTP id 2so1404754yib.24 for ; Wed, 27 Jul 2011 08:32:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.145.66 with SMTP id o42mr273755yhj.61.1311780733042; Wed, 27 Jul 2011 08:32:13 -0700 (PDT) Received: by 10.236.170.34 with HTTP; Wed, 27 Jul 2011 08:32:13 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C302589DA4@XMB-RCD-109.cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589B59@XMB-RCD-109.cisco.com> <3946F646-0B16-49A4-A146-A93CFF26C21F@nominum.com> <5B6B2B64C9FE2A489045EEEADDAFF2C302589C62@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C302589DA4@XMB-RCD-109.cisco.com> Date: Wed, 27 Jul 2011 08:32:13 -0700 Message-ID: From: Andre Kostur To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=20cf303b3be39dbf8604a90ec05b Cc: dhcwg@ietf.org, IPv6 Operations Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc 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, 27 Jul 2011 15:32:16 -0000 --20cf303b3be39dbf8604a90ec05b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable (Whups... I meant "Why would the _client_ necessarily wait....") Again, why shouldn't the CPE wait the natural lifespan of the IA_NA before talking about it again? The CPE has lots of uses for the IA_NA. Namely it's own management, SNMP monitoring, source IP for syslog notifications, whatever. Otherwise why does it want an IA_NA at all? The client device shouldn't be tying the IA_NA together with the IA_PD. They are separate transactions that may travel together in a single DHCP packet. Not to put words in Ted's mouth, but I believe he was asking the same question. Why should the device abandon the perfectly good IA_NA that it has (or could have) already obtained just because the IA_PD was wrong. If the IA_NA stuff was changed on the DHCP server, the DHCP server knows who already has a lease which may be affected by whatever configuration change happened and either the admin can wait for the IA_NA to timeout (Renew, Rebind, or expiry), or explicitly send a Reconfigure to the device. Prevents this errant device from endlessly pounding the DHCP server about an IA_NA that it has already given the device. PS: I slightly misspoke about the preferred/valid times being per IA, those are per-iaddr, or prefix). On Wed, Jul 27, 2011 at 06:04, Hemant Singh (shemant) wr= ote: > ** ** > > *From:* Andre Kostur [mailto:akostur@incognito.com] > *Sent:* Tuesday, July 26, 2011 4:55 PM > *To:* Hemant Singh (shemant) > *Cc:* Ted Lemon; dhcwg@ietf.org; IPv6 Operations > *Subject:* Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr > bis doc**** > > ** ** > > >Why would the server necessarily wait for the IA_NA to expire before > talking about the IA_PD again? Those two should be on separate timers. = The > preferred/valid/T1/T2 timers are all per IA, and the IA_NA is separate fr= om > the IA_PD.**** > > I am discussing the client since Ted asked why not wait for the IA_NA to > timeout. If a CPE router has failed IA_PD acquisition, the IA_NA is not > much use for the CPE and then CPE should try DHCPv6 forever to get both a= n > IA_NA and IA_PD. The CPE router DHCv6 client hasn=92t even completed DHC= Pv6 > to consider a client renewal/rebind or the server to send a Reconfigure.*= * > ** > > ** ** > > Hemant**** > --=20 Andre Kostur Senior Software Design Engineer P: 604-678-2864 SIP: 864@incognito.com --20cf303b3be39dbf8604a90ec05b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

(Whups... I meant "Why would the _client_ necess= arily wait....")

Again, why shouldn't the CPE = wait the natural lifespan of the IA_NA before talking about it again? =A0Th= e CPE has lots of uses for the IA_NA. =A0Namely it's own management, SN= MP monitoring, source IP for syslog notifications, whatever. =A0Otherwise w= hy does it want an IA_NA at all? =A0The client device shouldn't be tyin= g the IA_NA together with the IA_PD. =A0They are separate transactions that= may travel together in a single DHCP packet.

Not to put words in Ted's mouth, but I believe he was as= king the same question. =A0Why should the device abandon the perfectly good= IA_NA that it has (or could have) already obtained just because the IA_PD = was wrong. =A0If the IA_NA stuff was changed on the DHCP server, the DHCP s= erver knows who already has a lease which may be affected by whatever confi= guration change happened and either the admin can wait for the IA_NA to tim= eout (Renew, Rebind, or expiry), or explicitly send a Reconfigure to the de= vice. =A0Prevents this errant device from endlessly pounding the DHCP serve= r about an IA_NA that it has already given the device.

PS: I slightly misspoke about the prefer= red/valid times being per IA, those are per-iaddr, or prefix).

On Wed, Jul 27, 2011 at 06:04, Hemant Sin= gh (shemant) <she= mant@cisco.com> wrote:

=A0

From:= Andre Kostur [mailto:akostur@= incognito.com]
Sent: Tuesday, July 26, 2011 4:55 PM
To: Hemant Singh (shemant)
Cc: Ted Lemon; d= hcwg@ietf.org; IPv6 Operations
Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE = rtr bis doc

=A0

>Why would the server necessarily wait for the IA_NA to expire before talking ab= out the IA_PD again? =A0Those two should be on separate timers. =A0The preferred/valid/T1/T2 timers are all per IA, and the IA_NA is separate from= the IA_PD.

I am discussing the cl= ient since Ted asked why not wait for the IA_NA to timeout.=A0 =A0If a CPE router has failed IA_PD acquisition, the IA_NA is not much use for the CPE and the= n CPE should try DHCPv6 forever to get both an IA_NA and IA_PD. =A0The CPE router DHCv6 client hasn=92t even completed DHCPv6 to consider a client renewal/rebind or the server to send a Reconfigure.
=A0

Hemant

Andre Kostur
Senior Softwa= re Design Engineer

P: 604-678-2864
SIP:=A0864@incognito.com

--20cf303b3be39dbf8604a90ec05b-- From Ted.Lemon@nominum.com Wed Jul 27 10:50:15 2011 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 6987421F8AE1 for ; Wed, 27 Jul 2011 10:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zop7OOHMitey for ; Wed, 27 Jul 2011 10:50:14 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id A44AA21F8AF3 for ; Wed, 27 Jul 2011 10:50:14 -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 DSNKTjBP1cME8lZIb2O1wfNfeRbpQ+fww+1p@postini.com; Wed, 27 Jul 2011 10:50:14 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 949221B81F6 for ; Wed, 27 Jul 2011 10:50:13 -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 7DE5C190058 for ; Wed, 27 Jul 2011 10:50: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.01.0289.001; Wed, 27 Jul 2011 10:50:12 -0700 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: IETF 81 DHC presenters, please read this. Thread-Index: AQHMTIWh5mV5gfQL+0mOAQD5BIep7g== Date: Wed, 27 Jul 2011 17:50:11 +0000 Message-ID: <3D403C66-5222-4405-AE49-629C92BBBEA5@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.83.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <744F211172DAA04FA1A3C4CF6510FAAC@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] IETF 81 DHC presenters, please read this. 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, 27 Jul 2011 17:50:15 -0000 Please check your slide presentation to see if each slide is numbered. If= not, please send us new versions of your slides with page numbering turned= on. Slides should be encoded as PDF. Please do not use any point sizes= smaller than 18 points. Thanks! (I'm sorry for sending this so late, but someone mentioned this on the IETF= mailing list, and I think it's an important point, which we unfortunately = forgot to recommend earlier). From john_brzozowski@cable.comcast.com Wed Jul 27 11:02:30 2011 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 9D90911E8116 for ; Wed, 27 Jul 2011 11:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=-0.673, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJrtQjfhSpPc for ; Wed, 27 Jul 2011 11:02:29 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id D18D011E8113 for ; Wed, 27 Jul 2011 11:02:28 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.46402707; Wed, 27 Jul 2011 12:07:09 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Wed, 27 Jul 2011 14:02:25 -0400 From: "Brzozowski, John" To: dhc WG Thread-Topic: IETF81 dhcwg - volunteers for minutes and jabber Thread-Index: AQHMTIdW/lGbLcdwWECmnN+VSCmUBw== Date: Wed, 27 Jul 2011 18:02:24 +0000 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.12.0.110505 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] IETF81 dhcwg - volunteers for minutes and jabber 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, 27 Jul 2011 18:02:30 -0000 Any volunteers please contact the chairs. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 7/23/11 9:28 PM, "John Jason Brzozowski" wrote: >The dhcwg chair would like volunteers to take meeting minutes and for >jabber scribing during our upcoming working group meeting in Quebec City. > >Meeting details can be found here: > >http://www.ietf.org/proceedings/81/agenda/dhc.html > >Thanks, > >Ted and John > From john_brzozowski@cable.comcast.com Wed Jul 27 11:04:08 2011 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 0A00E11E8114 for ; Wed, 27 Jul 2011 11:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.463 X-Spam-Level: X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgVE2lktzVpx for ; Wed, 27 Jul 2011 11:04:07 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 49DA011E8107 for ; Wed, 27 Jul 2011 11:04:06 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.135342509; Wed, 27 Jul 2011 14:04:01 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Wed, 27 Jul 2011 14:03:48 -0400 From: "Brzozowski, John" To: dhc WG Thread-Topic: Updated agenda Thread-Index: AQHMTIeIcG97bTr/SkWWdoae8SsXbg== Date: Wed, 27 Jul 2011 18:03:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [130.129.21.46] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] Updated agenda 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, 27 Jul 2011 18:04:08 -0000 FYI http://www.ietf.org/proceedings/81/agenda/dhc.html Thank you, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From Maximilien.MOUTON@cea.fr Wed Jul 27 11:06:41 2011 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 B1F0121F8B09 for ; Wed, 27 Jul 2011 11:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHqo+4pUpHij for ; Wed, 27 Jul 2011 11:06:41 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id EDDB521F8AFA for ; Wed, 27 Jul 2011 11:06:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p6RI6cA7025565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jul 2011 20:06:38 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p6RI6cCX007860; Wed, 27 Jul 2011 20:06:38 +0200 (envelope-from Maximilien.MOUTON@cea.fr) Received: from EXCAH-A0.intra.cea.fr (excah-a0.intra.cea.fr [132.166.88.74]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p6RI6cmb030139; Wed, 27 Jul 2011 20:06:38 +0200 Received: from EXDAG0-A3.intra.cea.fr ([fe80::25a1:c396:2106:4c5b]) by EXCAH-A0.intra.cea.fr ([fe80::446e:fe1a:2892:9de1%11]) with mapi id 14.01.0270.001; Wed, 27 Jul 2011 20:06:38 +0200 From: MOUTON Maximilien To: Mikael Abrahamsson Thread-Topic: [dhcwg] comment on default route of draft-ietf-mif-dhcpv6-route-option-01 (was: UPDATED - IETF81 dhcwg agenda) Thread-Index: AQHMSmp5OYMFwuDBj0+n11WR2t5/DZT8areAgAIbt2CAAE3fgIABpZRg Date: Wed, 27 Jul 2011 18:06:37 +0000 Message-ID: References: <4E2CC731.40506@gmail.com>

In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.105] x-tm-as-product-ver: SMEX-10.0.0.4152-6.500.1024-18286.007 x-tm-as-result: No--43.805600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Alexandru Petrescu Subject: Re: [dhcwg] comment on default route of draft-ietf-mif-dhcpv6-route-option-01 (was: UPDATED - IETF81 dhcwg agenda) 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, 27 Jul 2011 18:06:41 -0000 >-----Message d'origine----- >De : Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 >Envoy=E9 : mardi 26 juillet 2011 20:54 >=C0 : MOUTON Maximilien >Cc : Alexandru Petrescu; dhcwg@ietf.org >Objet : RE: [dhcwg] comment on default route of draft-ietf-mif-dhcpv6-rout= e-option-01 (was: UPDATED - IETF81 dhcwg >agenda) >On Tue, 26 Jul 2011, MOUTON Maximilien wrote: >>> I would like to include a source address field as well. In some deploym= ent >>> scenarios one wants different default gateways depending on what source >>> address the packet has (think multiple ISPs, multiple on-link networks = in >>> combination with antispoofing). It would be short sighted to not includ= e >>> support for this when designing route handout via DHCPv6. >> >> Can you clarify how you intend to use the source address field? In one=20 >> scenario you mentioned multiple ISPs and multiple on-link networks=20 >> meaning that the client is connected to multiple links over one or=20 >> several interfaces. My question is then how the source address can=20 >>influence the choice of the default gateway? I would expect that if the=20 >> client wants to send a packet, with one of its addresses, it should be=20 >> sent through a default gateway of the link the source address belongs. > >On NIC1 there is /64 for ISP1 and another /64 from ISP2. I want packets=20 >sourced from IP addresses from ISP1 to go out thru the CPE for ISP1, and=20 >packet sourced from ISP2 addresses to go thru ISP2 CPE. > I agree with you. In this scenario the client needs two default routers; ea= ch one wants to receive packets with source address in its prefix. Thus a s= ource address field is justified in this case. But in your example the content of source address field is the client addre= ss the client already knows. Isn't it? My question is then is an address field really necessary?=20 In the present scenario you could simply use a bit equals to 0 if the defau= lt router accepts all source addresses and equals to 1 if it accepts only s= ource addresses from its prefix. Maximilien >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Wed Jul 27 11:12:29 2011 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 2856C21F8BD4 for ; Wed, 27 Jul 2011 11:12:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZpHUTM8pqbG for ; Wed, 27 Jul 2011 11:12:28 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 4228F21F84C5 for ; Wed, 27 Jul 2011 11:12:28 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 80A579C; Wed, 27 Jul 2011 20:12:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7D4DD9A; Wed, 27 Jul 2011 20:12:27 +0200 (CEST) Date: Wed, 27 Jul 2011 20:12:27 +0200 (CEST) From: Mikael Abrahamsson To: MOUTON Maximilien In-Reply-To: Message-ID: References: <4E2CC731.40506@gmail.com>

User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dhcwg@ietf.org" , Alexandru Petrescu Subject: Re: [dhcwg] comment on default route of draft-ietf-mif-dhcpv6-route-option-01 (was: UPDATED - IETF81 dhcwg agenda) 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, 27 Jul 2011 18:12:29 -0000 On Wed, 27 Jul 2011, MOUTON Maximilien wrote: > But in your example the content of source address field is the client > address the client already knows. Isn't it? Yes. > My question is then is an address field really necessary? I'm not sure. > In the present scenario you could simply use a bit equals to 0 if the > default router accepts all source addresses and equals to 1 if it > accepts only source addresses from its prefix. How does the client know what prefix sourced it should send where? What if the DHCPv6 server is not the same unit as the default router, or if the default gw for a certain prefix consists of two routers running VRRP? What if you have a DHCPv6-PD structure so a ISP CPE actually handles a range of subnets? Deducing this information from other information might work in some scenarios, but I doubt it'll work in all. -- Mikael Abrahamsson email: swmike@swm.pp.se From shemant@cisco.com Wed Jul 27 12:31:59 2011 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 E971611E80AD; Wed, 27 Jul 2011 12:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM8xDdEWAUwn; Wed, 27 Jul 2011 12:31:58 -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 8B9695E8028; Wed, 27 Jul 2011 12:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=10825; q=dns/txt; s=iport; t=1311795118; x=1313004718; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=uKuBGbSONoyAnrlZYagnDMNW1iXALvi9JIGCy5nAY9g=; b=NqUv0TFRNrHn2R77RhCW3dqLLq4OhwU3en0QZzHbsUaL9mPGyuwd1Tt3 S93JwzIRHD0eogULePaFm62IjirYctEcPCoboZfilPwawoTqmj5kRlAS3 YNpvBya+vcyCY8oGAbXNU9K+6KfBwI2riVSya43QLo7JJC9QDKcH+II+l 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAHBmME6tJV2a/2dsb2JhbAAqCwEBAQEDFAEMEgNPEQIBCQ4DBAEBCwYjAQYBEzsOCAEBBRcMG4I2lSaPSHerf55thWFfBIdXkC6LcA X-IronPort-AV: E=Sophos;i="4.67,278,1309737600"; d="scan'208,217";a="7112421" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 27 Jul 2011 19:31:55 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6RJVthb031820; Wed, 27 Jul 2011 19:31:55 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jul 2011 14:31:55 -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_01CC4C93.D7A8C21C" Date: Wed, 27 Jul 2011 14:31:51 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30258A028@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc Thread-Index: AcxMclwnKq0M3m5GT5ioMV5CXtVTTAAH06Sg References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589B59@XMB-RCD-109.cisco.com><3946F646-0B16-49A4-A146-A93CFF26C21F@nominum.com><5B6B2B64C9FE2A489045EEEADDAFF2C302589C62@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C302589DA4@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Andre Kostur" X-OriginalArrivalTime: 27 Jul 2011 19:31:55.0257 (UTC) FILETIME=[D7DFBE90:01CC4C93] Cc: dhcwg@ietf.org, IPv6 Operations Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc 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, 27 Jul 2011 19:32:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4C93.D7A8C21C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: Andre Kostur [mailto:akostur@incognito.com]=20 Sent: Wednesday, July 27, 2011 11:32 AM To: Hemant Singh (shemant) Cc: dhcwg@ietf.org; IPv6 Operations Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc =20 >The CPE has lots of uses for the IA_NA. Namely it's own management, SNMP monitoring, source IP for syslog notifications, whatever.=20 =20 The CPE rtr document supports both a managed CPE and a unmanaged CPE. There is no SNMP in the unmanaged case, nor any syslog. I don't understand "own management". Without the IA_PD no device in the home will be able to obtain an IPv6 address that is globally routable via the SP network. Thus one broadband deployment in the cable one has already specified a CPE rtr inside a cable modem deems IP address acquisition as failed unless both of the IA_NA and IA_PD are obtained from the DHCPv6 server.=20 =20 >Otherwise why does it want an IA_NA at all? The client device shouldn't be tying the IA_NA together with the IA_PD. They are separate transactions that may tr>avel together in a single DHCP packet. =20 The CPE rtr document supports an unnumbered WAN or a numbered WAN when the WAN has an IA_NA assigned. There are several uses for the IA_NA that have been discussed during the past four years in the IETF. Will get to those later. =20 =20 Not to put words in Ted's mouth, but I believe he was asking the same question. Why should the device abandon the perfectly good IA_NA that it has (or could have) already obtained just because the IA_PD was wrong. =20 =20 The IA_PD was responded to by a failure error code - it wasn't a wrong PD. Thus the CPE router resets and starts DHCPv6 again. So why should the CPE rtr not send both options in the new SOLICIT? =20 If the IA_NA stuff was changed on the DHCP server, the DHCP server knows who already has a lease which may be affected by whatever configuration change happened and either the admin can wait for the IA_NA to timeout (Renew, Rebind, or expiry), or explicitly send a Reconfigure to the device. =20 =20 Operator intervention is not acceptable in a SP broadband network and also the intervention can be delayed. I have already spoken to this fact.=20 =20 Prevents this errant device from endlessly pounding the DHCP server about an IA_NA that it has already given the device. =20 Each day in a cable SP deployment we see a failed DHCPv4 client try forever. I am not sold on endless pounding of the server. Actually some pounding at the server is a cue to the admin to look into their server configuration. =20 =20 Hemant =20 ------_=_NextPart_001_01CC4C93.D7A8C21C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From:= Andre = Kostur [mailto:akostur@incognito.com]
Sent: Wednesday, July 27, 2011 11:32 AM
To: Hemant Singh (shemant)
Cc: dhcwg@ietf.org; IPv6 Operations
Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 = CE rtr bis doc

>The CPE = has lots of uses for the IA_NA. Namely it's own management, SNMP monitoring, = source IP for syslog notifications, whatever.

The CPE rtr document supports both a managed CPE and a = unmanaged CPE. There is no SNMP in the unmanaged case, nor any syslog. = I don’t understand “own management”. Without the IA_PD = no device in the home will be able to obtain an IPv6 address that is = globally routable via the SP network. Thus one broadband = deployment in the cable one has already specified a CPE rtr inside a cable modem deems = IP address acquisition as failed unless both of the IA_NA and IA_PD are = obtained from the DHCPv6 server.

>Otherwise = why does it want an IA_NA at all? The client device shouldn't be tying the = IA_NA together with the IA_PD. They are separate transactions that may = tr>avel together in a single DHCP = packet.

The CPE rtr document supports an unnumbered WAN or a = numbered WAN when the WAN has an IA_NA assigned. There are several = uses for the IA_NA that have been discussed during the past four years in the IETF. Will get to those later.

Not to put words in Ted's mouth, but I believe he = was asking the same question. Why should the device abandon the perfectly = good IA_NA that it has (or could have) already obtained just because the IA_PD was = wrong.

The IA_PD was responded to by a failure error code = – it wasn’t a wrong PD. Thus the CPE router resets and = starts DHCPv6 again. So why should the CPE rtr not send both = options in the new SOLICIT?

If the IA_NA stuff was changed on the DHCP server, = the DHCP server knows who already has a lease which may be affected by whatever configuration change happened and either the admin can wait for the = IA_NA to timeout (Renew, Rebind, or expiry), or explicitly send a Reconfigure to = the device.

Operator intervention is not acceptable in a SP broadband network and also the intervention can be delayed. I have = already spoken to this fact.

Prevents this errant device from endlessly pounding = the DHCP server about an IA_NA that it has already given the = device.

Each day in a cable SP deployment we see a failed DHCPv4 = client try forever. I am not sold on endless pounding of the = server. Actually some pounding at the server is a cue to the admin to look into = their server configuration.

Hemant

------_=_NextPart_001_01CC4C93.D7A8C21C-- From leaf.y.yeh@huawei.com Thu Jul 28 07:26:32 2011 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 997B221F8BDA for ; Thu, 28 Jul 2011 07:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=3.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYFg1G8vqMIS for ; Thu, 28 Jul 2011 07:26:32 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id DE9B321F8BD9 for ; Thu, 28 Jul 2011 07:26:31 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP100BNWS46E6@szxga03-in.huawei.com> for dhcwg@ietf.org; Thu, 28 Jul 2011 22:26:30 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP100LXXS469S@szxga03-in.huawei.com> for dhcwg@ietf.org; Thu, 28 Jul 2011 22:26:30 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACR32966; Thu, 28 Jul 2011 22:26:30 +0800 (CST) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 28 Jul 2011 22:26:22 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.200]) by szxeml408-hub.china.huawei.com ([169.254.27.188]) with mapi id 14.01.0270.001; Thu, 28 Jul 2011 22:26:28 +0800 Date: Thu, 28 Jul 2011 14:26:27 +0000 From: Leaf yeh X-Originating-IP: [172.24.2.41] To: Jiangsheng Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_YDNQaGVpsCPTvcZQOsHcyA)" Content-language: zh-CN Content-class: urn:content-classes:message Accept-Language: zh-CN, en-US Thread-topic: A of one Q in Page 4 of #7 presentation in IETF81 DHC session Thread-index: AcxNMlZMatSa2z02Rpy0yffsstWxlA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" Subject: [dhcwg] A of one Q in Page 4 of #7 presentation in IETF81 DHC session 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, 28 Jul 2011 14:26:32 -0000 --Boundary_(ID_YDNQaGVpsCPTvcZQOsHcyA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT There is one question on in the Page 4 of #7 presentation in IETF81 DHC session, 07-draft-jiang-6man-addr-registration-req-02. [Open Question to WG] is length 0 allowed? My answer is yes. As I know, OPTION_RECONF_ACCEPT (20) defined in RFC3315 has length of 0. Best Regards, Leaf --Boundary_(ID_YDNQaGVpsCPTvcZQOsHcyA) Content-id: <42CF5AEABA3DBF4BBE18CCCA94F955FF@huawei.com> Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

There is one question on in the Page 4 of #7 presentation in IETF81 DHC session, 07-draft-jiang-6man-addr-registration-req-02.

[Open Question to WG] is length 0 allowed?

My answer is yes. As I know, OPTION_RECONF_ACCEPT (20) defined in RFC3315 has length of 0.

Best Regards,

Leaf

--Boundary_(ID_YDNQaGVpsCPTvcZQOsHcyA)-- From jiangsheng@huawei.com Thu Jul 28 08:13:36 2011 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 8BF0721F873D for ; Thu, 28 Jul 2011 08:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.783 X-Spam-Level: X-Spam-Status: No, score=-5.783 tagged_above=-999 required=5 tests=[AWL=0.815, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gqo42LtA49ce for ; Thu, 28 Jul 2011 08:13:36 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B94F121F8C75 for ; Thu, 28 Jul 2011 08:13:35 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP1007ENUACGV@szxga03-in.huawei.com> for dhcwg@ietf.org; Thu, 28 Jul 2011 23:13:24 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP100GMMUACGK@szxga03-in.huawei.com> for dhcwg@ietf.org; Thu, 28 Jul 2011 23:13:24 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACW28559; Thu, 28 Jul 2011 23:13:23 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 28 Jul 2011 23:13:17 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Thu, 28 Jul 2011 23:13:22 +0800 Date: Thu, 28 Jul 2011 15:13:21 +0000 From: Jiangsheng In-reply-to: X-Originating-IP: [172.24.2.41] To: Leaf yeh Message-id: <5D36713D8A4E7348A7E10DF7437A4B920121FAE8@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_X3a+JNAMHa5xBIhgWDBttg)" Content-language: en-GB Accept-Language: en-GB, zh-CN, en-US Thread-topic: A of one Q in Page 4 of #7 presentation in IETF81 DHC session Thread-index: AcxNMlZMatSa2z02Rpy0yffsstWxlAABnrhY X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] A of one Q in Page 4 of #7 presentation in IETF81 DHC session 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, 28 Jul 2011 15:13:36 -0000 --Boundary_(ID_X3a+JNAMHa5xBIhgWDBttg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Ok. Then we can have it. Thanks, Leaf. Sheng ________________________________ From: Leaf yeh Sent: 28 July 2011 22:26 To: Jiangsheng Cc: dhcwg@ietf.org Subject: A of one Q in Page 4 of #7 presentation in IETF81 DHC session There is one question on in the Page 4 of #7 presentation in IETF81 DHC session, 07-draft-jiang-6man-addr-registration-req-02. [Open Question to WG] is length 0 allowed? My answer is yes. As I know, OPTION_RECONF_ACCEPT (20) defined in RFC3315 has length of 0. Best Regards, Leaf --Boundary_(ID_X3a+JNAMHa5xBIhgWDBttg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

Ok. Then we can have it. Thanks, Leaf.

Sheng

From: Leaf yeh
Sent: 28 July 2011 22:26
To: Jiangsheng
Cc: dhcwg@ietf.org
Subject: A of one Q in Page 4 of #7 presentation in IETF81 DHC session

There is one question on in the Page 4 of #7 presentation in IETF81 DHC session, 07-draft-jiang-6man-addr-registration-req-02.

[Open Question to WG] is length 0 allowed?

My answer is yes. As I know, OPTION_RECONF_ACCEPT (20) defined in RFC3315 has length of 0.

Best Regards,

Leaf

--Boundary_(ID_X3a+JNAMHa5xBIhgWDBttg)-- From tomasz.mrugalski@gmail.com Thu Jul 28 10:26:39 2011 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 972BC21F8C0B for ; Thu, 28 Jul 2011 10:26: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgtJ16ZnsyV5 for ; Thu, 28 Jul 2011 10:26:37 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 861D321F8C09 for ; Thu, 28 Jul 2011 10:26:37 -0700 (PDT) Received: by qwc23 with SMTP id 23so1944457qwc.31 for ; Thu, 28 Jul 2011 10:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=KPy4xU/B1CJVnKgfCmriKtwl0mj7LiNhLzGOVHQFocg=; b=Dd8VrMHTff1cx/63JHIaMIhwFGJ7qWHL09Vi+66LomNtQBUKDUquIBSFNRDGPf1Xnp q522WaVqC9QoBi71Sx9nStKHv1DulZ2l3yY/IgmkuUNpoeeGkn7D2Q9sRZ3IjtlKOC7k uAHNdhsLkuL3EoY2smJSiLCPHFD/ELcRHizU8= Received: by 10.224.181.72 with SMTP id bx8mr212421qab.274.1311873959382; Thu, 28 Jul 2011 10:25:59 -0700 (PDT) Received: from dhcp-158e.meeting.ietf.org (dhcp-158e.meeting.ietf.org [130.129.21.142]) by mx.google.com with ESMTPS id cd4sm557509qab.12.2011.07.28.10.25.57 (version=SSLv3 cipher=OTHER); Thu, 28 Jul 2011 10:25:58 -0700 (PDT) Message-ID: <4E319BA4.6040407@gmail.com> Date: Thu, 28 Jul 2011 13:25:56 -0400 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: DHC WG Content-Type: multipart/mixed; boundary="------------020208030503000205030403" Subject: [dhcwg] Failover meeting 2011-07-28 - agenda 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, 28 Jul 2011 17:26:39 -0000 This is a multi-part message in MIME format. --------------020208030503000205030403 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Sorry for the late notice, but I received room confirmation this morning. Don't worry if you skip this meeting. This is more or less weekly activity, so there will be plenty of opportunities to participate and contribute. The next failover meeting will take place today (Thursday, 2011-07-28, 14:00 EDT). For remote participants, see bridge info below. For local participants, you are welcome to join in room 303AB, IETF'81 meeting venue. Note: we are moving to webex based meetings. Follow up meetings will hopefully be announced on DHC list in advance. AGENDA 0. Agenda bashing 1. Post DHC meeting comments on failover-requirements draft 2. Connection creation 2.1 comments on contributed text 3. Address/prefix allocation mechanisms 3.1 apportioned allocation - mechanism from v4 failover 3.2 independent allocation - leverages vast v6 space 3.3 determining allocation approach 4. Partner update 4.1 Time skew 4.2 Sending data 4.3 Conflict resolution 4.4 Acknowledging reception 5. Endpoint states 5.1 State descriptions 5.2 Initializing FSM 5.3 State transitions 6. Failure recovery 6.1 partner-down event 6.2 network-partition event 7. security I don't really expect to discuss all those items in today's meeting. Consider this a multi-meeting agenda that doubles as table of contents for the design document as well. We will work as far as we can today and will continue during next meeting. DESIGN DOCUMENT Based on our discussion and proposal sent by Kim, I have prepared an initial sketch of the design document. Don't expect much at this stage - it is mostly a table of contents. The idea is to work from there and start filling the content once we reach consensus on various topics. REQUIREMENTS DOCUMENT The latest version of requirements document is available here: http://datatracker.ietf.org/doc/draft-mrugalski-dhc-dhcpv6-failover-requirements/ See you there, Tomek On 11-07-27 16:37, Tomasz Mrugalski wrote: > Hi, > > I have finally managed to find some time to ogranize next failover > meeting. It will be tomorrow, Thursday, 2011-07-28 14:00 EDT. > If I didn't messed up timezones, that will be 11:00 PDT (20:00 CEST). > > If you want to participate remotely, call in this number: > Call-in toll-free number (US/Canada): 1-877-669-3239 > > If you happen to be in Quebec City, there will be room booked. > Unfortunately, the details are not yet available. I'll send them > together with agenda as soon as they become available. > > Reminder: There's DHC meeting tomorrow 9:00 EDT. Results of the failover > work done so far will be presented there. You are more than welcome to > join in. > > Regards, > Tomek Mrugalski > ISC > > Topic: v6 Failover > Date: Thursday, July 28, 2011 > Time: 2:00 pm, Eastern Daylight Time (New York, GMT-04:00) > Meeting Number: 807 854 900 > Meeting Password: bofs > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://internetconsort.webex.com/internetconsort/j.php?ED=157983692&UID=1203225977&PW=NM2RkZWJlNjgx&RT=MiMxMQ%3D%3D > 2. If requested, enter your name and email address. > 3. If a password is required, enter the meeting password: bofs > 4. Click "Join". > > To view in other time zones or languages, please click the link: > https://internetconsort.webex.com/internetconsort/j.php?ED=157983692&UID=1203225977&PW=NM2RkZWJlNjgx&ORT=MiMxMQ%3D%3D > > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > To receive a call back, provide your phone number when you join the > meeting, or call the number below and enter the access code. > Call-in toll-free number (US/Canada): 1-877-669-3239 > Call-in toll number (US/Canada): +1-408-600-3600 > Global call-in numbers: > https://internetconsort.webex.com/internetconsort/globalcallin.php?serviceType=MC&ED=157983692&tollFree=1 > Toll-free dialing restrictions: > http://www.webex.com/pdf/tollfree_restrictions.pdf > > Access code:807 854 900 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://internetconsort.webex.com/internetconsort/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > larissas@isc.org > > > To update this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://internetconsort.webex.com/internetconsort/j.php?ED=157983692&UID=1203225977&ICS=MRS3&LD=1&RD=2&ST=1&SHA2=gQZ4dw-gaYZtypGBOYmwekh9cjBsVkOe0EDersuM03M=&RT=MiMxMQ%3D%3D > > > WebEx will automatically setup Meeting Manager for Windows the first > time you join a meeting. To save time, you can setup prior to the > meeting by clicking this link: > https://internetconsort.webex.com/internetconsort/meetingcenter/mcsetup.php > > > The playback of UCF (Universal Communications Format) rich media files > requires appropriate players. To view this type of rich media files in > the meeting, please check whether you have the players installed on your > computer by going to > https://internetconsort.webex.com/internetconsort/systemdiagnosis.php. > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > CCP:+14086003600x807854900# > > IMPORTANT NOTICE: This WebEx service includes a feature that allows > audio and any documents and other materials exchanged or viewed during > the session to be recorded. By joining this session, you automatically > consent to such recordings. If you do not consent to the recording, > discuss your concerns with the meeting host prior to the start of the > recording or do not join the session. Please note that any such > recordings may be subject to discovery in the event of litigation. --------------020208030503000205030403 Content-Type: text/plain; name="draft-mrugalski-dhc-dhcpv6-failover-design-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-mrugalski-dhc-dhcpv6-failover-design-00.txt" Dynamic Host Configuration (DHC) T. Mrugalski Internet-Draft ISC Intended status: Standards Track K. Kinnear Expires: January 29, 2012 Cisco July 28, 2011 DHCPv6 Failover Design draft-mrugalski-dhc-dhcpv6-failover-design-00 Abstract TBD This is DHCPv6 Failover design document, it is not protocol specification document. Protocol specification document will follow. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 29, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Mrugalski & Kinnear Expires January 29, 2012 [Page 1] Internet-Draft DHCPv6 Failover Requirements July 2011 Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Fulfill Requirements from Requirements Draft . . . . . . . 3 3.2. Minimize Asymmetry . . . . . . . . . . . . . . . . . . . . 3 4. Connection Management . . . . . . . . . . . . . . . . . . . . . 3 4.1. Creating Connections . . . . . . . . . . . . . . . . . . . 3 4.2. Endpoint Identification . . . . . . . . . . . . . . . . . . 5 5. Address Allocation . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Apportioned Allocation . . . . . . . . . . . . . . . . . . 5 5.2. Independent Allocation . . . . . . . . . . . . . . . . . . 5 5.3. Determining Allocation Approach . . . . . . . . . . . . . . 6 5.3.1. IPv6 Addresses . . . . . . . . . . . . . . . . . . . . 6 5.3.2. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . . 6 6. Partner Update . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. Sending Data . . . . . . . . . . . . . . . . . . . . . . . 6 6.2.1. Required Data . . . . . . . . . . . . . . . . . . . . . 6 6.2.2. Optional Data . . . . . . . . . . . . . . . . . . . . . 6 6.3. Receiving Data . . . . . . . . . . . . . . . . . . . . . . 6 6.3.1. Conflict Resolution . . . . . . . . . . . . . . . . . . 6 6.3.2. Acknowledging Reception . . . . . . . . . . . . . . . . 6 7. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. State Descriptions . . . . . . . . . . . . . . . . . . . . 6 7.2. State Machine Initialization . . . . . . . . . . . . . . . 6 7.3. State Transitions . . . . . . . . . . . . . . . . . . . . . 6 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 12.1. Normative References . . . . . . . . . . . . . . . . . . . 7 12.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Mrugalski & Kinnear Expires January 29, 2012 [Page 2] Internet-Draft DHCPv6 Failover Requirements July 2011 1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Glossary 3. Goals 3.1. Fulfill Requirements from Requirements Draft 3.2. Minimize Asymmetry 4. Connection Management 4.1. Creating Connections Every server implementing the failover protocol SHOULD attempt to connect to all of its partners periodically, where the period is implementation dependent and SHOULD be configurable. In the event that a connection has been rejected by a CONNECTACK message with a reject-reason option contained in it or a DISCONNECT message, a server SHOULD reduce the frequency with which it attempts to connect to that server but it SHOULD continue to attempt to connect periodically. When a connection attempt succeeds, if the server generating the connection attempt is a primary server for that relationship, then it MUST send a CONNECT message down the connection. If it is not a primary server for the relationship, then it MUST just drop the connection and wait for the primary server to connect to it. When a connection attempt is received, the only information that the receiving server has is the IP address of the partner initiating a connection. It also knows whether it has the primary role for any failover relationships with the connecting server. If it has any relationships for which it is a primary server, it should initiate a connection of its own to the partner server, one for each primary relationship it has with that server. If it has any relationships with the connecting server for which it is a seconary server, it should just await the CONNECT message to determine which relationship this connection is to serve. Mrugalski & Kinnear Expires January 29, 2012 [Page 3] Internet-Draft DHCPv6 Failover Requirements July 2011 If it has no secondary relationships with the connecting server, it SHOULD drop the connection. To summarize -- a primary server MUST use a connection that it has initiated in order to send a CONNECT message. Every server that is a secondary server in a relationship attempts to create a connection to the server which is primary in the relationship, but that connection is only used to stimulate the primary server into recognizing that the secondary server is ready for operation. The reason behind this is that the secondary server has no way to communicate to the primary server which relationship a connection is designed to serve. A server which has multiple secondary relationships with a primary server SHOULD only send one stimulus connection attempt to the primary server. Once a connection is established, the primary server MUST send a CONNECT message across the connection. A secondary server MUST wait for the CONNECT message from a primary server. If the secondary server doesn't receive a CONNECT message from the primary server in an installation dependent amount of time, it MAY drop the connection and send another stimulus connection attempt to the primary server. Every CONNECT message includes a TLS-request option, and if the CONNECTACK message does not reject the CONNECT message and the TLS- reply option says TLS MUST be used, then the servers will immediately enter into TLS negotiation. Once TLS negotiation is complete, the primary server MUST resend the CONNECT message on the newly secured TLS connection and then wait for the CONNECTACK message in response. The TLS-request and TLS-reply options MUST NOT appear in either this second CONNECT or its associated CONNECTACK message as they had in the first messages. The second message sent over a new connection (either a bare TCP connection or a connection utilizing TLS) is a STATE message. Upon the receipt of this message, the receiver can consider communications up. It is entirely possible that two servers will attempt to make connections to each other essentially simultaneously, and in this case the secondary server will be waiting for a CONNECT message on each connection. The primary server MUST send a CONNECT message over one connection and it MUST close the other connection. A secondary server MUST NOT respond to the closing of a TCP connection with a blind attempt to reconnect -- there may be another TCP connection to the same failover partner already in use. Mrugalski & Kinnear Expires January 29, 2012 [Page 4] Internet-Draft DHCPv6 Failover Requirements July 2011 4.2. Endpoint Identification The proper operation of the failover protocol requires more than the transmission of messages between one server and the other. Each end- point might seem to be a single DHCP server, but in fact there are many situations where additional flexibility in configuration is useful. The failover protocol SHOULD be configured with one failover relationship between each pair of failover servers. In this case there is one failover endpoint for that relationship on each partner. This failover relationship MUST have a unique name. There is typically little need for addtional relationships between any two servers but there MAY be more than one failover relationship between two servers -- however each MUST have a unique relationship name. Any failover endpoint can take actions and hold unique states. This document frequently describes the behavior of the protocol in terms of primary and secondary servers, not primary and secondary failover endpoints. However, it is important to remember that every 'server' described in this document is in reality a failover endpoint that resides in a particular process, and that many failover end- points may reside in the same server process. It is not the case that there is a unique failover endpoint for each prefix that participates in a failover relationship. On one server, there is (typically) one failover endpoint per partner, regardless of how many prefixes are managed by that combination of partner and role. Conversely, on a particular server, any given prefix will be associated with exactly one failover endpoint. When a connection is received from the partner, the unique failover endpoint to which the message is directed is determined solely by the IP address of the partner, the relationship-name, and the role of the receiving server. 5. Address Allocation 5.1. Apportioned Allocation 5.2. Independent Allocation Mrugalski & Kinnear Expires January 29, 2012 [Page 5] Internet-Draft DHCPv6 Failover Requirements July 2011 5.3. Determining Allocation Approach 5.3.1. IPv6 Addresses 5.3.2. IPv6 Prefixes 6. Partner Update 6.1. Time Skew 6.2. Sending Data 6.2.1. Required Data 6.2.2. Optional Data 6.3. Receiving Data 6.3.1. Conflict Resolution 6.3.2. Acknowledging Reception 7. Endpoint States 7.1. State Descriptions 7.2. State Machine Initialization 7.3. State Transitions 8. Security 9. Security Considerations TBD... 10. IANA Considerations IANA is not requested to perform any actions at this time. Mrugalski & Kinnear Expires January 29, 2012 [Page 6] Internet-Draft DHCPv6 Failover Requirements July 2011 11. Acknowledgements This document extensively uses concepts, definitions and other parts of [dhcpv4-failover] document. Authors would like to thank ... for their comments and feedback. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3074] Volz, B., Gonczi, S., Lemon, T., and R. Stevens, "DHC Load Balancing Algorithm", RFC 3074, February 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, October 2006. 12.2. Informative References [I-D.ietf-dhc-dhcpv6-redundancy-consider] Brzozowski, J., Tremblay, J., Chen, J., and T. Mrugalski, "DHCPv6 Redundancy Deployment Considerations", draft-ietf-dhc-dhcpv6-redundancy-consider-00 (work in progress), April 2011. [I-D.mrugalski-dhc-dhcpv6-failover-requirements] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Requirements", draft-mrugalski-dhc-dhcpv6-failover-requirements-00 (work in progress), June 2011. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", Mrugalski & Kinnear Expires January 29, 2012 [Page 7] Internet-Draft DHCPv6 Failover Requirements July 2011 RFC 2136, April 1997. [dhcpv4-failover] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., Rabil, G., Dooley, M., and A. Kapur, "DHCP Failover Protocol", draft-ietf-dhc-failover-12 (work in progress), March 2003. Authors' Addresses Tomasz Mrugalski Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 USA Phone: +1 650 423 1345 Email: tomasz.mrugalski@gmail.com Kim Kinnear Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, Massachusetts 01719 USA Phone: +1 (978) 936-0000 Email: kkinear@cisco.com Mrugalski & Kinnear Expires January 29, 2012 [Page 8] --------------020208030503000205030403-- From volz@cisco.com Thu Jul 28 12:25:05 2011 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 1933511E80F0 for ; Thu, 28 Jul 2011 12:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxkqF-PepS0d for ; Thu, 28 Jul 2011 12:25:04 -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 AFDD311E80E5 for ; Thu, 28 Jul 2011 12:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=7692; q=dns/txt; s=iport; t=1311881103; x=1313090703; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=SG0Gw8MX2xJ5PVFZUIK+OUzYqiwCuHrhvmpv9FPZNSY=; b=aULe4eDZyjgB0v2SvuihtymQo6DuLcd8krXGW7Lz4fM5bsw3KiYzUWr5 thBfzEJavEH/149fvcsDwye8Ou/F6D107SKQSn6cEoNat/31VIDbUfu3Z mrPxcvXg632kUtNq9H47EWMUMj7BP5ZWgTNxY2yrf9ToTljcVs9G7wMyI w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUAAIy2MU6tJXG9/2dsb2JhbAApCwEBAQECAQEBAREBIQo6CwUHBQIBCREEAQELBgYdAQYBExgjDggBAQUBFgwUB5drj093iHwEpGmeQoMjgj9fBIdZkDCLcg X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208";a="7510453" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 28 Jul 2011 19:25:01 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6SJP1K1025332; Thu, 28 Jul 2011 19:25:01 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, 28 Jul 2011 14:25:01 -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: Thu, 28 Jul 2011 14:24:58 -0500 Message-ID: In-Reply-To: <8028E635-78F5-4979-8DF5-1F329317B90D@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Comments on draft-ietf-dhc-pd-exclude-02 (& draft-mrugalski-dhc-dhcpv6-suboptions-01) Thread-Index: AcxK9cnqP+NCnk2oQueTINdxMez1YACYng0Q References: <4E2C7836.5090404@gmail.com> <8028E635-78F5-4979-8DF5-1F329317B90D@gmail.com> From: "Bernie Volz (volz)" To: "jouni korhonen" , "Tomasz Mrugalski" X-OriginalArrivalTime: 28 Jul 2011 19:25:01.0083 (UTC) FILETIME=[0B6B8EB0:01CC4D5C] Cc: DHC WG Subject: Re: [dhcwg] Comments on draft-ietf-dhc-pd-exclude-02 (& draft-mrugalski-dhc-dhcpv6-suboptions-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: Thu, 28 Jul 2011 19:25:05 -0000 Regarding issue #3 and draft-mrugalski-dhc-dhcpv6-suboptions-01.txt ... Actually the list in draft-mrugalski-dhc-dhcpv6-suboptions-01.txt on page 5 somewhat compares apples and oranges ... #3. in that list could NEVER use the RFC 3315 ORO as it provides only a method to identify IANA assigned options and not vendor options. So, I really don't think this is valid as an argument here. For vendor options, the vendor will need to define their own ORO option in their space to accommodate this (if needed). End of story. Regarding draft-ietf-dhc-pd-exclude-02, I was thinking a bit about how this might be implemented in servers (whether a delegating router or server). And, actually, putting the ORO inside the IA_PD option would, IMHO, be better as it does allow us to start thinking more about what draft-mrugalski-dhc-dhcpv6-suboptions-01 is proposing. And, I would think that this pd-exclude option could just be pre-configured on the appropriate level for the server (prefix, server-wide, etc) and sent out 'as is' when requested? While today this would not work for servers that aren't updated to support the ORO at various levels, it will require a generic server change and not something specific to this one option. While DHC RFCs generally stay away from 'server' configuration issues, I think in this case the two configuration models are to pre-configure it or have some settings as to whether exclude-pd is enabled, the target excluded prefix length (likely 64), and whether the all-zero's or all-one's prefix should be excluded (excluding other values, such as the example in pd-exclude, is more difficult in this calculated case if the delegated prefix length is allowed to be variable). This could then be used in cases where 'clients' (requesting routers) might be delegated a variety of prefix lengths depending on what they requested (hint) or are to be given based on some policy decisions. I also wonder this might even argue for a simplified option ... 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_PD_EXCLUDE | option-len =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix-len | flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where flags has just 1 bit for now which specifies whether to 0s or 1s extend the delegated prefix to the prefix-len. Is the example (where 5 bits of 0|1|1|1|1 where used really realistic)? Do we really need this level of flexibility? Another reason for placing this into an IA_PD ORO option is what if there are multiple IA_PDs and the requesting router is only interested in supporting this in some cases. Consider the case where the requesting router has already obtained an IA_PD (w/PD_EXCLUDE) and now needs another because there are more prefixes needed. In this case, this request would NOT want to include the PD_EXCLUDE for these additional IA_PD(s) because they would NOT be used on the WAN interface? So, I think having this be at the IA_PD level is the correct way to go. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of jouni korhonen Sent: Monday, July 25, 2011 2:08 PM To: Tomasz Mrugalski Cc: DHC WG Subject: Re: [dhcwg] Comments on draft-ietf-dhc-pd-exclude-02 Hi Tomasz, On Jul 24, 2011, at 10:53 PM, Tomasz Mrugalski wrote: > Hi, > I've just read the updated version of draft-ietf-dhc-pd-exclude-02 > draft. Thank you for amending the draft according to most of my > comments. It looks good. Thanks for reviewing -02. Comments inline. > I have several more comments: >=20 > 1. Section 5.1 describes SOLICIT-ADVERTISE exchange and concludes that > received PD_EXCLUDE may be used to select best server. You may want to > add a single sentence similar to "Requesting router MUST proceed to > Prefix Delegation procedure described in section 6.1". Makes sense. > 2. Section 5.1 describes 4 message exchange. What if delegating router > wants to use rapid-commit (SOLICIT-REPLY)? You should add a > clarification that requesting router MUST use received values in REPLY > if rapid-commit option was sent in SOLICIT (recommended). Alternatively, > you may say that rapid-commit is not allowed with PD_EXCLUDE (that would > be unnecessary restriction, so it is not recommended). Hmm.. restricting rapid-commit wouldn't make sense, agree. However, the current wording is like it is now due trying to be align with RFC3633, which has the following text in Section 11.1: ... 3315. The requesting router MAY choose to consider the presence of advertised prefixes in its decision about which delegating router to respond to. The above implies me also a 4 message exchange. How about: Once receiving Advertise message, the requesting router uses the prefix(es) received in OPTION_PD_EXCLUDE in addition to the advertised prefixes to choose the delegating router. Requesting router MUST proceed to Prefix Delegation procedure described in Section 6.1. If Advertise message did not include OPTION_PD_EXCLUDE option, then the requesting router MUST fall back to normal [RFC3633] Section 11.1 behavior. >=20 > 3. I acknowledge that authors chose not to follow ORO suboption approach > proposed in draft-mrugalski-dhc-dhcpv6-suboptions. That is unfortunate, > but I can live with it. However, if you still considering that > possibility, I'd like to present additional arguments that may support > ORO suboption approach. >=20 > Since PD_EXCLUDE implementation requires modification of both server > (delegating router) and client (requesting router) code, there's no real > difference if you: > a) send top-level ORO and server needs to know that this specific > PD_EXCLUDE option does not go to the message directly, but rathere > within IAPPREFIX > b) send ORO within IA_PD (or IAPREFIX) and server needs to parse it in > those scopes >=20 > In both cases, server requires custom logic to be coded to serve > PD_EXCLUDE to requesting routers. My opinion is that option b) would be > generic and would allow reusing this logic for other options that may be > stored as suboptions. >=20 > Think about this in a long term. 10 years from now, there will probably > be around 200 options defined. With your current approach, server will > need to decide on a per option basis, where to return requested options > - directly in message or perhaps within other options. >=20 > Ok, that was the last time I tried to convince you to use ORO suboption. > Regardless of your decision, I strongly support your draft. I understand this. My issue is more of the lack of clear text for this type of OPTION_ORO usage in RFC3315. I can see it mentioned in Appendix B table but that is all. In order to provide unambiguous solution I would most probably add all required text in this I-D as standalone or reference to draft-mrugalski (apparently it the should be a normative reference, with normative language). I don't find either of these as a good approach. - Jouni >=20 > Good luck with the presentation on Thursday! >=20 > Regards, > 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 leaf.y.yeh@huawei.com Thu Jul 28 13:12:53 2011 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 8FC585E8009 for ; Thu, 28 Jul 2011 13:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.796 X-Spam-Level: X-Spam-Status: No, score=-3.796 tagged_above=-999 required=5 tests=[AWL=2.802, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5szt0Dz92DwT for ; Thu, 28 Jul 2011 13:12:53 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9C79B21F8A70 for ; Thu, 28 Jul 2011 13:12:52 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP2007MK85EQX@szxga04-in.huawei.com> for dhcwg@ietf.org; Fri, 29 Jul 2011 04:12:50 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP200MO285ESM@szxga04-in.huawei.com> for dhcwg@ietf.org; Fri, 29 Jul 2011 04:12:50 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACR43887; Fri, 29 Jul 2011 04:12:49 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 29 Jul 2011 04:12:42 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.200]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Fri, 29 Jul 2011 04:12:48 +0800 Date: Thu, 28 Jul 2011 20:12:47 +0000 From: Leaf yeh X-Originating-IP: [172.24.2.41] To: "dhcwg@ietf.org" Message-id: <7748265D-39EA-44CD-B94E-00D7CAEEDD29@mimectl> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_8AoXbiMh3kkHVtXfZpEfSA)" Content-language: zh-CN Content-class: urn:content-classes:message Accept-Language: zh-CN, en-US Thread-topic: Item for the Errata - Section 17.2.1 - RFC3315? Thread-index: AcxNYrcIg4nOpobdSPi/5s4muLi9hA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "rdroms@cisco.com" Subject: [dhcwg] Item for the Errata - Section 17.2.1 - RFC3315? 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, 28 Jul 2011 20:12:53 -0000 --Boundary_(ID_8AoXbiMh3kkHVtXfZpEfSA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT I might get a item for the Errata after reading RFC3315 this morning. The words in the following 2 paragraphs have a conflict. Section 17.2.1 - RFC3315 - DHCPv6 - Server Behavior - Receipt of Solicit Messages For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client indicates with a Reconfigure Accept option in the Solicit message that it will not accept a Reconfigure message, the servers discard the Solicit message. Section 22.20 - RFC3315 - DHCPv6 - Reconfigure Accept Option A client uses the Reconfigure Accept option to announce to the server whether the client is willing to accept Reconfigure messages, and a server uses this option to tell the client whether or not to accept Reconfigure messages. The default behavior, in the absence of this option, means unwillingness to accept Reconfigure messages, or instruction not to accept Reconfigure messages, for the client and server messages, respectively. The following figure gives the format of the Reconfigure Accept option: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_RECONF_ACCEPT | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_RECONF_ACCEPT (20). option-len 0. I mean the client can not include a Reconfigure Accept Option for the unwillingness to accept a Reconfigure message per the description of Reconfigure Accept Option in Section 22.20. So the words for the revison in section 17.2.1 might be 'For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client does not include a Reconfigure Accept option in the Solicit message, the servers discard the Solicit message.' Best Regards, Leaf --Boundary_(ID_8AoXbiMh3kkHVtXfZpEfSA) Content-id: <4B27423652198D46A8D4CCDFD4FADC0D@huawei.com> Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

I might get a item for the Errata after reading RFC3315 this morning.

The words in the following 2 paragraphs have a conflict.

Section 17.2.1 - RFC3315 - DHCPv6 - Server Behavior - Receipt of Solicit Messages

   For example, if the administrative policy for the server is
   that it may only respond to a client that is willing to accept a
   Reconfigure message, if the client indicates with a Reconfigure
   Accept option in the Solicit message that it will not accept a
   Reconfigure message, the servers discard the Solicit message.

Section 22.20 - RFC3315 - DHCPv6 - Reconfigure Accept Option

   A client uses the Reconfigure Accept option to announce to the server
   whether the client is willing to accept Reconfigure messages, and a
   server uses this option to tell the client whether or not to accept
   Reconfigure messages. The default behavior, in the absence of this
   option, means unwillingness to accept Reconfigure messages, or
   instruction not to accept Reconfigure messages, for the client and
   server messages, respectively. The following figure gives the format
   of the Reconfigure Accept option:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     OPTION_RECONF_ACCEPT      |               0               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code   OPTION_RECONF_ACCEPT (20).
    option-len    0.

I mean the client can not include a Reconfigure Accept Option for the unwillingness to accept a Reconfigure message per the description of Reconfigure Accept Option in Section 22.20.

So the words for the revison in section 17.2.1 might be 'For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client does not include a Reconfigure Accept option in the Solicit message, the servers discard the Solicit message.'

Best Regards,

Leaf

--Boundary_(ID_8AoXbiMh3kkHVtXfZpEfSA)-- From leaf.y.yeh@huawei.com Thu Jul 28 13:55:04 2011 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 2F09221F8B23 for ; Thu, 28 Jul 2011 13:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.076 X-Spam-Level: X-Spam-Status: No, score=-4.076 tagged_above=-999 required=5 tests=[AWL=2.523, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rrf21gzj4nrX for ; Thu, 28 Jul 2011 13:55:03 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id E879B21F8AD2 for ; Thu, 28 Jul 2011 13:55:02 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP2005A4A3PX6@szxga04-in.huawei.com> for dhcwg@ietf.org; Fri, 29 Jul 2011 04:55:01 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP200MIPA3PSM@szxga04-in.huawei.com> for dhcwg@ietf.org; Fri, 29 Jul 2011 04:55:01 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACR44939; Fri, 29 Jul 2011 04:55:01 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 29 Jul 2011 04:54:51 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.200]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Fri, 29 Jul 2011 04:55:00 +0800 Date: Thu, 28 Jul 2011 20:55:00 +0000 From: Leaf yeh X-Originating-IP: [172.24.2.41] To: "dhcwg@ietf.org" Message-id: <58DFA861-81E1-4735-86A4-33863F012BCC@mimectl> Content-id: <3A569D11D19AB14BA90FD8325AD5D364@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: 7BIT Content-class: urn:content-classes:message Accept-Language: zh-CN, en-US Thread-topic: Correction Item - Errata of RFC3633 ? Thread-index: AcxNaJ1JgwNlSeM/QGSxEKB18VVj3Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "ot@cisco.com" Subject: [dhcwg] Correction Item - Errata of RFC3633 ? 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, 28 Jul 2011 20:55:04 -0000 I might get a correction item for the Errata of RFC3633 this morning. http://www.rfc-editor.org/errata_search.php?rfc=3633 - Errata ID: 2468 New last paragraph of 12.2: When the DR delegates prefixes to a Requesting Router, the Requesting Router has sole authority for assignment of those prefixes, and the Delegating Router MUST NOT assign any prefixes from that delegated prefix to any of its own links. Notes: This change clarifies that the authority over the address space is delegated to the RR. Moving the use restriction for the address space from the RR to the DR. I think the correct Notes might be '.... Moving the use restriction for the address space from the DR to the RR.' Best Regards, Leaf From ot@cisco.com Thu Jul 28 14:08:52 2011 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 B2FFB21F855A for ; Thu, 28 Jul 2011 14:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kt3CxksjBHd for ; Thu, 28 Jul 2011 14:08:52 -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 3462111E80B4 for ; Thu, 28 Jul 2011 14:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=892; q=dns/txt; s=iport; t=1311887332; x=1313096932; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=7LdQ5XKZ0Oop3ayMZxKateAFDI3imUvs02oJ7YMrOAg=; b=XRtIeT12sRXCeJY3KgwWJBcLOo+LerDacmhrcxIZBT9PRSbdPecFHzL+ dLHIFV8PYW5VBXtEhH2vSH7Y0/W+EZfoEeePknMYfMUXe1/Ob1/6sHy/v CdFo3Y3KoA3GLa9OehloYe2aQ88neJ7B56WKckI0Mfdx4JoDVwp11/8bH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALnOMU6rRDoG/2dsb2JhbAA0AQEBAQIBCwkBK0UFDAxSFFEHPqc6d4h8BCOkU549hWJfBJJ5hQeLeU0 X-IronPort-AV: E=Sophos;i="4.67,284,1309737600"; d="scan'208";a="7542224" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-3.cisco.com with ESMTP; 28 Jul 2011 21:08:44 +0000 Received: from [10.21.73.106] ([10.21.73.106]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6SL8h7j030276; Thu, 28 Jul 2011 21:08:43 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <58DFA861-81E1-4735-86A4-33863F012BCC@mimectl> Date: Thu, 28 Jul 2011 17:08:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <58DFA861-81E1-4735-86A4-33863F012BCC@mimectl> To: Leaf yeh X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sat, 30 Jul 2011 10:45:08 -0700 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Correction Item - Errata of RFC3633 ? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: