From dhcwg-bounces@ietf.org Thu Nov 01 08:12:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InYru-0003mG-Va; Thu, 01 Nov 2007 08:09:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImXh4-0005Ri-Ae for dhcwg@ietf.org; Mon, 29 Oct 2007 12:42:26 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImXh3-0000KB-JI for dhcwg@ietf.org; Mon, 29 Oct 2007 12:42:26 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9TGgEib026035; Mon, 29 Oct 2007 18:42:22 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 18:42:20 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 11:41:44 -0500 Received: from 10.241.59.117 ([10.241.59.117]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 29 Oct 2007 16:41:44 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 29 Oct 2007 11:42:24 -0500 Subject: Re: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication From: Basavaraj Patil To: ext Ralph Droms , Message-ID: Thread-Topic: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication Thread-Index: AcgaSq6k7SnHSIY9EdyP2QARJNUNiA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Oct 2007 16:41:44.0285 (UTC) FILETIME=[96F8D0D0:01C81A4A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-Mailman-Approved-At: Thu, 01 Nov 2007 08:09:49 -0400 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ralph, I think overloading DHCP for access authentication is a bad idea. DHCP was not designed for that purpose. I guess I need to communicate this on the int-area list. But anyway you know my opinion at least in the DHC WG. -Basavaraj On 10/19/07 6:05 AM, "ext Ralph Droms" wrote: > There is a lengthy discussion about rechartering the dhc WG to take > on the DHCP authentication proposals in draft-pruss-dhcp-auth- > dsl-01.txt and draft-zhao-dhc-user-authentication-02 in the int- > area@ietf.org mailing list. Both of these drafts have been submitted > for to the WG for review in the past, and neither, to date, has been > accepted as a dhc WG work iterm. I've included a copy of the initial > posting, http://www1.ietf.org/mail-archive/web/int-area/current/ > msg00957.html, below. Because this discussion may lead to the > rechartering of the dhc WG to take on either or both of these drafts > as new work items, those of you not on the int-area mailing list > should consider reviewing the e-mail thread and contributing to the > discussion. > > - Ralph > > > ===== > To: Internet Area > Subject: [Int-area] DCHP-based authentication for DSL? > From: Jari Arkko > Date: Thu, 04 Oct 2007 23:22:15 +0300 > > > We talked about the DSL requirements earlier on this list. Now > they have sent us a liaison statement regarding what they would > like to do: > > "At this time, we would like to make the IETF aware that during > our most recent DSL Forum quarterly meeting, the Architecture > and Transport Working Group agreed to seriously consider adopting > a mechanism such as that proposed in draft-pruss-dhcp-auth-dsl-01.txt > or draft-zhao-dhc-user-authentication-02. We understand that the authors > of these specifications intend to produce a combined document soon. > The DSL Forum formally requests that the IETF adopt this as a work > item, and would appreciate being advised of progress as soon as > possible. > > Our next quarterly meeting is December 10-13, in Lisbon, Portugal." > > > How do we feel about this? Is this a good idea, considering the DSL > architecture? How will it affect DHCP the protocol? How would > you go about making DHCP extensions so that they work best > for all possible environments and not just DSL? Is anyone > already working on the combined draft promised above? Are > there any other choices that we should recommend instead? > > I would like to hold the discussion on this in this list until > we've determined that the DHCP protocol is the right tool > for the job. If it is, we can recharter DHC WG again to add > the actual development work there. (DHC is right now > being rechartered but that recharting is mostly a cleanup > and not the addition of functionality to do this.) > > Jari > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 01 11:53:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IncIs-00089Q-DL; Thu, 01 Nov 2007 11:49:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IncIq-00086b-Ld for dhcwg@ietf.org; Thu, 01 Nov 2007 11:49:52 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IncIk-0006k7-5L for dhcwg@ietf.org; Thu, 01 Nov 2007 11:49:52 -0400 X-IronPort-AV: E=Sophos;i="4.21,358,1188802800"; d="scan'208,217";a="14168002" Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 01 Nov 2007 08:49:41 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id lA1Fnd5E005576; Thu, 1 Nov 2007 08:49:39 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA1FndZU015090; Thu, 1 Nov 2007 15:49:39 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 08:49:39 -0700 Received: from dhcp-128-107-112-156.cisco.com ([128.107.112.156]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 08:49:38 -0700 Message-ID: <4729F592.5070008@cisco.com> Date: Thu, 01 Nov 2007 08:49:38 -0700 From: Richard Pruss Organization: Cisco Systems User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication References: In-Reply-To: X-OriginalArrivalTime: 01 Nov 2007 15:49:38.0795 (UTC) FILETIME=[CF4623B0:01C81C9E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8391; t=1193932179; x=1194796179; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ric@cisco.com; z=From:=20Richard=20Pruss=20 |Subject:=20Re=3A=20[dhcwg]=20Discussion=20of=20dhc=20WG=20rechartering=2 0for=20DHCP=20authentication |Sender:=20; bh=CRBC+TuSoRjhdsu5vabj9Ybt8pFX5z4HcBk7y+xqeDw=; b=j4sXFWzqxv9ueBO0ChN8JujTZi4bI2R6l2F93KUR97WaIogClJCUn1ZYDgL5XkYSHciCMF6/ MWLaIqaslgOg51dV/EZDOGrABEFTYjRLwoXP+HCt8UmitIkNji6D1aCt; Authentication-Results: sj-dkim-8; header.From=ric@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: dhcwg@ietf.org, ext Ralph Droms X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ric@cisco.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0015827449==" Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0015827449== Content-Type: multipart/alternative; boundary="------------070706040609060208020901" This is a multi-part message in MIME format. --------------070706040609060208020901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication is something that happens at every layer with every application. Terminal access was designed without authentication, that does not mean we do it like that today. I do not think we can take the argument of it was not designed for x as a reason to stay in the past. Regards, Ric Basavaraj Patil wrote, around 29/10/07 9:42 AM: > Ralph, > > I think overloading DHCP for access authentication is a bad idea. DHCP was > not designed for that purpose. I guess I need to communicate this on the > int-area list. But anyway you know my opinion at least in the DHC WG. > > -Basavaraj > > > On 10/19/07 6:05 AM, "ext Ralph Droms" wrote: > > >> There is a lengthy discussion about rechartering the dhc WG to take >> on the DHCP authentication proposals in draft-pruss-dhcp-auth- >> dsl-01.txt and draft-zhao-dhc-user-authentication-02 in the int- >> area@ietf.org mailing list. Both of these drafts have been submitted >> for to the WG for review in the past, and neither, to date, has been >> accepted as a dhc WG work iterm. I've included a copy of the initial >> posting, http://www1.ietf.org/mail-archive/web/int-area/current/ >> msg00957.html, below. Because this discussion may lead to the >> rechartering of the dhc WG to take on either or both of these drafts >> as new work items, those of you not on the int-area mailing list >> should consider reviewing the e-mail thread and contributing to the >> discussion. >> >> - Ralph >> >> >> ===== >> To: Internet Area >> Subject: [Int-area] DCHP-based authentication for DSL? >> From: Jari Arkko >> Date: Thu, 04 Oct 2007 23:22:15 +0300 >> >> >> We talked about the DSL requirements earlier on this list. Now >> they have sent us a liaison statement regarding what they would >> like to do: >> >> "At this time, we would like to make the IETF aware that during >> our most recent DSL Forum quarterly meeting, the Architecture >> and Transport Working Group agreed to seriously consider adopting >> a mechanism such as that proposed in draft-pruss-dhcp-auth-dsl-01.txt >> or draft-zhao-dhc-user-authentication-02. We understand that the authors >> of these specifications intend to produce a combined document soon. >> The DSL Forum formally requests that the IETF adopt this as a work >> item, and would appreciate being advised of progress as soon as >> possible. >> >> Our next quarterly meeting is December 10-13, in Lisbon, Portugal." >> >> >> How do we feel about this? Is this a good idea, considering the DSL >> architecture? How will it affect DHCP the protocol? How would >> you go about making DHCP extensions so that they work best >> for all possible environments and not just DSL? Is anyone >> already working on the combined draft promised above? Are >> there any other choices that we should recommend instead? >> >> I would like to hold the discussion on this in this list until >> we've determined that the DHCP protocol is the right tool >> for the job. If it is, we can recharter DHC WG again to add >> the actual development work there. (DHC is right now >> being rechartered but that recharting is mostly a cleanup >> and not the addition of functionality to do this.) >> >> Jari >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/dhcwg >> > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > --------------070706040609060208020901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication is something that happens at every layer with every application. Terminal access was designed without authentication, that does not mean we do it like that today.

 I do not think we can take the argument of it was not designed for x as a reason to stay in the past.

Regards,
Ric

Basavaraj Patil wrote, around 29/10/07 9:42 AM: 
Ralph,

I think overloading DHCP for access authentication is a bad idea. DHCP was
not designed for that purpose. I guess I need to communicate this on the
int-area list. But anyway you know my opinion at least in the DHC WG.

-Basavaraj


On 10/19/07 6:05 AM, "ext Ralph Droms" <rdroms@cisco.com> wrote:

  
There is a lengthy discussion about rechartering the dhc WG to take
on the DHCP authentication proposals in draft-pruss-dhcp-auth-
dsl-01.txt and draft-zhao-dhc-user-authentication-02 in the int-
area@ietf.org mailing list.  Both of these drafts have been submitted
for to the WG for review in the past, and neither, to date, has been
accepted as a dhc WG work iterm.  I've included a copy of the initial
posting, http://www1.ietf.org/mail-archive/web/int-area/current/
msg00957.html, below.  Because this discussion may lead to the
rechartering of the dhc WG to take on either or both of these drafts
as new work items, those of you not on the int-area mailing list
should consider reviewing the e-mail thread and contributing to the
discussion.

- Ralph


=====
To: Internet Area <int-area at ietf.org>
Subject: [Int-area] DCHP-based authentication for DSL?
From: Jari Arkko <jari.arkko at piuha.net>
Date: Thu, 04 Oct 2007 23:22:15 +0300


We talked about the DSL requirements earlier on this list. Now
they have sent us a liaison statement regarding what they would
like to do:

"At this time, we would like to make the IETF aware that during
our most recent DSL Forum quarterly meeting, the Architecture
and Transport Working Group agreed to seriously consider adopting
a mechanism such as that proposed in draft-pruss-dhcp-auth-dsl-01.txt
or draft-zhao-dhc-user-authentication-02. We understand that the authors
of these specifications intend to produce a combined document soon.
The DSL Forum formally requests that the IETF adopt this as a work
item, and would appreciate being advised of progress as soon as
possible.

Our next quarterly meeting is December 10-13, in Lisbon, Portugal."


How do we feel about this? Is this a good idea, considering the DSL
architecture? How will it affect DHCP the protocol? How would
you go about making DHCP extensions so that they work best
for all possible environments and not just DSL? Is anyone
already working on the combined draft promised above? Are
there any other choices that we should recommend instead?

I would like to hold the discussion on this in this list until
we've determined that the DHCP protocol is the right tool
for the job. If it is, we can recharter DHC WG again to add
the actual development work there. (DHC is right now
being rechartered but that recharting is mostly a cleanup
and not the addition of functionality to do this.)

Jari


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


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
--------------070706040609060208020901-- --===============0015827449== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0015827449==-- From dhcwg-bounces@ietf.org Thu Nov 01 13:02:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IndOW-0003Gr-Cj; Thu, 01 Nov 2007 12:59:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IndOU-0003GV-Sk for dhcwg@ietf.org; Thu, 01 Nov 2007 12:59:46 -0400 Received: from exprod7og104.obsmtp.com ([64.18.2.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IndOU-00073A-DS for dhcwg@ietf.org; Thu, 01 Nov 2007 12:59:46 -0400 Received: from source ([81.200.64.181]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Thu, 01 Nov 2007 09:59:44 PDT Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 875BE56835 for ; Thu, 1 Nov 2007 09:59:44 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) X-Spam-Status: No, hits=0.0 required=8.4 tests=CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: 0.000 X-Spam-Level: Received: from [81.200.65.53] ([81.200.65.53]) (authenticated user mellon@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for dhcwg@ietf.org; Thu, 1 Nov 2007 09:59:43 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <97AA148C-232F-4905-AC98-AFA58EA15558@cisco.com> References: <005501c81555$6f49f360$ba3dfea9@ad.redback.com> <471F0F26.4070006@uninett.no> <471FACDD.3000707@cisco.com> <8BA9DF9F-7094-4F4A-8FDD-ED9F36017251@cisco.com> <20071026002824.GA14789@steelhead.localdomain> <97AA148C-232F-4905-AC98-AFA58EA15558@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Date: Thu, 1 Nov 2007 09:58:44 -0700 To: dhcwg WG X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [dhcwg] Re: [Int-area] DCHP-based authentication for DSL? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Oct 29, 2007, at 12:16 AM, Stig Venaas wrote: [...] At Ralph's request, I've gone back and read the archives for this discussion. Much learned and useful argument has been presented, including Stig's most recent objection, which is certainly a good valid technical objection. However, what I have *not* noticed, which I find kind of stunning, is anybody from the "let's do it" side of the argument answering Iljitsch's very cogent and telling objection here: http://www1.ietf.org/mail-archive/web/int-area/current/msg01014.html This objection is a showstopper. If it can't be answered, there is no chance that this protocol can ever be deployed. All the technical and procedural objections that have been discussed here are irrelevant if this one objection can't be answered. So I think that before any further discussion on the merits of the wire protocol go forward, perhaps it would behoove this learned body to actually address Iljitsch's objection. I must confess that I have not read every message in the archive, because there are a remarkable lot of them, so if someone can point me at the place where Iljitsch's objection was shown to be unnecessary, I would consider it a great favor. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 01 14:03:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IneMU-0004ej-Vr; Thu, 01 Nov 2007 14:01:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IneMU-0004dr-8C for dhcwg@ietf.org; Thu, 01 Nov 2007 14:01:46 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IneMR-0003Py-0I for dhcwg@ietf.org; Thu, 01 Nov 2007 14:01:46 -0400 X-IronPort-AV: E=Sophos;i="4.21,359,1188802800"; d="scan'208";a="542248657" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 01 Nov 2007 11:01:34 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lA1I1Ymh017074; Thu, 1 Nov 2007 11:01:34 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA1I1TZW005515; Thu, 1 Nov 2007 18:01:34 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 11:01:28 -0700 Received: from dhcp-128-107-112-156.cisco.com ([128.107.112.156]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 11:01:28 -0700 Message-ID: <472A1477.1050706@cisco.com> Date: Thu, 01 Nov 2007 11:01:27 -0700 From: Richard Pruss Organization: Cisco Systems User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Ted Lemon Subject: Re: [dhcwg] Re: [Int-area] DCHP-based authentication for DSL? References: <005501c81555$6f49f360$ba3dfea9@ad.redback.com> <471F0F26.4070006@uninett.no> <471FACDD.3000707@cisco.com> <8BA9DF9F-7094-4F4A-8FDD-ED9F36017251@cisco.com> <20071026002824.GA14789@steelhead.localdomain> <97AA148C-232F-4905-AC98-AFA58EA15558@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2007 18:01:28.0199 (UTC) FILETIME=[39A56970:01C81CB1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2493; t=1193940094; x=1194804094; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ric@cisco.com; z=From:=20Richard=20Pruss=20 |Subject:=20Re=3A=20[dhcwg]=20Re=3A=20[Int-area]=20DCHP-based=20authentic ation=20for=20DSL? |Sender:=20; bh=C6qYVIUiP2V5PwMy1cWfSGDzCpvU88iYZ7vArUe7+co=; b=oW+JMVJzBFrVV5ycPoK7Vu0sD5xO4TlVTMaKFI5i6o2yYiT75O0o7ihQbXIweusE6ha+Nxe3 RWcMTAKMy2n1ixPBfYsspnuhUXiUiXkIjb+BBpii2+VulEMmbKWCeBZS; Authentication-Results: sj-dkim-3; header.From=ric@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: dhcwg WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ric@cisco.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi Ted, The message you quote seems to be a what about the clients that do not support a new authentication method. The answer is they work as always with PPPoE. The requirement to remove PPPoE from the DSL architecture is driven by part technical and part emotional reasoning. On the technical side you see a real need to remove the tunnelling aspect of PPPoE so that services (like multicast) can be injected in the layer 2 network. The new services are supported by new equipment and the expectation is that the customer can take the new gear, put in his old credentials and come up on the new services. The DSL networks are very, very large and very slow to migrate and the answer to Iljitsch's comment, they do not move unless they take the new service and the new gear. The whole point of the design is to allow a migration from PPP to DHCP Auth without any touch to the AAA databases or requiring a big flag day for million user networks. Regards, Ric Ted Lemon wrote, around 1/11/07 9:58 AM: > On Oct 29, 2007, at 12:16 AM, Stig Venaas wrote: > > [...] > > At Ralph's request, I've gone back and read the archives for this > discussion. Much learned and useful argument has been presented, > including Stig's most recent objection, which is certainly a good > valid technical objection. > > However, what I have *not* noticed, which I find kind of stunning, is > anybody from the "let's do it" side of the argument answering > Iljitsch's very cogent and telling objection here: > > http://www1.ietf.org/mail-archive/web/int-area/current/msg01014.html > > This objection is a showstopper. If it can't be answered, there is > no chance that this protocol can ever be deployed. All the technical > and procedural objections that have been discussed here are irrelevant > if this one objection can't be answered. > > So I think that before any further discussion on the merits of the > wire protocol go forward, perhaps it would behoove this learned body > to actually address Iljitsch's objection. I must confess that I have > not read every message in the archive, because there are a remarkable > lot of them, so if someone can point me at the place where Iljitsch's > objection was shown to be unnecessary, I would consider it a great favor. > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 02 05:06:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InsPn-00005Q-H5; Fri, 02 Nov 2007 05:02:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InsPm-00005L-R2 for dhcwg@ietf.org; Fri, 02 Nov 2007 05:02:06 -0400 Received: from tyholt.uninett.no ([158.38.62.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InsPf-00062a-Gj for dhcwg@ietf.org; Fri, 02 Nov 2007 05:02:06 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id BD8E02BAF3A; Fri, 2 Nov 2007 09:56:37 +0100 (CET) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01748-01-25; Fri, 2 Nov 2007 09:56:37 +0100 (CET) Received: from [IPv6?2001?700?1?0?215?f2ff?fe35?307d] (sverresborg.uninett.no [IPv6:2001:700:1:0:215:f2ff:fe35:307d]) by tyholt.uninett.no (Postfix) with ESMTP id 6E1432BAF39; Fri, 2 Nov 2007 09:56:37 +0100 (CET) Message-ID: <472AE645.3060503@uninett.no> Date: Fri, 02 Nov 2007 09:56:37 +0100 From: Stig Venaas User-Agent: Thunderbird 2.0.0.6 (X11/20070910) MIME-Version: 1.0 To: Bharat Joshi Subject: Re: [dhcwg] Feedback on Layer 2 Relay Agent functionality References: <31D55C4D55BEED48A4459EB64567589A0960F9D31E@BLRKECMBX02.ad.infosys.com> <46E7B421.4040208@uninett.no> <46FB6618.8050800@uninett.no> <20070927173835.GG30666@isc.org> <31D55C4D55BEED48A4459EB64567589A09E117BC27@BLRKECMBX02.ad.infosys.com> <20071005184727.GE19997@isc.org> <31D55C4D55BEED48A4459EB64567589A09E117BC84@BLRKECMBX02.ad.infosys.com> In-Reply-To: <31D55C4D55BEED48A4459EB64567589A09E117BC84@BLRKECMBX02.ad.infosys.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: "'dhcwg@ietf.org'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Bharat Joshi wrote: > Hi David, > > Thanks for your details response. Please see my response in line. Thanks David for providing some input on this. It's been very quiet from others. I'm wondering how we should proceed with the layer 2 relay agent stuff. I'm thinking perhaps a first step could be an informational document discussing what we mean by a layer-2 relay agent and different ways they may be implemented and relevant issues like what is in the current draft and also what David point out here. Perhaps also some scenarios where layer-2 agents are useful. Thoughts? What do you think Bharat? Stig > > Thanks, > Bharat > >>> I did not get this one. In case of Layer 2 Relay A gent, DHCP client >> will still send DHCP requests as unicast to the DHCP server. Can you >> elaborate on how do we get the illusion of a rebinding in this case? >> >> Server logic uses several hints in the DHCP packets to sense the >> client's state. This may make small, but noticeable, changes in >> server behaviour (such as in the example case, multiple packets >> are transmitted). >> >> One of those of course is the message in question. A discover vs. >> a request helps narrow down greatly wether we're talking about INIT >> or the INIT_REBOOT/SELECTING/RENEWING/REBINDING kitchen sink. >> >> Within the request message specifically however, it's necessary to >> look at other hints to further narrow down the client state. >> >> First, you look at the message type, let's just look at DHCPREQUEST. >> >> If ciaddr is zero, you're looking at INIT_REBOOT or SELECTING. >> >> If the server-identifer is supplied, you're looking at >> SELECTING. >> >> ELSE you're looking at INIT_REBOOT. >> >> ELSE (ciaddr is nonzero) you're looking at RENEWING or REBINDING. >> >> If the packet was unicast you're looking at RENEWING. >> >> ELSE (the packet was broadcast) you're looking at REBINDING. >> >> So how do you sense broadcast vs unicast? >> >> If 'giaddr' is set, you assume the packet to be broadcast. If >> giaddr is not set, then you examine the destination IP address of >> the packet*. >> > > Ok. Now I understand what you meant there. > >> So, if a client in RENEWING sends a packet as described in rfc, and an >> intervening device sets giaddr nonzero, the server will (correctly) >> interpret that to be REBINDING and may use different behaviour than >> might be expected for RENEWING. This is only a problem if you rely >> on the RENEWING server-behaviour for a RENEWING client and are then >> fazed by REBINDING server-behaviour for a RENEWING client. >> >> I described some 'alternate' behaviour recently in regards to >> failover, but conceivably there are other potential, subtle, changes >> in behaviour or processing across different perceived client states. >> > > Ok. > >> Anyway. L2 relay agents usually sniff DHCP packets out of an L2 >> filter, rather than listening at L3. Depending on the filter, they >> may catch unicasts as well as broadcasts, and relay both equally. >> > > Actually AFAIK Layer 2 Relay Agent filter would also need to look at UDP port to intercept DHCP messages. > >> I know of precisely two L2 relay agent implementations. I don't >> think that's a big enough number. :( >> >> They both intercept unicasts and append relay agent options. One sets >> giaddr, the other leaves it clear. I can check my notes if vendor >> names are needed. >> > > Our implementation always used to add 'giaddr' in unicast messages as well. > >> For the first implementation, we had a compatibility issue because >> our failover servers sent multiple responses. I told him he was >> going to have to sleep in the bed he made. That's just what we do. >> >> For the second implementation, we had a compatibility issue because >> we refused to reply with the relay agent information option (so the >> L2 relay lost the info it needed to forward the packet on). We >> changed our server behaviour because I think (even if I disagree >> with the practice of including agent options in unicasts) that the >> relay agent information option RFC does specify this behaviour as >> correct. The implicit assertion that all relays set giaddr is false. >> >> >> * - At least one implementation, for RENEWING/REBINDING clients on >> the local wire, "punts on the issue" because it can not >> differentiate between unicasts and broadcasts. Only where >> giaddr is set can it differentiate a REBINDING...otherwise it >> assumes RENEWING. This has some amusing results in extremely >> contrived circumstances. >> > > Ok. > > As mentioned in my last mail, I think we need to come out with a document that discusses this kind of stuff. I am waiting for more inputs and may be present this in the coming up meeting for getting feedback from working group's participants. > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 02 05:42:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Int0S-0008VM-Dl; Fri, 02 Nov 2007 05:40:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Int0Q-0008UU-UI for dhcwg@ietf.org; Fri, 02 Nov 2007 05:39:58 -0400 Received: from sfovwl03.progeon.com ([216.251.50.9] helo=SFOVWL03.infosys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Int0K-0007BV-LH for dhcwg@ietf.org; Fri, 02 Nov 2007 05:39:58 -0400 Received: from indhubbhs01.ad.infosys.com ([192.168.200.81]) by SFOVWL03.infosys.com with InterScan Message Security Suite; Fri, 02 Nov 2007 02:37:32 -0700 Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Nov 2007 15:08:47 +0530 Received: from [10.10.11.146] (10.66.216.45) by blrkechub01.ad.infosys.com (10.66.236.41) with Microsoft SMTP Server id 8.0.744.0; Fri, 2 Nov 2007 15:08:46 +0530 Subject: Re: [dhcwg] Feedback on Layer 2 Relay Agent functionality From: Bharat Joshi To: Stig Venaas In-Reply-To: <472AE645.3060503@uninett.no> References: <31D55C4D55BEED48A4459EB64567589A0960F9D31E@BLRKECMBX02.ad.infos ys.com> <46E7B421.4040208@uninett.no> <46FB6618.8050800@uninett.no> <20070927173835.GG30666@isc.org> <31D55C4D55B EED48A4459EB64567589A09E117BC27@BLRKECMBX02.ad.infosys.com> <20071005184727 .GE19997@isc.org> <31D55C4D55BEED48A4459EB64567589A09E117BC84@BLRKECMBX02.ad.infosys.com> <472AE645.3060503@uninett.no> Content-Type: text/plain Organization: Infosys Technologies Ltd Date: Fri, 2 Nov 2007 15:04:34 +0530 Message-ID: <1193996074.3306.6.camel@magadha> MIME-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Nov 2007 09:38:47.0315 (UTC) FILETIME=[2AC57E30:01C81D34] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: "'dhcwg@ietf.org'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi Stig, > > Thanks for your details response. Please see my response in line. > > Thanks David for providing some input on this. It's been very quiet from > others. I'm wondering how we should proceed with the layer 2 relay agent > stuff. > Yes. I would also like to thank David for sharing this information. It will really help understanding what people are looking for. > I'm thinking perhaps a first step could be an informational document > discussing what we mean by a layer-2 relay agent and different ways > they may be implemented and relevant issues like what is in the > current draft and also what David point out here. > Yes. It looks like whatever assumption we made in the starting about the general understanding of this domain is not correct. So we will have to go one step back and talk about this in a generic terms. > Perhaps also some scenarios where layer-2 agents are useful. > > Thoughts? What do you think Bharat? > We have already started working on an information document which captures following things: * What a Layer 2 Relay Agent is? Where it fits in and how it works? * Various scenarios where a Layer 2 Relay Agent is used and how DHCP server and Layer 3 Relay Agent behaves in its presence? We are still working on it and I think it should be completed in couple of days. If anyone has any inputs in next couple of days, Please let us know. Thanks & Regards, Bharat > Stig > > > > > Thanks, > > Bharat > > > >>> I did not get this one. In case of Layer 2 Relay A gent, DHCP client > >> will still send DHCP requests as unicast to the DHCP server. Can you > >> elaborate on how do we get the illusion of a rebinding in this case? > >> > >> Server logic uses several hints in the DHCP packets to sense the > >> client's state. This may make small, but noticeable, changes in > >> server behaviour (such as in the example case, multiple packets > >> are transmitted). > >> > >> One of those of course is the message in question. A discover vs. > >> a request helps narrow down greatly wether we're talking about INIT > >> or the INIT_REBOOT/SELECTING/RENEWING/REBINDING kitchen sink. > >> > >> Within the request message specifically however, it's necessary to > >> look at other hints to further narrow down the client state. > >> > >> First, you look at the message type, let's just look at DHCPREQUEST. > >> > >> If ciaddr is zero, you're looking at INIT_REBOOT or SELECTING. > >> > >> If the server-identifer is supplied, you're looking at > >> SELECTING. > >> > >> ELSE you're looking at INIT_REBOOT. > >> > >> ELSE (ciaddr is nonzero) you're looking at RENEWING or REBINDING. > >> > >> If the packet was unicast you're looking at RENEWING. > >> > >> ELSE (the packet was broadcast) you're looking at REBINDING. > >> > >> So how do you sense broadcast vs unicast? > >> > >> If 'giaddr' is set, you assume the packet to be broadcast. If > >> giaddr is not set, then you examine the destination IP address of > >> the packet*. > >> > > > > Ok. Now I understand what you meant there. > > > >> So, if a client in RENEWING sends a packet as described in rfc, and an > >> intervening device sets giaddr nonzero, the server will (correctly) > >> interpret that to be REBINDING and may use different behaviour than > >> might be expected for RENEWING. This is only a problem if you rely > >> on the RENEWING server-behaviour for a RENEWING client and are then > >> fazed by REBINDING server-behaviour for a RENEWING client. > >> > >> I described some 'alternate' behaviour recently in regards to > >> failover, but conceivably there are other potential, subtle, changes > >> in behaviour or processing across different perceived client states. > >> > > > > Ok. > > > >> Anyway. L2 relay agents usually sniff DHCP packets out of an L2 > >> filter, rather than listening at L3. Depending on the filter, they > >> may catch unicasts as well as broadcasts, and relay both equally. > >> > > > > Actually AFAIK Layer 2 Relay Agent filter would also need to look at UDP port to intercept DHCP messages. > > > >> I know of precisely two L2 relay agent implementations. I don't > >> think that's a big enough number. :( > >> > >> They both intercept unicasts and append relay agent options. One sets > >> giaddr, the other leaves it clear. I can check my notes if vendor > >> names are needed. > >> > > > > Our implementation always used to add 'giaddr' in unicast messages as well. > > > >> For the first implementation, we had a compatibility issue because > >> our failover servers sent multiple responses. I told him he was > >> going to have to sleep in the bed he made. That's just what we do. > >> > >> For the second implementation, we had a compatibility issue because > >> we refused to reply with the relay agent information option (so the > >> L2 relay lost the info it needed to forward the packet on). We > >> changed our server behaviour because I think (even if I disagree > >> with the practice of including agent options in unicasts) that the > >> relay agent information option RFC does specify this behaviour as > >> correct. The implicit assertion that all relays set giaddr is false. > >> > >> > >> * - At least one implementation, for RENEWING/REBINDING clients on > >> the local wire, "punts on the issue" because it can not > >> differentiate between unicasts and broadcasts. Only where > >> giaddr is set can it differentiate a REBINDING...otherwise it > >> assumes RENEWING. This has some amusing results in extremely > >> contrived circumstances. > >> > > > > Ok. > > > > As mentioned in my last mail, I think we need to come out with a document that discusses this kind of stuff. I am waiting for more inputs and may be present this in the coming up meeting for getting feedback from working group's participants. > > > > **************** CAUTION - Disclaimer ***************** > > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. > > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 02 08:16:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InvPI-0004t2-4x; Fri, 02 Nov 2007 08:13:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InvPG-0004ph-9c for dhcwg@ietf.org; Fri, 02 Nov 2007 08:13:46 -0400 Received: from kecgate03.progeon.com ([220.227.179.21] helo=Kecgate03.infosys.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InvPF-0004s1-2m for dhcwg@ietf.org; Fri, 02 Nov 2007 08:13:46 -0400 Received: from indhubbhs01.ad.infosys.com ([192.168.200.81]) by Kecgate03.infosys.com with InterScan Message Security Suite; Fri, 02 Nov 2007 17:44:42 +0530 Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Nov 2007 17:43:42 +0530 Received: from BLRKECMBX01.ad.infosys.com ([10.66.236.21]) by blrkechub03.ad.infosys.com ([10.66.236.43]) with mapi; Fri, 2 Nov 2007 17:43:41 +0530 From: pavan_kurapati To: "dhcwg@ietf.org" Date: Fri, 2 Nov 2007 17:43:41 +0530 Subject: RE: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication Thread-Topic: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication Thread-Index: AcgbwQbGwe+0siZSSHi+bgPi+maMqgBhw4qb Message-ID: <7221E17E68B1A944ADCE8A83364DBEE614625EF36D@BLRKECMBX01.ad.infosys.com> References: <95F429B7-CBC0-4DA0-88CA-8CF9E4746A85@cisco.com> In-Reply-To: <95F429B7-CBC0-4DA0-88CA-8CF9E4746A85@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Nov 2007 12:13:42.0383 (UTC) FILETIME=[CF104FF0:01C81D49] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi, I think it is a good idea to extend DHCP for providing subscriber= authentication given that other approaches are more complex. I think most= of the service providers supply their own Residential Gateways and it is= RGs which initiate PPPoE/DHCP. Those who use their modems in plain= bridging mode and rely on 3rd party devices (including PCs and other= routers) may have to continue with PPP for the migration. Coming to the= alternative approaches 1. PANA needs considerable re-work like PANA snooping on DSLAM to install= L2 filters, and PANA support on RG,BNG and also a tweak in the way DHCP= functions. 2. There are some deployments which use 802.1x directly and let the DSLAM= talk to AAA and do the authentication. In this case, RG initiates 802.1x= and DSLAM acts as authenticator. But it is always preferred to have the= authentication done at BRAS than at the DSLAM. So, 802.1x in its current= form may not be suitable for all the service providers offering DSL= service. Ofcourse, if 802.1af is available which enables forwarding 802.1x frames to= BRAS, then this looks more efficient than changing DHCP. It depends on how= long it takes to become a standard. Thanks, Pavan Kurapati ________________________________________ From: Ralph Droms [rdroms@cisco.com] Sent: Wednesday, October 31, 2007 6:43 PM To: dhcwg@ietf.org Subject: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication Second try - still soliciting expert DHCP input (as well as any other input you might care to provide) from dhc WG members... There is a lengthy discussion about rechartering the dhc WG to take on the DHCP authentication proposals in draft-pruss-dhcp-auth- dsl-01.txt and draft-zhao-dhc-user-authentication-02 in the int- area@ietf.org mailing list. Both of these drafts have been submitted for to the WG for review in the past, and neither, to date, has been accepted as a dhc WG work iterm. I've included a copy of the initial posting, http://www1.ietf.org/mail-archive/web/int-area/current/ msg00957.html, below. Because this discussion may lead to the rechartering of the dhc WG to take on either or both of these drafts as new work items, those of you not on the int-area mailing list should consider reviewing the e-mail thread and contributing to the discussion. - Ralph =3D=3D=3D=3D=3D To: Internet Area Subject: [Int-area] DCHP-based authentication for DSL? From: Jari Arkko Date: Thu, 04 Oct 2007 23:22:15 +0300 We talked about the DSL requirements earlier on this list. Now they have sent us a liaison statement regarding what they would like to do: "At this time, we would like to make the IETF aware that during our most recent DSL Forum quarterly meeting, the Architecture and Transport Working Group agreed to seriously consider adopting a mechanism such as that proposed in draft-pruss-dhcp-auth-dsl-01.txt or draft-zhao-dhc-user-authentication-02. We understand that the authors of these specifications intend to produce a combined document soon. The DSL Forum formally requests that the IETF adopt this as a work item, and would appreciate being advised of progress as soon as possible. Our next quarterly meeting is December 10-13, in Lisbon, Portugal." How do we feel about this? Is this a good idea, considering the DSL architecture? How will it affect DHCP the protocol? How would you go about making DHCP extensions so that they work best for all possible environments and not just DSL? Is anyone already working on the combined draft promised above? Are there any other choices that we should recommend instead? I would like to hold the discussion on this in this list until we've determined that the DHCP protocol is the right tool for the job. If it is, we can recharter DHC WG again to add the actual development work there. (DHC is right now being rechartered but that recharting is mostly a cleanup and not the addition of functionality to do this.) Jari _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended= solely for the use of the addressee(s). If you are not the intended= recipient, please notify the sender by e-mail and delete the original= message. Further, you are not to copy, disclose, or distribute this e-mail= or its contents to any other person and any such actions are unlawful.= This e-mail may contain viruses. Infosys has taken every reasonable= precaution to minimize this risk, but is not liable for any damage you may= sustain as a result of any virus in this e-mail. You should carry out your= own virus checks before opening the e-mail or attachment. Infosys reserves= the right to monitor and review the content of all messages sent to or= from this e-mail address. Messages sent to or from this e-mail address may= be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 02 08:51:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InvzK-0002W3-Ek; Fri, 02 Nov 2007 08:51:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InvzJ-0002VZ-ML for dhcwg@ietf.org; Fri, 02 Nov 2007 08:51:01 -0400 Received: from mout.perfora.net ([74.208.4.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InvzD-0004j7-EP for dhcwg@ietf.org; Fri, 02 Nov 2007 08:51:01 -0400 Received: from IBM52A5038A94F ([88.233.212.1]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1Invys46az-0005zR; Fri, 02 Nov 2007 08:50:38 -0400 From: "Alper Yegin" To: "'pavan_kurapati'" , Subject: RE: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication Date: Fri, 2 Nov 2007 14:50:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <7221E17E68B1A944ADCE8A83364DBEE614625EF36D@BLRKECMBX01.ad.infosys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgbwQbGwe+0siZSSHi+bgPi+maMqgBhw4qbAAF8ktA= Message-Id: <0MKp8S-1Invys46az-0005zR@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19u13hBLuVGCqfZVRPfxvzi1Ikp3XnLQAkMnSZ sN18SiNcsW2bO+GiB+82SWjSOdEQxMa8Yjl9fwR/H5ncCnlvyZ DVFD0gujwil13pWAlPZBw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi, > 1. PANA needs considerable re-work like PANA snooping on DSLAM to install > L2 filters, How is setting up a different filter on the devices that already know how to setup filters considered a "considerable re-work"? I'd appreciate if you can tell us how this is anything more than simply setting up a filter rule. > and PANA support on RG,BNG I hope you are aware that what appears like saving PANA implementation on RG and BNG are in fact coming back in the form of DHCP growing PANA from within -- with all the problems associated with that unfortunate merger. > and also a tweak in the way DHCP > functions. Please explain this one. I'm not sure what you are referring to. Thanks. Alper _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 02 12:00:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inytg-0002cr-SL; Fri, 02 Nov 2007 11:57:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inytf-0002c7-Ls for dhcwg@ietf.org; Fri, 02 Nov 2007 11:57:23 -0400 Received: from goliath.isc.org ([204.152.187.72]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Inytf-0003Wd-AK for dhcwg@ietf.org; Fri, 02 Nov 2007 11:57:23 -0400 Received: by goliath.isc.org (Postfix, from userid 10200) id 099C95A6EC; Fri, 2 Nov 2007 08:57:21 -0700 (PDT) Date: Fri, 2 Nov 2007 08:57:21 -0700 From: "David W. Hankins" To: DHC WG Subject: Re: [dhcwg] Feedback on Layer 2 Relay Agent functionality Message-ID: <20071102155721.GA3749@isc.org> References: <31D55C4D55BEED48A4459EB64567589A0960F9D31E@BLRKECMBX02.ad.infosys.com> <46E7B421.4040208@uninett.no> <46FB6618.8050800@uninett.no> <20070927173835.GG30666@isc.org> <31D55C4D55BEED48A4459EB64567589A09E117BC27@BLRKECMBX02.ad.infosys.com> <20071005184727.GE19997@isc.org> <31D55C4D55BEED48A4459EB64567589A09E117BC84@BLRKECMBX02.ad.infosys.com> <472AE645.3060503@uninett.no> Mime-Version: 1.0 In-Reply-To: <472AE645.3060503@uninett.no> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1325855286==" Errors-To: dhcwg-bounces@ietf.org --===============1325855286== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 02, 2007 at 09:56:37AM +0100, Stig Venaas wrote: > Thanks David for providing some input on this. It's been very quiet from > others. I'm wondering how we should proceed with the layer 2 relay agent > stuff. I'm somewhat concerned about this as well, I'd like to see some comment from other server implementors. If they've seen more issues than I have, the same issues, or no issues at all, that's all useful information. > I'm thinking perhaps a first step could be an informational document > discussing what we mean by a layer-2 relay agent and different ways > they may be implemented and relevant issues like what is in the > current draft and also what David point out here. I think that's an excellent idea, 'documenting existing operational practices,' which really helps frame new work in this area. I just want to add that this is more work for *someone*, by which I mean not me...I just have too much on my plate right now to do more than read and review. So I'm happy to accept whatever work in this area as can find willing authors. :) --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHK0jhcXeLeWu2vmoRAnOcAKCl8MgmtIAejE6sKKiugXTETEk7YgCeNyKv g1VNgnePbLtIyFnzrevlQJU= =Od3x -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- --===============1325855286== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1325855286==-- From dhcwg-bounces@ietf.org Sun Nov 04 23:47:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IotsJ-0007xd-Ot; Sun, 04 Nov 2007 23:47:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IotsI-0007wQ-I0 for dhcwg@ietf.org; Sun, 04 Nov 2007 23:47:46 -0500 Received: from kecgate03.progeon.com ([220.227.179.21] helo=Kecgate03.infosys.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IotsH-0002k6-IT for dhcwg@ietf.org; Sun, 04 Nov 2007 23:47:46 -0500 Received: from indhubbhs04.ad.infosys.com ([192.168.200.84]) by Kecgate03.infosys.com with InterScan Message Security Suite; Mon, 05 Nov 2007 10:17:18 +0530 Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by indhubbhs04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Nov 2007 10:16:14 +0530 Received: from BLRKECMBX01.ad.infosys.com ([10.66.236.21]) by blrkechub03.ad.infosys.com ([10.66.236.43]) with mapi; Mon, 5 Nov 2007 10:16:14 +0530 From: pavan_kurapati To: Alper Yegin , "dhcwg@ietf.org" Date: Mon, 5 Nov 2007 10:16:13 +0530 Subject: RE: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication Thread-Topic: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication Thread-Index: AcgbwQbGwe+0siZSSHi+bgPi+maMqgBhw4qbAAF8ktAAhfY+TA== Message-ID: <7221E17E68B1A944ADCE8A83364DBEE614625EF372@BLRKECMBX01.ad.infosys.com> References: <7221E17E68B1A944ADCE8A83364DBEE614625EF36D@BLRKECMBX01.ad.info sys.com>,<0MKp8S-1Invys46az-0005zR@mrelay.perfora.net> In-Reply-To: <0MKp8S-1Invys46az-0005zR@mrelay.perfora.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Nov 2007 04:46:14.0351 (UTC) FILETIME=[CBA0FDF0:01C81F66] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi Alper, Please find replies inline Thanks, Pavan ________________________________________ From: Alper Yegin [alper.yegin@yegin.org] Sent: Friday, November 02, 2007 6:20 PM To: pavan_kurapati; dhcwg@ietf.org Subject: RE: [dhcwg] Discussion of dhc WG rechartering for DHCP = authentication Hi, >> 1. PANA needs considerable re-work like PANA snooping on DSLAM to= install >> L2 filters, >How is setting up a different filter on the devices that already know how= to >setup filters considered a "considerable re-work"? I'd appreciate if you= can >tell us how this is anything more than simply setting up a filter rule. I was talking about introducing another element in DSLAMs to apply filters= (IP/MAC) based on PANA in addition to what it does by doing DHCP snooping.= I am not saying that it is not doable. I am just saying that it is an= additional work whereas there is no change required in case of DHCP based= solution. >> and PANA support on RG,BNG >I hope you are aware that what appears like saving PANA implementation on= RG >and BNG are in fact coming back in the form of DHCP growing PANA from= within >-- with all the problems associated with that unfortunate merger. >> and also a tweak in the way DHCP >> functions. >Please explain this one. I'm not sure what you are referring to. After receiving DHCP offer, the client takes the offered IP address and PAA= address and initiate PANA (instead of doing traditional Request/Ack= process and then make use of the IP address). This is one tweak. And then= based on PANA result you restart the DHCP Discover process and take the= other IP address. So, isnt there a change in the way DHCP is done? Thanks. Alper **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended= solely for the use of the addressee(s). If you are not the intended= recipient, please notify the sender by e-mail and delete the original= message. Further, you are not to copy, disclose, or distribute this e-mail= or its contents to any other person and any such actions are unlawful.= This e-mail may contain viruses. Infosys has taken every reasonable= precaution to minimize this risk, but is not liable for any damage you may= sustain as a result of any virus in this e-mail. You should carry out your= own virus checks before opening the e-mail or attachment. Infosys reserves= the right to monitor and review the content of all messages sent to or= from this e-mail address. Messages sent to or from this e-mail address may= be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 05 00:22:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IouQD-000420-J1; Mon, 05 Nov 2007 00:22:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IouQC-0003zK-Rb for dhcwg@ietf.org; Mon, 05 Nov 2007 00:22:48 -0500 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IouQC-0003cM-9Q for dhcwg@ietf.org; Mon, 05 Nov 2007 00:22:48 -0500 Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by syd-iport-1.cisco.com with ESMTP; 05 Nov 2007 16:16:55 +1100 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA55Gr7B010841; Mon, 5 Nov 2007 13:16:53 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA55D3NP020290; Mon, 5 Nov 2007 05:16:53 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 13:15:39 +0800 Received: from syd-rpruss-vpn1.cisco.com ([10.67.195.18]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 13:15:39 +0800 Message-ID: <472EA6FA.40602@cisco.com> Date: Mon, 05 Nov 2007 15:15:38 +1000 From: Richard Pruss Organization: Cisco Systems User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Alper Yegin Subject: Re: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication References: <0MKp8S-1Invys46az-0005zR@mrelay.perfora.net> In-Reply-To: <0MKp8S-1Invys46az-0005zR@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2007 05:15:39.0322 (UTC) FILETIME=[E7A231A0:01C81F6A] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15522.000 X-TM-AS-Result: No--8.170200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1532; t=1194239813; x=1195103813; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ric@cisco.com; z=From:=20Richard=20Pruss=20 |Subject:=20Re=3A=20[dhcwg]=20Discussion=20of=20dhc=20WG=20rechartering=2 0for=20DHCP=20authentication |Sender:=20; bh=fLCqGuJ11p6IkucWgIZZQd6Umfopgq/xDEwQ/B6RdmQ=; b=EB8clepe+nknFBQgXlq1EFgKTfj8tCh8Sr+94T7dxaZ2g3oO2yiJHY/Mw6mqDsjK5lUcBB++ hePVIAu/IF/JT14JEUqsKf8FWPtpkUeY1mBVFDmBF8xmsdlSjEBXP7N5Bt4jCaYhkuy8Bxvx9L nAi4MJXwJlJSZL6pStUoiPcNI=; Authentication-Results: hkg-dkim-2; header.From=ric@cisco.com; dkim=pass (si g from cisco.com/hkgdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ric@cisco.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Alper Yegin wrote, around 2/11/07 10:50 PM: > How is setting up a different filter on the devices that already know how to > setup filters considered a "considerable re-work"? I'd appreciate if you can > tell us how this is anything more than simply setting up a filter rule. > The devices currently install these filters based on DHCP snooping. In our proposal current architecture use of the DHCP ack will still trigger drive the source address verification on the first network hop, exactly as they do today. With PANA, these devices which are the whole of the transmission edge would all need to get a new PANA snooping enabled code base, with all the filtering use cases around that. New ideas like authenticated and unauthenticated IP addresses and policy for those need to be hooked to new filters that operate on IP streams. A snooping version of PANA or some sort of PANA grafting to a policy distribution mechanisms. That more new stuff than I care to count can charitably called "considerable re-work", more it should be pretty obvious from ethernet security is not the application for PANA. This application is deeply entwined with layer 2, PANA is clearly aimed at IP authentication and is not a layer 2 or in the DHCP Auth case layer 2.5 application. I wonder why you keep driving this square peg into a round hole. The first entry of the PANA FAQ is that PANA is layer 2 agnostic and you seem determined to undo that. http://www.toshiba.com/tari/pana/pana-faq.txt - Ric _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 05 07:54:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip1TB-00067Y-Tc; Mon, 05 Nov 2007 07:54:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip1TA-000669-I6 for dhcwg@ietf.org; Mon, 05 Nov 2007 07:54:20 -0500 Received: from nz-out-0506.google.com ([64.233.162.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip1T9-0005os-C8 for dhcwg@ietf.org; Mon, 05 Nov 2007 07:54:20 -0500 Received: by nz-out-0506.google.com with SMTP id n1so967187nzf for ; Mon, 05 Nov 2007 04:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=9Z7EypIgzl0Gp8lIBCE05CZXfYrBdgcif9RzUhUe4Ao=; b=KzQnowv9E6sYUVZ2vMxPMriMeOJ98rqfYWfoqtFpmmFqqmw/zaYg4Ns5j9uI23H+hwNhnPSuDxmW++QitZ1RRTNasRjI6K1cEq/F3Q9NmHAZ290xenjV1wQ7+zH19/HlXmyFm4MuU7sGFkXfUkOmVuKBDN9+bv6AsNE6CMQ2og4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=k7wId8K/FjZjc7NE9Nmyf+KTlIwW92PYfOY4PbxYM4D7FtMiM1y4WtIAKXD+Wgm56VEAPb4fePBRmkgiZ6nS5Hypc7LaJNA7wyohVwa2NuWuHn3zovNZPA2UJ0jmsu0z+7pVvNcuh1YSvRDp6lWIdU2TBCA5kLS/r8+YciAoneY= Received: by 10.114.126.1 with SMTP id y1mr5103801wac.1194267257619; Mon, 05 Nov 2007 04:54:17 -0800 (PST) Received: by 10.114.193.3 with HTTP; Mon, 5 Nov 2007 04:54:17 -0800 (PST) Message-ID: Date: Mon, 5 Nov 2007 18:24:17 +0530 From: "ravi kumar" To: dhcwg@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [dhcwg] Clarification in RFC 3633 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2056211731==" Errors-To: dhcwg-bounces@ietf.org --===============2056211731== Content-Type: multipart/alternative; boundary="----=_Part_15309_27088971.1194267257616" ------=_Part_15309_27088971.1194267257616 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I would like to clarify, if the following scenario is valid, as per RFC 3633: 1) DHCP Server responds with "x" prefixes, in reponse to Client REQUEST message. 2) The client sends RENEW message, with "x" prefixes in IAPD option. 3) Then Server responds with "y" prefixes( where "y" > "x"), in the REPLY message. Should client accept the REPLY message from Server, as valid REPLY message or Not? regards Rav i ------=_Part_15309_27088971.1194267257616 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I would like to clarify, if the following scenario is valid, as per RFC 3633:
 
1) DHCP Server responds with "x" prefixes, in reponse to Client REQUEST message.
2) The client sends RENEW message, with "x" prefixes in IAPD option.
3) Then Server responds with "y" prefixes( where "y" > "x"), in the REPLY message.
 
Should client accept the REPLY message from Server, as valid REPLY message or Not? 
 
regards
Rav i
 
------=_Part_15309_27088971.1194267257616-- --===============2056211731== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============2056211731==-- From dhcwg-bounces@ietf.org Mon Nov 05 08:01:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip1aB-0005IF-BN; Mon, 05 Nov 2007 08:01:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip1a9-0005FP-HN for dhcwg@ietf.org; Mon, 05 Nov 2007 08:01:33 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip1a8-0005yA-At for dhcwg@ietf.org; Mon, 05 Nov 2007 08:01:33 -0500 X-IronPort-AV: E=Sophos;i="4.21,372,1188802800"; d="scan'208";a="246825831" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-6.cisco.com with ESMTP; 05 Nov 2007 05:01:30 -0800 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA5D1UQC022576; Mon, 5 Nov 2007 14:01:30 +0100 Received: from gpk-xdm-001.cisco.com (gpk-xdm-001.cisco.com [64.103.70.176]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA5D1TqT013046; Mon, 5 Nov 2007 13:01:29 GMT Received: from gpk-xdm-001.cisco.com (localhost.localdomain [127.0.0.1]) by gpk-xdm-001.cisco.com (8.13.1/8.13.1) with ESMTP id lA5D1TJN001108; Mon, 5 Nov 2007 13:01:29 GMT Received: (from otroan@localhost) by gpk-xdm-001.cisco.com (8.13.1/8.13.1/Submit) id lA5D1T84001107; Mon, 5 Nov 2007 13:01:29 GMT X-Authentication-Warning: gpk-xdm-001.cisco.com: otroan set sender to ot@cisco.com using -f From: Ole Troan To: "ravi kumar" Subject: Re: [dhcwg] Clarification in RFC 3633 References: Date: Mon, 05 Nov 2007 13:01:29 +0000 In-Reply-To: (ravi kumar's message of "Mon\, 5 Nov 2007 18\:24\:17 +0530") Message-ID: <7t5hck0onh2.fsf@gpk-xdm-001.cisco.com> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=474; t=1194267690; x=1195131690; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ot@cisco.com; z=From:=20Ole=20Troan=20 |Subject:=20Re=3A=20[dhcwg]=20Clarification=20in=20RFC=203633 |Sender:=20; bh=nHgGXE/6qagDDpHbNTnt06/CuiUogMxyXuXzQjlLzQM=; b=hoOBsNUYw36Q46h56pH4vHv/G+BRFHxjfQdAJ8TJovkngZnF3klzt065fEIwPz4JHTKaR/LL te1BeI+u3lK8TuUucpj8BK6z8Hik+fNcqIiR2WtnjT71d2tqFRGj4Ntm; Authentication-Results: ams-dkim-1; header.From=ot@cisco.com; dkim=pass (sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > I would like to clarify, if the following scenario is valid, as per RFC > 3633: > > 1) DHCP Server responds with "x" prefixes, in reponse to Client REQUEST > message. > 2) The client sends RENEW message, with "x" prefixes in IAPD option. > 3) Then Server responds with "y" prefixes( where "y" > "x"), in the REPLY > message. > > Should client accept the REPLY message from Server, as valid REPLY message > or Not? yes. this is how you do renumbering. /ot _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 05 08:27:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip1zV-0008GL-MF; Mon, 05 Nov 2007 08:27:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip1zT-0008G5-Vb for dhcwg@ietf.org; Mon, 05 Nov 2007 08:27:43 -0500 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip1zS-0006eU-N8 for dhcwg@ietf.org; Mon, 05 Nov 2007 08:27:43 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1337406rvb for ; Mon, 05 Nov 2007 05:27:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=COdWbRoVQlNmx0l+jcPr6HkkLTRJyIZKhvgU+nvjOOg=; b=th3Uh8x0EWCyQmz2bcCtJLE3o3OYFL7vPhwcdxsys/A2M9NS7tR1NqetxzYy0msj0lmxVPJPgPYAK1jIXRbCFU+NnJjj0gNl3xfHo1j6+VlSdcg2BLn8+HFdmaUg8rO9wLdO6Garqc4gwPkYhoQDY4LyvXa4baoVV2H8+8cQ64w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=r737rrRJbOFM+JeZB97OOntg0MHPWRU/Ebf8Df/c7N5jwZoQuSkIfRIVzPWj7GhX3nZSZ8R8q6HCZehIirMLxZuIqgkInR3SpbUw//1MYQFiIkCcyd9aMKpdM+I4ZRDV5C7sfZrws1Ri0uzJTvlQxHzuSj3ZOirz793sZ39YrIw= Received: by 10.114.73.1 with SMTP id v1mr5143169waa.1194269260026; Mon, 05 Nov 2007 05:27:40 -0800 (PST) Received: by 10.114.193.3 with HTTP; Mon, 5 Nov 2007 05:27:39 -0800 (PST) Message-ID: Date: Mon, 5 Nov 2007 18:57:39 +0530 From: "ravi kumar" To: "Ole Troan" Subject: Re: [dhcwg] Clarification in RFC 3633 In-Reply-To: <7t5hck0onh2.fsf@gpk-xdm-001.cisco.com> MIME-Version: 1.0 References: <7t5hck0onh2.fsf@gpk-xdm-001.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0321531768==" Errors-To: dhcwg-bounces@ietf.org --===============0321531768== Content-Type: multipart/alternative; boundary="----=_Part_15416_685138.1194269259751" ------=_Part_15416_685138.1194269259751 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for the reply. So in that case, The client should also accept the newly added prefixes in RENEW message. Am I right? regards Ravi On 11/5/07, Ole Troan wrote: > > > I would like to clarify, if the following scenario is valid, as per RFC > > 3633: > > > > 1) DHCP Server responds with "x" prefixes, in reponse to Client REQUEST > > message. > > 2) The client sends RENEW message, with "x" prefixes in IAPD option. > > 3) Then Server responds with "y" prefixes( where "y" > "x"), in the > REPLY > > message. > > > > Should client accept the REPLY message from Server, as valid REPLY > message > > or Not? > > yes. this is how you do renumbering. > > /ot > ------=_Part_15416_685138.1194269259751 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Thanks for the reply.
So in that case, The client should also accept the newly added prefixes in RENEW message. Am I right?
 
regards
Ravi
 
On 11/5/07, Ole Troan <ot@cisco.com> wrote:
> I would like to clarify, if the following scenario is valid, as per RFC
> 3633:
>
> 1) DHCP Server responds with "x" prefixes, in reponse to Client REQUEST
> message.
> 2) The client sends RENEW message, with "x" prefixes in IAPD option.
> 3) Then Server responds with "y" prefixes( where "y" > "x"), in the REPLY
> message.
>
> Should client accept the REPLY message from Server, as valid REPLY message
> or Not?

yes. this is how you do renumbering.

/ot

------=_Part_15416_685138.1194269259751-- --===============0321531768== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0321531768==-- From dhcwg-bounces@ietf.org Mon Nov 05 08:49:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2KT-0002YL-CB; Mon, 05 Nov 2007 08:49:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2KS-0002Vo-Cm for dhcwg@ietf.org; Mon, 05 Nov 2007 08:49:24 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip2KR-0007CB-6R for dhcwg@ietf.org; Mon, 05 Nov 2007 08:49:24 -0500 X-IronPort-AV: E=Sophos;i="4.21,372,1188802800"; d="scan'208";a="246846865" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-6.cisco.com with ESMTP; 05 Nov 2007 05:49:21 -0800 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA5DnLbA007547; Mon, 5 Nov 2007 14:49:21 +0100 Received: from gpk-xdm-001.cisco.com (gpk-xdm-001.cisco.com [64.103.70.176]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA5DnIqT003471; Mon, 5 Nov 2007 13:49:19 GMT Received: from gpk-xdm-001.cisco.com (localhost.localdomain [127.0.0.1]) by gpk-xdm-001.cisco.com (8.13.1/8.13.1) with ESMTP id lA5DnIiw006994; Mon, 5 Nov 2007 13:49:18 GMT Received: (from otroan@localhost) by gpk-xdm-001.cisco.com (8.13.1/8.13.1/Submit) id lA5DnGC8006992; Mon, 5 Nov 2007 13:49:16 GMT X-Authentication-Warning: gpk-xdm-001.cisco.com: otroan set sender to ot@cisco.com using -f From: Ole Troan To: "ravi kumar" Subject: Re: [dhcwg] Clarification in RFC 3633 References: <7t5hck0onh2.fsf@gpk-xdm-001.cisco.com> Date: Mon, 05 Nov 2007 13:49:16 +0000 In-Reply-To: (ravi kumar's message of "Mon\, 5 Nov 2007 18\:57\:39 +0530") Message-ID: <7t5d4uool9f.fsf@gpk-xdm-001.cisco.com> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=903; t=1194270561; x=1195134561; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ot@cisco.com; z=From:=20Ole=20Troan=20 |Subject:=20Re=3A=20[dhcwg]=20Clarification=20in=20RFC=203633 |Sender:=20; bh=6t3Hm2rTzzG5NVaVChFDt+pAesclC8LLhjjcMcDGNJc=; b=JVw/+eHwPDQYGNP0k9ZEqfFWJO0zgBd4kQAfDhzAz1J8KuzkDnX9ra57VO5clGHT5EKiuJ52 yskken8u4BB4YcSzkUV78Kx9Kkkm90Ob9pL9tJjg0/Hw8wwQqvOboAdE; Authentication-Results: ams-dkim-1; header.From=ot@cisco.com; dkim=pass (sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > So in that case, The client should also accept the newly added > prefixes in RENEW message. Am I right? I don't understand what you mean by a client accepting prefixes in a RENEW message. if you mean that the client includes the new set of prefixes in a subsequent RENEW message, then that is correct. /ot > On 11/5/07, Ole Troan wrote: >> >> > I would like to clarify, if the following scenario is valid, as per RFC >> > 3633: >> > >> > 1) DHCP Server responds with "x" prefixes, in reponse to Client REQUEST >> > message. >> > 2) The client sends RENEW message, with "x" prefixes in IAPD option. >> > 3) Then Server responds with "y" prefixes( where "y" > "x"), in the >> REPLY >> > message. >> > >> > Should client accept the REPLY message from Server, as valid REPLY >> message >> > or Not? >> >> yes. this is how you do renumbering. >> >> /ot >> _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 05 14:19:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip7U2-0001QS-Fg; Mon, 05 Nov 2007 14:19:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip7U1-0001PS-2F for dhcwg@ietf.org; Mon, 05 Nov 2007 14:19:37 -0500 Received: from mout.perfora.net ([74.208.4.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip7Tz-00084Y-ET for dhcwg@ietf.org; Mon, 05 Nov 2007 14:19:37 -0500 Received: from IBM52A5038A94F ([88.233.35.72]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Ip7Tp4AID-0008VV; Mon, 05 Nov 2007 14:19:31 -0500 From: "Alper Yegin" To: "'pavan_kurapati'" , Subject: RE: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication Date: Mon, 5 Nov 2007 21:19:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcgbwQbGwe+0siZSSHi+bgPi+maMqgBhw4qbAAF8ktAAhfY+TAAb8O0w In-Reply-To: <7221E17E68B1A944ADCE8A83364DBEE614625EF372@BLRKECMBX01.ad.infosys.com> Message-Id: <0MKpCa-1Ip7Tp4AID-0008VV@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX185cnbiYyaInmJC5feVZpB6dFZzUwqkNOLiqP7 6Rt3bBx41PNy/J/Y7VeWwbXl9qzLqaV1y+Gyr1RbQX6pOJStF4 xkvzZ8CRgRKbp2wZ4XC9A== X-Spam-Score: -0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi Pavan, > >> 1. PANA needs considerable re-work like PANA snooping on DSLAM to > install > >> L2 filters, > > >How is setting up a different filter on the devices that already know how > to > >setup filters considered a "considerable re-work"? I'd appreciate if you > can > >tell us how this is anything more than simply setting up a filter rule. > > I was talking about introducing another element in DSLAMs to apply filters > (IP/MAC) based on PANA in addition to what it does by doing DHCP snooping. > I am not saying that it is not doable. I am just saying that it is an > additional work whereas there is no change required in case of DHCP based > solution. "Additional work" seems a fair statement, not the "considerable re-work" that you used before. > > >> and PANA support on RG,BNG > > >I hope you are aware that what appears like saving PANA implementation on > RG > >and BNG are in fact coming back in the form of DHCP growing PANA from > within > >-- with all the problems associated with that unfortunate merger. > > >> and also a tweak in the way DHCP > >> functions. > > >Please explain this one. I'm not sure what you are referring to. > > After receiving DHCP offer, the client takes the offered IP address and > PAA address and initiate PANA (instead of doing traditional Request/Ack > process and then make use of the IP address). This is one tweak. And then > based on PANA result you restart the DHCP Discover process and take the > other IP address. So, isnt there a change in the way DHCP is done? I guess you are considering a call flow where a temporary IP address is assigned using DHCP, instead of configuring a link-local IP address. OK, even in that case, I don't see why you stop short of completing the full DHCP for pre-PANA address. You can either do: 1. CPE configures a link-local address 2. CPE discovers PAA (via DHCP or some other mechanism) 3. CPE runs PANA 4. CPE configures "session IP address" using DHCP Or, 1. CPE configures a pre-PANA IP address using DHCP 2. CPE runs PANA 3. CPE configures "session IP address" using DHCP I cannot think of why you'd need a tweak for DHCP. Alper > > Thanks. > > Alper > > > > > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > solely for the use of the addressee(s). If you are not the intended > recipient, please notify the sender by e-mail and delete the original > message. Further, you are not to copy, disclose, or distribute this e-mail > or its contents to any other person and any such actions are unlawful. > This e-mail may contain viruses. Infosys has taken every reasonable > precaution to minimize this risk, but is not liable for any damage you may > sustain as a result of any virus in this e-mail. You should carry out your > own virus checks before opening the e-mail or attachment. Infosys reserves > the right to monitor and review the content of all messages sent to or > from this e-mail address. Messages sent to or from this e-mail address may > be stored on the Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 05 16:26:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip9Sp-0003B3-HZ; Mon, 05 Nov 2007 16:26:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip9So-0003AX-Jn for dhcwg@ietf.org; Mon, 05 Nov 2007 16:26:30 -0500 Received: from mout.perfora.net ([74.208.4.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip9Sn-00030B-9L for dhcwg@ietf.org; Mon, 05 Nov 2007 16:26:30 -0500 Received: from IBM52A5038A94F ([88.233.35.72]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Ip9SL0XM2-0008Qo; Mon, 05 Nov 2007 16:26:20 -0500 From: "Alper Yegin" To: Subject: RE: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication Date: Mon, 5 Nov 2007 23:25:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcgfZAwVwSZ1oUZNTliIY1r0LrFM6QAihF4w In-Reply-To: <472E9B72.9090104@cisco.com> Message-Id: <0MKpCa-1Ip9SL0XM2-0008Qo@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/B2lZlxHM9GGoK7K4h/bKDumP3PC2yRhlmE7v K9vPxcPCR9B7uxacZH1986ZyjOdbdzOXPn9ewDh02ctF+fnG8Q i1GpupS9P0L7MwX6Mm0Kw== X-Spam-Score: -0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > > How is setting up a different filter on the devices that already know > how to > > setup filters considered a "considerable re-work"? I'd appreciate if you > can > > tell us how this is anything more than simply setting up a filter rule. > > > The devices currently install these filters based on DHCP snooping. In > our proposal current architecture use of the DHCP ack will still trigger > drive the source address verification on the first network hop, exactly > as they do today. > > With PANA, these devices which are the whole of the transmission edge > would all need to get a new PANA snooping enabled code base, with all > the filtering use cases around that. If we run PANA with link-local IP address, then we can still utilize DHCP snooping as usual. > New ideas like authenticated and > unauthenticated IP addresses and policy for those need to be hooked to > new filters that operate on IP streams. Not sure how difficult that is, but note that you need that even for your DHCP solution when running DHCPv6 -- the link-local address is already configured on the CPE before executing DHCP. > A snooping version of PANA or What does "a snooping version of PANA" mean? > some sort of PANA grafting to a policy distribution mechanisms. Not sure I understand this either. Could you please explain? > That more new stuff than I care to count can charitably called > "considerable re-work", more it should be pretty obvious from this is > not the application for PANA. Have you read RFC 4058? DSL networks are a specific example where PANA has the potential for addressing some of the deployment scenarios. Some DSL deployments do not use PPP [RFC1661] as the access link-layer (IP is carried over ATM and the subscriber device is either statically or DHCP- configured). The operators of these networks are left either using an application-layer web-based login (captive portal) scheme for subscriber authentication, or providing a best-effort service only as they cannot perform subscriber authentication required for the differentiated services. The captive portal scheme is a non-standard solution that has various limitations and security flaws. PPP-less DSL networks have been one of the deployment scenarios we had identified from the very beginning. So it is not an afterthought. > This application is deeply entwined with > layer 2, PANA is clearly aimed at IP authentication and is not a layer 2 > or in the DHCP Auth case layer 2.5 application. > > I wonder why you keep driving this square peg into a round hole. The > first entry of the PANA FAQ is that PANA is layer 2 agnostic and you > seem determined to undo that. > http://www.toshiba.com/tari/pana/pana-faq.txt There is no need to confuse things. PANA is not dependent on a specific L2 because it carries EAP above IP. How is that a mismatch with the problem DSLF is facing? Alper _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 05 20:51:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpDb6-0005tJ-83; Mon, 05 Nov 2007 20:51:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpDb4-0005s0-5b; Mon, 05 Nov 2007 20:51:18 -0500 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpDb3-0004Zl-MG; Mon, 05 Nov 2007 20:51:18 -0500 Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by syd-iport-1.cisco.com with ESMTP; 06 Nov 2007 12:51:15 +1100 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA61pEsg017537; Tue, 6 Nov 2007 09:51:14 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA61pARP027936; Tue, 6 Nov 2007 01:51:11 GMT Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 09:50:24 +0800 Received: from syd-rpruss-vpn1.cisco.com ([10.67.195.18]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 09:50:23 +0800 Message-ID: <472FC860.6000104@cisco.com> Date: Tue, 06 Nov 2007 11:50:24 +1000 From: Richard Pruss Organization: Cisco Systems User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Alper Yegin Subject: Re: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication References: <0MKpCa-1Ip7Tp4AID-0008VV@mrelay.perfora.net> In-Reply-To: <0MKpCa-1Ip7Tp4AID-0008VV@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2007 01:50:23.0616 (UTC) FILETIME=[65505800:01C82017] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15528.000 X-TM-AS-Result: No--7.175900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=742; t=1194313874; x=1195177874; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ric@cisco.com; z=From:=20Richard=20Pruss=20 |Subject:=20Re=3A=20[dhcwg]=20Discussion=20of=20dhc=20WG=20rechartering=2 0for=20DHCP=20authentication |Sender:=20; bh=Hjq2o1zJ8SqpBQyd7fQhuDN2UxdSIpp58AJCavwPe7s=; b=Mv9v/JLAYYXKYgcMmJS0vNYfAzSk52Jy8ld2spB29buGjXq1hJgNDY2lQnB/yQRPcAnPrzue yr1Iib7UG8RQHC5r3h4YHYNWbys8JY3NsCyfPc0S3AON+kub0WjxtG7cK+XiKRo2MpG6mRYOmt s5PwnESGsKdFerYzHoVBv3Kno=; Authentication-Results: hkg-dkim-2; header.From=ric@cisco.com; dkim=pass (si g from cisco.com/hkgdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: dhcwg@ietf.org, int-area@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ric@cisco.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Should this conversation not move to the int-area? Alper Yegin wrote, around 6/11/07 5:19 AM: > 1. CPE configures a pre-PANA IP address using DHCP > 2. CPE runs PANA > 3. CPE configures "session IP address" using DHCP > > The PANA idea if using short lease/long lease DHCP address switching in DSL deployments is simply not feasible. BRAS's with over 60K subscribers are common and many providers have central city pops of more than a million subscribers. During a pop restart the 60 second lease on a million subscribers would at best result in a sustained load of more than 16000 DHCP requests / second smashing through the relays and into the DHCP servers until the users had gradually authenticated. - Ric _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 05 21:38:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpEKY-00073X-1e; Mon, 05 Nov 2007 21:38:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpEKW-00071i-33; Mon, 05 Nov 2007 21:38:16 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpEKS-0003lX-NJ; Mon, 05 Nov 2007 21:38:16 -0500 X-IronPort-AV: E=Sophos;i="4.21,375,1188802800"; d="scan'208";a="247202071" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 05 Nov 2007 18:38:11 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA62cB1F003719; Mon, 5 Nov 2007 21:38:11 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA62cAg8009747; Tue, 6 Nov 2007 02:38:11 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 21:37:31 -0500 Received: from [192.168.1.102] ([10.86.242.65]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 21:37:30 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <472FC860.6000104@cisco.com> References: <0MKpCa-1Ip7Tp4AID-0008VV@mrelay.perfora.net> <472FC860.6000104@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D9309C4-247F-4751-BFDC-00CCEB9367E7@cisco.com> Content-Transfer-Encoding: 7bit From: Ralph Droms Subject: Re: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication Date: Mon, 5 Nov 2007 21:37:28 -0500 To: Internet Area , dhcwg@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 06 Nov 2007 02:37:30.0775 (UTC) FILETIME=[FA6E9270:01C8201D] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15522.000 X-TM-AS-Result: No--16.283600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1092; t=1194316691; x=1195180691; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20Discussion=20of=20dhc=20WG=20rechartering=2 0for=20DHCP=20authentication |Sender:=20 |To:=20Internet=20Area=20,=20dhcwg@ietf.org; bh=3wGMVwFIi30nVIT65vGppmM4BfCKr/+5clAt6uiE1f8=; b=HHjMlpdUL8YOEOme5w/PZJLGi6/m6uV815evKeW5V6MAMR+S3xNny5N9W6K1xZs2wCorOQS8 8V+5Jyo5aEj4k44gHfiChRA6WsRnNvrQhJRcjT2ypEEImmymKvgHJlxx; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Does the short lease/long lease scenario scale the DHCP server load by more than a factor of two? - Ralph On Nov 5, 2007, at Nov 5, 2007,8:50 PM, Richard Pruss wrote: > Should this conversation not move to the int-area? > > Alper Yegin wrote, around 6/11/07 5:19 AM: >> 1. CPE configures a pre-PANA IP address using DHCP >> 2. CPE runs PANA >> 3. CPE configures "session IP address" using DHCP >> > The PANA idea if using short lease/long lease DHCP address > switching in DSL deployments is simply not feasible. BRAS's with > over 60K subscribers are common and many providers have central > city pops of more than a million subscribers. > > During a pop restart the 60 second lease on a million subscribers > would at best result in a sustained load of more than 16000 DHCP > requests / second smashing through the relays and into the DHCP > servers until the users had gradually authenticated. > > - Ric > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 06 04:21:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpKcq-0007oF-9r; Tue, 06 Nov 2007 04:21:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpKcp-0007nP-7Y for dhcwg@ietf.org; Tue, 06 Nov 2007 04:21:35 -0500 Received: from [67.15.124.176] (helo=rakhan.thetiger.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpKco-0007ey-Ry for dhcwg@ietf.org; Tue, 06 Nov 2007 04:21:35 -0500 Received: from [10.0.1.100] (c211-28-94-237.smelb1.vic.optusnet.com.au [211.28.94.237]) by rakhan.thetiger.com (Postfix) with ESMTP id ED32C8A8651; Tue, 6 Nov 2007 02:34:28 -0600 (CST) Message-Id: From: David Miles To: dhcwg@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Subject: RE: [dhcwg] Feedback on Layer 2 Relay Agent functionality Date: Tue, 6 Nov 2007 20:21:29 +1100 X-Mailer: Apple Mail (2.912) X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org With the recent discussions around Layer 2 Relay Agents (such as that described in DSL Forum TR-101 Appendix B) has there been consideration of the equivalent for IPv6? Today Layer 2 Relay Agents are an integral part of TR-101 when N:1 VLANs are used. As we move towards IPv6 deployments there is a desire to keep the fundamental layer 2 architecture (N:1) which suggests a similar function for DHCPv6 in the DSLAM. Like the current DSL Forum L2 DHCPv4 Relay Agent, the purpose for the relay agent is to add DHCPv6 Remote ID (equivalent to DHCPv4 Option 82) so that a server can determine policy based on value matching. In DHCPv6 things become more challenging as for starters there is no real "layer 2". There seem to be two general options: 1) Implement a DHCPv6 Relay on the DSLAM - Implication is that the DSLAM must then have a IPv6 address (link- local) and stack, participating as an actual node in the N:1 VLAN (ie, the DSLAM should perform DAD and possibly ND) - As the DSLAM does not act as an IPv6 router, the Relay-Forward link address would be unspecified and thus requires the addition of Interface ID - The interface ID itself could then be used to convey the "circuit" to the router 2) DSLAM inserts Option 37 (Remote ID) into DHCPv6 messages - Inserts information into a client-sourced Solicit without the client knowledge - Minimal impact on the DSLAM (no need for complete IPv6 stack - Not supported by DHCPv6 (RFC 3315) as Option 37 is a Relay Agent Option I wouldn't suggest the above satisfactorily explores the issues relating to DHCPv6 Relay Agents in a DSLAM, but hopefully it may stir some ideas. IPv6 deployments are just on the horizon for carriers but without clear directives we could see multiple (and incompatible) approaches. My apologies if this has been discussed prior (I couldn't find any direct references in the archives) Regards, - David _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 06 13:15:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSxE-000648-M3; Tue, 06 Nov 2007 13:15:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSxD-00061S-Ew for dhcwg@ietf.org; Tue, 06 Nov 2007 13:15:11 -0500 Received: from [2001:4f8:3:bb::1:ee8b] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpSxC-000399-2p for dhcwg@ietf.org; Tue, 06 Nov 2007 13:15:11 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id 7D6615A6EC; Tue, 6 Nov 2007 10:15:09 -0800 (PST) Date: Tue, 6 Nov 2007 10:15:09 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Feedback on Layer 2 Relay Agent functionality Message-ID: <20071106181509.GA1343@isc.org> References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: -0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1124036319==" Errors-To: dhcwg-bounces@ietf.org --===============1124036319== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 06, 2007 at 08:21:29PM +1100, David Miles wrote: > With the recent discussions around Layer 2 Relay Agents (such as that =20 > described in DSL Forum TR-101 Appendix B) has there been consideration = =20 > of the equivalent for IPv6? I believe it has been discussed...it's an integral part of DHCPv6, this seems to have been a design consideration. The things we've been talking about are places where perhaps some clarification is in order; in particular that they will simply behave like a regular DHCPv6 relay agent - the only exception that they will send a zero-filled link-address value (3315 makes no explicit statement about what to do here, and some implementers have asked if they should fill it with a link-local address...). For this reason, servers use the outermost link-address value that is nonzero for client link detection ("unless otherwise configured"), something that is also not concretely defined ("exampled?") in 3315. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHMK8tcXeLeWu2vmoRAgkqAKCvA1hpR89dEES97TRVB3D2ZdvyUwCfVglc 7YWjqhEINUYPtHeBaj7Cllg= =sd1e -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- --===============1124036319== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1124036319==-- From dhcwg-bounces@ietf.org Tue Nov 06 17:12:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpWef-0008G5-Cy; Tue, 06 Nov 2007 17:12:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpWee-0008Fr-7u for dhcwg@ietf.org; Tue, 06 Nov 2007 17:12:16 -0500 Received: from [67.15.124.176] (helo=rakhan.thetiger.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpWed-0005yN-MD for dhcwg@ietf.org; Tue, 06 Nov 2007 17:12:16 -0500 Received: from [10.0.1.100] (c211-28-94-237.smelb1.vic.optusnet.com.au [211.28.94.237]) by rakhan.thetiger.com (Postfix) with ESMTP id 0A9DC8A8651; Tue, 6 Nov 2007 15:25:10 -0600 (CST) Message-Id: From: David Miles To: David W.Hankins In-Reply-To: <20071106181509.GA1343@isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: [dhcwg] Feedback on Layer 2 Relay Agent functionality Date: Wed, 7 Nov 2007 09:12:11 +1100 References: <20071106181509.GA1343@isc.org> X-Mailer: Apple Mail (2.912) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Thanks David, This aligns with what I had assumed for option 1. I'd assume its also legal to set the IP destination of this DHCPv6 Relay-Forward to the All-DHCPv6-Servers MC address (fe02::1:2)? One consequence of implementing a full DHCPv6 relay on the DSLAM is that the DSLAM is now an IPv6 host within each VLAN and must therefore respond to DAD and ND from both clients and the BNG (as an example, of course there is far more than this). This could introduce significant complexity into the implementation with little apparent benefit, after all the relay agent in the DSLAM is not trying to unicast the traffic directly to a server - it is simply inserting Remote-ID. When you say it has been discussed, does that imply a preliminary conclusion has been reached? I don't suppose you know roughly when it was discussed so I could trawl through the archives? While DHCPv6 relay is an integral part of RFC 3315 I'm not aware of a discussion around TR-101 L2 DHCPv6 Relay, though I see there was one recently for IPv4. Regards, -David On 07/11/2007, at 5:15 AM, David W. Hankins wrote: > On Tue, Nov 06, 2007 at 08:21:29PM +1100, David Miles wrote: >> With the recent discussions around Layer 2 Relay Agents (such as that >> described in DSL Forum TR-101 Appendix B) has there been >> consideration >> of the equivalent for IPv6? > > I believe it has been discussed...it's an integral part of DHCPv6, > this seems to have been a design consideration. The things we've been > talking about are places where perhaps some clarification is in order; > in particular that they will simply behave like a regular DHCPv6 relay > agent - the only exception that they will send a zero-filled > link-address value (3315 makes no explicit statement about what to do > here, and some implementers have asked if they should fill it with a > link-local address...). > > For this reason, servers use the outermost link-address value that > is nonzero for client link detection ("unless otherwise configured"), > something that is also not concretely defined ("exampled?") in 3315. > > -- > Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. > Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ > -- > David W. Hankins "If you don't do it right the first time, > Software Engineer you'll just have to do it again." > Internet Systems Consortium, Inc. -- Jack T. Hankins > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 07 01:25:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpeLi-00054s-OA; Wed, 07 Nov 2007 01:25:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpeLh-00052f-3o for dhcwg@ietf.org; Wed, 07 Nov 2007 01:25:13 -0500 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpeLf-0007uS-Ff for dhcwg@ietf.org; Wed, 07 Nov 2007 01:25:13 -0500 Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by syd-iport-1.cisco.com with ESMTP; 07 Nov 2007 17:25:09 +1100 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA76P7kr014847; Wed, 7 Nov 2007 14:25:07 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA76P4ZD008152; Wed, 7 Nov 2007 06:25:06 GMT Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 14:25:06 +0800 Received: from syd-rpruss-vpn1.cisco.com ([10.67.195.18]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 14:25:01 +0800 Message-ID: <47315A41.6020803@cisco.com> Date: Wed, 07 Nov 2007 16:25:05 +1000 From: Richard Pruss Organization: Cisco Systems User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication References: In-Reply-To: X-OriginalArrivalTime: 07 Nov 2007 06:25:02.0002 (UTC) FILETIME=[ED9C4120:01C82106] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.000 X-TM-AS-Result: No--31.289500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16389; t=1194416708; x=1195280708; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ric@cisco.com; z=From:=20Richard=20Pruss=20 |Subject:=20Re=3A=20[dhcwg]=20Discussion=20of=20dhc=20WG=20rechartering=2 0for=20DHCP=20authentication |Sender:=20; bh=JGqL/R0gqTTSqp8cdmM/rTWIGBc8Vi4ZrPY+2vZszbo=; b=IrR3ATxnes2cLpZGrIdQ5Zdn1AKjIJGGy/Hp7+AITuA1QTs5hIgQBAzPw9i6J35JVR76XHPW z4sUZFaKkO6KBVaKrWxhcJiHy3XnNftYG+ZxdY262B32lHJ2/ic1vlxyA2qp6Q+Qmf0rtN9uA6 ZMJXLWUUkaCml9kiobeJZ6QV4=; Authentication-Results: hkg-dkim-1; header.From=ric@cisco.com; dkim=pass (si g from cisco.com/hkgdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 Cc: dhcwg@ietf.org, ext Ralph Droms X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ric@cisco.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0688461273==" Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0688461273== Content-Type: multipart/alternative; boundary="------------040608080209000803090006" This is a multi-part message in MIME format. --------------040608080209000803090006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Basavaraj Patil wrote, around 2/11/07 1:49 AM: > > Ric, > > That's not the point. I agree that we do authentication at several > layers today. Access auth, SIP auth, etc. > But what the I-D is proposing is basically extending DHCP to > accomplish access auth. > For access auth, there are several mechanisms today. Do we need DHCP > to solve the access-auth problem as well? > > What is the primary reason/argument for doing access auth via DHCP? Is > it an optimization or is it because there is no other way to solve the > access auth problem in the domain that you are looking at? There a confluence of two design directions in DSL architecture coming together driving the next generation of IP session requirements in DSL Forum. One direction comes from small greenfield networks and the move to ethernet, they have been deploying DSL with DHCP and Option 82 line details providing the identity criteria to configure the host but also the L2 and L3 edges. Most of the DSL BRAS vendors now allow the BRAS to use DHCP attributes trigger configuration retrieval for the BRAS from RADIUS. The second comes from large long standing PPPoE/PPPoA networks which have massive databases of existing users and want to allow a gradual migration to ethernet service delivery but not require churn in the customer authentication database. Finally DSL architecture is all about scaling (I guess SP engineering always is) where we have BRAS's with 60K+ subscribers on and millions of users on the network, we try set everything up at the same time and do it once. To be clear we did not start off by trying to invent something new here, we went through many existing approaches before we got here today. I think if you take the authentication question in the DSL architecture context, the simple questions that are probably bugging you like "Why did they not just use 802.1x?" might be clearer: The current recommended DSL Forum architecture is in TR-101: http://www.dslforum.org/techwork/tr/TR-101.pdf The current draft of next generation WT-148 is: http://www.arkko.com/ietf/intarea/dsl2006.887.03.doc The living list of requirements for authentication for WT-146 is: https://datatracker.ietf.org/documents/LIAISON/file457.doc - Ric > > -Raj > > > On 11/1/07 10:33 AM, "ext Richard Pruss" wrote: > > Authentication is something that happens at every layer with every > application. Terminal access was designed without authentication, > that does not mean we do it like that today. > > I do not think we can take the argument of it was not designed > for x as a reason to stay in the past. > > Regards, > Ric > > Basavaraj Patil wrote, around 29/10/07 9:42 AM: > > > Ralph, > > I think overloading DHCP for access authentication is a bad > idea. DHCP was > not designed for that purpose. I guess I need to communicate > this on the > int-area list. But anyway you know my opinion at least in the > DHC WG. > > -Basavaraj > > > On 10/19/07 6:05 AM, "ext Ralph Droms" > wrote: > > > > > > There is a lengthy discussion about rechartering the dhc > WG to take > on the DHCP authentication proposals in draft-pruss-dhcp-auth- > dsl-01.txt and draft-zhao-dhc-user-authentication-02 in > the int- > area@ietf.org mailing list. Both of these drafts have > been submitted > for to the WG for review in the past, and neither, to > date, has been > accepted as a dhc WG work iterm. I've included a copy of > the initial > posting, > http://www1.ietf.org/mail-archive/web/int-area/current/ > msg00957.html, below. Because this discussion may lead to the > rechartering of the dhc WG to take on either or both of > these drafts > as new work items, those of you not on the int-area > mailing list > should consider reviewing the e-mail thread and > contributing to the > discussion. > > - Ralph > > > ===== > To: Internet Area > Subject: [Int-area] DCHP-based authentication for DSL? > From: Jari Arkko > Date: Thu, 04 Oct 2007 23:22:15 +0300 > > > We talked about the DSL requirements earlier on this list. Now > they have sent us a liaison statement regarding what they > would > like to do: > > "At this time, we would like to make the IETF aware that > during > our most recent DSL Forum quarterly meeting, the Architecture > and Transport Working Group agreed to seriously consider > adopting > a mechanism such as that proposed in > draft-pruss-dhcp-auth-dsl-01.txt > or draft-zhao-dhc-user-authentication-02. We understand > that the authors > of these specifications intend to produce a combined > document soon. > The DSL Forum formally requests that the IETF adopt this > as a work > item, and would appreciate being advised of progress as > soon as > possible. > > Our next quarterly meeting is December 10-13, in Lisbon, > Portugal." > > > How do we feel about this? Is this a good idea, > considering the DSL > architecture? How will it affect DHCP the protocol? How would > you go about making DHCP extensions so that they work best > for all possible environments and not just DSL? Is anyone > already working on the combined draft promised above? Are > there any other choices that we should recommend instead? > > I would like to hold the discussion on this in this list until > we've determined that the DHCP protocol is the right tool > for the job. If it is, we can recharter DHC WG again to add > the actual development work there. (DHC is right now > being rechartered but that recharting is mostly a cleanup > and not the addition of functionality to do this.) > > Jari > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > --------------040608080209000803090006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Basavaraj Patil wrote, around 2/11/07 1:49 AM:
Re: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication
Ric,

That’s not the point. I agree that we do authentication at several layers today. Access auth, SIP auth, etc.
But what the I-D is proposing is basically extending DHCP to accomplish access auth.
For access auth, there are several mechanisms today. Do we need DHCP to solve the access-auth problem as well?

What is the primary reason/argument for doing access auth via DHCP? Is it an optimization or is it because there is no other way to solve the access auth problem in the domain that you are looking at?
There a confluence of two design directions in DSL architecture coming together driving the next generation of IP session requirements in DSL Forum.

One direction comes from small greenfield networks and the move to ethernet, they have been deploying DSL with DHCP and Option 82 line details providing the identity criteria to configure the host but also the L2 and L3 edges.  Most of the DSL BRAS vendors now allow the BRAS to use DHCP attributes trigger configuration retrieval for the BRAS from RADIUS.

The second comes from large long standing PPPoE/PPPoA networks which have massive databases of existing users and want to allow a gradual migration to ethernet service delivery but not require churn in the customer authentication database.

Finally DSL architecture is all about scaling (I guess SP engineering always is) where we have BRAS's with 60K+ subscribers on and millions of users on the network, we try set everything up at the same time and do it once.  To be clear we did not start off by trying to invent something new here, we went through many existing approaches before we got here today.

I think if you take the authentication question in the DSL architecture context, the simple questions that are probably bugging you like "Why did they not just use 802.1x?" might be clearer:

The current recommended DSL Forum architecture is in TR-101:
http://www.dslforum.org/techwork/tr/TR-101.pdf

The current draft of next generation WT-148 is:
http://www.arkko.com/ietf/intarea/dsl2006.887.03.doc

The living list of requirements for authentication for WT-146 is:
https://datatracker.ietf.org/documents/LIAISON/file457.doc

- Ric



-Raj


On 11/1/07 10:33 AM, "ext Richard Pruss" <rpruss@cisco.com> wrote:
Authentication is something that happens at every layer with every application. Terminal access was designed without authentication, that does not mean we do it like that today.

 I do not think we can take the argument of it was not designed for x as a reason to stay in the past.

Regards,
Ric

Basavaraj Patil wrote, around 29/10/07 9:42 AM:

Ralph,

I think overloading DHCP for access authentication is a bad idea. DHCP was
not designed for that purpose. I guess I need to communicate this on the
int-area list. But anyway you know my opinion at least in the DHC WG.

-Basavaraj


On 10/19/07 6:05 AM, "ext Ralph Droms" <rdroms@cisco.com> <mailto:rdroms@cisco.com>  wrote:

  
 

There is a lengthy discussion about rechartering the dhc WG to take
on the DHCP authentication proposals in draft-pruss-dhcp-auth-
dsl-01.txt and draft-zhao-dhc-user-authentication-02 in the int-
area@ietf.org mailing list.  Both of these drafts have been submitted
for to the WG for review in the past, and neither, to date, has been
accepted as a dhc WG work iterm.  I've included a copy of the initial
posting, http://www1.ietf.org/mail-archive/web/int-area/current/
msg00957.html, below.  Because this discussion may lead to the
rechartering of the dhc WG to take on either or both of these drafts
as new work items, those of you not on the int-area mailing list
should consider reviewing the e-mail thread and contributing to the
discussion.

- Ralph


=====
To: Internet Area <int-area at ietf.org>
Subject: [Int-area] DCHP-based authentication for DSL?
From: Jari Arkko <jari.arkko at piuha.net>
Date: Thu, 04 Oct 2007 23:22:15 +0300


We talked about the DSL requirements earlier on this list. Now
they have sent us a liaison statement regarding what they would
like to do:

"At this time, we would like to make the IETF aware that during
our most recent DSL Forum quarterly meeting, the Architecture
and Transport Working Group agreed to seriously consider adopting
a mechanism such as that proposed in draft-pruss-dhcp-auth-dsl-01.txt
or draft-zhao-dhc-user-authentication-02. We understand that the authors
of these specifications intend to produce a combined document soon.
The DSL Forum formally requests that the IETF adopt this as a work
item, and would appreciate being advised of progress as soon as
possible.

Our next quarterly meeting is December 10-13, in Lisbon, Portugal."


How do we feel about this? Is this a good idea, considering the DSL
architecture? How will it affect DHCP the protocol? How would
you go about making DHCP extensions so that they work best
for all possible environments and not just DSL? Is anyone
already working on the combined draft promised above? Are
there any other choices that we should recommend instead?

I would like to hold the discussion on this in this list until
we've determined that the DHCP protocol is the right tool
for the job. If it is, we can recharter DHC WG again to add
the actual development work there. (DHC is right now
being rechartered but that recharting is mostly a cleanup
and not the addition of functionality to do this.)

Jari


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



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

  
--------------040608080209000803090006-- --===============0688461273== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0688461273==-- From dhcwg-bounces@ietf.org Wed Nov 07 06:04:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipii7-0005WT-Al; Wed, 07 Nov 2007 06:04:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipii4-0005V7-Vc; Wed, 07 Nov 2007 06:04:37 -0500 Received: from mout.perfora.net ([74.208.4.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipii1-00032V-2M; Wed, 07 Nov 2007 06:04:36 -0500 Received: from IBM52A5038A94F ([85.102.196.157]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Ipiht1wKu-0008SB; Wed, 07 Nov 2007 06:04:31 -0500 From: "Alper Yegin" To: "'Eric Voit \(evoit\)'" , "'Ralph Droms \(rdroms\)'" Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering forDHCPauthentication Date: Wed, 7 Nov 2007 13:04:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcggHm+KfPGdwHk5Th6TDrp6Vvyw4QAzsuSAAA8SLPA= Message-Id: <0MKpCa-1Ipiht1wKu-0008SB@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+a92EcyCGMYMMpR1xUgE3HGGph9obBuDq3s4m xqSrMY2PE6GRgNGuc6hrIBV696afVVwq+gUQGBbM1d/YkDhauH O9wW3FWcPd/R2vF8sNl0g== X-Spam-Score: -0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: dhcwg@ietf.org, 'Internet Area' X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org First of all, there is no way use of PANA would lead to more DHCP traffic. How can that be true when carrying EAP over DHCP always at the minimum contribute 2 additional round-trips just for the sake of transporting EAP? In the worst case (DHCP-configured pre-PANA address), there are two round trips for that 1st DHCP. Even in that case PANA is no worse than DHCP-auth. And then there are better cases, e.g. use of link-local address as pre-PANA address, rapid commit, etc. As for your 11-msg PANA call flow count, the example you used is the most verbose one. If you turn on the optimizations (agent-side initiation, piggybacking) it reduces to 2 round trips. So, in the worst case scenario (full dhcp, pana, another full dhcp), PANA has additional 2 round-trips. By kicking in more optimized deployment choices, this difference can be diminished. Alper > -----Original Message----- > From: Eric Voit (evoit) [mailto:evoit@cisco.com] > Sent: Wednesday, November 07, 2007 5:40 AM > To: Ralph Droms (rdroms) > Cc: dhcwg@ietf.org; Internet Area > Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering > forDHCPauthentication > > > From: Ralph Droms, November 05, 2007 9:37 PM > > > > Does the short lease/long lease scenario scale the DHCP > > server load by more than a factor of two? > > Ralph, > > The messages the DHCP servers will double. > The messages with L3 edge (BRAS) will more than double. > The messages with the CPE will more than triple. > > (Below is some rough math. I might have missed a message or two, but the > general trend is what I am trying to show.) > > ----------------------------------------- > CPE Messages > ----------------------------------------- > DHCP Auth, assuming a 2 message EAP Method, the messages used by EAP > would be equal > + 6 Messages (draft-pruss-dhcp-auth-dsl-01) > > PANA+DHCP Method > + 4 Messages: DHCP 1st IP address > ~ (+2) DHCP renews per 60 seconds until authenticated > + 11 Messages PANA with BRAS (draft-ietf-pana-pana-18, section 4.1) > + 4 Messages: DHCP 2nd IP address > > ----------------------------------------- > L3 Edge (BRAS) Messages > ----------------------------------------- > DHCP Auth, EAP Method > + 8 Messages (draft-pruss-dhcp-auth-dsl-01) > > PANA Method > + 4 Messages: DHCP 1st IP address > ~ (+2) DHCP renews per 60 seconds until authenticated > + 11 Messages PANA with CPE (draft-ietf-pana-pana-18, section 4.1) > + 2 messages min for validating with EAP Server > + 4 Messages: DHCP 2nd IP address > > ----------------------------------------- > L2 Edge (DSLAM or Access Switch) Messages > ----------------------------------------- > DHCP Auth, EAP Method > + 6 Messages snooped (draft-pruss-dhcp-auth-dsl-01) > > PANA+DHCP Method > + 4 Messages Snooped: DHCP 1st IP address > ~ (+2) DHCP renews per 60 seconds until authenticated > If snooping: 11 Messages PANA (draft-ietf-pana-pana-18, section 4.1) > Else if explicit policy distribution like ANCP, ~4 messages (one policy > per address) > + 4 Messages Snooped: DHCP 2nd IP address > > > Eric > > > > - Ralph > > > > > _______________________________________________ > Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 07 07:06:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipjfr-0004Go-C6; Wed, 07 Nov 2007 07:06:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipjfp-0004FL-JY; Wed, 07 Nov 2007 07:06:21 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ipjfp-0003UQ-4H; Wed, 07 Nov 2007 07:06:21 -0500 X-IronPort-AV: E=Sophos;i="4.21,384,1188802800"; d="scan'208";a="544074646" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 07 Nov 2007 04:06:20 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA7C6KPm016584; Wed, 7 Nov 2007 04:06:20 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA7C6Jfb007099; Wed, 7 Nov 2007 12:06:20 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 07:06:19 -0500 Received: from [192.168.1.102] ([10.86.241.102]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 07:06:19 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <0MKpCa-1Ip7Tp4AID-0008VV@mrelay.perfora.net><472FC860.6000104@cisco.com> <8D9309C4-247F-4751-BFDC-00CCEB9367E7@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <78AE241E-C3EC-4DCC-A52E-0615BE421FB0@cisco.com> Content-Transfer-Encoding: 7bit From: Ralph Droms Subject: Re: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering for DHCPauthentication Date: Wed, 7 Nov 2007 07:06:15 -0500 To: Internet Area , dhcwg@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Nov 2007 12:06:19.0159 (UTC) FILETIME=[9AF27270:01C82136] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.002 X-TM-AS-Result: No--23.910500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2451; t=1194437180; x=1195301180; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[Int-area]=20Re=3A=20[dhcwg]=20Discussion=20of=20dhc= 20WG=20rechartering=20for=20DHCPauthentication |Sender:=20; bh=IAsCZHkZZDY4Y94EWbqomzqi1bEYBALXbXgsHN+4lCE=; b=uqws07ISYtnWSTPZZ24KN8MHLiykTc9QYyaLSmDfep42iyVGwBMgfSUx5cg3leDxdTVBK3Oi Q2t3o96uVT1cwM8FLeH3lmwIHKwDvmM24YiBHTPJCVAll1B9nMm8fZQV; Authentication-Results: sj-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Eric - I was mostly responding to Ric's description of the excessive load on DHCP servers in the short-lease/long-lease scenario. As I understand the short-lease/long-lease scenario, if we assume that authentication takes place in the short-lease window, the load on the DHCP servers would double. Significant, sure, but not game-changing in the way Ric implied. - Ralph On Nov 6, 2007, at Nov 6, 2007,10:39 PM, Eric Voit (evoit) wrote: >> From: Ralph Droms, November 05, 2007 9:37 PM >> >> Does the short lease/long lease scenario scale the DHCP >> server load by more than a factor of two? > > Ralph, > > The messages the DHCP servers will double. > The messages with L3 edge (BRAS) will more than double. > The messages with the CPE will more than triple. > > (Below is some rough math. I might have missed a message or two, > but the > general trend is what I am trying to show.) > > ----------------------------------------- > CPE Messages > ----------------------------------------- > DHCP Auth, assuming a 2 message EAP Method, the messages used by EAP > would be equal > + 6 Messages (draft-pruss-dhcp-auth-dsl-01) > > PANA+DHCP Method > + 4 Messages: DHCP 1st IP address > ~ (+2) DHCP renews per 60 seconds until authenticated > + 11 Messages PANA with BRAS (draft-ietf-pana-pana-18, section 4.1) > + 4 Messages: DHCP 2nd IP address > > ----------------------------------------- > L3 Edge (BRAS) Messages > ----------------------------------------- > DHCP Auth, EAP Method > + 8 Messages (draft-pruss-dhcp-auth-dsl-01) > > PANA Method > + 4 Messages: DHCP 1st IP address > ~ (+2) DHCP renews per 60 seconds until authenticated > + 11 Messages PANA with CPE (draft-ietf-pana-pana-18, section 4.1) > + 2 messages min for validating with EAP Server > + 4 Messages: DHCP 2nd IP address > > ----------------------------------------- > L2 Edge (DSLAM or Access Switch) Messages > ----------------------------------------- > DHCP Auth, EAP Method > + 6 Messages snooped (draft-pruss-dhcp-auth-dsl-01) > > PANA+DHCP Method > + 4 Messages Snooped: DHCP 1st IP address > ~ (+2) DHCP renews per 60 seconds until authenticated > If snooping: 11 Messages PANA (draft-ietf-pana-pana-18, section 4.1) > Else if explicit policy distribution like ANCP, ~4 messages (one > policy > per address) > + 4 Messages Snooped: DHCP 2nd IP address > > > Eric > > >> - Ralph >> _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 08 10:41:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9V7-0003Y2-4h; Thu, 08 Nov 2007 10:41:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9V6-0003XH-Gn for dhcwg@ietf.org; Thu, 08 Nov 2007 10:41:00 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq9V3-0000rv-3r for dhcwg@ietf.org; Thu, 08 Nov 2007 10:41:00 -0500 X-IronPort-AV: E=Sophos;i="4.21,389,1188770400"; d="scan'208";a="157189576" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2007 16:40:37 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA8FebDq004573; Thu, 8 Nov 2007 16:40:37 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA8Feb8i004035; Thu, 8 Nov 2007 15:40:37 GMT Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 16:40:36 +0100 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, 8 Nov 2007 16:41:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Network Time Protocol (NTP) Options for DHCPv6 Thread-Index: AcgiHKqGaKJZnHkxTpKXpDEnqj6AlQ== From: "Benoit Lourdelet (blourdel)" To: , X-OriginalArrivalTime: 08 Nov 2007 15:40:36.0957 (UTC) FILETIME=[B53478D0:01C8221D] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.001 X-TM-AS-Result: No--10.121200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=565; t=1194536437; x=1195400437; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=blourdel@cisco.com; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20 |Subject:=20Network=20Time=20Protocol=20(NTP)=20Options=20for=20DHCPv6 |Sender:=20; bh=jTeBrEcAnPo/Y2Jl+4evSwWOvlLivT/2YUW2xv72nL0=; b=C3PIcYS7bumEutK+Jy9a4Bn+NXCYiFCbVPJUoB2TbzKCyGNGMCAe6qq8nWwT9ceMpKRtFBEg lGo7gAcnMWXadg4y8Z/u9tJiVF4ii27Snb30pR4cwXkExFBVgJFW5m8R; Authentication-Results: ams-dkim-2; header.From=blourdel@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Richard Gayraud \(rgayraud\)" Subject: [dhcwg] Network Time Protocol (NTP) Options for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hello,=20 We have just submitted a new draft proposing an NTP option for DHCPv6.=20 The goal of this draft is to standardize automatic configuration of NTPv4 (IPv6) clients over DHCPv6. We think there is currently no satisfactory solution for configuring NTPv4 clients from a centralized DHCPv6 server. We'd be very happy to hear feedback about the draft, and I'm planning to ask that it becomes a WG draft eventually. Here's a url: =20 http://www.ietf.org/internet-drafts/draft-gayraud-dhcpv6-ntp-opt-00.txt Thanks, Richard and Benoit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 08 11:36:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqAMJ-0006tR-KU; Thu, 08 Nov 2007 11:35:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqAMH-0006sM-8x for dhcwg@ietf.org; Thu, 08 Nov 2007 11:35:57 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqAMG-0004ST-VE for dhcwg@ietf.org; Thu, 08 Nov 2007 11:35:57 -0500 X-IronPort-AV: E=Sophos;i="4.21,390,1188792000"; d="scan'208";a="136363311" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 08 Nov 2007 11:35:55 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA8GZune015241; Thu, 8 Nov 2007 11:35:56 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA8GYWWj001507; Thu, 8 Nov 2007 16:35:55 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 11:35:48 -0500 Received: from [192.168.1.102] ([10.86.240.39]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 11:35:44 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2064072C-5AF5-447E-8266-57686DF824BF@cisco.com> Content-Transfer-Encoding: 7bit From: Ralph Droms Date: Thu, 8 Nov 2007 11:35:34 -0500 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 08 Nov 2007 16:35:46.0304 (UTC) FILETIME=[69BAC000:01C82225] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.002 X-TM-AS-Result: No--1.279100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=690; t=1194539756; x=1195403756; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20dhc=20WG=20meeting=20in=20Vancouver |Sender:=20 |To:=20dhcwg@ietf.org; bh=L5l2VefjASMZmzpbdagAVGaweM6gBXBTViKGMvE0cdE=; b=Jl3CB0SBQdkl0u7fdbZpFqqLtItA0Es5qJpDrc2ofeLc4uH4z0/FhCunY1IPARNt14kQ8h5y MFNGtGh/1hMEW22w5a9NEKqqxLgaJAMEMyyE2mfrHxKzeZb8cGWXwFEh; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Dhc Chairs Subject: [dhcwg] dhc WG meeting in Vancouver X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org The dhc WG will meet in Vancouver, http://ietf.org/meetings/70- IETF.html; here is the tentative scheduled date and time for our meeting: TUESDAY, December 4, 2007 1300-1500 Afternoon Session I Salon 1 INT dhc Dynamic Host Configuration WG Please contact the WG chairs, dhc-chairs@tools.ietf.org, with agenda requests before Wed, Nov 14. As always, we are looking for volunteers to act as meeting and Jabber scribes. Here are some important dates: http://ietf.org/meetings/70- cutoff_dates.html Note that the I-D rev -00 submission deadline is 0900 EST this coming Mon, 11/12, and the general I-D submission deadline is 0900 EST Mon, 11/19. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 08 23:24:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqLQ5-0001Fn-NE; Thu, 08 Nov 2007 23:24:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqLQ5-0001Fh-44 for dhcwg@ietf.org; Thu, 08 Nov 2007 23:24:37 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqLQ4-00037Y-Nb for dhcwg@ietf.org; Thu, 08 Nov 2007 23:24:37 -0500 X-IronPort-AV: E=Sophos;i="4.21,392,1188792000"; d="scan'208";a="75555401" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Nov 2007 23:24:36 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA94Oa1a000583; Thu, 8 Nov 2007 23:24:36 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA94OadQ020262; Fri, 9 Nov 2007 04:24:36 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 23:24:36 -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 Subject: RE: [dhcwg] Clarification in RFC 3633 Date: Thu, 8 Nov 2007 23:24:34 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2105874F6C@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <7t5d4uool9f.fsf@gpk-xdm-001.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Clarification in RFC 3633 Thread-Index: Acgfs5ypNBz2Eby3TwWuEgnryyLCWwC1FGDw From: "Bernie Volz (volz)" To: "Ole Troan (otroan)" , "ravi kumar" X-OriginalArrivalTime: 09 Nov 2007 04:24:36.0007 (UTC) FILETIME=[6F686B70:01C82288] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.002 X-TM-AS-Result: No--18.159600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1949; t=1194582276; x=1195446276; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Clarification=20in=20RFC=203633 |Sender:=20 |To:=20=22Ole=20Troan=20(otroan)=22=20, =0A=20=20=20=20= 20=20=20=20=22ravi=20kumar=22=20; bh=koSpH06bybwYaHQv9enhDtXR783sRYT9acC3NR81wQQ=; b=XZlgRcYJCmZxecNkBNgOaLfkTmZUKsML2+pQnrrLMp+/F7wV1NEpMBRR0xXFaTVRtUFercd0 o+shxH+yhi8VQ1mceTPgG2S+9SQp0E9i8re4ZDW7xt9YRNxzJX4Xj3JR; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I think he was meaning that the client use the prefixes in the REPLY in response to the RENEW. And, yes that is what the client should do. Basically, the client should do what is in the Reply (RFC 3315 has some text about this for addresses, not sure if 3633 duplicated that for prefixes). For those prefixes that are in the Reply and the client already has information, update the prefix lifetimes [note that the NEW lifetimes might be 0 if the server is attempting to revoke the prefixes]. For those prefixes that are in the Reply for which the client has no information, it should "install" them. And, those prefixes the client already has but are NOT in the reply, it should leave them be. - Bernie=20 -----Original Message----- From: Ole Troan (otroan)=20 Sent: Monday, November 05, 2007 8:49 AM To: ravi kumar Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Clarification in RFC 3633 > So in that case, The client should also accept the newly added > prefixes in RENEW message. Am I right? I don't understand what you mean by a client accepting prefixes in a RENEW message. if you mean that the client includes the new set of prefixes in a subsequent RENEW message, then that is correct. /ot > On 11/5/07, Ole Troan wrote: >> >> > I would like to clarify, if the following scenario is valid, as per RFC >> > 3633: >> > >> > 1) DHCP Server responds with "x" prefixes, in reponse to Client REQUEST >> > message. >> > 2) The client sends RENEW message, with "x" prefixes in IAPD option. >> > 3) Then Server responds with "y" prefixes( where "y" > "x"), in the >> REPLY >> > message. >> > >> > Should client accept the REPLY message from Server, as valid REPLY >> message >> > or Not? >> >> yes. this is how you do renumbering. >> >> /ot >> _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 08 23:26:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqLS6-0003Yz-UJ; Thu, 08 Nov 2007 23:26:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqLS4-0003UJ-93 for dhcwg@ietf.org; Thu, 08 Nov 2007 23:26:40 -0500 Received: from wa-out-1112.google.com ([209.85.146.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqLS0-000064-J5 for dhcwg@ietf.org; Thu, 08 Nov 2007 23:26:40 -0500 Received: by wa-out-1112.google.com with SMTP id k40so751077wah for ; Thu, 08 Nov 2007 20:26:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=esy4oYD7//QooWfvTHsfak2zT9a0iKOEtq+A1xnXfhw=; b=YT+myYK/WRXYMPbGgPECu3E0ZzI5C9ieNIs5x/GN67yhgYKmHP1snxh8k/YgWw8QnMvje0wuTJ8k1PXbPO9xp8H+0PfSR7KrXX76WSRqWn5lodxcdo07JoGfh1IqQgMvFJucpzZBs7RdCek6VM7KQnIpDTDDlw+zkCmUOiORVsI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=J3JTXL9ALMUltJOk3IAH2c250qor86n6n4olgp5ZGLmdPMuNdKbSALN3A6w8BH23P3c8ug1fIJ7rJ74tyoxortUen7ntVs2n/bBth/pnXwohquCSvSE4Mf35EoDrNajpKa/2brrlIgQCilJo4mtaVUGimSryNrtzbq/Ej3U9dW4= Received: by 10.114.192.1 with SMTP id p1mr716392waf.1194582394739; Thu, 08 Nov 2007 20:26:34 -0800 (PST) Received: by 10.114.193.3 with HTTP; Thu, 8 Nov 2007 20:26:34 -0800 (PST) Message-ID: Date: Fri, 9 Nov 2007 09:56:34 +0530 From: "ravi kumar" To: "Bernie Volz (volz)" Subject: Re: [dhcwg] Clarification in RFC 3633 In-Reply-To: <8E296595B6471A4689555D5D725EBB2105874F6C@xmb-rtp-20a.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7t5d4uool9f.fsf@gpk-xdm-001.cisco.com> <8E296595B6471A4689555D5D725EBB2105874F6C@xmb-rtp-20a.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: dhcwg@ietf.org, "Ole Troan \(otroan\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Thanks a lot for the reply. regards Ravi On Nov 9, 2007 9:54 AM, Bernie Volz (volz) wrote: > I think he was meaning that the client use the prefixes in the REPLY in > response to the RENEW. > > And, yes that is what the client should do. > > Basically, the client should do what is in the Reply (RFC 3315 has some > text about this for addresses, not sure if 3633 duplicated that for > prefixes). For those prefixes that are in the Reply and the client > already has information, update the prefix lifetimes [note that the NEW > lifetimes might be 0 if the server is attempting to revoke the > prefixes]. For those prefixes that are in the Reply for which the client > has no information, it should "install" them. And, those prefixes the > client already has but are NOT in the reply, it should leave them be. > > - Bernie > > -----Original Message----- > From: Ole Troan (otroan) > Sent: Monday, November 05, 2007 8:49 AM > To: ravi kumar > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Clarification in RFC 3633 > > > > So in that case, The client should also accept the newly added > > prefixes in RENEW message. Am I right? > > I don't understand what you mean by a client accepting prefixes in a > RENEW message. > > if you mean that the client includes the new set of prefixes in a > subsequent RENEW message, then that is correct. > > /ot > > > On 11/5/07, Ole Troan wrote: > >> > >> > I would like to clarify, if the following scenario is valid, as per > RFC > >> > 3633: > >> > > >> > 1) DHCP Server responds with "x" prefixes, in reponse to Client > REQUEST > >> > message. > >> > 2) The client sends RENEW message, with "x" prefixes in IAPD > option. > >> > 3) Then Server responds with "y" prefixes( where "y" > "x"), in the > >> REPLY > >> > message. > >> > > >> > Should client accept the REPLY message from Server, as valid REPLY > >> message > >> > or Not? > >> > >> yes. this is how you do renumbering. > >> > >> /ot > >> > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 08 23:30:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqLVl-0006p4-MU; Thu, 08 Nov 2007 23:30:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqLVk-0006oz-C7 for dhcwg@ietf.org; Thu, 08 Nov 2007 23:30:28 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqLVk-0003Gv-08 for dhcwg@ietf.org; Thu, 08 Nov 2007 23:30:28 -0500 X-IronPort-AV: E=Sophos;i="4.21,392,1188792000"; d="scan'208";a="75555656" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 08 Nov 2007 23:30:28 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA94UR4t027090; Thu, 8 Nov 2007 23:30:27 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA94UJdS021598; Fri, 9 Nov 2007 04:30:27 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 23:30:20 -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 Subject: RE: [dhcwg] dhc WG meeting in Vancouver Date: Thu, 8 Nov 2007 23:30:18 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2105874F70@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <2064072C-5AF5-447E-8266-57686DF824BF@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG meeting in Vancouver Thread-Index: AcgiJX7AqBTbJ1TaSjSnceHmDw0/IgAYvcAw From: "Bernie Volz (volz)" To: "Ralph Droms (rdroms)" , X-OriginalArrivalTime: 09 Nov 2007 04:30:20.0201 (UTC) FILETIME=[3C904190:01C82289] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.002 X-TM-AS-Result: No--13.670900-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1481; t=1194582627; x=1195446627; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhc=20WG=20meeting=20in=20Vancouver |Sender:=20 |To:=20=22Ralph=20Droms=20(rdroms)=22=20, =20; bh=x8m5E2uwoDPVLLHmj7SiGah7Geo548bf6MX+ybSy/Co=; b=UwrZ/djpU5K4JVfmUStNluxDtJpaRQS660ladWUlGEjR/rU1o43xt+1MrRz3csQiG1YjTr0c vTHyZHWTKO0f+xF4rz8HndQp5WKtkyMhGVE7VzD282qYI7DZgFHfHl86; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Dhc Chairs X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I'd like to discuss what should be done about draft-volz-dhc-3942-status-00. It has expired and while I could simply make a few edits (such as addressing 208-211) and resubmit, it seems silly to do that if there is no support or interest for the DHC WG. I did ask the DHC WG in early October about next steps for this draft, but it didn't go anywhere. We need to give IANA information about updating the DHCP options registry. - Bernie -----Original Message----- From: Ralph Droms (rdroms)=20 Sent: Thursday, November 08, 2007 11:36 AM To: dhcwg@ietf.org Cc: Dhc Chairs Subject: [dhcwg] dhc WG meeting in Vancouver The dhc WG will meet in Vancouver, http://ietf.org/meetings/70-=20 IETF.html; here is the tentative scheduled date and time for our =20 meeting: TUESDAY, December 4, 2007 1300-1500 Afternoon Session I Salon 1 INT dhc Dynamic Host Configuration WG Please contact the WG chairs, dhc-chairs@tools.ietf.org, with agenda =20 requests before Wed, Nov 14. As always, we are looking for volunteers to act as meeting and Jabber =20 scribes. Here are some important dates: http://ietf.org/meetings/70-=20 cutoff_dates.html Note that the I-D rev -00 submission deadline is =20 0900 EST this coming Mon, 11/12, and the general I-D submission =20 deadline is 0900 EST Mon, 11/19. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 09 09:02:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqURG-0005vy-PW; Fri, 09 Nov 2007 09:02:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqURF-0005sh-7l; Fri, 09 Nov 2007 09:02:25 -0500 Received: from p130.piuha.net ([193.234.218.130] helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqURB-0006gX-KM; Fri, 09 Nov 2007 09:02:25 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id C12AB19867C; Fri, 9 Nov 2007 16:02:18 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 79E1B1985FB; Fri, 9 Nov 2007 16:02:18 +0200 (EET) Message-ID: <47346861.5030608@piuha.net> Date: Fri, 09 Nov 2007 16:02:09 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: draft-ietf-mip6-hiopt@tools.ietf.org, "Bernie Volz (volz)" References: <471B4D4A.1060700@piuha.net> In-Reply-To: <471B4D4A.1060700@piuha.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Mobile IPv6 Mailing List , Dhcwg Subject: [dhcwg] Re: AD review of draft-ietf-mip6-hiopt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi all, I have reviewed the new version and it satisfies my AD review concerns with the exception of the below minor issues. Also, I expect that the draft also has to satisfy DHC WG's review, and address the issues raised by Bernie. I have not looked at those yet, Bernie have you? >> id-type >> >> The type of Home Network Identifier: >> >> 0 Visited domain (local ASP) >> >> 1 Target MSP >> >> 2 No preference >> > > This seems unnecessarily complicated. Is there some reason why you could > simply include the target MSP domain information if it is known or an > empty string otherwise and be allocated a local ASP in that case? > I still disagree that this is needed, but I'm not making this a blocking comment if the WG wants to do it. >> 3.2. MIP6 Relay Agent Option >> >> This option carries the RADIUS or Diameter attributes that are >> received at the NAS from the AAAH. The DHCP relay agent sends this >> option to the DHCP server in the Relay-Forward message. >> > It does not carry RADIUS or Diameter attributes (and nor should it). > Please align this text with the actual subattributes that you have. > > Also, it is inappropriate to assume that the information can only come > from AAA. Presumably we'd like the mechanisms to be general enough that, > for instance, manual configuration, link identifier, etc. could also be > used to determine what mobility domains are appropriate for this client. > Text was changed, but it still assumes the data comes from AAAH only. Suggested edit: OLD: This option carries the home network information which was transferred to the NAS from AAAH by using [I-D.ietf-mip6-radius]. NEW: This option carries the home network information for the mobile node (the NAS may know this, for instance, through AAA by using [I-D.ietf-mip6-radius]). >> OPTION_MIP6-HNID (TBD) >> > Do you really have to mix underscore and dash in the same symbol? > Some of this still remains: OPTION_MIP6-HNINF (TBD). Jari _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 09 09:37:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqUzY-00066m-4A; Fri, 09 Nov 2007 09:37:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqUzW-00061s-Rt; Fri, 09 Nov 2007 09:37:50 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqUzW-0004UG-1R; Fri, 09 Nov 2007 09:37:50 -0500 X-IronPort-AV: E=Sophos;i="4.21,395,1188792000"; d="scan'208";a="136469011" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Nov 2007 09:37:49 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA9EbncH021758; Fri, 9 Nov 2007 09:37:49 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA9EbUdo021153; Fri, 9 Nov 2007 14:37:47 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 09:37:07 -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_01C822DE.00BAF1C5" Date: Fri, 9 Nov 2007 09:37:05 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210587505B@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <47346861.5030608@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-mip6-hiopt Thread-Index: Acgi2TCM+DlyT7NUR4yrgeuV11dImQABHA/g From: "Bernie Volz (volz)" To: "Jari Arkko" , X-OriginalArrivalTime: 09 Nov 2007 14:37:07.0252 (UTC) FILETIME=[00DB5F40:01C822DE] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15534.002 X-TM-AS-Result: No--19.682000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6913; t=1194619069; x=1195483069; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20AD=20review=20of=20draft-ietf-mip6-hiopt |Sender:=20 |To:=20=22Jari=20Arkko=22=20, =0A=20=20=20=20=20=20= 20=20; bh=SOtxO81KL3Gfs35AehL84oKl/8c5u8yIZEKVJtAyfN8=; b=ruOyIC48GL/mlLBRja3dG725okXb+FqPts1RWp///kMIPBL6PnUyDHqQbhYcIAIAGw+URyr4 zoGzPgGUUkJ0Yo3O1iFB7Dfp7atleUQkfoO3x/LSi2/pWGxPk3bw2DLW; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: Mobile IPv6 Mailing List , Dhcwg Subject: [dhcwg] RE: AD review of draft-ietf-mip6-hiopt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C822DE.00BAF1C5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I did review a recent version of the draft - I'm not sure which revision is now the latest. See the attached email regarding my most recent set of comments. - Bernie -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Friday, November 09, 2007 9:02 AM To: draft-ietf-mip6-hiopt@tools.ietf.org; Bernie Volz (volz) Cc: Mobile IPv6 Mailing List; Dhcwg Subject: Re: AD review of draft-ietf-mip6-hiopt Hi all, I have reviewed the new version and it satisfies my AD review concerns with the exception of the below minor issues. Also, I expect that the draft also has to satisfy DHC WG's review, and address the issues raised by Bernie. I have not looked at those yet, Bernie have you? >> id-type >> >> The type of Home Network Identifier: >> >> 0 Visited domain (local ASP) >> >> 1 Target MSP >> >> 2 No preference >> =20 > > This seems unnecessarily complicated. Is there some reason why you could > simply include the target MSP domain information if it is known or an > empty string otherwise and be allocated a local ASP in that case? > =20 I still disagree that this is needed, but I'm not making this a blocking comment if the WG wants to do it. >> 3.2. MIP6 Relay Agent Option >> >> This option carries the RADIUS or Diameter attributes that are >> received at the NAS from the AAAH. The DHCP relay agent sends this >> option to the DHCP server in the Relay-Forward message. >> =20 > It does not carry RADIUS or Diameter attributes (and nor should it). > Please align this text with the actual subattributes that you have. > > Also, it is inappropriate to assume that the information can only come > from AAA. Presumably we'd like the mechanisms to be general enough that, > for instance, manual configuration, link identifier, etc. could also be > used to determine what mobility domains are appropriate for this client. > =20 Text was changed, but it still assumes the data comes from AAAH only. Suggested edit: OLD: This option carries the home network information which was transferred to the NAS from AAAH by using [I-D.ietf-mip6-radius]. NEW: This option carries the home network information for the mobile node (the NAS may know this, for instance, through AAA by using [I-D.ietf-mip6-radius]). >> OPTION_MIP6-HNID (TBD) >> =20 > Do you really have to mix underscore and dash in the same symbol? > =20 Some of this still remains: OPTION_MIP6-HNINF (TBD). Jari ------_=_NextPart_001_01C822DE.00BAF1C5 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit 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 Subject: RE: Review request Date: Thu, 1 Nov 2007 21:56:51 -0500 In-Reply-To: <66e98e80710242223q584931cdwaf7d5b180f3bc8f9@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review request Thread-Index: AcgWxyoEDu2MkbtMQyi5K7Itz1k06wGMXLyA From: "Bernie Volz (volz)" To: "Heejin Jang" , Cc: "Alper Yegin" , , , "Basavaraj Patil" , "Gopal Dommety (gdommety)" , "Ralph Droms (rdroms)" I haven't had much time to do a careful review, but from a quick scan at least the DHCPv6 options and suboptions are now formatted appropriately. There's a lot of reserved fields, and perhaps there are plans to use them, but usually it is difficult to predict the future and sometimes best to remove stuff like that. But, it is your call. I also wonder whether the 3.3.1 Home Network Information sub-options might not be 1 through 6 (instead of 1-3), and incorporate the V bit into the sub-opt-code. Perhaps you don't even need all 6 values (not sure if they can all have both values of the V bit). But, that's really your call. I think the IANA considerations should also request IANA to start a registry for the sub-options (3.2.1 & 3.3.1)? Or, how will that space be managed? And, usually IANA wants to know how future values are to be assigned (standards action or ...) if it is charged with maintaining a registry. You'll get that comment during the IANA review if you don't include it. I also wonder whether anyone needs to manage the "id-type" space? Or will there never be any more of these values? Or, is that already something managed elsewhere in the Mobile IP WG documents (if so, providing a cross reference to that document would be useful). I'd also suggest that when FQDN's are mentioned (such as in 3.2.1, "When the sub-opt-code is set to 3, the Home Network Information field MUST contain the FQDN as described in [RFC1035]."), you reference RFC 3315, Section 8 regarding the encoding. Just saying "as described in [RFC1035]" doesn't tell anyone how it is encoded -- we want all FQDNs to be DNS wire encoded. In section 4.3, what's the value of "It may include Interface-Id option, Client Identifier option according to [RFC3315]." First, interface-id is usually a RELAY AGENT option (so it may be in the Relayed Information-Request), but I don't understand why pointing out these two options is necessary (there are a lot of other options that could be in an Information-Request or the Relay-Forw part of the message. Nothing in that section ever references using either of these options for anything. So, I'd drop that sentence. Similar text ("The mobile node SHALL also include the OPTION_CLIENTID [RFC3315] to identify itself to the DHCP server." and later "The relay agent MAY include the Interface-Id option [RFC3315] in the Relay-forward message.") is also in 4.1. - Bernie=20 -----Original Message----- From: Heejin Jang [mailto:heejin.jang@gmail.com]=20 Sent: Thursday, October 25, 2007 1:23 AM To: Bernie Volz (volz); David_Hankins@isc.org Cc: Alper Yegin; kchowdhury@starentnetworks.com; jinchoe@samsung.com; Basavaraj Patil; Gopal Dommety (gdommety); Ralph Droms (rdroms) Subject: Review request Hi, Bernie and David. We appreciate your concern and kind feedback for the hiopt draft. Your comments were helpful to improve the draft, and the authors has revised the draft based on your feedback. Could you review the revised one? If you kindly review the draft, it would be much of help. ps> AD's comments will be handled separately. - Best Regards, Heejin. ------_=_NextPart_001_01C822DE.00BAF1C5 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C822DE.00BAF1C5-- From dhcwg-bounces@ietf.org Fri Nov 09 11:08:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWPL-0002Lb-1k; Fri, 09 Nov 2007 11:08:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWPJ-0002Jk-Of; Fri, 09 Nov 2007 11:08:33 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqWPE-00031N-Jo; Fri, 09 Nov 2007 11:08:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 49C02108050; Fri, 9 Nov 2007 11:08:25 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06165-18; Fri, 9 Nov 2007 11:08:24 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP; Fri, 9 Nov 2007 11:08:24 -0500 (EST) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 11:07:25 -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: Fri, 9 Nov 2007 11:08:23 -0500 Message-ID: <4D35478224365146822AE9E3AD4A266687773D@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-mip6-hiopt Thread-Index: Acgi2TCM+DlyT7NUR4yrgeuV11dImQABHA/gAALmg4A= From: "Chowdhury, Kuntal" To: "Bernie Volz (volz)" , "Jari Arkko" , X-OriginalArrivalTime: 09 Nov 2007 16:07:25.0513 (UTC) FILETIME=[9E646390:01C822EA] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Mobile IPv6 Mailing List , Dhcwg Subject: [dhcwg] RE: AD review of draft-ietf-mip6-hiopt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Dear Bernie, Let me try to address some of your comments/questions. Please see inline... BR, Kuntal > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com] > Sent: Friday, November 09, 2007 8:37 AM > To: Jari Arkko; draft-ietf-mip6-hiopt@tools.ietf.org > Cc: Mobile IPv6 Mailing List; Dhcwg > Subject: RE: AD review of draft-ietf-mip6-hiopt >=20 > I did review a recent version of the draft - I'm not sure which revision > is now the latest. See the attached email regarding my most recent set > of comments. >=20 > - Bernie >=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, November 09, 2007 9:02 AM > To: draft-ietf-mip6-hiopt@tools.ietf.org; Bernie Volz (volz) > Cc: Mobile IPv6 Mailing List; Dhcwg > Subject: Re: AD review of draft-ietf-mip6-hiopt >=20 > Hi all, >=20 > I have reviewed the new version and it satisfies my AD review > concerns with the exception of the below minor issues. >=20 > Also, I expect that the draft also has to satisfy DHC WG's review, > and address the issues raised by Bernie. I have not looked > at those yet, Bernie have you? >=20 > >> id-type > >> > >> The type of Home Network Identifier: > >> > >> 0 Visited domain (local ASP) > >> > >> 1 Target MSP > >> > >> 2 No preference > >> > > > > This seems unnecessarily complicated. Is there some reason why you > could > > simply include the target MSP domain information if it is known or an > > empty string otherwise and be allocated a local ASP in that case? > > >=20 [KC>] Empty string w/o this id-type indication will be ambiguous since it won't convey the case for value 2 (no preference). No preference is a common way for the MN to convey to the network that it does not really have a preference for the domain from which it wants to bootstrap MIP6 info. > I still disagree that this is needed, but I'm not making this > a blocking comment if the WG wants to do it. > > >> 3.2. MIP6 Relay Agent Option > >> > >> This option carries the RADIUS or Diameter attributes that are > >> received at the NAS from the AAAH. The DHCP relay agent sends > this > >> option to the DHCP server in the Relay-Forward message. > >> > > It does not carry RADIUS or Diameter attributes (and nor should it). > > Please align this text with the actual subattributes that you have. > > > > Also, it is inappropriate to assume that the information can only come > > from AAA. Presumably we'd like the mechanisms to be general enough > that, > > for instance, manual configuration, link identifier, etc. could also > be > > used to determine what mobility domains are appropriate for this > client. > > >=20 > Text was changed, but it still assumes the data comes from AAAH only. > Suggested edit: >=20 [KC>] The text says "the NAS _may_ know this....". Therefore, other ways are allowed too, but nothing wrong in giving an example, IMHO. > OLD: > This option carries the home network information which was > transferred to the NAS from AAAH by using [I-D.ietf-mip6-radius]. > NEW: > This option carries the home network information for the mobile > node (the NAS may know this, for instance, through AAA by > using [I-D.ietf-mip6-radius]). >=20 > >> OPTION_MIP6-HNID (TBD) > >> > > Do you really have to mix underscore and dash in the same symbol? > > >=20 > Some of this still remains: OPTION_MIP6-HNINF (TBD). >=20 [KC>] We should fix these inconsistencies. > Jari _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 09 11:29:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWjd-0006F5-N6; Fri, 09 Nov 2007 11:29:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWjb-0006A9-LC; Fri, 09 Nov 2007 11:29:31 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqWja-0000Wi-TZ; Fri, 09 Nov 2007 11:29:31 -0500 X-IronPort-AV: E=Sophos;i="4.21,396,1188792000"; d="scan'208";a="136482174" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Nov 2007 11:29:15 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA9GTFE3016468; Fri, 9 Nov 2007 11:29:15 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA9GSvdS012773; Fri, 9 Nov 2007 16:29:07 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 11:29: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: Fri, 9 Nov 2007 11:29:00 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21058750FF@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266687773D$0001@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-mip6-hiopt Thread-Index: Acgi2TCM+DlyT7NUR4yrgeuV11dImQABHA/gAALmg4AAARLGgA== From: "Bernie Volz (volz)" To: "Chowdhury, Kuntal" , "Jari Arkko" , X-OriginalArrivalTime: 09 Nov 2007 16:29:01.0881 (UTC) FILETIME=[A3167290:01C822ED] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15534.002 X-TM-AS-Result: No--35.758200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4744; t=1194625755; x=1195489755; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20AD=20review=20of=20draft-ietf-mip6-hiopt |Sender:=20 |To:=20=22Chowdhury, =20Kuntal=22=20, =0A=2 0=20=20=20=20=20=20=20=22Jari=20Arkko=22=20, =0A=20=2 0=20=20=20=20=20=20; bh=J5b6x2jidGT14P4GxVBxrpPFwOFP0X2zYiAQnvIfviE=; b=GH2pzAkNj1oaH+hOLuSrNEZiDrZUwmrR9OsV8k628bZQWo3IzEIRxKX4bRICkTZj5SFLVf10 5KWreVRLaMVEZHLdAJWz886igbiV7WSZ/xQ1t49MoNFBnFaX/m6B+CDL; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: Mobile IPv6 Mailing List , Dhcwg Subject: [dhcwg] RE: AD review of draft-ietf-mip6-hiopt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org These comments were from Jari. Mine I sent separately on Nov 1st. - Bernie=20 -----Original Message----- From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 Sent: Friday, November 09, 2007 11:08 AM To: Bernie Volz (volz); Jari Arkko; draft-ietf-mip6-hiopt@tools.ietf.org Cc: Mobile IPv6 Mailing List; Dhcwg Subject: RE: AD review of draft-ietf-mip6-hiopt Dear Bernie, Let me try to address some of your comments/questions. Please see inline... BR, Kuntal > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com] > Sent: Friday, November 09, 2007 8:37 AM > To: Jari Arkko; draft-ietf-mip6-hiopt@tools.ietf.org > Cc: Mobile IPv6 Mailing List; Dhcwg > Subject: RE: AD review of draft-ietf-mip6-hiopt >=20 > I did review a recent version of the draft - I'm not sure which revision > is now the latest. See the attached email regarding my most recent set > of comments. >=20 > - Bernie >=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, November 09, 2007 9:02 AM > To: draft-ietf-mip6-hiopt@tools.ietf.org; Bernie Volz (volz) > Cc: Mobile IPv6 Mailing List; Dhcwg > Subject: Re: AD review of draft-ietf-mip6-hiopt >=20 > Hi all, >=20 > I have reviewed the new version and it satisfies my AD review > concerns with the exception of the below minor issues. >=20 > Also, I expect that the draft also has to satisfy DHC WG's review, > and address the issues raised by Bernie. I have not looked > at those yet, Bernie have you? >=20 > >> id-type > >> > >> The type of Home Network Identifier: > >> > >> 0 Visited domain (local ASP) > >> > >> 1 Target MSP > >> > >> 2 No preference > >> > > > > This seems unnecessarily complicated. Is there some reason why you > could > > simply include the target MSP domain information if it is known or an > > empty string otherwise and be allocated a local ASP in that case? > > >=20 [KC>] Empty string w/o this id-type indication will be ambiguous since it won't convey the case for value 2 (no preference). No preference is a common way for the MN to convey to the network that it does not really have a preference for the domain from which it wants to bootstrap MIP6 info. > I still disagree that this is needed, but I'm not making this > a blocking comment if the WG wants to do it. > > >> 3.2. MIP6 Relay Agent Option > >> > >> This option carries the RADIUS or Diameter attributes that are > >> received at the NAS from the AAAH. The DHCP relay agent sends > this > >> option to the DHCP server in the Relay-Forward message. > >> > > It does not carry RADIUS or Diameter attributes (and nor should it). > > Please align this text with the actual subattributes that you have. > > > > Also, it is inappropriate to assume that the information can only come > > from AAA. Presumably we'd like the mechanisms to be general enough > that, > > for instance, manual configuration, link identifier, etc. could also > be > > used to determine what mobility domains are appropriate for this > client. > > >=20 > Text was changed, but it still assumes the data comes from AAAH only. > Suggested edit: >=20 [KC>] The text says "the NAS _may_ know this....". Therefore, other ways are allowed too, but nothing wrong in giving an example, IMHO. > OLD: > This option carries the home network information which was > transferred to the NAS from AAAH by using [I-D.ietf-mip6-radius]. > NEW: > This option carries the home network information for the mobile > node (the NAS may know this, for instance, through AAA by > using [I-D.ietf-mip6-radius]). >=20 > >> OPTION_MIP6-HNID (TBD) > >> > > Do you really have to mix underscore and dash in the same symbol? > > >=20 > Some of this still remains: OPTION_MIP6-HNINF (TBD). >=20 [KC>] We should fix these inconsistencies. > Jari "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 09 12:31:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqXh6-00074T-3A; Fri, 09 Nov 2007 12:31:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqXh4-00073j-SB for dhcwg@ietf.org; Fri, 09 Nov 2007 12:30:58 -0500 Received: from [2001:4f8:3:bb::1:ee8b] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqXh3-0006k5-Uy for dhcwg@ietf.org; Fri, 09 Nov 2007 12:30:58 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id 6C4DF5A6ED; Fri, 9 Nov 2007 09:30:57 -0800 (PST) Date: Fri, 9 Nov 2007 09:30:57 -0800 From: "David W. Hankins" To: DHC WG Subject: Re: [dhcwg] dhc WG meeting in Vancouver Message-ID: <20071109173057.GF30659@isc.org> References: <2064072C-5AF5-447E-8266-57686DF824BF@cisco.com> <8E296595B6471A4689555D5D725EBB2105874F70@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <8E296595B6471A4689555D5D725EBB2105874F70@xmb-rtp-20a.amer.cisco.com> User-Agent: Mutt/1.5.9i X-Spam-Score: -0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0896413004==" Errors-To: dhcwg-bounces@ietf.org --===============0896413004== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w2JjAQZceEVGylhD" Content-Disposition: inline --w2JjAQZceEVGylhD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 08, 2007 at 11:30:18PM -0500, Bernie Volz (volz) wrote: > We need to give IANA information about updating the DHCP options > registry. Didn't we already provide that guidance in 3942 itself? --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --w2JjAQZceEVGylhD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHNJlRcXeLeWu2vmoRAvNfAJ9wfBeTaoCnSD+YsHz4DAGjPQWpFACdGDDc JhmI6221Q0iHWES5YKVww0A= =aCS1 -----END PGP SIGNATURE----- --w2JjAQZceEVGylhD-- --===============0896413004== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0896413004==-- From dhcwg-bounces@ietf.org Fri Nov 09 18:42:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqdUx-0000kE-Ln; Fri, 09 Nov 2007 18:42:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqdUw-0000jE-QD for dhcwg@ietf.org; Fri, 09 Nov 2007 18:42:50 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqdUs-0004EX-H6 for dhcwg@ietf.org; Fri, 09 Nov 2007 18:42:50 -0500 X-IronPort-AV: E=Sophos;i="4.21,397,1188770400"; d="scan'208";a="157318147" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Nov 2007 00:42:44 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA9NghZ1011693; Sat, 10 Nov 2007 00:42:43 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA9Ngh8i016631; Fri, 9 Nov 2007 23:42:43 GMT Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Nov 2007 00:42:43 +0100 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: Sat, 10 Nov 2007 00:43:41 +0100 Message-ID: In-Reply-To: <4733482A.7020302@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Thread-Index: AcgiLWJaSnrlhX2VQJGk3/bCV3Ew/AA+1RBA References: <4733482A.7020302@sun.com> From: "Benoit Lourdelet (blourdel)" To: "Brian Utterback" X-OriginalArrivalTime: 09 Nov 2007 23:42:43.0220 (UTC) FILETIME=[3903AD40:01C8232A] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15536.001 X-TM-AS-Result: No--36.464400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4001; t=1194651763; x=1195515763; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=blourdel@cisco.com; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20 |Subject:=20RE=3A=20[ntpwg]=20Network=20Time=20Protocol=20(NTP)=20Options =20for=20DHCPv6 |Sender:=20; bh=SMtOx68/6czsjDOy8sdBBP+Ia31NYNy43JGybD3Ttm4=; b=vBiAyoW5jZGUOn9kw/Ka2P2oW8GsZay9fiBSfEvgJ2MHnBtnGHUjQo9inuoT9KqMpy9vC2cy eTTwIAdLHoZdnRz0wPCRcNxiGVregptuY/QeQeYz9QG+FJ+z8X5iKcwy; Authentication-Results: ams-dkim-1; header.From=blourdel@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "Richard Gayraud \(rgayraud\)" Subject: [dhcwg] RE: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hello, A possible usage of all the NTP parameters specified in the new options is to configure router gateway . In that scenario, the goal of a Service Provider or an Enterprise IT is to autoconfigure the gateway as much as possible, including some NTP client behavior, in order to keep the control. An additional benefit is that the gateway can be shipped to remote sites virtually without any configuration while keeping full control of the NTP behavior. Following that line of thought, I may still see a need for "minpoll, maxpoll, I and B fields". Considering a central DHCP server, the use of remote-id [RFC4649] or just link-id may tell the server from where=20 the request is coming then giving it the knowledge of the delay to apply. In the case of a DHCP server hosted by the first hop, the DHCP server is well positioned to know the delay. Considering the current option format which includes more than IP addresses, the choice of multiple occurrences of the=20 same option looks sensible. Should we reduce the new options to IPv6 addresses only, a list makes more sense. Benoit -----Original Message----- From: Brian Utterback [mailto:brian.utterback@sun.com]=20 Sent: Thursday, November 08, 2007 6:32 PM To: Benoit Lourdelet (blourdel) Cc: ntpwg@lists.ntp.org; dhcwg@ietf.org; Richard Gayraud (rgayraud) Subject: Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 I think that you should eliminate the minpoll, maxpoll, I and B fields, which would mean you could eliminate the reserved field, although you might want to keep it. As a policy request, maxpoll is useless. How can you specify the maximum poll interval? That just doesn't make sense. The minpoll parameter make some sense, but since you are depending on the client implementation to obey it, it seems likely that any such implementation will either get minpoll right or not. If it gets it right, then the minpoll parameter is not needed, and if it gets it wrong then it probably won't be obeyed anyway. I just don't see the point in having the I field since that is pretty much a client side kind of issue. The use of the B field might be useful in some weird circumstances, but I don't see this as something that the server could know. The multicast looks okay as is, although I would suggest that there be advice to leave delay as 0 if possible. The proper delay doesn't seem to me to be likely to be known by the server and possibly different across a subnet. I am not sure about the idea of allowing multiple instances. Is that normal for DHCP? I understand the need to have multiple addresses returned, I would have thought a single list would have made more sense, but that is a DHCP thing, not a NTP thing, so I leave that to the DHCP experts. Benoit Lourdelet (blourdel) wrote: > Hello, >=20 > We have just submitted a new draft proposing an NTP option for DHCPv6. >=20 > The goal of this draft is to standardize automatic configuration of > NTPv4 (IPv6) clients over DHCPv6. > We think there is currently no satisfactory solution for configuring > NTPv4 clients from a centralized DHCPv6 server. >=20 > We'd be very happy to hear feedback about the draft, and I'm planning=20 > to ask that it becomes a WG draft eventually. >=20 > Here's a url: >=20 > =20 > http://www.ietf.org/internet-drafts/draft-gayraud-dhcpv6-ntp-opt-00.tx > t >=20 >=20 > Thanks, >=20 > Richard and Benoit > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 11 02:03:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ir6qY-0002Bb-J5; Sun, 11 Nov 2007 02:03:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ir6qX-00029m-Ry for dhcwg@ietf.org; Sun, 11 Nov 2007 02:03:05 -0500 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ir6qU-0002Wv-J3 for dhcwg@ietf.org; Sun, 11 Nov 2007 02:03:05 -0500 Received: by wa-out-1112.google.com with SMTP id k40so1736348wah for ; Sat, 10 Nov 2007 23:03:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=ZyAkVsLd9O0WPd/FzNpg7CnpqSM8hUgs3AXp36+FtoI=; b=rYec+eNx7gUGYJ+mHoulVEhHN1qRtwYyL/tOfIUfDhXIYpqr0tK4hhXBNPQd549x8uheW4tzicUIcRwDFDZ87qUQkPEDCokMG63Vw6zy/LIEC9FwizrEKi+cLHw5oowRHPZQfV/+P5KWZ/uYBKfe+yMaUSdaOVMfZKmE5Hf9Cpo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=DZQhi8KgOc5RLORbZJ5KTkfkVmkylHVJG54o4/RwnhdIQjPwZZ3szIKHPmFExInYHEVEo6TrH66qyrXCdxmwKRcMeEZLX1zbOiYNd+7gOdsmt5nvv+zoB26mSw3tvnIXfpJcMufKPsOo5Pfq9JbAX9FCnVKzcgatLIMeLyFuKV4= Received: by 10.114.159.1 with SMTP id h1mr899956wae.1194764581945; Sat, 10 Nov 2007 23:03:01 -0800 (PST) Received: by 10.114.193.3 with HTTP; Sat, 10 Nov 2007 23:03:01 -0800 (PST) Message-ID: Date: Sun, 11 Nov 2007 12:33:01 +0530 From: "ravi kumar" To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [dhcwg] RFC 3633 - Pefix Allotment by Servers X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org RFC 3633 does not specify regarding "How Delegating Router selects prefixes to be given to the clients" Is there a common algorithm followed by the Servers that support Prefix Delegation, for this purpose. >From the documentation of Dibbler, I found the foolowing algorithm: 1. client didn't provide any hints: one pre=0Cx from each pool will be gran= ted 2. client has provided hint and that is valid (supported and unused): requested pre=0Cx will be granted 3. client has provided hint, which belongs to supported pool, but this pre=0Cx is used: other pre=0Cx from that pool will be asigned 4. client has provided hint, but it is invalid (not beloninging to a supported pool, multicast or link- local): see point 1 I would like to know, if majority of Server implementations use the above algorithm to allot prefixes to the client. regards Ravi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 11 23:43:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrR8i-0005I9-34; Sun, 11 Nov 2007 23:43:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrR8h-0005HA-3l; Sun, 11 Nov 2007 23:43:11 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrR8f-0000wt-Vz; Sun, 11 Nov 2007 23:43:11 -0500 Received: from ep_ms5_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JRD008LYMDHI6@mailout1.samsung.com>; Mon, 12 Nov 2007 13:41:41 +0900 (KST) Received: from ep_spt01 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JRD00E5JMDGEP@ms5.samsung.com>; Mon, 12 Nov 2007 13:41:40 +0900 (KST) Content-return: prohibited Date: Mon, 12 Nov 2007 04:41:40 +0000 (GMT) From: Heejin Jang To: Jari Arkko , kchowdhury@starentnetworks.com, =?windows-1252?Q?=3F=3F=3F?= Message-id: <2090145.427831194842500257.JavaMail.weblogic@epml09> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20071112043502836@heejin.jang X-MTR: 20071112043502836@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: ML X-EPHeader: ML X-Spam-Score: 2.8 (++) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: "draft-ietf-mip6-hiopt@tools.ietf.org" , "Bernie Volz \(volz\)" , Dhcwg , Mobile IPv6 Mailing List Subject: [dhcwg] Re: Re: AD review of draft-ietf-mip6-hiopt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1161921240==" Errors-To: dhcwg-bounces@ietf.org --===============1161921240== Content-return: prohibited Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 SGksIEphcmkuDQoNCldlJ3ZlIHNlbnQgdGhlIHJlcGx5IGVtYWlsIHRvIEJlcm5pZSBpbiBOb3Yg NnRoLg0KU29ycnkgbm90IHRvIHBvc3QgaXQgaGVyZSBhbmQga2luZGx5IHNlZSB0aGUgYmVsb3cu DQoNCi0gQmVzdCBSZWdhcmRzLCANCkhlZWppbiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkhpLCBCZXJuaWUuDQoNClRoYW5rIHlv dSBmb3IgeW91ciBraW5kIGZlZWRiYWNrIGFnYWluLg0KDQpZb3VyIGZlZWJhY2sgaXMgcmVmbGVj dGVkIGluIHRoZSBkcmFmdC1pZXRmLW1pcDYtaGlvcHQtMDggKHdoaWNoIHdpbGwNCmJlIGFubm91 bmNlZCBpbiAyfjMgZGF5cyBsYXRlcikgYW5kIGtpbmRseSBzZWUgdGhlIGlubGluZSBjb21tZW50 IGFzIGENCnJlc3BvbnNlIHRvIHlvdXIgZmVlZGJhY2suDQoNCk9uIDExLzIvMDcsIEJlcm5pZSBW b2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb20+IHdyb3RlOg0KPiBJIGhhdmVuJ3QgaGFkIG11Y2gg dGltZSB0byBkbyBhIGNhcmVmdWwgcmV2aWV3LCBidXQgZnJvbSBhIHF1aWNrIHNjYW4NCj4gYXQg bGVhc3QgdGhlIERIQ1B2NiBvcHRpb25zIGFuZCBzdWJvcHRpb25zIGFyZSBub3cgZm9ybWF0dGVk IGFwcHJvcHJpYXRlbHkuDQo+DQo+IFRoZXJlJ3MgYSBsb3Qgb2YgcmVzZXJ2ZWQgZmllbGRzLCBh bmQgcGVyaGFwcyB0aGVyZSBhcmUgcGxhbnMgdG8gdXNlDQo+IHRoZW0sIGJ1dCB1c3VhbGx5IGl0 IGlzIGRpZmZpY3VsdCB0byBwcmVkaWN0IHRoZSBmdXR1cmUgYW5kIHNvbWV0aW1lcw0KPiBiZXN0 IHRvIHJlbW92ZSBzdHVmZiBsaWtlIHRoYXQuIEJ1dCwgaXQgaXMgeW91ciBjYWxsLg0KDQpPay4g V2UgZGVsZXRlZCB0aGUgcmVzZXJ2ZWQgZmllbGQgZnJvbSB0aGUgSE4gSWRlbnRpZmllciBvcHRp b24sIEhODQpJbmZvcm1hdGlvbiBvcHRpb24gYW5kIE1JUDYgUmVsYXkgQWdlbnQgc3ViLW9wdGlv bi4gQnV0IHRoZSByZXNlcnZlZA0KZmllbGQgaW4gSE4gSW5mb3JtYXRpb24gc3ViLW9wdGlvbiBp cyBtYWludGFpbmVkIGZvciBmdXR1cmUgdXNlLg0KDQo+IEkgYWxzbyB3b25kZXIgd2hldGhlciB0 aGUgMy4zLjEgSG9tZSBOZXR3b3JrIEluZm9ybWF0aW9uIHN1Yi1vcHRpb25zDQo+IG1pZ2h0IG5v dCBiZSAxIHRocm91Z2ggNiAoaW5zdGVhZCBvZiAxLTMpLCBhbmQgaW5jb3Jwb3JhdGUgdGhlIFYg Yml0DQo+IGludG8gdGhlIHN1Yi1vcHQtY29kZS4gUGVyaGFwcyB5b3UgZG9uJ3QgZXZlbiBuZWVk IGFsbCA2IHZhbHVlcyAobm90DQo+IHN1cmUgaWYgdGhleSBjYW4gYWxsIGhhdmUgYm90aCB2YWx1 ZXMgb2YgdGhlIFYgYml0KS4gQnV0LCB0aGF0J3MNCj4gcmVhbGx5IHlvdXIgY2FsbC4NCg0KSXQn cyBwb3NzaWJsZS4gQnV0IHRoZSBzdWItb3B0LWNvZGUgKDEtMykgaXMgdXNlZCB0byBpbmRpY2F0 ZSB3aGF0DQpraW5kIG9mIGhvbWUgbmV0d29yayBpbmZvcm1hdGlvbiBpcyBwcm92aWRlZCBhbmQg dGhlICdWJyBmbGFnIGlzDQppbmRpY2F0ZSB0aGUgcGxhY2Ugd2hlcmUgdGhlIGhvbWUgbmV0d29y ayBpbmZvcm1hdGlvbiBpcyBhc3NpZ25lZC4gU28NCndlIHRoaW5rIHdlJ2QgcmF0aGVyIG5vdCBt aXggdGhlbSB1cCBhbmQgcHJlZmVyIHRvIGtlZXAgdGhlIGV4aXN0aW5nDQptZXNzYWdlIGZvcm1h dC4NCg0KPiBJIHRoaW5rIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNob3VsZCBhbHNvIHJlcXVl c3QgSUFOQSB0byBzdGFydCBhDQo+IHJlZ2lzdHJ5IGZvciB0aGUgc3ViLW9wdGlvbnMgKDMuMi4x ICYgMy4zLjEpPyBPciwgaG93IHdpbGwgdGhhdCBzcGFjZQ0KPiBiZSBtYW5hZ2VkPyBBbmQsIHVz dWFsbHkgSUFOQSB3YW50cyB0byBrbm93IGhvdyBmdXR1cmUgdmFsdWVzIGFyZSB0bw0KPiBiZSBh c3NpZ25lZCAoc3RhbmRhcmRzIGFjdGlvbiBvciAuLi4pIGlmIGl0IGlzIGNoYXJnZWQgd2l0aA0K PiBtYWludGFpbmluZyBhIHJlZ2lzdHJ5LiBZb3UnbGwgZ2V0IHRoYXQgY29tbWVudCBkdXJpbmcg dGhlIElBTkEgcmV2aWV3DQo+IGlmIHlvdSBkb24ndCBpbmNsdWRlIGl0Lg0KDQpPay4gVGhlIHJl cXVlc3QgZm9yIHRoZSBzdWItb3B0LWNvZGUgaXMgYWRkZWQgaW50byB0aGUgSUFOQSBTZWN0aW9u IGFzIGZvbGxvd3MuDQoNCiJUaGUgU3ViLW9wdGlvbiBDb2RlcyBmb3IgYm90aCBPUFRJT05fTUlQ Nl9SRUxBWSBhbmQgT1BUSU9OX01JUDZfSE5JTkYNCm9wdGlvbnM6DQogICAgICBvIEhvbWUgbmV0 d29yayBwcmVmaXggICAgICAgMQ0KICAgICAgbyBIb21lIGFnZW50IGFkZHJlc3MgICAgICAgMg0K ICAgICAgbyBIb21lIGFnZW50IEZRRE4gICAgICAgICAgMw0KDQo+IEkgYWxzbyB3b25kZXIgd2hl dGhlciBhbnlvbmUgbmVlZHMgdG8gbWFuYWdlIHRoZSAiaWQtdHlwZSIgc3BhY2U/IE9yDQo+IHdp bGwgdGhlcmUgbmV2ZXIgYmUgYW55IG1vcmUgb2YgdGhlc2UgdmFsdWVzPyBPciwgaXMgdGhhdCBh bHJlYWR5DQo+IHNvbWV0aGluZyBtYW5hZ2VkIGVsc2V3aGVyZSBpbiB0aGUgTW9iaWxlIElQIFdH IGRvY3VtZW50cyAoaWYgc28sDQo+IHByb3ZpZGluZyBhIGNyb3NzIHJlZmVyZW5jZSB0byB0aGF0 IGRvY3VtZW50IHdvdWxkIGJlIHVzZWZ1bCkuDQoNCldlIHRoaW5rIHRoYXQgaXQgaXMgYmV0dGVy IHRvIGdpdmUgYSBmaWVsZCBpbiBITiBpbmZvcm1hdGlvbiBvcHRpb24NCmZvciBpbmRpY2F0aW5n IHRoZSBtb2JpbGUgbm9kZSdzIHByZWZlcmVuY2UgZm9yIHRoZSByZXF1ZXN0ZWQgaG9tZQ0KbmV0 d29yay4gQWRkaXRpb25hbGx5LCBpZiBESENQIGNhbiBrbm93IHRoZSBraW5kIG9mIGhvbWUgbmV0 d29yaw0KcmVxdWVzdGVkIGJ5IE1OIGV4cGxpY2l0bHksIGl0IGRvZXMgbm90IG5lZWQgdG8gdHJh bnNmZXIgdW5uZWNlc3NhcnkNCmluZm9ybWF0aW9uIHdoaWNoIGlzIG5vdCBpbiB0aGUgbW9iaWxl IG5vZGUncyBpbnRlcmVzdC4NCg0KPiBJJ2QgYWxzbyBzdWdnZXN0IHRoYXQgd2hlbiBGUUROJ3Mg YXJlIG1lbnRpb25lZCAoc3VjaCBhcyBpbiAzLjIuMSwNCj4gIldoZW4gdGhlIHN1Yi1vcHQtY29k ZSBpcyBzZXQgdG8gMywgdGhlIEhvbWUgTmV0d29yayBJbmZvcm1hdGlvbiBmaWVsZA0KPiBNVVNU IGNvbnRhaW4gdGhlIEZRRE4gYXMgZGVzY3JpYmVkIGluIFtSRkMxMDM1XS4iKSwgeW91IHJlZmVy ZW5jZSBSRkMNCj4gMzMxNSwgU2VjdGlvbiA4IHJlZ2FyZGluZyB0aGUgZW5jb2RpbmcuIEp1c3Qg c2F5aW5nICJhcyBkZXNjcmliZWQgaW4NCj4gW1JGQzEwMzVdIiBkb2Vzbid0IHRlbGwgYW55b25l IGhvdyBpdCBpcyBlbmNvZGVkIC0tIHdlIHdhbnQgYWxsIEZRRE5zDQo+IHRvIGJlIEROUyB3aXJl IGVuY29kZWQuDQoNCk9rLiBXZSByZWZlcnJlZCBTZWN0aW9uIDggb2YgUkZDMzMxNSBpbnN0ZWFk IG9mIFJGQzEwMzUgaW4gU2VjdGlvbiAzLjIuMS4NCg0KPiBJbiBzZWN0aW9uIDQuMywgd2hhdCdz IHRoZSB2YWx1ZSBvZiAiSXQgbWF5IGluY2x1ZGUgSW50ZXJmYWNlLUlkDQo+IG9wdGlvbiwgQ2xp ZW50IElkZW50aWZpZXIgb3B0aW9uIGFjY29yZGluZyB0byBbUkZDMzMxNV0uIiBGaXJzdCwNCj4g aW50ZXJmYWNlLWlkIGlzIHVzdWFsbHkgYSBSRUxBWSBBR0VOVCBvcHRpb24gKHNvIGl0IG1heSBi ZSBpbiB0aGUNCj4gUmVsYXllZCBJbmZvcm1hdGlvbi1SZXF1ZXN0KSwgYnV0IEkgZG9uJ3QgdW5k ZXJzdGFuZCB3aHkgcG9pbnRpbmcgb3V0DQo+IHRoZXNlIHR3byBvcHRpb25zIGlzIG5lY2Vzc2Fy eSAodGhlcmUgYXJlIGEgbG90IG9mIG90aGVyIG9wdGlvbnMgdGhhdA0KPiBjb3VsZCBiZSBpbiBh biBJbmZvcm1hdGlvbi1SZXF1ZXN0IG9yIHRoZSBSZWxheS1Gb3J3IHBhcnQgb2YgdGhlDQo+IG1l c3NhZ2UuIE5vdGhpbmcgaW4gdGhhdCBzZWN0aW9uIGV2ZXIgcmVmZXJlbmNlcyB1c2luZyBlaXRo ZXIgb2YgdGhlc2Ugb3B0aW9ucyBmb3IgYW55dGhpbmcuDQo+IFNvLCBJJ2QgZHJvcCB0aGF0IHNl bnRlbmNlLg0KPiBTaW1pbGFyIHRleHQgKCJUaGUgbW9iaWxlIG5vZGUgU0hBTEwgYWxzbyBpbmNs dWRlIHRoZSBPUFRJT05fQ0xJRU5USUQNCj4gW1JGQzMzMTVdIHRvIGlkZW50aWZ5IGl0c2VsZiB0 byB0aGUgREhDUCBzZXJ2ZXIuIiBhbmQgbGF0ZXIgIlRoZSByZWxheQ0KPiBhZ2VudCBNQVkgaW5j bHVkZSB0aGUgSW50ZXJmYWNlLUlkIG9wdGlvbiBbUkZDMzMxNV0gaW4gdGhlDQo+IFJlbGF5LWZv cndhcmQNCj4gbWVzc2FnZS4iKSBpcyBhbHNvIGluIDQuMS4NCg0KT2suIFdlIGRlbGV0ZWQgdGhl IHVubmVjZXNzYXJ5IG1lbnRpb24gZm9yIEludGVyZmFjZS1JZC9DbGllbnQtaWQNCm9wdGlvbiBh bmQgZGVzY3JpYmVkIHRoYXQgdGhlIE1OIGFuZCB0aGUgcmVsYXkgYWdlbnQgcHJvY2Vzc2VzIHRo ZQ0KbWVzc2FnZXMgYWNjb3JkaW5nIHRvIFJGQzMzMTUuIEhvd2V2ZXIsIHdlIGxlZnQgdGhlIGRl Y3J5cHRpb24gZm9yIHRoZQ0KQ2xpZW50LWlkIG9wdGlvbiBpbiBTZWN0aW9uIDQuMiBiZWNhdXNl IGl0IGlzIG5lY2Vzc2FyeSB0byBtZW50aW9uDQp0aGF0IHRoZSByZWxheSBhZ2VudCBzZWFyY2hl cyBmb3IgdGhlIHJlcXVlc3RlZCBITiBpbmZvcm1hdGlvbiBhbmQNCmFkZHMgdGhlIGNvcnJlc3Bv bmRpbmcgSE4gaW5mb3JtYXRpb24gaW50byB0aGUgcmVjZWl2ZWQgbWVzc2FnZSBieQ0KdXNpbmcg dGhlIENsaWVudC1pZCBhcyBhIGtleS4NCg0KLSBCZXN0IHJlZ2FyZHMsDQpIZWVqaW4NCg0KPiAt IEJlcm5pZQ0KPg0KDQotLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLQ0KU2VuZGVyIDog SmFyaSBBcmtrbzxqYXJpLmFya2tvQHBpdWhhLm5ldD4NCkRhdGUgICA6IDIwMDctMTEtMDkgMjM6 MDIgKEdNVCswOTowMCkNClRpdGxlICA6IFJlOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1taXA2 LWhpb3B0DQoNCkhpIGFsbCwNCg0KSSBoYXZlIHJldmlld2VkIHRoZSBuZXcgdmVyc2lvbiBhbmQg aXQgc2F0aXNmaWVzIG15IEFEIHJldmlldw0KY29uY2VybnMgd2l0aCB0aGUgZXhjZXB0aW9uIG9m IHRoZSBiZWxvdyBtaW5vciBpc3N1ZXMuDQoNCkFsc28sIEkgZXhwZWN0IHRoYXQgdGhlIGRyYWZ0 IGFsc28gaGFzIHRvIHNhdGlzZnkgREhDIFdHJiMzOTtzIHJldmlldywNCmFuZCBhZGRyZXNzIHRo ZSBpc3N1ZXMgcmFpc2VkIGJ5IEJlcm5pZS4gSSBoYXZlIG5vdCBsb29rZWQNCmF0IHRob3NlIHll dCwgQmVybmllIGhhdmUgeW91Pw0KDQo+PiAgICAgICAgIGlkLXR5cGUNCj4+DQo+PiAgICAgICAg ICAgIFRoZSB0eXBlIG9mIEhvbWUgTmV0d29yayBJZGVudGlmaWVyOg0KPj4NCj4+ICAgICAgICAg ICAgICAgIDAgICAgVmlzaXRlZCBkb21haW4gKGxvY2FsIEFTUCkNCj4+DQo+PiAgICAgICAgICAg ICAgICAxICAgIFRhcmdldCBNU1ANCj4+DQo+PiAgICAgICAgICAgICAgICAyICAgIE5vIHByZWZl cmVuY2UNCj4+ICAgICANCj4NCj4gVGhpcyBzZWVtcyB1bm5lY2Vzc2FyaWx5IGNvbXBsaWNhdGVk LiBJcyB0aGVyZSBzb21lIHJlYXNvbiB3aHkgeW91IGNvdWxkDQo+IHNpbXBseSBpbmNsdWRlIHRo ZSB0YXJnZXQgTVNQIGRvbWFpbiBpbmZvcm1hdGlvbiBpZiBpdCBpcyBrbm93biBvciBhbg0KPiBl bXB0eSBzdHJpbmcgb3RoZXJ3aXNlIGFuZCBiZSBhbGxvY2F0ZWQgYSBsb2NhbCBBU1AgaW4gdGhh dCBjYXNlPw0KPiAgIA0KDQpJIHN0aWxsIGRpc2FncmVlIHRoYXQgdGhpcyBpcyBuZWVkZWQsIGJ1 dCBJJiMzOTttIG5vdCBtYWtpbmcgdGhpcw0KYSBibG9ja2luZyBjb21tZW50IGlmIHRoZSBXRyB3 YW50cyB0byBkbyBpdC4NCg0KPj4gMy4yLiAgTUlQNiBSZWxheSBBZ2VudCBPcHRpb24NCj4+DQo+ PiAgICBUaGlzIG9wdGlvbiBjYXJyaWVzIHRoZSBSQURJVVMgb3IgRGlhbWV0ZXIgYXR0cmlidXRl cyB0aGF0IGFyZQ0KPj4gICAgcmVjZWl2ZWQgYXQgdGhlIE5BUyBmcm9tIHRoZSBBQUFILiAgVGhl IERIQ1AgcmVsYXkgYWdlbnQgc2VuZHMgdGhpcw0KPj4gICAgb3B0aW9uIHRvIHRoZSBESENQIHNl cnZlciBpbiB0aGUgUmVsYXktRm9yd2FyZCBtZXNzYWdlLg0KPj4gICAgIA0KPiBJdCBkb2VzIG5v dCBjYXJyeSBSQURJVVMgb3IgRGlhbWV0ZXIgYXR0cmlidXRlcyAoYW5kIG5vciBzaG91bGQgaXQp Lg0KPiBQbGVhc2UgYWxpZ24gdGhpcyB0ZXh0IHdpdGggdGhlIGFjdHVhbCBzdWJhdHRyaWJ1dGVz IHRoYXQgeW91IGhhdmUuDQo+DQo+IEFsc28sIGl0IGlzIGluYXBwcm9wcmlhdGUgdG8gYXNzdW1l IHRoYXQgdGhlIGluZm9ybWF0aW9uIGNhbiBvbmx5IGNvbWUNCj4gZnJvbSBBQUEuIFByZXN1bWFi bHkgd2UmIzM5O2QgbGlrZSB0aGUgbWVjaGFuaXNtcyB0byBiZSBnZW5lcmFsIGVub3VnaCB0aGF0 LA0KPiBmb3IgaW5zdGFuY2UsIG1hbnVhbCBjb25maWd1cmF0aW9uLCBsaW5rIGlkZW50aWZpZXIs IGV0Yy4gY291bGQgYWxzbyBiZQ0KPiB1c2VkIHRvIGRldGVybWluZSB3aGF0IG1vYmlsaXR5IGRv bWFpbnMgYXJlIGFwcHJvcHJpYXRlIGZvciB0aGlzIGNsaWVudC4NCj4gICANCg0KVGV4dCB3YXMg Y2hhbmdlZCwgYnV0IGl0IHN0aWxsIGFzc3VtZXMgdGhlIGRhdGEgY29tZXMgZnJvbSBBQUFIIG9u bHkuDQpTdWdnZXN0ZWQgZWRpdDoNCg0KT0xEOg0KICAgVGhpcyBvcHRpb24gY2FycmllcyB0aGUg aG9tZSBuZXR3b3JrIGluZm9ybWF0aW9uIHdoaWNoIHdhcw0KICAgdHJhbnNmZXJyZWQgdG8gdGhl IE5BUyBmcm9tIEFBQUggYnkgdXNpbmcgW0ktRC5pZXRmLW1pcDYtcmFkaXVzXS4NCk5FVzoNCiAg IFRoaXMgb3B0aW9uIGNhcnJpZXMgdGhlIGhvbWUgbmV0d29yayBpbmZvcm1hdGlvbiBmb3IgdGhl IG1vYmlsZQ0KICAgbm9kZSAodGhlIE5BUyBtYXkga25vdyB0aGlzLCBmb3IgaW5zdGFuY2UsIHRo cm91Z2ggQUFBIGJ5DQogICB1c2luZyBbSS1ELmlldGYtbWlwNi1yYWRpdXNdKS4NCg0KPj4gICAg ICAgICAgICBPUFRJT05fTUlQNi1ITklEIChUQkQpDQo+PiAgICAgDQo+IERvIHlvdSByZWFsbHkg aGF2ZSB0byBtaXggdW5kZXJzY29yZSBhbmQgZGFzaCBpbiB0aGUgc2FtZSBzeW1ib2w/DQo+ICAg DQoNClNvbWUgb2YgdGhpcyBzdGlsbCByZW1haW5zOiBPUFRJT05fTUlQNi1ITklORiAoVEJEKS4N Cg0KSmFyaQ0KDQoNCg0K --===============1161921240== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1161921240==-- From dhcwg-bounces@ietf.org Mon Nov 12 01:55:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrTCT-0006XM-Eb; Mon, 12 Nov 2007 01:55:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrTCS-0006Wz-QJ for dhcwg@ietf.org; Mon, 12 Nov 2007 01:55:12 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrTCP-00044h-IX for dhcwg@ietf.org; Mon, 12 Nov 2007 01:55:12 -0500 Received: by ug-out-1314.google.com with SMTP id u2so1994186uge for ; Sun, 11 Nov 2007 22:55:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=rmUD/cQc8p1yie8DdIQzKIzi/dDoSDiOXXXWHtad3Zk=; b=IK8DX4ntNOj51scV2pw1p81ZYAStyvRaoboviG5/tMXd6zO99+IcjbuYGtLC6S4XfHkBvSSer7f269Bg3T+KcRUyOVg5RNuQq040sV/J1+I4fx3m5EuLtQQYHurd7QnUdK+lVxr6mmtPc1fnUJwf/NVO06TZffdSHakNKd1dDv4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DyXKjuLKOTfaG3q95CXxol5PktX1NtpVP/+/YlDVf9nECDVjlltzBYvK2ccP+cCuK+65QlMu2GYpp6OBXtX9zkNfgyNs1eklEuLx9hRDAWkiwzCQZurijtgMoPMq3Q3qG8tKBADEdFzSbOCbM522CRzgAb73xKDEx5fD10H1I5o= Received: by 10.67.122.12 with SMTP id z12mr2060720ugm.1194850508833; Sun, 11 Nov 2007 22:55:08 -0800 (PST) Received: by 10.66.250.19 with HTTP; Sun, 11 Nov 2007 22:55:08 -0800 (PST) Message-ID: Date: Mon, 12 Nov 2007 12:25:08 +0530 From: "ravi kumar" To: dhcwg@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [dhcwg] Re: RFC 3633 - Pefix Allotment by Servers X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org regards Ravi On Nov 11, 2007 12:33 PM, ravi kumar wrote: > RFC 3633 does not specify regarding "How Delegating Router selects > prefixes to be given to the clients" > Is there a common algorithm followed by the Servers that support > Prefix Delegation, for this purpose. > > From the documentation of Dibbler, I found the foolowing algorithm: > > 1. client didn't provide any hints: one pre x from each pool will be granted > 2. client has provided hint and that is valid (supported and unused): > requested pre x will be granted > 3. client has provided hint, which belongs to supported pool, but this > pre x is used: other pre x from > that pool will be asigned > 4. client has provided hint, but it is invalid (not beloninging to a > supported pool, multicast or link- > local): see point 1 > > I would like to know, if majority of Server implementations use the > above algorithm to allot prefixes to the client. > > regards > Ravi > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 12 09:04:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZu7-0001hx-5m; Mon, 12 Nov 2007 09:04:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZu6-0001hm-Ij for dhcwg@ietf.org; Mon, 12 Nov 2007 09:04:42 -0500 Received: from exchdev.pega.com ([198.22.153.35] helo=exchdev.rpega.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrZu1-0005NN-R4 for dhcwg@ietf.org; Mon, 12 Nov 2007 09:04:42 -0500 Received: from [10.60.98.37] ([10.60.98.37]) by exchdev.rpega.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Nov 2007 09:04:36 -0500 Message-ID: <47385CDE.7010700@ntp.org> Date: Mon, 12 Nov 2007 09:02:06 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Benoit Lourdelet (blourdel)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Nov 2007 14:04:36.0954 (UTC) FILETIME=[F5A0C3A0:01C82534] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "Richard Gayraud \(rgayraud\)" Subject: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org [This is a resend since the dhcpwg SMTP list server rejected my email for no obvious reason] Benoit Lourdelet (blourdel) wrote: > Hello, > > We have just submitted a new draft proposing an NTP option for DHCPv6. > > The goal of this draft is to standardize automatic configuration of > NTPv4 (IPv6) clients over DHCPv6. > We think there is currently no satisfactory solution for configuring > NTPv4 clients from a centralized DHCPv6 server. > > We'd be very happy to hear feedback about the draft, and I'm planning to > ask that it becomes a WG draft eventually. > > Here's a url: > > > http://www.ietf.org/internet-drafts/draft-gayraud-dhcpv6-ntp-opt-00.txt I reviewed this draft, even though I'm in the middle of reviewing the autokey draft, and I find it misconceived. 1) The draft seems geared to only the reference implementation of NTP rather than being implementation agnostic. There is also reference to SNTP which the reference implementation is not and in any case SNTP implementations are likely to have different terms and requirements for configuration. 2) The server must never be specified as an IP address but always as a DNS name. If you wish to use only IPv6 there are options to do so. It is easy to configure a DNS server for the specific purpose if it is local to the site. We have had too many incidents of hardcoded addresses which cause major incorrect usage of ntp servers not to mention clients that continue to try and use the same server months and even years after it has stopped being an NTP server. The only time you might use an IPv6 address here is if the address is site-local or link-local. A future enhancement to the reference implementation will requery the DNS for new address information in the case of failure of responses from the configured NTP server and will allow easy migration of NTP services. This also ignores the pool option now available in the development NTP reference code. 3) The additional fields that you specify should *never* be set unless you understand exactly what you are doing. We always recommend the use of iburst (and not i-burst BTW) so it's not necessary to specify this. The use of burst contradicts the last sentence of the last paragraph of Section 2.1. The use of minpoll and maxpoll is similarly bad for exactly the same reasons. You need to have very special reasons to set these to anything other than the default. 4) There is no autokey option even though the Section 6 discusses security considerations which seem to be for DHCPv6 only without any consideration whatsoever for NTP. These packet options provide a convenient way of distributing autokey keys to the clients but it is not an option under this draft 5) The multicast option similarly has flaws. The only practical values are FF02::101 and FF05::101 which are reserved for NTP usage unless you are planning to use other ones. The delay however is position-dependent on the wire and a DHCPv6 server is never going to know what that delay is likely to be so there is no way for it to determine what to set it to. 6) I have not read either RFC 3315 or RFC4075 but section 6 Security Considerations totally ignores NTP and other time issues. If you are provisioning NTP on the client you *cannot* use any authentication mechanism that assumes that the time on the client has any valid value. Furthermore there is nothing to prevent the client receiving invalid NTP configuration options. If DHCPv6 itself is using time-dependent authentication mechanisms it is flawed, possibly fatally so since the client will not have the correct time in the first place. I see no way to fix this nor how to prevent a rogue system sending its own packets and having them accepted as valid. I'm going to stop here but I recommend that this draft does not proceed and needs to be totally rewritten. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 12 09:29:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IraIT-0000bZ-EI; Mon, 12 Nov 2007 09:29:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IraIR-0000ad-EJ for dhcwg@ietf.org; Mon, 12 Nov 2007 09:29:51 -0500 Received: from owl.ecs.soton.ac.uk ([2001:630:d0:f102:230:48ff:fe77:96e]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IraIR-0006GE-01 for dhcwg@ietf.org; Mon, 12 Nov 2007 09:29:51 -0500 X-ECS-MailScanner-Watermark: 1195482583.68458@YaCxWlMgmbszGs9qDwTTjA Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe78:67b5]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id lACEThnf032750; Mon, 12 Nov 2007 14:29:43 GMT X-ECS-MailScanner-Watermark: 1195482417.83168@Dfkgnf3X9vT70AnO4xr8hg Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe59:5f12]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id lACEQvVY017981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2007 14:26:57 GMT Received: from login.ecs.soton.ac.uk (localhost.localdomain [127.0.0.1]) by login.ecs.soton.ac.uk (8.13.8/8.11.6) with ESMTP id lACETbck010690; Mon, 12 Nov 2007 14:29:37 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.13.8/8.13.8/Submit) id lACETbWM010689; Mon, 12 Nov 2007 14:29:37 GMT Date: Mon, 12 Nov 2007 14:29:37 +0000 From: Tim Chown To: v6ops@ops.ietf.org, dhcwg@ietf.org Message-ID: <20071112142937.GO27247@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org, dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-ECS-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Spam-Score: -1.4 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [dhcwg] Regarding I-D Action:draft-chown-v6ops-rogue-ra-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi, A heads-up that to complement Gunter et al's RA-Guard draft, I have submitted a problem statement draft based on IETF-69 discussions and subsequent list discussions. This captures comments on problem scenarios, possible solutions, and includes potential new DHCPv6 features. This discussions also highlighted a possible requirement for a DHCPv6 option for on-link prefixes, which should probably be taken forward in the DHC WG. The details are as follows: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Rogue IPv6 Router Advertisement Problem Statement Author(s) : T. Chown, S. Venaas Filename : draft-chown-v6ops-rogue-ra-00.txt Pages : 9 Date : 2007-11-12 When deploying IPv6 networks, whether IPv6-only or dual-stack, routers are configured to use IPv6 Router Advertisements to convey information to on link nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the Router Advertisement (RA) message. However, in some networks 'bogus' RAs are observed, which may be present due to misconfigurations or possibly malicious attacks on the network. In this draft we summarise the scenarios in which rogue RAs may be observed, and we present a list of possible solutions to the problem. The goal of this draft is to present a framework around which solutions can be proposed and discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chown-v6ops-rogue-ra-00.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 12 09:31:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IraK8-0003f0-7E; Mon, 12 Nov 2007 09:31:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IraK6-0003ek-Lw for dhcwg@ietf.org; Mon, 12 Nov 2007 09:31:34 -0500 Received: from intermail.se.dataphone.net ([212.37.1.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IraK6-0001om-6H for dhcwg@ietf.org; Mon, 12 Nov 2007 09:31:34 -0500 Received: from [213.115.152.226] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.2) with ESMTP id 50761838 for dhcwg@ietf.org; Mon, 12 Nov 2007 15:31:32 +0100 From: Bud Millwood Organization: Weird Solutions, Inc. To: dhcwg@ietf.org Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Date: Mon, 12 Nov 2007 14:47:09 +0100 User-Agent: KMail/1.8 References: <47385CDE.7010700@ntp.org> In-Reply-To: <47385CDE.7010700@ntp.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711121447.09978.budm@weird-solutions.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bud Millwood List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Monday 12 November 2007 15:02, Danny Mayer wrote: > [This is a resend since the dhcpwg SMTP list server rejected my email > for no obvious reason] > > Benoit Lourdelet (blourdel) wrote: > > Hello, > > > > We have just submitted a new draft proposing an NTP option for DHCPv6. > > > > The goal of this draft is to standardize automatic configuration of > > NTPv4 (IPv6) clients over DHCPv6. > > We think there is currently no satisfactory solution for configuring > > NTPv4 clients from a centralized DHCPv6 server. > > > > We'd be very happy to hear feedback about the draft, and I'm planning to > > ask that it becomes a WG draft eventually. > > > > Here's a url: > > > > > > http://www.ietf.org/internet-drafts/draft-gayraud-dhcpv6-ntp-opt-00.txt > > 2) The server must never be specified as an IP address but always as a > DNS name. If you wish to use only IPv6 there are options to do so. It is > easy to configure a DNS server for the specific purpose if it is local > to the site. We have had too many incidents of hardcoded addresses which > cause major incorrect usage of ntp servers not to mention clients that > continue to try and use the same server months and even years after it > has stopped being an NTP server. I suppose the argument here is not against provisioning services by IP address, but doing so across organizational lines, i.e. when you provide the service but don't provision the clients. In my experience NTP is one of those services, in which case I'd have to agree that it's a good idea to change this option from 'address' to 'DNS name'. - Bud Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 12 11:10:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irbrj-0005Ur-U4; Mon, 12 Nov 2007 11:10:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irbrj-0005UY-7J for dhcwg@ietf.org; Mon, 12 Nov 2007 11:10:23 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irbrf-00029y-Ub for dhcwg@ietf.org; Mon, 12 Nov 2007 11:10:23 -0500 Received: by ug-out-1314.google.com with SMTP id u2so2172829uge for ; Mon, 12 Nov 2007 08:10:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=3FdTWLCmNUCEldzCWCS2ubrIEhCpkLDfM2yqsWpyL9A=; b=gnWQuA55g2JUchRNSSQWASMGbSlg87tJNcOKDDkWG5MtOB/1Pr/2xe9O3oRqnDnMN9rDqTb9JgD/W6WI99Z23L+Yr2gvL81c1RWFWqvaPpufTqvjH1kvZyCy4SMvemyGcuN6MgDkD2MHEYKzUCuLoa53ZJWmgP6vQsjzIAQMJHQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=NhB1IacGiZ6tcD66EHR6SfeTG/cEKocyjg0vmyDMRufxIPJGB/3BV4fm5042L8cOU5M9/5ZHV8u6wHxodMN9BlKWi05iV7fs3c8+mIeag7VynGjszslM0xZ0BhNwWVaqJtSV+6f4u+DVcs/vVTSmj7I6N0kMUiX0vvwGTSQg25w= Received: by 10.66.238.16 with SMTP id l16mr44772ugh.1194883819237; Mon, 12 Nov 2007 08:10:19 -0800 (PST) Received: by 10.66.250.19 with HTTP; Mon, 12 Nov 2007 08:10:19 -0800 (PST) Message-ID: Date: Mon, 12 Nov 2007 21:40:19 +0530 From: "ravi kumar" To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [dhcwg] RFC 3315 Clarification : Renewing a prefix X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I need clarification regarding the following from RFC 3315: If a client obtains multiple ipv6 addresses from DHCP server, Is it possible to selectively renew only few addresses. For instance: Client obtains the addresses Addr1,Addr2,Addr3 from DHCP Server. If client sends RENEW for Addr1 alone, do Server renew all the addresses / Renews only the address sent by the client. RFC 3315 specifies that " The client includes an IA option with all addresses currently assigned to the IA in its Renew message". It is not mentioned clearly in rfc the server behaviour, if client doesnot include all the addresses obtained from Server, in RENEW message. Can someone please clarify this! regards Ravi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 12 11:12:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irbu3-0001Fz-Lg; Mon, 12 Nov 2007 11:12:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irbu2-0001Cf-GK for dhcwg@ietf.org; Mon, 12 Nov 2007 11:12:46 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irbty-0002EM-1u for dhcwg@ietf.org; Mon, 12 Nov 2007 11:12:46 -0500 Received: by ug-out-1314.google.com with SMTP id u2so2174706uge for ; Mon, 12 Nov 2007 08:12:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=62RwlFEAoG+j6Zj/J45PEEofUN2MzMQgOpo0H2ZqQm8=; b=mX/XUEeXVEh81GZ6GHwbJBBbhb0ciTbql3RvBbpO1btUU3yeWAH8h+2xJOF/o2iW4uoRJa1PwgyUhXTztDqB6FtwmbDGAvQ798AJPOfX0MduJQfN/12AS6ssGRFHhTLqej7VILH10w6/CmQFOY7Ef+CqPy5mwyUZvWDIyqy0GNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=HZ50G+EZbLSg+LWsJNb0CjoPQbmL2lAg215EP+s1gGffr4vUtPWirCvJn+EWXlQVbQ9OT6cX14BlG2YhYC60ztXRbDGoSzmDtOtpLSNu94f/y4INlQeh7Hv+cOsOT08do+u//55yk9tOMEnySJ63lH/jfun0keuk08+4AiLdk+I= Received: by 10.66.249.8 with SMTP id w8mr367375ugh.1194883961232; Mon, 12 Nov 2007 08:12:41 -0800 (PST) Received: by 10.66.250.19 with HTTP; Mon, 12 Nov 2007 08:12:39 -0800 (PST) Message-ID: Date: Mon, 12 Nov 2007 21:42:39 +0530 From: "ravi kumar" To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [dhcwg] Re: RFC 3315 Clarification : Renewing ipv6 addresses selectively X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Changed subject of mail. regards Ravi On Nov 12, 2007 9:40 PM, ravi kumar wrote: > I need clarification regarding the following from RFC 3315: > > If a client obtains multiple ipv6 addresses from DHCP server, Is it > possible to selectively renew only few addresses. > > For instance: > Client obtains the addresses Addr1,Addr2,Addr3 from DHCP Server. > If client sends RENEW for Addr1 alone, do Server renew all the > addresses / Renews only the address sent by the client. > > RFC 3315 specifies that " The client includes an IA option with all > addresses currently assigned to the IA in its Renew message". > It is not mentioned clearly in rfc the server behaviour, if client > doesnot include all the addresses obtained from Server, in RENEW > message. > > Can someone please clarify this! > > regards > Ravi > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 12 11:44:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcP8-0001mK-Gs; Mon, 12 Nov 2007 11:44:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcP7-0001jO-IZ for dhcwg@ietf.org; Mon, 12 Nov 2007 11:44:53 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrcP3-0003O3-GE for dhcwg@ietf.org; Mon, 12 Nov 2007 11:44:53 -0500 Received: from [10.6.126.250] (unknown [206.128.65.108]) by toccata.fugue.com (Postfix) with ESMTP id 48B35BC437D for ; Mon, 12 Nov 2007 09:44:48 -0700 (MST) Subject: Re: [dhcwg] RFC 3315 Clarification : Renewing a prefix From: Ted Lemon To: dhcwg@ietf.org In-Reply-To: References: Content-Type: text/plain Date: Mon, 12 Nov 2007 09:44:48 -0700 Message-Id: <1194885888.6571.2.camel@uma> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Mon, 2007-11-12 at 08:10 -0800, ravi kumar wrote: > If a client obtains multiple ipv6 addresses from DHCP server, Is it > possible to selectively renew only few addresses. The server is really in control of what prefixes and addresses get sent back to the client, so no, I don't think the client can control which addresses it renews in this way. Anyway, when would you do this? It might help to say what underlying problem you're trying to solve here. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 12 17:20:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrhdW-0002Qh-Cj; Mon, 12 Nov 2007 17:20:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrhdV-0002Qc-J0 for dhcwg@ietf.org; Mon, 12 Nov 2007 17:20:05 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrhdV-0006FK-7U for dhcwg@ietf.org; Mon, 12 Nov 2007 17:20:05 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 12 Nov 2007 17:20:05 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lACMK4nU012739; Mon, 12 Nov 2007 17:20:04 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lACMK0V5007999; Mon, 12 Nov 2007 22:20:04 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Nov 2007 17:20:03 -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 Subject: RE: [dhcwg] Re: RFC 3633 - Pefix Allotment by Servers Date: Mon, 12 Nov 2007 17:20:01 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21058757E4@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Re: RFC 3633 - Pefix Allotment by Servers Thread-Index: Acgk+P9bPY37/xUtRtu70tLB/yE7/wAgPBJg From: "Bernie Volz (volz)" To: "ravi kumar" , X-OriginalArrivalTime: 12 Nov 2007 22:20:03.0137 (UTC) FILETIME=[2BD05310:01C8257A] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15540.002 X-TM-AS-Result: No--16.155900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1559; t=1194906004; x=1195770004; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Re=3A=20RFC=203633=20-=20Pefix=20Allotment= 20by=20Servers |Sender:=20 |To:=20=22ravi=20kumar=22=20,=20; bh=Sj+OT1DV7mB2r4fMpZTLUYNsLalqRMyAbSDpiNVDzXU=; b=NtqqIE8i8/KXsX2vHYkWN8v7cavlfiHAJV4vF4M+m6sOGxHipKyRNZ8xswlOnLqiMWqLF4QT dYMYmkD1h7084u6lLeH87CfCtwmCaaNxPTkhmuDq3FeYYqE4Qhz4w4Wr; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org This is server policy and up to the server implementation. 3315 doesn't detail how addresses are "generated". Some servers may use sequential assignment. Others randomly generated. - Bernie=20 -----Original Message----- From: ravi kumar [mailto:ravikumar.lrk@gmail.com]=20 Sent: Monday, November 12, 2007 1:55 AM To: dhcwg@ietf.org Subject: [dhcwg] Re: RFC 3633 - Pefix Allotment by Servers regards Ravi On Nov 11, 2007 12:33 PM, ravi kumar wrote: > RFC 3633 does not specify regarding "How Delegating Router selects > prefixes to be given to the clients" > Is there a common algorithm followed by the Servers that support > Prefix Delegation, for this purpose. > > From the documentation of Dibbler, I found the foolowing algorithm: > > 1. client didn't provide any hints: one pre x from each pool will be granted > 2. client has provided hint and that is valid (supported and unused): > requested pre x will be granted > 3. client has provided hint, which belongs to supported pool, but this > pre x is used: other pre x from > that pool will be asigned > 4. client has provided hint, but it is invalid (not beloninging to a > supported pool, multicast or link- > local): see point 1 > > I would like to know, if majority of Server implementations use the > above algorithm to allot prefixes to the client. > > regards > Ravi > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 12 17:21:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irhf8-00041I-Tl; Mon, 12 Nov 2007 17:21:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irhf7-00040Q-RG for dhcwg@ietf.org; Mon, 12 Nov 2007 17:21:45 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irhf3-0008Ps-93 for dhcwg@ietf.org; Mon, 12 Nov 2007 17:21:45 -0500 X-IronPort-AV: E=Sophos;i="4.21,407,1188802800"; d="scan'208";a="31759595" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 12 Nov 2007 14:21:40 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lACMLe5o006699; Mon, 12 Nov 2007 14:21:40 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lACMLeIw013182; Mon, 12 Nov 2007 22:21:40 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Nov 2007 17:21:35 -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 Subject: RE: [dhcwg] Re: RFC 3633 - Pefix Allotment by Servers Date: Mon, 12 Nov 2007 17:21:33 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21058757E7@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Re: RFC 3633 - Pefix Allotment by Servers Thread-Index: Acgk+P9bPY37/xUtRtu70tLB/yE7/wAgPBJgAAAQBSA= From: "Bernie Volz (volz)" To: "ravi kumar" , X-OriginalArrivalTime: 12 Nov 2007 22:21:35.0502 (UTC) FILETIME=[62DE1AE0:01C8257A] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15540.002 X-TM-AS-Result: No--15.620300-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2025; t=1194906100; x=1195770100; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Re=3A=20RFC=203633=20-=20Pefix=20Allotment= 20by=20Servers |Sender:=20; bh=ccg6ZRXpl0EVGrF+1OLjsUWaZ00P+iyvz7q/i3Hi8pI=; b=NCjBzmXgrB/Ufaho+EMj+KW/h9XLqMWTaLkMom/2+55O5pgaXw0f5zpe0YNFpBrymHj8VpAk Gjyt/0KbEBHXBqSIdFb3UCIW/2ub4DOezFVnefB8iK7d5e/pD/VsTOg43KyMohCXDTWwTrfjLW +ghnk7PY1C3Ea1t5ElqskqxvA=; Authentication-Results: sj-dkim-1; header.From=volz@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Oh, I should have added that the server should provide multiple prefixes if that is what's been configured -- the device could be multi-homed or there could be a renumbering event sometime in the future and thus multiple prefixes may indeed be active and valid. -----Original Message----- From: Bernie Volz (volz)=20 Sent: Monday, November 12, 2007 5:20 PM To: 'ravi kumar'; dhcwg@ietf.org Subject: RE: [dhcwg] Re: RFC 3633 - Pefix Allotment by Servers This is server policy and up to the server implementation. 3315 doesn't detail how addresses are "generated". Some servers may use sequential assignment. Others randomly generated. - Bernie=20 -----Original Message----- From: ravi kumar [mailto:ravikumar.lrk@gmail.com]=20 Sent: Monday, November 12, 2007 1:55 AM To: dhcwg@ietf.org Subject: [dhcwg] Re: RFC 3633 - Pefix Allotment by Servers regards Ravi On Nov 11, 2007 12:33 PM, ravi kumar wrote: > RFC 3633 does not specify regarding "How Delegating Router selects > prefixes to be given to the clients" > Is there a common algorithm followed by the Servers that support > Prefix Delegation, for this purpose. > > From the documentation of Dibbler, I found the foolowing algorithm: > > 1. client didn't provide any hints: one pre x from each pool will be granted > 2. client has provided hint and that is valid (supported and unused): > requested pre x will be granted > 3. client has provided hint, which belongs to supported pool, but this > pre x is used: other pre x from > that pool will be asigned > 4. client has provided hint, but it is invalid (not beloninging to a > supported pool, multicast or link- > local): see point 1 > > I would like to know, if majority of Server implementations use the > above algorithm to allot prefixes to the client. > > regards > Ravi > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 12 17:34:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irhqx-00036N-7a; Mon, 12 Nov 2007 17:33:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irhqv-00033H-FN; Mon, 12 Nov 2007 17:33:57 -0500 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irhqq-0000J0-Cv; Mon, 12 Nov 2007 17:33:57 -0500 Received: from IBM52A5038A94F ([88.233.33.212]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1Irhqj0XRR-0005zk; Mon, 12 Nov 2007 17:33:51 -0500 From: "Alper Yegin" To: "'Eric Voit \(evoit\)'" , "'Ralph Droms \(rdroms\)'" Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WG recharteringforDHCPauthentication Date: Tue, 13 Nov 2007 00:33:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AcghNqSRIMtejNA6QuqLIl2FWroppAABZxPwAQ/JkXA= Message-Id: <0MKp8S-1Irhqj0XRR-0005zk@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19wB3LB/C+2jLSiJRoTZTE9YOvLfaZYFjTb6Gy BwIv5r0hdm7OUNtUcCgVqBgjJRU/VyDxUZGVmjzn83N3MvM1AF rEVauhQFBgSuIzcj1sk+A== X-Spam-Score: -0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: dhcwg@ietf.org, 'Internet Area' X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > Doubling the load on the DHCP servers probably will not change the game. > > The extra load on the L3 Edge/BRAS could easily change the game (and > hence the emails from Peter (Redback) & Bill (Juniper)). Hmmm... I followed up this feedback with Bill Welch in more technical detail, and if you remember it ended with a "And yes your observation is correct, the DHCP auth solution with EAP has the same issues." http://www1.ietf.org/mail-archive/web/int-area/current/msg01129.html Alper > > The extra complexity with the CPE has always been my biggest concern, > and is why I entered the thread many weeks ago. > > Eric > > > > From: Ralph Droms, November 07, 2007 7:06 AM > > > > Eric - I was mostly responding to Ric's description of the > > excessive load on DHCP servers in the short-lease/long-lease > > scenario. As I understand the short-lease/long-lease > > scenario, if we assume that authentication takes place in the > > short-lease window, the load on the DHCP servers would > > double. Significant, sure, but not game-changing in the way > > Ric implied. > > > > - Ralph > > > > On Nov 6, 2007, at Nov 6, 2007,10:39 PM, Eric Voit (evoit) wrote: > > > > >> From: Ralph Droms, November 05, 2007 9:37 PM > > >> > > >> Does the short lease/long lease scenario scale the DHCP > > server load > > >> by more than a factor of two? > > > > > > Ralph, > > > > > > The messages the DHCP servers will double. > > > The messages with L3 edge (BRAS) will more than double. > > > The messages with the CPE will more than triple. > > > > > > (Below is some rough math. I might have missed a message or > > two, but > > > the general trend is what I am trying to show.) > > > > > > ----------------------------------------- > > > CPE Messages > > > ----------------------------------------- > > > DHCP Auth, assuming a 2 message EAP Method, the messages > > used by EAP > > > would be equal > > > + 6 Messages (draft-pruss-dhcp-auth-dsl-01) > > > > > > PANA+DHCP Method > > > + 4 Messages: DHCP 1st IP address > > > ~ (+2) DHCP renews per 60 seconds until authenticated > > > + 11 Messages PANA with BRAS (draft-ietf-pana-pana-18, section 4.1) > > > + 4 Messages: DHCP 2nd IP address > > > > > > ----------------------------------------- > > > L3 Edge (BRAS) Messages > > > ----------------------------------------- > > > DHCP Auth, EAP Method > > > + 8 Messages (draft-pruss-dhcp-auth-dsl-01) > > > > > > PANA Method > > > + 4 Messages: DHCP 1st IP address > > > ~ (+2) DHCP renews per 60 seconds until authenticated > > > + 11 Messages PANA with CPE (draft-ietf-pana-pana-18, section 4.1) > > > + 2 messages min for validating with EAP Server > > > + 4 Messages: DHCP 2nd IP address > > > > > > ----------------------------------------- > > > L2 Edge (DSLAM or Access Switch) Messages > > > ----------------------------------------- > > > DHCP Auth, EAP Method > > > + 6 Messages snooped (draft-pruss-dhcp-auth-dsl-01) > > > > > > PANA+DHCP Method > > > + 4 Messages Snooped: DHCP 1st IP address > > > ~ (+2) DHCP renews per 60 seconds until authenticated If > > snooping: 11 > > > Messages PANA (draft-ietf-pana-pana-18, section 4.1) Else > > if explicit > > > policy distribution like ANCP, ~4 messages (one policy per address) > > > + 4 Messages Snooped: DHCP 2nd IP address > > > > > > > > > Eric > > > > > > > > >> - Ralph > > >> > > > > > > _______________________________________________ > > Int-area mailing list > > Int-area@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/int-area > > > > > _______________________________________________ > Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 12 17:53:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iri9Y-00070H-7P; Mon, 12 Nov 2007 17:53:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iri9W-0006yR-Eb; Mon, 12 Nov 2007 17:53:10 -0500 Received: from mout.perfora.net ([74.208.4.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iri9V-0007mB-Ls; Mon, 12 Nov 2007 17:53:10 -0500 Received: from IBM52A5038A94F ([88.233.33.212]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Iri9P1lus-0008V8; Mon, 12 Nov 2007 17:53:09 -0500 From: "Alper Yegin" To: "'Eric Voit \(evoit\)'" Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering forDHCPauthentication Date: Tue, 13 Nov 2007 00:52:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AcggHm+KfPGdwHk5Th6TDrp6Vvyw4QAzsuSAAA8SLPAAB8cG8AEM7RmA Message-Id: <0MKpCa-1Iri9P1lus-0008V8@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+gzhCXLQ70lK9Q9qyv659lGnLeT1n6Zr7tmCF fOzd7jOYsbEu48giAFw7Ktt5aNRDxJSeIKbfSEzylpHQ4IUwUR wiRjplk49bO3n1OYKaM6A== X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: dhcwg@ietf.org, 'Internet Area' , "'Ralph Droms \(rdroms\)'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > > From: Alper Yegin, November 07, 2007 6:04 AM > > > > First of all, there is no way use of PANA would lead to more > > DHCP traffic. > > ? You say below "full dhcp, pana, another full dhcp". Sounds like > doubling the DHCP traffic to me. If you compare it with EAP/DHCP, which adds at least two additional round-trips to usual DHCP, then you'd see even in that worst case (for PANA) scenario, the DHCP traffic using PANA is same as that of EAP/DHCP solution. > But there is another issue. It is very normal for AAA servers to take > time for all the sessions to authenticate after a BRAS reboot or > pop-wide power failure. PANA has the potential to introduce a large > amount of additional DHCP traffic simply due to short lease timer renews > being requested prior to authentication completion. You seem to assume the short leases are too short. > This sounds like a pretty effective distributed denial of service attack > to me. > > > How can that be true when carrying EAP over DHCP always at > > the minimum contribute 2 additional round-trips just for the > > sake of transporting EAP? > > I was trying to make the EAP method equivalent between the two cases. > Am I missing something? Yes. Ric said dedicated DHCP messages will carry EAP and in the very best case that means two additional round-trips of DHCP for the sake of shuttling EAP. > > In the worst case (DHCP-configured pre-PANA address), there > > are two round trips for that 1st DHCP. Even in that case PANA > > is no worse than DHCP-auth. > > > > And then there are better cases, e.g. use of link-local > > address as pre-PANA address, rapid commit, etc. > > > > As for your 11-msg PANA call flow count, the example you used > > is the most verbose one. If you turn on the optimizations > > (agent-side initiation, > > piggybacking) it reduces to 2 round trips. > > I chose the best message flow I could find within > draft-ietf-pana-pana-18. As I read your words above, I cannot match all > the potential variations to the DSLF requirements. Is there another What requirements are you referring to? The ones that DSLF provided to IETF does not really seem to talk about variations you are referring to. > documented DHCP+PANA message flow somewhere which meets the DSLF > requirements which I should use instead? Have you read the PANA spec? All these optimizations are documented there. Of course you cannot find call flows depicting every possible scenario in this IETF document. Alper > > Eric > > > > > So, in the worst case scenario (full dhcp, pana, another full > > dhcp), PANA has additional 2 round-trips. By kicking in more > > optimized deployment choices, this difference can be diminished. > > > > > > Alper > > > > > -----Original Message----- > > > From: Eric Voit (evoit) [mailto:evoit@cisco.com] > > > Sent: Wednesday, November 07, 2007 5:40 AM > > > To: Ralph Droms (rdroms) > > > Cc: dhcwg@ietf.org; Internet Area > > > Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WG > > rechartering > > > forDHCPauthentication > > > > > > > From: Ralph Droms, November 05, 2007 9:37 PM > > > > > > > > Does the short lease/long lease scenario scale the DHCP > > server load > > > > by more than a factor of two? > > > > > > Ralph, > > > > > > The messages the DHCP servers will double. > > > The messages with L3 edge (BRAS) will more than double. > > > The messages with the CPE will more than triple. > > > > > > (Below is some rough math. I might have missed a message or > > two, but > > > the general trend is what I am trying to show.) > > > > > > ----------------------------------------- > > > CPE Messages > > > ----------------------------------------- > > > DHCP Auth, assuming a 2 message EAP Method, the messages > > used by EAP > > > would be equal > > > + 6 Messages (draft-pruss-dhcp-auth-dsl-01) > > > > > > PANA+DHCP Method > > > + 4 Messages: DHCP 1st IP address > > > ~ (+2) DHCP renews per 60 seconds until authenticated > > > + 11 Messages PANA with BRAS (draft-ietf-pana-pana-18, section 4.1) > > > + 4 Messages: DHCP 2nd IP address > > > > > > ----------------------------------------- > > > L3 Edge (BRAS) Messages > > > ----------------------------------------- > > > DHCP Auth, EAP Method > > > + 8 Messages (draft-pruss-dhcp-auth-dsl-01) > > > > > > PANA Method > > > + 4 Messages: DHCP 1st IP address > > > ~ (+2) DHCP renews per 60 seconds until authenticated > > > + 11 Messages PANA with CPE (draft-ietf-pana-pana-18, section 4.1) > > > + 2 messages min for validating with EAP Server > > > + 4 Messages: DHCP 2nd IP address > > > > > > ----------------------------------------- > > > L2 Edge (DSLAM or Access Switch) Messages > > > ----------------------------------------- > > > DHCP Auth, EAP Method > > > + 6 Messages snooped (draft-pruss-dhcp-auth-dsl-01) > > > > > > PANA+DHCP Method > > > + 4 Messages Snooped: DHCP 1st IP address > > > ~ (+2) DHCP renews per 60 seconds until authenticated If > > snooping: 11 > > > Messages PANA (draft-ietf-pana-pana-18, section 4.1) Else > > if explicit > > > policy distribution like ANCP, ~4 messages (one policy per address) > > > + 4 Messages Snooped: DHCP 2nd IP address > > > > > > > > > Eric > > > > > > > > > > - Ralph > > > > > > > > > > > > > _______________________________________________ > > > Int-area mailing list > > > Int-area@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/int-area > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 13 06:59:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IruQZ-0005Ui-3L; Tue, 13 Nov 2007 06:59:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IruQX-0005UB-GZ for dhcwg@ietf.org; Tue, 13 Nov 2007 06:59:33 -0500 Received: from mx.isc.org ([2001:4f8:0:2::1c]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IruQW-00070p-1r for dhcwg@ietf.org; Tue, 13 Nov 2007 06:59:33 -0500 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 0057711401F for ; Tue, 13 Nov 2007 11:59:30 +0000 (UTC) (envelope-from Shane_Kerr@isc.org) Received: from [199.6.1.234] (unknown [199.6.1.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 757B3E6056 for ; Tue, 13 Nov 2007 11:59:30 +0000 (UTC) (envelope-from shane@isc.org) Message-ID: <473991A0.2060009@isc.org> Date: Tue, 13 Nov 2007 12:59:28 +0100 From: Shane Kerr Organization: ISC User-Agent: Thunderbird 2.0.0.6 (X11/20070806) MIME-Version: 1.0 To: DHCP discussion list X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [dhcwg] Client Port Option? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shane_kerr@isc.org List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, I think it might be useful for DHCP clients to use a different port, other than 68/546. One use case is when someone wants to run multiple clients on a single interface. It is possible to write a client that request multiple addresses now, but running separate clients has some benefits: clients that only manage a single lease are simpler, and many existing clients could be easily changed to bind to a different port and add a new option. Plus you get a (small) degree of fault isolation with separate clients. Another use case is for testing and debugging. Administrators could use DHCPLEASEQUERY (or maybe DHCPINFORM) to learn about their network, but since answers go to reserved ports, the uses are slightly limited. Plus it is much easier to simulate a set of clients if you can run them all on a single box. If this is not considered generally useful I might just make it an ISC vendor option (for our own testing), but I think it could have wider application. Please let me know what you think! - -- Shane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHOZGdMsfZxBO4kbQRAqz7AJ0W8PyMcVg6QMb7SF46ilt74eFnMACeKBQc VS+nsu1e4QfPepcUIAgrqaQ= =T6kB -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 13 07:02:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IruTU-0000vc-1E; Tue, 13 Nov 2007 07:02:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IruTR-0000ur-2j for dhcwg@ietf.org; Tue, 13 Nov 2007 07:02:33 -0500 Received: from mx.isc.org ([2001:4f8:0:2::1c]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IruTP-00077Z-PB for dhcwg@ietf.org; Tue, 13 Nov 2007 07:02:33 -0500 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id B88ED11401F for ; Tue, 13 Nov 2007 12:02:30 +0000 (UTC) (envelope-from Shane_Kerr@isc.org) Received: from [199.6.1.234] (unknown [199.6.1.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 4A47EE6065; Tue, 13 Nov 2007 12:02:30 +0000 (UTC) (envelope-from shane@isc.org) Message-ID: <47399253.60408@isc.org> Date: Tue, 13 Nov 2007 13:02:27 +0100 From: Shane Kerr Organization: ISC User-Agent: Thunderbird 2.0.0.6 (X11/20070806) MIME-Version: 1.0 To: shane_kerr@isc.org Subject: Re: [dhcwg] Client Port Option? References: <473991A0.2060009@isc.org> In-Reply-To: <473991A0.2060009@isc.org> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: DHCP discussion list X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shane_kerr@isc.org List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Shane Kerr wrote: > I think it might be useful for DHCP clients to use a different port, other than > 68/546. Hm... I just realized that I didn't explain the actual proposal. :( The idea is that if clients did want to use a different port, they would include an option with the port number when the sent a packet. I know some DHCP servers would drop the queries, and there are firewalling issues, but these can be addressed in the long term. - -- Shane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHOZJSMsfZxBO4kbQRAvOiAKDivc0O8YqF6nX4FZyCJN2yQJzSKgCgtyLm 8kDQjNqwYnQk26RGrA6Nv1o= =auim -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 13 08:28:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrvoN-00015o-7C; Tue, 13 Nov 2007 08:28:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrvoK-00015Q-1q for dhcwg@ietf.org; Tue, 13 Nov 2007 08:28:12 -0500 Received: from intermail.se.dataphone.net ([212.37.1.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrvoJ-0003Rk-NA for dhcwg@ietf.org; Tue, 13 Nov 2007 08:28:11 -0500 Received: from [213.115.152.226] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.2) with ESMTP id 50823066; Tue, 13 Nov 2007 14:28:10 +0100 From: Bud Millwood Organization: Weird Solutions, Inc. To: dhcwg@ietf.org, shane_kerr@isc.org Subject: Re: [dhcwg] Client Port Option? Date: Tue, 13 Nov 2007 13:43:42 +0100 User-Agent: KMail/1.8 References: <473991A0.2060009@isc.org> <47399253.60408@isc.org> In-Reply-To: <47399253.60408@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711131343.42205.budm@weird-solutions.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bud Millwood List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Tuesday 13 November 2007 13:02, Shane Kerr wrote: > Shane Kerr wrote: > > I think it might be useful for DHCP clients to use a different port, > > other than 68/546. > > Hm... I just realized that I didn't explain the actual proposal. :( > > The idea is that if clients did want to use a different port, they would > include an option with the port number when the sent a packet. We respond to whatever the source port was *by default*, and allow an administrative override that forces responses to a particular dest port (68 being the obvious choice). That way you can skip the need for a client option. - Bud _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 13 11:06:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryH7-0004Yd-Bi; Tue, 13 Nov 2007 11:06:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryH4-0004Wm-VN for dhcwg@ietf.org; Tue, 13 Nov 2007 11:06:02 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IryH1-0000KT-7d for dhcwg@ietf.org; Tue, 13 Nov 2007 11:06:02 -0500 Received: from [10.6.126.250] (unknown [206.128.65.108]) by toccata.fugue.com (Postfix) with ESMTP id 057E1BC43F9; Tue, 13 Nov 2007 09:05:57 -0700 (MST) Subject: Re: [dhcwg] Client Port Option? From: Ted Lemon To: "shane_kerr@isc.org" In-Reply-To: <47399253.60408@isc.org> References: <473991A0.2060009@isc.org> <47399253.60408@isc.org> Content-Type: text/plain Date: Tue, 13 Nov 2007 09:05:57 -0700 Message-Id: <1194969957.7635.27.camel@uma> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: DHCP discussion list X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Tue, 2007-11-13 at 04:02 -0800, Shane Kerr wrote: > Hm... I just realized that I didn't explain the actual proposal. :( Okay, it makes a lot more sense now. > The idea is that if clients did want to use a different port, they would include > an option with the port number when the sent a packet. > > I know some DHCP servers would drop the queries, and there are firewalling > issues, but these can be addressed in the long term. My main concern would be relay agents not handling it correctly. My other concern is that on a practical level, it's not the case that DHCP servers will respond incorrectly; rather, they will respond to the standard port if they don't implement the option. So I don't see any way to reliably get the behavior you are hoping for; that is, I don't see what good it would do. In the case of something like leasequery, it seems like you'd need to *inquire* whether the server would do port return, but expect the answer to come to the usual port. And then, if the answer was in the affirmative, you could just send your unicast packets from a different source port, with the same flag, and the server could answer to that port. This seems like it would have utility for things like DHCPINFORM and DHCPLEASEQUERY, but not so much for regular DHCP action. I'm also not sure how broad the use for this would be outside of debugging - clearly it's useful for debugging to be able to do DHCPLEASEQUERY from a separate process on a machine that got its address using DHCP, but would it ever happen in a real deployment? So I guess I'm interested, but lukewarm, on the idea... :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 13 11:28:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrycN-00029w-78; Tue, 13 Nov 2007 11:28:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrycL-00029l-6q for dhcwg@ietf.org; Tue, 13 Nov 2007 11:28:01 -0500 Received: from sfovwl03.inf.com ([216.251.50.9] helo=SFOVWL03.infosys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrycH-0002cQ-SA for dhcwg@ietf.org; Tue, 13 Nov 2007 11:28:01 -0500 Received: from INDHUBBHS02.ad.infosys.com ([192.168.200.82]) by SFOVWL03.infosys.com with InterScan Message Security Suite; Tue, 13 Nov 2007 08:26:30 -0800 Received: from blrkechub04.ad.infosys.com ([10.66.236.44]) by INDHUBBHS02.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Nov 2007 21:57:54 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub04.ad.infosys.com ([10.66.236.44]) with mapi; Tue, 13 Nov 2007 21:57:54 +0530 From: Bharat Joshi To: "dhcwg@ietf.org" Date: Tue, 13 Nov 2007 21:57:52 +0530 Thread-Topic: I-D ACTION:draft-joshi-dhc-l2ra-00.txt Thread-Index: AcgmCsF7YiAGpKS/TiCYcWjtaDPqBwABhDcs Message-ID: <31D55C4D55BEED48A4459EB64567589A0ADFF09687@BLRKECMBX02.ad.infosys.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_31D55C4D55BEED48A4459EB64567589A0ADFF09687BLRKECMBX02ad_" MIME-Version: 1.0 X-OriginalArrivalTime: 13 Nov 2007 16:27:54.0710 (UTC) FILETIME=[24B3F760:01C82612] X-Spam-Score: -4.0 (----) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Subject: [dhcwg] FW: I-D ACTION:draft-joshi-dhc-l2ra-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org --_003_31D55C4D55BEED48A4459EB64567589A0ADFF09687BLRKECMBX02ad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the feedback received in last IETF and on mailing list, we= have created a document that provides information on Layer 2 Relay Agent= functionality and describes the changes in DHCP server, Relay Agents= because of the introduction of Layer 2 Relay Agent in different network= scenarios. Please review this document and let us know your= comments/suggestions. Thanks & Regards, Bharat ________________________________________ From: Internet-Drafts@ietf.org [Internet-Drafts@ietf.org] Sent: Tuesday, November 13, 2007 8:45 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-joshi-dhc-l2ra-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Layer 2 Relay Agent Information Author(s) : B. Joshi, P. Kurapati Filename : draft-joshi-dhc-l2ra-00.txt Pages : 18 Date : 2007-11-13 In some networks, DHCP servers rely on Relay Agent Information option appended by Relay Agents for IP address and other parameter assignment policies. This works fine when End Hosts are directly connected to Relay Agents. In some network configurations, one or more Layer 2 devices may reside between DHCP clients and Relay agent. In these network scenarios, it is difficult to use the Relay Agent Information option for IP address and other parameter assignment policies effectively. So there is a need for the closest Layer 2 device to append Relay Agent Information option in DHCP messages. These devices are typically known as Layer 2 Relay Agents. This document aims to describe the network scenarios where Layer 2 Relay Agent is in use and also how it handles DHCP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-joshi-dhc-l2ra-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-joshi-dhc-l2ra-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-joshi-dhc-l2ra-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail= readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended= solely for the use of the addressee(s). If you are not the intended= recipient, please notify the sender by e-mail and delete the original= message. Further, you are not to copy, disclose, or distribute this e-mail= or its contents to any other person and any such actions are unlawful.= This e-mail may contain viruses. Infosys has taken every reasonable= precaution to minimize this risk, but is not liable for any damage you may= sustain as a result of any virus in this e-mail. You should carry out your= own virus checks before opening the e-mail or attachment. Infosys reserves= the right to monitor and review the content of all messages sent to or= from this e-mail address. Messages sent to or from this e-mail address may= be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** --_003_31D55C4D55BEED48A4459EB64567589A0ADFF09687BLRKECMBX02ad_ Content-Type: message/external-body; name="ATT00001" Content-Description: ATT00001 Content-Disposition: attachment; filename="ATT00001"; size=0; creation-date="Tue, 13 Nov 2007 15:35:01 GMT"; modification-date="Tue, 13 Nov 2007 15:35:01 GMT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBtZXNzYWdlL2V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPW1haWwtc2Vy dmVyOw0KCXNlcnZlcj0ibWFpbHNlcnZAaWV0Zi5vcmciDQoNCkNvbnRlbnQtVHlwZTogdGV4dC9w bGFpbg0KQ29udGVudC1JRDogPDIwMDctMTEtMTMwOTU3MDIuSS1EQGlldGYub3JnPg0KDQpFTkNP RElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtam9zaGktZGhjLWwycmEtMDAu dHh0DQo= --_003_31D55C4D55BEED48A4459EB64567589A0ADFF09687BLRKECMBX02ad_ Content-Type: text/plain; name="ATT00002" Content-Description: ATT00002 Content-Disposition: attachment; filename="ATT00002"; size=0; creation-date="Tue, 13 Nov 2007 15:35:01 GMT"; modification-date="Tue, 13 Nov 2007 15:35:01 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= --_003_31D55C4D55BEED48A4459EB64567589A0ADFF09687BLRKECMBX02ad_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --_003_31D55C4D55BEED48A4459EB64567589A0ADFF09687BLRKECMBX02ad_-- From dhcwg-bounces@ietf.org Tue Nov 13 12:47:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrzrU-0001HI-ED; Tue, 13 Nov 2007 12:47:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrzrT-0001GV-AU for dhcwg@ietf.org; Tue, 13 Nov 2007 12:47:43 -0500 Received: from mx.isc.org ([2001:4f8:0:2::1c]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrzrQ-0005sv-Fd for dhcwg@ietf.org; Tue, 13 Nov 2007 12:47:43 -0500 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 34E1B11401C; Tue, 13 Nov 2007 17:47:39 +0000 (UTC) (envelope-from Shane_Kerr@isc.org) Received: from [199.6.1.234] (unknown [199.6.1.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 8749BE6065; Tue, 13 Nov 2007 17:47:38 +0000 (UTC) (envelope-from shane@isc.org) Message-ID: <4739E337.1090107@isc.org> Date: Tue, 13 Nov 2007 18:47:35 +0100 From: Shane Kerr Organization: ISC User-Agent: Thunderbird 2.0.0.6 (X11/20070806) MIME-Version: 1.0 To: Bud Millwood Subject: Re: [dhcwg] Client Port Option? References: <473991A0.2060009@isc.org> <47399253.60408@isc.org> <200711131343.42205.budm@weird-solutions.com> In-Reply-To: <200711131343.42205.budm@weird-solutions.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shane_kerr@isc.org List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bud Millwood wrote: > On Tuesday 13 November 2007 13:02, Shane Kerr wrote: >> Shane Kerr wrote: >>> I think it might be useful for DHCP clients to use a different port, >>> other than 68/546. >> Hm... I just realized that I didn't explain the actual proposal. :( >> >> The idea is that if clients did want to use a different port, they would >> include an option with the port number when the sent a packet. > > We respond to whatever the source port was *by default*, and allow an > administrative override that forces responses to a particular dest port (68 > being the obvious choice). That way you can skip the need for a client > option. Interesting to hear that you do this by default. IMHO this should have been the defined behavior all along. I wonder why this wasn't corrected, at least for DHCPv6? I can't think of a way to change this in the protocol without potential pain. Still, maybe a hack is possible. Something like: - - Send the first reply to the UDP port in the packet. - - If a retransmission is detected, send the reply to port 68 and the UDP port in the packet. This will cause extra packets and delay, but mostly for clients that send from a port other than 68 and expect a reply on port 68. Actually, in this case a 1-byte option saying "don't send to port 68" might be useful (0-byte in DHCPv6). That will prevent extra packets in the case where a retransmission is required due to lost packets or busy servers. - -- Shane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHOeM3MsfZxBO4kbQRAmUXAJ4oCNa2pOBzsg+8qx5WqofnxX2D7QCdGy3b EHi1RqfdjhXZsR3pfgUUOUg= =vtpF -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 13 17:52:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is4bv-0005aM-4D; Tue, 13 Nov 2007 17:51:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is4bt-0005Vw-A4; Tue, 13 Nov 2007 17:51:57 -0500 Received: from mout.perfora.net ([74.208.4.197]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is4bs-0002Tn-KW; Tue, 13 Nov 2007 17:51:57 -0500 Received: from IBM52A5038A94F ([88.233.33.212]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1Is4bk42Da-0005t9; Tue, 13 Nov 2007 17:51:56 -0500 From: "Alper Yegin" To: Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WGrecharteringforDHCPauthentication Date: Wed, 14 Nov 2007 00:51:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <014c01c82581$b51e9b70$ba3dfea9@ad.redback.com> Thread-Index: AcghNqSRIMtejNA6QuqLIl2FWroppAABZxPwAQ/JkXAAAXPf0AAxbakw Message-Id: <0MKp8S-1Is4bk42Da-0005t9@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18QU/QVcnfmVbaDAyHYhHjNj2Tb638oJ/aAlc2 DnYXCAFCcwP0IIhw+lHzf8aatX49x/RLjerqFqqFuds7CQtjDM b0HKaXUABZbU93JpBPAmw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: dhcwg@ietf.org, 'Internet Area' X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi, > It is clear that any solution which requires a temporary ip-address > will create more turn on a BRAS, and the subscriber setup rate will > very likely go down compared to a solution which will finish > authentication before ip-address allocation. Can you please elaborate on the impact of using a link-local or DHCP-assigned IP address prior to running access authentication? Details would help us understand the level of impact, and let us see if we can identify any remedies. Thanks. Alper > > Peter > > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > Sent: 12. november 2007 14:34 > > To: 'Eric Voit (evoit)'; 'Ralph Droms (rdroms)' > > Cc: dhcwg@ietf.org; 'Internet Area' > > Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc > > WGrecharteringforDHCPauthentication > > > > > Doubling the load on the DHCP servers probably will not > > change the game. > > > > > > The extra load on the L3 Edge/BRAS could easily change the game (and > > > hence the emails from Peter (Redback) & Bill (Juniper)). > > > > Hmmm... I followed up this feedback with Bill Welch in more technical > > detail, and if you remember it ended with a "And yes your > > observation is > > correct, the DHCP auth solution with EAP has the same issues." > > > > http://www1.ietf.org/mail-archive/web/int-area/current/msg01129.html > > > > Alper > > > > > > > > > > The extra complexity with the CPE has always been my > > biggest concern, > > > and is why I entered the thread many weeks ago. > > > > > > Eric > > > > > > > > > > From: Ralph Droms, November 07, 2007 7:06 AM > > > > > > > > Eric - I was mostly responding to Ric's description of the > > > > excessive load on DHCP servers in the short-lease/long-lease > > > > scenario. As I understand the short-lease/long-lease > > > > scenario, if we assume that authentication takes place in the > > > > short-lease window, the load on the DHCP servers would > > > > double. Significant, sure, but not game-changing in the way > > > > Ric implied. > > > > > > > > - Ralph > > > > > > > > On Nov 6, 2007, at Nov 6, 2007,10:39 PM, Eric Voit (evoit) wrote: > > > > > > > > >> From: Ralph Droms, November 05, 2007 9:37 PM > > > > >> > > > > >> Does the short lease/long lease scenario scale the DHCP > > > > server load > > > > >> by more than a factor of two? > > > > > > > > > > Ralph, > > > > > > > > > > The messages the DHCP servers will double. > > > > > The messages with L3 edge (BRAS) will more than double. > > > > > The messages with the CPE will more than triple. > > > > > > > > > > (Below is some rough math. I might have missed a message or > > > > two, but > > > > > the general trend is what I am trying to show.) > > > > > > > > > > ----------------------------------------- > > > > > CPE Messages > > > > > ----------------------------------------- > > > > > DHCP Auth, assuming a 2 message EAP Method, the messages > > > > used by EAP > > > > > would be equal > > > > > + 6 Messages (draft-pruss-dhcp-auth-dsl-01) > > > > > > > > > > PANA+DHCP Method > > > > > + 4 Messages: DHCP 1st IP address > > > > > ~ (+2) DHCP renews per 60 seconds until authenticated > > > > > + 11 Messages PANA with BRAS (draft-ietf-pana-pana-18, > > section 4.1) > > > > > + 4 Messages: DHCP 2nd IP address > > > > > > > > > > ----------------------------------------- > > > > > L3 Edge (BRAS) Messages > > > > > ----------------------------------------- > > > > > DHCP Auth, EAP Method > > > > > + 8 Messages (draft-pruss-dhcp-auth-dsl-01) > > > > > > > > > > PANA Method > > > > > + 4 Messages: DHCP 1st IP address > > > > > ~ (+2) DHCP renews per 60 seconds until authenticated > > > > > + 11 Messages PANA with CPE (draft-ietf-pana-pana-18, > > section 4.1) > > > > > + 2 messages min for validating with EAP Server > > > > > + 4 Messages: DHCP 2nd IP address > > > > > > > > > > ----------------------------------------- > > > > > L2 Edge (DSLAM or Access Switch) Messages > > > > > ----------------------------------------- > > > > > DHCP Auth, EAP Method > > > > > + 6 Messages snooped (draft-pruss-dhcp-auth-dsl-01) > > > > > > > > > > PANA+DHCP Method > > > > > + 4 Messages Snooped: DHCP 1st IP address > > > > > ~ (+2) DHCP renews per 60 seconds until authenticated If > > > > snooping: 11 > > > > > Messages PANA (draft-ietf-pana-pana-18, section 4.1) Else > > > > if explicit > > > > > policy distribution like ANCP, ~4 messages (one policy > > per address) > > > > > + 4 Messages Snooped: DHCP 2nd IP address > > > > > > > > > > > > > > > Eric > > > > > > > > > > > > > > >> - Ralph > > > > >> > > > > > > > > > > > > _______________________________________________ > > > > Int-area mailing list > > > > Int-area@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/int-area > > > > > > > > > > > > > _______________________________________________ > > > Int-area mailing list > > > Int-area@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/int-area > > > > > > > > _______________________________________________ > > Int-area mailing list > > Int-area@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/int-area > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 13 17:55:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is4ff-0003Yd-Mn; Tue, 13 Nov 2007 17:55:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is4fd-0003Up-LL for dhcwg@ietf.org; Tue, 13 Nov 2007 17:55:49 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is4fa-0006Xx-B8 for dhcwg@ietf.org; Tue, 13 Nov 2007 17:55:49 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Nov 2007 17:55:44 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lADMtjHu012094 for ; Tue, 13 Nov 2007 17:55:45 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lADMtQVT020321 for ; Tue, 13 Nov 2007 22:55:45 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 17:55:40 -0500 Received: from [192.168.1.102] ([10.86.242.8]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 17:55:40 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A3194E1-D82A-4307-9ABB-8EEBED5DF6BB@cisco.com> Content-Transfer-Encoding: 7bit From: Ralph Droms Date: Tue, 13 Nov 2007 17:55:38 -0500 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 13 Nov 2007 22:55:40.0437 (UTC) FILETIME=[50282C50:01C82648] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15542.002 X-TM-AS-Result: No--9.424300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=974; t=1194994545; x=1195858545; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Fwd=3A=20New=20Version=20Notification=20for=20draft-droms-dhc -container-opt-01=20 |Sender:=20 |To:=20dhcwg@ietf.org; bh=TEu5uNDvCfW0wI5IEoCppHolDF023t5dKYF7xB+7Q4M=; b=SuN3IobxgUyCS100xOCy/2xeNU8ESIJK+WdQ+g33L/QMC83I2sME4dD5jTU4FixbxlgaYMN7 q9MIL8GM4HktGTVcWdLJLpYN23rNgCW1Shr7t7fPahwAR5RDCz8elaMU; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Droms Ralph Subject: [dhcwg] Fwd: New Version Notification for draft-droms-dhc-container-opt-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org FYI; for discussion in Vancouver. - Ralph Begin forwarded message: > From: IETF I-D Submission Tool > Date: November 13, 2007 5:52:51 PM EST > To: rdroms@cisco.com > Subject: New Version Notification for draft-droms-dhc-container-opt-01 > > > A new version of I-D, draft-droms-dhc-container-opt-01.txt has been > successfuly submitted by Ralph Droms and posted to the IETF > repository. > > Filename: draft-droms-dhc-container-opt > Revision: 01 > Title: Container Option for Server Configuration > Creation_date: 2007-11-13 > WG ID: Independent Submission > Number_of_pages: 9 > > Abstract: > In some DHCP service deployments, it is desirable for a DHCP server > in one administrative domain to pass configuration options to a DHCP > server in a different administrative domain. This DHCP option > carries a set of DHCP options that can be used by another DHCP > server. > > > > The IETF Secretariat. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 13 18:23:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is56l-0003FX-VS; Tue, 13 Nov 2007 18:23:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is56k-0003EV-TK; Tue, 13 Nov 2007 18:23:50 -0500 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is56j-0003QW-Er; Tue, 13 Nov 2007 18:23:50 -0500 X-IronPort-AV: E=Sophos;i="4.21,412,1188757800"; d="scan'208,217";a="90964092" Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 14 Nov 2007 17:58:08 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lADNNj8Q023616; Wed, 14 Nov 2007 07:23:45 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lADNNfXT027677; Tue, 13 Nov 2007 23:23:42 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 07:23:41 +0800 Received: from syd-rpruss-vpn2.cisco.com ([10.67.195.19]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 07:23:39 +0800 Message-ID: <473A31FF.20504@cisco.com> Date: Wed, 14 Nov 2007 09:23:43 +1000 From: Richard Pruss Organization: Cisco Systems User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Alper Yegin Subject: Re: [Int-area] Re: [dhcwg] Discussion of dhc WGrecharteringforDHCPauthentication References: <0MKp8S-1Is4bk42Da-0005t9@mrelay.perfora.net> In-Reply-To: <0MKp8S-1Is4bk42Da-0005t9@mrelay.perfora.net> X-OriginalArrivalTime: 13 Nov 2007 23:23:40.0234 (UTC) FILETIME=[3964DAA0:01C8264C] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15544.000 X-TM-AS-Result: No--11.345700-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5002; t=1194996226; x=1195860226; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ric@cisco.com; z=From:=20Richard=20Pruss=20 |Subject:=20Re=3A=20[Int-area]=20Re=3A=20[dhcwg]=20Discussion=20of=20dhc= 09WGrecharteringforDHCPauthentication |Sender:=20; bh=q2kiLSQolFavJzF6PqPzuOuy/grHLab6DIvU4/b/7S0=; b=bbHwxp3GYOEDhak7BNFQ8PzDdGRz8I30J4YRW2n6Y3A+tAbxuAkS9/Q2MxGXXuQVUWj1ArSN aN8UuUgw5ol/0c9lohAv/iPqkBDPGuyXFR8Eo1Tm8SdrTrIX2S7VRAc4Cm+4yc6WXWTK5+FqcF UBgjJeTX+ke0M07pJUouwuTL4=; Authentication-Results: hkg-dkim-2; header.From=ric@cisco.com; dkim=pass (si g from cisco.com/hkgdkim2001 verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: dhcwg@ietf.org, 'Internet Area' , parberg@redback.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ric@cisco.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1171421754==" Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1171421754== Content-Type: multipart/alternative; boundary="------------030704050805030102010107" This is a multi-part message in MIME format. --------------030704050805030102010107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Alper Yegin wrote, around 14/11/07 8:51 AM: > Hi, > > >> It is clear that any solution which requires a temporary ip-address >> will create more turn on a BRAS, and the subscriber setup rate will >> very likely go down compared to a solution which will finish >> authentication before ip-address allocation. >> > > Can you please elaborate on the impact of using a link-local or > DHCP-assigned IP address prior to running access authentication? Details > would help us understand the level of impact, and let us see if we can > identify any remedies. > Well if you use link local you need to stop the DHCP client stack which means changing the DHCP stack which you have said is scary many times. Secondly to run PANA with link local to the NAS, you need to re engineer all the layer 2 SAVA security because the link local addresses look like spoofed addresses to the layer 2 switches and would be dropped. If you couple that with all the rest of the extra mess of PANA discovery stuff then it is obvious that DHCP authentication it is much, much cleaner and leaner. If you run DHCP-assigned address prior to authentication. The whole layer 2 network is exposed to attack by unauthenticated IP end-point. The SAVA done by DSLAMs and first hop switches is eliminated because unauthenticated users have DHCP assigned addresses. Not to mention thet obvious point that every renew during the unauthenticated period is extra messaging which for 60K-500K subscriber access networks are effectively huge extra message loads on everything in the DHCP path. Plus the point that you are now saying that 60 seconds is too short for the renew, which means that from around 10-15 second logins, which we have today, the latency is going to 60 seconds +. Worse than that, the worst time for access is after a massive power outage where we have heard of is 20 minutes during recoveries due to AAA server loads and for this vulnerable time with PANA the DHCP has 20 extra renew per client which is millions of extra messages smashing things up. - Ric --------------030704050805030102010107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Alper Yegin wrote, around 14/11/07 8:51 AM: 
Hi,

  
It is clear that any solution which requires a temporary ip-address
will create more turn on a BRAS, and the subscriber setup rate will
very likely go down compared to a solution which will finish
authentication before ip-address allocation.
    

Can you please elaborate on the impact of using a link-local or
DHCP-assigned IP address prior to running access authentication? Details
would help us understand the level of impact, and let us see if we can
identify any remedies.
Well if you use link local you need to stop the DHCP client stack which means changing the DHCP stack which you have said is scary many times.  Secondly to run PANA with link local to the NAS, you need to re engineer all the layer 2 SAVA security because the link local addresses look like spoofed addresses to the layer 2 switches and would be dropped. If you couple that with all the rest of the extra mess of PANA discovery stuff then it is obvious that DHCP authentication it is much, much cleaner and leaner.

If you run DHCP-assigned address prior to authentication.  The whole layer 2 network is exposed to attack by unauthenticated IP end-point.  The SAVA done by DSLAMs and first hop switches is eliminated because unauthenticated  users have DHCP assigned addresses.  Not to mention thet obvious point that every renew during the unauthenticated period is extra messaging which for 60K-500K  subscriber access networks are effectively huge extra message loads on everything in the DHCP path.  Plus the point that you are now saying that 60 seconds is too short for the renew, which means that from around 10-15 second logins, which we have today, the latency is going to 60 seconds +.  Worse than that, the worst time for access is after a massive power outage where we have heard of is 20 minutes during recoveries due to AAA server loads and for this vulnerable time with PANA the DHCP has 20 extra renew per client which is millions of extra messages smashing things up.

- Ric


--------------030704050805030102010107-- --===============1171421754== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1171421754==-- From dhcwg-bounces@ietf.org Tue Nov 13 18:24:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is57N-00049b-Se; Tue, 13 Nov 2007 18:24:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is57L-00047P-OS for dhcwg@ietf.org; Tue, 13 Nov 2007 18:24:27 -0500 Received: from intermail.se.dataphone.net ([212.37.1.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is57K-0003RG-VQ for dhcwg@ietf.org; Tue, 13 Nov 2007 18:24:27 -0500 Received: from [213.115.152.226] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.2) with ESMTP id 50854638; Wed, 14 Nov 2007 00:24:21 +0100 From: Bud Millwood Organization: Weird Solutions, Inc. To: shane_kerr@isc.org, dhcwg@ietf.org Subject: Re: [dhcwg] Client Port Option? Date: Tue, 13 Nov 2007 23:39:50 +0100 User-Agent: KMail/1.8 References: <473991A0.2060009@isc.org> <200711131343.42205.budm@weird-solutions.com> <4739E337.1090107@isc.org> In-Reply-To: <4739E337.1090107@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711132339.50550.budm@weird-solutions.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bud Millwood List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Tuesday 13 November 2007 18:47, Shane Kerr wrote: > Bud Millwood wrote: > > On Tuesday 13 November 2007 13:02, Shane Kerr wrote: > >> Shane Kerr wrote: > >>> I think it might be useful for DHCP clients to use a different port, > >>> other than 68/546. > >> > >> Hm... I just realized that I didn't explain the actual proposal. :( > >> > >> The idea is that if clients did want to use a different port, they would > >> include an option with the port number when the sent a packet. > > > > We respond to whatever the source port was *by default*, and allow an > > administrative override that forces responses to a particular dest port > > (68 being the obvious choice). That way you can skip the need for a > > client option. > > Interesting to hear that you do this by default. IMHO this should have been > the defined behavior all along. I wonder why this wasn't corrected, at > least for DHCPv6? > > I can't think of a way to change this in the protocol without potential > pain. Still, maybe a hack is possible. Something like: > > - Send the first reply to the UDP port in the packet. > - If a retransmission is detected, send the reply to port 68 and the UDP > port in the packet. If the client used src port N, why would it not expect a reply on that same port? It seems to me that a client that's straddling two ports - 68 for inbound and something else for outbound - is already on thin ice. > This will cause extra packets and delay, but mostly for clients that send > from a port other than 68 and expect a reply on port 68. Do you know of any clients that do this, or is this just debug code? And if it's debug code, why not allow the server to respond to the client's source port instead? That way you can transmit from as many source ports as you want. - Bud Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 13 18:30:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is5Cm-0004Np-07; Tue, 13 Nov 2007 18:30:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is5Ck-0004Ix-EJ; Tue, 13 Nov 2007 18:30:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is5Ck-0007KC-2k; Tue, 13 Nov 2007 18:30:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id E2D5826E7E; Tue, 13 Nov 2007 23:30:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Is5Cj-0001Nm-R8; Tue, 13 Nov 2007 18:30:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 13 Nov 2007 18:30:01 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-reconfigure-rebind-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Rebind Capability in DHCPv6 Reconfigure Messages Author(s) : D. Evans, R. Droms Filename : draft-ietf-dhc-dhcpv6-reconfigure-rebind-02.txt Pages : 5 Date : 2007-11-13 This document updates RFC 3315 to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message, which allows DHCPv6 servers to instruct clients to perform a Rebind operation as well as a Renew operation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebind-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-reconfigure-rebind-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebind-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-13182107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebind-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-reconfigure-rebind-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-13182107.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Wed Nov 14 04:41:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEkc-0005SU-QQ; Wed, 14 Nov 2007 04:41:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEkb-0005LN-2C for dhcwg@ietf.org; Wed, 14 Nov 2007 04:41:37 -0500 Received: from mx.isc.org ([2001:4f8:0:2::1c]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsEkY-0003Gy-UU for dhcwg@ietf.org; Wed, 14 Nov 2007 04:41:37 -0500 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id AB88F11401C; Wed, 14 Nov 2007 09:41:33 +0000 (UTC) (envelope-from Shane_Kerr@isc.org) Received: from [199.6.1.234] (unknown [199.6.1.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id CFDC8E6065; Wed, 14 Nov 2007 09:41:32 +0000 (UTC) (envelope-from shane@isc.org) Message-ID: <473AC2CA.2080509@isc.org> Date: Wed, 14 Nov 2007 10:41:30 +0100 From: Shane Kerr Organization: ISC User-Agent: Thunderbird 2.0.0.6 (X11/20070806) MIME-Version: 1.0 To: TS Glassey References: <4733482A.7020302@sun.com><4735A243.6090905@sun.com> <47368636.3070007@udel.edu><4736F7A7.2090707@sun.com> <473736A7.5000801@udel.edu><47387778.4030702@sun.com> <47391B04.8080202@udel.edu> <006801c82641$cd256990$6401a8c0@tsg1> In-Reply-To: <006801c82641$cd256990$6401a8c0@tsg1> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org Subject: [dhcwg] Re: [ntpwg] Digital Evidence Standards and a statement that this directly effects NTP and its use... X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shane_kerr@isc.org List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Todd, TS Glassey wrote: > > Google the actual ruling here: > http://www.google.com/search?q=lorraine+v+markel&rls=com.microsoft:en-us:IE-SearchBox&ie=UTF-8&oe=UTF-8&sourceid=ie7&rlz=1I7GGLF A massive triumph of legal formalism over common sense, IMHO. > Bluntly, the world changed a tad on May 4th and while this effort is pointed > at the physics of operating NTP, these new controls impact any work with any > other Standardized Protocol as well... What this means to people who NTP is > a part of their commercial offering, is that they MUST apply these new > standards to this code and its support as well, or they must use their own > internal code-base's rather than depending on one here. I think this ruling > re-set the bar heighth, and it is now much higher - even for an Academic > Entity. As to how this effects this WG, we need to build tools that are > capable of being used in these key application contexts or this protocol > will likely be ultimately replaced. I'm a little slow this morning... I can't figure out how this standard applies to NTP. Can you explain what it means, from a protocol and a software point of view (plain English preferred, technical gibberish okay, no legalese please)? - -- Shane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHOsLAMsfZxBO4kbQRAk8uAKCjfp0XvQUKcCat2oBvUDOBgZ39fwCfWtcN 5ejJMaSb3blH3h/9kohaioo= =4DDy -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1U-0002kW-Ew; Wed, 14 Nov 2007 08:11:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpkZw-00069l-3T; Wed, 07 Nov 2007 08:04:20 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpkZv-0005u0-In; Wed, 07 Nov 2007 08:04:20 -0500 X-IronPort-AV: E=Sophos;i="4.21,384,1188792000"; d="scan'208";a="75360698" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Nov 2007 08:04:19 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA7D4J98013978; Wed, 7 Nov 2007 08:04:19 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA7D40dW003293; Wed, 7 Nov 2007 13:04:18 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 08:04:08 -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 Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering forDHCPauthentication Date: Wed, 7 Nov 2007 08:04:59 -0500 Message-ID: In-Reply-To: <78AE241E-C3EC-4DCC-A52E-0615BE421FB0@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering forDHCPauthentication Thread-Index: AcghNqSRIMtejNA6QuqLIl2FWroppAABZxPw References: <0MKpCa-1Ip7Tp4AID-0008VV@mrelay.perfora.net><472FC860.6000104@cisco.com><8D9309C4-247F-4751-BFDC-00CCEB9367E7@cisco.com> <78AE241E-C3EC-4DCC-A52E-0615BE421FB0@cisco.com> From: "Eric Voit (evoit)" To: "Ralph Droms (rdroms)" X-OriginalArrivalTime: 07 Nov 2007 13:04:08.0682 (UTC) FILETIME=[AEF1A4A0:01C8213E] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.002 X-TM-AS-Result: No--33.484400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3224; t=1194440659; x=1195304659; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=evoit@cisco.com; z=From:=20=22Eric=20Voit=20(evoit)=22=20 |Subject:=20RE=3A=20[Int-area]=20Re=3A=20[dhcwg]=20Discussion=20of=20dhc= 20WG=20rechartering=20forDHCPauthentication |Sender:=20 |To:=20=22Ralph=20Droms=20(rdroms)=22=20; bh=ADaH7Jtsrhy9MkUDvpGEiKm7cW0Nt5wUIRwICcVkpI8=; b=CIu5XnF63J4Vb+STztEe5kKzhJS21ulcdO211PVcAk07BKabJ2LT46i4eF1AeyyOcYjDvJt+ 9lMTvnQaTJmdLvUeniOTbZcjmb/23TDtWzTOEoqXpAChgiboAmhRWYhf; Authentication-Results: rtp-dkim-2; header.From=evoit@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: dhcwg@ietf.org, Internet Area X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi Ralph, Doubling the load on the DHCP servers probably will not change the game. The extra load on the L3 Edge/BRAS could easily chanFrom dhcwg-bounces@ietf.org Wed Nov 14 08:11:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1U-0002kW-Ew; Wed, 14 Nov 2007 08:11:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpkZw-00069l-3T; Wed, 07 Nov 2007 08:04:20 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpkZv-0005u0-In; Wed, 07 Nov 2007 08:04:20 -0500 X-IronPort-AV: E=Sophos;i="4.21,384,1188792000"; d="scan'208";a="75360698" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Nov 2007 08:04:19 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA7D4J98013978; Wed, 7 Nov 2007 08:04:19 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA7D40dW003293; Wed, 7 Nov 2007 13:04:18 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 08:04:08 -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 Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering forDHCPauthentication Date: Wed, 7 Nov 2007 08:04:59 -0500 Message-ID: In-Reply-To: <78AE241E-C3EC-4DCC-A52E-0615BE421FB0@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering forDHCPauthentication Thread-Index: AcghNqSRIMtejNA6QuqLIl2FWroppAABZxPw References: <0MKpCa-1Ip7Tp4AID-0008VV@mrelay.perfora.net><472FC860.6000104@cisco.com><8D9309C4-247F-4751-BFDC-00CCEB9367E7@cisco.com> <78AE241E-C3EC-4DCC-A52E-0615BE421FB0@cisco.com> From: "Eric Voit (evoit)" To: "Ralph Droms (rdroms)" X-OriginalArrivalTime: 07 Nov 2007 13:04:08.0682 (UTC) FILETIME=[AEF1A4A0:01C8213E] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.002 X-TM-AS-Result: No--33.484400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3224; t=1194440659; x=1195304659; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=evoit@cisco.com; z=From:=20=22Eric=20Voit=20(evoit)=22=20 |Subject:=20RE=3A=20[Int-area]=20Re=3A=20[dhcwg]=20Discussion=20of=20dhc= 20WG=20rechartering=20forDHCPauthentication |Sender:=20 |To:=20=22Ralph=20Droms=20(rdroms)=22=20; bh=ADaH7Jtsrhy9MkUDvpGEiKm7cW0Nt5wUIRwICcVkpI8=; b=CIu5XnF63J4Vb+STztEe5kKzhJS21ulcdO211PVcAk07BKabJ2LT46i4eF1AeyyOcYjDvJt+ 9lMTvnQaTJmdLvUeniOTbZcjmb/23TDtWzTOEoqXpAChgiboAmhRWYhf; Authentication-Results: rtp-dkim-2; header.From=evoit@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: dhcwg@ietf.org, Internet Area X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi Ralph, Doubling the load on the DHCP servers probably will not change the game. The extra load on the L3 Edge/BRAS could easily change the game (and hence the emails from Peter (Redback) & Bill (Juniper)). =20 The extra complexity with the CPE has always been my biggest concern, and is why I entered the thread many weeks ago. Eric=20 > From: Ralph Droms, November 07, 2007 7:06 AM >=20 > Eric - I was mostly responding to Ric's description of the=20 > excessive load on DHCP servers in the short-lease/long-lease=20 > scenario. As I understand the short-lease/long-lease=20 > scenario, if we assume that authentication takes place in the=20 > short-lease window, the load on the DHCP servers would=20 > double. Significant, sure, but not game-changing in the way=20 > Ric implied. >=20 > - Ralph >=20 > On Nov 6, 2007, at Nov 6, 2007,10:39 PM, Eric Voit (evoit) wrote: >=20 > >> From: Ralph Droms, November 05, 2007 9:37 PM > >> > >> Does the short lease/long lease scenario scale the DHCP=20 > server load=20 > >> by more than a factor of two? > > > > Ralph, > > > > The messages the DHCP servers will double. > > The messages with L3 edge (BRAS) will more than double. > > The messages with the CPE will more than triple. > > > > (Below is some rough math. I might have missed a message or=20 > two, but=20 > > the general trend is what I am trying to show.) > > > > ----------------------------------------- > > CPE Messages > > ----------------------------------------- > > DHCP Auth, assuming a 2 message EAP Method, the messages=20 > used by EAP=20 > > would be equal > > + 6 Messages (draft-pruss-dhcp-auth-dsl-01) > > > > PANA+DHCP Method > > + 4 Messages: DHCP 1st IP address > > ~ (+2) DHCP renews per 60 seconds until authenticated > > + 11 Messages PANA with BRAS (draft-ietf-pana-pana-18, section 4.1) > > + 4 Messages: DHCP 2nd IP address > > > > ----------------------------------------- > > L3 Edge (BRAS) Messages > > ----------------------------------------- > > DHCP Auth, EAP Method > > + 8 Messages (draft-pruss-dhcp-auth-dsl-01) > > > > PANA Method > > + 4 Messages: DHCP 1st IP address > > ~ (+2) DHCP renews per 60 seconds until authenticated > > + 11 Messages PANA with CPE (draft-ietf-pana-pana-18, section 4.1) > > + 2 messages min for validating with EAP Server > > + 4 Messages: DHCP 2nd IP address > > > > ----------------------------------------- > > L2 Edge (DSLAM or Access Switch) Messages > > ----------------------------------------- > > DHCP Auth, EAP Method > > + 6 Messages snooped (draft-pruss-dhcp-auth-dsl-01) > > > > PANA+DHCP Method > > + 4 Messages Snooped: DHCP 1st IP address > > ~ (+2) DHCP renews per 60 seconds until authenticated If=20 > snooping: 11=20 > > Messages PANA (draft-ietf-pana-pana-18, section 4.1) Else=20 > if explicit=20 > > policy distribution like ANCP, ~4 messages (one policy per address) > > + 4 Messages Snooped: DHCP 2nd IP address > > > > > > Eric > > > > > >> - Ralph > >> >=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1U-0002kk-Tt; Wed, 14 Nov 2007 08:11:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipm7B-0003Oz-4Y; Wed, 07 Nov 2007 09:42:45 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ipm7A-0002AV-Ge; Wed, 07 Nov 2007 09:42:45 -0500 X-IronPort-AV: E=Sophos;i="4.21,384,1188792000"; d="scan'208";a="136249735" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Nov 2007 09:42:44 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA7EghAu025727; Wed, 7 Nov 2007 09:42:43 -0500 Received: from xbh-rtp-201.amerge the game (and hence the emails from Peter (Redback) & Bill (Juniper)). =20 The extra complexity with the CPE has always been my biggest concern, and is why I entered the thread many weeks ago. Eric=20 > From: Ralph Droms, November 07, 2007 7:06 AM >=20 > Eric - I was mostly responding to Ric's description of the=20 > excessive load on DHCP servers in the short-lease/long-lease=20 > scenario. As I understand the short-lease/long-lease=20 > scenario, if we assume that authentication takes place in the=20 > short-lease window, the load on the DHCP servers would=20 > double. Significant, sure, but not game-changing in the way=20 > Ric implied. >=20 > - Ralph >=20 > On Nov 6, 2007, at Nov 6, 2007,10:39 PM, Eric Voit (evoit) wrote: >=20 > >> From: Ralph Droms, November 05, 2007 9:37 PM > >> > >> Does the short lease/long lease scenario scale the DHCP=20 > server load=20 > >> by more than a factor of two? > > > > Ralph, > > > > The messages the DHCP servers will double. > > The messages with L3 edge (BRAS) will more than double. > > The messages with the CPE will more than triple. > > > > (Below is some rough math. I might have missed a message or=20 > two, but=20 > > the general trend is what I am trying to show.) > > > > ----------------------------------------- > > CPE Messages > > ----------------------------------------- > > DHCP Auth, assuming a 2 message EAP Method, the messages=20 > used by EAP=20 > > would be equal > > + 6 Messages (draft-pruss-dhcp-auth-dsl-01) > > > > PANA+DHCP Method > > + 4 Messages: DHCP 1st IP address > > ~ (+2) DHCP renews per 60 seconds until authenticated > > + 11 Messages PANA with BRAS (draft-ietf-pana-pana-18, section 4.1) > > + 4 Messages: DHCP 2nd IP address > > > > ----------------------------------------- > > L3 Edge (BRAS) Messages > > ----------------------------------------- > > DHCP Auth, EAP Method > > + 8 Messages (draft-pruss-dhcp-auth-dsl-01) > > > > PANA Method > > + 4 Messages: DHCP 1st IP address > > ~ (+2) DHCP renews per 60 seconds until authenticated > > + 11 Messages PANA with CPE (draft-ietf-pana-pana-18, section 4.1) > > + 2 messages min for validating with EAP Server > > + 4 Messages: DHCP 2nd IP address > > > > ----------------------------------------- > > L2 Edge (DSLAM or Access Switch) Messages > > ----------------------------------------- > > DHCP Auth, EAP Method > > + 6 Messages snooped (draft-pruss-dhcp-auth-dsl-01) > > > > PANA+DHCP Method > > + 4 Messages Snooped: DHCP 1st IP address > > ~ (+2) DHCP renews per 60 seconds until authenticated If=20 > snooping: 11=20 > > Messages PANA (draft-ietf-pana-pana-18, section 4.1) Else=20 > if explicit=20 > > policy distribution like ANCP, ~4 messages (one policy per address) > > + 4 Messages Snooped: DHCP 2nd IP address > > > > > > Eric > > > > > >> - Ralph > >> >=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1U-0002kk-Tt; Wed, 14 Nov 2007 08:11:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipm7B-0003Oz-4Y; Wed, 07 Nov 2007 09:42:45 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ipm7A-0002AV-Ge; Wed, 07 Nov 2007 09:42:45 -0500 X-IronPort-AV: E=Sophos;i="4.21,384,1188792000"; d="scan'208";a="136249735" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Nov 2007 09:42:44 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA7EghAu025727; Wed, 7 Nov 2007 09:42:43 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA7EdSWV005213; Wed, 7 Nov 2007 14:42:43 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 09:42:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering forDHCPauthentication Date: Wed, 7 Nov 2007 09:43:31 -0500 Message-ID: In-Reply-To: <0MKpCa-1Ipiht1wKu-0008SB@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering forDHCPauthentication Thread-Index: AcggHm+KfPGdwHk5Th6TDrp6Vvyw4QAzsuSAAA8SLPAAB8cG8A== References: <0MKpCa-1Ipiht1wKu-0008SB@mrelay.perfora.net> From: "Eric Voit (evoit)" To: "Alper Yegin" X-OriginalArrivalTime: 07 Nov 2007 14:42:38.0846 (UTC) FILETIME=[71AD19E0:01C8214C] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.002 X-TM-AS-Result: No--25.528600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4671; t=1194446563; x=1195310563; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=evoit@cisco.com; z=From:=20=22Eric=20Voit=20(evoit)=22=20 |Subject:=20RE=3A=20[Int-area]=20Re=3A=20[dhcwg]=20Discussion=20of=20dhc= 20WG=20rechartering=20forDHCPauthentication |Sender:=20 |To:=20=22Alper=20Yegin=22=20; bh=De529+Lmdfgh0z6zsfSd/CI6eXs1bnBTe7fVG25wlZs=; b=zye/TgOj2M6PcKBosW/vH922Sfb0BEsPPnGY/lPXVBamgNGk9csonlySM/M+lDZ942eZEnEr fVdiKxXu81E86jtKzOsCvf60rJqt+nUrpqOZB+FAlErBFdzVShBm3Iqj; Authentication-Results: rtp-dkim-2; header.From=evoit@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: dhcwg@ietf.org, Internet Area , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > From: Alper Yegin, November 07, 2007 6:04 AM >=20 > First of all, there is no way use of PANA would lead to more=20 > DHCP traffic. ? You say below "full dhcp, pana, another full dhcp". Sounds like doubling the DHCP traffic to me. But there is another issue. It is very normal for AAA servers to take time for all the sessions to authenticate after a BRAS reboot or pop-wide power failure. PANA has the potential to introduce a large amount of additional DHCP traffic simply due to short lease timer renews being requested prior to authentication completion. This sounds like a pretty effective distributed denial of service attack to me. > How can that be true when carrying EAP over DHCP always at=20 > the minimum contribute 2 additional round-trips just for the=20 > sake of transporting EAP? =20 I was trying to make the EAP method equivalent between the two cases. Am I missing something? =20 > In the worst case (DHCP-configured pre-PANA address), there=20 > are two round trips for that 1st DHCP. Even in that case PANA=20 > is no worse than DHCP-auth. >=20 > And then there are better cases, e.g. use of link-local=20 > address as pre-PANA address, rapid commit, etc. >.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA7EdSWV005213; Wed, 7 Nov 2007 14:42:43 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 09:42:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering forDHCPauthentication Date: Wed, 7 Nov 2007 09:43:31 -0500 Message-ID: In-Reply-To: <0MKpCa-1Ipiht1wKu-0008SB@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering forDHCPauthentication Thread-Index: AcggHm+KfPGdwHk5Th6TDrp6Vvyw4QAzsuSAAA8SLPAAB8cG8A== References: <0MKpCa-1Ipiht1wKu-0008SB@mrelay.perfora.net> From: "Eric Voit (evoit)" To: "Alper Yegin" X-OriginalArrivalTime: 07 Nov 2007 14:42:38.0846 (UTC) FILETIME=[71AD19E0:01C8214C] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.002 X-TM-AS-Result: No--25.528600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4671; t=1194446563; x=1195310563; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=evoit@cisco.com; z=From:=20=22Eric=20Voit=20(evoit)=22=20 |Subject:=20RE=3A=20[Int-area]=20Re=3A=20[dhcwg]=20Discussion=20of=20dhc= 20WG=20rechartering=20forDHCPauthentication |Sender:=20 |To:=20=22Alper=20Yegin=22=20; bh=De529+Lmdfgh0z6zsfSd/CI6eXs1bnBTe7fVG25wlZs=; b=zye/TgOj2M6PcKBosW/vH922Sfb0BEsPPnGY/lPXVBamgNGk9csonlySM/M+lDZ942eZEnEr fVdiKxXu81E86jtKzOsCvf60rJqt+nUrpqOZB+FAlErBFdzVShBm3Iqj; Authentication-Results: rtp-dkim-2; header.From=evoit@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: dhcwg@ietf.org, Internet Area , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > From: Alper Yegin, November 07, 2007 6:04 AM >=20 > First of all, there is no way use of PANA would lead to more=20 > DHCP traffic. ? You say below "full dhcp, pana, another full dhcp". Sounds like doubling the DHCP traffic to me. But there is another issue. It is very normal for AAA servers to take time for all the sessions to authenticate after a BRAS reboot or pop-wide power failure. PANA has the potential to introduce a large amount of additional DHCP traffic simply due to short lease timer renews being requested prior to authentication completion. This sounds like a pretty effective distributed denial of service attack to me. > How can that be true when carrying EAP over DHCP always at=20 > the minimum contribute 2 additional round-trips just for the=20 > sake of transporting EAP? =20 I was trying to make the EAP method equivalent between the two cases. Am I missing something? =20 > In the worst case (DHCP-configured pre-PANA address), there=20 > are two round trips for that 1st DHCP. Even in that case PANA=20 > is no worse than DHCP-auth. >=20 > And then there are better cases, e.g. use of link-local=20 > address as pre-PANA address, rapid commit, etc. >=20 > As for your 11-msg PANA call flow count, the example you used=20 > is the most verbose one. If you turn on the optimizations=20 > (agent-side initiation, > piggybacking) it reduces to 2 round trips. I chose the best message flow I could find within draft-ietf-pana-pana-18. As I read your words above, I cannot match all the potential variations to the DSLF requirements. Is there another documented DHCP+PANA message flow somewhere which meets the DSLF requirements which I should use instead? Eric =20 >=20 > So, in the worst case scenario (full dhcp, pana, another full=20 > dhcp), PANA has additional 2 round-trips. By kicking in more=20 > optimized deployment choices, this difference can be diminished. >=20 >=20 > Alper >=20 > > -----Original Message----- > > From: Eric Voit (evoit) [mailto:evoit@cisco.com] > > Sent: Wednesday, November 07, 2007 5:40 AM > > To: Ralph Droms (rdroms) > > Cc: dhcwg@ietf.org; Internet Area > > Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WG=20 > rechartering=20 > > forDHCPauthentication > >=20 > > > From: Ralph Droms, November 05, 2007 9:37 PM > > > > > > Does the short lease/long lease scenario scale the DHCP=20 > server load=20 > > > by more than a factor of two? > >=20 > > Ralph, > >=20 > > The messages the DHCP servers will double. > > The messages with L3 edge (BRAS) will more than double. > > The messages with the CPE will more than triple. > >=20 > > (Below is some rough math. I might have missed a message or=20 > two, but=20 > > the general trend is what I am trying to show.) > >=20 > > ----------------------------------------- > > CPE Messages > > ----------------------------------------- > > DHCP Auth, assuming a 2 message EAP Method, the messages=20 > used by EAP=20 > > would be equal > > + 6 Messages (draft-pruss-dhcp-auth-dsl-01) > >=20 > > PANA+DHCP Method > > + 4 Messages: DHCP 1st IP address > > ~ (+2) DHCP renews per 60 seconds until authenticated > > + 11 Messages PANA with BRAS (draft-ietf-pana-pana-18, section 4.1) > > + 4 Messages: DHCP 2nd IP address > >=20 > > ----------------------------------------- > > L3 Edge (BRAS) Messages > > ----------------------------------------- > > DHCP Auth, EAP Method > > + 8 Messages (draft-pruss-dhcp-auth-dsl-01) > >=20 > > PANA Method > > + 4 Messages: DHCP 1st IP address > > ~ (+2) DHCP renews per 60 seconds until authenticated > > + 11 Messages PANA with CPE (draft-ietf-pana-pana-18, section 4.1) > > + 2 messages min for validating with EAP Server > > + 4 Messages: DHCP 2nd IP address > >=20 > > ----------------------------------------- > > L2 Edge (DSLAM or Access Switch) Messages > > ----------------------------------------- > > DHCP Auth, EAP Method > > + 6 Messages snooped (draft-pruss-dhcp-auth-dsl-01) > >=20 > > PANA+DHCP Method > > + 4 Messages Snooped: DHCP 1st IP address > > ~ (+2) DHCP renews per 60 seconds until authenticated If=20 > snooping: 11=20 > > Messages PANA (draft-ietf-pana-pana-18, section 4.1) Else=20 > if explicit=20 > > policy distribution like ANCP, ~4 messages (one policy per address) > > + 4 Messages Snooped: DHCP 2nd IP address > >=20 > >=20 > > Eric > >=20 > >=20 > > > - Ralph > > > > >=20 > >=20 > > _______________________________________________ > > Int-area mailing list > > Int-area@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/int-area >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg =20 > As for your 11-msg PANA call flow count, the example you used=20 > is the most verbose one. If you turn on the optimizations=20 > (agent-side initiation, > piggybacking) it reduces to 2 round trips. I chose the best message flow I could find within draft-ietf-pana-pana-18. As I read your words above, I cannot match all the potential variations to the DSLF requirements. Is there another documented DHCP+PANA message flow somewhere which meets the DSLF requirements which I should use instead? Eric =20 >=20 > So, in the worst case scenario (full dhcp, pana, another full=20 > dhcp), PANA has additional 2 round-trips. By kicking in more=20 > optimized deployment choices, this difference can be diminished. >=20 >=20 > Alper >=20 > > -----Original Message----- > > From: Eric Voit (evoit) [mailto:evoit@cisco.com] > > Sent: Wednesday, November 07, 2007 5:40 AM > > To: Ralph Droms (rdroms) > > Cc: dhcwg@ietf.org; Internet Area > > Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WG=20 > rechartering=20 > > forDHCPauthentication > >=20 > > > From: Ralph Droms, November 05, 2007 9:37 PM > > > > > > Does the short lease/long lease scenario scale the DHCP=20 > server load=20 > > > by more than a factor of two? > >=20 > > Ralph, > >=20 > > The messages the DHCP servers will double. > > The messages with L3 edge (BRAS) will more than double. > > The messages with the CPE will more than triple. > >=20 > > (Below is some rough math. I might have missed a message or=20 > two, but=20 > > the general trend is what I am trying to show.) > >=20 > > ----------------------------------------- > > CPE Messages > > ----------------------------------------- > > DHCP Auth, assuming a 2 message EAP Method, the messages=20 > used by EAP=20 > > would be equal > > + 6 Messages (draft-pruss-dhcp-auth-dsl-01) > >=20 > > PANA+DHCP Method > > + 4 Messages: DHCP 1st IP address > > ~ (+2) DHCP renews per 60 seconds until authenticated > > + 11 Messages PANA with BRAS (draft-ietf-pana-pana-18, section 4.1) > > + 4 Messages: DHCP 2nd IP address > >=20 > > ----------------------------------------- > > L3 Edge (BRAS) Messages > > ----------------------------------------- > > DHCP Auth, EAP Method > > + 8 Messages (draft-pruss-dhcp-auth-dsl-01) > >=20 > > PANA Method > > + 4 Messages: DHCP 1st IP address > > ~ (+2) DHCP renews per 60 seconds until authenticated > > + 11 Messages PANA with CPE (draft-ietf-pana-pana-18, section 4.1) > > + 2 messages min for validating with EAP Server > > + 4 Messages: DHCP 2nd IP address > >=20 > > ----------------------------------------- > > L2 Edge (DSLAM or Access Switch) Messages > > ----------------------------------------- > > DHCP Auth, EAP Method > > + 6 Messages snooped (draft-pruss-dhcp-auth-dsl-01) > >=20 > > PANA+DHCP Method > > + 4 Messages Snooped: DHCP 1st IP address > > ~ (+2) DHCP renews per 60 seconds until authenticated If=20 > snooping: 11=20 > > Messages PANA (draft-ietf-pana-pana-18, section 4.1) Else=20 > if explicit=20 > > policy distribution like ANCP, ~4 messages (one policy per address) > > + 4 Messages Snooped: DHCP 2nd IP address > >=20 > >=20 > > Eric > >=20 > >=20 > > > - Ralph > > > > >=20 > >=20 > > _______________________________________________ > > Int-area mailing list > > Int-area@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/int-area >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1Y-0002rB-TC; Wed, 14 Nov 2007 08:11:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBKS-0001hE-6T for dhcwg@ietf.org; Thu, 08 Nov 2007 12:38:08 -0500 Received: from mail4.symmetricom.com ([69.25.98.6]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqBKR-0006ps-MO for dhcwg@ietf.org; Thu, 08 Nov 2007 12:38:08 -0500 X-ASG-Debug-ID: 1194543485-46af02cd0000-IQRdtg X-Barracuda-URL: http://192.168.10.95:80/cgi-bin/mark.cgi Received: from sjowa.symmetricom.com (localhost [127.0.0.1]) by mail4.symmetricom.com (Spam Firewall) with ESMTP id 07BA72DEE00; Thu, 8 Nov 2007 09:38:05 -0800 (PST) Received: from sjowa.symmetricom.com ([192.168.10.41]) by mail4.symmetricom.com with ESMTP id ngmWJfRVQfaWFOl6; Thu, 08 Nov 2007 09:38:05 -0800 (PST) X-ASG-Whitelist: Client Received: from sjmail2.symmetricom.com ([192.168.10.66]) by sjowa.symmetricom.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Nov 2007 09:38:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Date: Thu, 8 Nov 2007 09:38:05 -0800 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Thread-Index: AcgiHKqGaKJZnHkxTpKXpDEnqj6AlQADpkpA From: "Mark Elliot" To: "Benoit Lourdelet \(blourdel\)" , , X-OriginalArrivalTime: 08 Nov 2007 17:38:05.0737 (UTC) FILETIME=[1E9AF190:01C8222E] X-Barracuda-Connect: UNKNOWN[192.168.10.41] X-Barracuda-Start-Time: 1194543486 X-Barracuda-Virus-Scanned: by Symmetricom Spam Gateway at symmetricom.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:05 -0500 Cc: "Richard Gayraud \(rgayraud\)" Subject: [dhcwg] RE: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Great idea! I will take a look at the draft! I think its an idea that is needed!=20 -----Original Message----- From: ntpwg-bounces+melliot=3Dsymmetricom.com@lists.ntp.org [mailto:ntpwg-bounces+melliot=3Dsymmetricom.com@lists.ntp.org] On Behalf Of Benoit Lourdelet (blourdel) Sent: Thursday, November 08, 2007 7:41 AM To: ntpwg@lists.ntp.org; dhcwg@ietf.org Cc: Richard Gayraud (rgayraud) Subject: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Hello,=20 We have just submitted a new draft proposing an NTP option for DHCPv6.=20 The goal of this draft is to standardize automatic configuration of NTPv4 (IPv6) clients over DHCPv6. We think there is currently no satisfactory solution for configuring NTPv4 clients from a centralized DHCPv6 server. We'd be very happy to hear feedback about the draft, and I'm planning to ask that it becomes a WG draft eventually. Here's a url: =20 http://www.ietf.org/internet-drafts/draft-gayraud-dhcpv6-ntp-opt-00.txt Thanks, Richard and Benoit _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1Z-0002zX-Uf; Wed, 14 Nov 2007 08:11:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBYe-0006uO-OW for dhcwg@ietf.org; Thu, 08 Nov 2007 12:52:48 -0500 Received: from mail1.ntp.org ([204.152.184.126]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqBYe-0007H5-7x for dhcwg@ietf.org; Thu, 08 Nov 2007 12:52:48 -0500 Received: from localhost (localhost [127.0.0.1]) by mail1.ntp.org (Postfix) with ESMTP id 240FB39DF6; Thu, 8 Nov 2007 17:52:45 +0000 (UTC) (envelope-from stenn@ntp1.ntp.org) Received: from mail1.ntp.org ([127.0.0.1]) by localhost (ntp1.isc.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53161-02; Thu, 8 Nov 2007 17:52:24 +0000 (UTC) Received: from ntp1.ntp.org (localhost [127.0.0.1]) by mail1.ntp.org (Postfix) with ESMTP; Thu, 8 Nov 2007 17:52:23 +0000 (UTC) (envelope-from stenn@ntp1.ntp.org) To: "Benoit Lourdelet (blourdel)" In-Reply-To: Message from "Benoit Lourdelet (blourdel)" of "Thu, 08 Nov 2007 16:41:08 +0100." X-Mailer: MH-E 7.4.2; nmh 1.0.4; XEmacs 21.4 (patch 14) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 08 Nov 2007 17:52:23 +0000 From: Harlan Stenn X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on ntp1.isc.org Message-Id: <20071108175245.240FB39DF6@mail1.ntp.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "Richard Gayraud \(rgayraud\)" Subject: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Guys, Thanks for doing this. I've been sporadically discussing this with David Hankins. I have added the URL below to the appropriate section at: http://support.ntp.org/Dev/GettingNtpdItsConfiguration and for those of us who prefer using the TWiki over email for development discussion, I volunteer the above as a place to (also) have any discussion about this. H -- > Hello, > > We have just submitted a new draft proposing an NTP option for DHCPv6. > > The goal of this draft is to standardize automatic configuration of > NTPv4 (IPv6) clients over DHCPv6. > We think there is currently no satisfactory solution for configuring > NTPv4 clients from a centralized DHCPv6 server. > > We'd be very happy to hear feedback about the draft, and I'm planning to > ask that it becomes a WG draft eventually. > > Here's a url: > > > http://www.ietf.org/internet-drafts/draft-gayraud-dhcpv6-ntp-opt-00.txt > > > Thanks, > > Richard and Benoit > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1a-00031o-O5; Wed, 14 Nov 2007 08:11:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqDNq-0001i4-9u for dhcwg@ietf.org; Thu, 08 Nov 2007 14:49:46 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqDNg-0001GT-V1 for dhcwg@ietf.org; Thu, 08 Nov 2007 14:49:46 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA8Jn36s026881; Thu, 8 Nov 2007 21:49:31 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 21:49:28 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 13:49:26 -0600 Received: from 172.19.244.140 ([172.19.244.140]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 8 Nov 2007 19:49:25 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 08 Nov 2007 13:50:16 -0500 Subject: Re: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication From: Basavaraj Patil To: Message-ID: Thread-Topic: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication Thread-Index: AcgiQJVp097zRo4zEdyP2QARJNUNiA== In-Reply-To: <47315A41.6020803@cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 08 Nov 2007 19:49:26.0139 (UTC) FILETIME=[77B0DCB0:01C82240] X-Nokia-AV: Clean X-Spam-Score: 2.1 (++) X-Scan-Signature: f5c1164b9029aa0dd842007e530e24ad X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: dhcwg@ietf.org, ext Ralph Droms X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1799561383==" Errors-To: dhcwg-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1799561383== Content-type: multipart/alternative; boundary="B_3277374616_71793029" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3277374616_71793029 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Ric, So I understand that the reason to use DHCP as a means to do the authentication of the subscriber is from the perspective of: 1. Minimal impact to deployed large scale DSL networks 2. Reusing a protocol that is already used in DSL networks rather than having to implement a new protocol because of the deployed base and backwards compatibility I think I understand your predicament a little better now. I am just wondering if the DSL forum is going down the wrong path by extending DHCP to solve a problem by taking this band-aid approach instead of solving it the right way (whether that is 802.1x, PANA or whatever else)= . -Raj On 11/7/07 1:25 AM, "ext Richard Pruss" wrote: >=20 >=20 > Basavaraj Patil wrote, around 2/11/07 1:49 AM: >> Re: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication >> Ric, >> =20 >> That=B9s not the point. I agree that we do authentication at several layer= s >> today. Access auth, SIP auth, etc. >> But what the I-D is proposing is basically extending DHCP to accomplish >> access auth. >> For access auth, there are several mechanisms today. Do we need DHCP to = solve >> the access-auth problem as well? >> =20 >> What is the primary reason/argument for doing access auth via DHCP? Is i= t an >> optimization or is it because there is no other way to solve the access = auth >> problem in the domain that you are looking at? >> =20 > There a confluence of two design directions in DSL architecture coming > together driving the next generation of IP session requirements in DSL Fo= rum. >=20 > One direction comes from small greenfield networks and the move to ethern= et, > they have been deploying DSL with DHCP and Option 82 line details providi= ng > the identity criteria to configure the host but also the L2 and L3 edges. > Most of the DSL BRAS vendors now allow the BRAS to use DHCP attributes tr= igger > configuration retrieval for the BRAS from RADIUS. >=20 > The second comes from large long standing PPPoE/PPPoA networks which have > massive databases of existing users and want to allow a gradual migration= to > ethernet service delivery but not require churn in the customer authentic= ation > database. >=20 > Finally DSL architecture is all about scaling (I guess SP engineering alw= ays > is) where we have BRAS's with 60K+ subscribers on and millions of users o= n the > network, we try set everything up at the same time and do it once. To be > clear we did not start off by trying to invent something new here, we wen= t > through many existing approaches before we got here today. >=20 > I think if you take the authentication question in the DSL architecture > context, the simple questions that are probably bugging you like "Why did= they > not just use 802.1x?" might be clearer: >=20 > The current recommended DSL Forum architecture is in TR-101: > http://www.dslforum.org/techwork/tr/TR-101.pdf >=20 > The current draft of next generation WT-148 is: > http://www.arkko.com/ietf/intarea/dsl2006.887.03.doc >=20 > The living list of requirements for authentication for WT-146 is: > https://datatracker.ietf.org/documents/LIAISON/file457.doc >=20 > - Ric >=20 >=20 >>=20 >> -Raj >> =20 >> =20 >> On 11/1/07 10:33 AM, "ext Richard Pruss" >> wrote: >> =20 >> =20 >>> Authentication is something that happens at every layer with every >>> application. Terminal access was designed without authentication, that = does >>> not mean we do it like that today. >>> =20 >>> I do not think we can take the argument of it was not designed for x a= s a >>> reason to stay in the past. >>> =20 >>> Regards, >>> Ric >>> =20 >>> Basavaraj Patil wrote, around 29/10/07 9:42 AM: >>> =20 >>>> =20 >>>> Ralph, >>>> =20 >>>> I think overloading DHCP for access authentication is a bad idea. DHCP= was >>>> not designed for that purpose. I guess I need to communicate this on t= he >>>> int-area list. But anyway you know my opinion at least in the DHC WG. >>>> =20 >>>> -Basavaraj >>>> =20 >>>> =20 >>>> On 10/19/07 6:05 AM, "ext Ralph Droms" >>>> wrote: >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>>> =20 >>>>> There is a lengthy discussion about rechartering the dhc WG to take >>>>> on the DHCP authentication proposals in draft-pruss-dhcp-auth- >>>>> dsl-01.txt and draft-zhao-dhc-user-authentication-02 in the int- >>>>> area@ietf.org mailing list. Both of these drafts have been submitted >>>>> for to the WG for review in the past, and neither, to date, has been >>>>> accepted as a dhc WG work iterm. I've included a copy of the initial >>>>> posting, http://www1.ietf.org/mail-archive/web/int-area/current/ >>>>> msg00957.html, below. Because this discussion may lead to the >>>>> rechartering of the dhc WG to take on either or both of these drafts >>>>> as new work items, those of you not on the int-area mailing list >>>>> should consider reviewing the e-mail thread and contributing to the >>>>> discussion. >>>>> =20 >>>>> - Ralph >>>>> =20 >>>>> =20 >>>>> =3D=3D=3D=3D=3D >>>>> To: Internet Area >>>>> Subject: [Int-area] DCHP-based authentication for DSL? >>>>> From: Jari Arkko >>>>> Date: Thu, 04 Oct 2007 23:22:15 +0300 >>>>> =20 >>>>> =20 >>>>> We talked about the DSL requirements earlier on this list. Now >>>>> they have sent us a liaison statement regarding what they would >>>>> like to do: >>>>> =20 >>>>> "At this time, we would like to make the IETF aware that during >>>>> our most recent DSL Forum quarterly meeting, the Architecture >>>>> and Transport Working Group agreed to seriously consider adopting >>>>> a mechanism such as that proposed in draft-pruss-dhcp-auth-dsl-01.txt >>>>> or draft-zhao-dhc-user-authentication-02. We understand that the auth= ors >>>>> of these specifications intend to produce a combined document soon. >>>>> The DSL Forum formally requests that the IETF adopt this as a work >>>>> item, and would appreciate being advised of progress as soon as >>>>> possible. >>>>> =20 >>>>> Our next quarterly meeting is December 10-13, in Lisbon, Portugal." >>>>> =20 >>>>> =20 >>>>> How do we feel about this? Is this a good idea, considering the DSL >>>>> architecture? How will it affect DHCP the protocol? How would >>>>> you go about making DHCP extensions so that they work best >>>>> for all possible environments and not just DSL? Is anyone >>>>> already working on the combined draft promised above? Are >>>>> there any other choices that we should recommend instead? >>>>> =20 >>>>> I would like to hold the discussion on this in this list until >>>>> we've determined that the DHCP protocol is the right tool >>>>> for the job. If it is, we can recharter DHC WG again to add >>>>> the actual development work there. (DHC is right now >>>>> being rechartered but that recharting is mostly a cleanup >>>>> and not the addition of functionality to do this.) >>>>> =20 >>>>> Jari >>>>> =20 >>>>> =20 >>>>> _______________________________________________ >>>>> dhcwg mailing list >>>>> dhcwg@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/dhcwg >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> _______________________________________________ >>>> dhcwg mailing list >>>> dhcwg@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dhcwg >>>> =20 >>>> =20 >>>> =20 >>> =20 >>> =20 >> =20 >> =20 >=20 --B_3277374616_71793029 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [dhcwg] Discussion of dhc WG rechartering for DHCP authenticatio= n
Hi Ric,

So I understand that the reason to use DHCP as a means to do the authentica= tion of the subscriber is from the perspective of:
  1. Minimal impact to deployed large scale DSL networks
  2. Reusing a protocol that is already used in DSL networks rather = than having to implement a new protocol because of the deployed base and bac= kwards compatibility

I think I understand your predicament a little better now.
I am just wondering if the DSL forum is going down the wrong path by extend= ing DHCP to solve a problem by taking this band-aid approach instead of solv= ing it the right way (whether that is 802.1x, PANA or whatever else).

-Raj

On 11/7/07 1:25 AM, "ext Richard Pruss" <ric@cisco.com> wro= te:



Basavaraj Patil wrote, around 2/11/07 1:49 AM:
Re: [dhcwg] Discussion of dhc WG rechartering for DHCP= authentication
Ric,
 
That’s not the point. I agree that we do authentication at several la= yers today. Access auth, SIP auth, etc.
But what the I-D is proposing is basically extending DHCP to accomplish acc= ess auth.
For access auth, there are several mechanisms today. Do we need DHCP to sol= ve the access-auth problem as well?
 
What is the primary reason/argument for doing access auth via DHCP? Is it a= n optimization or is it because there is no other way to solve the access au= th problem in the domain that you are looking at?
 
There a confluence of two design directions in DSL arc= hitecture coming together driving the next generation of IP session requirem= ents in DSL Forum.

One direction comes from small greenfield networks and the move to ethernet= , they have been deploying DSL with DHCP and Option 82 line details providin= g the identity criteria to configure the host but also the L2 and L3 edges. =  Most of the DSL BRAS vendors now allow the BRAS to use DHCP attributes= trigger configuration retrieval for the BRAS from RADIUS.

The second comes from large long standing PPPoE/PPPoA networks which have m= assive databases of existing users and want to allow a gradual migration to = ethernet service delivery but not require churn in the customer authenticati= on database.

Finally DSL architecture is all about scaling (I guess SP engineering alway= s is) where we have BRAS's with 60K+ subscribers on and millions of users on= the network, we try set everything up at the same time and do it once. &nbs= p;To be clear we did not start off by trying to invent something new here, w= e went through many existing approaches before we got here today.

I think if you take the authentication question in the DSL architecture con= text, the simple questions that are probably bugging you like "Why did = they not just use 802.1x?" might be clearer:

The current recommended DSL Forum architecture is in TR-101:
http://www.dslforu= m.org/techwork/tr/TR-101.pdf

The current draft of next generation WT-148 is:
http://www.a= rkko.com/ietf/intarea/dsl2006.887.03.doc

The living list of requirements for authentication for WT-146 is:
https://datatracker.ietf.org/documents/LIAISON/file457.doc

- Ric



-Raj
 
 
On 11/1/07 10:33 AM, "ext Richard Pruss" <rpruss@cisco.com>= <mailto:rpruss@cisco.com>  = ;wrote:
 
  
Authentication is something that happens at every layer= with every application. Terminal access was designed without authentication= , that does not mean we do it like that today.
 
 I do not think we can take the argument of it was not designed for x = as a reason to stay in the past.
 
Regards,
Ric
 
Basavaraj Patil wrote, around 29/10/07 9:42 AM:
  

Ralph,
 
I think overloading DHCP for access authentication is a bad idea. DHCP was<= BR> not designed for that purpose. I guess I need to communicate this on the int-area list. But anyway you know my opinion at least in the DHC WG.
 
-Basavaraj
 
 
On 10/19/07 6:05 AM, "ext Ralph Droms" <rdroms@cisco.com> <= a href=3D"mailto:rdroms@cisco.com"><mailto:rdroms@cisco.com>  <= a href=3D"mailto:rdroms@cisco.com"><mailto:rdroms@cisco.com>  w= rote:
 
  
 
  

There is a lengthy discussion about rechartering the dhc WG to take
on the DHCP authentication proposals in draft-pruss-dhcp-auth-
dsl-01.txt and draft-zhao-dhc-user-authentication-02 in the int-
area@ietf.org mailing list.  Both of these drafts have been submitted<= BR> for to the WG for review in the past, and neither, to date, has been
accepted as a dhc WG work iterm.  I've included a copy of the initial<= BR> posting, = http://www1.ietf.org/mail-archive/web/int-area/current/
msg00957.html, below.  Because this discussion may lead to the
rechartering of the dhc WG to take on either or both of these drafts
as new work items, those of you not on the int-area mailing list
should consider reviewing the e-mail thread and contributing to the
discussion.
 
- Ralph
 
 
=3D=3D=3D=3D=3D
To: Internet Area <int-area at ietf.org>
Subject: [Int-area] DCHP-based authentication for DSL?
From: Jari Arkko <jari.arkko at piuha.net>
Date: Thu, 04 Oct 2007 23:22:15 +0300
 
 
We talked about the DSL requirements earlier on this list. Now
they have sent us a liaison statement regarding what they would
like to do:
 
"At this time, we would like to make the IETF aware that during
our most recent DSL Forum quarterly meeting, the Architecture
and Transport Working Group agreed to seriously consider adopting
a mechanism such as that proposed in draft-pruss-dhcp-auth-dsl-01.txt
or draft-zhao-dhc-user-authentication-02. We understand that the authors of these specifications intend to produce a combined document soon.
The DSL Forum formally requests that the IETF adopt this as a work
item, and would appreciate being advised of progress as soon as
possible.
 
Our next quarterly meeting is December 10-13, in Lisbon, Portugal."  
 
How do we feel about this? Is this a good idea, considering the DSL
architecture? How will it affect DHCP the protocol? How would
you go about making DHCP extensions so that they work best
for all possible environments and not just DSL? Is anyone
already working on the combined draft promised above? Are
there any other choices that we should recommend instead?
 
I would like to hold the discussion on this in this list until
we've determined that the DHCP protocol is the right tool
for the job. If it is, we can recharter DHC WG again to add
the actual development work there. (DHC is right now
being rechartered but that recharting is mostly a cleanup
and not the addition of functionality to do this.)
 
Jari
 
 
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
    
 
 
 
 
 
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
 
  
 

 

 


 --B_3277374616_71793029-- --===============1799561383== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1799561383==-- From dhcwg-bounces@ietf.org Wed Nov 14 08:11:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1b-000351-LB; Wed, 14 Nov 2007 08:11:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqpLB-0006My-4k for dhcwg@ietf.org; Sat, 10 Nov 2007 07:21:33 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqpL8-00068Q-Gd for dhcwg@ietf.org; Sat, 10 Nov 2007 07:21:33 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAACLTmN010343 for ; Sat, 10 Nov 2007 12:21:29 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRA00201I35VF00@mail-amer.sun.com> (original mail from Brian.Utterback@Sun.COM) for dhcwg@ietf.org; Sat, 10 Nov 2007 05:21:29 -0700 (MST) Received: from [192.168.1.5] ([71.168.64.220]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRA00JWTIBNWPE0@mail-amer.sun.com>; Sat, 10 Nov 2007 05:21:28 -0700 (MST) Date: Sat, 10 Nov 2007 07:21:23 -0500 From: Brian Utterback In-reply-to: To: "Benoit Lourdelet (blourdel)" Message-id: <4735A243.6090905@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <4733482A.7020302@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) X-Spam-Score: -1.0 (-) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "Richard Gayraud \(rgayraud\)" Subject: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Benoit Lourdelet (blourdel) wrote: > Hello, > > A possible usage of all the NTP parameters specified in the new options > is to configure router gateway . In that scenario, the goal of a Service > Provider or an Enterprise IT is to autoconfigure the gateway as much as > possible, including some NTP client behavior, in order to keep the > control. An additional benefit is that the gateway can be shipped to > remote sites virtually without any configuration while keeping full > control of the NTP behavior. I'm sorry, but I still don't see it. Are you saying that the router is a DHCP client and gets the server from DHCP? Okay fine, but how does minpoll, maxpoll, I and B get used? I still don't see the point of maxpoll here at all, that is, I don't even get what it means to the client to get this value imposed. See, minpoll says "do not poll more often than this", but maxpoll would mean "do not poll less often than this". This just doesn't make sense to me. > Following that line of thought, I may still see a need for "minpoll, > maxpoll, I and B fields". > Now, I could see the I and B meaning "do not do this" rather than "do this". If I and B are 0, then it means to do whatever you want, but if they are 1, then do not do it. It doesn't make sense to tell a client to use iburst when it wasn't going to anyway. Same with burts, although in a strange set of ceircumstances I could imagine the need for burst being known centrally, so maybe the B flag makes some kind of sense as is. > Considering a central DHCP server, the use of remote-id [RFC4649] or > just link-id may tell the server from where > the request is coming then giving it the knowledge of the delay to > apply. > In the case of a DHCP server hosted by the first hop, the DHCP server is > well positioned to know the delay. > > Oh, agreed, it is possible for the delay to be known. But I just don't think it is likely that it will ever be used correctly in that scenario. All I said is that it should generally be left at 0 unless there is a good reason not to. > Considering the current option format which includes more than IP > addresses, the choice of multiple occurrences of the > same option looks sensible. Should we reduce the new options to IPv6 > addresses only, a list makes more sense. > > Okay. --blu "You've added a new disk. Do you want to replace your current drive,protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1V-0002nD-Ct; Wed, 14 Nov 2007 08:11:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBF2-0002VI-T8 for dhcwg@ietf.org; Thu, 08 Nov 2007 12:32:32 -0500 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqBEz-0004x7-2d for dhcwg@ietf.org; Thu, 08 Nov 2007 12:32:32 -0500 Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA8HWRYJ029686; Thu, 8 Nov 2007 17:32:28 GMT Received: from [129.148.226.18] (sr1-unsh01-06.East.Sun.COM [129.148.226.18]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lA8HWQqi025655; Thu, 8 Nov 2007 12:32:27 -0500 (EST) Message-ID: <4733482A.7020302@sun.com> Date: Thu, 08 Nov 2007 12:32:26 -0500 From: Brian Utterback User-Agent: Thunderbird 2.0.0.7pre (X11/20071104) MIME-Version: 1.0 To: "Benoit Lourdelet (blourdel)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "Richard Gayraud \(rgayraud\)" Subject: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I think that you should eliminate the minpoll, maxpoll, I and B fields, which would mean you could eliminate the reserved field, although you might want to keep it. As a policy request, maxpoll is useless. How can you specify the maximum poll interval? That just doesn't make sense. The minpoll parameter make some sense, but since you are depending on the client implementation to obey it, it seems likely that any such implementation will either get minpoll right or not. If it gets it right, then the minpoll parameter is not needed, and if it gets it wrong then it probably won't be obeyed anyway. I just don't see the point in having the I field since that is pretty much a client side kind of issue. The use of the B field might be useful in some weird circumstances, but I don't see this as something that the server could know. The multicast looks okay as is, although I would suggest that there be advice to leave delay as 0 if possible. The proper delay doesn't seem to me to be likely to be known by the server and possibly different across a subnet. I am not sure about the idea of allowing multiple instances. Is that normal for DHCP? I understand the need to have multiple addresses returned, I would have thought a single list would have made more sense, but that is a DHCP thing, not a NTP thing, so I leave that to the DHCP experts. Benoit Lourdelet (blourdel) wrote: > Hello, > > We have just submitted a new draft proposing an NTP option for DHCPv6. > > The goal of this draft is to standardize automatic configuration of > NTPv4 (IPv6) clients over DHCPv6. > We think there is currently no satisfactory solution for configuring > NTPv4 clients from a centralized DHCPv6 server. > > We'd be very happy to hear feedback about the draft, and I'm planning to > ask that it becomes a WG draft eventually. > > Here's a url: > > > http://www.ietf.org/internet-drafts/draft-gayraud-dhcpv6-ntp-opt-00.txt > > > Thanks, > > Richard and Benoit > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1c-000377-5Y; Wed, 14 Nov 2007 08:11:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ir4WU-00014k-LU for dhcwg@ietf.org; Sat, 10 Nov 2007 23:34:14 -0500 Received: from whimsy.udel.edu ([128.4.2.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ir4WR-00077M-43 for dhcwg@ietf.org; Sat, 10 Nov 2007 23:34:14 -0500 Received: by whimsy.udel.edu (Postfix, from userid 62) id 8C34B1694; Sun, 11 Nov 2007 04:34:09 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id EE7621629; Sun, 11 Nov 2007 04:34:03 +0000 (UTC) Message-ID: <47368636.3070007@udel.edu> Date: Sun, 11 Nov 2007 04:33:58 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Brian Utterback References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> In-Reply-To: <4735A243.6090905@sun.com> X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "Richard Gayraud \(rgayraud\)" Subject: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Brian, We need to think about scenarios for server discovery. Without prejudice on the message formats, a virgin client might be directed to either: 1. Listen for broadcast/multicast on
and do/do not execute a volley. I like the delay field to enable/disable that and have added it to ntpd. In principle, the delay can be determined from the DHCP packets themselves, a feature that might be added. 2. Troll the pool at one of the pool DNS names, us.pool.ntp.org, etc. The client should be smart enough to use/not use iburst and preempt flags. 3. Specify a list of to send to, each together with the mode and minpoll. I don't think maxpoll is useful either. 4. Specify a manycast server group address, ttl limit and beacon interval. In the broadcast/multicast, pool and manycast schemes, we need the optional tos floor and tos ceiling and tos cohort commands as well. All schemes may need the key ID or Autokey flag. All this makes me nervous. A possible alternative is simply to send a configuration file like the ntpq program can now. However, this of course is implemention specific. It might be useful to provide the name of a local configuration file only. The most important thing is to make it flexible for use by current ntpd and possibly others. Dave 2.Brian Utterback wrote: > Benoit Lourdelet (blourdel) wrote: > >> Hello, >> >> A possible usage of all the NTP parameters specified in the new options >> is to configure router gateway . In that scenario, the goal of a Service >> Provider or an Enterprise IT is to autoconfigure the gateway as much as >> possible, including some NTP client behavior, in order to keep the >> control. An additional benefit is that the gateway can be shipped to >> remote sites virtually without any configuration while keeping full >> control of the NTP behavior. > > I'm sorry, but I still don't see it. Are you saying that the router > is a DHCP client and gets the server from DHCP? Okay fine, > but how does minpoll, maxpoll, I and B get used? I still > don't see the point of maxpoll here at all, that is, I don't even > get what it means to the client to get this value imposed. > See, minpoll says "do not poll more often than this", > but maxpoll would mean "do not poll less often than this". > This just doesn't make sense to me. > >> Following that line of thought, I may still see a need for "minpoll, >> maxpoll, I and B fields". >> > > Now, I could see the I and B meaning "do not do this" rather than "do > this". If I and B are 0, then > it means to do whatever you want, but if they are 1, then do not do it. > It doesn't > make sense to tell a client to use iburst when it wasn't going to > anyway. Same with burts, although > in a strange set of ceircumstances I could imagine the need for burst > being known centrally, > so maybe the B flag makes some kind of sense as is. > >> Considering a central DHCP server, the use of remote-id [RFC4649] or >> just link-id may tell the server from where >> the request is coming then giving it the knowledge of the delay to >> apply. >> In the case of a DHCP server hosted by the first hop, the DHCP server is >> well positioned to know the delay. >> >> > > Oh, agreed, it is possible for the delay to be known. But I just don't > think it is likely > that it will ever be used correctly in that scenario. All I said is that > it should generally > be left at 0 unless there is a good reason not to. > >> Considering the current option format which includes more than IP >> addresses, the choice of multiple occurrences of the >> same option looks sensible. Should we reduce the new options to IPv6 >> addresses only, a list makes more sense. >> >> > > Okay. > > --blu > > "You've added a new disk. Do you want to replace > your current drive,protect your data from a drive failure > or expand your storage capacity?" > - Disk management as it should be. > ---------------------------------------------------------------------- > Brian Utterback - Solaris RPE, Sun Microsystems, Inc. > > Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom > > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1T-0002jr-OJ; Wed, 14 Nov 2007 08:11:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IriTq-0002oF-Tx; Mon, 12 Nov 2007 18:14:10 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IriTn-00020q-34; Mon, 12 Nov 2007 18:14:10 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 925AA65ED98; Mon, 12 Nov 2007 15:14:06 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15436-10; Mon, 12 Nov 2007 15:14:06 -0800 (PST) Received: from PARBETM2XP2 (unknown [172.31.253.88]) by prattle.redback.com (Postfix) with ESMTP id E7FD965ED96; Mon, 12 Nov 2007 15:14:05 -0800 (PST) From: "Peter Arberg" To: "'Alper Yegin'" , "'Eric Voit (evoit)'" , "'Ralph Droms (rdroms)'" Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WGrecharteringforDHCPauthentication Date: Mon, 12 Nov 2007 15:13:59 -0800 Organization: Redback Networks Inc. Message-ID: <014c01c82581$b51e9b70$ba3dfea9@ad.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcghNqSRIMtejNA6QuqLIl2FWroppAABZxPwAQ/JkXAAAXPf0A== In-Reply-To: <0MKp8S-1Irhqj0XRR-0005zk@mrelay.perfora.net> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:03 -0500 Cc: dhcwg@ietf.org, 'Internet Area' X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I do not think you and Bill were talking about the same issues in the email. It is clear that any solution which requires a temporary ip-address will create more turn on a BRAS, and the subscriber setup rate will very likely go down compared to a solution which will finish authentication before ip-address allocation. Peter > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: 12. november 2007 14:34 > To: 'Eric Voit (evoit)'; 'Ralph Droms (rdroms)' > Cc: dhcwg@ietf.org; 'Internet Area' > Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc > WGrecharteringforDHCPauthentication > > > Doubling the load on the DHCP servers probably will not > change the game. > > > > The extra load on the L3 Edge/BRAS could easily change the game (and > > hence the emails from Peter (Redback) & Bill (Juniper)). > > Hmmm... I followed up this feedback with Bill Welch in more technical > detail, and if you remember it ended with a "And yes your > observation is > correct, the DHCP auth solution with EAP has the same issues." > > http://www1.ietf.org/mail-archive/web/int-area/current/msg01129.html > > Alper > > > > > > The extra complexity with the CPE has always been my > biggest concern, > > and is why I entered the thread many weeks ago. > > > > Eric > > > > > > > From: Ralph Droms, November 07, 2007 7:06 AM > > > > > > Eric - I was mostly responding to Ric's description of the > > > excessive load on DHCP servers in the short-lease/long-lease > > > scenario. As I understand the short-lease/long-lease > > > scenario, if we assume that authentication takes place in the > > > short-lease window, the load on the DHCP servers would > > > double. Significant, sure, but not game-changing in the way > > > Ric implied. > > > > > > - Ralph > > > > > > On Nov 6, 2007, at Nov 6, 2007,10:39 PM, Eric Voit (evoit) wrote: > > > > > > >> From: Ralph Droms, November 05, 2007 9:37 PM > > > >> > > > >> Does the short lease/long lease scenario scale the DHCP > > > server load > > > >> by more than a factor of two? > > > > > > > > Ralph, > > > > > > > > The messages the DHCP servers will double. > > > > The messages with L3 edge (BRAS) will more than double. > > > > The messages with the CPE will more than triple. > > > > > > > > (Below is some rough math. I might have missed a message or > > > two, but > > > > the general trend is what I am trying to show.) > > > > > > > > ----------------------------------------- > > > > CPE Messages > > > > ----------------------------------------- > > > > DHCP Auth, assuming a 2 message EAP Method, the messages > > > used by EAP > > > > would be equal > > > > + 6 Messages (draft-pruss-dhcp-auth-dsl-01) > > > > > > > > PANA+DHCP Method > > > > + 4 Messages: DHCP 1st IP address > > > > ~ (+2) DHCP renews per 60 seconds until authenticated > > > > + 11 Messages PANA with BRAS (draft-ietf-pana-pana-18, > section 4.1) > > > > + 4 Messages: DHCP 2nd IP address > > > > > > > > ----------------------------------------- > > > > L3 Edge (BRAS) Messages > > > > ----------------------------------------- > > > > DHCP Auth, EAP Method > > > > + 8 Messages (draft-pruss-dhcp-auth-dsl-01) > > > > > > > > PANA Method > > > > + 4 Messages: DHCP 1st IP address > > > > ~ (+2) DHCP renews per 60 seconds until authenticated > > > > + 11 Messages PANA with CPE (draft-ietf-pana-pana-18, > section 4.1) > > > > + 2 messages min for validating with EAP Server > > > > + 4 Messages: DHCP 2nd IP address > > > > > > > > ----------------------------------------- > > > > L2 Edge (DSLAM or Access Switch) Messages > > > > ----------------------------------------- > > > > DHCP Auth, EAP Method > > > > + 6 Messages snooped (draft-pruss-dhcp-auth-dsl-01) > > > > > > > > PANA+DHCP Method > > > > + 4 Messages Snooped: DHCP 1st IP address > > > > ~ (+2) DHCP renews per 60 seconds until authenticated If > > > snooping: 11 > > > > Messages PANA (draft-ietf-pana-pana-18, section 4.1) Else > > > if explicit > > > > policy distribution like ANCP, ~4 messages (one policy > per address) > > > > + 4 Messages Snooped: DHCP 2nd IP address > > > > > > > > > > > > Eric > > > > > > > > > > > >> - Ralph > > > >> > > > > > > > > > _______________________________________________ > > > Int-area mailing list > > > Int-area@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/int-area > > > > > > > > > _______________________________________________ > > Int-area mailing list > > Int-area@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/int-area > > > > _______________________________________________ > Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1c-00039s-Pk; Wed, 14 Nov 2007 08:11:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrC4o-0005PT-4W for dhcwg@ietf.org; Sun, 11 Nov 2007 07:38:10 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrC4j-0001Bm-Cc for dhcwg@ietf.org; Sun, 11 Nov 2007 07:38:10 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lABCc4Rc010703 for ; Sun, 11 Nov 2007 12:38:04 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRC00M01DNH3300@mail-amer.sun.com> (original mail from Brian.Utterback@Sun.COM) for dhcwg@ietf.org; Sun, 11 Nov 2007 05:38:04 -0700 (MST) Received: from [192.168.1.5] ([71.168.64.220]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRC00I31DRBM1E0@mail-amer.sun.com>; Sun, 11 Nov 2007 05:38:04 -0700 (MST) Date: Sun, 11 Nov 2007 07:37:59 -0500 From: Brian Utterback In-reply-to: <47368636.3070007@udel.edu> To: "David L. Mills" Message-id: <4736F7A7.2090707@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> <47368636.3070007@udel.edu> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-Spam-Score: -1.0 (-) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "Richard Gayraud \(rgayraud\)" Subject: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org David L. Mills wrote: > > 1. Listen for broadcast/multicast on
and do/do not execute a > volley. I like the delay field to enable/disable that and have added > it to ntpd. In principle, the delay can be determined from the DHCP > packets themselves, a feature that might be added. > Right, I am fine with having the delay given and novolley specified. You can't determine the delay from the DHCP packets because the DHCP server is likely not the NTP server. The DHCP server may be multiple hops away. > 2. Troll the pool at one of the pool DNS names, us.pool.ntp.org, etc. > The client should be smart enough to use/not use iburst and preempt > flags. This argues for having another possible field/format, where a string for lookup is given. > > 3. Specify a list of to send to, each together with the > mode and minpoll. I don't think maxpoll is useful either. What other mode than active client do you envision? > > 4. Specify a manycast server group address, ttl limit and beacon > interval. Okay. > > In the broadcast/multicast, pool and manycast schemes, we need the > optional tos floor and tos ceiling and tos cohort commands as well. > All schemes may need the key ID or Autokey flag. Interesting. I agree that a key needs to be specified somehow, but it is not clear to me how to do it. We have to assume that the client does not have the same NTP keys. However, we would like a way to specify a server and keys securely, so that the security of the network depends only on the security of DHCP. Again I am not up to date, *is* there a secure DHCP? If so, then how to get keys to the clients becomes an issue. > > All this makes me nervous. A possible alternative is simply to send a > configuration file like the ntpq program can now. However, this of > course is implemention specific. It might be useful to provide the > name of a local configuration file only. The most important thing is > to make it flexible for use by current ntpd and possibly others. > It seems (as you said) that a general purpose configuration mechanism is needed. One that is implementation neutral. We have talked in the past about config over LDAP and HTTP. Maybe we need to revist that. It would not have to be built into ntpd, though, it could easily live as a separate process. Brian > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1d-0003Cf-Qu; Wed, 14 Nov 2007 08:11:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrGGz-0001gB-Fn for dhcwg@ietf.org; Sun, 11 Nov 2007 12:07:01 -0500 Received: from whimsy.udel.edu ([128.4.2.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrGGy-0008Bw-CB for dhcwg@ietf.org; Sun, 11 Nov 2007 12:07:01 -0500 Received: by whimsy.udel.edu (Postfix, from userid 62) id 1278D1684; Sun, 11 Nov 2007 17:06:57 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id 7A67D165A; Sun, 11 Nov 2007 17:06:52 +0000 (UTC) Message-ID: <473736A7.5000801@udel.edu> Date: Sun, 11 Nov 2007 17:06:47 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> <47368636.3070007@udel.edu> <4736F7A7.2090707@sun.com> In-Reply-To: <4736F7A7.2090707@sun.com> X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org Subject: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Brian, My model about the keys is that the DHCP server would supply a key ID for the NTP server(s) as configured, but not the keys themselves. The keys would have to be configured for the NTP server and client separately. The DHCP server would be responsible only for the opaque key ID. There is an issue about the security of the DFCP server itself; that is another issue. I'm assuming the DHCP server is behind the firewall. The mode specification could be any of the valid NTP modes. If client (3) it would be an ordinary client/server association. A means would be necessary to specify broadcast client, as that is not a mode in the strict sense. It could be symmetric active (1), in which case the victim would initiate that type association. To specify symmetric passive (2) means that the victim should wait for a symmetric active (1) packet. This does not seem useful. Dave Brian Utterback wrote: > David L. Mills wrote: > >> >> 1. Listen for broadcast/multicast on
and do/do not execute >> a volley. I like the delay field to enable/disable that and have >> added it to ntpd. In principle, the delay can be determined from the >> DHCP packets themselves, a feature that might be added. >> > Right, I am fine with having the delay given and novolley specified. > You can't determine the delay from the DHCP > packets because the DHCP server is likely not the NTP server. The DHCP > server may be multiple hops away. > >> 2. Troll the pool at one of the pool DNS names, us.pool.ntp.org, etc. >> The client should be smart enough to use/not use iburst and preempt >> flags. > > > This argues for having another possible field/format, where a string > for lookup is given. > >> >> 3. Specify a list of to send to, each together with the >> mode and minpoll. I don't think maxpoll is useful either. > > > What other mode than active client do you envision? > >> >> 4. Specify a manycast server group address, ttl limit and beacon >> interval. > > > Okay. > >> >> In the broadcast/multicast, pool and manycast schemes, we need the >> optional tos floor and tos ceiling and tos cohort commands as well. >> All schemes may need the key ID or Autokey flag. > > > Interesting. I agree that a key needs to be specified somehow, but it > is not clear > to me how to do it. We have to assume that the client does not have > the same NTP > keys. However, we would like a way to specify a server and keys > securely, so that > the security of the network depends only on the security of DHCP. > Again I am not > up to date, *is* there a secure DHCP? If so, then how to get keys to > the clients > becomes an issue. > > >> >> All this makes me nervous. A possible alternative is simply to send a >> configuration file like the ntpq program can now. However, this of >> course is implemention specific. It might be useful to provide the >> name of a local configuration file only. The most important thing is >> to make it flexible for use by current ntpd and possibly others. >> > It seems (as you said) that a general purpose configuration mechanism > is needed. One that > is implementation neutral. We have talked in the past about config > over LDAP and HTTP. > Maybe we need to revist that. It would not have to be built into ntpd, > though, it could easily > live as a separate process. > > Brian > >> > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1e-0003Fe-Bf; Wed, 14 Nov 2007 08:11:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrHui-0003VD-7R for dhcwg@ietf.org; Sun, 11 Nov 2007 13:52:08 -0500 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrHuh-0004Zc-Jw for dhcwg@ietf.org; Sun, 11 Nov 2007 13:52:08 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Wj230CZAnkuMxBjjkJjtb6ifReLnu9KSO0RWWE4/oqxxVguK4Tc6fsuMU/m5Plof; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IrHug-0005rw-L9; Sun, 11 Nov 2007 13:52:06 -0500 Message-ID: <005a01c82494$17d194f0$6401a8c0@tsg1> From: "TS Glassey" To: "David L. Mills" References: <4733482A.7020302@sun.com><4735A243.6090905@sun.com> <47368636.3070007@udel.edu><4736F7A7.2090707@sun.com> <473736A7.5000801@udel.edu> Date: Sun, 11 Nov 2007 10:52:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79d8fb97eb214c03c0c1687fd845a8690b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org Subject: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Dave I can understand the ISC's goal in using DHCP but how does this work for the users? DHCP also has problems with being constrained to the same subnet unless provisions are made for its propagation... maning that without special provisions for propagating DHCP across a local subnet this may not be of any use at all. Especially since today its VERY rare to find anyone who wants to route DHCP through their network, so maybe the IETF's new NEA protocol could be a solution for this??? Todd ----- Original Message ----- From: "David L. Mills" Cc: ; Sent: Sunday, November 11, 2007 9:06 AM Subject: Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 > Brian, > > My model about the keys is that the DHCP server would supply a key ID > for the NTP server(s) as configured, but not the keys themselves. The > keys would have to be configured for the NTP server and client > separately. The DHCP server would be responsible only for the opaque key > ID. > > There is an issue about the security of the DFCP server itself; that is > another issue. I'm assuming the DHCP server is behind the firewall. > > The mode specification could be any of the valid NTP modes. If client > (3) it would be an ordinary client/server association. A means would be > necessary to specify broadcast client, as that is not a mode in the > strict sense. It could be symmetric active (1), in which case the victim > would initiate that type association. To specify symmetric passive (2) > means that the victim should wait for a symmetric active (1) packet. > This does not seem useful. > > Dave > > Brian Utterback wrote: > >> David L. Mills wrote: >> >>> >>> 1. Listen for broadcast/multicast on
and do/do not execute >>> a volley. I like the delay field to enable/disable that and have >>> added it to ntpd. In principle, the delay can be determined from the >>> DHCP packets themselves, a feature that might be added. >>> >> Right, I am fine with having the delay given and novolley specified. >> You can't determine the delay from the DHCP >> packets because the DHCP server is likely not the NTP server. The DHCP >> server may be multiple hops away. >> >>> 2. Troll the pool at one of the pool DNS names, us.pool.ntp.org, etc. >>> The client should be smart enough to use/not use iburst and preempt >>> flags. >> >> >> This argues for having another possible field/format, where a string >> for lookup is given. >> >>> >>> 3. Specify a list of to send to, each together with the >>> mode and minpoll. I don't think maxpoll is useful either. >> >> >> What other mode than active client do you envision? >> >>> >>> 4. Specify a manycast server group address, ttl limit and beacon >>> interval. >> >> >> Okay. >> >>> >>> In the broadcast/multicast, pool and manycast schemes, we need the >>> optional tos floor and tos ceiling and tos cohort commands as well. >>> All schemes may need the key ID or Autokey flag. >> >> >> Interesting. I agree that a key needs to be specified somehow, but it >> is not clear >> to me how to do it. We have to assume that the client does not have >> the same NTP >> keys. However, we would like a way to specify a server and keys >> securely, so that >> the security of the network depends only on the security of DHCP. >> Again I am not >> up to date, *is* there a secure DHCP? If so, then how to get keys to >> the clients >> becomes an issue. >> >> >>> >>> All this makes me nervous. A possible alternative is simply to send a >>> configuration file like the ntpq program can now. However, this of >>> course is implemention specific. It might be useful to provide the >>> name of a local configuration file only. The most important thing is >>> to make it flexible for use by current ntpd and possibly others. >>> >> It seems (as you said) that a general purpose configuration mechanism >> is needed. One that >> is implementation neutral. We have talked in the past about config >> over LDAP and HTTP. >> Maybe we need to revist that. It would not have to be built into ntpd, >> though, it could easily >> live as a separate process. >> >> Brian >> >>> >> > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1e-0003HR-VB; Wed, 14 Nov 2007 08:11:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrbdW-00005K-Va for dhcwg@ietf.org; Mon, 12 Nov 2007 10:55:42 -0500 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrbdT-0000Nw-HQ for dhcwg@ietf.org; Mon, 12 Nov 2007 10:55:42 -0500 Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lACFtc0O003826; Mon, 12 Nov 2007 15:55:38 GMT Received: from [129.148.226.18] (sr1-unsh01-06.East.Sun.COM [129.148.226.18]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lACFtbrt014841; Mon, 12 Nov 2007 10:55:37 -0500 (EST) Message-ID: <47387778.4030702@sun.com> Date: Mon, 12 Nov 2007 10:55:36 -0500 From: Brian Utterback User-Agent: Thunderbird 2.0.0.7pre (X11/20071110) MIME-Version: 1.0 To: "David L. Mills" References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> <47368636.3070007@udel.edu> <4736F7A7.2090707@sun.com> <473736A7.5000801@udel.edu> In-Reply-To: <473736A7.5000801@udel.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org Subject: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org David L. Mills wrote: > Brian, > > My model about the keys is that the DHCP server would supply a key ID > for the NTP server(s) as configured, but not the keys themselves. The > keys would have to be configured for the NTP server and client > separately. The DHCP server would be responsible only for the opaque key ID. > I see what you mean, but I am not sure about the use case here. Certainly if the keys are pre-configured on both the clients and the servers, then the key id is a must. But I am concerned about the roaming laptop mode here. If I bring my laptop to a network, I would like to be able to get enough info from the DHCP server to allow me to securely connect to the server and have it be authenticated. Perhaps a public key distribution scheme? > There is an issue about the security of the DFCP server itself; that is > another issue. I'm assuming the DHCP server is behind the firewall. Right. Out of the realm of our discussion. > > The mode specification could be any of the valid NTP modes. If client > (3) it would be an ordinary client/server association. A means would be > necessary to specify broadcast client, as that is not a mode in the > strict sense. It could be symmetric active (1), in which case the victim > would initiate that type association. To specify symmetric passive (2) > means that the victim should wait for a symmetric active (1) packet. > This does not seem useful. If you get a broadcast address to use then you should be a broadcast client. I don't see the usefulness of a DHCP client being a symmetric anything. Perhaps this is a failure of imagination on my part. -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1f-0003KU-Jp; Wed, 14 Nov 2007 08:11:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrmWy-0000jZ-Q1 for dhcwg@ietf.org; Mon, 12 Nov 2007 22:33:40 -0500 Received: from whimsy.udel.edu ([128.4.2.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrmWy-0008Iy-1C for dhcwg@ietf.org; Mon, 12 Nov 2007 22:33:40 -0500 Received: by whimsy.udel.edu (Postfix, from userid 62) id E5E101689; Tue, 13 Nov 2007 03:33:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id 49EC0149A; Tue, 13 Nov 2007 03:33:31 +0000 (UTC) Message-ID: <47391B04.8080202@udel.edu> Date: Tue, 13 Nov 2007 03:33:24 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: ntpwg@lists.ntp.org, dhcwg@ietf.org References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> <47368636.3070007@udel.edu> <4736F7A7.2090707@sun.com> <473736A7.5000801@udel.edu> <47387778.4030702@sun.com> In-Reply-To: <47387778.4030702@sun.com> X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: Subject: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Brian, Roaming laptops is what NTP Autokey is designed for. All a properly configued laptop would not need anything except a flag that says to use it and possibly the public group key. Heck with NTP; use Autokey to authenticate the server for anything. Dave Brian Utterback wrote: > > > David L. Mills wrote: > >> Brian, >> >> My model about the keys is that the DHCP server would supply a key ID >> for the NTP server(s) as configured, but not the keys themselves. The >> keys would have to be configured for the NTP server and client >> separately. The DHCP server would be responsible only for the opaque >> key ID. >> > > I see what you mean, but I am not sure about the use case here. > Certainly if the keys are pre-configured on both the clients and the > servers, then the key id is a must. But I am concerned about the > roaming laptop mode here. If I bring my laptop to a network, I would > like to be able to get enough info from the DHCP server to allow me > to securely connect to the server and have it be authenticated. Perhaps > a public key distribution scheme? > >> There is an issue about the security of the DFCP server itself; that >> is another issue. I'm assuming the DHCP server is behind the firewall. > > > Right. Out of the realm of our discussion. > >> >> The mode specification could be any of the valid NTP modes. If client >> (3) it would be an ordinary client/server association. A means would >> be necessary to specify broadcast client, as that is not a mode in >> the strict sense. It could be symmetric active (1), in which case the >> victim would initiate that type association. To specify symmetric >> passive (2) means that the victim should wait for a symmetric active >> (1) packet. This does not seem useful. > > > If you get a broadcast address to use then you should be a broadcast > client. I don't see the usefulness of a DHCP client being a symmetric > anything. Perhaps this is a failure of imagination on my part. > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1g-0003MY-4t; Wed, 14 Nov 2007 08:11:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is3wR-0001vv-97 for dhcwg@ietf.org; Tue, 13 Nov 2007 17:09:07 -0500 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is3wQ-0001bT-IU for dhcwg@ietf.org; Tue, 13 Nov 2007 17:09:07 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=t/a7fJL5XIKgu8A5gBChOJyUbTrAZ3IFbf7oJDgnvV7W1aGUDMx2y+3/up9oGFc5; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Is3wN-0006Iz-K7; Tue, 13 Nov 2007 17:09:03 -0500 Message-ID: <006801c82641$cd256990$6401a8c0@tsg1> From: "TS Glassey" To: "David L. Mills" , , References: <4733482A.7020302@sun.com><4735A243.6090905@sun.com> <47368636.3070007@udel.edu><4736F7A7.2090707@sun.com> <473736A7.5000801@udel.edu><47387778.4030702@sun.com> <47391B04.8080202@udel.edu> Date: Tue, 13 Nov 2007 09:15:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7931ae74108ea98562e6d420c3cd8f9e42350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 1.4 (+) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: Subject: [dhcwg] Digital Evidence Standards and a statement that this directly effects NTP and its use... X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Dave - There is ANOTHER issue facing this WG and that is that just like the "description's" of the NTP Process the AutoKEY system needs to be accountable to a standard which allows data captured from such a source to be admitted in a court of law and now that there are formal standards many of the cool methods of delivering time over networks from a physics perspective dont mean squat now to the Courts. The case that set this standard was called Lorraine v Markel CIVIL ACTION NO. PWG-06-1893 and it came out of the US District Court in Maryland on May 4th 2007 from a Judge (a Chief Magistrate Judge) by the name of Paul Grimm. Google the actual ruling here: http://www.google.com/search?q=lorraine+v+markel&rls=com.microsoft:en-us:IE-SearchBox&ie=UTF-8&oe=UTF-8&sourceid=ie7&rlz=1I7GGLF Bluntly, the world changed a tad on May 4th and while this effort is pointed at the physics of operating NTP, these new controls impact any work with any other Standardized Protocol as well... What this means to people who NTP is a part of their commercial offering, is that they MUST apply these new standards to this code and its support as well, or they must use their own internal code-base's rather than depending on one here. I think this ruling re-set the bar heighth, and it is now much higher - even for an Academic Entity. As to how this effects this WG, we need to build tools that are capable of being used in these key application contexts or this protocol will likely be ultimately replaced. Just my two cents, Todd Glassey ----- Original Message ----- From: "David L. Mills" To: ; Sent: Monday, November 12, 2007 7:33 PM Subject: Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 > Brian, > > Roaming laptops is what NTP Autokey is designed for. All a properly > configued laptop would not need anything except a flag that says to use > it and possibly the public group key. Heck with NTP; use Autokey to > authenticate the server for anything. > > Dave > > Brian Utterback wrote: > >> >> >> David L. Mills wrote: >> >>> Brian, >>> >>> My model about the keys is that the DHCP server would supply a key ID >>> for the NTP server(s) as configured, but not the keys themselves. The >>> keys would have to be configured for the NTP server and client >>> separately. The DHCP server would be responsible only for the opaque >>> key ID. >>> >> >> I see what you mean, but I am not sure about the use case here. >> Certainly if the keys are pre-configured on both the clients and the >> servers, then the key id is a must. But I am concerned about the >> roaming laptop mode here. If I bring my laptop to a network, I would >> like to be able to get enough info from the DHCP server to allow me >> to securely connect to the server and have it be authenticated. Perhaps >> a public key distribution scheme? >> >>> There is an issue about the security of the DFCP server itself; that >>> is another issue. I'm assuming the DHCP server is behind the firewall. >> >> >> Right. Out of the realm of our discussion. >> >>> >>> The mode specification could be any of the valid NTP modes. If client >>> (3) it would be an ordinary client/server association. A means would >>> be necessary to specify broadcast client, as that is not a mode in >>> the strict sense. It could be symmetric active (1), in which case the >>> victim would initiate that type association. To specify symmetric >>> passive (2) means that the victim should wait for a symmetric active >>> (1) packet. This does not seem useful. >> >> >> If you get a broadcast address to use then you should be a broadcast >> client. I don't see the usefulness of a DHCP client being a symmetric >> anything. Perhaps this is a failure of imagination on my part. >> >> > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1U-0002kQ-0G; Wed, 14 Nov 2007 08:11:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipbkk-0003R6-IN; Tue, 06 Nov 2007 22:38:54 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipbkh-0005hD-3x; Tue, 06 Nov 2007 22:38:54 -0500 X-IronPort-AV: E=Sophos;i="4.21,381,1188802800"; d="scan'208";a="247703120" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2007 19:38:50 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA73co3I024010; Tue, 6 Nov 2007 19:38:50 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA73cnfb002375; Wed, 7 Nov 2007 03:38:50 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 22:38:49 -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 Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering for DHCPauthentication Date: Tue, 6 Nov 2007 22:39:43 -0500 Message-ID: In-Reply-To: <8D9309C4-247F-4751-BFDC-00CCEB9367E7@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering for DHCPauthentication Thread-Index: AcggHm+KfPGdwHk5Th6TDrp6Vvyw4QAzsuSA References: <0MKpCa-1Ip7Tp4AID-0008VV@mrelay.perfora.net><472FC860.6000104@cisco.com> <8D9309C4-247F-4751-BFDC-00CCEB9367E7@cisco.com> From: "Eric Voit (evoit)" To: "Ralph Droms (rdroms)" X-OriginalArrivalTime: 07 Nov 2007 03:38:49.0671 (UTC) FILETIME=[B5A34D70:01C820EF] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15528.002 X-TM-AS-Result: No--12.075000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1901; t=1194406730; x=1195270730; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=evoit@cisco.com; z=From:=20=22Eric=20Voit=20(evoit)=22=20 |Subject:=20RE=3A=20[Int-area]=20Re=3A=20[dhcwg]=20Discussion=20of=20dhc= 20WG=20rechartering=20for=20DHCPauthentication |Sender:=20; bh=UXo/pOe7KXW9rrXIkwWlWYdImtHRaSlfULcIxstpMms=; b=JqmJwgHyvlZLkdJ2x3GEhn1cJcma3FBXMS1VcRueq1K/CS/NvpUzVdAhHnC2lt24KgDGwUWr PAdCIWCU+2/tEsUpcUwDeZOm+qVu6mP2rS7e40CNsKePuigHlP9hw1ImikoovPU6JukHoqbfWC 0RRTdm114GqMO6Gusf5XN1huQ=; Authentication-Results: sj-dkim-1; header.From=evoit@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: dhcwg@ietf.org, Internet Area X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > From: Ralph Droms, November 05, 2007 9:37 PM >=20 > Does the short lease/long lease scenario scale the DHCP=20 > server load by more than a factor of two? Ralph, The messages the DHCP servers will double. =20 The messages with L3 edge (BRAS) will more than double. =20 The messages with the CPE will more than triple. =20 (Below is some rough math. I might have missed a message or two, but the general trend is what I am trying to show.) ----------------------------------------- CPE Messages ----------------------------------------- DHCP Auth, assuming a 2 message EAP Method, the messages used by EAP would be equal + 6 Messages (draft-pruss-dhcp-auth-dsl-01) PANA+DHCP Method + 4 Messages: DHCP 1st IP address ~ (+2) DHCP renews per 60 seconds until authenticated + 11 Messages PANA with BRAS (draft-ietf-pana-pana-18, section 4.1) + 4 Messages: DHCP 2nd IP address ----------------------------------------- L3 Edge (BRAS) Messages ----------------------------------------- DHCP Auth, EAP Method + 8 Messages (draft-pruss-dhcp-auth-dsl-01) PANA Method + 4 Messages: DHCP 1st IP address ~ (+2) DHCP renews per 60 seconds until authenticated + 11 Messages PANA with CPE (draft-ietf-pana-pana-18, section 4.1) + 2 messages min for validating with EAP Server + 4 Messages: DHCP 2nd IP address ----------------------------------------- L2 Edge (DSLAM or Access Switch) Messages ----------------------------------------- DHCP Auth, EAP Method + 6 Messages snooped (draft-pruss-dhcp-auth-dsl-01) PANA+DHCP Method + 4 Messages Snooped: DHCP 1st IP address ~ (+2) DHCP renews per 60 seconds until authenticated If snooping: 11 Messages PANA (draft-ietf-pana-pana-18, section 4.1) Else if explicit policy distribution like ANCP, ~4 messages (one policy per address) + 4 Messages Snooped: DHCP 2nd IP address Eric =20 > - Ralph >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1S-0002jm-Vb; Wed, 14 Nov 2007 08:11:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io3Dt-0004Di-Rr for dhcwg@ietf.org; Fri, 02 Nov 2007 16:34:33 -0400 Received: from mo-p07-ob.rzone.de ([81.169.146.188]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Io3Dq-0006BS-97 for dhcwg@ietf.org; Fri, 02 Nov 2007 16:34:30 -0400 Received: from [192.168.2.21] (i577B4EF3.versanet.de [87.123.78.243]) by post.webmailer.de (klopstock mo17) (RZmta 14.0) with ESMTP id w03908jA2IWepV for ; Fri, 2 Nov 2007 21:34:26 +0100 (MET) (envelope-from: ) Message-ID: <472B8C0B.9020201@perlich.info> Date: Fri, 02 Nov 2007 21:43:55 +0100 From: Karsten Perlich User-Agent: Thunderbird 2.0.0.6 (X11/20070801) MIME-Version: 1.0 To: dhcwg@ietf.org X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RZG-AUTH: iaLm2Pt7DKx7lM0nYtbFIubn3F54eTCfrDEp3QGY7lox1YSj2vlxs+0lx9+a94Zo+4wrhg== X-RZG-CLASS-ID: mo07 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:03 -0500 Subject: [dhcwg] ONE DHCP-Server for different pfysical and logical networks X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: karsten@perlich.info List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi, I set up a Linux-router using OpenSuSE 10.3. This router connects the three networks with the companies network. Here are the facts: - - Each network is powered by an own networkcard. - - Each network is using its own logical IP-Pool. My wishes: - - All this should be done by one dhcp-server on the router/server. The probs: - - The subnets cannot be build using MAC-addresses, cause the laptops are used in different rooms, but the teams are worging in the same rooms. Is there any combination of options for the dhcpd.conf I can use to manage all this? Help needed!! Thanks Karsten _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 08:11:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1S-0002jF-LQ; Wed, 14 Nov 2007 08:11:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IncIG-0007JN-Ey for dhcwg@ietf.org; Thu, 01 Nov 2007 11:49:16 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IncIF-0004uz-B3 for dhcwg@ietf.org; Thu, 01 Nov 2007 11:49:16 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA1Fmjwu006623; Thu, 1 Nov 2007 17:49:10 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 17:48:32 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 10:48:31 -0500 Received: from 10.241.59.199 ([10.241.59.199]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 1 Nov 2007 15:48:31 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 01 Nov 2007 10:49:12 -0500 Subject: Re: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication From: Basavaraj Patil To: Message-ID: Thread-Topic: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication Thread-Index: Acgcnr9N/g/9c4iREdyP2QARJNUNiA== In-Reply-To: <4729F1BB.3060807@cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 01 Nov 2007 15:48:31.0289 (UTC) FILETIME=[A7098A90:01C81C9E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500 Cc: dhcwg@ietf.org, ext Ralph Droms X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0213510708==" Errors-To: dhcwg-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0213510708== Content-type: multipart/alternative; boundary="B_3276758953_59506264" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3276758953_59506264 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Ric, That=B9s not the point. I agree that we do authentication at several layers today. Access auth, SIP auth, etc. But what the I-D is proposing is basically extending DHCP to accomplish access auth. For access auth, there are several mechanisms today. Do we need DHCP to solve the access-auth problem as well? What is the primary reason/argument for doing access auth via DHCP? Is it a= n optimization or is it because there is no other way to solve the access aut= h problem in the domain that you are looking at? -Raj On 11/1/07 10:33 AM, "ext Richard Pruss" wrote: > Authentication is something that happens at every layer with every > application. Terminal access was designed without authentication, that do= es > not mean we do it like that today. >=20 > I do not think we can take the argument of it was not designed for x as = a > reason to stay in the past. >=20 > Regards, > Ric >=20 > Basavaraj Patil wrote, around 29/10/07 9:42 AM: >> =20 >> Ralph, >>=20 >> I think overloading DHCP for access authentication is a bad idea. DHCP w= as >> not designed for that purpose. I guess I need to communicate this on the >> int-area list. But anyway you know my opinion at least in the DHC WG. >>=20 >> -Basavaraj >>=20 >>=20 >> On 10/19/07 6:05 AM, "ext Ralph Droms" >> wrote: >>=20 >> =20 >> =20 >>> =20 >>> There is a lengthy discussion about rechartering the dhc WG to take >>> on the DHCP authentication proposals in draft-pruss-dhcp-auth- >>> dsl-01.txt and draft-zhao-dhc-user-authentication-02 in the int- >>> area@ietf.org mailing list. Both of these drafts have been submitted >>> for to the WG for review in the past, and neither, to date, has been >>> accepted as a dhc WG work iterm. I've included a copy of the initial >>> posting, http://www1.ietf.org/mail-archive/web/int-area/current/ >>> msg00957.html, below. Because this discussion may lead to the >>> rechartering of the dhc WG to take on either or both of these drafts >>> as new work items, those of you not on the int-area mailing list >>> should consider reviewing the e-mail thread and contributing to the >>> discussion. >>>=20 >>> - Ralph >>>=20 >>>=20 >>> =3D=3D=3D=3D=3D >>> To: Internet Area >>> Subject: [Int-area] DCHP-based authentication for DSL? >>> From: Jari Arkko >>> Date: Thu, 04 Oct 2007 23:22:15 +0300 >>>=20 >>>=20 >>> We talked about the DSL requirements earlier on this list. Now >>> they have sent us a liaison statement regarding what they would >>> like to do: >>>=20 >>> "At this time, we would like to make the IETF aware that during >>> our most recent DSL Forum quarterly meeting, the Architecture >>> and Transport Working Group agreed to seriously consider adopting >>> a mechanism such as that proposed in draft-pruss-dhcp-auth-dsl-01.txt >>> or draft-zhao-dhc-user-authentication-02. We understand that the author= s >>> of these specifications intend to produce a combined document soon. >>> The DSL Forum formally requests that the IETF adopt this as a work >>> item, and would appreciate being advised of progress as soon as >>> possible. >>>=20 >>> Our next quarterly meeting is December 10-13, in Lisbon, Portugal." >>>=20 >>>=20 >>> How do we feel about this? Is this a good idea, considering the DSL >>> architecture? How will it affect DHCP the protocol? How would >>> you go about making DHCP extensions so that they work best >>> for all possible environments and not just DSL? Is anyone >>> already working on the combined draft promised above? Are >>> there any other choices that we should recommend instead? >>>=20 >>> I would like to hold the discussion on this in this list until >>> we've determined that the DHCP protocol is the right tool >>> for the job. If it is, we can recharter DHC WG again to add >>> the actual development work there. (DHC is right now >>> being rechartered but that recharting is mostly a cleanup >>> and not the addition of functionality to do this.) >>>=20 >>> Jari >>>=20 >>>=20 >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dhcwg >>> =20 >>> =20 >> =20 >>=20 >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/dhcwg >>=20 >> =20 >=20 --B_3276758953_59506264 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [dhcwg] Discussion of dhc WG rechartering for DHCP authenticatio= n
Ric,

That’s not the point. I agree that we do authentication at several la= yers today. Access auth, SIP auth, etc.
But what the I-D is proposing is basically extending DHCP to accomplish acc= ess auth.
For access auth, there are several mechanisms today. Do we need DHCP to sol= ve the access-auth problem as well?

What is the primary reason/argument for doing access auth via DHCP? Is it a= n optimization or is it because there is no other way to solve the access au= th problem in the domain that you are looking at?

-Raj


On 11/1/07 10:33 AM, "ext Richard Pruss" <rpruss@cisco.com>= wrote:

Authentication is something that happens at every layer= with every application. Terminal access was designed without authentication= , that does not mean we do it like that today.

 I do not think we can take the argument of it was not designed for x = as a reason to stay in the past.

Regards,
Ric

Basavaraj Patil wrote, around 29/10/07 9:42 AM:

Ralph,

I think overloading DHCP for access authentication is a bad idea. DHCP was<= BR> not designed for that purpose. I guess I need to communicate this on the int-area list. But anyway you know my opinion at least in the DHC WG.

-Basavaraj


On 10/19/07 6:05 AM, "ext Ralph Droms" <rdroms@cisco.com> <= a href=3D"mailto:rdroms@cisco.com"><mailto:rdroms@cisco.com>  w= rote:

  
 

There is a lengthy discussion about rechartering the dhc WG to take
on the DHCP authentication proposals in draft-pruss-dhcp-auth-
dsl-01.txt and draft-zhao-dhc-user-authentication-02 in the int-
area@ietf.org mailing list.  Both of these drafts have been submitted<= BR> for to the WG for review in the past, and neither, to date, has been
accepted as a dhc WG work iterm.  I've included a copy of the initial<= BR> posting, = http://www1.ietf.org/mail-archive/web/int-area/current/
msg00957.html, below.  Because this discussion may lead to the
rechartering of the dhc WG to take on either or both of these drafts
as new work items, those of you not on the int-area mailing list
should consider reviewing the e-mail thread and contributing to the
discussion.

- Ralph


=3D=3D=3D=3D=3D
To: Internet Area <int-area at ietf.org>
Subject: [Int-area] DCHP-based authentication for DSL?
From: Jari Arkko <jari.arkko at piuha.net>
Date: Thu, 04 Oct 2007 23:22:15 +0300


We talked about the DSL requirements earlier on this list. Now
they have sent us a liaison statement regarding what they would
like to do:

"At this time, we would like to make the IETF aware that during
our most recent DSL Forum quarterly meeting, the Architecture
and Transport Working Group agreed to seriously consider adopting
a mechanism such as that proposed in draft-pruss-dhcp-auth-dsl-01.txt
or draft-zhao-dhc-user-authentication-02. We understand that the authors of these specifications intend to produce a combined document soon.
The DSL Forum formally requests that the IETF adopt this as a work
item, and would appreciate being advised of progress as soon as
possible.

Our next quarterly meeting is December 10-13, in Lisbon, Portugal."

How do we feel about this? Is this a good idea, considering the DSL
architecture? How will it affect DHCP the protocol? How would
you go about making DHCP extensions so that they work best
for all possible environments and not just DSL? Is anyone
already working on the combined draft promised above? Are
there any other choices that we should recommend instead?

I would like to hold the discussion on this in this list until
we've determined that the DHCP protocol is the right tool
for the job. If it is, we can recharter DHC WG again to add
the actual development work there. (DHC is right now
being rechartered but that recharting is mostly a cleanup
and not the addition of functionality to do this.)

Jari


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



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

  


 --B_3276758953_59506264-- --===============0213510708== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0213510708==-- From dhcwg-bounces@ietf.org Wed Nov 14 09:02:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsIpO-00074w-Ha; Wed, 14 Nov 2007 09:02:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsIpM-000730-KE for dhcwg@ietf.org; Wed, 14 Nov 2007 09:02:48 -0500 Received: from mx.isc.org ([2001:4f8:0:2::1c]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsIpK-0004aX-Pi for dhcwg@ietf.org; Wed, 14 Nov 2007 09:02:48 -0500 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 61D6811401F; Wed, 14 Nov 2007 14:02:45 +0000 (UTC) (envelope-from Shane_Kerr@isc.org) Received: from [192.168.1.18] (hurix.ams-ix.net [193.194.136.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 49F03E6056; Wed, 14 Nov 2007 14:02:45 +0000 (UTC) (envelope-from shane@isc.org) Message-ID: <473B0002.9080902@isc.org> Date: Wed, 14 Nov 2007 15:02:42 +0100 From: Shane Kerr Organization: ISC User-Agent: Thunderbird 2.0.0.6 (X11/20070806) MIME-Version: 1.0 To: Bud Millwood Subject: Re: [dhcwg] Client Port Option? References: <473991A0.2060009@isc.org> <200711131343.42205.budm@weird-solutions.com> <4739E337.1090107@isc.org> <200711132339.50550.budm@weird-solutions.com> In-Reply-To: <200711132339.50550.budm@weird-solutions.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shane_kerr@isc.org List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bud Millwood wrote: > On Tuesday 13 November 2007 18:47, Shane Kerr wrote: >> Bud Millwood wrote: >>> On Tuesday 13 November 2007 13:02, Shane Kerr wrote: >>>> Shane Kerr wrote: >>>>> I think it might be useful for DHCP clients to use a different port, >>>>> other than 68/546. >>>> Hm... I just realized that I didn't explain the actual proposal. :( >>>> >>>> The idea is that if clients did want to use a different port, they would >>>> include an option with the port number when the sent a packet. >>> We respond to whatever the source port was *by default*, and allow an >>> administrative override that forces responses to a particular dest port >>> (68 being the obvious choice). That way you can skip the need for a >>> client option. >> Interesting to hear that you do this by default. IMHO this should have been >> the defined behavior all along. I wonder why this wasn't corrected, at >> least for DHCPv6? >> >> I can't think of a way to change this in the protocol without potential >> pain. Still, maybe a hack is possible. Something like: >> >> - Send the first reply to the UDP port in the packet. >> - If a retransmission is detected, send the reply to port 68 and the UDP >> port in the packet. > > If the client used src port N, why would it not expect a reply on that same > port? It seems to me that a client that's straddling two ports - 68 for > inbound and something else for outbound - is already on thin ice. Well, I agree, but happens to be the thin ice that the protocol defines as okay. :) I think that RFC 2131 is the only place where this is defined: DHCP uses UDP as its transport protocol. DHCP messages from a client to a server are sent to the 'DHCP server' port (67), and DHCP messages from a server to a client are sent to the 'DHCP client' port (68). A server with multiple network address (e.g., a multi-homed host) MAY use any of its network addresses in outgoing DHCP messages. >> This will cause extra packets and delay, but mostly for clients that send >> from a port other than 68 and expect a reply on port 68. > > Do you know of any clients that do this, or is this just debug code? And if > it's debug code, why not allow the server to respond to the client's source > port instead? That way you can transmit from as many source ports as you > want. I don't know of any clients that send from a port other than 68 and expect a reply on port 68. But if there are any, then they are following RFC 2131, and if we change the specification then they will break even though they do the right thing according to the RFC. I don't really know if there are clients that send from a port other than 68 at all. I guess from the server point of view it is "almost safe" to send back to the originating port. You have experience with this, since it is how your software operates - have you seen any problems with this in the field? Does anybody ever set the option to change from this behavior? Thinking about it, the problem is tricker from a client point of view. Since servers may have the address hard-coded in, a generic client cannot assume that a port other than 68 will ever work. I can imagine how to do this from a operational point of view (try it with your server) or maybe from a OS point of view (use port 68 by default, and if you want to run multiple clients try it and give appropriate error messages if it doesn't work). But from a protocol point of view? No idea. :( Maybe the best thing is just to set it as a non-standard option in our server... - -- Shane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHOv/+MsfZxBO4kbQRAgI1AJ9FruPv/3f+h4T40YPQ39ods9Q39ACglx/s VcXOY08O73XAkMJTA2qzkQs= =zaJA -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 09:28:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJEa-00057P-F4; Wed, 14 Nov 2007 09:28:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJEY-00053x-Lu for dhcwg@ietf.org; Wed, 14 Nov 2007 09:28:50 -0500 Received: from intermail.se.dataphone.net ([212.37.1.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsJEX-0007ry-JC for dhcwg@ietf.org; Wed, 14 Nov 2007 09:28:50 -0500 Received: from [213.115.152.226] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.2) with ESMTP id 50895562; Wed, 14 Nov 2007 15:28:45 +0100 From: Bud Millwood Organization: Weird Solutions, Inc. To: shane_kerr@isc.org, dhcwg@ietf.org Subject: Re: [dhcwg] Client Port Option? Date: Wed, 14 Nov 2007 14:44:08 +0100 User-Agent: KMail/1.8 References: <473991A0.2060009@isc.org> <200711132339.50550.budm@weird-solutions.com> <473B0002.9080902@isc.org> In-Reply-To: <473B0002.9080902@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711141444.08674.budm@weird-solutions.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bud Millwood List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Wednesday 14 November 2007 15:02, Shane Kerr wrote: > Bud Millwood wrote: > > On Tuesday 13 November 2007 18:47, Shane Kerr wrote: > >> Bud Millwood wrote: > >>> On Tuesday 13 November 2007 13:02, Shane Kerr wrote: > >>>> Shane Kerr wrote: > >>>>> I think it might be useful for DHCP clients to use a different port, > >>>>> other than 68/546. > >>>> > >>>> Hm... I just realized that I didn't explain the actual proposal. :( > >>>> > >>>> The idea is that if clients did want to use a different port, they > >>>> would include an option with the port number when the sent a packet. > >>> > >>> We respond to whatever the source port was *by default*, and allow an > >>> administrative override that forces responses to a particular dest port > >>> (68 being the obvious choice). That way you can skip the need for a > >>> client option. > >> > >> Interesting to hear that you do this by default. IMHO this should have > >> been the defined behavior all along. I wonder why this wasn't corrected, > >> at least for DHCPv6? > >> > >> I can't think of a way to change this in the protocol without potential > >> pain. Still, maybe a hack is possible. Something like: > >> > >> - Send the first reply to the UDP port in the packet. > >> - If a retransmission is detected, send the reply to port 68 and the UDP > >> port in the packet. > > > > If the client used src port N, why would it not expect a reply on that > > same port? It seems to me that a client that's straddling two ports - 68 > > for inbound and something else for outbound - is already on thin ice. > > Well, I agree, but happens to be the thin ice that the protocol defines as > okay. :) > > I think that RFC 2131 is the only place where this is defined: > > DHCP uses UDP as its transport protocol. DHCP messages from a client > to a server are sent to the 'DHCP server' port (67), and DHCP > messages from a server to a client are sent to the 'DHCP client' port > (68). A server with multiple network address (e.g., a multi-homed > host) MAY use any of its network addresses in outgoing DHCP messages. > > >> This will cause extra packets and delay, but mostly for clients that > >> send from a port other than 68 and expect a reply on port 68. > > > > Do you know of any clients that do this, or is this just debug code? And > > if it's debug code, why not allow the server to respond to the client's > > source port instead? That way you can transmit from as many source ports > > as you want. > > I don't know of any clients that send from a port other than 68 and expect > a reply on port 68. But if there are any, then they are following RFC 2131, > and if we change the specification then they will break even though they do > the right thing according to the RFC. > > I don't really know if there are clients that send from a port other than > 68 at all. I guess from the server point of view it is "almost safe" to > send back to the originating port. You have experience with this, since it > is how your software operates - have you seen any problems with this in the > field? Does anybody ever set the option to change from this behavior? Originally we simply transmitted back to the source port, and I seem to recall having someone report that it was not strictly compliant behavior. That was many years ago, and IIRC it was an engineer writing in-house debug code. I'm not aware of anyone that's asked how to configure the server to enforce strict dest-port compliance since then, and our default is still to transmit to the source port. So in practice, for us, it hasn't been an issue at all if you discount the original report. There's always the possibility that a user has figured out how to enforce dest-port compliance without asking, though. > Maybe the best thing is just to set it as a non-standard option in our > server... If you make it an option that defaults to the opposite of ours, your behavior doesn't change, but you get the same flexibility. - Bud _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 09:57:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJga-0005Sz-2a; Wed, 14 Nov 2007 09:57:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJgY-0005SA-Em for dhcwg@ietf.org; Wed, 14 Nov 2007 09:57:46 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsJgU-0001b0-DB for dhcwg@ietf.org; Wed, 14 Nov 2007 09:57:46 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=IN7ZRDQmyxL0wyVRmQkxSqVjJUD/t22TNs1ow17rbyL2qMLCZYc943b9WZ2Qc7dt; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IsJgT-0005SA-1N; Wed, 14 Nov 2007 09:57:41 -0500 Message-ID: <000f01c826ce$b4494bc0$6401a8c0@tsg1> From: "TS Glassey" To: References: <4733482A.7020302@sun.com><4735A243.6090905@sun.com> <47368636.3070007@udel.edu><4736F7A7.2090707@sun.com> <473736A7.5000801@udel.edu><47387778.4030702@sun.com> <47391B04.8080202@udel.edu> <006801c82641$cd256990$6401a8c0@tsg1> <473AC2CA.2080509@isc.org> Date: Wed, 14 Nov 2007 06:57:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79efc464e1a1329cd30a6393c93a2d9284350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org Subject: [dhcwg] Re: [ntpwg] Digital Evidence Standards and a statement that this directly effects NTP and its use... X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org ----- Original Message ----- From: "Shane Kerr" To: "TS Glassey" Cc: ; Sent: Wednesday, November 14, 2007 1:41 AM Subject: Re: [ntpwg] Digital Evidence Standards and a statement that this directly effects NTP and its use... > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Todd, > > TS Glassey wrote: >> >> Google the actual ruling here: >> http://www.google.com/search?q=lorraine+v+markel&rls=com.microsoft:en-us:IE-SearchBox&ie=UTF-8&oe=UTF-8&sourceid=ie7&rlz=1I7GGLF > > A massive triumph of legal formalism over common sense, IMHO. Yeah - I hear this same statement from Systems Administrator's - the same buch of guys and girls that keep failing those IT Security Audits... so I look to their commentary as their way of getting out of doing a honest day's work. If that statement offfends you as much as a buch of Systems Administrator's trying to control the world of Information Security becuase they are too freaking lazy to 'do it right', well... you explain to me why so many folks fail those audits again and again ??? This ruling sets the world of the System Administrator on its arse and did so globally by eliminating the concept that there is no-such thing as a digital original. In fact there is and the issue is that while document conterfeiting used to be more difficult, now a days it is as easy as saying 'cp file1-name counterfeit-file name'... > >> Bluntly, the world changed a tad on May 4th and while this effort is >> pointed >> at the physics of operating NTP, these new controls impact any work with >> any >> other Standardized Protocol as well... What this means to people who NTP >> is >> a part of their commercial offering, is that they MUST apply these new >> standards to this code and its support as well, or they must use their >> own >> internal code-base's rather than depending on one here. I think this >> ruling >> re-set the bar heighth, and it is now much higher - even for an Academic >> Entity. As to how this effects this WG, we need to build tools that are >> capable of being used in these key application contexts or this protocol >> will likely be ultimately replaced. > > I'm a little slow this morning... I can't figure out how this standard > applies > to NTP. OK Shane, I personally think the ruling means that there are now requirement's for tight and reliable evidence ganthering and maintanence in all aspects of the use of something creating digital evidence, especially when those processes run automatically below the general control of the end-user... It sets a new bar-height for demonstrating the quality of the system and the security in place for its use. So in some senses its NOT the NTP protocol itslef but its use that are impacted. Certianly the integrity of the code management process will become a real issue. For what its worth this matter is before the US Appellate Court right now to get it advanced into real precedent "standard" from the persusave precedent it is now and all concerned will need to understand this and comply with it. > Can you explain what it means, from a protocol and a software point of > view (plain English preferred, technical gibberish okay, no legalese > please)? 1) REAL reliable NTP user models MUST be developed. That means Use Statment's and what the system will provide in the form of timestamps per second based on some baseline metric. 2) A real TEST PLAN needs to exist for each program in the NTP Suite and that will be executed by the supporting party. Its MUCH better for the commercial relying parties if they dont develop the core of this TEST PLAN but rather just customize the one used to pre-certify the operations of NTP in their environment. 3) The entity holding the Code Base will have to take full responsibility for that as well, meaning that they will become liable for screwup's or damages that people suffer using the code. 4) The "No warranty for fitness" language needs to be removed from the license IMHO, because if there is no accountability in the time transfer process there is no point in using it. Hmmm- what would that mean for the ISC by the way? - could it step to the plate and put in place a secured and audited change control process and service? Could it and will it bear the expense of those? Just my two cents. Todd Glassey > > - -- > Shane > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHOsLAMsfZxBO4kbQRAk8uAKCjfp0XvQUKcCat2oBvUDOBgZ39fwCfWtcN > 5ejJMaSb3blH3h/9kohaioo= > =4DDy > -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 11:24:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsL2h-00029l-14; Wed, 14 Nov 2007 11:24:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsL2f-00026P-2K for dhcwg@ietf.org; Wed, 14 Nov 2007 11:24:41 -0500 Received: from whimsy.udel.edu ([128.4.2.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsL2d-0005Ez-SO for dhcwg@ietf.org; Wed, 14 Nov 2007 11:24:40 -0500 Received: by whimsy.udel.edu (Postfix, from userid 62) id 3FB861689; Wed, 14 Nov 2007 16:24:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id C9DBB167F; Wed, 14 Nov 2007 16:24:32 +0000 (UTC) Message-ID: <473B2139.805@udel.edu> Date: Wed, 14 Nov 2007 16:24:25 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: ntpwg@lists.ntp.org, dhcwg@ietf.org References: <4733482A.7020302@sun.com><4735A243.6090905@sun.com> <47368636.3070007@udel.edu><4736F7A7.2090707@sun.com> <473736A7.5000801@udel.edu><47387778.4030702@sun.com> <47391B04.8080202@udel.edu> <006801c82641$cd256990$6401a8c0@tsg1> In-Reply-To: <006801c82641$cd256990$6401a8c0@tsg1> X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Subject: [dhcwg] Re: Digital Evidence Standards and a statement that this directly effects NTP and its use... X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ted, There may be much merit in the case you cite; however, this is a volunteer group and neither a cabal of lawyers nor capable of high finance. If you have a specific plan, are willing to direct and contribute to it and suffient labor is available, let's do it. If you have very specific proposals that can be implemented without serious committment of effort, let's hear that, too. Better yet, find a lawyer needing to fill out his required 100 hours of pro-bono time per year and have him translate your legal issues to actionable projects. Dave TS Glassey wrote: > Dave - > There is ANOTHER issue facing this WG and that is that just like the > "description's" of the NTP Process the AutoKEY system needs to be > accountable to a standard which allows data captured from such a > source to be admitted in a court of law and now that there are formal > standards many of the cool methods of delivering time over networks > from a physics perspective dont mean squat now to the Courts. > > The case that set this standard was called Lorraine v Markel CIVIL > ACTION NO. PWG-06-1893 and it came out of the US District Court in > Maryland on May 4th 2007 from a Judge (a Chief Magistrate Judge) by > the name of Paul Grimm. Google the actual ruling here: > http://www.google.com/search?q=lorraine+v+markel&rls=com.microsoft:en-us:IE-SearchBox&ie=UTF-8&oe=UTF-8&sourceid=ie7&rlz=1I7GGLF > > > Bluntly, the world changed a tad on May 4th and while this effort is > pointed at the physics of operating NTP, these new controls impact any > work with any other Standardized Protocol as well... What this means > to people who NTP is a part of their commercial offering, is that they > MUST apply these new standards to this code and its support as well, > or they must use their own internal code-base's rather than depending > on one here. I think this ruling re-set the bar heighth, and it is now > much higher - even for an Academic Entity. As to how this effects this > WG, we need to build tools that are capable of being used in these key > application contexts or this protocol will likely be ultimately replaced. > > Just my two cents, > > Todd Glassey > > ----- Original Message ----- From: "David L. Mills" > To: ; > Sent: Monday, November 12, 2007 7:33 PM > Subject: Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 > > >> Brian, >> >> Roaming laptops is what NTP Autokey is designed for. All a properly >> configued laptop would not need anything except a flag that says to use >> it and possibly the public group key. Heck with NTP; use Autokey to >> authenticate the server for anything. >> >> Dave >> >> Brian Utterback wrote: >> >>> >>> >>> David L. Mills wrote: >>> >>>> Brian, >>>> >>>> My model about the keys is that the DHCP server would supply a key ID >>>> for the NTP server(s) as configured, but not the keys themselves. The >>>> keys would have to be configured for the NTP server and client >>>> separately. The DHCP server would be responsible only for the opaque >>>> key ID. >>>> >>> >>> I see what you mean, but I am not sure about the use case here. >>> Certainly if the keys are pre-configured on both the clients and the >>> servers, then the key id is a must. But I am concerned about the >>> roaming laptop mode here. If I bring my laptop to a network, I would >>> like to be able to get enough info from the DHCP server to allow me >>> to securely connect to the server and have it be authenticated. Perhaps >>> a public key distribution scheme? >>> >>>> There is an issue about the security of the DFCP server itself; that >>>> is another issue. I'm assuming the DHCP server is behind the firewall. >>> >>> >>> >>> Right. Out of the realm of our discussion. >>> >>>> >>>> The mode specification could be any of the valid NTP modes. If client >>>> (3) it would be an ordinary client/server association. A means would >>>> be necessary to specify broadcast client, as that is not a mode in >>>> the strict sense. It could be symmetric active (1), in which case the >>>> victim would initiate that type association. To specify symmetric >>>> passive (2) means that the victim should wait for a symmetric active >>>> (1) packet. This does not seem useful. >>> >>> >>> >>> If you get a broadcast address to use then you should be a broadcast >>> client. I don't see the usefulness of a DHCP client being a symmetric >>> anything. Perhaps this is a failure of imagination on my part. >>> >>> >> >> _______________________________________________ >> ntpwg mailing list >> ntpwg@lists.ntp.org >> https://lists.ntp.org/mailman/listinfo/ntpwg > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 14 12:02:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLdZ-0006Wn-RF; Wed, 14 Nov 2007 12:02:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLdY-0006WW-PL for dhcwg@ietf.org; Wed, 14 Nov 2007 12:02:48 -0500 Received: from [2001:4f8:3:bb::1:ee8b] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsLdY-00005S-9b for dhcwg@ietf.org; Wed, 14 Nov 2007 12:02:48 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id B751A5A6ED; Wed, 14 Nov 2007 09:02:47 -0800 (PST) Date: Wed, 14 Nov 2007 09:02:47 -0800 From: "David W. Hankins" To: Karsten Perlich Subject: Re: [dhcwg] ONE DHCP-Server for different pfysical and logical networks Message-ID: <20071114170247.GB22241@isc.org> References: <472B8C0B.9020201@perlich.info> Mime-Version: 1.0 In-Reply-To: <472B8C0B.9020201@perlich.info> User-Agent: Mutt/1.5.9i X-Spam-Score: -0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0813015179==" Errors-To: dhcwg-bounces@ietf.org --===============0813015179== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 02, 2007 at 09:43:55PM +0100, Karsten Perlich wrote: > Help needed!! Hi Karsten, Unfortunately the IETF DHC WG mailing list is the wrong place to ask. This is a place for discussion of the IETF DHCP protocol itself, and various IETF standards work related to DHCP. I assume you are using the ISC DHCP software package, in which case you should direct this question to the dhcp-users mailing list. You can learn more and subscribe here; http://www.isc.org/sw/dhcp/dhcp-lists.php --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHOyo3cXeLeWu2vmoRAoFFAJ9lZPqFOfgZkqOGGIEN6TUbEhsaegCeOzDg DIvmW12IegUnhLQFQCWYs+Y= =r65O -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- --===============0813015179== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0813015179==-- From dhcwg-bounces@ietf.org Wed Nov 14 18:23:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsRa2-0001dP-6U; Wed, 14 Nov 2007 18:23:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsRZz-0001cD-IN; Wed, 14 Nov 2007 18:23:31 -0500 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsRZq-0004q6-OH; Wed, 14 Nov 2007 18:23:31 -0500 Received: from IBM52A5038A94F ([88.233.33.212]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1IsRZc2aBW-00009V; Wed, 14 Nov 2007 18:23:21 -0500 From: "Alper Yegin" To: Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WGrecharteringforDHCPauthentication Date: Thu, 15 Nov 2007 01:23:01 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <473A31FF.20504@cisco.com> Thread-Index: AcgmTD/PwF9Uy0boSGiUuy4vJ1PIbwAxMetw Message-Id: <0MKpCa-1IsRZc2aBW-00009V@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19jakZiYbrYFszvWaXyIuBtWJRRCuBIBhhEHjO T835h0TmW3bhOpMXDmMoHUJI7KJBzwf1LysGniQVLYZ0ubFwmV sCfz/tBRwx3Cr+7HvVBlg== X-Spam-Score: 0.3 (/) X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c Cc: dhcwg@ietf.org, 'Internet Area' , parberg@redback.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0343542829==" Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0343542829== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0AF8_01C82726.18CB5B40" This is a multi-part message in MIME format. ------=_NextPart_000_0AF8_01C82726.18CB5B40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Alper Yegin wrote, around 14/11/07 8:51 AM: Hi, It is clear that any solution which requires a temporary ip-address will create more turn on a BRAS, and the subscriber setup rate will very likely go down compared to a solution which will finish authentication before ip-address allocation. Can you please elaborate on the impact of using a link-local or DHCP-assigned IP address prior to running access authentication? Details would help us understand the level of impact, and let us see if we can identify any remedies. Well if you use link local you need to stop the DHCP client stack which means changing the DHCP stack which you have said is scary many times. Alper> If you are using link-local IP address prior to PANA, that means you don't attempt to configure an IP address using DHCP prior to successful completion of PANA. That does not alter DHCP state machine. Secondly to run PANA with link local to the NAS, you need to re engineer all the layer 2 SAVA security because the link local addresses look like spoofed addresses to the layer 2 switches and would be dropped. Alper> This statement gives me the impression that L2 SAVA is based on snooping DHCP only and it cannot be touched at all. Well, this cannot be true if you consider IPv6. It has to deal with link-local IP addresses and a lot more. See http://ietf.org/internet-drafts/draft-baker-sava-implementation-00.txt. And btw, somehow I see IPv6 is being characterized as a "future" thing that does not exist today, but I know IPv6 is deployed in several DSL networks. If you couple that with all the rest of the extra mess of PANA discovery stuff then it is obvious that DHCP authentication it is much, much cleaner and leaner. Alper> If you can provide a technical point regarding the discovery, we can understand better. If you run DHCP-assigned address prior to authentication. The whole layer 2 network is exposed to attack by unauthenticated IP end-point. The SAVA done by DSLAMs and first hop switches is eliminated because unauthenticated users have DHCP assigned addresses. Alper> I don't see anything wrong with SAVA there. Up until the host reconfigures its IP address using second DHCP after successful PANA, there is the pre-PANA address that SAVA system checks. Alper> And. unauthenticated IP end-point does not have be a thread, because the network can limit that host's traffic to just "running PANA with the PAA." Not to mention thet obvious point that every renew during the unauthenticated period is extra messaging which for 60K-500K subscriber access networks are effectively huge extra message loads on everything in the DHCP path. Alper> As I have explained to Eric, if you are concerned about "load on DHCP path", loading more things to DHCP like access authentication is not going to help with reducing that load. This is fundamentally contradicting. Plus the point that you are now saying that 60 seconds is too short for the renew, which means that from around 10-15 second logins, which we have today, the latency is going to 60 seconds +. Alper> Sorry I couldn't follow this. What latency is that 60+? DHCP lease for the pre-PANA address shall be long enough to accommodate typical access authentication latency in order to reduce the possibility of renewals. Worse than that, the worst time for access is after a massive power outage where we have heard of is 20 minutes during recoveries due to AAA server loads and for this vulnerable time with PANA the DHCP has 20 extra renew per client which is millions of extra messages smashing things up. Alper> Have you considered how many EAP/DHCP retransmissions are going to occur due to EAP retranmissions during that 20 minutes? Assuming no crazy EAP implementation or configuration would have a 60-second timeout for retranmissions, the answer is at least "more", if not "a lot more". Alper ------=_NextPart_000_0AF8_01C82726.18CB5B40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alper Yegin wrote, around 14/11/07 8:51 AM: = 

Hi,
 
  
It is clear that any solution which requires =
a temporary ip-address
will create more turn on a BRAS, and the =
subscriber setup rate will
very likely go down compared to a solution =
which will finish
authentication before ip-address =
allocation.
    =

 
Can you please elaborate on the impact of =
using a link-local or
DHCP-assigned IP address prior to running =
access authentication? Details
would help us understand the level of impact, =
and let us see if we can
identify any =
remedies.
 

Well if you = use link local you need to stop the DHCP client stack which means changing the = DHCP stack which you have said is scary many times. 

Alper> If you are using link-local IP address prior to PANA, that means you = don’t attempt to configure an IP address using DHCP prior to successful = completion of PANA. That does not alter DHCP state = machine.

Secondly to = run PANA with link local to the NAS, you need to re engineer all the layer 2 = SAVA security because the link local addresses = look like spoofed addresses to the layer 2 switches and would be dropped. =

Alper> This statement gives me the impression that L2 SAVA is based on snooping = DHCP only and it cannot be touched at all. Well, this cannot be true if you = consider IPv6. It has to deal with link-local IP addresses and a lot more. See http://ietf.org/internet-drafts/draft-baker-sava-implementation-00= .txt. And btw, somehow I see IPv6 is being characterized as a = “future” thing that does not exist today, but I know IPv6 is deployed in several = DSL networks.

If you couple = that with all the rest of the extra mess of PANA discovery stuff then it is = obvious that DHCP authentication it is much, much cleaner and leaner.

Alper> If you can provide a technical point regarding the discovery, we can = understand better.


If you run DHCP-assigned address prior to authentication.  The = whole layer 2 network is exposed to attack by unauthenticated IP end-point.  = The SAVA done by DSLAMs and first hop switches is = eliminated because unauthenticated  users have DHCP assigned addresses.  =

Alper> I don’t see anything wrong with SAVA there. Up until the host reconfigures its IP address using second DHCP = after successful PANA, there is the pre-PANA address that SAVA system checks.

Alper> And… unauthenticated IP end-point does not have be a thread, = because the network can limit that host’s traffic to just “running PANA with the = PAA.”

Not to mention = thet obvious point that every renew during the unauthenticated period is = extra messaging which for 60K-500K  subscriber access networks are = effectively huge extra message loads on everything in the DHCP path.  =

Alper> As I have explained to Eric, if you are concerned about “load on = DHCP path”, loading more things to DHCP like access authentication is = not going to help with reducing that load. This is fundamentally = contradicting.

Plus the point = that you are now saying that 60 seconds is too short for the renew, which means = that from around 10-15 second logins, which we have today, the latency is = going to 60 seconds +. 

Alper> Sorry I couldn’t follow this. What latency is that 60+? DHCP lease = for the pre-PANA address shall be long enough to accommodate typical access = authentication latency in order to reduce the possibility of renewals. =

 =

Worse than = that, the worst time for access is after a massive power outage where we have = heard of is 20 minutes during recoveries due to AAA server loads and for this = vulnerable time with PANA the DHCP has 20 extra renew per client which is millions = of extra messages smashing things up.

Alper> Have you considered how many EAP/DHCP retransmissions are going to occur = due to EAP retranmissions during that 20 minutes? Assuming no crazy EAP = implementation or configuration would have a 60-second timeout for retranmissions, the = answer is at least “more”, if not “a lot = more”.

Alper<= /span>

 

------=_NextPart_000_0AF8_01C82726.18CB5B40-- --===============0343542829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0343542829==-- From dhcwg-bounces@ietf.org Thu Nov 15 00:16:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsX5h-00081R-Nr; Thu, 15 Nov 2007 00:16:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsX5e-0007xw-OQ; Thu, 15 Nov 2007 00:16:34 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsX5d-0001jQ-Rf; Thu, 15 Nov 2007 00:16:34 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 14 Nov 2007 21:16:33 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAF5GXSJ031533; Wed, 14 Nov 2007 21:16:33 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAF5GXEA023035; Thu, 15 Nov 2007 05:16:33 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 21:16:32 -0800 Received: from Rics-MacBook-Pro.local ([10.21.114.69]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 21:16:32 -0800 Message-ID: <473BD623.8090300@cisco.com> Date: Thu, 15 Nov 2007 15:16:19 +1000 From: Richard Pruss Organization: Cisco Systems User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Alper Yegin Subject: Re: [Int-area] Re: [dhcwg] Discussion of dhc WGrecharteringforDHCPauthentication References: <0MKpCa-1IsRZc2aBW-00009V@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IsRZc2aBW-00009V@mrelay.perfora.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Nov 2007 05:16:32.0462 (UTC) FILETIME=[AF7036E0:01C82746] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5782; t=1195103793; x=1195967793; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ric@cisco.com; z=From:=20Richard=20Pruss=20 |Subject:=20Re=3A=20[Int-area]=20Re=3A=20[dhcwg]=20Discussion=20of=20dhc= 09WGrecharteringforDHCPauthentication |Sender:=20; bh=cMArjK3bReEh5p79+bNLsmqvCNb0K96HqoG+agC8urk=; b=Wt2s5ESGcp1IwJnJ+B1Q0v8ZHozOJ1DM0B0OqAsJo1W/zfxxS6V8R2feJZ5PaB8BPKZp/MO+ h3I/k8TE/Sul+eNzUPJqacQxjJnrY12LtfjzRtNdj+6fo/kd1wqycg2ODf66ItOzLBqx7aGViX HJPtjPZmIlFILqYL2qj7hGwqE=; Authentication-Results: sj-dkim-1; header.From=ric@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: dhcwg@ietf.org, 'Internet Area' , parberg@redback.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ric@cisco.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Alper Yegin wrote, around 15/11/07 9:23 AM: > Alper Yegin wrote, around 14/11/07 8:51 AM: > > Hi, > > > > > >> It is clear that any solution which requires a temporary ip-address >> will create more turn on a BRAS, and the subscriber setup rate will >> very likely go down compared to a solution which will finish >> authentication before ip-address allocation. >> > > > Can you please elaborate on the impact of using a link-local or > > DHCP-assigned IP address prior to running access authentication? Details > > would help us understand the level of impact, and let us see if we can > > identify any remedies. > > > > Well if you use link local you need to stop the DHCP client stack which > means changing the DHCP stack which you have said is scary many times. > > Alper> If you are using link-local IP address prior to PANA, that means > you don’t attempt to configure an IP address using DHCP prior to > successful completion of PANA. That does not alter DHCP state machine. Well do not run until after PANA state for DHCP is an alteration of the DHCP state machine and of course a change in the DHCP client. > > Secondly to run PANA with link local to the NAS, you need to re engineer > all the layer 2 SAVA security because the link local addresses look like > spoofed addresses to the layer 2 switches and would be dropped. > > Alper> This statement gives me the impression that L2 SAVA is based on > snooping DHCP only and it cannot be touched at all. Well, this cannot be > true if you consider IPv6. It has to deal with link-local IP addresses > and a lot more. See > http://ietf.org/internet-drafts/draft-baker-sava-implementation-00.txt. > And btw, somehow I see IPv6 is being characterized as a “future” thing > that does not exist today, but I know IPv6 is deployed in several DSL > networks. Fred is proposing how SAVA for IPv6 could possibly work one day in the future. There is a huge difference between that and the IPv4 SAVA which is deployed. I know of no residential DSL services in the work. This is one thing I would love to learn I am wrong about, please name a provider doing residential IPv6 over DSL. > > If you couple that with all the rest of the extra mess of PANA discovery > stuff then it is obvious that DHCP authentication it is much, much > cleaner and leaner. > > Alper> If you can provide a technical point regarding the discovery, we > can understand better. Provide a side to side comparison of PANA verse DHCP Auth including L2 switches and SAVA security in L2 and it is very obvious. I notice you have been careful just to cast smoke over the number Eric put out but not provided your own. > > > If you run DHCP-assigned address prior to authentication. The whole > layer 2 network is exposed to attack by unauthenticated IP end-point. > The SAVA done by DSLAMs and first hop switches is eliminated because > unauthenticated users have DHCP assigned addresses. > > Alper> I don’t see anything wrong with SAVA there. Up until the host > reconfigures its IP address using second DHCP after successful PANA, > there is the pre-PANA address that SAVA system checks. > > Alper> And… unauthenticated IP end-point does not have be a thread, > because the network can limit that host’s traffic to just “running PANA > with the PAA.” How? Please specify which elements need to run what shiny new protocols and how this done. > > Not to mention thet obvious point that every renew during the > unauthenticated period is extra messaging which for 60K-500K subscriber > access networks are effectively huge extra message loads on everything > in the DHCP path. > > Alper> As I have explained to Eric, if you are concerned about “load on > DHCP path”, loading more things to DHCP like access authentication is > not going to help with reducing that load. This is fundamentally > contradicting. > > Plus the point that you are now saying that 60 seconds is too short for > the renew, which means that from around 10-15 second logins, which we > have today, the latency is going to 60 seconds +. > > Alper> Sorry I couldn’t follow this. What latency is that 60+? DHCP > lease for the pre-PANA address shall be long enough to accommodate > typical access authentication latency in order to reduce the possibility > of renewals. Latency from user line up until services is now some unspecified large number. > > > > Worse than that, the worst time for access is after a massive power > outage where we have heard of is 20 minutes during recoveries due to AAA > server loads and for this vulnerable time with PANA the DHCP has 20 > extra renew per client which is millions of extra messages smashing > things up. > > Alper> Have you considered how many EAP/DHCP retransmissions are going > to occur due to EAP retranmissions during that 20 minutes? Assuming no > crazy EAP implementation or configuration would have a 60-second timeout > for retranmissions, the answer is at least “more”, if not “a lot more”. Assuming both proposals use the same EAP method through the AAA path, main difference is all the extra messages on the DHCP path to the server from PANA. Unless of course you fully couple PANA to the DHCP relay stack and do local caching for the relay responses as you have said in the past. Which when one gets down to the real implementation impact of PANA has to do exactly the same things as DHCP Auth in the CPE and the BRAS DHCP stacks, and has the additional impacts to other elements that DHCP auth leaves untouched. - Ric > > Alper > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 15 14:33:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IskT2-0003E7-Op; Thu, 15 Nov 2007 14:33:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IskT1-0003Aw-08; Thu, 15 Nov 2007 14:33:35 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IskSw-0003nr-Ne; Thu, 15 Nov 2007 14:33:34 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 Nov 2007 14:33:30 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAFJXUHN020758; Thu, 15 Nov 2007 14:33:30 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAFJX7Ew003418; Thu, 15 Nov 2007 19:33:26 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 14:33:19 -0500 Received: from [161.44.65.201] ([161.44.65.201]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 14:33:19 -0500 In-Reply-To: References: <7CCD07160348804497EF29E9EA5560D7024DA3E6@exchtewks2.starentnetworks.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C0F76B1-96EA-4600-BC1F-EEB91D46CE4C@cisco.com> Content-Transfer-Encoding: 7bit From: Ralph Droms Date: Thu, 15 Nov 2007 14:33:23 -0500 To: McCann Peter-A001034 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 15 Nov 2007 19:33:19.0475 (UTC) FILETIME=[6067E430:01C827BE] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15546.002 X-TM-AS-Result: No--30.077700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4984; t=1195155210; x=1196019210; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[Mip4]=20draft-ietf-mip4-gen-ext-03.txt |Sender:=20 |To:=20McCann=20Peter-A001034=20; bh=KehWSP1S/nTZWzP8RY2xgTMGXJb9edV9DkTg998iiMU=; b=pYrEBmdInhRbRjfCUA3LWzMiOXY36c27NqPZMSDJt+uXtP7cf/DUR50mwv/SjhuHTNtFmD0h sfu06KqQ+aJ8ybhLLkzg8GPbQaxt/II+TEGHwHxZJFvDm68UApMatRk+; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: dhcwg@ietf.org, mip4@ietf.org, Levkowetz Henrik Subject: [dhcwg] Re: [Mip4] draft-ietf-mip4-gen-ext-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Pete - I notice that there are no references to other Mobile IPv4 documents in this draft, which makes it difficult for someone like myself who is relatively uninformed about Mobile IPv4 to know how to get more context about Mobile IPv4 extensions, the Mobile IPv4 message exchanges, etc. I tried reading RFC 3024 and, perhaps not giving myself enough time to understand the doc fully, I didn't see the problem with using DHCPINFORM with reverse tunneling. I wasn't able to answer another question for myself: what is the address assignment model and does critical information like subnet mask and default router have to be delivered at the same time as any assigned addresses? - Ralph On Nov 13, 2007, at Nov 13, 2007,12:00 PM, McCann Peter-A001034 wrote: > We have yet to arrive at a conclusion on whether to > proceed with this draft or document a DHCP-based > solution. > > It was recently pointed out to me that the DHCPINFORM > message may have some issues with reverse tunneling > due to the need to use encapsulating delivery style. > People might be concerned about the extra overhead > of this requirement. > > I'd like to ask members of the DHCP community especially > to please comment to both lists; it may help to read > RFC 3024 before doing so. > > I'd like to have this issue resolved before Vancouver. > > -Pete > > > Chowdhury, Kuntal wrote: >> Hi Pete, >> >> I think the source of the confusion is the use of DHCP options. The >> initial version of this I-D did not propose to use DHCP options at >> all. >> The proposal contained a few possible host config parameters that we >> would have defined. However, someone saw the light, and suggested >> that instead of redesigning the host config options from scratch, why >> not we used the options and the format of the options carrying config >> info as defined in DHCP. It made sense; hence we decided to accept >> that approach. >> >> Now, I see that people are mixing the use of DHCP protocol with MIP4 >> host config options. I think this is a digression that we should >> avoid. >> We need to understand the scope of the I-D. It does not rule out >> other ways to do host configuration when the MN is using MIP4. It >> defines _a_ way that is Mobile IP specific. It is also the most >> efficient one from the number of round trips point of view. >> >> When you say that running DHCP inside MIP4 tunnel allows for a single >> protocol to be used whether the MN is at home or visiting, I have a >> question. How is it possible for the MN to fetch config info from the >> visited network when RT is negotiated and enforced at the FA? >> >> BTW, the approach specified in the draft-ietf-mip4-gen-ext-03.txt >> allows the use of a single protocol i.e. MIP4 to be used to fetch >> config info from home and visited networks, not to mention with fewer >> number of messages. >> >> Another issue that we need to think about the use of DHCP inside MIP4 >> tunnel is security. We cannot prohibit the MN to run DHCPINFORM only, >> right? The MN may start doing IP address config (lease and release). >> How to secure these DHCP messages? If we intend to only allow the MN >> to send DHCPINFORM, how do we prevent it from sending other DHCP >> messages? >> >> AFAIK, RFC 3118 is not widely implemented and used. Even if it is, we >> can't expect the MIP4 implementations to start implementing RFC 3118 >> just to get a few config info from the home domain. >> >> Regards, >> Kuntal >> >>> -----Original Message----- >>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>> Sent: Tuesday, July 31, 2007 9:01 AM >>> To: mip4@ietf.org; dhcwg@ietf.org >>> Subject: [Mip4] draft-ietf-mip4-gen-ext-03.txt >>> >>> A question has arisen during the last call for >>> draft-ietf-mip4-gen-ext-03.txt. >>> >>> The draft includes the following text: >>> >>> There are mechanisms >>> such as DHCP for the mobile node to configure information from >>> the foreign network, but not from the home network when the >>> mobile node is not attached to the home network. >>> >>> However, this may not be strictly true. In particular, it might be >>> possible to use a DHCPINFORM message through the tunnel that was >>> established with Mobile IP, thus eliminating the need to encode DHCP >>> options inside Mobile IP messages. >>> This would allow for a single configuration protocol to be used >>> whether the MN is at home or visiting. >>> >>> I think we may have touched on this question during our last >>> chartering discussion but we might not have explored all the >>> ramifications. Please, if you have an opinion either way express it >>> now and give some background as to why you think so. >>> It is possible that we might turn this draft into a BCP-like >>> document >>> for how to configure and run DHCP over the tunnel to the home >>> network. >>> >>> -Pete _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 15 22:22:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsrmH-0006nC-VZ; Thu, 15 Nov 2007 22:21:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsrmG-0006j4-Ne for dhcwg@ietf.org; Thu, 15 Nov 2007 22:21:56 -0500 Received: from mx05.gis.net ([208.218.130.13]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsrmG-0004xo-8X for dhcwg@ietf.org; Thu, 15 Nov 2007 22:21:56 -0500 Received: from [10.10.10.100] ([63.209.227.112]) by mx05.gis.net; Thu, 15 Nov 2007 22:21:47 -0500 Message-ID: <473D0C34.4030507@ntp.org> Date: Thu, 15 Nov 2007 22:19:16 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Benoit Lourdelet (blourdel)" References: <4733482A.7020302@sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Brian Utterback , "Richard Gayraud \(rgayraud\)" Subject: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Benoit Lourdelet (blourdel) wrote: > Hello, > > A possible usage of all the NTP parameters specified in the new options > is to configure router gateway . In that scenario, the goal of a Service > Provider or an Enterprise IT is to autoconfigure the gateway as much as > possible, including some NTP client behavior, in order to keep the > control. An additional benefit is that the gateway can be shipped to > remote sites virtually without any configuration while keeping full > control of the NTP behavior. > > Following that line of thought, I may still see a need for "minpoll, > maxpoll, I and B fields". > No you don't, as I stated elsewhere, iburst should always be used by default but neither burst nor adjustments to the minpoll and maxpoll values should be made except under very special circumstances. burst is extremely unfriendly to the server and minpoll and maxpoll can make the algorithms used in NTP less stable. You really have to be an expert in NTP and its algorithms to change these from their default value. > Considering a central DHCP server, the use of remote-id [RFC4649] or > just link-id may tell the server from where > the request is coming then giving it the knowledge of the delay to > apply. > In the case of a DHCP server hosted by the first hop, the DHCP server is > well positioned to know the delay. > That's not true. The delay is between the NTP client and the NTP server and includes delays of any intermediary points like a router. > Considering the current option format which includes more than IP > addresses, the choice of multiple occurrences of the > same option looks sensible. Should we reduce the new options to IPv6 > addresses only, a list makes more sense. > No you should be using a DNS name and not IP addresses. The client then can use the DNS to lookup the name and get a bunch of IP addresses. The new pool option will then configure all of them (up to 10) for NTP servers. > > Benoit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 15 22:52:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IssGF-0001Kf-CU; Thu, 15 Nov 2007 22:52:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IssGD-0001Gf-BL for dhcwg@ietf.org; Thu, 15 Nov 2007 22:52:53 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IssGA-0004az-Sq for dhcwg@ietf.org; Thu, 15 Nov 2007 22:52:53 -0500 Received: from [10.6.126.250] (unknown [206.128.65.108]) by toccata.fugue.com (Postfix) with ESMTP id 65D4CBC43CB; Thu, 15 Nov 2007 20:52:49 -0700 (MST) Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 From: Ted Lemon To: Danny Mayer In-Reply-To: <473D0C34.4030507@ntp.org> References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> Content-Type: text/plain Date: Thu, 15 Nov 2007 20:52:53 -0700 Message-Id: <1195185173.26090.4.camel@uma> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , Brian Utterback , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Thu, 2007-11-15 at 19:19 -0800, Danny Mayer wrote: > No you should be using a DNS name and not IP addresses. The client > then can use the DNS to lookup the name and get a bunch of IP > addresses. The new pool option will then configure all of them > (up to 10) for NTP servers. True, but not really important, since the DHCP server is normally configured with a domain name, not an IP address. So it can do the lookup and return those ten IP addresses to the client. So you get the same effect whether you send the FQDN to the client and make it do the lookup, or do the lookup on the server. The advantage of doing it on the server is (1) you don't have to send an FQDN, and (2) the client doesn't need to have a resolver. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 15 23:29:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsspF-0002TB-Nq; Thu, 15 Nov 2007 23:29:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsspE-0002Nn-Ei for dhcwg@ietf.org; Thu, 15 Nov 2007 23:29:04 -0500 Received: from mx04.gis.net ([208.218.130.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsspB-0006ib-1u for dhcwg@ietf.org; Thu, 15 Nov 2007 23:29:04 -0500 Received: from [10.10.10.100] ([63.209.227.112]) by mx04.gis.net; Thu, 15 Nov 2007 23:28:47 -0500 Message-ID: <473D1BEB.1090102@ntp.org> Date: Thu, 15 Nov 2007 23:26:19 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Brian Utterback References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> <47368636.3070007@udel.edu> <4736F7A7.2090707@sun.com> In-Reply-To: <4736F7A7.2090707@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "Richard Gayraud \(rgayraud\)" , "David L. Mills" Subject: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Brian Utterback wrote: > Interesting. I agree that a key needs to be specified somehow, but it > is not clear to me how to do it. We have to assume that the client > does not have the same NTP keys. However, we would like a way to > specify a server and keys securely, so that the security of the > network depends only on the security of DHCP. Again I am not up to > date, *is* there a secure DHCP? If so, then how to get keys to the > clients becomes an issue. DHCPv6 uses IPSEC for security. However, as I pointed out in my own response, if you are provisioning an NTP server then it means that NTP is not running at the time and any security that requires reasonably close timestamps at both ends is likely to fail. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 15 23:32:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsssP-0000Ef-IE; Thu, 15 Nov 2007 23:32:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsssN-0000CQ-Vt for dhcwg@ietf.org; Thu, 15 Nov 2007 23:32:19 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsssH-0006wQ-Og for dhcwg@ietf.org; Thu, 15 Nov 2007 23:32:19 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Nov 2007 23:32:13 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAG4WDmB009913; Thu, 15 Nov 2007 23:32:13 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAG4W3ES005229; Fri, 16 Nov 2007 04:32:03 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 23:32:02 -0500 Received: from [192.168.1.100] ([10.86.243.77]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 23:32:01 -0500 In-Reply-To: <473D1BEB.1090102@ntp.org> References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> <47368636.3070007@udel.edu> <4736F7A7.2090707@sun.com> <473D1BEB.1090102@ntp.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4DE1A6EA-10E5-4707-AD34-28C95153EF6D@cisco.com> Content-Transfer-Encoding: 7bit From: Ralph Droms Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Date: Thu, 15 Nov 2007 23:32:05 -0500 To: Danny Mayer X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 16 Nov 2007 04:32:01.0959 (UTC) FILETIME=[A21B8B70:01C82809] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15546.002 X-TM-AS-Result: No--18.753700-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1191; t=1195187533; x=1196051533; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20Re=3A=20[ntpwg]=20Network=20Time=20Protocol =20(NTP)=20Options=20for=20DHCPv6 |Sender:=20 |To:=20Danny=20Mayer=20; bh=1Q6n3ElEmGdviNWQyMoX48a8we6oYnHj5k9pC3QzvPg=; b=R27NpZmZIjKicu9QB+3AHlxfridJIi7Un8/XEhjXKTr8cz41cJhRCkBQleya+MQnOS7xHrnO NqQ1BujFuzqirMTzBn6xbX9loSvU1wi+JwFcA3RH47bjT9fjkl8qo+jF; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Brian Utterback , "Richard Gayraud \(\(rgayraud\)\)" , "David L. Mills" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org DHCPv6 does not use IPSEC between the client and the server. Rather, it uses a shared key for authentication and message verification. It is possible to use IPSEC between a relay agent and a server. - Ralph On Nov 15, 2007, at Nov 15, 2007,11:26 PM, Danny Mayer wrote: > Brian Utterback wrote: >> Interesting. I agree that a key needs to be specified somehow, but it >> is not clear to me how to do it. We have to assume that the client >> does not have the same NTP keys. However, we would like a way to >> specify a server and keys securely, so that the security of the >> network depends only on the security of DHCP. Again I am not up to >> date, *is* there a secure DHCP? If so, then how to get keys to the >> clients becomes an issue. > > DHCPv6 uses IPSEC for security. However, as I pointed out in my own > response, if you are provisioning an NTP server then it means that NTP > is not running at the time and any security that requires reasonably > close timestamps at both ends is likely to fail. > > Danny > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 16 02:13:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsvOc-0006LI-F8; Fri, 16 Nov 2007 02:13:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsvOa-0006EA-NP for dhcwg@ietf.org; Fri, 16 Nov 2007 02:13:44 -0500 Received: from an-out-0708.google.com ([209.85.132.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsvOa-0001vy-G9 for dhcwg@ietf.org; Fri, 16 Nov 2007 02:13:44 -0500 Received: by an-out-0708.google.com with SMTP id c5so334594anc for ; Thu, 15 Nov 2007 23:13:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=YCqUuKcNEfQridAIp5bhOFNlUM9KoD8WjWEKjeWflXE=; b=gyakx5u+spv88sSJVHHyQceDb2d3EzK2ElJ/k9tk+FKbrgdTuCTF/CfAEkMDkt4IwM/aB8ABbDbdUqDaDwUx0eVEd9MFsYQnyz3GmqB6/6yK8aMIVALuL4CQvgVKdZ3V33ScS6KfyhTrRfrGVFcp0MJv6a93tl+Diny1FgMRUGk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RPeYYxhAlpQQ799P3j0mMQKPO5rJazL4QR7lP0i+ZakOdkulMbAAD67vgForbg6LvN1LFsdtNuNcCXVU16BnREEOEqubTHbIswKv7VRb05MKFT55Fx7+eFt5LTAXK59olCSRpZ4Hb+kecqQMDNPWULl/Ar0+fv38x7y6LGSzddg= Received: by 10.142.217.17 with SMTP id p17mr514597wfg.1195197223305; Thu, 15 Nov 2007 23:13:43 -0800 (PST) Received: by 10.143.196.2 with HTTP; Thu, 15 Nov 2007 23:13:43 -0800 (PST) Message-ID: <1d38a3350711152313s49656e90yab73b1a21d21d396@mail.gmail.com> Date: Fri, 16 Nov 2007 15:13:43 +0800 From: "Hui Deng" To: dhcwg@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [dhcwg] Fwd: I-D ACTION:draft-deng-dhc-service-identifiers-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hello, all If possible, please help to review and make some comment on it. Many thanks -Hui A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Service Identfiers List Option for DHCPv6 Author(s) : H. Deng Filename : draft-deng-dhc-service-identifiers-00.txt Pages : 11 Date : 2007-11-15 This document describes a new option for DHCPv6 [RFC3315] that provides a mechanism for specifying a list of service identifer which this connection support or doesn't support. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 16 03:34:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iswf4-000265-3H; Fri, 16 Nov 2007 03:34:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iswf2-00022d-PY for dhcwg@ietf.org; Fri, 16 Nov 2007 03:34:48 -0500 Received: from mx.isc.org ([2001:4f8:0:2::1c]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iswez-0002kn-H9 for dhcwg@ietf.org; Fri, 16 Nov 2007 03:34:48 -0500 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 0191B11401C; Fri, 16 Nov 2007 08:34:43 +0000 (UTC) (envelope-from Shane_Kerr@isc.org) Received: from [199.6.1.234] (unknown [199.6.1.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 5C382E6065; Fri, 16 Nov 2007 08:34:43 +0000 (UTC) (envelope-from shane@isc.org) Message-ID: <473D5620.4090009@isc.org> Date: Fri, 16 Nov 2007 09:34:40 +0100 From: Shane Kerr Organization: ISC User-Agent: Thunderbird 2.0.0.6 (X11/20070806) MIME-Version: 1.0 To: Hui Deng Subject: Re: [dhcwg] Fwd: I-D ACTION:draft-deng-dhc-service-identifiers-00.txt References: <1d38a3350711152313s49656e90yab73b1a21d21d396@mail.gmail.com> In-Reply-To: <1d38a3350711152313s49656e90yab73b1a21d21d396@mail.gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shane_kerr@isc.org List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hui, Hui Deng wrote: > If possible, please help to review and make some comment on it. > Many thanks Interesting idea, but it's not clear to me what it means when a service is advertised. For instance, if I advertise "ntp", does that mean that the local network has a reachable NTP server, or that the network allows port 123 traffic through it's firewall, or what? - -- Shane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHPVYcMsfZxBO4kbQRArZvAKDler9LDf9wrhprtpg1o0W7QKqZ/wCgtITI k9VA4Q2XKlfn2SzAEZHoRgk= =gE+O -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 16 10:36:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3F6-0000Sj-6W; Fri, 16 Nov 2007 10:36:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3F4-0000OT-2q for dhcwg@ietf.org; Fri, 16 Nov 2007 10:36:26 -0500 Received: from exchdev.pega.com ([198.22.153.35] helo=exchdev.rpega.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It3F3-0001sH-OY for dhcwg@ietf.org; Fri, 16 Nov 2007 10:36:25 -0500 Received: from [10.60.98.37] ([10.60.98.37]) by exchdev.rpega.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 10:35:44 -0500 Message-ID: <473DB834.4040606@ntp.org> Date: Fri, 16 Nov 2007 10:33:08 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ralph Droms Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> <47368636.3070007@udel.edu> <4736F7A7.2090707@sun.com> <473D1BEB.1090102@ntp.org> <4DE1A6EA-10E5-4707-AD34-28C95153EF6D@cisco.com> In-Reply-To: <4DE1A6EA-10E5-4707-AD34-28C95153EF6D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2007 15:35:44.0318 (UTC) FILETIME=[5A154DE0:01C82866] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Brian Utterback , "Richard Gayraud \(\(rgayraud\)\)" , "David L. Mills" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ralph Droms wrote: > DHCPv6 does not use IPSEC between the client and the server. Rather, > it uses a shared key for authentication and message verification. > > It is possible to use IPSEC between a relay agent and a server. > Thanks for the correction. As long as the shared key authentication does not depend on a valid time in any way then this is fine. Danny > - Ralph > > On Nov 15, 2007, at Nov 15, 2007,11:26 PM, Danny Mayer wrote: > >> Brian Utterback wrote: >>> Interesting. I agree that a key needs to be specified somehow, but it >>> is not clear to me how to do it. We have to assume that the client >>> does not have the same NTP keys. However, we would like a way to >>> specify a server and keys securely, so that the security of the >>> network depends only on the security of DHCP. Again I am not up to >>> date, *is* there a secure DHCP? If so, then how to get keys to the >>> clients becomes an issue. >> >> DHCPv6 uses IPSEC for security. However, as I pointed out in my own >> response, if you are provisioning an NTP server then it means that NTP >> is not running at the time and any security that requires reasonably >> close timestamps at both ends is likely to fail. >> >> Danny >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 16 11:58:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4WQ-0000mr-Gi; Fri, 16 Nov 2007 11:58:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4WP-0000mh-AH for dhcwg@ietf.org; Fri, 16 Nov 2007 11:58:25 -0500 Received: from the.hankinsfamily.info ([204.152.186.148] helo=hankinsfamily.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It4WM-0004QY-KA for dhcwg@ietf.org; Fri, 16 Nov 2007 11:58:25 -0500 Received: from navarre.mercenary.net (c-24-6-90-99.hsd1.ca.comcast.net [24.6.90.99]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id lAGGwL4P025784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Nov 2007 08:58:22 -0800 Received: by navarre.mercenary.net (Postfix, from userid 1000) id 73B3137FEE; Fri, 16 Nov 2007 05:48:03 -0800 (PST) Date: Fri, 16 Nov 2007 05:48:03 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Message-ID: <20071116134803.GB18883@isc.org> References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> <47368636.3070007@udel.edu> <4736F7A7.2090707@sun.com> <473D1BEB.1090102@ntp.org> Mime-Version: 1.0 In-Reply-To: <473D1BEB.1090102@ntp.org> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.6 (--) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ntpwg@lists.ntp.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1147700197==" Errors-To: dhcwg-bounces@ietf.org --===============1147700197== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 15, 2007 at 11:26:19PM -0500, Danny Mayer wrote: > Brian Utterback wrote: > > Interesting. I agree that a key needs to be specified somehow, but it > > is not clear to me how to do it. We have to assume that the client > > does not have the same NTP keys. However, we would like a way to > > specify a server and keys securely, so that the security of the > > network depends only on the security of DHCP. Again I am not up to > > date, *is* there a secure DHCP? If so, then how to get keys to the=20 > > clients becomes an issue. Although DHCPv6 does have a signature verification mechanism, it does not encrypt carried configuration. So unless you're transferring public keys for NTP, there's an exposure problem I'm not sure you're aware of. Just making sure you know, I'm not familiar with the keys discussed in this context. Next, I want to make sure that your expectations of the services DHCPv6 can provide are set appropriately. Others have pointed out DHCPv6's authentication mechanism uses shared secrets; there is also a similar mechanism for DHCPv4, RFC3118 "Authentication for DHCP Messages" (which 3315 says its method is based upon). You should know that this has not been well deployed in DHCPv4, and it shares very similar design features to RFC3315's authentication. The primary problem is that for most networks in operation, "configure a shared secret on all of your clients" defeats the purpose of the "Dynamic" in DHCP. If you have to manually configure all your clients with a key, why bother using DHCP at all? You may as well manually configure them all with the final configuration state and skip a lot of needless machinery. So although it can be done, no one actually does it. I understand that 3315 authentication has precisely the same barrier, that the client's keys are distributed "out of band." I have no reason to think that IPv6 makes operators more interested in manually configuring clients to obtain dynamic configuration state than they have been in IPv4. This is surmountable I think, it's possible the authentication methods might be extended and improved to remove this barrier to adoption, but there have been zero drafts to date which attempt to do so. So, expectations. Your expectations should be: No one will use 3315 authentication as it is, and therefore you will not have a cryptographically secured means to deliver this information on real networks. People will, however, take special care with their DHCPv6 protocol packets on their networks (firewalling, etc, just as many always have done in IPv4), and there exists the potential for improvement and actual deployment of cryptographic trust here at some future date. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --DocE+STaALJfprDB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHPZ+TcXeLeWu2vmoRAiHHAKCqoodhIfEwnDTtLKOuU8I2EcUy3ACePAbo 5N2/rw50n5i/pPcBco0mTAo= =ZpqN -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- --===============1147700197== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1147700197==-- From dhcwg-bounces@ietf.org Fri Nov 16 12:40:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4oY-0002sj-BS; Fri, 16 Nov 2007 12:17:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4n9-0001Al-2Y; Fri, 16 Nov 2007 12:15:43 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It4my-0004wG-HJ; Fri, 16 Nov 2007 12:15:42 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 6B8A22AC7F; Fri, 16 Nov 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1It4mU-0002rJ-4G; Fri, 16 Nov 2007 12:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 16 Nov 2007 12:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-subnet-alloc-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Subnet Allocation Option Author(s) : R. Johnson, et al. Filename : draft-ietf-dhc-subnet-alloc-06.txt Pages : 32 Date : 2007-11-16 This document defines a new DHCP option which is passed between the DHCP Client and the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with RFC-3942[4], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-alloc-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-subnet-alloc-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-subnet-alloc-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-16115008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-subnet-alloc-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-subnet-alloc-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-16115008.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Fri Nov 16 15:20:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It7g5-0001qa-Gz; Fri, 16 Nov 2007 15:20:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It7g3-0001qE-T4; Fri, 16 Nov 2007 15:20:35 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It7g0-0008Ik-Fn; Fri, 16 Nov 2007 15:20:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 64E303293E; Fri, 16 Nov 2007 20:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1It7fW-0002ZQ-AG; Fri, 16 Nov 2007 15:20:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 16 Nov 2007 15:20:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action:draft-ietf-dhc-agent-vpn-id-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Virtual Subnet Selection Sub-Option for the Relay Agent Information Option for DHCPv4 Author(s) : K. Kinnear, et al. Filename : draft-ietf-dhc-agent-vpn-id-05.txt Pages : 11 Date : 2007-11-16 In some environments, a relay agent resides in a network element which also has access to one or more virtual private networks (VPNs). If a DHCP server wishes to offer service to DHCP clients on those different VPNs the DHCP server needs to know information about the VPN on which each client resides. The Virtual Subnet Selection sub- option of the relay-agent-information option is used by the relay agent to tell the DHCP server important information about the VPN (called the Virtual Subnet Selection information, or VSS) for every DHCP request it passes on to the DHCP server, and is also used to properly forward any DHCP reply that the DHCP server sends back to the relay agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-vpn-id-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-agent-vpn-id-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agent-vpn-id-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-16151947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agent-vpn-id-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agent-vpn-id-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-16151947.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Fri Nov 16 15:53:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It8C2-0000XS-6h; Fri, 16 Nov 2007 15:53:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It8C1-0000XM-HY for dhcwg@ietf.org; Fri, 16 Nov 2007 15:53:37 -0500 Received: from exchdev.pega.com ([198.22.153.35] helo=exchdev.rpega.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It8C0-0000cH-Vd for dhcwg@ietf.org; Fri, 16 Nov 2007 15:53:37 -0500 Received: from [10.60.98.37] ([10.60.98.37]) by exchdev.rpega.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 15:53:36 -0500 Message-ID: <473E02B4.2050308@ntp.org> Date: Fri, 16 Nov 2007 15:51:00 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "David W. Hankins" Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> <47368636.3070007@udel.edu> <4736F7A7.2090707@sun.com> <473D1BEB.1090102@ntp.org> <20071116134803.GB18883@isc.org> In-Reply-To: <20071116134803.GB18883@isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2007 20:53:36.0336 (UTC) FILETIME=[C1E44D00:01C82892] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org David W. Hankins wrote: > On Thu, Nov 15, 2007 at 11:26:19PM -0500, Danny Mayer wrote: >> Brian Utterback wrote: >>> Interesting. I agree that a key needs to be specified somehow, but it >>> is not clear to me how to do it. We have to assume that the client >>> does not have the same NTP keys. However, we would like a way to >>> specify a server and keys securely, so that the security of the >>> network depends only on the security of DHCP. Again I am not up to >>> date, *is* there a secure DHCP? If so, then how to get keys to the >>> clients becomes an issue. > > Although DHCPv6 does have a signature verification mechanism, it does > not encrypt carried configuration. > > So unless you're transferring public keys for NTP, there's an exposure > problem I'm not sure you're aware of. Just making sure you know, I'm > not familiar with the keys discussed in this context. > I am aware of it, thanks. It was part of what I was trying to hilight. > > Next, I want to make sure that your expectations of the services > DHCPv6 can provide are set appropriately. > > Others have pointed out DHCPv6's authentication mechanism uses shared > secrets; there is also a similar mechanism for DHCPv4, RFC3118 > "Authentication for DHCP Messages" (which 3315 says its method is > based upon). You should know that this has not been well deployed in > DHCPv4, and it shares very similar design features to RFC3315's > authentication. The primary problem is that for most networks in > operation, "configure a shared secret on all of your clients" defeats > the purpose of the "Dynamic" in DHCP. If you have to manually > configure all your clients with a key, why bother using DHCP at all? > You may as well manually configure them all with the final > configuration state and skip a lot of needless machinery. > Well we are only responding to an effort to do this via DHCP. We cannot say for sure that this is the best method to do this and obviously it's not the only method. Of course you might say why bother with DHCP for that matter? > So although it can be done, no one actually does it. > > I understand that 3315 authentication has precisely the same barrier, > that the client's keys are distributed "out of band." I have no > reason to think that IPv6 makes operators more interested in manually > configuring clients to obtain dynamic configuration state than they > have been in IPv4. > > This is surmountable I think, it's possible the authentication methods > might be extended and improved to remove this barrier to adoption, but > there have been zero drafts to date which attempt to do so. > > So, expectations. > > > Your expectations should be: No one will use 3315 authentication as > it is, and therefore you will not have a cryptographically secured > means to deliver this information on real networks. People will, > however, take special care with their DHCPv6 protocol packets on their > networks (firewalling, etc, just as many always have done in IPv4), > and there exists the potential for improvement and actual deployment > of cryptographic trust here at some future date. Agreed. There are a whole slew of issues regarding provisioning of a system during the booting process (and other times) that need to be worked out. Specifically the network configuration and booting order of network configs for DHCP, DNS, NTP, syslog, SSH, SNMP, etc. At some point we really need to sit down and thrash out how to do this in a secure way, in what order that it makes sense, error conditions, etc. I'm not sure what the DHCP folks have been discussing so I bring it all up and you can tell us what's already been solved and how. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 16 18:45:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItAsh-0006Us-Ca; Fri, 16 Nov 2007 18:45:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItAsf-0006UM-Td; Fri, 16 Nov 2007 18:45:49 -0500 Received: from mout.perfora.net ([74.208.4.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItAsa-0007Ew-VC; Fri, 16 Nov 2007 18:45:49 -0500 Received: from IBM52A5038A94F ([88.233.33.212]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1ItAsT0w6V-00063J; Fri, 16 Nov 2007 18:45:43 -0500 From: "Alper Yegin" To: Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WGrecharteringforDHCPauthentication Date: Sat, 17 Nov 2007 01:45:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <473BD623.8090300@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgnRrBaBNhanykTQOmUeWxuLS9eaABYbgpQ Message-Id: <0MKp8S-1ItAsT0w6V-00063J@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+9egrY3kerG+4+zVgV4+f7j+47B1hlXPjm3q8 XxfFT7gsRsS21ZvzMYiAc67z5vtxFTpbrH2Ifx/g5WwtKmpOYs ZmdSbILQ+a65zvE/zRCfA== X-Spam-Score: 0.3 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: dhcwg@ietf.org, 'Internet Area' , parberg@redback.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > > Alper> If you are using link-local IP address prior to PANA, that means > > you don't attempt to configure an IP address using DHCP prior to > > successful completion of PANA. That does not alter DHCP state machine. > > Well do not run until after PANA state for DHCP is an alteration > of the DHCP state machine and of course a change in the DHCP client. Not starting the DHCP client is the simplest way. And that, obviously, has no change whatsoever on the DHCP SM or client. > > Secondly to run PANA with link local to the NAS, you need to re engineer > > all the layer 2 SAVA security because the link local addresses look like > > spoofed addresses to the layer 2 switches and would be dropped. > > > > Alper> This statement gives me the impression that L2 SAVA is based on > > snooping DHCP only and it cannot be touched at all. Well, this cannot be > > true if you consider IPv6. It has to deal with link-local IP addresses > > and a lot more. See > > http://ietf.org/internet-drafts/draft-baker-sava-implementation-00.txt. > > And btw, somehow I see IPv6 is being characterized as a "future" thing > > that does not exist today, but I know IPv6 is deployed in several DSL > > networks. > Fred is proposing how SAVA for IPv6 could possibly work one day > in the future. There is a huge difference between that and the IPv4 > SAVA which is deployed. I know of no residential DSL services in the > work. This is one thing I would love to learn I am wrong about, please > name a provider doing residential IPv6 over DSL. NTT. Since 2001. > > If you couple that with all the rest of the extra mess of PANA discovery > > stuff then it is obvious that DHCP authentication it is much, much > > cleaner and leaner. > > > > Alper> If you can provide a technical point regarding the discovery, we > > can understand better. > Provide a side to side comparison of PANA verse DHCP Auth > including L2 switches and SAVA security in L2 and it is very obvious. I > notice you have been careful just to cast smoke over the number Eric put > out but not provided your own. I already provided the numbers in response to Eric's email. Let me know if you have a specific question. Meanwhile, I hope you are seeing the fundamental problem: You cannot reduce DHCP "load" if you "overload" DHCP with EAP. > > If you run DHCP-assigned address prior to authentication. The whole > > layer 2 network is exposed to attack by unauthenticated IP end-point. > > The SAVA done by DSLAMs and first hop switches is eliminated because > > unauthenticated users have DHCP assigned addresses. > > > > Alper> I don't see anything wrong with SAVA there. Up until the host > > reconfigures its IP address using second DHCP after successful PANA, > > there is the pre-PANA address that SAVA system checks. > > > > Alper> And. unauthenticated IP end-point does not have be a thread, > > because the network can limit that host's traffic to just "running PANA > > with the PAA." > How? Please specify which elements need to run what shiny new > protocols and how this done. There is no protocol in there. It's all filtering. > > Not to mention thet obvious point that every renew during the > > unauthenticated period is extra messaging which for 60K-500K subscriber > > access networks are effectively huge extra message loads on everything > > in the DHCP path. > > > > Alper> As I have explained to Eric, if you are concerned about "load on > > DHCP path", loading more things to DHCP like access authentication is > > not going to help with reducing that load. This is fundamentally > > contradicting. > > > > Plus the point that you are now saying that 60 seconds is too short for > > the renew, which means that from around 10-15 second logins, which we > > have today, the latency is going to 60 seconds +. > > > > Alper> Sorry I couldn't follow this. What latency is that 60+? DHCP > > lease for the pre-PANA address shall be long enough to accommodate > > typical access authentication latency in order to reduce the possibility > > of renewals. > Latency from user line up until services is now some unspecified > large number. I didn't understand your point (or conclusion?). > > Worse than that, the worst time for access is after a massive power > > outage where we have heard of is 20 minutes during recoveries due to AAA > > server loads and for this vulnerable time with PANA the DHCP has 20 > > extra renew per client which is millions of extra messages smashing > > things up. > > > > Alper> Have you considered how many EAP/DHCP retransmissions are going > > to occur due to EAP retranmissions during that 20 minutes? Assuming no > > crazy EAP implementation or configuration would have a 60-second timeout > > for retranmissions, the answer is at least "more", if not "a lot more". > > Assuming both proposals use the same EAP method through the AAA > path, main difference is all the extra messages on the DHCP path to the > server from PANA. Unless of course you fully couple PANA to the DHCP > relay stack and do local caching for the relay responses as you have > said in the past. I never said such a thing. I suspect you are confusing someone else's statement about some other scenario/proposal. > Which when one gets down to the real implementation > impact of PANA has to do exactly the same things as DHCP Auth in the CPE > and the BRAS DHCP stacks, and has the additional impacts to other > elements that DHCP auth leaves untouched. Disagree, as explained throughout this thread. Alper _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 16 20:10:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItCCC-0007XC-Kt; Fri, 16 Nov 2007 20:10:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItCCA-0007TS-Cf; Fri, 16 Nov 2007 20:10:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItCCA-0000qY-0B; Fri, 16 Nov 2007 20:10:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D8D4E26E6E; Sat, 17 Nov 2007 01:10:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItCC9-0007CW-PM; Fri, 16 Nov 2007 20:10:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 16 Nov 2007 20:10:01 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action:draft-ietf-dhc-vpn-option-07.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Virtual Subnet Selection Option Author(s) : R. Johnson, et al. Filename : draft-ietf-dhc-vpn-option-07.txt Pages : 12 Date : 2007-11-16 This memo defines existing usage for the Virtual Subnet Selection (VSS) information option. It is intended for use primarily by DHCP proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address allocation to take place. The option number currently in use is 221. This memo documents the current usage of the option in agreement with [8], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-vpn-option-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-vpn-option-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-16200609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-vpn-option-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-vpn-option-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-16200609.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Fri Nov 16 20:38:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItCe2-0006rP-Fy; Fri, 16 Nov 2007 20:38:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItCe1-0006ow-Gs for dhcwg@ietf.org; Fri, 16 Nov 2007 20:38:49 -0500 Received: from rv-out-0910.google.com ([209.85.198.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItCdy-0001bT-82 for dhcwg@ietf.org; Fri, 16 Nov 2007 20:38:49 -0500 Received: by rv-out-0910.google.com with SMTP id l15so764430rvb for ; Fri, 16 Nov 2007 17:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=YdM2T1eGlUK4DJR53lGVUeFV6HQT24shHR0HoAxy9SM=; b=sG0Xf2+o1dm2hEbTwB9jzx/igWU7ckKugtdT1TuZu5JdCH+Bv1aC4496NZKmTFpzZSiPiAd6CfiIVhqX4/IF3AhAw9ABu4gEWO5DLUIG1u2bGnY9oXhyldiiMhgpoSYidUBIk9k1B8QeYUZIaPoSoqTQHF4q7NObbNDTCRHhPq4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fYw4otEY9NYxsG4G6KDKcGV8Gt/FUCaeWpcdf6IMs0QkgrxIKDRgc6ugBJkLUydUFzVQ1T5utOnAmW+hN2rLphtwIG4ljgm3xgOkEW/C3Rxx/sgOZMke/7yYmhix4f4TrxV2agq7qRJ2MPuowXnr5pvHK47PwZLXdU3UzXniayE= Received: by 10.140.139.11 with SMTP id m11mr604579rvd.1195263525718; Fri, 16 Nov 2007 17:38:45 -0800 (PST) Received: by 10.140.177.17 with HTTP; Fri, 16 Nov 2007 17:38:45 -0800 (PST) Message-ID: <1d38a3350711161738m2e6f83b9q7c925feac9f21624@mail.gmail.com> Date: Sat, 17 Nov 2007 09:38:45 +0800 From: "Hui Deng" To: shane_kerr@isc.org Subject: Re: [dhcwg] Fwd: I-D ACTION:draft-deng-dhc-service-identifiers-00.txt In-Reply-To: <473D5620.4090009@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1d38a3350711152313s49656e90yab73b1a21d21d396@mail.gmail.com> <473D5620.4090009@isc.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi, Shane, Thanks for your comments, reply as below, > Interesting idea, but it's not clear to me what it means when a service is > advertised. For instance, if I advertise "ntp", does that mean that the local > network has a reachable NTP server, or that the network allows port 123 traffic > through it's firewall, or what? I guess for some operator, they would like to say they allow such kind of port 123 traffic, for others operator, this draft could be extended to show there is a reachable NTP server. We hope it could ignite other purpose as well based on comments. Thanks again -Hui _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 16 21:00:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItCz7-00057W-Rp; Fri, 16 Nov 2007 21:00:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItCz4-00056y-L1; Fri, 16 Nov 2007 21:00:34 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItCz4-0002qr-8b; Fri, 16 Nov 2007 21:00:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 160F82AC88; Sat, 17 Nov 2007 02:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItCyY-0000jS-32; Fri, 16 Nov 2007 21:00:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 16 Nov 2007 21:00:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action:draft-ietf-dhc-server-override-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Server Identifier Override Suboption Author(s) : R. Johnson, et al. Filename : draft-ietf-dhc-server-override-05.txt Pages : 12 Date : 2007-11-16 This memo defines a new suboption of the DHCP relay information option which allows the DHCP relay to specify a new value for the Server Identifier option, which is inserted by the DHCP Server. This allows the DHCP relay to act as the actual DHCP server such that RENEW DHCPREQUESTs will come to the relay instead of going to the server directly. This gives the relay the opportunity to include the Relay Agent option with appropriate suboptions even on DHCP RENEW messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-override-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-server-override-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-server-override-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-16205220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-server-override-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-server-override-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-16205220.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Sat Nov 17 11:48:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItQpn-0006C6-Fx; Sat, 17 Nov 2007 11:47:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItQpm-0006Ax-6m for dhcwg@ietf.org; Sat, 17 Nov 2007 11:47:54 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItQph-0004K5-9w for dhcwg@ietf.org; Sat, 17 Nov 2007 11:47:54 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 17 Nov 2007 11:47:49 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAHGlm5S016058 for ; Sat, 17 Nov 2007 11:47:48 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAHGlmwl012792 for ; Sat, 17 Nov 2007 16:47:48 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Nov 2007 11:47:48 -0500 Received: from [192.168.3.134] ([10.82.241.208]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Nov 2007 11:47:47 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <94552139-D8AF-4D11-BC05-DF725E336A55@cisco.com> Content-Transfer-Encoding: 7bit From: Ralph Droms Date: Sat, 17 Nov 2007 11:47:57 -0500 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Nov 2007 16:47:47.0890 (UTC) FILETIME=[958BC920:01C82939] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15550.002 X-TM-AS-Result: No--10.270900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3521; t=1195318069; x=1196182069; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Fwd=3A=20I-D=20Action=3Adraft-sarikaya-16ng-prefix-delegation -02.txt=20 |Sender:=20 |To:=20dhcwg@ietf.org; bh=Q9DVRzpMn9mEytjgbmuHDmWwQ/oGBt2lAXF8s/mkq5I=; b=tHsMG9J2tcHtpqC5D5+nKPT5ut+jdRbS3bRrYrZct2CzUdFjcZcclkR8k9ONdxB7maxQFilk jlk1m6rAri1ZN865U8sK18fC2P6tFhHtHjPrC+IW1B1mKlBABHn2tyjV; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [dhcwg] Fwd: I-D Action:draft-sarikaya-16ng-prefix-delegation-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Might be good to get dhc WG review of this doc. - Ralph Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: November 17, 2007 11:40:02 AM EST > To: i-d-announce@ietf.org > Subject: I-D Action:draft-sarikaya-16ng-prefix-delegation-02.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Using DHCPv6 for Prefix Delegation in IEEE > 802.16 Networks > Author(s) : F. Xia, B. Sarikaya > Filename : draft-sarikaya-16ng-prefix-delegation-02.txt > Pages : 12 > Date : 2007-11-17 > > In the 802.16 Per-MS interface prefix model, one prefix can only be > assigned to one interface of a mobile station by an access router and > different mobile stations can't share a prefix. Managing Per-MS > interface prefixes is likely to increase the processing load at the > access router. Based on the idea that DHCPv6 servers can manage > prefixes as well as addresses, we propose a new technique in which > the access router offloads delegation and release tasks of the > prefixes to an DHCPv6 server. The access router first requests a > prefix for an incoming mobile station to the DHCPv6 server. The > access router next advertises the prefix information to the mobile > station with a Router Advertisement message. When the mobile station > hands off, the prefix is returned to the DHCPv6 server. We also > describe how AAA servers can help in prefix delegation. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sarikaya-16ng-prefix- > delegation-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-sarikaya-16ng-prefix-delegation-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-sarikaya-16ng-prefix-delegation-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-11-17113125.I-D\@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Nov 17 12:29:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItRU6-0002px-U1; Sat, 17 Nov 2007 12:29:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItRU5-0002pq-Ib for dhcwg@ietf.org; Sat, 17 Nov 2007 12:29:33 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItRU5-0008WE-45 for dhcwg@ietf.org; Sat, 17 Nov 2007 12:29:33 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 17 Nov 2007 09:29:32 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAHHTWuJ007831; Sat, 17 Nov 2007 09:29:32 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAHHTVGc018988; Sat, 17 Nov 2007 17:29:32 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Nov 2007 12:29:31 -0500 Received: from [192.168.3.134] ([10.82.241.208]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Nov 2007 12:29:30 -0500 In-Reply-To: <8E296595B6471A4689555D5D725EBB2105874F70@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB2105874F70@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ralph Droms Subject: Re: [dhcwg] dhc WG meeting in Vancouver Date: Sat, 17 Nov 2007 12:28:15 -0500 To: Bernie Volz (volz) X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Nov 2007 17:29:31.0154 (UTC) FILETIME=[699B8F20:01C8293F] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15550.002 X-TM-AS-Result: No--25.231900-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1954; t=1195320572; x=1196184572; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20dhc=20WG=20meeting=20in=20Vancouver |Sender:=20; bh=wMdWYP3243cwWdI5iqevW/DCnTiZSAu6ih847LjsrXM=; b=HEcIhJOetZM9HbKFCOAIH+r445xK4bvOVLUbD6/+ZC7dyrp1LHYv41+Cok289lmBLGSpKsxQ LxFO0XJK3Gt3G1nGZtc+8eqscjde9STPnrXHhm5HVCuHDKzgfbjU+V1gqhzGf3uqIkDwzVlPc2 QMJITQ+Zu03Vl4BiiY/N3pHDA=; Authentication-Results: sj-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: dhcwg@ietf.org, Dhc Chairs X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Bernie - are there any action items remaining from RFC 3942? Might be good to (a) update draft-volz-dhc-3942-status-00 (although I regret I'm responding too late for you to make the draft pub deadline) and (b) publish a final doc when everything from RFC 3942 is wrapped up to capture that the issues have all been closed. - Ralph On Nov 8, 2007, at Nov 8, 2007,11:30 PM, Bernie Volz (volz) wrote: > I'd like to discuss what should be done about > draft-volz-dhc-3942-status-00. It has expired and while I could simply > make a few edits (such as addressing 208-211) and resubmit, it seems > silly to do that if there is no support or interest for the DHC WG. > > I did ask the DHC WG in early October about next steps for this draft, > but it didn't go anywhere. > > We need to give IANA information about updating the DHCP options > registry. > > - Bernie > > -----Original Message----- > From: Ralph Droms (rdroms) > Sent: Thursday, November 08, 2007 11:36 AM > To: dhcwg@ietf.org > Cc: Dhc Chairs > Subject: [dhcwg] dhc WG meeting in Vancouver > > The dhc WG will meet in Vancouver, http://ietf.org/meetings/70- > IETF.html; here is the tentative scheduled date and time for our > meeting: > > TUESDAY, December 4, 2007 > 1300-1500 Afternoon Session I > Salon 1 INT dhc Dynamic Host Configuration WG > > Please contact the WG chairs, dhc-chairs@tools.ietf.org, with agenda > requests before Wed, Nov 14. > > As always, we are looking for volunteers to act as meeting and Jabber > scribes. > > Here are some important dates: http://ietf.org/meetings/70- > cutoff_dates.html Note that the I-D rev -00 submission deadline is > 0900 EST this coming Mon, 11/12, and the general I-D submission > deadline is 0900 EST Mon, 11/19. > > - Ralph > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Nov 17 13:11:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItS8T-0004Qp-7x; Sat, 17 Nov 2007 13:11:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItS8R-0004Ic-SP for dhcwg@ietf.org; Sat, 17 Nov 2007 13:11:15 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItS8R-0001N4-DM for dhcwg@ietf.org; Sat, 17 Nov 2007 13:11:15 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 17 Nov 2007 10:11:14 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAHIBENS032130 for ; Sat, 17 Nov 2007 10:11:14 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAHIBEGc006707 for ; Sat, 17 Nov 2007 18:11:14 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Nov 2007 13:11:13 -0500 Received: from [192.168.3.134] ([10.82.241.208]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Nov 2007 13:11:13 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <29941F02-448F-4BED-94B5-E50ABB58B564@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: dhcwg@ietf.org From: Ralph Droms Date: Sat, 17 Nov 2007 13:11:22 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Nov 2007 18:11:13.0419 (UTC) FILETIME=[3D12E5B0:01C82945] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15550.002 X-TM-AS-Result: No--2.492400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1583; t=1195323074; x=1196187074; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20*DRAFT*=20WG=20agenda=20 |Sender:=20; bh=6RBhSGaoslYE4m6aAo9MUiwVv9BxQi1QirS/B7yB59Q=; b=SArWrPTHdfwZY4IuB2m+QfY7Eh3LU+slI5VgFYGRD5T6GMuQK4d65dXriXYxKYGAvHfi1375 EnZ39RWHOMtwR8847HAs2RQLCjLzjyprf+Qd8464M4cIhmd0O1R9adLy; Authentication-Results: sj-dkim-4; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [dhcwg] *DRAFT* WG agenda X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Please contact Stig or me if we missed your request for an agenda slot or if you would like to get on the agenda. - Ralph ===== DHC WG DRAFT agenda - IETF 70 1300-1500 2007-12-04 (Tue) (Last revised 2007-11-17 01:08 PM ET) ------------------------------------- Administrivia Venaas/Droms 10 minutes Agenda bashing; blue sheets; scribe; Jabber scribe Draft last call and adoption announcements Venaas/Droms 05 minutes RFC 3942 status update B. Volz 05 minutes Progressing two drafts under RFC 3942 R. Droms 10 minutes DHCPv6 Bulk Leasequery M. Stapp 10 minutes Initial discussion Layer 2 Relay Agent Information B. Joshi 20 minutes Followup discussion of revised draft NTP Options for DHCPv6 B. Lourdelet 05 minutes Initial discussion and input to ntp WG Service Identfiers List Option for DHCPv6 H. Deng 10 minutes ----------- 75 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Nov 17 14:21:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItTEl-0000ky-UG; Sat, 17 Nov 2007 14:21:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItTEj-0000kT-5p; Sat, 17 Nov 2007 14:21:50 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ItTEi-0003OP-ND; Sat, 17 Nov 2007 14:21:49 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1195327306!10065514!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 5575 invoked from network); 17 Nov 2007 19:21:46 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-6.tower-153.messagelabs.com with SMTP; 17 Nov 2007 19:21:46 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lAHJLj4g027758; Sat, 17 Nov 2007 12:21:46 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lAHJLjIw017292; Sat, 17 Nov 2007 13:21:45 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.146]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lAHJLgVh017282; Sat, 17 Nov 2007 13:21:43 -0600 (CST) Message-ID: <473F3F45.4050204@gmail.com> Date: Sat, 17 Nov 2007 20:21:41 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [Int-area] Re: [dhcwg] Discussion of dhc WGrecharteringforDHCPauthentication References: <0MKp8S-1ItAsT0w6V-00063J@mrelay.perfora.net> In-Reply-To: <0MKp8S-1ItAsT0w6V-00063J@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071117-0, 17/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: dhcwg@ietf.org, 'Internet Area' X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org (I have a certain oppinion on DHCPAuthentication vs PANA as well but it seems many things have been already told.) Alper Yegin wrote: [...] >> This is one thing I would love to learn I am wrong about, please >> name a provider doing residential IPv6 over DSL. > > NTT. Since 2001. NERIM in France since about 2003. But Alper - can you cite how NTT is doing it? How many customers? How many addresses delivered to customer? What kind of addresses are delivered? What transition mechanism? I can for NERIM. I'm talking from a 2001 experience of actually picking up the phone and calling NTT and asking them for IPv6 access. All these things are important in order to really answer the question raised above. It may all be in that 'residential' keyword. How much 'residential' is a SOHO? What does 'residential' really mean in Japanese? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 18 20:18:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItvHB-0000dI-8H; Sun, 18 Nov 2007 20:18:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItvH9-0000d9-Te; Sun, 18 Nov 2007 20:18:11 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItvH5-0007Hi-IK; Sun, 18 Nov 2007 20:18:11 -0500 Received: from ep_ms5_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JRQ003AOBLWFV@mailout2.samsung.com>; Mon, 19 Nov 2007 10:17:56 +0900 (KST) Received: from ep_spt01 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JRQ00MHCBLVAM@ms5.samsung.com>; Mon, 19 Nov 2007 10:17:55 +0900 (KST) Content-return: prohibited Date: Mon, 19 Nov 2007 01:17:55 +0000 (GMT) From: Heejin Jang To: "Chowdhury, Kuntal" Message-id: <19382159.94931195435075468.JavaMail.weblogic@epml10> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20071119010403102@heejin.jang X-MTR: 20071119010403102@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: ML X-EPHeader: ML X-Spam-Score: -1.2 (-) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: "draft-ietf-mip6-hiopt@tools.ietf.org" , "Bernie Volz \(volz\)" , Dhcwg , Mobile IPv6 Mailing List Subject: [dhcwg] Re: [Mip6] RE: AD review of draft-ietf-mip6-hiopt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0640471357==" Errors-To: dhcwg-bounces@ietf.org --===============0640471357== Content-return: prohibited Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 SGksIEt1bnRhbC4gDQoNCk5vLCBoZSBkaWRuJ3QuIA0KQWJvdXQgdGhlIGlkLXR5cGUsIGhlIHNl ZW1zIHRvIHRoaW5rIHRoYXQgJ3RoZSBpZC10eXBlJyBpcyB1bm5lY2Vzc2FyeSwgYW5kIHdoaWNo IG1ha2VzIHRoZSBwcm90b2NvbCBjb21wbGljYXRlZC4NCg0KLS0tLS0tLS0tLSBBRCdzIGNvbW1l bnQgLS0tLS0tLS0tLS0tLQ0KPj4+ICAgICAgICAgaWQtdHlwZQ0KPj4+ICAgICAgICAgICAgVGhl IHR5cGUgb2YgSG9tZSBOZXR3b3JrIElkZW50aWZpZXI6DQo+Pj4gICAgICAgICAgICAgICAgMCAg ICBWaXNpdGVkIGRvbWFpbiAobG9jYWwgQVNQKQ0KPj4+ICAgICAgICAgICAgICAgIDEgICAgVGFy Z2V0IE1TUA0KPj4+ICAgICAgICAgICAgICAgIDIgICAgTm8gcHJlZmVyZW5jZQ0KIA0KPj4gVGhp cyBzZWVtcyB1bm5lY2Vzc2FyaWx5IGNvbXBsaWNhdGVkLiBJcyB0aGVyZSBzb21lIHJlYXNvbiB3 aHkgeW91IA0KPj5jb3VsZCBzaW1wbHkgaW5jbHVkZSB0aGUgdGFyZ2V0IE1TUCBkb21haW4gaW5m b3JtYXRpb24gaWYgaXQgaXMga25vd24gDQo+PiBvciBhbiBlbXB0eSBzdHJpbmcgb3RoZXJ3aXNl IGFuZCBiZSBhbGxvY2F0ZWQgYSBsb2NhbCBBU1AgaW4gdGhhdCBjYXNlPyAgDQogDQo+SSBzdGls bCBkaXNhZ3JlZSB0aGF0IHRoaXMgaXMgbmVlZGVkLCBidXQgSSdtIG5vdCBtYWtpbmcgdGhpcyBh IGJsb2NraW5nIGNvbW1lbnQgaWYgdGhlIFdHIHdhbnRzIHRvIGRvIGl0LiANCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogSWYgICJubyBwcmVmZXJlbmNl IiBpcyBzdGlsbCBuZWVkZWQvdXNlZCBieSBzb21lIG90aGVyIFNETyAoZm9yIDNHUFAyID8pLCB3 ZSBuZWVkIHRvIGFyZ3VlIGl0Lg0KT3RoZXJ3aXNlLCB3ZSdkIHJhdGhlciByZW1vdmUgaXQgaW4g dGhlIGRyYWZ0Lg0KS2luZGx5IGxldCBtZSBrbm93IHlvdXIgb3Bpbmlvbi4gDQogDQotIEJlc3Qg UmVnYXJkcywgDQpIZWVqaW4NCg0KIA0KDQotLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0t LQ0KU2VuZGVyIDogQ2hvd2RodXJ5LCBLdW50YWw8a2Nob3dkaHVyeUBzdGFyZW50bmV0d29ya3Mu Y29tPg0KRGF0ZSAgIDogMjAwNy0xMS0xMCAwMTowOCAoR01UKzA5OjAwKQ0KVGl0bGUgIDogW01p cDZdIFJFOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1taXA2LWhpb3B0DQoNCkRlYXIgQmVybmll LA0KDQpMZXQgbWUgdHJ5IHRvIGFkZHJlc3Mgc29tZSBvZiB5b3VyIGNvbW1lbnRzL3F1ZXN0aW9u cy4gUGxlYXNlIHNlZQ0KaW5saW5lLi4uDQoNCkJSLA0KS3VudGFsDQoNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZXJuaWUgVm9seiAodm9seikgW21haWx0bzp2b2x6 QGNpc2NvLmNvbV0NCj4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciAwOSwgMjAwNyA4OjM3IEFNDQo+ IFRvOiBKYXJpIEFya2tvOyBkcmFmdC1pZXRmLW1pcDYtaGlvcHRAdG9vbHMuaWV0Zi5vcmcNCj4g Q2M6IE1vYmlsZSBJUHY2IE1haWxpbmcgTGlzdDsgRGhjd2cNCj4gU3ViamVjdDogUkU6IEFEIHJl dmlldyBvZiBkcmFmdC1pZXRmLW1pcDYtaGlvcHQNCj4gDQo+IEkgZGlkIHJldmlldyBhIHJlY2Vu dCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCAtIEkmIzM5O20gbm90IHN1cmUgd2hpY2gNCnJldmlzaW9u DQo+IGlzIG5vdyB0aGUgbGF0ZXN0LiBTZWUgdGhlIGF0dGFjaGVkIGVtYWlsIHJlZ2FyZGluZyBt eSBtb3N0IHJlY2VudCBzZXQNCj4gb2YgY29tbWVudHMuDQo+IA0KPiAtIEJlcm5pZQ0KPiANCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmFyaSBBcmtrbyBbbWFpbHRvOmph cmkuYXJra29AcGl1aGEubmV0XQ0KPiBTZW50OiBGcmlkYXksIE5vdmVtYmVyIDA5LCAyMDA3IDk6 MDIgQU0NCj4gVG86IGRyYWZ0LWlldGYtbWlwNi1oaW9wdEB0b29scy5pZXRmLm9yZzsgQmVybmll IFZvbHogKHZvbHopDQo+IENjOiBNb2JpbGUgSVB2NiBNYWlsaW5nIExpc3Q7IERoY3dnDQo+IFN1 YmplY3Q6IFJlOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1taXA2LWhpb3B0DQo+IA0KPiBIaSBh bGwsDQo+IA0KPiBJIGhhdmUgcmV2aWV3ZWQgdGhlIG5ldyB2ZXJzaW9uIGFuZCBpdCBzYXRpc2Zp ZXMgbXkgQUQgcmV2aWV3DQo+IGNvbmNlcm5zIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiB0aGUgYmVs b3cgbWlub3IgaXNzdWVzLg0KPiANCj4gQWxzbywgSSBleHBlY3QgdGhhdCB0aGUgZHJhZnQgYWxz byBoYXMgdG8gc2F0aXNmeSBESEMgV0cmIzM5O3MgcmV2aWV3LA0KPiBhbmQgYWRkcmVzcyB0aGUg aXNzdWVzIHJhaXNlZCBieSBCZXJuaWUuIEkgaGF2ZSBub3QgbG9va2VkDQo+IGF0IHRob3NlIHll dCwgQmVybmllIGhhdmUgeW91Pw0KPiANCj4gPj4gICAgICAgICBpZC10eXBlDQo+ID4+DQo+ID4+ ICAgICAgICAgICAgVGhlIHR5cGUgb2YgSG9tZSBOZXR3b3JrIElkZW50aWZpZXI6DQo+ID4+DQo+ ID4+ICAgICAgICAgICAgICAgIDAgICAgVmlzaXRlZCBkb21haW4gKGxvY2FsIEFTUCkNCj4gPj4N Cj4gPj4gICAgICAgICAgICAgICAgMSAgICBUYXJnZXQgTVNQDQo+ID4+DQo+ID4+ICAgICAgICAg ICAgICAgIDIgICAgTm8gcHJlZmVyZW5jZQ0KPiA+Pg0KPiA+DQo+ID4gVGhpcyBzZWVtcyB1bm5l Y2Vzc2FyaWx5IGNvbXBsaWNhdGVkLiBJcyB0aGVyZSBzb21lIHJlYXNvbiB3aHkgeW91DQo+IGNv dWxkDQo+ID4gc2ltcGx5IGluY2x1ZGUgdGhlIHRhcmdldCBNU1AgZG9tYWluIGluZm9ybWF0aW9u IGlmIGl0IGlzIGtub3duIG9yDQphbg0KPiA+IGVtcHR5IHN0cmluZyBvdGhlcndpc2UgYW5kIGJl IGFsbG9jYXRlZCBhIGxvY2FsIEFTUCBpbiB0aGF0IGNhc2U/DQo+ID4NCj4gDQpbS0M+XSBFbXB0 eSBzdHJpbmcgdy9vIHRoaXMgaWQtdHlwZSBpbmRpY2F0aW9uIHdpbGwgYmUgYW1iaWd1b3VzIHNp bmNlDQppdCB3b24mIzM5O3QgY29udmV5IHRoZSBjYXNlIGZvciB2YWx1ZSAyIChubyBwcmVmZXJl bmNlKS4gTm8gcHJlZmVyZW5jZSBpcyBhDQpjb21tb24gd2F5IGZvciB0aGUgTU4gdG8gY29udmV5 IHRvIHRoZSBuZXR3b3JrIHRoYXQgaXQgZG9lcyBub3QgcmVhbGx5DQpoYXZlIGEgcHJlZmVyZW5j ZSBmb3IgdGhlIGRvbWFpbiBmcm9tIHdoaWNoIGl0IHdhbnRzIHRvIGJvb3RzdHJhcCBNSVA2DQpp bmZvLg0KDQoNCj4gSSBzdGlsbCBkaXNhZ3JlZSB0aGF0IHRoaXMgaXMgbmVlZGVkLCBidXQgSSYj Mzk7bSBub3QgbWFraW5nIHRoaXMNCj4gYSBibG9ja2luZyBjb21tZW50IGlmIHRoZSBXRyB3YW50 cyB0byBkbyBpdC4NCj4NCj4gPj4gMy4yLiAgTUlQNiBSZWxheSBBZ2VudCBPcHRpb24NCj4gPj4N Cj4gPj4gICAgVGhpcyBvcHRpb24gY2FycmllcyB0aGUgUkFESVVTIG9yIERpYW1ldGVyIGF0dHJp YnV0ZXMgdGhhdCBhcmUNCj4gPj4gICAgcmVjZWl2ZWQgYXQgdGhlIE5BUyBmcm9tIHRoZSBBQUFI LiAgVGhlIERIQ1AgcmVsYXkgYWdlbnQgc2VuZHMNCj4gdGhpcw0KPiA+PiAgICBvcHRpb24gdG8g dGhlIERIQ1Agc2VydmVyIGluIHRoZSBSZWxheS1Gb3J3YXJkIG1lc3NhZ2UuDQo+ID4+DQo+ID4g SXQgZG9lcyBub3QgY2FycnkgUkFESVVTIG9yIERpYW1ldGVyIGF0dHJpYnV0ZXMgKGFuZCBub3Ig c2hvdWxkIGl0KS4NCj4gPiBQbGVhc2UgYWxpZ24gdGhpcyB0ZXh0IHdpdGggdGhlIGFjdHVhbCBz dWJhdHRyaWJ1dGVzIHRoYXQgeW91IGhhdmUuDQo+ID4NCj4gPiBBbHNvLCBpdCBpcyBpbmFwcHJv cHJpYXRlIHRvIGFzc3VtZSB0aGF0IHRoZSBpbmZvcm1hdGlvbiBjYW4gb25seQ0KY29tZQ0KPiA+ IGZyb20gQUFBLiBQcmVzdW1hYmx5IHdlJiMzOTtkIGxpa2UgdGhlIG1lY2hhbmlzbXMgdG8gYmUg Z2VuZXJhbCBlbm91Z2gNCj4gdGhhdCwNCj4gPiBmb3IgaW5zdGFuY2UsIG1hbnVhbCBjb25maWd1 cmF0aW9uLCBsaW5rIGlkZW50aWZpZXIsIGV0Yy4gY291bGQgYWxzbw0KPiBiZQ0KPiA+IHVzZWQg dG8gZGV0ZXJtaW5lIHdoYXQgbW9iaWxpdHkgZG9tYWlucyBhcmUgYXBwcm9wcmlhdGUgZm9yIHRo aXMNCj4gY2xpZW50Lg0KPiA+DQo+IA0KPiBUZXh0IHdhcyBjaGFuZ2VkLCBidXQgaXQgc3RpbGwg YXNzdW1lcyB0aGUgZGF0YSBjb21lcyBmcm9tIEFBQUggb25seS4NCj4gU3VnZ2VzdGVkIGVkaXQ6 DQo+IA0KW0tDPl0gVGhlIHRleHQgc2F5cyAidGhlIE5BUyBfbWF5XyBrbm93IHRoaXMuLi4uIi4g VGhlcmVmb3JlLCBvdGhlciB3YXlzDQphcmUgYWxsb3dlZCB0b28sIGJ1dCBub3RoaW5nIHdyb25n IGluIGdpdmluZyBhbiBleGFtcGxlLCBJTUhPLg0KDQoNCj4gT0xEOg0KPiAgICBUaGlzIG9wdGlv biBjYXJyaWVzIHRoZSBob21lIG5ldHdvcmsgaW5mb3JtYXRpb24gd2hpY2ggd2FzDQo+ICAgIHRy YW5zZmVycmVkIHRvIHRoZSBOQVMgZnJvbSBBQUFIIGJ5IHVzaW5nIFtJLUQuaWV0Zi1taXA2LXJh ZGl1c10uDQo+IE5FVzoNCj4gICAgVGhpcyBvcHRpb24gY2FycmllcyB0aGUgaG9tZSBuZXR3b3Jr IGluZm9ybWF0aW9uIGZvciB0aGUgbW9iaWxlDQo+ICAgIG5vZGUgKHRoZSBOQVMgbWF5IGtub3cg dGhpcywgZm9yIGluc3RhbmNlLCB0aHJvdWdoIEFBQSBieQ0KPiAgICB1c2luZyBbSS1ELmlldGYt bWlwNi1yYWRpdXNdKS4NCj4gDQo+ID4+ICAgICAgICAgICAgT1BUSU9OX01JUDYtSE5JRCAoVEJE KQ0KPiA+Pg0KPiA+IERvIHlvdSByZWFsbHkgaGF2ZSB0byBtaXggdW5kZXJzY29yZSBhbmQgZGFz aCBpbiB0aGUgc2FtZSBzeW1ib2w/DQo+ID4NCj4gDQo+IFNvbWUgb2YgdGhpcyBzdGlsbCByZW1h aW5zOiBPUFRJT05fTUlQNi1ITklORiAoVEJEKS4NCj4gDQpbS0M+XSBXZSBzaG91bGQgZml4IHRo ZXNlIGluY29uc2lzdGVuY2llcy4NCg0KDQo+IEphcmkNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCk1pcDYgbWFpbGluZyBsaXN0DQpNaXA2QGlldGYu b3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taXA2DQoNCg0K --===============0640471357== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0640471357==-- From dhcwg-bounces@ietf.org Sun Nov 18 23:02:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItxpW-00069N-KE; Sun, 18 Nov 2007 23:01:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItxpW-00069H-6u for dhcwg@ietf.org; Sun, 18 Nov 2007 23:01:50 -0500 Received: from mx05.gis.net ([208.218.130.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItxpS-0004YV-UU for dhcwg@ietf.org; Sun, 18 Nov 2007 23:01:50 -0500 Received: from [10.10.10.100] ([63.209.224.211]) by mx05.gis.net; Sun, 18 Nov 2007 23:01:28 -0500 Message-ID: <474109FB.2080508@ntp.org> Date: Sun, 18 Nov 2007 22:58:51 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Brian Utterback Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> In-Reply-To: <4735A243.6090905@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Brian Utterback wrote: > Benoit Lourdelet (blourdel) wrote: >> Considering a central DHCP server, the use of remote-id [RFC4649] or >> just link-id may tell the server from where the request is coming then >> giving it the knowledge of the delay to >> apply. >> In the case of a DHCP server hosted by the first hop, the DHCP server is >> well positioned to know the delay. > > Oh, agreed, it is possible for the delay to be known. I consider that it is most unlikely for the DHCP server to know the delay. Consider DHCP server D, client C and NTP server N. Each are in different locations on the physical wire (wireless and other medium are similar). D may know its own delay to N but C is elsewhere on the wire. You might be able to figure out the delay between D and C but how does it relate to the delay between C and N? They are in different locations on the wire. Is C closer to N, further away, on another segment of the network? Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 18 23:02:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itxpl-0006DH-Ci; Sun, 18 Nov 2007 23:02:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itxpk-0006Cs-1d for dhcwg@ietf.org; Sun, 18 Nov 2007 23:02:04 -0500 Received: from mx05.gis.net ([208.218.130.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itxph-0004ZM-QZ for dhcwg@ietf.org; Sun, 18 Nov 2007 23:02:04 -0500 Received: from [10.10.10.100] ([63.209.224.211]) by mx05.gis.net; Sun, 18 Nov 2007 23:01:56 -0500 Message-ID: <47410A17.8090503@ntp.org> Date: Sun, 18 Nov 2007 22:59:19 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "David L. Mills" Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> <47368636.3070007@udel.edu> In-Reply-To: <47368636.3070007@udel.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Brian Utterback , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Dave, I don't see how. The DHCP server and the NTP server are different nodes on the network, unless the DHCP server is going to provide the NTP service as well but that's a bad assumption to make even though the DHCP server SHOULD be running NTP, if only for itself. Danny David L. Mills wrote: > Brian, > > We need to think about scenarios for server discovery. Without prejudice > on the message formats, a virgin client might be directed to either: > > 1. Listen for broadcast/multicast on
and do/do not execute a > volley. I like the delay field to enable/disable that and have added it > to ntpd. In principle, the delay can be determined from the DHCP packets > themselves, a feature that might be added. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 18 23:02:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItxpW-00069N-KE; Sun, 18 Nov 2007 23:01:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItxpW-00069H-6u for dhcwg@ietf.org; Sun, 18 Nov 2007 23:01:50 -0500 Received: from mx05.gis.net ([208.218.130.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItxpS-0004YV-UU for dhcwg@ietf.org; Sun, 18 Nov 2007 23:01:50 -0500 Received: from [10.10.10.100] ([63.209.224.211]) by mx05.gis.net; Sun, 18 Nov 2007 23:01:28 -0500 Message-ID: <474109FB.2080508@ntp.org> Date: Sun, 18 Nov 2007 22:58:51 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Brian Utterback Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> In-Reply-To: <4735A243.6090905@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Brian Utterback wrote: > Benoit Lourdelet (blourdel) wrote: >> Considering a central DHCP server, the use of remote-id [RFC4649] or >> just link-id may tell the server from where the request is coming then >> giving it the knowledge of the delay to >> apply. >> In the case of a DHCP server hosted by the first hop, the DHCP server is >> well positioned to know the delay. > > Oh, agreed, it is possible for the delay to be known. I consider that it is most unlikely for the DHCP server to know the delay. Consider DHCP server D, client C and NTP server N. Each are in different locations on the physical wire (wireless and other medium are similar). D may know its own delay to N but C is elsewhere on the wire. You might be able to figure out the delay between D and C but how does it relate to the delay between C and N? They are in different locations on the wire. Is C closer to N, further away, on another segment of the network? Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 18 23:02:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itxpl-0006DH-Ci; Sun, 18 Nov 2007 23:02:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itxpk-0006Cs-1d for dhcwg@ietf.org; Sun, 18 Nov 2007 23:02:04 -0500 Received: from mx05.gis.net ([208.218.130.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itxph-0004ZM-QZ for dhcwg@ietf.org; Sun, 18 Nov 2007 23:02:04 -0500 Received: from [10.10.10.100] ([63.209.224.211]) by mx05.gis.net; Sun, 18 Nov 2007 23:01:56 -0500 Message-ID: <47410A17.8090503@ntp.org> Date: Sun, 18 Nov 2007 22:59:19 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "David L. Mills" Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> <47368636.3070007@udel.edu> In-Reply-To: <47368636.3070007@udel.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Brian Utterback , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Dave, I don't see how. The DHCP server and the NTP server are different nodes on the network, unless the DHCP server is going to provide the NTP service as well but that's a bad assumption to make even though the DHCP server SHOULD be running NTP, if only for itself. Danny David L. Mills wrote: > Brian, > > We need to think about scenarios for server discovery. Without prejudice > on the message formats, a virgin client might be directed to either: > > 1. Listen for broadcast/multicast on
and do/do not execute a > volley. I like the delay field to enable/disable that and have added it > to ntpd. In principle, the delay can be determined from the DHCP packets > themselves, a feature that might be added. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 18 23:02:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itxpg-0006BM-SM; Sun, 18 Nov 2007 23:02:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itxpd-0006AY-6F for dhcwg@ietf.org; Sun, 18 Nov 2007 23:01:57 -0500 Received: from mx05.gis.net ([208.218.130.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itxpa-0004Yy-R8 for dhcwg@ietf.org; Sun, 18 Nov 2007 23:01:57 -0500 Received: from [10.10.10.100] ([63.209.224.211]) by mx05.gis.net; Sun, 18 Nov 2007 23:01:43 -0500 Message-ID: <47410A0A.8000007@ntp.org> Date: Sun, 18 Nov 2007 22:59:06 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Brian Utterback Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> In-Reply-To: <4733482A.7020302@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Brian Utterback wrote: > The multicast looks okay as is, although I would suggest that there be > advice to leave delay as 0 if possible. The proper delay doesn't seem to > me to be likely to be known by the server and possibly different across > a subnet. > No, there's a problem there too. A multicast client by default needs to do authentication. That means that you either provide it a key file (or the contents thereof) or you have to disable authentication in which case you have to accept whatever you receive including rogues. You need to pick one and act accordingly. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 18 23:48:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItyYc-0007Ci-KB; Sun, 18 Nov 2007 23:48:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItyYb-0007Ca-9p for dhcwg@ietf.org; Sun, 18 Nov 2007 23:48:25 -0500 Received: from mx04.gis.net ([208.218.130.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItyYX-0005pW-SP for dhcwg@ietf.org; Sun, 18 Nov 2007 23:48:25 -0500 Received: from [10.10.10.100] ([63.209.224.211]) by mx04.gis.net; Sun, 18 Nov 2007 23:48:00 -0500 Message-ID: <474114E3.9040309@ntp.org> Date: Sun, 18 Nov 2007 23:45:23 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ted Lemon Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> In-Reply-To: <1195185173.26090.4.camel@uma> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , Brian Utterback , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ted Lemon wrote: > On Thu, 2007-11-15 at 19:19 -0800, Danny Mayer wrote: > >> No you should be using a DNS name and not IP addresses. The client >> then can use the DNS to lookup the name and get a bunch of IP >> addresses. The new pool option will then configure all of them >> (up to 10) for NTP servers. >> > > True, but not really important, since the DHCP server is normally > configured with a domain name, not an IP address. So it can do the > lookup and return those ten IP addresses to the client. So you get the > same effect whether you send the FQDN to the client and make it do the > lookup, or do the lookup on the server. The advantage of doing it on > the server is (1) you don't have to send an FQDN, and (2) the client > doesn't need to have a resolver. > > I have no idea what configuring the DHCP server with a domain name has to do with anything. The addresses of NTP servers are not related to domain names. Furthermore by looking up the IP addresses for the client means that the client loses flexibility of being able to do a new lookup when one of those NTP servers stop responding to queries. This capability is not in the currently implementation of the NTP reference implementation but will be there in the next few months. There is *no* avantage to not sending a FQDN and plenty of disadvantages to not doing so. Would you like a list of vendors who have hardcoded IP addresses into their devices without permission of the operator of that NTP server causing headaches for not just the owner of the NTP Server but also for the users of those devices? The NTP reference implementation expects the existence of a resolver so you haven't gained anything. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 00:18:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itz18-0008FK-Ry; Mon, 19 Nov 2007 00:17:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itz17-0008FF-49 for dhcwg@ietf.org; Mon, 19 Nov 2007 00:17:53 -0500 Received: from whimsy.udel.edu ([128.4.2.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itz14-0006rG-C8 for dhcwg@ietf.org; Mon, 19 Nov 2007 00:17:53 -0500 Received: by whimsy.udel.edu (Postfix, from userid 62) id 2A63C16AD; Mon, 19 Nov 2007 05:17:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id BC511164A; Mon, 19 Nov 2007 05:17:34 +0000 (UTC) Message-ID: <47411C6D.1010808@udel.edu> Date: Mon, 19 Nov 2007 05:17:33 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: ntpwg@lists.ntp.org, dhcwg@ietf.org Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> <47368636.3070007@udel.edu> <47410A17.8090503@ntp.org> In-Reply-To: <47410A17.8090503@ntp.org> X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Danny, As I understand it, the DHCP client broadcasts a request to the DHCP server and receives a response. There is an opportunity for the DHCP client to measure the delay, should it be so instrumented. In no way did I intend the DHCP server run NTP for any business but itself. The discussion has left me a little uneasy about the specificy of the message formats to the current NTP implementation. Things like minpoll and maxpoll could be interpreted in context to protect the NTP servers, but in the DHCP environment that probably is not an issue. There is no real need to reveal broadcast mode servers. As long as the client knows the address mask, it can generate the broadcast address to listen on. It doesn't make sense to advertise symmetric modes, as these are usually reserved for serious low-stratum campus servers. This leaves only client/server mode as useful. However, the key ID is important, as the NTP client and server should share the same bag of keys and the client might not know the current server key ID. Some perspective on the issues can be gained from our experience with other discovery schemes like broadcast, manycast and the pool. Broadcast provides the server address (for delay measurements), stratum and key ID. Manycast servers filter the client stratum and respond only if they can provide better time. They also provide the key ID. The pool scheme merely provides the server addresses. In all three schemes the client can filter the responses for acceptable stratum and then cast out the survivors from the population leaving only the best quality survivors. The DHCP discovery scheme needs only to provide comparable statistics. A client can use any combination of these schemes. Dave Danny Mayer wrote: > Dave, > > I don't see how. The DHCP server and the NTP server are different nodes > on the network, unless the DHCP server is going to provide the NTP > service as well but that's a bad assumption to make even though the DHCP > server SHOULD be running NTP, if only for itself. > > Danny > > David L. Mills wrote: > >> Brian, >> >> We need to think about scenarios for server discovery. Without prejudice >> on the message formats, a virgin client might be directed to either: >> >> 1. Listen for broadcast/multicast on
and do/do not execute a >> volley. I like the delay field to enable/disable that and have added it >> to ntpd. In principle, the delay can be determined from the DHCP packets >> themselves, a feature that might be added. >> _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 00:39:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItzLj-0002Su-Gn; Mon, 19 Nov 2007 00:39:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItzLi-0002Rb-Qn for dhcwg@ietf.org; Mon, 19 Nov 2007 00:39:10 -0500 Received: from smtp01.jaxtr.com ([66.231.182.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItzLg-0004ea-HB for dhcwg@ietf.org; Mon, 19 Nov 2007 00:39:08 -0500 Received: from 216.93.183.164 (media1.jaxtr.com [216.93.183.164]) by smtp01.jaxtr.com (Postfix) with ESMTP id 0BDE02D6B69 for ; Mon, 19 Nov 2007 05:39:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=jaxtr.com; s=dkprod1; t=1195450748; bh=O0LLW5BwO0L9Kww1Gpc92DZbVTsjesWUma+cZzzM6uU=; h=DomainKey-Signature:Date:From:Sender:To:Message-ID:Subject: MIME-Version:Content-Type:X-Sysflow; b=Aw2iFePpkskFm5nnwHLy9mupOJW kmLyMxV33O33PXdam/gUjAjIEd4D4xo/H4iSaBv9X+0TGL0P2h/8YmkZVvA== DomainKey-Signature: a=rsa-sha1; s=dkprod1; d=jaxtr.com; c=simple; q=dns; h=date:from:sender:to:message-id:subject:mime-version: content-type:x-sysflow; b=RuTKTkpKkj1hdW7L3Xg/vvsxBOk4K96n7ydBVAOuQII2yuqgkLFCOOEjnGVzrc8AC RXgHuO/WPYm3oO2PTPVWg== Date: Mon, 19 Nov 2007 05:39:07 +0000 (GMT) From: Sandy G To: dhcwg@ietf.org Message-ID: <3992743.1899171195450747485.JavaMail.tomcat@media1.jaxtr.com> MIME-Version: 1.0 X-Sysflow: cq,20071113t0352,dbemfs.46qthd,130528706 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [dhcwg] Link to call me for free X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0097108065==" Errors-To: dhcwg-bounces@ietf.org --===============0097108065== Content-Type: multipart/alternative; boundary="----=_Part_189932_6151317.1195450747481" ------=_Part_189932_6151317.1195450747481 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am using jaxtr, and if you also sign up, we -Sandy P.S. Here is the link to sign up: http://www.jaxtr.com/user/ticket?n=Tuov2239woq9q&type=joininvite --- Delivered by jaxtr, Inc., 855 Oak Grove Avenue, Suite 100, Menlo Park, California 94025. To stop receiving messages from this sender go to http://www.jaxtr.com/user/reportabuse.jsp?it=Tuov2239woq9q ------=_Part_189932_6151317.1195450747481 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

I am using jaxtr, and if you also sign up, we

-Sandy

P.S. Here is the link to sign up:
http://www.jaxtr.com/user/ticket?n=Tuov2239woq9q&type=joininvite

Delivered by jaxtr, Inc., 855 Oak Grove Avenue, Suite 100, Menlo Park, California 94025. Click here to stop receiving messages from this sender. ------=_Part_189932_6151317.1195450747481-- --===============0097108065== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0097108065==-- From dhcwg-bounces@ietf.org Mon Nov 19 01:53:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu0VR-0003ZK-A2; Mon, 19 Nov 2007 01:53:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu0VP-0003Z7-Oy for dhcwg@ietf.org; Mon, 19 Nov 2007 01:53:15 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu0VP-0007SG-E3 for dhcwg@ietf.org; Mon, 19 Nov 2007 01:53:15 -0500 Received: from [192.168.11.2] (cpe-66-69-216-249.austin.res.rr.com [66.69.216.249]) by toccata.fugue.com (Postfix) with ESMTP id 300F5BC443F; Sun, 18 Nov 2007 23:53:14 -0700 (MST) Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 From: Ted Lemon To: Danny Mayer In-Reply-To: <474114E3.9040309@ntp.org> References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> Content-Type: text/plain Date: Mon, 19 Nov 2007 00:53:14 -0600 Message-Id: <1195455194.9159.2.camel@uma> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , Brian Utterback , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Sun, 2007-11-18 at 23:45 -0500, Danny Mayer wrote: > I have no idea what configuring the DHCP server with a domain name has > to do with anything. Yes, I definitely got that impression. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 05:02:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3Sa-0002tu-D2; Mon, 19 Nov 2007 05:02:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3SY-0002tC-ER for dhcwg@ietf.org; Mon, 19 Nov 2007 05:02:30 -0500 Received: from mx.isc.org ([2001:4f8:0:2::1c]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu3SV-000752-Vo for dhcwg@ietf.org; Mon, 19 Nov 2007 05:02:30 -0500 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id C4A1C11401E; Mon, 19 Nov 2007 10:02:26 +0000 (UTC) (envelope-from Shane_Kerr@isc.org) Received: from [199.6.1.234] (unknown [199.6.1.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 11908E6056; Mon, 19 Nov 2007 10:02:25 +0000 (UTC) (envelope-from shane@isc.org) Message-ID: <47415F29.1080903@isc.org> Date: Mon, 19 Nov 2007 11:02:17 +0100 From: Shane Kerr Organization: ISC User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: Hui Deng Subject: Re: [dhcwg] Fwd: I-D ACTION:draft-deng-dhc-service-identifiers-00.txt References: <1d38a3350711152313s49656e90yab73b1a21d21d396@mail.gmail.com> <473D5620.4090009@isc.org> <1d38a3350711161738m2e6f83b9q7c925feac9f21624@mail.gmail.com> In-Reply-To: <1d38a3350711161738m2e6f83b9q7c925feac9f21624@mail.gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shane_kerr@isc.org List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hui Deng wrote: > Hi, Shane, > > Thanks for your comments, reply as below, > >> Interesting idea, but it's not clear to me what it means when a service is >> advertised. For instance, if I advertise "ntp", does that mean that the local >> network has a reachable NTP server, or that the network allows port 123 traffic >> through it's firewall, or what? > > I guess for some operator, they would like to say they allow such kind of > port 123 traffic, for others operator, > this draft could be extended to show there is a reachable NTP server. Clients need to be able to know exactly what the server means when it sends a service identifier. Also, if you are going to be sending lists of ports that are open, perhaps it makes more sense to send those, instead of giving service names. Clients will need to know how these ports are handled. I think the draft needs more work before wider consideration. - -- Shane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQV8lMsfZxBO4kbQRAgWKAJ9Z3wUuaBQ11Hgv3fzHtAifZ6OyVQCeOrls 9ZylQ5krx74pyGgBO9TyKk0= =v08B -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 07:27:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu5j9-0002qn-Rm; Mon, 19 Nov 2007 07:27:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu5j4-0002iv-Ss; Mon, 19 Nov 2007 07:27:42 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu5j0-0005PH-6m; Mon, 19 Nov 2007 07:27:42 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BC1F020FCC; Mon, 19 Nov 2007 13:27:37 +0100 (CET) X-AuditID: c1b4fb3e-af032bb0000007e1-c4-474181399f53 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ACD7820FC9; Mon, 19 Nov 2007 13:27:37 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 13:27:37 +0100 Received: from [147.214.22.209] ([147.214.22.209]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 13:27:36 +0100 Message-ID: <47418138.2090307@levkowetz.com> Date: Mon, 19 Nov 2007 13:27:36 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: McCann Peter-A001034 References: <7CCD07160348804497EF29E9EA5560D7024DA3E6@exchtewks2.starentnetworks.com> <0C0F76B1-96EA-4600-BC1F-EEB91D46CE4C@cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2007 12:27:36.0963 (UTC) FILETIME=[9188DD30:01C82AA7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: dhcwg@ietf.org, mip4@ietf.org, Ralph Droms Subject: [dhcwg] Re: [Mip4] draft-ietf-mip4-gen-ext-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi Ralph and all, I have only one small comment regarding Pete's excellent exposition, inline below: On 2007-11-15 21:24 McCann Peter-A001034 said the following: > Hi, Ralph, ... > When reverse tunneling ala RFC 3024 is used (as it is in most > major deployments of MIP), the MN has a choice about whether > to negotiate "encapsulated delivery style" on the last hop > link. It must negotiate this if it wants to send broadcast > datagrams (of which I think the DHCPDISCOVER is one) to the > home network. In this case, an FA will look at each packet, > and reverse tunnel the ones that are so encapsulated and send > other packets directly. The problem I was trying to point > out is that this extra encapsulation would be present on > every packet sent to the home network, which might cause > a lot of overhead on the link between the MN and FA. If > this is a wireless link, this overhead is especially onerous. Note, though, that there is currently a proposal in draft-chakrabarti-mip4-mcbc-01 which if pursued will remove the extra encapsulation on all packets: http://www.tools.ietf.org/html/draft-chakrabarti-mip4-mcbc-01 > Please post if you have any remaining questions or if I > have misunderstood the DHCP message flow. Regards, Henrik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 08:55:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu75a-0003GT-HR; Mon, 19 Nov 2007 08:55:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu75Z-0003FF-1p for dhcwg@ietf.org; Mon, 19 Nov 2007 08:55:01 -0500 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu75Y-0000rV-D9 for dhcwg@ietf.org; Mon, 19 Nov 2007 08:55:00 -0500 Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAJDsxbu007325; Mon, 19 Nov 2007 13:54:59 GMT Received: from [129.148.226.18] (sr1-unsh01-06.East.Sun.COM [129.148.226.18]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lAJDsvtW030995; Mon, 19 Nov 2007 08:54:58 -0500 (EST) Message-ID: <474195B1.5030108@sun.com> Date: Mon, 19 Nov 2007 08:54:57 -0500 From: Brian Utterback User-Agent: Thunderbird 2.0.0.7pre (X11/20071110) MIME-Version: 1.0 To: Danny Mayer Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> <474109FB.2080508@ntp.org> In-Reply-To: <474109FB.2080508@ntp.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Danny Mayer wrote: > Brian Utterback wrote: >> Benoit Lourdelet (blourdel) wrote: >>> Considering a central DHCP server, the use of remote-id [RFC4649] or >>> just link-id may tell the server from where the request is coming then >>> giving it the knowledge of the delay to >>> apply. >>> In the case of a DHCP server hosted by the first hop, the DHCP server is >>> well positioned to know the delay. >> Oh, agreed, it is possible for the delay to be known. > > I consider that it is most unlikely for the DHCP server to know the > delay. Consider DHCP server D, client C and NTP server N. Each are in > different locations on the physical wire (wireless and other medium are > similar). D may know its own delay to N but C is elsewhere on the > wire. You might be able to figure out the delay between D and C but how > does it relate to the delay between C and N? They are in different > locations on the wire. Is C closer to N, further away, on another > segment of the network? Also, agreed. One can imagine a setup where the DHCP server has been configured with the correct broadcast delay for every subnet that it serves. However, I consider that this is a very rare occurrence and very error prone. Why bother? Just let the client do the volley and have done with it. So I agree with you in general, Danny. Having a broadcast delay served from the DHCP server is usually going to be a bad idea. -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 09:08:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7I9-0003bT-PE; Mon, 19 Nov 2007 09:08:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7I9-0003bK-2Q for dhcwg@ietf.org; Mon, 19 Nov 2007 09:08:01 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu7I8-0002HY-8q for dhcwg@ietf.org; Mon, 19 Nov 2007 09:08:00 -0500 Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAJE7ubk021460; Mon, 19 Nov 2007 14:07:56 GMT Received: from [129.148.226.18] (sr1-unsh01-06.East.Sun.COM [129.148.226.18]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lAJE7t1W035120; Mon, 19 Nov 2007 09:07:55 -0500 (EST) Message-ID: <474198BA.3000109@sun.com> Date: Mon, 19 Nov 2007 09:07:54 -0500 From: Brian Utterback User-Agent: Thunderbird 2.0.0.7pre (X11/20071110) MIME-Version: 1.0 To: Danny Mayer Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> In-Reply-To: <474114E3.9040309@ntp.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Danny Mayer wrote: > There is *no* avantage to not sending a FQDN and plenty of disadvantages > to not doing so. > Would you like a list of vendors who have hardcoded IP addresses into > their devices without > permission of the operator of that NTP server causing headaches for not > just the owner of the > NTP Server but also for the users of those devices? The NTP reference > implementation expects > the existence of a resolver so you haven't gained anything. > As already noted, there is an advantage, namely that the client does not have to have a resolver. And even if the reference implementation requires one (Is that really true? Even if no name resolution is required?) DHCP should remain implementation agnostic. As far the "hard coded address" problem goes, I don't see that scenario as very likely. DHCP clients don't tend to remain up for very long periods. And you don't have the same IP addresses being served by thousands of DHCP servers. The thing to be careful of is that the DHCP server not be embedded and replicated with hard coded addresses, not that the clients only get IP addresses. That having been said, I would like to see a way to pass a FQDN as an option, perhaps passing both. Then you could have logic like "Here's both, use the name if you can, and use the address if you must." -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 09:43:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7px-0004vr-Ko; Mon, 19 Nov 2007 09:42:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7pw-0004vj-Ls for dhcwg@ietf.org; Mon, 19 Nov 2007 09:42:56 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu7ps-00062P-Vz for dhcwg@ietf.org; Mon, 19 Nov 2007 09:42:56 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Nov 2007 09:42:53 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAJEgq19002228; Mon, 19 Nov 2007 09:42:52 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAJEgDWH005699; Mon, 19 Nov 2007 14:42:50 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 09:42:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc WG meeting in Vancouver Date: Mon, 19 Nov 2007 09:42:31 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210592C987@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG meeting in Vancouver Thread-Index: AcgpP2nbbZqmYPMlTv+LWxGCXvtU9gBepGoA From: "Bernie Volz (volz)" To: "Ralph Droms (rdroms)" X-OriginalArrivalTime: 19 Nov 2007 14:42:38.0869 (UTC) FILETIME=[6EA59C50:01C82ABA] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15554.002 X-TM-AS-Result: No--28.763700-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4072; t=1195483372; x=1196347372; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhc=20WG=20meeting=20in=20Vancouver |Sender:=20 |To:=20=22Ralph=20Droms=20(rdroms)=22=20; bh=TIP5dCBKMyzrdoQx2lJmM0XBzfxRmIQOTaXixIQ+V5Y=; b=rtVpM3lag7ae6WgsRgHrywX69lT0VQbJPdse2jYbjRrPTLULnBNRJHyCJo5aJJrL0jlUiaAC gPg2eYKiStXOt1eCIKfNiEJRyXT8UMEa6D+JIQZDnRwhL8Ix6leW1KQf; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: dhcwg@ietf.org, Dhc Chairs X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org The only action items remaining are to update the IANA registry with the current status, which is what this draft was attempting to do. 128 PXE - undefined (vendor specific) [RFC4578] 129 PXE - undefined (vendor specific) [RFC4578] 130 PXE - undefined (vendor specific) [RFC4578] 131 PXE - undefined (vendor specific) [RFC4578] 132 PXE - undefined (vendor specific) [RFC4578] 133 PXE - undefined (vendor specific) [RFC4578] 134 PXE - undefined (vendor specific) [RFC4578] 135 PXE - undefined (vendor specific) [RFC4578] 150 TFTP server address (Tentatively Assigned - 23 Jun 2005 - DRAFT-RAJ-DHC-TFTP-ADDR-OPTION-01.TXT) 175-177 Unassigned [RFC3942] 208 pxelinux.magic (string) =3D F1:00:74:7E (241.0.116.126) = (Tentatively Assigned - 23 Jun 2005 - DRAFT-IETF-DHC-PXELINUX-01.TXT) 209 pxelinux.configfile (text) (Tentatively Assigned - 23 Jun 2005 - DRAFT-IETF-DHC-PXELINUX-01.TXT) 210 pxelinux.pathprefix (text) (Tentatively Assigned - 23 Jun 2005 - DRAFT-IETF-DHC-PXELINUX-01.TXT) 211 pxelinux.reboottime (unsigned integer 32 bits) (Tentatively Assigned - 23 Jun 2005 - DRAFT-IETF-DHC-PXELINUX-01.TXT) 220 Subnet Allocation Option (Tentatively Assigned - 23 Jun 2005 - DRAFT-IETF-DHC-SUBNET-ALLOC-04.TXT) 221 Virtual Subnet Selection Option (Tentatively Assigned - 23 Jun 2005 - DRAFT-IETF-DHC-VPN-OPTION-06.TXT) The above list is changed slightly because 208-211 are covered by the soon to be published RFC-ietf-dhc-pxelinux-03.txt and there have been some revisions to the other documents to get them through WG last call. - Bernie -----Original Message----- From: Ralph Droms (rdroms)=20 Sent: Saturday, November 17, 2007 12:28 PM To: Bernie Volz (volz) Cc: dhcwg@ietf.org; Dhc Chairs Subject: Re: [dhcwg] dhc WG meeting in Vancouver Bernie - are there any action items remaining from RFC 3942? Might =20 be good to (a) update draft-volz-dhc-3942-status-00 (although I =20 regret I'm responding too late for you to make the draft pub =20 deadline) and (b) publish a final doc when everything from RFC 3942 =20 is wrapped up to capture that the issues have all been closed. - Ralph On Nov 8, 2007, at Nov 8, 2007,11:30 PM, Bernie Volz (volz) wrote: > I'd like to discuss what should be done about > draft-volz-dhc-3942-status-00. It has expired and while I could simply > make a few edits (such as addressing 208-211) and resubmit, it seems > silly to do that if there is no support or interest for the DHC WG. > > I did ask the DHC WG in early October about next steps for this draft, > but it didn't go anywhere. > > We need to give IANA information about updating the DHCP options > registry. > > - Bernie > > -----Original Message----- > From: Ralph Droms (rdroms) > Sent: Thursday, November 08, 2007 11:36 AM > To: dhcwg@ietf.org > Cc: Dhc Chairs > Subject: [dhcwg] dhc WG meeting in Vancouver > > The dhc WG will meet in Vancouver, http://ietf.org/meetings/70- > IETF.html; here is the tentative scheduled date and time for our > meeting: > > TUESDAY, December 4, 2007 > 1300-1500 Afternoon Session I > Salon 1 INT dhc Dynamic Host Configuration WG > > Please contact the WG chairs, dhc-chairs@tools.ietf.org, with agenda > requests before Wed, Nov 14. > > As always, we are looking for volunteers to act as meeting and Jabber > scribes. > > Here are some important dates: http://ietf.org/meetings/70- > cutoff_dates.html Note that the I-D rev -00 submission deadline is > 0900 EST this coming Mon, 11/12, and the general I-D submission > deadline is 0900 EST Mon, 11/19. > > - Ralph > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 09:58:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu84y-0004bb-Kz; Mon, 19 Nov 2007 09:58:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu84x-0004bS-Dy for dhcwg@ietf.org; Mon, 19 Nov 2007 09:58:27 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu84x-0005RV-3q for dhcwg@ietf.org; Mon, 19 Nov 2007 09:58:27 -0500 Received: from [192.168.11.2] (cpe-66-69-216-249.austin.res.rr.com [66.69.216.249]) by toccata.fugue.com (Postfix) with ESMTP id DFAD3BC4473; Mon, 19 Nov 2007 07:58:25 -0700 (MST) Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 From: Ted Lemon To: Brian Utterback In-Reply-To: <474198BA.3000109@sun.com> References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> Content-Type: text/plain Date: Mon, 19 Nov 2007 08:58:26 -0600 Message-Id: <1195484306.9159.13.camel@uma> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "ntpwg@lists.ntp.org" , "Richard Gayraud \(rgayraud\)" , "dhcwg@ietf.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Mon, 2007-11-19 at 09:07 -0500, Brian Utterback wrote: > That having been said, I would like to see a way to pass a FQDN > as an option, perhaps passing both. Then you could have logic > like "Here's both, use the name if you can, and use the address if > you must." An option in a protocol that produces no different behavior is just an opportunity for interoperability problems. This is actually an old discussion. Danny's position isn't unheard of, but the fact is that there's really no way in which this option is different from the other fifty options that tell DHCP clients how to contact servers. There's no reason why this option should use FQDNs while the other fifty use IP addresses, and there are a number of good reasons not to send FQDNs, the first and most obvious of which is that they take up more space in the packet, and space in the packet is very limited. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 10:17:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8N8-0001cf-0V; Mon, 19 Nov 2007 10:17:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8N7-0001cS-2Z for dhcwg@ietf.org; Mon, 19 Nov 2007 10:17:13 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu8N6-00071X-Lq for dhcwg@ietf.org; Mon, 19 Nov 2007 10:17:12 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1296837rvb for ; Mon, 19 Nov 2007 07:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=lxbcQFHhdW1L5vLgofFwumzANi0lTvZ8pekXNOduMI8=; b=UlzGG5XKIYHo1i7qCfJkYFCKNmviAjALwxTNFbjM7j9j9MslzQxD7F1RBD6vCIIoFgDMXqKfpZJVWT+qK8qvDVJAmX1gYf2602Tv9W/ZKojWd52QNFdxbBHewTJLBw1NxwdsWhwmOUchRl9H58kfAG7jha35yNhLI32Af+nax7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=e71hG8KD/mKOSkCEQ5pEYmZ4HsfCb4CL6gQ53auyE8bHWQMeAe9Mje6kIXKw38TYp0PTiACOAO4UppoUb89ENlTVeMJ5T/qRaqC3K+kOMYrpVY9qFiBDKbZlUPEPxTnkbQZ51b+xoltfdsvJhLa3+AZUHtXyV65X4dKaeEl7+oM= Received: by 10.141.99.4 with SMTP id b4mr2082306rvm.1195485431969; Mon, 19 Nov 2007 07:17:11 -0800 (PST) Received: by 10.140.177.17 with HTTP; Mon, 19 Nov 2007 07:17:11 -0800 (PST) Message-ID: <1d38a3350711190717i5b9122aana6d3cdff30d10222@mail.gmail.com> Date: Mon, 19 Nov 2007 23:17:11 +0800 From: "Hui Deng" To: shane_kerr@isc.org Subject: Re: [dhcwg] Fwd: I-D ACTION:draft-deng-dhc-service-identifiers-00.txt In-Reply-To: <47415F29.1080903@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1d38a3350711152313s49656e90yab73b1a21d21d396@mail.gmail.com> <473D5620.4090009@isc.org> <1d38a3350711161738m2e6f83b9q7c925feac9f21624@mail.gmail.com> <47415F29.1080903@isc.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi, Shane, Thanks for the discussion, see below reply. 2007/11/19, Shane Kerr : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hui Deng wrote: > > Hi, Shane, > > > > Thanks for your comments, reply as below, > > > >> Interesting idea, but it's not clear to me what it means when a service is > >> advertised. For instance, if I advertise "ntp", does that mean that the local > >> network has a reachable NTP server, or that the network allows port 123 traffic > >> through it's firewall, or what? > > > > I guess for some operator, they would like to say they allow such kind of > > port 123 traffic, for others operator, > > this draft could be extended to show there is a reachable NTP server. > > Clients need to be able to know exactly what the server means when it sends a > service identifier. As you said here, client does need to know what exactly means of it, Software cooperation work between client and server is mandatory to support this function. > Also, if you are going to be sending lists of ports that are open, perhaps it > makes more sense to send those, instead of giving service names. Clients will > need to know how these ports are handled. I guess that here really need deep discussion. some time service are dynamically negotiate the port number, you remind us here like whether we also need consider the port number range information shall be advertised or not. really thanks for your comments. -Hui > I think the draft needs more work before wider consideration. We appreciate the comments which could help to progress it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 11:42:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu9hZ-0003gm-HO; Mon, 19 Nov 2007 11:42:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu9hX-0003ge-Vi for dhcwg@ietf.org; Mon, 19 Nov 2007 11:42:23 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu9hU-0007nf-Iy for dhcwg@ietf.org; Mon, 19 Nov 2007 11:42:23 -0500 X-IronPort-AV: E=Sophos;i="4.21,437,1188770400"; d="scan'208";a="158164569" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2007 17:42:20 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAJGgJ8p004718; Mon, 19 Nov 2007 17:42:19 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAJGg6Um023019; Mon, 19 Nov 2007 16:42:11 GMT Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 17:42:06 +0100 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 Subject: RE: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Optionsfor DHCPv6 Date: Mon, 19 Nov 2007 17:43:17 +0100 Message-ID: In-Reply-To: <1195484306.9159.13.camel@uma> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Optionsfor DHCPv6 Thread-Index: AcgqvKhi+fNjIHtPQSikkuqS+aEQ3QADk33Q References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> From: "Benoit Lourdelet (blourdel)" To: "Ted Lemon" , "Brian Utterback" X-OriginalArrivalTime: 19 Nov 2007 16:42:06.0295 (UTC) FILETIME=[1EC40670:01C82ACB] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15554.001 X-TM-AS-Result: No--16.596200-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1566; t=1195490539; x=1196354539; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=blourdel@cisco.com; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Re=3A=20[ntpwg]=20Network=20Time=20Protocol =20(NTP)=20Optionsfor=09DHCPv6 |Sender:=20; bh=YkdvBSPWBSk891w/XoD6fZQp++xOys2I/WOtNlRMCyk=; b=KRnbf4CtOzrDWiZQbfk+Dl+YHmTY1I2gSfWZ6MhBEjyV64hQcb8ia3SoxhgqL7apA7QaTlZd PhCh3Y41vlyDLwRGnU1Zjk+O68XvYckhv6dLfxxRVJE19gAbCw8wc33U; Authentication-Results: ams-dkim-1; header.From=blourdel@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ntpwg@lists.ntp.org, "Richard Gayraud \(rgayraud\)" , dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org The beauty of offering IP address instead of FQDN is that you totally control your client. You don't let any room for interpretation of the result of the subsequent DNS query in the DHCP Client. Benoit=20 > -----Original Message----- > From: Ted Lemon [mailto:mellon@fugue.com]=20 > Sent: Monday, November 19, 2007 3:58 PM > To: Brian Utterback > Cc: Danny Mayer; Benoit Lourdelet (blourdel);=20 > ntpwg@lists.ntp.org; dhcwg@ietf.org; Richard Gayraud (rgayraud) > Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP)=20 > Optionsfor DHCPv6 >=20 > On Mon, 2007-11-19 at 09:07 -0500, Brian Utterback wrote: > > That having been said, I would like to see a way to pass a=20 > FQDN as an=20 > > option, perhaps passing both. Then you could have logic=20 > like "Here's=20 > > both, use the name if you can, and use the address if you must." >=20 > An option in a protocol that produces no different behavior=20 > is just an opportunity for interoperability problems. >=20 > This is actually an old discussion. Danny's position isn't=20 > unheard of, > but the fact is that there's really no way in which this=20 > option is different from the other fifty options that tell=20 > DHCP clients how to contact servers. >=20 > There's no reason why this option should use FQDNs while the=20 > other fifty use IP addresses, and there are a number of good=20 > reasons not to send FQDNs, the first and most obvious of=20 > which is that they take up more space in the packet, and=20 > space in the packet is very limited. >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 13:08:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuB2F-0003mt-K4; Mon, 19 Nov 2007 13:07:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuB2E-0003ft-RQ for dhcwg@ietf.org; Mon, 19 Nov 2007 13:07:50 -0500 Received: from exchdev.pega.com ([198.22.153.35] helo=exchdev.rpega.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuB2E-0006st-F9 for dhcwg@ietf.org; Mon, 19 Nov 2007 13:07:50 -0500 Received: from [10.60.98.36] ([10.60.98.36]) by exchdev.rpega.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 13:07:50 -0500 Message-ID: <4741D057.4070703@ntp.org> Date: Mon, 19 Nov 2007 13:05:11 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ted Lemon Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> In-Reply-To: <1195484306.9159.13.camel@uma> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2007 18:07:50.0085 (UTC) FILETIME=[18B41750:01C82AD7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , Brian Utterback , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ted Lemon wrote: > On Mon, 2007-11-19 at 09:07 -0500, Brian Utterback wrote: > >> That having been said, I would like to see a way to pass a FQDN >> as an option, perhaps passing both. Then you could have logic >> like "Here's both, use the name if you can, and use the address if >> you must." >> > > An option in a protocol that produces no different behavior is just an > opportunity for interoperability problems. > > This is actually an old discussion. Danny's position isn't unheard of, > but the fact is that there's really no way in which this option is > different from the other fifty options that tell DHCP clients how to > contact servers. > > There's no reason why this option should use FQDNs while the other fifty > use IP addresses, and there are a number of good reasons not to send > FQDNs, the first and most obvious of which is that they take up more > space in the packet, and space in the packet is very limited. > > There is no way of answering that claim without knowing more about a) those other 50 options; and b) how those options are obtained. So let's step back here for a moment and have someone from the DHCP community explain exactly how and when these options are sent to the client. Remember that those of us concentrating on NTP have only some idea how DHCP is sending these options. Does DHCP: a) Send these options unsolicited when it is requested to send an IP address to be used by the client?; b) Only send these options when requested by the client?; c) something else? When does the client send/receive the request? a) Upon boot b) upon lease renew c) some other time? Except for a) the NTP server is not going to be taking any options from the DHCP server unless some other mechanism (which NTP has not designed) tells it to. That means that the NTP can be up for months never updating it's list of NTP server addresses. In the meantime, Server 1 has stopped running, Server 2 has moved to a different address, Server 3 was always suspect. DCHP has no say in what to do about this, at least so far. DNS at least provides a way of getting a fresh set of addresses. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 13:29:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBMy-0000fu-SM; Mon, 19 Nov 2007 13:29:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBMy-0000fm-9k for dhcwg@ietf.org; Mon, 19 Nov 2007 13:29:16 -0500 Received: from pacdcimo02.cable.comcast.com ([24.40.8.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuBMv-0001Ul-PZ for dhcwg@ietf.org; Mon, 19 Nov 2007 13:29:16 -0500 Received: from ([10.195.246.152]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.13859712; Mon, 19 Nov 2007 13:28:58 -0500 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 13:28:58 -0500 Received: from 10.21.110.204 ([10.21.110.204]) by PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Nov 2007 18:28:57 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 19 Nov 2007 13:28:55 -0500 From: Alain Durand To: , Message-ID: Thread-Topic: 2nd DHCPv6 bake-off announcement Thread-Index: Acgq2gqmSWW8tpbNEdyVvgAX8t+c7g== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Nov 2007 18:28:58.0136 (UTC) FILETIME=[0C855180:01C82ADA] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [dhcwg] 2nd DHCPv6 bake-off announcement X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I would like to announce the 2nd DHCPv6 bake off to be organized the week-end after the IETF in Vancouver. The 1st DHCPv6 bake-off was held earlier this year at RIPE-NCC in Amsterdam and was a great success. See: http://www.isoc.org/tools/blogs/ietfjournal/?p=135 This new bake-off will be conducted in the same spirit, ie focusing on interoperability and operational practice. I've developed in partnership with ISC a preliminary test plan for this bake-off that is available upon request. Please contact me directly asap if you plan to attend or have any questions. - Alain. Organization information: ------------------------- Dates: Friday December 7th 12pm to Sunday December 9th 3pm Location: TBD, in Vancouver, BC, Canada Open to: any participant coming with an original implementation of a DHCPv6 client, relay or server Disclosure mode: this is a typical non disclosure event, ie you'll have full access to your test results, and we will only publish a short summary of the even as we did for the 1st bake-off in the above URL Contact & registration: Alain_Durand@cable.comcast.com What to bring: A platform to run your code (laptop, small router,...) Cost: there might be nominal fees to cover some of the local logistic (renting the room, etc..). Last time, I was able to bring those fees to $0. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 14:50:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCdO-0007o3-12; Mon, 19 Nov 2007 14:50:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuC9V-0005Al-VX; Mon, 19 Nov 2007 14:19:27 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuC8o-0005G8-9l; Mon, 19 Nov 2007 14:18:55 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D477F175B3; Mon, 19 Nov 2007 19:18:11 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuC8J-0000Cp-C4; Mon, 19 Nov 2007 14:18:11 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 19 Nov 2007 14:18:11 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: dhc mailing list , dhc chair , Internet Architecture Board , RFC Editor Subject: [dhcwg] Protocol Action: 'DHCP Server Identifier Override Suboption' to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org The IESG has approved the following document: - 'DHCP Server Identifier Override Suboption ' as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-override-05.txt Technical Summary This document specifies a DHCP relay agent information sub-option that causes the DHCP server to insert a different value for the Server Identifier option instead of the IP address of the DHCP server. By inserting the IP address of the DHCP relay agent option in the Server Identifier option, the DHCP client will send all DHCP messages through the DHCP relay agent, which is useful in some deployments in which the DHCP relay agent maintains state about the DHCP client. Working Group Summary The DHC WG reviewed this document and raised several issues during the WG last call. All of the issues have been resolved or addressed in this revision of the draft. Protocol Quality This specification is an extension to the DHCP specification. It provides the same function as the requirement in RFC 3315, DHCP for IPv6, that all DHCP messages be sent to the IPv6 All_DHCP_Relay_Agents_and_Servers multicast address. This document was reviewed for the IESG by Margaret Wasserman. Note to RFC Editor Please change: OLD: the DHCP Relay should forward all DHCP packets all servers. NEW: the DHCP Relay SHOULD forward all DHCP packets to all servers. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 15:02:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCpU-0004ki-HY; Mon, 19 Nov 2007 15:02:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCpS-0004kE-SB for dhcwg@ietf.org; Mon, 19 Nov 2007 15:02:46 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuCpP-0000jr-La for dhcwg@ietf.org; Mon, 19 Nov 2007 15:02:46 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 508D8B45C05 for ; Mon, 19 Nov 2007 12:02:43 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11617-04 for ; Mon, 19 Nov 2007 12:02:43 -0800 (PST) Received: from PARBETM2XP2 (unknown [172.31.253.173]) by prattle.redback.com (Postfix) with ESMTP id DF3A0B45C03 for ; Mon, 19 Nov 2007 12:02:42 -0800 (PST) From: "Peter Arberg" To: Date: Mon, 19 Nov 2007 12:02:39 -0800 Organization: Redback Networks Inc. Message-ID: <010801c82ae7$231379b0$ba3dfea9@ad.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acgq5yKzW7FtSRnhTHmBE+FmUyXIsQ== X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [dhcwg] Question on DHCP reconfigure extension (RFC 3203) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi, Reading the RFC3203 on ForceRenew, it is not very specific how servers should format the DHCP packet, if just refer to "the normal DHCP message layout". Since this is a server initiated packet, can the server then select a new xid for the DHCP packet, or does it have to used the same xid as the client used in the last packet it send to the server ? Also RFC3203 says that any ForceRenew message MUST be authenticated using the procedures as described in [DHCP-AUTH], that seems like a strong requirement, and I read that like any clients support of RFC3203 can only happen if they also support DHCP Authentication Option 90, is that the intent of this requirement, or is it more a resommendation that DHCP Auth. is good for the security :) thanks, Peter _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 16:16:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDyc-0002yq-Iw; Mon, 19 Nov 2007 16:16:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDyb-0002yU-68; Mon, 19 Nov 2007 16:16:17 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuDyX-0004FY-Oq; Mon, 19 Nov 2007 16:16:17 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 19 Nov 2007 13:16:13 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAJLGDKP001261; Mon, 19 Nov 2007 13:16:13 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAJLFtUp008234; Mon, 19 Nov 2007 21:16:13 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 13:16:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: [Mip4] draft-ietf-mip4-gen-ext-03.txt Date: Mon, 19 Nov 2007 13:17:29 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB04C73BF7@xmb-sjc-236.amer.cisco.com> In-Reply-To: <47418138.2090307@levkowetz.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Re: [Mip4] draft-ietf-mip4-gen-ext-03.txt Thread-Index: Acgqp53kHlzr2bn3RbCr/1YJL1NoRgASbNUA References: <7CCD07160348804497EF29E9EA5560D7024DA3E6@exchtewks2.starentnetworks.com><0C0F76B1-96EA-4600-BC1F-EEB91D46CE4C@cisco.com> <47418138.2090307@levkowetz.com> From: "Parviz Yegani (pyegani)" To: "Henrik Levkowetz" , "McCann Peter-A001034" X-OriginalArrivalTime: 19 Nov 2007 21:16:07.0030 (UTC) FILETIME=[66351960:01C82AF1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1795; t=1195506973; x=1196370973; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pyegani@cisco.com; z=From:=20=22Parviz=20Yegani=20(pyegani)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Re=3A=20[Mip4]=20draft-ietf-mip4-gen-ext-03 .txt |Sender:=20; bh=VNHpOgl0jZjW1fZy18hN9mVBUqFDcTc/iiVDFh/H8RU=; b=EkHwfF0S88WkNVG/FpL5OTmA9rakJ+8jXBQYRaffXPhGSaz5foOLq06SnkPNzdwvD/3YUQs5 Y8mlFQ3JJKTurqlO4iMJ7q1SNuilSbSDxkTPmdh6JCTEX92xn1GwqQHzlRsEO8833EteTuPxfX ZHpD4lFYLd1UVlL61pViF0atE=; Authentication-Results: sj-dkim-1; header.From=pyegani@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: dhcwg@ietf.org, mip4@ietf.org, "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org =20 -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Monday, November 19, 2007 4:28 AM To: McCann Peter-A001034 Cc: dhcwg@ietf.org; mip4@ietf.org; Ralph Droms (rdroms) Subject: [dhcwg] Re: [Mip4] draft-ietf-mip4-gen-ext-03.txt Hi Ralph and all, I have only one small comment regarding Pete's excellent exposition, inline below: On 2007-11-15 21:24 McCann Peter-A001034 said the following: > Hi, Ralph, ... > When reverse tunneling ala RFC 3024 is used (as it is in most major=20 > deployments of MIP), the MN has a choice about whether to negotiate=20 > "encapsulated delivery style" on the last hop link. It must negotiate > this if it wants to send broadcast datagrams (of which I think the=20 > DHCPDISCOVER is one) to the home network. In this case, an FA will=20 > look at each packet, and reverse tunnel the ones that are so=20 > encapsulated and send other packets directly. The problem I was=20 > trying to point out is that this extra encapsulation would be present=20 > on every packet sent to the home network, which might cause a lot of=20 > overhead on the link between the MN and FA. If this is a wireless=20 > link, this overhead is especially onerous. Note, though, that there is currently a proposal in draft-chakrabarti-mip4-mcbc-01 which if pursued will remove the extra encapsulation on all packets: http://www.tools.ietf.org/html/draft-chakrabarti-mip4-mcbc-01 Yes, an update (-02) has been posted. Rgds, Parviz > Please post if you have any remaining questions or if I have=20 > misunderstood the DHCP message flow. Regards, Henrik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 17:10:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuEoh-0000zK-Nm; Mon, 19 Nov 2007 17:10:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuEoh-0000zF-5V for dhcwg@ietf.org; Mon, 19 Nov 2007 17:10:07 -0500 Received: from [2001:4f8:3:bb::1:ee8b] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuEod-0006BR-HK for dhcwg@ietf.org; Mon, 19 Nov 2007 17:10:07 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id A380E5A6ED; Mon, 19 Nov 2007 14:09:58 -0800 (PST) Date: Mon, 19 Nov 2007 14:09:58 -0800 From: "David W. Hankins" To: DHC WG Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Message-ID: <20071119220958.GH14750@isc.org> References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> <47368636.3070007@udel.edu> <47410A17.8090503@ntp.org> <47411C6D.1010808@udel.edu> Mime-Version: 1.0 In-Reply-To: <47411C6D.1010808@udel.edu> User-Agent: Mutt/1.5.9i X-Spam-Score: -0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ntpwg@lists.ntp.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1362810539==" Errors-To: dhcwg-bounces@ietf.org --===============1362810539== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dkEUBIird37B8yKS" Content-Disposition: inline --dkEUBIird37B8yKS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 19, 2007 at 05:17:33AM +0000, David L. Mills wrote: > server and receives a response. There is an opportunity for the DHCP=20 > client to measure the delay, should it be so instrumented. In no way did= =20 I'm not aware of any DHCP message exchanges that are suitable for RTT measurements in any meaningful way. Many DHCP message exchanges require physical flushes to disc or other similar recoverable storage before replying, and in other messages servers may engage in additional behaviours that rely on additional RTTs (such as Dynamic DNS updates), or timeouts (such as with ICMP echoes). I can go into detail if you wish, but I personally would not use even the informational messages for any kind of meaningful time derivation (since even with informational messages, the server may perform recursive DNS resolution of names in its configuration in order to deliver IP addresses over DHCP). --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --dkEUBIird37B8yKS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHQgm2cXeLeWu2vmoRAmUtAJ9yByXCWblcfCOq5p5fNXLU2YZIZQCggoL3 g8hL1sYII1eYbYR6mvpmRq8= =NZqX -----END PGP SIGNATURE----- --dkEUBIird37B8yKS-- --===============1362810539== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1362810539==-- From dhcwg-bounces@ietf.org Mon Nov 19 17:26:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuF4z-0000jy-2l; Mon, 19 Nov 2007 17:26:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuF4x-0000jN-13; Mon, 19 Nov 2007 17:26:55 -0500 Received: from mout.perfora.net ([74.208.4.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuF4w-0005iX-Il; Mon, 19 Nov 2007 17:26:54 -0500 Received: from IBM52A5038A94F ([88.235.56.154]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1IuF4d142M-0005uP; Mon, 19 Nov 2007 17:26:41 -0500 From: "Alper Yegin" To: "'Alexandru Petrescu'" Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WGrecharteringforDHCPauthentication Date: Tue, 20 Nov 2007 00:26:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <473F3F45.4050204@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgpTxmteo7V0hijRoqWzz5VbLG6dgBq610Q Message-Id: <0MKp8S-1IuF4d142M-0005uP@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18QPu24BMCV9T4ghzwLnGDKERPWQNfCThKQzVP gMqie9PFsFbpF8t9FyR9kXOm+Ay3j/tLe3xrqCxwEeCpVFd3jC 8aJk5sP+XVoGsB5wHL+kg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: dhcwg@ietf.org, 'Internet Area' X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi Alex, I need to let NTT folks answer that. Meanwhile, the point I was trying to make is, IPv6 over DSL is not a future thing that we can blindly ignore. Tossing the ball back to DSLF is just a recipe for avoiding discussions. Alper > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Saturday, November 17, 2007 9:22 PM > To: Alper Yegin > Cc: ric@cisco.com; dhcwg@ietf.org; 'Internet Area' > Subject: Re: [Int-area] Re: [dhcwg] Discussion of dhc > WGrecharteringforDHCPauthentication > > (I have a certain oppinion on DHCPAuthentication vs PANA as well but it > seems many things have been already told.) > > Alper Yegin wrote: > [...] > >> This is one thing I would love to learn I am wrong about, please > >> name a provider doing residential IPv6 over DSL. > > > > NTT. Since 2001. > > NERIM in France since about 2003. > > But Alper - can you cite how NTT is doing it? How many customers? How > many addresses delivered to customer? What kind of addresses are > delivered? What transition mechanism? I can for NERIM. > > I'm talking from a 2001 experience of actually picking up the phone and > calling NTT and asking them for IPv6 access. > > All these things are important in order to really answer the question > raised above. > > It may all be in that 'residential' keyword. How much 'residential' is > a SOHO? What does 'residential' really mean in Japanese? > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 17:56:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuFXs-0007Md-4Q; Mon, 19 Nov 2007 17:56:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuFXq-0007Kd-2O for dhcwg@ietf.org; Mon, 19 Nov 2007 17:56:46 -0500 Received: from [2001:4f8:3:bb::1:ee8b] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuFXo-0007QG-Ok for dhcwg@ietf.org; Mon, 19 Nov 2007 17:56:46 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id 0D2D65A6ED; Mon, 19 Nov 2007 14:56:44 -0800 (PST) Date: Mon, 19 Nov 2007 14:56:44 -0800 From: "David W. Hankins" To: DHC WG Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Message-ID: <20071119225643.GI14750@isc.org> References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> Mime-Version: 1.0 In-Reply-To: <1195484306.9159.13.camel@uma> User-Agent: Mutt/1.5.9i X-Spam-Score: -0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: "ntpwg@lists.ntp.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1621324520==" Errors-To: dhcwg-bounces@ietf.org --===============1621324520== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cHMo6Wbp1wrKhbfi" Content-Disposition: inline --cHMo6Wbp1wrKhbfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 19, 2007 at 08:58:26AM -0600, Ted Lemon wrote: > There's no reason why this option should use FQDNs while the other fifty > use IP addresses, and there are a number of good reasons not to send > FQDNs, the first and most obvious of which is that they take up more > space in the packet, and space in the packet is very limited. There is a concern of which I am aware among the NTP users community concerning a recent catastrophic event which I think I am reading in the subtext of this thread. Lets find out. A SOHO router manufacturer latched onto the IPv4 address (not the domain name) of a particular open-to-the-public NTP clock. The IPv4 address was hard-coded into their firmware. Upon the release of this product, said clock was slowly subjected to what grew into an Entire-Internet scale distributed DDOS. The operator responsible for the NTP device at said IPv4 address was not willing nor capable of continuing to supply free bandwidth and hardened NTP servers to meet this SOHO router manufacturer's global clocking needs, certainly not free of charge, and ultimately had to readdress his clock. I seem to recall he was actually sued by the SOHO router manufacturer, because all their SOHO routers suddenly started spitting errors and misbehaving when this free service was withheld, but my memory is beyond its limits at this point. So it is possible that the community may strongly desire an otherwise unusual number of intermediaries between /etc/ntp.conf and the IPv4 addresses they determine. DHCP is an excellent solution, because it is likely that this SOHO router was in fact obtaining its own IP address via DHCPv4, so if it also received its clock via DHCPv4 rather than being hard- coded, there would never have been a problem to solve. IPv4 addresses via DHCP are possibly a worse solution, however, because if it does deliver fixed IPv4 addresses to clients, then a NAT box acting as a home gateway is a greater operational danger than the above; imagine if this SOHO router manufacturer had decided to deliver the fixed IPv4 address they had selected via DHCPv4 to all its NAT-side clients, in all homes its clones resided, worldwide. So if the DHCP protocol field required RFC1035 syntax, an IPv4 address becomes an illegal configuration format, and that may be a desirable outcome to a segment of the operational community that is concerned with the historic stickyness of their IPv4 addresses, and the tendency to get sued for publishing one. I do not make a judgement at this time, but I would like to caution the NTP community that additional intermediaries will not necessarily correct bad behaviour. In example, putting your clock's location in DNS resolution into A/AAAA records does not mean a SOHO router manufacturer can not / will not resolve those addresses and then hard-code them into products. I would also like to suggest that some of these concerns may be mitigated by tracking Ralph Drom's recent 'container option' draft, wherein a SOHO router may dynamically receive from an 'upstream' DHCPv6 server the configuration values it should give 'downstream' DHCPv6 clients. I'm not aware of an equivalent for DHCPv4 however. So cautioned, I personally leave it up to the NTP community to prove to us exactly to what extent it is genuinely useful to have such intermediaries as DNS (or even DHCP, even if I consider that a given) involved. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --cHMo6Wbp1wrKhbfi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHQhSrcXeLeWu2vmoRAmvmAJ9jsze05UQiSKZOAqX7utBmoCBhpACcC7eE slUAcRbDpR28JadySL53eMc= =2V1O -----END PGP SIGNATURE----- --cHMo6Wbp1wrKhbfi-- --===============1621324520== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1621324520==-- From dhcwg-bounces@ietf.org Mon Nov 19 18:22:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuFwj-0001fn-SF; Mon, 19 Nov 2007 18:22:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuFwi-0001fg-67 for dhcwg@ietf.org; Mon, 19 Nov 2007 18:22:28 -0500 Received: from [2001:4f8:3:bb::1:ee8b] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuFwg-0007yO-Oz for dhcwg@ietf.org; Mon, 19 Nov 2007 18:22:28 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id DF28F5A6ED; Mon, 19 Nov 2007 15:22:25 -0800 (PST) Date: Mon, 19 Nov 2007 15:22:25 -0800 From: "David W. Hankins" To: DHC WG Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Message-ID: <20071119232225.GJ14750@isc.org> References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <4741D057.4070703@ntp.org> Mime-Version: 1.0 In-Reply-To: <4741D057.4070703@ntp.org> User-Agent: Mutt/1.5.9i X-Spam-Score: -0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: "ntpwg@lists.ntp.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0683132893==" Errors-To: dhcwg-bounces@ietf.org --===============0683132893== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ryJZkp9/svQ58syV" Content-Disposition: inline --ryJZkp9/svQ58syV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 19, 2007 at 01:05:11PM -0500, Danny Mayer wrote: > a) Send these options unsolicited when it is requested to send an IP > address to be used by the client?; > b) Only send these options when requested by the client?; > c) something else? In general, and in context of this discussion, it is most important to understand that DHCP servers (both v4 and v6) provide exactly those options the DHCP clients request (via the DHCPv4 Parameter Request List option, or the DHCPv6 Option Request Option). A server might be configured to send additional options explicitly, but doing so is no guarantee that the client will use the options. The request lists are essentially an advertisement of what options the client is willing to digest, and the order of priority it places in them (in the event of packet space exhaustion, earlier options will preclude later). In DHCPv4, there are approximately 312 bytes available for DHCP options, considering realistic operational deployment. Less if you don't want to bear support costs. Some of those must be textual (domain name, search path), but the majority have been and continue to be carried in binary IP address forms. In DHCPv6, there are potentially 64k bytes available for DHCP options, with some handwaving for the (extremely brief) headers, recursive headers due to DHCPv6 relay paths, and the various options that are 'mandatory' for normal operation...you are still left with a "large" potential for options payload. This is much more than four times the available packet space, considering IPv6 addresses are "only" four times larger than IPv4 addresses. > When does the client send/receive the request? It depends, and in either protocol is at the discretion of the client. > a) Upon boot Obviously the client will obtain an address upon booting. Upon rebooting... In DHCPv4, we have the INIT-REBOOT state, so the client sends a request that effectively extends its lease, and new configuration state is loaded along with that. In DHCPv6, we have the Confirm message, which allows a client to continue to use its previous binding (or not, sending it back to the beginning), and no new configuration state is loaded. Any change in configuration (such as its absence) is detected, and new values (or lack thereof) are adopted. > b) upon lease renew Yes. New values from the network always supplant older ones. How to integrate this onto e.g. a Unix-like system is unclear, and realistically many configuration values are "sticky" with running applications (such as /etc/resolv.conf contents that are loaded once when firefox starts and never again). So all of this is academic if your ntpd runs once at startup on a laptop that "sleeps" rather than being shutdown, and never reloads its configuratoin file with fresh values from the DHCP client. Ostensibly you would want to have some closer integration with the DHCP client to receive these configuration events in near real time. > c) some other time? Both DHCP protocols include a mechanism to reconfigure/force the renewal of configuration information causing a client to enter into the renewal event at any time, but the DHCPv4 method is not well deployed, and the DHCPv6 method is not clearly well used (to me, maybe someone else will comment). I don't know if you will find this document helpful; http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-00.txt But I (rather egotistically) think it is a good read for background information for any authors looking to write new DHCP options. It expires Jan. 2 2008. I should probably rev it soon, but doubt I will have the time available until approx Jan 15... --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --ryJZkp9/svQ58syV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHQhqxcXeLeWu2vmoRAsOoAKC97EN5+D5IOzb/T0FG10QlLiRbxwCfQBQb AMhcer+XunEWb+88c7AVB14= =1k6a -----END PGP SIGNATURE----- --ryJZkp9/svQ58syV-- --===============0683132893== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0683132893==-- From dhcwg-bounces@ietf.org Mon Nov 19 18:41:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuGFV-0008Os-RA; Mon, 19 Nov 2007 18:41:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuGFV-0008On-4G for dhcwg@ietf.org; Mon, 19 Nov 2007 18:41:53 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuGFU-0007PY-Pd for dhcwg@ietf.org; Mon, 19 Nov 2007 18:41:53 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Nov 2007 18:41:52 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAJNfqt6007836; Mon, 19 Nov 2007 18:41:52 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAJNflwr026621; Mon, 19 Nov 2007 23:41:48 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 18:41:05 -0500 Received: from [192.168.1.102] ([10.86.240.146]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 18:41:05 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20071119225643.GI14750@isc.org> References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <20071119225643.GI14750@isc.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6DD46BAB-2F5F-4DFB-A4CC-BCA325DDFDA8@cisco.com> Content-Transfer-Encoding: 7bit From: Ralph Droms Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Date: Mon, 19 Nov 2007 18:41:18 -0500 To: DHC WG , ntpwg@lists.ntp.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 19 Nov 2007 23:41:05.0526 (UTC) FILETIME=[A6EA4160:01C82B05] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15554.002 X-TM-AS-Result: No--18.416600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1233; t=1195515712; x=1196379712; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20Re=3A=20[ntpwg]=20Network=20Time=20Protocol =20(NTP)=20Options=20for=09DHCPv6 |Sender:=20 |To:=20DHC=20WG=20,=20ntpwg@lists.ntp.org; bh=rzWFrobBo/AFISrcr/eEXgigCgkUD8uRLh2ipiZEPsw=; b=bZZVxtr/aTMvJe3fsp9iDl/qEIgvee8x1/B1z4sZSMk+olIdAH3KKEdc2a4LIObLeoRNLqmc DwSJTt8+D3gqApahClvkjMP3cnGdL3pe2397k1DTWnFNGSq1qNM0PJoQ; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org draft-droms-dhc-container-opt-01.txt defines container options for both DHCPv4 and DHCPv6. - Ralph On Nov 19, 2007, at Nov 19, 2007,5:56 PM, David W. Hankins wrote: > [...] > I would also like to suggest that some of these concerns may be > mitigated by tracking Ralph Drom's recent 'container option' draft, > wherein a SOHO router may dynamically receive from an 'upstream' > DHCPv6 server the configuration values it should give 'downstream' > DHCPv6 clients. > > I'm not aware of an equivalent for DHCPv4 however. > > > So cautioned, I personally leave it up to the NTP community to > prove to us exactly to what extent it is genuinely useful to have > such intermediaries as DNS (or even DHCP, even if I consider that > a given) involved. > > -- > Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. > Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ > -- > David W. Hankins "If you don't do it right the first time, > Software Engineer you'll just have to do it again." > Internet Systems Consortium, Inc. -- Jack T. Hankins > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 19 22:24:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuJib-0006r0-HO; Mon, 19 Nov 2007 22:24:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuJia-0006qe-AD; Mon, 19 Nov 2007 22:24:08 -0500 Received: from gura.nttv6.jp ([2001:218:1:1040::2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuJiW-000570-HB; Mon, 19 Nov 2007 22:24:08 -0500 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id B781FBDC08; Tue, 20 Nov 2007 12:24:03 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 881746E661; Tue, 20 Nov 2007 12:24:03 +0900 (JST) Date: Tue, 20 Nov 2007 12:24:03 +0900 (JST) Message-Id: <20071120.122403.193720425.miyakawa@nttv6.jp> To: alper.yegin@yegin.org Subject: Re: [Int-area] Re: [dhcwg] Discussion of dhc WGrecharteringforDHCPauthentication From: Shin Miyakawa In-Reply-To: <0MKp8S-1IuF4d142M-0005uP@mrelay.perfora.net> References: <473F3F45.4050204@gmail.com> <0MKp8S-1IuF4d142M-0005uP@mrelay.perfora.net> Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: dhcwg@ietf.org, alexandru.petrescu@gmail.com, miyakawa@nttv6.jp, int-area@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org From: "Alper Yegin" Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WGrecharteringforDHCPauthentication Date: Tue, 20 Nov 2007 00:26:23 +0200 > I need to let NTT folks answer that. Which means Me , Alper ? :-p > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > But Alper - can you cite how NTT is doing it? http://www.ipv6style.jp/en/statistics/services/index.shtml is a good reference what we're doing in Japan. Not only by NTT. Talking about ISP service, please see http://www.v6.ntt.net/index_e.html > > How many customers? We can not disclose without proper permission from company, sorry about that. > > How many addresses delivered to customer? > > What kind of addresses are delivered? Please look at RFC4241. Actually, we've modified a bit in addition to this model. Basically, we've added RA onto the uplink between CPE and Access Concentrator because of some operating system like Windows Vista uses the strong model for its network design. If I could have a chance, I am grad to tell about our architecture in Vancouvor in some proper place. > >What transition mechanism? No transition mechanism. Also, we've already commercialized "softwire" service named "OCNIPv6". Basically, this is as same as we've discussed within SOFTWIRE WG of IETF. > > I'm talking from a 2001 experience of actually picking up the phone and > > calling NTT and asking them for IPv6 access. > > > > All these things are important in order to really answer the question > > raised above. > > > > It may all be in that 'residential' keyword. How much 'residential' is > > a SOHO? What does 'residential' really mean in Japanese? SOHO as well as just an apartment or house. One my house in Tokyo had been equipped with residential IPv6/v4 dual ADSL service from my own company. I believe that this is residential :-) (Now I personally am using FTTH service from NTT as well with IPv6 softwire commercial service on it.) Best regards, Shin Miyakawa NTT Communications Corporation _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 20 09:27:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuU4Z-0003lk-HY; Tue, 20 Nov 2007 09:27:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuU4Y-0003lX-JK for dhcwg@ietf.org; Tue, 20 Nov 2007 09:27:30 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuU4Y-0004Di-0W for dhcwg@ietf.org; Tue, 20 Nov 2007 09:27:30 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1195568848!18579179!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 22781 invoked from network); 20 Nov 2007 14:27:29 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-2.tower-119.messagelabs.com with SMTP; 20 Nov 2007 14:27:29 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id lAKERSUk014769 for ; Tue, 20 Nov 2007 07:27:28 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id lAKERRtm017467 for ; Tue, 20 Nov 2007 08:27:28 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id lAKERP4S017444 for ; Tue, 20 Nov 2007 08:27:26 -0600 (CST) Message-ID: <4742EECD.9030503@gmail.com> Date: Tue, 20 Nov 2007 15:27:25 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 CC: dhcwg@ietf.org Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-subnet-alloc-06.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 1.6 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi, I've read this draft and I have some comments. I may have missed prior discussion around it, sorry if I sound uninformed on this. Was there a Last Call for this draft? What are the reasons behind its intended status being Informational? Was there any mention about prototyping or intent of it or of an Ethereal/WireShark packet analyzer dissector? 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 Dynamic Host > Configuration Working Group of the IETF. > > Title : Subnet Allocation Option Author(s) : R. Johnson, et al. > Filename : draft-ietf-dhc-subnet-alloc-06.txt Pages : 32 Date : > 2007-11-16 This document defines a new DHCP option which is passed > between the DHCP Client and the DHCP Server to request dynamic > allocation of a subnet, give specifications of subnet(s) allocated, > and report usage statistics. This memo documents the current usage > of the option in agreement with RFC-3942[4], which declares that any > pre-existing usages of option numbers in the range 128 - 223 should > be documented and the working group will try to officially assign > those numbers to those options. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-alloc-06.txt Comments on this draft: > 3.1. Subnet-Request Suboption format > > 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 2 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 1 | Len | Flags |i|h| Prefix | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Since the Prefix field will only encode a maximum of 32 values (the prefix length of an IPv4 address, or the subnet mask) 5 bits would suffice (and not 8 as above). This would allow Flags field to expand more flags in the future. Thoughts? Nit: > The DHCP Server SHOULD allocate a subnet with prefix size less than > or equal to the size P specified in the request. In other words, a > subnet at least the size requested and possibly bigger. ^^ I think you meant 'possibly smaller' (if we characterize the size parameter as the number of addresses within it then a bigger subnet accommodates more hosts). > The actual method of allocating subnets on the DHCP Server, as well > as the configuration of what networks may be subnetted and how, is > left up to the implementation. I think this is reasonable. However, I see more simple issues around it that don't necessarily need to be left to implementations and moreover have a direct relationship to DHCP. -Could we have a picture somewhere at the beginning of the document describing an example with topology how you see this prototyped? Is that like Client--Server or more like Client--Relay--Server? -If the latter then we may have some new restrictions to specify: the Server should allocate a subnet _within_ the subnet on which the Relay already allocates addresses for Clients. This has a strong impact on implementations' ways to specify their configuration files. -and also about routing: if working through a Relay then the routing must be updated for the subnet allocation to work. Maybe how to update it it's left to other specs, but the routing must be updated (Server's routing table must point to Client's address for the subnet it allocated). This is something that could be mentioned I hinkl. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 20 10:27:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuV0a-0006ln-8z; Tue, 20 Nov 2007 10:27:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuV0Z-0006k3-6m for dhcwg@ietf.org; Tue, 20 Nov 2007 10:27:27 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuV0U-0005Fh-Hl for dhcwg@ietf.org; Tue, 20 Nov 2007 10:27:27 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Nov 2007 10:27:22 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAKFRMfx001250; Tue, 20 Nov 2007 10:27:22 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAKFRHVx023596; Tue, 20 Nov 2007 15:27:22 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 10:27:09 -0500 Received: from [192.168.1.102] ([10.86.240.146]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 10:27:08 -0500 In-Reply-To: <4742EECD.9030503@gmail.com> References: <4742EECD.9030503@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <233398A2-AF01-4444-9293-E076482B8184@cisco.com> Content-Transfer-Encoding: 7bit From: Ralph Droms Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-subnet-alloc-06.txt Date: Tue, 20 Nov 2007 10:27:17 -0500 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 20 Nov 2007 15:27:08.0546 (UTC) FILETIME=[D04FBE20:01C82B89] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15556.002 X-TM-AS-Result: No--40.844200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4858; t=1195572442; x=1196436442; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20I-D=20ACTION=3Adraft-ietf-dhc-subnet-alloc- 06.txt |Sender:=20 |To:=20Alexandru=20Petrescu=20; bh=JD2sLu5Uv13wtnme4Q/3JikSkI10/1p/WZNt3ssfntk=; b=N2p02vcy+wy+3g+Q3qdd71nVOCnlIh7l9nD0ovwvyCyZORzT0dszgVXontkbIfD/UESe/N7S 9NpArOvvxqSsByJ98vnNB6Ez6rzSPop/XYRC/+EG14V7luqhf1YO6+wS; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: DHC WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Quick top-level response. This draft describes Cisco's current use of option code 220, and follows the process outlined in RFC 3942 to document the use of option codes the were previously identified as "site-specific options" in RFC 2132. According to the RFC 3942 process, the document will be published as "Informational"; because it documents current use rather than future deployment, there likely won't be changes to the syntax or semantics of the option at this point. - Ralph On Nov 20, 2007, at Nov 20, 2007,9:27 AM, Alexandru Petrescu wrote: > Hi, I've read this draft and I have some comments. I may have > missed prior discussion around it, sorry if I sound uninformed on > this. > > Was there a Last Call for this draft? What are the reasons behind > its intended status being Informational? Was there any mention > about prototyping or intent of it or of an Ethereal/WireShark > packet analyzer dissector? > > 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 Dynamic Host >> Configuration Working Group of the IETF. >> Title : Subnet Allocation Option Author(s) : R. Johnson, et al. >> Filename : draft-ietf-dhc-subnet-alloc-06.txt Pages : 32 Date : >> 2007-11-16 This document defines a new DHCP option which is >> passed between the DHCP Client and the DHCP Server to request >> dynamic allocation of a subnet, give specifications of subnet(s) >> allocated, and report usage statistics. This memo documents the >> current usage of the option in agreement with RFC-3942[4], which >> declares that any pre-existing usages of option numbers in the >> range 128 - 223 should be documented and the working group will >> try to officially assign those numbers to those options. >> A URL for this Internet-Draft is: http://www.ietf.org/internet- >> drafts/draft-ietf-dhc-subnet-alloc-06.txt > > Comments on this draft: > >> 3.1. Subnet-Request Suboption format > > >> 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 2 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 1 | Len | Flags |i|h| Prefix | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Since the Prefix field will only encode a maximum of 32 values (the > prefix length of an IPv4 address, or the subnet mask) 5 bits would > suffice (and not 8 as above). This would allow Flags field to > expand more flags in the future. Thoughts? > > Nit: >> The DHCP Server SHOULD allocate a subnet with prefix size less >> than or equal to the size P specified in the request. In other >> words, a subnet at least the size requested and possibly bigger. > ^^ > I think you meant 'possibly smaller' (if we characterize the size > parameter as the number of addresses within it then a bigger subnet > accommodates more hosts). > >> The actual method of allocating subnets on the DHCP Server, as >> well >> as the configuration of what networks may be subnetted and how, is >> left up to the implementation. > > I think this is reasonable. > > However, I see more simple issues around it that don't necessarily > need to be left to implementations and moreover have a direct > relationship to DHCP. > > -Could we have a picture somewhere at the beginning of the document > describing an example with topology how you see this prototyped? Is > that like Client--Server or more like Client--Relay--Server? > -If the latter then we may have some new restrictions to specify: the > Server should allocate a subnet _within_ the subnet on which the > Relay > already allocates addresses for Clients. This has a strong impact on > implementations' ways to specify their configuration files. > -and also about routing: if working through a Relay then the routing > must be updated for the subnet allocation to work. Maybe how to > update > it it's left to other specs, but the routing must be updated > (Server's > routing table must point to Client's address for the subnet it > allocated). This is something that could be mentioned I hinkl. > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 20 11:33:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuW2b-0007cj-B9; Tue, 20 Nov 2007 11:33:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuW2Z-0007bv-7j; Tue, 20 Nov 2007 11:33:35 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuW2Y-0008GC-7C; Tue, 20 Nov 2007 11:33:35 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm17474337df; Wed, 21 Nov 2007 00:46:31 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm29473e6571; Sat, 17 Nov 2007 06:46:03 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 17 Nov 2007 06:46:03 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It7g7-0001qj-IF; Fri, 16 Nov 2007 15:20:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It7g3-0001qE-T4; Fri, 16 Nov 2007 15:20:35 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It7g0-0008Ik-Fn; Fri, 16 Nov 2007 15:20:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 64E303293E; Fri, 16 Nov 2007 20:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1It7fW-0002ZQ-AG; Fri, 16 Nov 2007 15:20:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 16 Nov 2007 15:20:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action:draft-ietf-dhc-agent-vpn-id-05.txt X-BeenThere: dhcwg@ietf.org Reply-To: internet-drafts@ietf.org List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Virtual Subnet Selection Sub-Option for the Relay Agent Information Option for DHCPv4 Author(s) : K. Kinnear, et al. Filename : draft-ietf-dhc-agent-vpn-id-05.txt Pages : 11 Date : 2007-11-16 In some environments, a relay agent resides in a network element which also has access to one or more virtual private networks (VPNs). If a DHCP server wishes to offer service to DHCP clients on those different VPNs the DHCP server needs to know information about the VPN on which each client resides. The Virtual Subnet Selection sub- option of the relay-agent-information option is used by the relay agent to tell the DHCP server important information about the VPN (called the Virtual Subnet Selection information, or VSS) for every DHCP request it passes on to the DHCP server, and is also used to properly forward any DHCP reply that the DHCP server sends back to the relay agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-vpn-id-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-agent-vpn-id-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agent-vpn-id-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-16151947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agent-vpn-id-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agent-vpn-id-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-16151947.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Tue Nov 20 17:02:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IubA1-0000rq-0W; Tue, 20 Nov 2007 17:01:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IubA0-0000rk-AS for dhcwg@ietf.org; Tue, 20 Nov 2007 17:01:36 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iub9z-0006Nh-Uq for dhcwg@ietf.org; Tue, 20 Nov 2007 17:01:36 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Nov 2007 17:01:36 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAKM1ZCI022069 for ; Tue, 20 Nov 2007 17:01:35 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAKM1Hx3010383 for ; Tue, 20 Nov 2007 22:01:35 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 17:01:23 -0500 Received: from [192.168.1.102] ([10.86.240.146]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 17:01:22 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <6DCDA360-5BED-43C5-A5C3-030A7CF2EDC3@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: DHC WG From: Ralph Droms Date: Tue, 20 Nov 2007 17:01:29 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 20 Nov 2007 22:01:23.0367 (UTC) FILETIME=[E3AEFB70:01C82BC0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2461; t=1195596095; x=1196460095; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20dhc=20WG=20meeting=20agenda |Sender:=20 |To:=20DHC=20WG=20; bh=fdp49FpGTmAklFv9E2Y40sflRS/1KYGh04YskQT+Ipc=; b=J8TTCvQdb+UT0MUzmL+fpCb3+Jsv/d+N8jS8w8fzvTIMT6qrU2k0oPfea4bJ2ygfWLpN3E+l +Lz4mF2sqs3blPPRkbI4vF7xJW7BQxRbdPdbpR0u5KLOeoLM+IXuskbH; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [dhcwg] dhc WG meeting agenda X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Here is the latest revised agenda. Please be sure to *read* all of the drafts before the meeting and be prepared for discussion. - Ralph ----- DHC WG DRAFT agenda - IETF 70 1300-1500 2007-12-04 (Tue) (Last revised 2007-11-20 04:58 PM ET) ------------------------------------- Administrivia Venaas/Droms 10 minutes Agenda bashing; blue sheets; scribe; Jabber scribe Draft last call and adoption announcements Venaas/Droms 05 minutes RFC 3942 status update B. Volz 05 minutes Progressing two drafts under RFC 3942 R. Droms 10 minutes Virtual Subnet Selection Option R. Johnson 05 minutes Review changes prior ot WG last call Virtual Subnet Selection RAIO Sub-Option K. Kinnear 05 minutes Review changes prior ot WG last call Container Option for Server Configuration R. Droms 10 minutes Accept as WG work item? DHCPv6 Bulk Leasequery M. Stapp 10 minutes Initial discussion Layer 2 Relay Agent Information B. Joshi 20 minutes Followup discussion of revised draft NTP Options for DHCPv6 B. Lourdelet 05 minutes Initial discussion and input to ntp WG Rebind Capability in DHCPv6 Reconfigure Msgs R. Droms 10 minutes Ready for WG last call? Service Identfiers List Option for DHCPv6 H. Deng 10 minutes Initial discussion for consideration as WG work item Neighbor Discovery Information over DHCP S. Krishnan 15 minutes Initial discussion for consideration as WG work item ----------- 120 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 20 23:44:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuhRn-00023c-DG; Tue, 20 Nov 2007 23:44:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuhRm-00023X-9o for dhcwg@ietf.org; Tue, 20 Nov 2007 23:44:22 -0500 Received: from whimsy.udel.edu ([128.4.2.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuhRj-0007s5-KV for dhcwg@ietf.org; Tue, 20 Nov 2007 23:44:22 -0500 Received: by whimsy.udel.edu (Postfix, from userid 62) id DDB4116B6; Wed, 21 Nov 2007 04:43:57 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id 9C95115EE; Wed, 21 Nov 2007 04:43:55 +0000 (UTC) Message-ID: <4743B78A.3070300@udel.edu> Date: Wed, 21 Nov 2007 04:43:54 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: ntpwg@lists.ntp.org, dhcwg@ietf.org Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com> <474109FB.2080508@ntp.org> In-Reply-To: <474109FB.2080508@ntp.org> X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Danny, The one-way delay on a fast Ethernet is usually in the weenieseconds on a fast Ethernet, so I wouldn't worry to much about it. The scenario where the DHCP delay would be useful is when for some reason or other the client cannot use the client/server volley to measure it. A nonzero delay value in the DHCP response would be an explicit indication of that. Davev Danny Mayer wrote: > Brian Utterback wrote: > >> Benoit Lourdelet (blourdel) wrote: >> >>> Considering a central DHCP server, the use of remote-id [RFC4649] or >>> just link-id may tell the server from where the request is coming then >>> giving it the knowledge of the delay to >>> apply. >>> In the case of a DHCP server hosted by the first hop, the DHCP server is >>> well positioned to know the delay. >> >> Oh, agreed, it is possible for the delay to be known. > > > I consider that it is most unlikely for the DHCP server to know the > delay. Consider DHCP server D, client C and NTP server N. Each are in > different locations on the physical wire (wireless and other medium are > similar). D may know its own delay to N but C is elsewhere on the > wire. You might be able to figure out the delay between D and C but how > does it relate to the delay between C and N? They are in different > locations on the wire. Is C closer to N, further away, on another > segment of the network? > > Danny > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 20 23:49:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuhWN-0007QA-I7; Tue, 20 Nov 2007 23:49:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuhWM-0007Dq-BU for dhcwg@ietf.org; Tue, 20 Nov 2007 23:49:06 -0500 Received: from mx05.gis.net ([208.218.130.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuhWI-0007yR-Vg for dhcwg@ietf.org; Tue, 20 Nov 2007 23:49:06 -0500 Received: from [10.10.10.100] ([63.209.224.211]) by mx05.gis.net; Tue, 20 Nov 2007 23:48:47 -0500 Message-ID: <4743B810.9030100@ntp.org> Date: Tue, 20 Nov 2007 23:46:08 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Brian Utterback Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> In-Reply-To: <474198BA.3000109@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Brian Utterback wrote: > Danny Mayer wrote: > >> There is *no* avantage to not sending a FQDN and plenty of >> disadvantages to not doing so. Would you like a list of vendors who >> have hardcoded IP addresses into their devices without permission >> of the operator of that NTP server causing headaches for not just >> the owner of the NTP Server but also for the users of those >> devices? The NTP reference implementation expects the existence of >> a resolver so you haven't gained anything. >> > > As already noted, there is an advantage, namely that the client does > not have to have a resolver. And even if the reference implementation > requires one (Is that really true? Even if no name resolution is > required?) DHCP should remain implementation agnostic. > The reference implementation calls getaddrinfo(). Whether it actually contacts a resolver depends partly on the O/S. > As far the "hard coded address" problem goes, I don't see that > scenario as very likely. DHCP clients don't tend to remain up for > very long periods. And you don't have the same IP addresses being > served by thousands of DHCP servers. The thing to be careful of is > that the DHCP server not be embedded and replicated with hard coded > addresses, not that the clients only get IP addresses. This laptop that I'm typing on hasn't been restarted in at least a month. The NTP server (which I am stopping and starting constantly as I'm testing and debugging code) would not normally be stopped and never fetches an new addresses once it has them. In the meantime it's changing networks at least 3 times a day and therefore getting a new address from DHCP each time. Currently, if the DHCP server were to send me new IP addresses for the NTP server it would ignore it as it's already running and doesn't look at anything before it's restarted or you use ntpdc to change it. So except for bootup, sending me IP addresses every time I change my local IP address would be useless since the running ntpd server doesn't get notified, at least not right now. If you want to use the DHCP server essentially as a resolver (it looks up the addresses and sends them to the NTP server) that's fine except there's no mechanism currently in place to do that. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 20 23:50:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuhXW-00021Q-NW; Tue, 20 Nov 2007 23:50:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuhXU-00021L-VR for dhcwg@ietf.org; Tue, 20 Nov 2007 23:50:17 -0500 Received: from whimsy.udel.edu ([128.4.2.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuhXU-0002U0-AW for dhcwg@ietf.org; Tue, 20 Nov 2007 23:50:16 -0500 Received: by whimsy.udel.edu (Postfix, from userid 62) id EEC3616B6; Wed, 21 Nov 2007 04:50:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id 0DAF515EE; Wed, 21 Nov 2007 04:50:11 +0000 (UTC) Message-ID: <4743B902.3030406@udel.edu> Date: Wed, 21 Nov 2007 04:50:10 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> In-Reply-To: <474198BA.3000109@sun.com> X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Brian, Trying to put out fires when the network is burning is a good excercise in fault containment. When the DNS is broken and the repair party arrives, it's good to know the gateway works even if DNS doesn't. I'm not sure this exactly applies to NTP, but I sure would like to see the NTP servers options include hard coded addresses. Dave Brian Utterback wrote: > > Danny Mayer wrote: > >> There is *no* avantage to not sending a FQDN and plenty of disadvantages >> to not doing so. >> Would you like a list of vendors who have hardcoded IP addresses into >> their devices without >> permission of the operator of that NTP server causing headaches for not >> just the owner of the >> NTP Server but also for the users of those devices? The NTP reference >> implementation expects >> the existence of a resolver so you haven't gained anything. >> > > As already noted, there is an advantage, namely that the client does > not have to have a resolver. And even if the reference implementation > requires one (Is that really true? Even if no name resolution is > required?) DHCP should remain implementation agnostic. > > As far the "hard coded address" problem goes, I don't see that > scenario as very likely. DHCP clients don't tend to remain up > for very long periods. And you don't have the same IP addresses > being served by thousands of DHCP servers. The thing to be careful > of is that the DHCP server not be embedded and replicated with hard > coded addresses, not that the clients only get IP addresses. > > That having been said, I would like to see a way to pass a FQDN > as an option, perhaps passing both. Then you could have logic > like "Here's both, use the name if you can, and use the address if > you must." > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 21 00:26:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iui6K-0002KJ-DI; Wed, 21 Nov 2007 00:26:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iui6I-0002An-O6 for dhcwg@ietf.org; Wed, 21 Nov 2007 00:26:14 -0500 Received: from mail1.ntp.org ([204.152.184.126]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iui6F-0000he-H2 for dhcwg@ietf.org; Wed, 21 Nov 2007 00:26:14 -0500 Received: from localhost (localhost [127.0.0.1]) by mail1.ntp.org (Postfix) with ESMTP id DD3EF39E3F; Wed, 21 Nov 2007 05:26:10 +0000 (UTC) (envelope-from stenn@ntp1.ntp.org) Received: from mail1.ntp.org ([127.0.0.1]) by localhost (ntp1.isc.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82058-04; Wed, 21 Nov 2007 05:24:39 +0000 (UTC) Received: from ntp1.ntp.org (localhost [127.0.0.1]) by mail1.ntp.org (Postfix) with ESMTP; Wed, 21 Nov 2007 05:24:36 +0000 (UTC) (envelope-from stenn@ntp1.ntp.org) To: Ted Lemon Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 In-Reply-To: Message from Ted Lemon of "Thu, 15 Nov 2007 20:52:53 MST." <1195185173.26090.4.camel@uma> X-Mailer: MH-E 7.4.2; nmh 1.0.4; XEmacs 21.4 (patch 14) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 21 Nov 2007 05:24:36 +0000 From: Harlan Stenn X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on ntp1.isc.org Message-Id: <20071121052610.DD3EF39E3F@mail1.ntp.org> X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: "ntpwg@lists.ntp.org" , "Richard Gayraud \(rgayraud\)" , "dhcwg@ietf.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Guys, Is this about mechanism or policy? I would suspect (and hope) it is about mechanism. In that case one must be able to "offer" either a name or an IPv4 address or an IPv6 address. If one *also* wishes to address policy issues, that's OK (IMO). But (again IMO) the underlying mechanism needs to support names and/or addresses. H _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 21 02:05:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IujeA-0005R6-JU; Wed, 21 Nov 2007 02:05:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuje8-0005R0-Mg for dhcwg@ietf.org; Wed, 21 Nov 2007 02:05:16 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuje8-00060m-2O for dhcwg@ietf.org; Wed, 21 Nov 2007 02:05:16 -0500 X-IronPort-AV: E=Sophos;i="4.21,444,1188770400"; d="scan'208";a="158328016" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2007 08:05:15 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAL75FpO000826; Wed, 21 Nov 2007 08:05:15 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAL759Um013102; Wed, 21 Nov 2007 07:05:14 GMT Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 08:05:09 +0100 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 Subject: RE: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Date: Wed, 21 Nov 2007 08:06:19 +0100 Message-ID: In-Reply-To: <4741D057.4070703@ntp.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Thread-Index: Acgq1y1Q3aiDcf4+T8eKgYySBn/5LwBNUTlQ References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <4741D057.4070703@ntp.org> From: "Benoit Lourdelet (blourdel)" To: "Danny Mayer" , "Ted Lemon" X-OriginalArrivalTime: 21 Nov 2007 07:05:09.0784 (UTC) FILETIME=[DA8B2180:01C82C0C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3021; t=1195628715; x=1196492715; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=blourdel@cisco.com; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Re=3A=20[ntpwg]=20Network=20Time=20Protocol =20(NTP)=20Options=09for=09DHCPv6 |Sender:=20; bh=/dbt5HOZTSzwYas70kEphuAJsq6dAHII81EwC6g+P9k=; b=Q6JWm/F58xDDEqlbS26kqxhtluTi8s2vhEWVNkyy1ZYHZoHev4EbuHfYRmmbrZ+JJlgCeMPJ VniKi9LWxiCl7RE+WEarHboNKNxGc8NhqW8rvM54FgEth3R5WuegOrdj; Authentication-Results: ams-dkim-2; header.From=blourdel@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Brian Utterback , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org About those 50 options ... For DHCPv6, listing already defined options specifying an IP service, I find option : 22,27,28,31,34, 40 that have hardcoded IPv6 addresses. So far, I cant find any IP service defined by an FQDN for DHCPv6. Benoit=20 > -----Original Message----- > From: Danny Mayer [mailto:mayer@ntp.org]=20 > Sent: Monday, November 19, 2007 7:05 PM > To: Ted Lemon > Cc: Brian Utterback; Benoit Lourdelet (blourdel);=20 > ntpwg@lists.ntp.org; dhcwg@ietf.org; Richard Gayraud (rgayraud) > Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP)=20 > Options for DHCPv6 >=20 > Ted Lemon wrote: > > On Mon, 2007-11-19 at 09:07 -0500, Brian Utterback wrote: > > =20 > >> That having been said, I would like to see a way to pass a=20 > FQDN as an=20 > >> option, perhaps passing both. Then you could have logic=20 > like "Here's=20 > >> both, use the name if you can, and use the address if you must." > >> =20 > > > > An option in a protocol that produces no different behavior=20 > is just an=20 > > opportunity for interoperability problems. > > > > This is actually an old discussion. Danny's position=20 > isn't unheard of, > > but the fact is that there's really no way in which this option is=20 > > different from the other fifty options that tell DHCP=20 > clients how to=20 > > contact servers. > > > > There's no reason why this option should use FQDNs while the other=20 > > fifty use IP addresses, and there are a number of good=20 > reasons not to=20 > > send FQDNs, the first and most obvious of which is that=20 > they take up=20 > > more space in the packet, and space in the packet is very limited. > > > > =20 > There is no way of answering that claim without knowing more=20 > about a) those other 50 options; and > b) how those options are obtained. >=20 > So let's step back here for a moment and have someone from=20 > the DHCP community explain exactly how and when these options=20 > are sent to the client. Remember that those of us=20 > concentrating on NTP have only some idea how DHCP is sending=20 > these options. Does DHCP: > a) Send these options unsolicited when it is requested to=20 > send an IP address to be used by the client?; > b) Only send these options when requested by the client?; > c) something else? >=20 > When does the client send/receive the request? > a) Upon boot > b) upon lease renew > c) some other time? >=20 > Except for a) the NTP server is not going to be taking any=20 > options from the DHCP server unless some other mechanism=20 > (which NTP has not designed) tells it to. That means that the=20 > NTP can be up for months never updating it's list of NTP=20 > server addresses. In the meantime, Server 1 has stopped=20 > running, Server 2 has moved to a different address, Server 3=20 > was always suspect. DCHP has no say in what to do about this,=20 > at least so far. DNS at least provides a way of getting a=20 > fresh set of addresses. >=20 > Danny >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 21 03:18:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iukn0-0008JC-G1; Wed, 21 Nov 2007 03:18:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iukmx-0008J6-GA for dhcwg@ietf.org; Wed, 21 Nov 2007 03:18:27 -0500 Received: from mout.perfora.net ([74.208.4.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iukmw-0007mh-Uu for dhcwg@ietf.org; Wed, 21 Nov 2007 03:18:27 -0500 Received: from IBM52A5038A94F ([88.235.56.154]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Iukms0Ak5-00006O; Wed, 21 Nov 2007 03:18:25 -0500 From: "Alper Yegin" To: "'Kim Kinnear'" Date: Wed, 21 Nov 2007 10:18:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AcgojklI8Y9Jk3dtRwCIzj291QcNOQDiKcbA Message-Id: <0MKpCa-1Iukms0Ak5-00006O@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18hMaCQOt3SuGpAGBFHH7cgC4KPknspva1M3Zq 0KZTOkLURXQ8Rr9m+GIJFkgJvFO9wJgukE9Vh0Z/B9u3Dmkqw5 JmyU5iptVFXgjnDt4a6qg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: dhcwg@ietf.org Subject: [dhcwg] RE: I-D Action:draft-ietf-dhc-agent-vpn-id-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi Kim, What is the applicability of this option to DHCPv6? Alper > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, November 16, 2007 10:20 PM > To: i-d-announce@ietf.org > Cc: dhcwg@ietf.org > Subject: I-D Action:draft-ietf-dhc-agent-vpn-id-05.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Dynamic Host Configuration Working Group > of the IETF. > > > Title : Virtual Subnet Selection Sub-Option for the Relay > Agent Information Option for DHCPv4 > Author(s) : K. Kinnear, et al. > Filename : draft-ietf-dhc-agent-vpn-id-05.txt > Pages : 11 > Date : 2007-11-16 > > In some environments, a relay agent resides in a network element > which also has access to one or more virtual private networks (VPNs). > If a DHCP server wishes to offer service to DHCP clients on those > different VPNs the DHCP server needs to know information about the > VPN on which each client resides. The Virtual Subnet Selection sub- > option of the relay-agent-information option is used by the relay > agent to tell the DHCP server important information about the VPN > (called the Virtual Subnet Selection information, or VSS) for every > DHCP request it passes on to the DHCP server, and is also used to > properly forward any DHCP reply that the DHCP server sends back to > the relay agent. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-vpn-id-05.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-dhc-agent-vpn-id-05.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-dhc-agent-vpn-id-05.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 21 03:39:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iul76-0001lH-3w; Wed, 21 Nov 2007 03:39:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iul74-0001lA-Va for dhcwg@ietf.org; Wed, 21 Nov 2007 03:39:14 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iul71-0004oK-Da for dhcwg@ietf.org; Wed, 21 Nov 2007 03:39:14 -0500 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lAL8blBv007898 for ; Wed, 21 Nov 2007 09:37:47 +0100 Received: from [172.17.245.127] ([172.17.245.127]) by FRVELSBHS07.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 21 Nov 2007 09:39:10 +0100 Message-ID: <4743EEAD.4040105@alcatel-lucent.be> Date: Wed, 21 Nov 2007 09:39:09 +0100 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2007 08:39:10.0252 (UTC) FILETIME=[FC863EC0:01C82C19] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [dhcwg] comments L2 Relay Agent Information X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi, I have some comments on draft-joshi-dhc-l2ra-00: 1) section 4.1.1 in point 3 and 6 says that the L2 relay agent looks to the broadcast flag to see if has to broadcast or to unicast. Is this not the task of the DHCP server or L3 relay agent? Would there be any reason why the L2 relay agent should also inspect the broadcast flag? Is it not enough that the L2 relay agent just looks to the destination MAC address? 2) point 3 in 4.1.1 says that the L2 relay agent removes the relay agent information option. As far as I know, this is not mandatory for L3 relay agents (and I have seen implementations that do not remove it), so should it for L2 relay agents also not be something optional? 3) point 4 in 4.1.1: A L2 relay agent uses the RAI to find out if it has appended the RAI or not. There is not really a requirement that the content of the RAI must be unique per access link network-wide. For instance, if the circuit-id contains a string indicating the slot and port number of the link, then the same circuit-id can be used by multiple L2 relay agents. The DSL Forum has solved this by adding a DSLAM-ID to the string of the suboptions of the RAI in their suggested format of the string. It would be therefore better to add the word "usually" just like it is done in 3 and 6 where the L2RA "usually" find the outgoing port based on the RAI, because there are other means as well. 4) Section 4.3.2, point 1: this is not really a new issue when there is a L3 relay agent and is already mentioned in 4.1.2. Some typos: - section 3, point 1: position instead of postion - I do not understand 3rd sentence in section 3, point 2: "This helps in preventing the Layer 2 and Layer 3...." - section 4.3 line 3: "...its seen.." -> "...it is seen..." regards, Stefaan _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 21 08:12:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IupNT-0007rL-K2; Wed, 21 Nov 2007 08:12:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IupNS-0007pO-2Z for dhcwg@ietf.org; Wed, 21 Nov 2007 08:12:26 -0500 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IupNP-0004N4-La for dhcwg@ietf.org; Wed, 21 Nov 2007 08:12:26 -0500 Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lALDCMVx025106; Wed, 21 Nov 2007 13:12:22 GMT Received: from [129.148.226.18] (sr1-unsh01-06.East.Sun.COM [129.148.226.18]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lALDCLki043002; Wed, 21 Nov 2007 08:12:21 -0500 (EST) Message-ID: <47442EB4.1010100@sun.com> Date: Wed, 21 Nov 2007 08:12:20 -0500 From: Brian Utterback User-Agent: Thunderbird 2.0.0.10pre (X11/20071118) MIME-Version: 1.0 To: Danny Mayer Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <4743B810.9030100@ntp.org> In-Reply-To: <4743B810.9030100@ntp.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Danny Mayer wrote: > If you want to use the DHCP server essentially as a resolver (it looks > up the addresses and sends them to the NTP server) that's fine except > there's no mechanism currently in place to do that. > > Danny Well, certainly we would need a way to update the servers used by ntpd. The obvious choice is to restart, but the requests I made to the hackers list for arbitrary command line config specification was specifically to allow just such a mechanism for update be available to the O/S when new servers came in via DHCP. -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 21 10:01:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iur4x-0007VY-Kd; Wed, 21 Nov 2007 10:01:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iur4w-0007VO-Nt for dhcwg@ietf.org; Wed, 21 Nov 2007 10:01:26 -0500 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iur4t-0007ho-42 for dhcwg@ietf.org; Wed, 21 Nov 2007 10:01:26 -0500 Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lALF1J6L017944; Wed, 21 Nov 2007 15:01:20 GMT Received: from [129.148.226.18] (sr1-unsh01-06.East.Sun.COM [129.148.226.18]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lALF1IN5062596; Wed, 21 Nov 2007 10:01:19 -0500 (EST) Message-ID: <4744483E.6080304@sun.com> Date: Wed, 21 Nov 2007 10:01:18 -0500 From: Brian Utterback User-Agent: Thunderbird 2.0.0.10pre (X11/20071118) MIME-Version: 1.0 To: "David L. Mills" Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <4743B902.3030406@udel.edu> In-Reply-To: <4743B902.3030406@udel.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Dave, I think you misunderstood. By saying the "hard-coded address" sceanrio as "not very likely" I meant that a DHCP caused fiasco like the Netgear/Wisc. one was not likely, even if IP addresses are supplied in the DHCP field. In other words, we are once again in violent agreement here. David L. Mills wrote: > Brian, > > Trying to put out fires when the network is burning is a good excercise > in fault containment. When the DNS is broken and the repair party > arrives, it's good to know the gateway works even if DNS doesn't. I'm > not sure this exactly applies to NTP, but I sure would like to see the > NTP servers options include hard coded addresses. > > Dave > > Brian Utterback wrote: > >> Danny Mayer wrote: >> >>> There is *no* avantage to not sending a FQDN and plenty of disadvantages >>> to not doing so. >>> Would you like a list of vendors who have hardcoded IP addresses into >>> their devices without >>> permission of the operator of that NTP server causing headaches for not >>> just the owner of the >>> NTP Server but also for the users of those devices? The NTP reference >>> implementation expects >>> the existence of a resolver so you haven't gained anything. >>> >> As already noted, there is an advantage, namely that the client does >> not have to have a resolver. And even if the reference implementation >> requires one (Is that really true? Even if no name resolution is >> required?) DHCP should remain implementation agnostic. >> >> As far the "hard coded address" problem goes, I don't see that >> scenario as very likely. DHCP clients don't tend to remain up >> for very long periods. And you don't have the same IP addresses >> being served by thousands of DHCP servers. The thing to be careful >> of is that the DHCP server not be embedded and replicated with hard >> coded addresses, not that the clients only get IP addresses. >> >> That having been said, I would like to see a way to pass a FQDN >> as an option, perhaps passing both. Then you could have logic >> like "Here's both, use the name if you can, and use the address if >> you must." >> > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 21 10:19:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurMD-0000EO-Lt; Wed, 21 Nov 2007 10:19:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurMB-0000EB-Ic for dhcwg@ietf.org; Wed, 21 Nov 2007 10:19:15 -0500 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IurM7-0008B3-Uv for dhcwg@ietf.org; Wed, 21 Nov 2007 10:19:15 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=dBDyRe0W9TwJ9i7T1EPvtEshxUgA5G2g2JlFthETqaTLZzMmCIJeR9EAjX+uyk3L; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IurM6-0002nW-9B; Wed, 21 Nov 2007 10:19:10 -0500 Message-ID: <008501c82c51$dd9c99e0$6401a8c0@tsg1> From: "TS Glassey" To: "Danny Mayer" , "Ralph Droms" References: <4733482A.7020302@sun.com> <4735A243.6090905@sun.com><47368636.3070007@udel.edu> <4736F7A7.2090707@sun.com><473D1BEB.1090102@ntp.org><4DE1A6EA-10E5-4707-AD34-28C95153EF6D@cisco.com> <473DB834.4040606@ntp.org> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options forDHCPv6 Date: Wed, 21 Nov 2007 07:18:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79a8c29a1dc2e62dfb35c48ba8bad0bf57350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Brian Utterback , "Richard Gayraud \(\(rgayraud\)\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org ----- Original Message ----- From: "Danny Mayer" To: "Ralph Droms" Cc: ; ; "Brian Utterback" ; "Richard Gayraud ((rgayraud))" Sent: Friday, November 16, 2007 7:33 AM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options forDHCPv6 > Ralph Droms wrote: >> DHCPv6 does not use IPSEC between the client and the server. Rather, >> it uses a shared key for authentication and message verification. >> >> It is possible to use IPSEC between a relay agent and a server. >> > > Thanks for the correction. As long as the shared key authentication does > not depend on a valid time in any way then this is fine. That potentially eliminates the use of KRB5 Tokens > > Danny >> - Ralph >> >> On Nov 15, 2007, at Nov 15, 2007,11:26 PM, Danny Mayer wrote: >> >>> Brian Utterback wrote: >>>> Interesting. I agree that a key needs to be specified somehow, but it >>>> is not clear to me how to do it. We have to assume that the client >>>> does not have the same NTP keys. However, we would like a way to >>>> specify a server and keys securely, so that the security of the >>>> network depends only on the security of DHCP. Again I am not up to >>>> date, *is* there a secure DHCP? If so, then how to get keys to the >>>> clients becomes an issue. >>> >>> DHCPv6 uses IPSEC for security. However, as I pointed out in my own >>> response, if you are provisioning an NTP server then it means that NTP >>> is not running at the time and any security that requires reasonably >>> close timestamps at both ends is likely to fail. >>> >>> Danny >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dhcwg >> > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 21 10:35:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurbT-0002uN-Qi; Wed, 21 Nov 2007 10:35:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurbR-0002mG-97 for dhcwg@ietf.org; Wed, 21 Nov 2007 10:35:01 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IurbO-0000IP-1s for dhcwg@ietf.org; Wed, 21 Nov 2007 10:35:01 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=CKcwm+rc4rq09vIyfwWYgrA0646/wDq2pq5l0lVe0LlZT5Th1BUG+FdAdNyO+XpY; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IurbM-0000V8-Mv; Wed, 21 Nov 2007 10:34:56 -0500 Message-ID: <009201c82c54$11cd6e90$6401a8c0@tsg1> From: "TS Glassey" To: "Brian Utterback" , "Danny Mayer" References: <4733482A.7020302@sun.com><473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma><474114E3.9040309@ntp.org> <474198BA.3000109@sun.com><4743B810.9030100@ntp.org> <47442EB4.1010100@sun.com> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 Date: Wed, 21 Nov 2007 07:34:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7975b35a67f057947f6f887edc7fed968d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Seems like there are two ways to deal with this, either define a set of pre-existing names and services ala RFC1918 type thingee or through some lookup process in DHCP. Either way it seems that this also plugs into the NEA functionality as well. Todd ----- Original Message ----- From: "Brian Utterback" To: "Danny Mayer" Cc: ; ; "Ted Lemon" ; "Richard Gayraud (rgayraud)" Sent: Wednesday, November 21, 2007 5:12 AM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 > > > Danny Mayer wrote: > >> If you want to use the DHCP server essentially as a resolver (it looks >> up the addresses and sends them to the NTP server) that's fine except >> there's no mechanism currently in place to do that. >> >> Danny > > Well, certainly we would need a way to update the servers used by > ntpd. The obvious choice is to restart, but the requests I made to > the hackers list for arbitrary command line config specification > was specifically to allow just such a mechanism for update be > available to the O/S when new servers came in via DHCP. > > -- > blu > > "You've added a new disk. Do you want to replace your current > drive, protect your data from a drive failure or expand your > storage capacity?" - Disk management as it should be. > ---------------------------------------------------------------------- > Brian Utterback - Solaris RPE, Sun Microsystems, Inc. > Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 21 10:51:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iurr3-0007eL-RA; Wed, 21 Nov 2007 10:51:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iurr2-0007bB-FV for dhcwg@ietf.org; Wed, 21 Nov 2007 10:51:08 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iurr2-0005Gn-5o for dhcwg@ietf.org; Wed, 21 Nov 2007 10:51:08 -0500 Received: from [10.0.1.2] (cpe-67-9-133-15.austin.res.rr.com [67.9.133.15]) by toccata.fugue.com (Postfix) with ESMTP id 105C8BC4416; Wed, 21 Nov 2007 08:51:06 -0700 (MST) Message-Id: <7BB8EBF4-9CCA-4C34-86CD-CD8449F9BDE3@fugue.com> From: Ted Lemon To: "Benoit Lourdelet (blourdel)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Date: Wed, 21 Nov 2007 09:45:52 -0600 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <4741D057.4070703@ntp.org> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: DHC WG , Brian Utterback , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 21, 2007, at 1:06 AM, Benoit Lourdelet (blourdel) wrote: > So far, I cant find any IP service defined by an FQDN for DHCPv6. I was counting DHCPv4 options as well. Brian, many an unmaintainable, non-interoperating edifice has been built atop the "mechanism, not policy" fallacy. Danny, if your NTP server doesn't periodically check to see if its configuration file has changed, that seems like a bug to me; changing the DHCP protocol to address a bug in an NTP server seems like the wrong answer. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 21 11:11:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IusA8-0003Ye-LD; Wed, 21 Nov 2007 11:10:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IusA6-0003U2-Va for dhcwg@ietf.org; Wed, 21 Nov 2007 11:10:50 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IusA3-0001vc-DB for dhcwg@ietf.org; Wed, 21 Nov 2007 11:10:50 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Nov 2007 11:10:37 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lALGAbcn029181; Wed, 21 Nov 2007 11:10:37 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lALGAOKl020880; Wed, 21 Nov 2007 16:10:32 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 11:10:14 -0500 Received: from [10.86.242.134] ([10.86.242.134]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 11:10:14 -0500 Message-ID: <47445863.4000208@cisco.com> Date: Wed, 21 Nov 2007 11:10:11 -0500 From: Mark Stapp User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "David L. Mills" Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <4743B902.3030406@udel.edu> In-Reply-To: <4743B902.3030406@udel.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2007 16:10:14.0507 (UTC) FILETIME=[0013D3B0:01C82C59] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2771; t=1195661437; x=1196525437; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20[ntpwg]=20[dhcwg]=20Re=3A=20Network=20Time=20Protocol =20(NTP)=20Options=09for=09DHCPv6 |Sender:=20 |To:=20=22David=20L.=20Mills=22=20; bh=l3y7QzxyPfJTDZ6wvA2AVBPtbpwYGO23sbZtL+OMVF4=; b=LmDsFmlBG42P2BwsH/NCrwFVrahDHira4i6q+BJZGGcoUytKnwK2pGoY7gHmyh4fdJjVCSRN uQJeeJrDU1dUOPUHqqN+pgTth0aPrxFtEFOFCtcvmwIiVY05gRn9imld; Authentication-Results: rtp-dkim-2; header.From=mjs@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org yes, this is another reason why the DHCP folks have generally used addresses in options. it just removes a dependency among the various clients in the system, and it doesn't usually have any significant drawback. there seems to be a concern that delivering addresses via DHCP somehow makes them difficult to update over time. just to reiterate: it's often the case that the information at the DHCP server is updated. the updated information flows out to clients as they renew. if the lease timers were very long, a client who got NTP addresses and found itself having trouble with them all could also use the INFORMATION-REQUEST message to check whether the addresses were still valid, outside of the normal renewal timers. -- Mark David L. Mills wrote: > Brian, > > Trying to put out fires when the network is burning is a good excercise > in fault containment. When the DNS is broken and the repair party > arrives, it's good to know the gateway works even if DNS doesn't. I'm > not sure this exactly applies to NTP, but I sure would like to see the > NTP servers options include hard coded addresses. > > Dave > > Brian Utterback wrote: > >> >> Danny Mayer wrote: >> >>> There is *no* avantage to not sending a FQDN and plenty of disadvantages >>> to not doing so. >>> Would you like a list of vendors who have hardcoded IP addresses into >>> their devices without >>> permission of the operator of that NTP server causing headaches for not >>> just the owner of the >>> NTP Server but also for the users of those devices? The NTP reference >>> implementation expects >>> the existence of a resolver so you haven't gained anything. >>> >> >> As already noted, there is an advantage, namely that the client does >> not have to have a resolver. And even if the reference implementation >> requires one (Is that really true? Even if no name resolution is >> required?) DHCP should remain implementation agnostic. >> >> As far the "hard coded address" problem goes, I don't see that >> scenario as very likely. DHCP clients don't tend to remain up >> for very long periods. And you don't have the same IP addresses >> being served by thousands of DHCP servers. The thing to be careful >> of is that the DHCP server not be embedded and replicated with hard >> coded addresses, not that the clients only get IP addresses. >> >> That having been said, I would like to see a way to pass a FQDN >> as an option, perhaps passing both. Then you could have logic >> like "Here's both, use the name if you can, and use the address if >> you must." >> > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 21 11:43:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iusfc-0005Tx-7o; Wed, 21 Nov 2007 11:43:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iusfb-0005Ts-ID for dhcwg@ietf.org; Wed, 21 Nov 2007 11:43:23 -0500 Received: from sfovwl03.infy.com ([216.251.50.9] helo=SFOVWL03.infosys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IusfX-0002vT-R5 for dhcwg@ietf.org; Wed, 21 Nov 2007 11:43:23 -0500 Received: from indhubbhs01.ad.infosys.com ([192.168.200.81]) by SFOVWL03.infosys.com with InterScan Message Security Suite; Wed, 21 Nov 2007 08:41:48 -0800 Received: from blrkechub02.ad.infosys.com ([10.66.236.42]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Nov 2007 22:13:14 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub02.ad.infosys.com ([10.66.236.42]) with mapi; Wed, 21 Nov 2007 22:13:14 +0530 From: Bharat Joshi To: "'dhcwg@ietf.org'" Date: Wed, 21 Nov 2007 22:13:00 +0530 Subject: RE: [dhcwg] comments L2 Relay Agent Information Thread-Topic: [dhcwg] comments L2 Relay Agent Information Thread-Index: AcgsGhujs2q1JEjmQxKa38KdB45/awAQb6AA Message-ID: <31D55C4D55BEED48A4459EB64567589A0AE064A8D2@BLRKECMBX02.ad.infosys.com> References: <4743EEAD.4040105@alcatel-lucent.be> In-Reply-To: <4743EEAD.4040105@alcatel-lucent.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Nov 2007 16:43:14.0235 (UTC) FILETIME=[9C1658B0:01C82C5D] X-Spam-Score: -4.0 (----) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi Stefaan, Thanks for your comments. Please see my response in line. Thanks, Bharat > 1) section 4.1.1 in point 3 and 6 says that the L2 relay agent looks to > the broadcast flag to see if has to broadcast or to unicast. Is this > not the task of the DHCP server or L3 relay agent? Would there be any > reason why the L2 relay agent should also inspect the broadcast flag? > Is it not enough that the L2 relay agent just looks to the destination > MAC address? > Yes. You are correct. A L2 RA would not need to look at the broadcast flag= at all. We shall correct this in our next revision. > 2) point 3 in 4.1.1 says that the L2 relay agent removes the relay agent > information option. As far as I know, this is not mandatory for L3 > relay agents (and I have seen implementations that do not remove it), so > should it for L2 relay agents also not be something optional? As per RFC 3046 whoever has added relay agent information option MUST= remove it. Section 2.1 of RFC 3046: The Relay Agent Information option echoed by a server MUST be removed by= either the relay agent or the trusted downstream network element which= added it when forwarding a server-to-client response back to the client. > 3) point 4 in 4.1.1: A L2 relay agent uses the RAI to find out if it has > appended the RAI or not. There is not really a requirement that the > content of the RAI must be unique per access link network-wide. For > instance, if the circuit-id contains a string indicating the slot and > port number of the link, then the same circuit-id can be used by > multiple L2 relay agents. The DSL Forum has solved this by adding a > DSLAM-ID to the string of the suboptions of the RAI in their suggested > format of the string. It would be therefore better to add the word > "usually" just like it is done in 3 and 6 where the L2RA "usually" find > the outgoing port based on the RAI, because there are other means as= well. > Yes. Adding 'Usually' will be helpful. After re-reading it, I think we need= to update it. > 4) Section 4.3.2, point 1: this is not really a new issue when there is > a L3 relay agent and is already mentioned in 4.1.2. Yes. They are essentially same but we just wanted to keep it at both the= places. It just shows that if a L3 RA does not snoop a unicast message,= DHCP server should echo back the option 82. > Some typos: > - section 3, point 1: position instead of postion > - I do not understand 3rd sentence in section 3, point 2: "This helps in > preventing the Layer 2 and Layer 3...." > - section 4.3 line 3: "...its seen.." -> "...it is seen..." > Will fix all of them in next revision. **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended= solely for the use of the addressee(s). If you are not the intended= recipient, please notify the sender by e-mail and delete the original= message. Further, you are not to copy, disclose, or distribute this e-mail= or its contents to any other person and any such actions are unlawful.= This e-mail may contain viruses. Infosys has taken every reasonable= precaution to minimize this risk, but is not liable for any damage you may= sustain as a result of any virus in this e-mail. You should carry out your= own virus checks before opening the e-mail or attachment. Infosys reserves= the right to monitor and review the content of all messages sent to or= from this e-mail address. Messages sent to or from this e-mail address may= be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 21 11:53:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuspf-0003cE-B5; Wed, 21 Nov 2007 11:53:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuspe-0003c2-Bf for dhcwg@ietf.org; Wed, 21 Nov 2007 11:53:46 -0500 Received: from [2001:4f8:3:bb:20c:76ff:fe16:4040] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuspd-0003MX-P0 for dhcwg@ietf.org; Wed, 21 Nov 2007 11:53:46 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id 639C55A6ED; Wed, 21 Nov 2007 08:53:23 -0800 (PST) Date: Wed, 21 Nov 2007 08:53:23 -0800 From: "David W. Hankins" To: DHC WG Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 Message-ID: <20071121165323.GC3291@isc.org> References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <4743B902.3030406@udel.edu> <47445863.4000208@cisco.com> Mime-Version: 1.0 In-Reply-To: <47445863.4000208@cisco.com> User-Agent: Mutt/1.5.9i X-Spam-Score: -0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "ntpwg@lists.ntp.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1747740323==" Errors-To: dhcwg-bounces@ietf.org --===============1747740323== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ILuaRSyQpoVaJ1HG" Content-Disposition: inline --ILuaRSyQpoVaJ1HG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 21, 2007 at 11:10:11AM -0500, Mark Stapp wrote: > very long, a client who got NTP addresses and found itself having=20 > trouble with them all could also use the INFORMATION-REQUEST message to= =20 > check whether the addresses were still valid, outside of the normal=20 > renewal timers. We have at least one DHCPv4 client that does this, and it is not adviseable. I don't want to get into a nuts and bolts 'thing' for the NTP people, we can talk about that on DHC separately if you like. The short version of my opinion is that it's preferrable to renew early, if you take any special action at all. If the operator selects a long lease time, without specifying a short renew time, they are selecting this behaviour by design. So an even better interpretation is to just wait the normal renew interval, even it is terribly long. No special action is best by far. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --ILuaRSyQpoVaJ1HG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHRGKDcXeLeWu2vmoRAgPlAKCrdf2FMo5U0YUjLj0zt3IyME49IgCffViu mzv+pDJAgGLrsgSNGycgAH4= =jCSv -----END PGP SIGNATURE----- --ILuaRSyQpoVaJ1HG-- --===============1747740323== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1747740323==-- From dhcwg-bounces@ietf.org Wed Nov 21 11:58:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IusuC-0000Wb-DB; Wed, 21 Nov 2007 11:58:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IusuA-0000WV-Qe for dhcwg@ietf.org; Wed, 21 Nov 2007 11:58:26 -0500 Received: from [2001:4f8:3:bb:20c:76ff:fe16:4040] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IusuA-0003Vm-HF for dhcwg@ietf.org; Wed, 21 Nov 2007 11:58:26 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id 7D5F07E03; Wed, 21 Nov 2007 08:58:26 -0800 (PST) Date: Wed, 21 Nov 2007 08:58:26 -0800 From: "David W. Hankins" To: DHC WG Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 Message-ID: <20071121165826.GD3291@isc.org> References: <47442EB4.1010100@sun.com> <009201c82c54$11cd6e90$6401a8c0@tsg1> Mime-Version: 1.0 In-Reply-To: <009201c82c54$11cd6e90$6401a8c0@tsg1> User-Agent: Mutt/1.5.9i X-Spam-Score: -0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ntpwg@lists.ntp.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1910107037==" Errors-To: dhcwg-bounces@ietf.org --===============1910107037== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sDKAb4OeUBrWWL6P" Content-Disposition: inline --sDKAb4OeUBrWWL6P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 21, 2007 at 07:34:49AM -0800, TS Glassey wrote: > Seems like there are two ways to deal with this, either define a set of= =20 > pre-existing names and services ala RFC1918 type thingee or through some= =20 > lookup process in DHCP. Either way it seems that this also plugs into the= =20 > NEA functionality as well. Isn't there already an 'all ntp servers' multicast address allocated? --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --sDKAb4OeUBrWWL6P Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHRGOycXeLeWu2vmoRAoaLAKC3CxEdOwNxwnoDQwei2Cvvf54qsQCgj9q+ Xav+Mi4jn50JkfThJWpTgmI= =YBwF -----END PGP SIGNATURE----- --sDKAb4OeUBrWWL6P-- --===============1910107037== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1910107037==-- From dhcwg-bounces@ietf.org Wed Nov 21 12:48:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IutgM-0006P2-F0; Wed, 21 Nov 2007 12:48:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IutgK-0006Ox-9p for dhcwg@ietf.org; Wed, 21 Nov 2007 12:48:12 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IutgJ-0001lk-Py for dhcwg@ietf.org; Wed, 21 Nov 2007 12:48:12 -0500 X-IronPort-AV: E=Sophos;i="4.21,447,1188770400"; d="scan'208";a="158443418" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2007 18:48:06 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lALHm5s4006878 for ; Wed, 21 Nov 2007 18:48:05 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lALHfGZx004862 for ; Wed, 21 Nov 2007 17:48:05 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 18:43:06 +0100 Received: from [192.168.1.102] ([10.86.240.14]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 18:43:06 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <6DCDA360-5BED-43C5-A5C3-030A7CF2EDC3@cisco.com> References: <6DCDA360-5BED-43C5-A5C3-030A7CF2EDC3@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ralph Droms Date: Wed, 21 Nov 2007 10:43:36 -0500 To: DHC WG X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 21 Nov 2007 17:43:06.0736 (UTC) FILETIME=[F9627F00:01C82C65] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3065; t=1195667286; x=1196531286; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20dhc=20WG=20meeting=20agenda |Sender:=20; bh=/lrZISKZkSdB9kz9U+o6icva8y2Va1r6H9s0TltSUgo=; b=dy0HjICquTUjNf3UaoSi4/9twmUHXNoNWPNQbA+44ZiDmsO7Rseg3Y9OAMmpFqMlebuPjOda ZeaWh6xfEgmEuui3hmyrStrPIhd9nbBuoEfxB66Iix1KoQvIkuDIprt2; Authentication-Results: ams-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [dhcwg] Re: dhc WG meeting agenda X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Latest revised draft included below... Note that we have a *very* tight schedule. Be sure to read the drafts prior to the WG meeting and be prepared with questions directed toward the desired WG action. Presenters - please avoid repeating details in your presentation that are spelled out in your I-D. Focus on high-level architecture, design questions and other issues related to the WG action. Forward your presentations (PDF preferred!) to dhc-chairs@tools.ietf.org by Wed, Nov 28, for posting to the IETF meeting materials page. - Ralph DHC WG DRAFT agenda - IETF 70 1300-1500 2007-12-04 (Tue) (Last revised 2007-11-21 10:35 AM ET) ------------------------------------- Administrivia Venaas/Droms 10 minutes Agenda bashing; blue sheets; scribe; Jabber scribe Draft last call and adoption announcements Venaas/Droms 05 minutes RFC 3942 status update B. Volz 05 minutes Progressing two drafts under RFC 3942 R. Droms 10 minutes Virtual Subnet Selection Option R. Johnson 05 minutes Review changes prior ot WG last call Virtual Subnet Selection RAIO Sub-Option K. Kinnear 05 minutes Review changes prior ot WG last call Container Option for Server Configuration R. Droms 10 minutes Accept as WG work item? DHCPv6 Bulk Leasequery M. Stapp 10 minutes Initial discussion Layer 2 Relay Agent Information B. Joshi 15 minutes Followup discussion of revised draft DHCPv6 Delegation of Certificates Option TBD 10 minutes Initial discussion for consideration as WG work item NTP Options for DHCPv6 B. Lourdelet 05 minutes Initial discussion and input to ntp WG Rebind Capability in DHCPv6 Reconfigure Msgs R. Droms 10 minutes Ready for WG last call? Service Identfiers List Option for DHCPv6 H. Deng 10 minutes Initial discussion for consideration as WG work item Neighbor Discovery Information over DHCP S. Krishnan 10 minutes Initial discussion for consideration as WG work item ----------- 120 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 21 14:10:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuuxC-0003pw-Q4; Wed, 21 Nov 2007 14:09:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuuxB-0003pq-Ko for dhcwg@ietf.org; Wed, 21 Nov 2007 14:09:41 -0500 Received: from whimsy.udel.edu ([128.4.2.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuuxA-0004LQ-E2 for dhcwg@ietf.org; Wed, 21 Nov 2007 14:09:41 -0500 Received: by whimsy.udel.edu (Postfix, from userid 62) id C41B216B8; Wed, 21 Nov 2007 19:09:39 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id 66BC2161A; Wed, 21 Nov 2007 19:09:35 +0000 (UTC) Message-ID: <4744826C.3070000@udel.edu> Date: Wed, 21 Nov 2007 19:09:32 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: DHC WG , "ntpwg@lists.ntp.org" Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <20071119225643.GI14750@isc.org> In-Reply-To: <20071119225643.GI14750@isc.org> X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org David, The true story of the U. Wisconsiin incident, along with others at NIST and USNO, is in: Mills, D.L., J. Levine, R. Schmidt and D. Plonka. Coping with overload on the Network Time Protocol public servers. Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting (Washington DC, December 2004), 5-16. The paper is also on the web: www.eecis.udel.edu/~mills/papers.html. So far as I know, Netgear had no plans to sue U. Wisconsin or the ISP. However, my very strong advice to U. Wisconsin was to sue Netgear. The incidents are what prompted the in-your-face practices in the latest SNTP RFC, as well as the traffic grooming and Kiss-o'Death response in recent NTP distributions. I don't know what the argument is about with respect to IPV4 and NAT. I would assume best practice would be for the firewall to run NTP and provide its nonroutable IPv4 address behind the firewall. In principle, it could hand out a routable IPv4 (or IPv6) address of an outside server and translate only the return address. Frankly, I would rather the SOHO do broadcast, rather than be stung by a raft of clients. Dave David W. Hankins wrote: > On Mon, Nov 19, 2007 at 08:58:26AM -0600, Ted Lemon wrote: > >> There's no reason why this option should use FQDNs while the other fifty >> use IP addresses, and there are a number of good reasons not to send >> FQDNs, the first and most obvious of which is that they take up more >> space in the packet, and space in the packet is very limited. > > > There is a concern of which I am aware among the NTP users community > concerning a recent catastrophic event which I think I am reading > in the subtext of this thread. Lets find out. > > A SOHO router manufacturer latched onto the IPv4 address (not the > domain name) of a particular open-to-the-public NTP clock. The > IPv4 address was hard-coded into their firmware. > > Upon the release of this product, said clock was slowly subjected to > what grew into an Entire-Internet scale distributed DDOS. > > The operator responsible for the NTP device at said IPv4 address was > not willing nor capable of continuing to supply free bandwidth and > hardened NTP servers to meet this SOHO router manufacturer's global > clocking needs, certainly not free of charge, and ultimately had to > readdress his clock. I seem to recall he was actually sued by the > SOHO router manufacturer, because all their SOHO routers suddenly > started spitting errors and misbehaving when this free service was > withheld, but my memory is beyond its limits at this point. > > > So it is possible that the community may strongly desire an otherwise > unusual number of intermediaries between /etc/ntp.conf and the IPv4 > addresses they determine. > > DHCP is an excellent solution, because it is likely that this SOHO > router was in fact obtaining its own IP address via DHCPv4, so if > it also received its clock via DHCPv4 rather than being hard- > coded, there would never have been a problem to solve. > > IPv4 addresses via DHCP are possibly a worse solution, however, > because if it does deliver fixed IPv4 addresses to clients, then a NAT > box acting as a home gateway is a greater operational danger than the > above; imagine if this SOHO router manufacturer had decided to deliver > the fixed IPv4 address they had selected via DHCPv4 to all its > NAT-side clients, in all homes its clones resided, worldwide. > > > So if the DHCP protocol field required RFC1035 syntax, an IPv4 address > becomes an illegal configuration format, and that may be a desirable > outcome to a segment of the operational community that is concerned > with the historic stickyness of their IPv4 addresses, and the tendency > to get sued for publishing one. > > I do not make a judgement at this time, but I would like to caution > the NTP community that additional intermediaries will not necessarily > correct bad behaviour. In example, putting your clock's location in > DNS resolution into A/AAAA records does not mean a SOHO router > manufacturer can not / will not resolve those addresses and then > hard-code them into products. > > I would also like to suggest that some of these concerns may be > mitigated by tracking Ralph Drom's recent 'container option' draft, > wherein a SOHO router may dynamically receive from an 'upstream' > DHCPv6 server the configuration values it should give 'downstream' > DHCPv6 clients. > > I'm not aware of an equivalent for DHCPv4 however. > > > So cautioned, I personally leave it up to the NTP community to > prove to us exactly to what extent it is genuinely useful to have > such intermediaries as DNS (or even DHCP, even if I consider that > a given) involved. > > > ------------------------------------------------------------------------ > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 21 14:19:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuv6b-0004CB-1L; Wed, 21 Nov 2007 14:19:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuv6Z-0004C4-Qe for dhcwg@ietf.org; Wed, 21 Nov 2007 14:19:23 -0500 Received: from whimsy.udel.edu ([128.4.2.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuv6Z-0004f7-AC for dhcwg@ietf.org; Wed, 21 Nov 2007 14:19:23 -0500 Received: by whimsy.udel.edu (Postfix, from userid 62) id D316E167E; Wed, 21 Nov 2007 19:19:22 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id 072D4161A; Wed, 21 Nov 2007 19:19:21 +0000 (UTC) Message-ID: <474484B6.2030403@udel.edu> Date: Wed, 21 Nov 2007 19:19:18 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: DHC WG , ntpwg@lists.ntp.org Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 References: <47442EB4.1010100@sun.com> <009201c82c54$11cd6e90$6401a8c0@tsg1> <20071121165826.GD3291@isc.org> In-Reply-To: <20071121165826.GD3291@isc.org> X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org David, Yes; the IANA has allocated IPv4 and IPv6 addresses for multicast NTP. Most of our department servers and clients use them. Dave David W. Hankins wrote: > On Wed, Nov 21, 2007 at 07:34:49AM -0800, TS Glassey wrote: > >> Seems like there are two ways to deal with this, either define a set of >> pre-existing names and services ala RFC1918 type thingee or through some >> lookup process in DHCP. Either way it seems that this also plugs into >> the >> NEA functionality as well. > > > Isn't there already an 'all ntp servers' multicast address allocated? > > > ------------------------------------------------------------------------ > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 21 14:37:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuvO5-0002Sf-12; Wed, 21 Nov 2007 14:37:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuvO3-0002LW-5X for dhcwg@ietf.org; Wed, 21 Nov 2007 14:37:27 -0500 Received: from exchdev.pega.com ([198.22.153.35] helo=exchdev.rpega.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuvO2-0005Eo-SL for dhcwg@ietf.org; Wed, 21 Nov 2007 14:37:27 -0500 Received: from [10.60.98.36] ([10.60.98.36]) by exchdev.rpega.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 14:37:20 -0500 Message-ID: <4744884F.70200@ntp.org> Date: Wed, 21 Nov 2007 14:34:39 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "David W. Hankins" Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 References: <47442EB4.1010100@sun.com> <009201c82c54$11cd6e90$6401a8c0@tsg1> <20071121165826.GD3291@isc.org> In-Reply-To: <20071121165826.GD3291@isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2007 19:37:20.0980 (UTC) FILETIME=[EED52140:01C82C75] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ntpwg@lists.ntp.org, DHC WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org David W. Hankins wrote: > On Wed, Nov 21, 2007 at 07:34:49AM -0800, TS Glassey wrote: >> Seems like there are two ways to deal with this, either define a set of >> pre-existing names and services ala RFC1918 type thingee or through some >> lookup process in DHCP. Either way it seems that this also plugs into the >> NEA functionality as well. > > Isn't there already an 'all ntp servers' multicast address allocated? FF02::101 and FF05::101 are reserved for link-local and site-local. Actually the whole FFxx::101 space is reserved for NTP. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 21 19:23:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuzqD-0000li-PF; Wed, 21 Nov 2007 19:22:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuzqC-0000ld-MC for dhcwg@ietf.org; Wed, 21 Nov 2007 19:22:48 -0500 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuzqC-0002EE-AI for dhcwg@ietf.org; Wed, 21 Nov 2007 19:22:48 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=jLEoyltlf2OdLo+XW+R1IhSPFGzw4ukNE4Jps3zHGvHudARD2jrgkq27E8NPWE9X; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IuzqA-0002IT-0p; Wed, 21 Nov 2007 19:22:46 -0500 Message-ID: <001801c82c9d$ce250780$6401a8c0@tsg1> From: "TS Glassey" To: "Ted Lemon" , "Harlan Stenn" References: <20071121052610.DD3EF39E3F@mail1.ntp.org> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options forDHCPv6 Date: Wed, 21 Nov 2007 16:05:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79b3ccb8fab3432bb809c7ae5479e6de74350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ntpwg@lists.ntp.org, "Richard Gayraud \(rgayraud\)" , dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org ----- Original Message ----- From: "Harlan Stenn" To: "Ted Lemon" Cc: ; "Danny Mayer" ; "Richard Gayraud (rgayraud)" ; Sent: Tuesday, November 20, 2007 9:24 PM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options forDHCPv6 > Guys, > > Is this about mechanism or policy? Both > > I would suspect (and hope) it is about mechanism. > > In that case one must be able to "offer" either a name or an IPv4 > address or an IPv6 address. > > If one *also* wishes to address policy issues, that's OK (IMO). > > But (again IMO) the underlying mechanism needs to support names and/or > addresses. true. > > H > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 23 22:49:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivm1R-0007g2-IV; Fri, 23 Nov 2007 22:49:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivm1Q-0007cC-8d for dhcwg@ietf.org; Fri, 23 Nov 2007 22:49:36 -0500 Received: from mx04.gis.net ([208.218.130.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivm1N-0001wk-RY for dhcwg@ietf.org; Fri, 23 Nov 2007 22:49:36 -0500 Received: from [10.10.10.100] ([63.209.224.211]) by mx04.gis.net; Fri, 23 Nov 2007 22:49:00 -0500 Message-ID: <47479E8B.2060107@ntp.org> Date: Fri, 23 Nov 2007 22:46:19 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "David W. Hankins" Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <20071119225643.GI14750@isc.org> In-Reply-To: <20071119225643.GI14750@isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: "ntpwg@lists.ntp.org" , DHC WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org David W. Hankins wrote: > So it is possible that the community may strongly desire an otherwise > unusual number of intermediaries between /etc/ntp.conf and the IPv4 > addresses they determine. > No, we don't want that, we want to ensure that we don't repeat the mistake of hardware manufacturers (and for that matter software developers) embedding fixed addresses in their implementations. > So if the DHCP protocol field required RFC1035 syntax, an IPv4 address > becomes an illegal configuration format, and that may be a desirable > outcome to a segment of the operational community that is concerned > with the historic stickyness of their IPv4 addresses, and the tendency > to get sued for publishing one. > This is one of the problems that the NTP pool servers face. The pool DNS servers pass out different addresses on a regular basis but the NTP clients are hanging onto the addresses. One of my urgent projects is to get at least the reference implementation of ntpd to do another DNS lookup in case the NTP server is not responding after a specified number of request packets don't get a response. Pool servers that get removed from the pool are continuing to receive NTP request packets for a very long time. We cannot do anything about third-party clients but we can certainly have the reference implementation do the right thing. The new pool configuration option is also helpful because it now makes use of multiple IP addresses returned by the DNS lookup. > I do not make a judgement at this time, but I would like to caution > the NTP community that additional intermediaries will not necessarily > correct bad behaviour. In example, putting your clock's location in > DNS resolution into A/AAAA records does not mean a SOHO router > manufacturer can not / will not resolve those addresses and then > hard-code them into products. Agreed. > I would also like to suggest that some of these concerns may be > mitigated by tracking Ralph Drom's recent 'container option' draft, > wherein a SOHO roFrom dhcwg-bounces@ietf.org Fri Nov 23 22:49:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivm1R-0007g2-IV; Fri, 23 Nov 2007 22:49:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivm1Q-0007cC-8d for dhcwg@ietf.org; Fri, 23 Nov 2007 22:49:36 -0500 Received: from mx04.gis.net ([208.218.130.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivm1N-0001wk-RY for dhcwg@ietf.org; Fri, 23 Nov 2007 22:49:36 -0500 Received: from [10.10.10.100] ([63.209.224.211]) by mx04.gis.net; Fri, 23 Nov 2007 22:49:00 -0500 Message-ID: <47479E8B.2060107@ntp.org> Date: Fri, 23 Nov 2007 22:46:19 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "David W. Hankins" Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <20071119225643.GI14750@isc.org> In-Reply-To: <20071119225643.GI14750@isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: "ntpwg@lists.ntp.org" , DHC WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org David W. Hankins wrote: > So it is possible that the community may strongly desire an otherwise > unusual number of intermediaries between /etc/ntp.conf and the IPv4 > addresses they determine. > No, we don't want that, we want to ensure that we don't repeat the mistake of hardware manufacturers (and for that matter software developers) embedding fixed addresses in their implementations. > So if the DHCP protocol field required RFC1035 syntax, an IPv4 address > becomes an illegal configuration format, and that may be a desirable > outcome to a segment of the operational community that is concerned > with the historic stickyness of their IPv4 addresses, and the tendency > to get sued for publishing one. > This is one of the problems that the NTP pool servers face. The pool DNS servers pass out different addresses on a regular basis but the NTP clients are hanging onto the addresses. One of my urgent projects is to get at least the reference implementation of ntpd to do another DNS lookup in case the NTP server is not responding after a specified number of request packets don't get a response. Pool servers that get removed from the pool are continuing to receive NTP request packets for a very long time. We cannot do anything about third-party clients but we can certainly have the reference implementation do the right thing. The new pool configuration option is also helpful because it now makes use of multiple IP addresses returned by the DNS lookup. > I do not make a judgement at this time, but I would like to caution > the NTP community that additional intermediaries will not necessarily > correct bad behaviour. In example, putting your clock's location in > DNS resolution into A/AAAA records does not mean a SOHO router > manufacturer can not / will not resolve those addresses and then > hard-code them into products. Agreed. > I would also like to suggest that some of these concerns may be > mitigated by tracking Ralph Drom's recent 'container option' draft, > wherein a SOHO router may dynamically receive from an 'upstream' > DHCPv6 server the configuration values it should give 'downstream' > DHCPv6 clients. > We'd have to figure out how to integrate that if we were to do that. > I'm not aware of an equivalent for DHCPv4 however. > > > So cautioned, I personally leave it up to the NTP community to > prove to us exactly to what extent it is genuinely useful to have > such intermediaries as DNS (or even DHCP, even if I consider that > a given) involved. DNS is required for the pool configuration option. IP addresses are strongly discouraged from the server configuration option for the same reasons. The only time I can see allowing DHCP provided IP addresses is if those addresses are link-local or site-local. That way we'd guarantee that they were not going to bombard a remote NTP server with requests. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 23 22:49:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivm1b-0007sm-TZ; Fri, 23 Nov 2007 22:49:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivm1Z-0007sb-Vg for dhcwg@ietf.org; Fri, 23 Nov 2007 22:49:45 -0500 Received: from mx04.gis.net ([208.218.130.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivm1W-0001x0-L3 for dhcwg@ietf.org; Fri, 23 Nov 2007 22:49:45 -0500 Received: from [10.10.10.100] ([63.209.224.211]) by mx04.gis.net; Fri, 23 Nov 2007 22:48:53 -0500 Message-ID: <47479E84.8080309@ntp.org> Date: Fri, 23 Nov 2007 22:46:12 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "David W. Hankins" Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <4741D057.4070703@ntp.org> <20071119232225.GJ14750@isc.org> In-Reply-To: <20071119232225.GJ14750@isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "ntpwg@lists.ntp.org" , DHC WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org David W. Hankins wrote: > Yes. New values from the network always supplant older ones. How > to integrate this onto e.g. a Unix-like system is unclear, and > realistically many configuration values are "sticky" with running > applications (such as /etc/resolv.conf contents that are loaded > once when firefox starts and never again). > > So all of this is academic if your ntpd runs once at startup on > a laptop that "sleeps" rather than being shutdown, and never > reloads its configuratoin file with fresh values from the DHCP > client. > That's currently the situation with the reference implementation of ntpd. It gets its configuration information and doesn't go back. You can update some of the configuration information using ntpdc, changing servers for example, but it won't reread the config file itself right now. So for the DHCP client to have an influence on what it uses for servers it either needs to use ntpdc, send private mode 7 NTP packets, restart ntpd, or have some sort of interface futer may dynamically receive from an 'upstream' > DHCPv6 server the configuration values it should give 'downstream' > DHCPv6 clients. > We'd have to figure out how to integrate that if we were to do that. > I'm not aware of an equivalent for DHCPv4 however. > > > So cautioned, I personally leave it up to the NTP community to > prove to us exactly to what extent it is genuinely useful to have > such intermediaries as DNS (or even DHCP, even if I consider that > a given) involved. DNS is required for the pool configuration option. IP addresses are strongly discouraged from the server configuration option for the same reasons. The only time I can see allowing DHCP provided IP addresses is if those addresses are link-local or site-local. That way we'd guarantee that they were not going to bombard a remote NTP server with requests. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 23 22:49:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivm1b-0007sm-TZ; Fri, 23 Nov 2007 22:49:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivm1Z-0007sb-Vg for dhcwg@ietf.org; Fri, 23 Nov 2007 22:49:45 -0500 Received: from mx04.gis.net ([208.218.130.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivm1W-0001x0-L3 for dhcwg@ietf.org; Fri, 23 Nov 2007 22:49:45 -0500 Received: from [10.10.10.100] ([63.209.224.211]) by mx04.gis.net; Fri, 23 Nov 2007 22:48:53 -0500 Message-ID: <47479E84.8080309@ntp.org> Date: Fri, 23 Nov 2007 22:46:12 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "David W. Hankins" Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <4741D057.4070703@ntp.org> <20071119232225.GJ14750@isc.org> In-Reply-To: <20071119232225.GJ14750@isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "ntpwg@lists.ntp.org" , DHC WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org David W. Hankins wrote: > Yes. New values from the network always supplant older ones. How > to integrate this onto e.g. a Unix-like system is unclear, and > realistically many configuration values are "sticky" with running > applications (such as /etc/resolv.conf contents that are loaded > once when firefox starts and never again). > > So all of this is academic if your ntpd runs once at startup on > a laptop that "sleeps" rather than being shutdown, and never > reloads its configuratoin file with fresh values from the DHCP > client. > That's currently the situation with the reference implementation of ntpd. It gets its configuration information and doesn't go back. You can update some of the configuration information using ntpdc, changing servers for example, but it won't reread the config file itself right now. So for the DHCP client to have an influence on what it uses for servers it either needs to use ntpdc, send private mode 7 NTP packets, restart ntpd, or have some sort of interface for ntpd to get updated values from the DHCP client. > Ostensibly you would want to have some closer integration with the > DHCP client to receive these configuration events in near real time. > See above. >> c) some other time? > > Both DHCP protocols include a mechanism to reconfigure/force the > renewal of configuration information causing a client to enter into > the renewal event at any time, but the DHCPv4 method is not well > deployed, and the DHCPv6 method is not clearly well used (to me, maybe > someone else will comment). Well, if ntpd can poke the DHCP client for new values, presumably it can request new values from the DHCP server to pass back to ntpd. That's not even defined. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg or ntpd to get updated values from the DHCP client. > Ostensibly you would want to have some closer integration with the > DHCP client to receive these configuration events in near real time. > See above. >> c) some other time? > > Both DHCP protocols include a mechanism to reconfigure/force the > renewal of configuration information causing a client to enter into > the renewal event at any time, but the DHCPv4 method is not well > deployed, and the DHCPv6 method is not clearly well used (to me, maybe > someone else will comment). Well, if ntpd can poke the DHCP client for new values, presumably it can request new values from the DHCP server to pass back to ntpd. That's not even defined. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Nov 24 21:18:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw74e-0007YC-Dv; Sat, 24 Nov 2007 21:18:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw74b-0007Y4-5Z for dhcwg@ietf.org; Sat, 24 Nov 2007 21:18:17 -0500 Received: from mx04.gis.net ([208.218.130.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iw74a-00050N-QD for dhcwg@ietf.org; Sat, 24 Nov 2007 21:18:17 -0500 Received: from [10.10.10.101] ([63.209.224.211]) by mx04.gis.net; Sat, 24 Nov 2007 21:17:56 -0500 Message-ID: <4748DAB1.2030506@ntp.org> Date: Sat, 24 Nov 2007 21:15:13 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Harlan Stenn Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 References: <20071121052610.DD3EF39E3F@mail1.ntp.org> In-Reply-To: <20071121052610.DD3EF39E3F@mail1.ntp.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Harlan Stenn wrote: > Guys, > > Is this about mechanism or policy? > > I would suspect (and hope) it is about mechanism. > > In that case one must be able to "offer" either a name or an IPv4 > address or an IPv6 address. > > If one *also* wishes to address policy issues, that's OK (IMO). > > But (again IMO) the underlying mechanism needs to support names and/or > addresses. Let me make an alternative suggestion which would make sense (at least to me). The IPv6 address sent by the server MUST be a site-local or link-local address or, for an IPv4 address a local LAN address as specified by the netmask. The client MUST ignore any addresses that don't meet this criteria. This way the DHCP admins are restricted to use only those NTP servers that the business owns and cannot configure one outside their own address spaces. Would this satisfy both sides? The other issues with the options we've already discussed and we leave open for now the issue of specifying NTP authentication keys for a separate discussion. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Nov 24 21:19:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw75S-0008M9-Vz; Sat, 24 Nov 2007 21:19:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw75R-0008Ly-U5 for dhcwg@ietf.org; Sat, 24 Nov 2007 21:19:09 -0500 Received: from mx04.gis.net ([208.218.130.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iw75R-00051O-Hh for dhcwg@ietf.org; Sat, 24 Nov 2007 21:19:09 -0500 Received: from [10.10.10.101] ([63.209.224.211]) by mx04.gis.net; Sat, 24 Nov 2007 21:19:05 -0500 Message-ID: <4748DAF7.9080705@ntp.org> Date: Sat, 24 Nov 2007 21:16:23 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mark Stapp Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <4743B902.3030406@udel.edu> <47445863.4000208@cisco.com> In-Reply-To: <47445863.4000208@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , "David L. Mills" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Mark Stapp wrote: > yes, this is another reason why the DHCP folks have generally used > addresses in options. it just removes a dependency among the various > clients in the system, and it doesn't usually have any significant > drawback. > > there seems to be a concern that delivering addresses via DHCP somehow > makes them difficult to update over time. just to reiterate: it's often > the case that the information at the DHCP server is updated. the updated > information flows out to clients as they renew. if the lease timers were > very long, a client who got NTP addresses and found itself having > trouble with them all could also use the INFORMATION-REQUEST message to > check whether the addresses were still valid, outside of the normal > renewal timers. > > -- Mark Mark, My biggest worry is the "set and forget" attitude of a system admin who has more than just NTP servers to worry about. The reality is that NTP is a long-running daemon on the client and unless something happens it will continue to query the same client, not just for days, but for months and even years. We can propose that the DHC client updates the NTP server but I have yet to see anything that proposes to do that. If the sysadmin sets up the list of NTP servers for the DHC client to use when is he/she going to go back and check if they are still valid? Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Nov 24 21:40:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw7QA-0001Ji-7z; Sat, 24 Nov 2007 21:40:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw7Q8-0001Av-MA for dhcwg@ietf.org; Sat, 24 Nov 2007 21:40:32 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iw7Q5-0001rf-8y for dhcwg@ietf.org; Sat, 24 Nov 2007 21:40:32 -0500 Received: from [10.0.1.2] (cpe-67-9-133-15.austin.res.rr.com [67.9.133.15]) by toccata.fugue.com (Postfix) with ESMTP id 2B542BC4373; Sat, 24 Nov 2007 19:40:28 -0700 (MST) Message-Id: <6EDC6595-CD66-490F-90FD-A730E4BF3360@fugue.com> From: Ted Lemon To: Danny Mayer In-Reply-To: <4748DAB1.2030506@ntp.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 Date: Sat, 24 Nov 2007 20:40:26 -0600 References: <20071121052610.DD3EF39E3F@mail1.ntp.org> <4748DAB1.2030506@ntp.org> X-Mailer: Apple Mail (2.915) X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "ntpwg@lists.ntp.org" , Harlan Stenn , "Richard Gayraud \(rgayraud\)" , "dhcwg@ietf.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 24, 2007, at 8:15 PM, Danny Mayer wrote: > Would this satisfy both sides? This is sort of like when a spendthrift congresscritter says "look, we want to take half of that national park for oil exploration, but you've objected that visitors to the park won't want to look at the oil derricks, so let's compromise: we'll take the *whole* park. That satisfies our needs, and satisfies your objection as well. There is simply no need for the kind of complexity you're proposing. The reason why DHCP is such a success is because it's a great place to put your client configuration control information. It works. Network administrators keep it up to date. Clients refresh their configurations periodically. The problem you're afraid will happen is not going to happen. Please stop trying to create additional complexity to deal with a problem that's not going to happen. The whole point of DHCP is to PREVENT the kind of problem you're worried about. You don't need to complexify it to accomplish your goals - it already accomplishes them! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Nov 24 23:09:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw8od-0006D3-Fb; Sat, 24 Nov 2007 23:09:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw8oc-0006Cx-Gk for dhcwg@ietf.org; Sat, 24 Nov 2007 23:09:54 -0500 Received: from mx04.gis.net ([208.218.130.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iw8oc-0006jk-2B for dhcwg@ietf.org; Sat, 24 Nov 2007 23:09:54 -0500 Received: from [10.10.10.101] ([63.209.224.211]) by mx04.gis.net; Sat, 24 Nov 2007 23:09:10 -0500 Message-ID: <4748F4C4.1090407@ntp.org> Date: Sat, 24 Nov 2007 23:06:28 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ted Lemon Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 References: <20071121052610.DD3EF39E3F@mail1.ntp.org> <4748DAB1.2030506@ntp.org> <6EDC6595-CD66-490F-90FD-A730E4BF3360@fugue.com> In-Reply-To: <6EDC6595-CD66-490F-90FD-A730E4BF3360@fugue.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: "ntpwg@lists.ntp.org" , Harlan Stenn , "Richard Gayraud \(rgayraud\)" , "dhcwg@ietf.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ted Lemon wrote: > On Nov 24, 2007, at 8:15 PM, Danny Mayer wrote: >> Would this satisfy both sides? > > This is sort of like when a spendthrift congresscritter says "look, we > want to take half of that national park for oil exploration, but you've > objected that visitors to the park won't want to look at the oil > derricks, so let's compromise: we'll take the *whole* park. That > satisfies our needs, and satisfies your objection as well. > Let's stop being silly about this shall we? NTP servers have a real problem and we want to be sure that proposals don't make the situation worse. > There is simply no need for the kind of complexity you're proposing. Of course there is. There have been enough DDOS attacks on NTP servers that we need to consider all of the ways that easy propogation of targets don't work. Just remember that DNSSEC took over 10 years to develop and is still in the starting stages of being rolled out. > The reason why DHCP is such a success is because it's a great place to > put your client configuration control information. It works. Network > administrators keep it up to date. Clients refresh their > configurations periodically. That's nice. But let's make sure that it doesn't cause problems when you do that. > The problem you're afraid will happen is > not going to happen. You're too late. It already has. We are already in the situation that we need to take defensive measures against existing errant NTP clients. > Please stop trying to create additional complexity to deal with a > problem that's not going to happen. The whole point of DHCP is to > PREVENT the kind of problem you're worried about. You don't need to > complexify it to accomplish your goals - it already accomplishes them! The minimal complexity suggested is necessary since DHCP will do *nothing* to prevent the kind of problem that I'm worried about. To the contrary it will most likely *cause* the problem. You don't see the problem, we have to live with it. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 07:50:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwGvy-0004Z4-Jk; Sun, 25 Nov 2007 07:50:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwGvx-0004VE-LE for dhcwg@ietf.org; Sun, 25 Nov 2007 07:50:01 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwGvt-000252-HX for dhcwg@ietf.org; Sun, 25 Nov 2007 07:50:01 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAPCnvit009954 for ; Sun, 25 Nov 2007 12:49:57 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS200F01BFOFM00@mail-amer.sun.com> (original mail from Brian.Utterback@Sun.COM) for dhcwg@ietf.org; Sun, 25 Nov 2007 05:49:57 -0700 (MST) Received: from [192.168.1.5] ([71.168.64.220]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS20006KBN71680@mail-amer.sun.com>; Sun, 25 Nov 2007 05:49:56 -0700 (MST) Date: Sun, 25 Nov 2007 07:49:55 -0500 From: Brian Utterback Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 In-reply-to: <4748F4C4.1090407@ntp.org> To: Danny Mayer Message-id: <47496F73.8040206@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <20071121052610.DD3EF39E3F@mail1.ntp.org> <4748DAB1.2030506@ntp.org> <6EDC6595-CD66-490F-90FD-A730E4BF3360@fugue.com> <4748F4C4.1090407@ntp.org> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) X-Spam-Score: -1.0 (-) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Danny Mayer wrote: > Ted Lemon wrote: > > >> The problem you're afraid will happen is >> not going to happen. >> > > You're too late. It already has. We are already in the situation that we > need to take defensive measures against existing errant NTP clients. > > No it hasn't. AFAIK, there has not been a case of multitudes of clients that received NTP server IP addresses from DHCP spamming servers abusively for extended periods of time. My gut feel is that Ted is correct and that this is not likely to be a problem. However, the fact that we have had other situations develop into just such problems means that examining the proposal for potential abuse scenarios is worthwhile. Before we start looking for a compromise solution, perhaps we should look more closely at the problem. For instance, I don't see the problem as being any worse than an ntp.conf file that has the server given by an IP address. If you are going to restrict DHCP, perhaps we should consider not allowing IP addresses in the ntp.conf file. If you think that is absurd, then perhaps the DHCP restriction is absurd as well. Or perhaps not. Brian Utterback _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 09:18:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwIJP-0004UP-Ng; Sun, 25 Nov 2007 09:18:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwIJO-0004UH-De for dhcwg@ietf.org; Sun, 25 Nov 2007 09:18:18 -0500 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwIJK-0004vf-KK for dhcwg@ietf.org; Sun, 25 Nov 2007 09:18:18 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Ms58D3aEeVYAQoYmAt8Gu7NCTL4XXMkqGU7e2iieGokW5rv/WXwuUlK8DfBE9jjk; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IwIJJ-0003RP-1l; Sun, 25 Nov 2007 09:18:13 -0500 Message-ID: <000701c82f6e$03795350$6401a8c0@tsg1> From: "TS Glassey" To: "Brian Utterback" , "Danny Mayer" References: <20071121052610.DD3EF39E3F@mail1.ntp.org><4748DAB1.2030506@ntp.org><6EDC6595-CD66-490F-90FD-A730E4BF3360@fugue.com><4748F4C4.1090407@ntp.org> <47496F73.8040206@sun.com> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 Date: Sun, 25 Nov 2007 06:18:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79dd87e95264c61e224f68ec085d6a26a1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Brian - "Likely" isn't something that Auditor's will let you resell as a commercial product. Likely means that the security model of NTP is broken. Time transfer MUST be assured and reliable or NTP is more of a curiosity than the key to the everything many of us believe it to be. Todd Glassey ----- Original Message ----- From: "Brian Utterback" To: "Danny Mayer" Cc: ; ; "Ted Lemon" ; "Richard Gayraud (rgayraud)" Sent: Sunday, November 25, 2007 4:49 AM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 > Danny Mayer wrote: >> Ted Lemon wrote: >> >> >>> The problem you're afraid will happen is >>> not going to happen. >>> >> >> You're too late. It already has. We are already in the situation that we >> need to take defensive measures against existing errant NTP clients. >> >> > > No it hasn't. AFAIK, there has not been a case of multitudes of clients > that received NTP server > IP addresses from DHCP spamming servers abusively for extended periods > of time. My gut feel > is that Ted is correct and that this is not likely to be a problem. > > However, the fact that we have had other situations develop into just > such problems means > that examining the proposal for potential abuse scenarios is worthwhile. > Before we start > looking for a compromise solution, perhaps we should look more closely > at the problem. > > For instance, I don't see the problem as being any worse than an > ntp.conf file that has > the server given by an IP address. If you are going to restrict DHCP, > perhaps we > should consider not allowing IP addresses in the ntp.conf file. If you > think that > is absurd, then perhaps the DHCP restriction is absurd as well. Or > perhaps not. > > Brian Utterback > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 14:53:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwNXA-0001Wj-NL; Sun, 25 Nov 2007 14:52:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwNX9-0001We-Jg for dhcwg@ietf.org; Sun, 25 Nov 2007 14:52:51 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwNX5-0005sk-PU for dhcwg@ietf.org; Sun, 25 Nov 2007 14:52:51 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAPJqkS8012612 for ; Sun, 25 Nov 2007 19:52:46 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS200301V54ZC00@mail-amer.sun.com> (original mail from Brian.Utterback@Sun.COM) for dhcwg@ietf.org; Sun, 25 Nov 2007 12:52:46 -0700 (MST) Received: from [192.168.1.5] ([71.168.64.220]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS200JJUV7X67D0@mail-amer.sun.com>; Sun, 25 Nov 2007 12:52:46 -0700 (MST) Date: Sun, 25 Nov 2007 14:52:45 -0500 From: Brian Utterback Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 In-reply-to: <000701c82f6e$03795350$6401a8c0@tsg1> To: TS Glassey Message-id: <4749D28D.8090505@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <20071121052610.DD3EF39E3F@mail1.ntp.org> <4748DAB1.2030506@ntp.org> <6EDC6595-CD66-490F-90FD-A730E4BF3360@fugue.com> <4748F4C4.1090407@ntp.org> <47496F73.8040206@sun.com> <000701c82f6e$03795350$6401a8c0@tsg1> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) X-Spam-Score: -1.0 (-) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ntpwg@lists.ntp.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" , dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org But we are not talking about anything to due with the security model, assurance or reliability. The question at hand is how to avoid abusive spamming of servers by persistent and pervasive clients. TS Glassey wrote: > Brian - "Likely" isn't something that Auditor's will let you resell as a > commercial product. Likely means that the security model of NTP is broken. > Time transfer MUST be assured and reliable or NTP is more of a curiosity > than the key to the everything many of us believe it to be. > > Todd Glassey > > ----- Original Message ----- > From: "Brian Utterback" > To: "Danny Mayer" > Cc: ; ; "Ted Lemon" ; > "Richard Gayraud (rgayraud)" > Sent: Sunday, November 25, 2007 4:49 AM > Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor > DHCPv6 > > > >> Danny Mayer wrote: >> >>> Ted Lemon wrote: >>> >>> >>> >>>> The problem you're afraid will happen is >>>> not going to happen. >>>> >>>> >>> You're too late. It already has. We are already in the situation that we >>> need to take defensive measures against existing errant NTP clients. >>> >>> >>> >> No it hasn't. AFAIK, there has not been a case of multitudes of clients >> that received NTP server >> IP addresses from DHCP spamming servers abusively for extended periods >> of time. My gut feel >> is that Ted is correct and that this is not likely to be a problem. >> >> However, the fact that we have had other situations develop into just >> such problems means >> that examining the proposal for potential abuse scenarios is worthwhile. >> Before we start >> looking for a compromise solution, perhaps we should look more closely >> at the problem. >> >> For instance, I don't see the problem as being any worse than an >> ntp.conf file that has >> the server given by an IP address. If you are going to restrict DHCP, >> perhaps we >> should consider not allowing IP addresses in the ntp.conf file. If you >> think that >> is absurd, then perhaps the DHCP restriction is absurd as well. Or >> perhaps not. >> >> Brian Utterback >> _______________________________________________ >> ntpwg mailing list >> ntpwg@lists.ntp.org >> https://lists.ntp.org/mailman/listinfo/ntpwg >> > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 15:55:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwOW4-0001oP-3r; Sun, 25 Nov 2007 15:55:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwOW3-0001kF-Cp for dhcwg@ietf.org; Sun, 25 Nov 2007 15:55:47 -0500 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwOW0-0007O7-6L for dhcwg@ietf.org; Sun, 25 Nov 2007 15:55:47 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=tlcEkqAjfN8OvwPxjzsfIf94+rgAIkGf53IliNh5ON2+W+bXMS2Fv75opBKTN3Ex; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IwOVy-0007mA-3e; Sun, 25 Nov 2007 15:55:42 -0500 Message-ID: <00af01c82fa5$8a9acfd0$6401a8c0@tsg1> From: "TS Glassey" To: "Brian Utterback" References: <20071121052610.DD3EF39E3F@mail1.ntp.org> <4748DAB1.2030506@ntp.org> <6EDC6595-CD66-490F-90FD-A730E4BF3360@fugue.com> <4748F4C4.1090407@ntp.org> <47496F73.8040206@sun.com> <000701c82f6e$03795350$6401a8c0@tsg1> <4749D28D.8090505@sun.com> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 Date: Sun, 25 Nov 2007 12:55:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec792464d94dca297fd1bae12968cc42591c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ntpwg@lists.ntp.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" , dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org ----- Original Message ----- From: "Brian Utterback" To: "TS Glassey" Cc: "Danny Mayer" ; ; ; "Ted Lemon" ; "Richard Gayraud (rgayraud)" Sent: Sunday, November 25, 2007 11:52 AM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 > But we are not talking about anything to due with the security model, > assurance or reliability. The > question at hand is how to avoid abusive spamming of servers by persistent > and pervasive clients. OK but that sounds like Integrity of Opertions insurance to me, si? Isnt the issue is how to authenticate any control processes since without this I can slam the server's with bad requests to make it unavailable to the legit users. ????? Todd > > TS Glassey wrote: >> Brian - "Likely" isn't something that Auditor's will let you resell as a >> commercial product. Likely means that the security model of NTP is >> broken. Time transfer MUST be assured and reliable or NTP is more of a >> curiosity than the key to the everything many of us believe it to be. >> >> Todd Glassey >> >> ----- Original Message ----- >> From: "Brian Utterback" >> To: "Danny Mayer" >> Cc: ; ; "Ted Lemon" >> ; "Richard Gayraud (rgayraud)" >> Sent: Sunday, November 25, 2007 4:49 AM >> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor >> DHCPv6 >> >> >> >>> Danny Mayer wrote: >>> >>>> Ted Lemon wrote: >>>> >>>> >>>> >>>>> The problem you're afraid will happen is >>>>> not going to happen. >>>>> >>>>> >>>> You're too late. It already has. We are already in the situation that >>>> we >>>> need to take defensive measures against existing errant NTP clients. >>>> >>>> >>>> >>> No it hasn't. AFAIK, there has not been a case of multitudes of clients >>> that received NTP server >>> IP addresses from DHCP spamming servers abusively for extended periods >>> of time. My gut feel >>> is that Ted is correct and that this is not likely to be a problem. >>> >>> However, the fact that we have had other situations develop into just >>> such problems means >>> that examining the proposal for potential abuse scenarios is worthwhile. >>> Before we start >>> looking for a compromise solution, perhaps we should look more closely >>> at the problem. >>> >>> For instance, I don't see the problem as being any worse than an >>> ntp.conf file that has >>> the server given by an IP address. If you are going to restrict DHCP, >>> perhaps we >>> should consider not allowing IP addresses in the ntp.conf file. If you >>> think that >>> is absurd, then perhaps the DHCP restriction is absurd as well. Or >>> perhaps not. >>> >>> Brian Utterback >>> _______________________________________________ >>> ntpwg mailing list >>> ntpwg@lists.ntp.org >>> https://lists.ntp.org/mailman/listinfo/ntpwg >> >> _______________________________________________ >> ntpwg mailing list >> ntpwg@lists.ntp.org >> https://lists.ntp.org/mailman/listinfo/ntpwg >> > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 16:24:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwOxX-0007uW-0y; Sun, 25 Nov 2007 16:24:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwOxV-0007uQ-2p for dhcwg@ietf.org; Sun, 25 Nov 2007 16:24:09 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwOxU-0002fK-FF for dhcwg@ietf.org; Sun, 25 Nov 2007 16:24:09 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAPLO7ba001355 for ; Sun, 25 Nov 2007 21:24:07 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS200801ZCRWC00@mail-amer.sun.com> (original mail from Brian.Utterback@Sun.COM) for dhcwg@ietf.org; Sun, 25 Nov 2007 14:24:07 -0700 (MST) Received: from [192.168.1.5] ([71.168.64.220]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS2008IZZG6HQA0@mail-amer.sun.com>; Sun, 25 Nov 2007 14:24:07 -0700 (MST) Date: Sun, 25 Nov 2007 16:24:06 -0500 From: Brian Utterback Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 In-reply-to: <00af01c82fa5$8a9acfd0$6401a8c0@tsg1> To: TS Glassey Message-id: <4749E7F6.8010709@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <20071121052610.DD3EF39E3F@mail1.ntp.org> <4748DAB1.2030506@ntp.org> <6EDC6595-CD66-490F-90FD-A730E4BF3360@fugue.com> <4748F4C4.1090407@ntp.org> <47496F73.8040206@sun.com> <000701c82f6e$03795350$6401a8c0@tsg1> <4749D28D.8090505@sun.com> <00af01c82fa5$8a9acfd0$6401a8c0@tsg1> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ntpwg@lists.ntp.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" , dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org TS Glassey wrote: > >> But we are not talking about anything to due with the security model, >> assurance or reliability. The >> question at hand is how to avoid abusive spamming of servers by persistent >> and pervasive clients. >> > > OK but that sounds like Integrity of Opertions insurance to me, si? > > Isnt the issue is how to authenticate any control processes since without > this I can slam the server's with bad requests to make it unavailable to the > legit users. > > ????? > > Todd > > Sort of. We aren't talking about any protection from malicious clients, we are dealing with the inadvertent slamming of a server due to long term up time of multiple clients that use the same IP address forever and ever. If a client is served an IP address at start up time, it has no choice but to use that address for the entire time it is up and running. If a particular DHCP server serves the same IP to all of its clients, the problem is multiplied. If the DHCP happens to be an embedded client, with the server IP hard-coded and this embedded client is deployed to multiple thousands of home appliances, then we have the Netgear/Wisc fiasco again. Is this scenario likely enough to be worth making major modifications to the way DHCP does things? This is what seems unlikely to Ted and I. Rather than jump through hoops at the client protocol level, a requirement that the IP served not be hard coded at the server might be enough. A compromise on Danny's compromise might be that the addresses must either be site-local, or determined dynamically by the server via DNS lookup. Brian Utterback _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 18:20:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwQm0-0005k2-9D; Sun, 25 Nov 2007 18:20:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwQly-0005hp-Qs for dhcwg@ietf.org; Sun, 25 Nov 2007 18:20:22 -0500 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwQly-0005LX-AM for dhcwg@ietf.org; Sun, 25 Nov 2007 18:20:22 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=d5U/Ct83OQyUBHGJ1LV10xb0rnjJBxwKQAvuByntJ6ZgY1sTluskGJQrIvzN9nut; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IwQlv-0005Js-CI; Sun, 25 Nov 2007 18:20:19 -0500 Message-ID: <00f101c82fb9$beaad0e0$6401a8c0@tsg1> From: "TS Glassey" To: "Brian Utterback" References: <20071121052610.DD3EF39E3F@mail1.ntp.org> <4748DAB1.2030506@ntp.org> <6EDC6595-CD66-490F-90FD-A730E4BF3360@fugue.com> <4748F4C4.1090407@ntp.org> <47496F73.8040206@sun.com> <000701c82f6e$03795350$6401a8c0@tsg1> <4749D28D.8090505@sun.com> <00af01c82fa5$8a9acfd0$6401a8c0@tsg1> <4749E7F6.8010709@sun.com> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 Date: Sun, 25 Nov 2007 15:20:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec798bc2758b5627c7b691792882215b83cb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ntpwg@lists.ntp.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" , dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org ----- Original Message ----- From: "Brian Utterback" To: "TS Glassey" Cc: ; "Danny Mayer" ; "Ted Lemon" ; "Richard Gayraud (rgayraud)" ; Sent: Sunday, November 25, 2007 1:24 PM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 > > TS Glassey wrote: >> >>> But we are not talking about anything to due with the security model, >>> assurance or reliability. The >>> question at hand is how to avoid abusive spamming of servers by >>> persistent and pervasive clients. >>> >> >> OK but that sounds like Integrity of Opertions insurance to me, si? >> >> Isnt the issue is how to authenticate any control processes since without >> this I can slam the server's with bad requests to make it unavailable to >> the legit users. >> >> ????? >> >> Todd >> >> > Sort of. We aren't talking about any protection from malicious clients, we > are dealing with the inadvertent > slamming of a server due to long term up time of multiple clients that use > the same IP address forever and > ever. Yeah... its a possibility especially with systems/appliances that hardcoded the server addresses into their firmware... I still get several hundred thousand hits a day on the old SJ NIST Server address. > If a client is served an IP address at start up time, it has no choice but > to use that address for the > entire time it is up and running. You mean the DHCP lease? True unless the connection is forced to be renewed. Otherwise, as long as the connection is in place one would think its proper to have the service address remain the same. The same is not true of NTP server's though. Those should expire per some settable policy such that a NTP Discovery is redone every 'period' to insure the proper operations of the Audit/Evidence model produced. BTW - Didnt we bring up the idea of a independant Time Server Discovery/Selection protocol some time ago. This is a dance that is done periodically to renew the validity of the policy controls in the NTP system. > If a particular DHCP server serves the same IP to all of its clients, the > problem is multiplied. If the DHCP happens to be an embedded client, with > the server IP hard-coded and > this embedded client is deployed to multiple thousands of home appliances, > then we have the Netgear/Wisc > fiasco again. Yeah - I lost use of several IP's permanently because of this issue... > > Is this scenario likely enough to be worth making major modifications to > the way DHCP does things? > This is what seems unlikely to Ted and I. Rather than jump through hoops > at the client protocol > level, a requirement that the IP served not be hard coded at the server > might be enough. A compromise > on Danny's compromise might be that the addresses must either be > site-local, or determined dynamically > by the server via DNS lookup. I agree that DNS is another way to carry the Time Server addresses, and they could easily be setup as Well Known Services, which might work pretty well. > > Brian Utterback > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 18:31:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwQwF-0005gy-G7; Sun, 25 Nov 2007 18:30:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwQwE-0005gn-0a for dhcwg@ietf.org; Sun, 25 Nov 2007 18:30:58 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwQwA-0002PS-Is for dhcwg@ietf.org; Sun, 25 Nov 2007 18:30:57 -0500 Received: from [10.0.1.2] (cpe-67-9-133-15.austin.res.rr.com [67.9.133.15]) by toccata.fugue.com (Postfix) with ESMTP id 6286BBC43ED; Sun, 25 Nov 2007 16:30:53 -0700 (MST) Message-Id: <3D222556-27E9-4EFA-87E0-A43A3C5E9E16@fugue.com> From: Ted Lemon To: Brian Utterback In-Reply-To: <4749E7F6.8010709@sun.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 Date: Sun, 25 Nov 2007 17:30:52 -0600 References: <20071121052610.DD3EF39E3F@mail1.ntp.org> <4748DAB1.2030506@ntp.org> <6EDC6595-CD66-490F-90FD-A730E4BF3360@fugue.com> <4748F4C4.1090407@ntp.org> <47496F73.8040206@sun.com> <000701c82f6e$03795350$6401a8c0@tsg1> <4749D28D.8090505@sun.com> <00af01c82fa5$8a9acfd0$6401a8c0@tsg1> <4749E7F6.8010709@sun.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ntpwg@lists.ntp.org, TS Glassey , "Richard Gayraud \(rgayraud\)" , dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 25, 2007, at 3:24 PM, Brian Utterback wrote: > If a client is served an IP address at start up time, it has no > choice but to use that address for the > entire time it is up and running. This is simply not true. The client would get the currently- configured NTP server IP address every time it renews its lease. It's true that some NTP clients may not bother to check their configuration information for updates, but it is not true that they have no choice - checking for configuration updates is trivial. Indeed, I would say that at this late date, a network service that gets its configuration information from the DHCP client, but does not follow updates to that information, is broken. Information provided by the local DHCP server will most likely change when the client moves from network to network. The information that worked on one network may not work at all on another. This is true whether the information is a domain name or an IP address. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 19:09:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwRXJ-0004TN-9f; Sun, 25 Nov 2007 19:09:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwRXI-0004TH-JD for dhcwg@ietf.org; Sun, 25 Nov 2007 19:09:16 -0500 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwRXG-0003Pb-49 for dhcwg@ietf.org; Sun, 25 Nov 2007 19:09:16 -0500 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id lAQ092va059077; Mon, 26 Nov 2007 11:09:02 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200711260009.lAQ092va059077@drugs.dv.isc.org> To: Ted Lemon From: Mark Andrews Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 In-reply-to: Your message of "Sun, 25 Nov 2007 17:30:52 MDT." <3D222556-27E9-4EFA-87E0-A43A3C5E9E16@fugue.com> Date: Mon, 26 Nov 2007 11:09:02 +1100 X-Spam-Score: -1.4 (-) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ntpwg@lists.ntp.org, Brian Utterback , "Richard Gayraud \(rgayraud\)" , dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > On Nov 25, 2007, at 3:24 PM, Brian Utterback wrote: > > If a client is served an IP address at start up time, it has no > > choice but to use that address for the > > entire time it is up and running. > > This is simply not true. The client would get the currently- > configured NTP server IP address every time it renews its lease. > It's true that some NTP clients may not bother to check their > configuration information for updates, but it is not true that they > have no choice - checking for configuration updates is trivial. > > Indeed, I would say that at this late date, a network service that > gets its configuration information from the DHCP client, but does not > follow updates to that information, is broken. Information provided > by the local DHCP server will most likely change when the client moves > from network to network. The information that worked on one network > may not work at all on another. This is true whether the information > is a domain name or an IP address. I would think that this should be a push operation from the dhcp client rather than a pull operation. A trivial push would be for the DHCP client to re-start the NTP client on address change (NTP server and optionally lease address change). I already do the later as the NTP client doesn't notice lease address changes. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 19:17:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwRep-00026u-Vc; Sun, 25 Nov 2007 19:17:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwRen-0001x1-Tj for dhcwg@ietf.org; Sun, 25 Nov 2007 19:17:01 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwRen-0006aY-Hw for dhcwg@ietf.org; Sun, 25 Nov 2007 19:17:01 -0500 Received: from [10.0.1.2] (cpe-67-9-133-15.austin.res.rr.com [67.9.133.15]) by toccata.fugue.com (Postfix) with ESMTP id 2FC76BC4401; Sun, 25 Nov 2007 17:17:00 -0700 (MST) Message-Id: <93DCBBAA-5FB3-4187-B8A3-67DDC0AF3519@fugue.com> From: Ted Lemon To: TS Glassey In-Reply-To: <00f101c82fb9$beaad0e0$6401a8c0@tsg1> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 Date: Sun, 25 Nov 2007 18:16:58 -0600 References: <20071121052610.DD3EF39E3F@mail1.ntp.org> <4748DAB1.2030506@ntp.org> <6EDC6595-CD66-490F-90FD-A730E4BF3360@fugue.com> <4748F4C4.1090407@ntp.org> <47496F73.8040206@sun.com> <000701c82f6e$03795350$6401a8c0@tsg1> <4749D28D.8090505@sun.com> <00af01c82fa5$8a9acfd0$6401a8c0@tsg1> <4749E7F6.8010709@sun.com> <00f101c82fb9$beaad0e0$6401a8c0@tsg1> X-Mailer: Apple Mail (2.915) X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , Brian Utterback , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 25, 2007, at 5:20 PM, TS Glassey wrote: > You mean the DHCP lease? True unless the connection is forced to be > renewed. > Otherwise, as long as the connection is in place one would think its > proper > to have the service address remain the same. This is a very frustrating discussion. Do you guys ever actually use DHCP in operation? Connections aren't "forced to be renewed." DHCP clients renew their leases periodically. It's possible to set up a DHCP server to give out a lease that doesn't need to be renewed, but nobody ever does that. Even if some random person at one site somewhere does it, they're not going to have enough clients to cause you trouble - it's only a large site that will cause you trouble, and trust me, they can't operate their network without regular lease renewals. So in practice, for any significant source of NTP traffic, you are going to have DHCP lease renewals. There aren't going to be any exceptions to this. Furthermore, for clients that only do the lightweight DHCP protocol, there is a required refresh interval. So again, this simply isn't a problem. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 19:40:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwS1R-0003xE-Ih; Sun, 25 Nov 2007 19:40:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwS1P-0003x9-I1 for dhcwg@ietf.org; Sun, 25 Nov 2007 19:40:23 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwS1M-0004BM-4f for dhcwg@ietf.org; Sun, 25 Nov 2007 19:40:23 -0500 Received: from [10.0.1.2] (cpe-67-9-133-15.austin.res.rr.com [67.9.133.15]) by toccata.fugue.com (Postfix) with ESMTP id 2222EBC43D3; Sun, 25 Nov 2007 17:40:19 -0700 (MST) Message-Id: From: Ted Lemon To: Mark Andrews In-Reply-To: <200711260009.lAQ092va059077@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 Date: Sun, 25 Nov 2007 18:40:18 -0600 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> X-Mailer: Apple Mail (2.915) X-Spam-Score: -4.0 (----) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ntpwg@lists.ntp.org, Brian Utterback , "Richard Gayraud \(rgayraud\)" , dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 25, 2007, at 6:09 PM, Mark Andrews wrote: > I would think that this should be a push operation from the dhcp > client rather than a pull operation. Sure, but it amounts to the same thing. This is trivial to do with the ISC DHCP client (which I presume is the one you use). It's also trivial to do on Linux with dbus. Mac OS X and Windows handle it differently still, but they already have mechanisms in place for doing this. So the point is that if the will exists to make it happen, it's trivial to make it happen. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 19:49:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwSAK-0003Th-Ii; Sun, 25 Nov 2007 19:49:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwSAI-0003Sl-QG for dhcwg@ietf.org; Sun, 25 Nov 2007 19:49:34 -0500 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwSAE-0004Pv-EQ for dhcwg@ietf.org; Sun, 25 Nov 2007 19:49:34 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=HqyViIhdE8wj5XD2Bg0kl82TqwWqIJGun2rcn+EYqJ5j1mCp1oveErXm45JvgUeR; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IwSAC-0006T4-3l; Sun, 25 Nov 2007 19:49:28 -0500 Message-ID: <014701c82fc6$32c17b30$6401a8c0@tsg1> From: "TS Glassey" To: "Ted Lemon" References: <20071121052610.DD3EF39E3F@mail1.ntp.org> <4748DAB1.2030506@ntp.org> <6EDC6595-CD66-490F-90FD-A730E4BF3360@fugue.com> <4748F4C4.1090407@ntp.org> <47496F73.8040206@sun.com> <000701c82f6e$03795350$6401a8c0@tsg1> <4749D28D.8090505@sun.com> <00af01c82fa5$8a9acfd0$6401a8c0@tsg1> <4749E7F6.8010709@sun.com> <00f101c82fb9$beaad0e0$6401a8c0@tsg1> <93DCBBAA-5FB3-4187-B8A3-67DDC0AF3519@fugue.com> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 Date: Sun, 25 Nov 2007 16:48:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79ebf4c825155ed1a11519a0363fa21942350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Brian Utterback , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org ----- Original Message ----- From: "Ted Lemon" To: "TS Glassey" Cc: "Brian Utterback" ; ; "Richard Gayraud (rgayraud)" ; Sent: Sunday, November 25, 2007 4:16 PM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 > On Nov 25, 2007, at 5:20 PM, TS Glassey wrote: >> You mean the DHCP lease? True unless the connection is forced to be >> renewed. >> Otherwise, as long as the connection is in place one would think its >> proper >> to have the service address remain the same. > > This is a very frustrating discussion. Do you guys ever actually use > DHCP in operation? Yes all the time. > Connections aren't "forced to be renewed." DHCP clients renew their > leases periodically. Sorry Ted... they most assuredly do expire and if the user wants to continue to use those services the transport MUST renew its lease to have an IP address. That's what 'forces' the lease renegotiation > It's possible to set up a DHCP server to give out a lease that doesn't > need to be renewed, but nobody ever does that. Uh yes they do and its one of the problems with this type of system too. > Even if some random person at one site somewhere does it, they're not > going to have enough clients to cause you trouble - it's only a large > site that will cause you trouble, and trust me, they can't operate their > network without regular lease renewals. Ted, here again this is a policy issue. > > So in practice, for any significant source of NTP traffic, you are going > to have DHCP lease renewals. There aren't going to be any exceptions to > this. > > Furthermore, for clients that only do the lightweight DHCP protocol, > there is a required refresh interval. So again, this simply isn't a > problem. Ted - this is about auditing and what's needed for digital evidence. So we disagree here. NTP will not be run on platforms constrained by those issues if we are not careful and properly setup NTP so that the trust factor's it operates off of are secured as well. Todd > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 19:51:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwSBm-0003kx-Lg; Sun, 25 Nov 2007 19:51:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwSBl-0003kQ-FR for dhcwg@ietf.org; Sun, 25 Nov 2007 19:51:05 -0500 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwSBl-0007OS-4p for dhcwg@ietf.org; Sun, 25 Nov 2007 19:51:05 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=WWH4ac1y4SvjjMxIy8qHcgrVc4OYlaQzys3Kn4wchG6HH14XWwXDMnSPj3b8KqNo; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IwSBi-0004lO-L0; Sun, 25 Nov 2007 19:51:02 -0500 Message-ID: <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> From: "TS Glassey" To: "Ted Lemon" , "Mark Andrews" References: <200711260009.lAQ092va059077@drugs.dv.isc.org> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Sun, 25 Nov 2007 16:50:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7939d48b7fb01b4ca082084746c2e1df83350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ntpwg@lists.ntp.org, "Richard Gayraud \(rgayraud\)" , dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org So Ted how does the DHCP server get refreshed to know that NTP Server "A" is dead now? Todd ----- Original Message ----- From: "Ted Lemon" To: "Mark Andrews" Cc: ; "Danny Mayer" ; "Richard Gayraud (rgayraud)" ; Sent: Sunday, November 25, 2007 4:40 PM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 > On Nov 25, 2007, at 6:09 PM, Mark Andrews wrote: >> I would think that this should be a push operation from the dhcp >> client rather than a pull operation. > > Sure, but it amounts to the same thing. This is trivial to do with > the ISC DHCP client (which I presume is the one you use). It's also > trivial to do on Linux with dbus. Mac OS X and Windows handle it > differently still, but they already have mechanisms in place for doing > this. So the point is that if the will exists to make it happen, > it's trivial to make it happen. > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 20:28:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwSmG-0001SZ-Hu; Sun, 25 Nov 2007 20:28:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwSmF-0001SU-Bc for dhcwg@ietf.org; Sun, 25 Nov 2007 20:28:47 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwSmB-0005Od-Vl for dhcwg@ietf.org; Sun, 25 Nov 2007 20:28:47 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAQ1SWun020863 for ; Mon, 26 Nov 2007 01:28:32 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS300D01AHY5L00@mail-amer.sun.com> (original mail from Brian.Utterback@Sun.COM) for dhcwg@ietf.org; Sun, 25 Nov 2007 18:28:32 -0700 (MST) Received: from [192.168.1.5] ([71.168.64.220]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS300CMCARJF7A0@mail-amer.sun.com>; Sun, 25 Nov 2007 18:28:32 -0700 (MST) Date: Sun, 25 Nov 2007 20:28:30 -0500 From: Brian Utterback Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 In-reply-to: To: Ted Lemon Message-id: <474A213E.1040304@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200711260009.lAQ092va059077@drugs.dv.isc.org> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) X-Spam-Score: -1.0 (-) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ntpwg@lists.ntp.org, Mark Andrews , "Richard Gayraud \(rgayraud\)" , dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I think we are all arguing at cross purposes. We have people reasoning about what will be, some about what is, some about what could be and some about what should be. The question on the floor is very simple. Is it sufficient for the DHCP option to follow convention and serve an IP address or is it necessary to instead serve a string that represents a FQDN that should be used for a DNS lookup and periodically re-resolved. It has been suggested that if you are going to serve up a string, a URL that points to a configuration file to be used would offer the most general mechanism for configuration, but this is highly problematic since there is no implementation agnostic configuration language it it is way, way out of scope to think about making one. This this idea is rejected. So, the advantage of serving a FQDN is that the client is forced to resolve the host and get the IP addresses from DNS and removal of an IP from the DNS name system will cause all the traffic to that IP to eventually disappear. The disadvantage is that it forces client to run and configure a resolver and potentially adds a lot of overhead to the DHCP protocol. Ted maintains that as a practical matter, the same effect is achieved with the IP address. We can specify in the DHCP protocol that when the DHCP lease is renewed, that the NTP client must accept a new IP address and if different from the old one, cease using the old one. We can specify that the DHCP client may only serve site local addresses unless the IP addresses served are themselves the result of periodic DNS lookup if FQDN's. We can specify that the FQDN used may not be hard coded and must be configurable. Not all of these "can"s and "must"s may be necessary or perhaps they are not sufficient. If we decide on using the IP address, then we must also decide on the musts and shoulds and mays. Ted Lemon wrote: > On Nov 25, 2007, at 6:09 PM, Mark Andrews wrote: >> I would think that this should be a push operation from the dhcp >> client rather than a pull operation. > > Sure, but it amounts to the same thing. This is trivial to do with > the ISC DHCP client (which I presume is the one you use). It's also > trivial to do on Linux with dbus. Mac OS X and Windows handle it > differently still, but they already have mechanisms in place for doing > this. So the point is that if the will exists to make it happen, > it's trivial to make it happen. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 20:44:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwT1p-0005zF-Pf; Sun, 25 Nov 2007 20:44:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwT1o-0005zA-Ma for dhcwg@ietf.org; Sun, 25 Nov 2007 20:44:52 -0500 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwT1k-0005ky-UM for dhcwg@ietf.org; Sun, 25 Nov 2007 20:44:52 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=o85Gga3W6DTXAkhyap8k7ZAKrxgXzOyooD26A9qXPDhNDwqrQgWa3afcUaPauETp; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IwT1i-0005qP-Df; Sun, 25 Nov 2007 20:44:46 -0500 Message-ID: <017401c82fcd$ec9d44b0$6401a8c0@tsg1> From: "TS Glassey" To: "Brian Utterback" , "Ted Lemon" References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <474A213E.1040304@sun.com> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Sun, 25 Nov 2007 17:44:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec790691e01c1b4792eff3a51a32f46350dc350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ntpwg@lists.ntp.org, "Richard Gayraud \(rgayraud\)" , dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org BLU :-) ----- Original Message ----- From: "Brian Utterback" To: "Ted Lemon" Cc: ; "Danny Mayer" ; "Richard Gayraud (rgayraud)" ; Sent: Sunday, November 25, 2007 5:28 PM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 >I think we are all arguing at cross purposes. We have people reasoning > about what will be, > some about what is, some about what could be and some about what should > be. > > The question on the floor is very simple. Is it sufficient for the DHCP > option to follow convention > and serve an IP address or is it necessary to instead serve a string > that represents a FQDN that should > be used for a DNS lookup and periodically re-resolved. I would san "NO" if it is also to be required to present stateful info on the status of the TS system... > > It has been suggested that if you are going to serve up a string, a URL > that points to a configuration > file to be used would offer the most general mechanism for > configuration, but this is highly problematic > since there is no implementation agnostic configuration language it it > is way, way out of scope to think > about making one. This this idea is rejected. Agreed > > So, the advantage of serving a FQDN is that the client is forced to > resolve the host and get the IP > addresses from DNS and removal of an IP from the DNS name system will > cause all the traffic > to that IP to eventually disappear. But not the surious traffic to the name servers; The issues before were not just the NTP traffic but the DNS traffic to resolve those names as well. I can speak to that first hand too. > > The disadvantage is that it forces client to run and configure a > resolver and potentially adds a lot > of overhead to the DHCP protocol. > > Ted maintains that as a practical matter, the same effect is achieved > with the IP address. > We can specify in the DHCP protocol that when the DHCP lease is renewed, > that the > NTP client must accept a new IP address and if different from the old > one, cease using > the old one. We can specify that the DHCP client may only serve site > local addresses > unless the IP addresses served are themselves the result of periodic DNS > lookup if > FQDN's. We can specify that the FQDN used may not be hard coded and must > be > configurable. > > Not all of these "can"s and "must"s may be necessary or perhaps they are > not > sufficient. If we decide on using the IP address, then we must also > decide on the > musts and shoulds and mays. > > Ted Lemon wrote: >> On Nov 25, 2007, at 6:09 PM, Mark Andrews wrote: >>> I would think that this should be a push operation from the dhcp >>> client rather than a pull operation. >> >> Sure, but it amounts to the same thing. This is trivial to do with >> the ISC DHCP client (which I presume is the one you use). It's also >> trivial to do on Linux with dbus. Mac OS X and Windows handle it >> differently still, but they already have mechanisms in place for doing >> this. So the point is that if the will exists to make it happen, >> it's trivial to make it happen. >> > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 21:26:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTgO-0005SC-0a; Sun, 25 Nov 2007 21:26:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTgM-0005Ow-Mf for dhcwg@ietf.org; Sun, 25 Nov 2007 21:26:46 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwTgJ-0006jA-Am for dhcwg@ietf.org; Sun, 25 Nov 2007 21:26:46 -0500 Received: from [10.0.1.2] (cpe-67-9-133-15.austin.res.rr.com [67.9.133.15]) by toccata.fugue.com (Postfix) with ESMTP id 5EFDABC43ED; Sun, 25 Nov 2007 19:26:42 -0700 (MST) Message-Id: <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> From: Ted Lemon To: TS Glassey In-Reply-To: <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Sun, 25 Nov 2007 20:26:41 -0600 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> X-Mailer: Apple Mail (2.915) X-Spam-Score: -4.0 (----) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , Mark Andrews , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 25, 2007, at 6:50 PM, TS Glassey wrote: > So Ted how does the DHCP server get refreshed to know that NTP > Server "A" is > dead now? Like most DNS servers, most DHCP servers are operated by network administrators. So the network administrator goes in and updates one or the other, and the next time a request comes in, the DHCP server gets the new IP address and returns it, whether it gets it from the DNS or from its own configuration. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 21:32:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTmC-0002Ry-9S; Sun, 25 Nov 2007 21:32:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTmA-0002I1-Fq for dhcwg@ietf.org; Sun, 25 Nov 2007 21:32:46 -0500 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwTm7-00072H-2W for dhcwg@ietf.org; Sun, 25 Nov 2007 21:32:46 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=GriCHzH84gYZVULNA/q+FSUchlzhz5MnmHMITceKkJekresX6sP5WV11OyaYbZ8u; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IwTm2-0004Qp-NE; Sun, 25 Nov 2007 21:32:39 -0500 Message-ID: <017901c82fd4$9cad3b70$6401a8c0@tsg1> From: "TS Glassey" To: "Ted Lemon" References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Sun, 25 Nov 2007 18:32:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79f1280addc682424474bbbc67c241f07f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Mark Andrews , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org ----- Original Message ----- From: "Ted Lemon" To: "TS Glassey" Cc: "Mark Andrews" ; ; "Richard Gayraud (rgayraud)" ; Sent: Sunday, November 25, 2007 6:26 PM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 > On Nov 25, 2007, at 6:50 PM, TS Glassey wrote: >> So Ted how does the DHCP server get refreshed to know that NTP Server >> "A" is >> dead now? > > Like most DNS servers, most DHCP servers are operated by network > administrators. So the network administrator goes in and updates one or > the other, and the next time a request comes in, the DHCP server gets the > new IP address and returns it, whether it gets it from the DNS or from > its own configuration. > Which makes the Network Administrator liable for screw-up's and the damages therein... Sorry this one is a no-sale IMHO. Todd _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 21:42:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTvd-00037p-Dv; Sun, 25 Nov 2007 21:42:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTvc-00037c-Cz for dhcwg@ietf.org; Sun, 25 Nov 2007 21:42:32 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwTvW-0007Gu-Sv for dhcwg@ietf.org; Sun, 25 Nov 2007 21:42:32 -0500 Received: from [10.0.1.2] (cpe-67-9-133-15.austin.res.rr.com [67.9.133.15]) by toccata.fugue.com (Postfix) with ESMTP id 0BBC5BC42D8; Sun, 25 Nov 2007 19:42:25 -0700 (MST) Message-Id: <030AED4F-4876-43AB-93C4-0D2EBD33DFFC@fugue.com> From: Ted Lemon To: Brian Utterback In-Reply-To: <474A213E.1040304@sun.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 Date: Sun, 25 Nov 2007 20:42:25 -0600 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <474A213E.1040304@sun.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: -4.0 (----) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , Mark Andrews , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 25, 2007, at 7:28 PM, Brian Utterback wrote: > So, the advantage of serving a FQDN is that the client is forced to > resolve the host and get the IP > addresses from DNS and removal of an IP from the DNS name system will > cause all the traffic > to that IP to eventually disappear. The client is not *forced* to do anything. Whether or not it does what you describe depends on the implementation. On a practical level, there is no difference between refreshing information from the DNS and refreshing information from DHCP. > We can specify in the DHCP protocol that when the DHCP lease is > renewed, > that the > NTP client must accept a new IP address and if different from the old > one, cease using > the old one. We can specify that the DHCP client may only serve site > local addresses > unless the IP addresses served are themselves the result of periodic > DNS > lookup if > FQDN's. We can specify that the FQDN used may not be hard coded and > must be > configurable. You can specify things until you're blue in the face, but no specification that you write forces the implementor to do anything. As a practical matter, specifying things like this isn't really going to accomplish your goals. It's probably good to write a requirement that the NTP server MUST process updates from the DHCP client each time the client refreshes the NTP server addresses option, but the reason this will get implemented is that clients that don't implement it won't work reliably. I would expect the DHC working group to choose between using IP addresses or using FQDNs. We don't like to have flags that switch between these, because they create implementation complexity and cause interoperability problems. I am in favor of using IP addresses because it uses less space in the packet, because it simplifies client-side implementations, and because every DHCP server of which I'm aware will take either an IP address or a domain name in any configuration field where an IP address is called for, and will look the IP address up in the DNS if a domain name was provided. So you get the exact functionality you want, without any complexity on the part of the client. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 21:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTvn-0003BE-Mb; Sun, 25 Nov 2007 21:42:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTvm-0003B3-GH for dhcwg@ietf.org; Sun, 25 Nov 2007 21:42:42 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwTvh-0007HB-TW for dhcwg@ietf.org; Sun, 25 Nov 2007 21:42:42 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAQ2gbcb009352 for ; Mon, 26 Nov 2007 02:42:37 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS300A01E4H4S00@mail-amer.sun.com> (original mail from Brian.Utterback@Sun.COM) for dhcwg@ietf.org; Sun, 25 Nov 2007 19:42:37 -0700 (MST) Received: from [192.168.1.5] ([71.168.64.220]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS3004KAE6VPN20@mail-amer.sun.com>; Sun, 25 Nov 2007 19:42:37 -0700 (MST) Date: Sun, 25 Nov 2007 21:42:31 -0500 From: Brian Utterback Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 In-reply-to: <017901c82fd4$9cad3b70$6401a8c0@tsg1> To: TS Glassey Message-id: <474A3297.5040907@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) X-Spam-Score: -1.0 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org TS Glassey wrote: > >> Like most DNS servers, most DHCP servers are operated by network >> administrators. So the network administrator goes in and updates one or >> the other, and the next time a request comes in, the DHCP server gets the >> new IP address and returns it, whether it gets it from the DNS or from >> its own configuration. >> >> > > Which makes the Network Administrator liable for screw-up's and the damages > therein... Sorry this one is a no-sale IMHO. > > Okay, Todd. The proposal is pretty much SOP right now, with some slight refinements. If you deem that a show-stopper, I think the onus is on you to suggest a reasonable alternative. blu _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 21:43:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTwX-0003qE-T2; Sun, 25 Nov 2007 21:43:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTwX-0003q7-2K for dhcwg@ietf.org; Sun, 25 Nov 2007 21:43:29 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwTwW-0001uV-PP for dhcwg@ietf.org; Sun, 25 Nov 2007 21:43:28 -0500 Received: from [10.0.1.2] (cpe-67-9-133-15.austin.res.rr.com [67.9.133.15]) by toccata.fugue.com (Postfix) with ESMTP id D0AFDBC42D8; Sun, 25 Nov 2007 19:43:27 -0700 (MST) Message-Id: From: Ted Lemon To: TS Glassey In-Reply-To: <017901c82fd4$9cad3b70$6401a8c0@tsg1> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Sun, 25 Nov 2007 20:43:27 -0600 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> X-Mailer: Apple Mail (2.915) X-Spam-Score: -4.0 (----) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , Mark Andrews , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 25, 2007, at 8:32 PM, TS Glassey wrote: > Which makes the Network Administrator liable for screw-up's and the > damages > therein... Sorry this one is a no-sale IMHO. Why? Network administrators are already responsible for all the other fields in the DHCP server - why is the NTP server address special? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 21:54:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwU72-00019f-Az; Sun, 25 Nov 2007 21:54:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwU70-00019L-V7 for dhcwg@ietf.org; Sun, 25 Nov 2007 21:54:18 -0500 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwU6x-0007YL-0t for dhcwg@ietf.org; Sun, 25 Nov 2007 21:54:18 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=tF5mS6VXCH9TDW8wmpHNU/Q5bgBA5DtIEMJ+wtM4db7vHX8LZhwfUwnPTgGhbQYZ; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IwU6u-0007lp-OE; Sun, 25 Nov 2007 21:54:12 -0500 Message-ID: <018501c82fd7$9ff707e0$6401a8c0@tsg1> From: "TS Glassey" To: "Ted Lemon" References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Sun, 25 Nov 2007 18:54:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec799f52d4d967dc6d0c206ceb10b18cadc2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Mark Andrews , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ted :-) ----- Original Message ----- From: "Ted Lemon" To: "TS Glassey" Cc: ; ; "Mark Andrews" ; "Richard Gayraud (rgayraud)" Sent: Sunday, November 25, 2007 6:43 PM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 > On Nov 25, 2007, at 8:32 PM, TS Glassey wrote: >> Which makes the Network Administrator liable for screw-up's and the >> damages >> therein... Sorry this one is a no-sale IMHO. > > Why? Network administrators are already responsible for all the other > fields in the DHCP server - why is the NTP server address special? > Ted there are issues with the Old-School methods and if you believe that they are the right way to operate your network nothing I can say from either someone who has written subpicosecond event capture code as well as auditing profiles for securing and making the evidence believable. So lets just agree to disagree about this. The addition of NTP servers in this instance opens more liabilities than it solves problems for whether anyone likes that or not. Sorry, but your neat fix here opens new security issues and allows NTP servers to become also impacted by DHCP security issues. Sorry but reality is what it is, and adding this support to DHCP opens more problems than it solves. Todd _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 21:54:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwU72-0001AD-Iw; Sun, 25 Nov 2007 21:54:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwU70-00019O-Vt for dhcwg@ietf.org; Sun, 25 Nov 2007 21:54:18 -0500 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwU6x-0007YN-0v for dhcwg@ietf.org; Sun, 25 Nov 2007 21:54:18 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=SXzzBNhNo8QXBQvzFZaKXPbO3lE1cpX0OXTZezupjQ8N9YxtZ1MZXr9JxlzobGAK; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IwU6t-0007lp-Pc; Sun, 25 Nov 2007 21:54:12 -0500 Message-ID: <018401c82fd7$9f632c50$6401a8c0@tsg1> From: "TS Glassey" To: "Brian Utterback" References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <474A3297.5040907@sun.com> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Sun, 25 Nov 2007 18:49:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec799f52d4d967dc6d0c16594073eeb7ba95350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org ----- Original Message ----- From: "Brian Utterback" To: "TS Glassey" Cc: "Ted Lemon" ; ; ; "Richard Gayraud (rgayraud)" Sent: Sunday, November 25, 2007 6:42 PM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 > TS Glassey wrote: >> >>> Like most DNS servers, most DHCP servers are operated by network >>> administrators. So the network administrator goes in and updates one >>> or the other, and the next time a request comes in, the DHCP server >>> gets the new IP address and returns it, whether it gets it from the DNS >>> or from its own configuration. >>> >>> >> >> Which makes the Network Administrator liable for screw-up's and the >> damages therein... Sorry this one is a no-sale IMHO. >> >> > > Okay, Todd. The proposal is pretty much SOP right now, with some slight > refinements. OK, SOP for who? > If you deem that a show-stopper, I think the onus is on > you to suggest a reasonable alternative. > > blu I still don't know that the service is needed I have heard a couple of people mandate that they think this is necessary but in actuality I still haven't heard anything that makes this mandatory. Especially since without any pain at all its pretty easy to create a set of known NTP servers and just use the local DNS service to propagate these. WKS inside of DNS is a simple method that is time tested. Todd _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 22:00:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUCZ-0000rp-6m; Sun, 25 Nov 2007 22:00:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUCY-0000rg-8X for dhcwg@ietf.org; Sun, 25 Nov 2007 22:00:02 -0500 Received: from mx05.gis.net ([208.218.130.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwUCV-0007hF-T4 for dhcwg@ietf.org; Sun, 25 Nov 2007 22:00:02 -0500 Received: from [10.10.10.101] ([63.209.224.211]) by mx05.gis.net; Sun, 25 Nov 2007 21:59:56 -0500 Message-ID: <474A3608.80803@ntp.org> Date: Sun, 25 Nov 2007 21:57:12 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mark Andrews Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> In-Reply-To: <200711260009.lAQ092va059077@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Brian Utterback , Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Mark Andrews wrote: >> On Nov 25, 2007, at 3:24 PM, Brian Utterback wrote: >>> If a client is served an IP address at start up time, it has no >>> choice but to use that address for the >>> entire time it is up and running. >> This is simply not true. The client would get the currently- >> configured NTP server IP address every time it renews its lease. >> It's true that some NTP clients may not bother to check their >> configuration information for updates, but it is not true that they >> have no choice - checking for configuration updates is trivial. >> >> Indeed, I would say that at this late date, a network service that >> gets its configuration information from the DHCP client, but does not >> follow updates to that information, is broken. Information provided >> by the local DHCP server will most likely change when the client moves >> from network to network. The information that worked on one network >> may not work at all on another. This is true whether the information >> is a domain name or an IP address. > > I would think that this should be a push operation from the dhcp > client rather than a pull operation. A trivial push would be for > the DHCP client to re-start the NTP client on address change (NTP > server and optionally lease address change). > > I already do the later as the NTP client doesn't notice lease address > changes. > > Mark You must be running an old NTP server. As of 4.2.4 ntpd rescans the interfaces for local interface address changes. You can disable rescanning by using -U 0 on the startup command line. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 22:00:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUCs-0001EG-KG; Sun, 25 Nov 2007 22:00:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUCq-0001DX-S0 for dhcwg@ietf.org; Sun, 25 Nov 2007 22:00:20 -0500 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwUCo-0007hv-8s for dhcwg@ietf.org; Sun, 25 Nov 2007 22:00:20 -0500 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id lAQ3065E094221; Mon, 26 Nov 2007 14:00:06 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200711260300.lAQ3065E094221@drugs.dv.isc.org> To: "TS Glassey" From: Mark Andrews Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 In-reply-to: Your message of "Sun, 25 Nov 2007 18:32:34 -0800." <017901c82fd4$9cad3b70$6401a8c0@tsg1> Date: Mon, 26 Nov 2007 14:00:06 +1100 X-Spam-Score: -1.4 (-) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > > ----- Original Message ----- > From: "Ted Lemon" > To: "TS Glassey" > Cc: "Mark Andrews" ; ; "Richard > Gayraud (rgayraud)" ; > Sent: Sunday, November 25, 2007 6:26 PM > Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) > OptionsforDHCPv6 > > > > On Nov 25, 2007, at 6:50 PM, TS Glassey wrote: > >> So Ted how does the DHCP server get refreshed to know that NTP Server > >> "A" is > >> dead now? > > > > Like most DNS servers, most DHCP servers are operated by network > > administrators. So the network administrator goes in and updates one or > > the other, and the next time a request comes in, the DHCP server gets the > > new IP address and returns it, whether it gets it from the DNS or from > > its own configuration. > > > > Which makes the Network Administrator liable for screw-up's and the damages > therein... Sorry this one is a no-sale IMHO. > > Todd There is no system that a network administrator can't screw up. DHCP is not the same as embedded in firmware. "Cease and Desist" will work with DHCP as there is a configuration knob that can be changed. It's also not a knob that is shipped set. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 22:06:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUIO-0006LC-GN; Sun, 25 Nov 2007 22:06:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUIL-0006Fv-Tb for dhcwg@ietf.org; Sun, 25 Nov 2007 22:06:01 -0500 Received: from mail1.ntp.org ([204.152.184.126]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwUIL-0002Uo-Ho for dhcwg@ietf.org; Sun, 25 Nov 2007 22:06:01 -0500 Received: from localhost (localhost [127.0.0.1]) by mail1.ntp.org (Postfix) with ESMTP id E5A2D39E9E; Mon, 26 Nov 2007 03:05:59 +0000 (UTC) (envelope-from stenn@ntp1.ntp.org) Received: from mail1.ntp.org ([127.0.0.1]) by localhost (ntp1.isc.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11781-06; Mon, 26 Nov 2007 03:05:51 +0000 (UTC) Received: from ntp1.ntp.org (localhost [127.0.0.1]) by mail1.ntp.org (Postfix) with ESMTP; Mon, 26 Nov 2007 03:05:51 +0000 (UTC) (envelope-from stenn@ntp1.ntp.org) To: ntpwg@lists.ntp.org, dhcwg@ietf.org Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 In-Reply-To: Message from Brian Utterback of "Sun, 25 Nov 2007 21:42:31 EST." <474A3297.5040907@sun.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4; XEmacs 21.4 (patch 14) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 26 Nov 2007 03:05:51 +0000 From: Harlan Stenn X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on ntp1.isc.org Message-Id: <20071126030559.E5A2D39E9E@mail1.ntp.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Guys, Just to pick a random message on this thread to respond to, I think it would be Swell if a DHCP server could send back some configuration information for the benefit of an NTP server. If the information is "here's *a* server you should use" I would like to see that information be either an IP (v4 or v6) or a DNS name. If it is a *list* of servers, I would like to see that list contain any of IPs (v4 or v6) and/or hostnames. If it is more generic "ntp configuration information" then prehaps regardless of whatever other formats are proffered, I would be happy to see a URL as a choice. Also please remmeber that there is an excellent chance that there will be something in between ntp on the client and the incoming DHCP packet that "handles" the information and ntp may *never* actually directly talk to the DHCP server. OTOH, it might. If anybody cares, please visit (and comment if you like): http://support.ntp.org/Dev/GettingNtpdItsConfiguration H _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 22:06:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUIr-0006WH-4X; Sun, 25 Nov 2007 22:06:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUIp-0006W5-Tf for dhcwg@ietf.org; Sun, 25 Nov 2007 22:06:31 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwUIm-0007tG-9t for dhcwg@ietf.org; Sun, 25 Nov 2007 22:06:31 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=tjS3DomP8mNDUbu2OEtmqu/9Iqd2F1DFz/evGgiRMJbbRMoJLsLXTMxDB7ZDSGxp; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IwUIk-0006SN-Lh; Sun, 25 Nov 2007 22:06:26 -0500 Message-ID: <018d01c82fd9$554da620$6401a8c0@tsg1> From: "TS Glassey" To: "Ted Lemon" , "Brian Utterback" References: <200711260009.lAQ092va059077@drugs.dv.isc.org><474A213E.1040304@sun.com> <030AED4F-4876-43AB-93C4-0D2EBD33DFFC@fugue.com> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Sun, 25 Nov 2007 19:06:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79335bb8cbc793ee0f908de2d741e3359e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ted...From an audit perspective Time Transfer is one of those things that needs an audit profile for it, and adding more loopholes is the way to make the security model harder to prove not easier. Todd ----- Original Message ----- From: "Ted Lemon" To: "Brian Utterback" Cc: ; ; "Richard Gayraud (rgayraud)" Sent: Sunday, November 25, 2007 6:42 PM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 > On Nov 25, 2007, at 7:28 PM, Brian Utterback wrote: >> So, the advantage of serving a FQDN is that the client is forced to >> resolve the host and get the IP >> addresses from DNS and removal of an IP from the DNS name system will >> cause all the traffic >> to that IP to eventually disappear. > > The client is not *forced* to do anything. Whether or not it does > what you describe depends on the implementation. On a practical > level, there is no difference between refreshing information from the > DNS and refreshing information from DHCP. > >> We can specify in the DHCP protocol that when the DHCP lease is >> renewed, >> that the >> NTP client must accept a new IP address and if different from the old >> one, cease using >> the old one. We can specify that the DHCP client may only serve site >> local addresses >> unless the IP addresses served are themselves the result of periodic >> DNS >> lookup if >> FQDN's. We can specify that the FQDN used may not be hard coded and >> must be >> configurable. > > You can specify things until you're blue in the face, but no > specification that you write forces the implementor to do anything. > As a practical matter, specifying things like this isn't really going > to accomplish your goals. > > It's probably good to write a requirement that the NTP server MUST > process updates from the DHCP client each time the client refreshes > the NTP server addresses option, but the reason this will get > implemented is that clients that don't implement it won't work reliably. > > I would expect the DHC working group to choose between using IP > addresses or using FQDNs. We don't like to have flags that switch > between these, because they create implementation complexity and cause > interoperability problems. > > I am in favor of using IP addresses because it uses less space in the > packet, because it simplifies client-side implementations, and because > every DHCP server of which I'm aware will take either an IP address or > a domain name in any configuration field where an IP address is called > for, and will look the IP address up in the DNS if a domain name was > provided. So you get the exact functionality you want, without any > complexity on the part of the client. > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 22:13:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUPk-0000QH-E5; Sun, 25 Nov 2007 22:13:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUPi-0000Lo-7N for dhcwg@ietf.org; Sun, 25 Nov 2007 22:13:39 -0500 Received: from mx04.gis.net ([208.218.130.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwUPh-0002fY-Tp for dhcwg@ietf.org; Sun, 25 Nov 2007 22:13:38 -0500 Received: from [10.10.10.101] ([63.209.224.211]) by mx04.gis.net; Sun, 25 Nov 2007 22:13:32 -0500 Message-ID: <474A3939.4090202@ntp.org> Date: Sun, 25 Nov 2007 22:10:49 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ted Lemon Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Mark Andrews , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ted Lemon wrote: > On Nov 25, 2007, at 6:09 PM, Mark Andrews wrote: >> I would think that this should be a push operation from the dhcp >> client rather than a pull operation. > > Sure, but it amounts to the same thing. This is trivial to do with > the ISC DHCP client (which I presume is the one you use). It's also > trivial to do on Linux with dbus. Mac OS X and Windows handle it > differently still, but they already have mechanisms in place for doing > this. So the point is that if the will exists to make it happen, > it's trivial to make it happen. It's trivial to send a private mode 7 NTP packet (along with an appropriate password) to the reference implementation of ntpd telling it to add or remove a server from its list of servers to use. As far as I know only ntpdc does this currently and it's not a DHC client. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 22:14:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUQZ-0001NK-W3; Sun, 25 Nov 2007 22:14:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUQW-0001Eb-Of for dhcwg@ietf.org; Sun, 25 Nov 2007 22:14:30 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwUQT-00082j-D2 for dhcwg@ietf.org; Sun, 25 Nov 2007 22:14:28 -0500 Received: from [10.0.1.2] (cpe-67-9-133-15.austin.res.rr.com [67.9.133.15]) by toccata.fugue.com (Postfix) with ESMTP id 976A8BC439D; Sun, 25 Nov 2007 20:14:24 -0700 (MST) From: Ted Lemon To: TS Glassey In-Reply-To: <018501c82fd7$9ff707e0$6401a8c0@tsg1> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 X-Priority: 3 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Sun, 25 Nov 2007 21:14:23 -0600 X-Mailer: Apple Mail (2.915) X-Spam-Score: -4.0 (----) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Mark Andrews , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 25, 2007, at 8:54 PM, TS Glassey wrote: > Sorry but reality is what it is, and adding this support to DHCP > opens more problems than it solves. If one of the options here is for you guys to take your marbles and go home, I'd be all in favor of that - I don't see this converging on a good solution, and I'd rather that we have no solution for now than a bad solution - we can always try again later. You guys remind me of a first-time motorcycle passenger who freaks out when the bike leans over in a turn, and tries to get it to stand back up. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 22:23:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUZK-0004Sv-C3; Sun, 25 Nov 2007 22:23:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUZJ-0004Sq-DI for dhcwg@ietf.org; Sun, 25 Nov 2007 22:23:33 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwUZI-0002qP-Lv for dhcwg@ietf.org; Sun, 25 Nov 2007 22:23:32 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAQ3NVUN003201 for ; Mon, 26 Nov 2007 03:23:31 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS300L01FUWVW00@mail-amer.sun.com> (original mail from Brian.Utterback@Sun.COM) for dhcwg@ietf.org; Sun, 25 Nov 2007 20:23:31 -0700 (MST) Received: from [192.168.1.5] ([71.168.64.220]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS30044QG36PN80@mail-amer.sun.com>; Sun, 25 Nov 2007 20:23:31 -0700 (MST) Date: Sun, 25 Nov 2007 22:23:30 -0500 From: Brian Utterback Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 In-reply-to: <018401c82fd7$9f632c50$6401a8c0@tsg1> To: TS Glassey Message-id: <474A3C32.1020006@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <474A3297.5040907@sun.com> <018401c82fd7$9f632c50$6401a8c0@tsg1> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org TS Glassey wrote: > > I still don't know that the service is needed I have heard a couple of > people mandate that they think this is necessary but in actuality I > still haven't heard anything that makes this mandatory. Especially > since without any pain at all its pretty easy to create a set of known > NTP servers and just use the local DNS service to propagate these. WKS > inside of DNS is a simple method that is time tested. > > Todd Okay, so your suggestion is to not have a DHCP NTP field at all, but to have the clients use WKS and DNS resolution to find servers. Fair enough. blu _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 22:38:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUnh-0007K9-LM; Sun, 25 Nov 2007 22:38:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUng-0007K3-Mn for dhcwg@ietf.org; Sun, 25 Nov 2007 22:38:24 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwUnd-00008R-D3 for dhcwg@ietf.org; Sun, 25 Nov 2007 22:38:24 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAQ3cKUB004466 for ; Mon, 26 Nov 2007 03:38:21 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS300301GOAQJ00@mail-amer.sun.com> (original mail from Brian.Utterback@Sun.COM) for dhcwg@ietf.org; Sun, 25 Nov 2007 20:38:20 -0700 (MST) Received: from [192.168.1.5] ([71.168.64.220]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS3004XZGRTPN90@mail-amer.sun.com>; Sun, 25 Nov 2007 20:38:18 -0700 (MST) Date: Sun, 25 Nov 2007 22:38:17 -0500 From: Brian Utterback Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 In-reply-to: <018501c82fd7$9ff707e0$6401a8c0@tsg1> To: TS Glassey Message-id: <474A3FA9.5020303@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) X-Spam-Score: -1.0 (-) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org TS Glassey wrote: > > Sorry but reality is what it is, and adding this support to DHCP opens more > problems than it solves. > > Todd > Truly? In your audited world, can't you just preclude the use of DHCP based server discovery if it poses such a problem? blu _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 22:50:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUzT-0001pl-Nh; Sun, 25 Nov 2007 22:50:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUzS-0001pf-85 for dhcwg@ietf.org; Sun, 25 Nov 2007 22:50:34 -0500 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwUzR-0003cY-Nh for dhcwg@ietf.org; Sun, 25 Nov 2007 22:50:34 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=sGQIe7bVX/ixPRKpH1s5Okp0T8jF70PwKJ5pSa8ckfzneHU6GB18hlMD96QGmEwQ; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IwUzP-0001wc-Ks; Sun, 25 Nov 2007 22:50:31 -0500 Message-ID: <019901c82fdf$7df28f40$6401a8c0@tsg1> From: "TS Glassey" To: "Mark Andrews" References: <200711260300.lAQ3065E094221@drugs.dv.isc.org> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Sun, 25 Nov 2007 19:09:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec790b1457005f1114014a36d9d7119cd224350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Mark That's the problem. its not that I think that its not a good idea to be able to propagate a set of NTP servers to any set of users, and DHCP is something that most operator's have running, but DNS is a better solution I think especially if there is a set of basic Time Services and addressing ala RFC1918 defined for them per the suggestion I sent in some months ago. Todd ----- Original Message ----- From: "Mark Andrews" To: "TS Glassey" Cc: "Ted Lemon" ; ; "Richard Gayraud (rgayraud)" ; Sent: Sunday, November 25, 2007 7:00 PM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 > >> >> ----- Original Message ----- >> From: "Ted Lemon" >> To: "TS Glassey" >> Cc: "Mark Andrews" ; ; >> "Richard >> Gayraud (rgayraud)" ; >> Sent: Sunday, November 25, 2007 6:26 PM >> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) >> OptionsforDHCPv6 >> >> >> > On Nov 25, 2007, at 6:50 PM, TS Glassey wrote: >> >> So Ted how does the DHCP server get refreshed to know that NTP Server >> >> "A" is >> >> dead now? >> > >> > Like most DNS servers, most DHCP servers are operated by network >> > administrators. So the network administrator goes in and updates one >> > or >> > the other, and the next time a request comes in, the DHCP server gets >> > the >> > new IP address and returns it, whether it gets it from the DNS or from >> > its own configuration. >> > >> >> Which makes the Network Administrator liable for screw-up's and the >> damages >> therein... Sorry this one is a no-sale IMHO. >> >> Todd > > There is no system that a network administrator can't screw > up. > > DHCP is not the same as embedded in firmware. > > "Cease and Desist" will work with DHCP as there is a > configuration knob that can be changed. It's also not a > knob that is shipped set. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 22:59:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwV8B-0000aM-Gj; Sun, 25 Nov 2007 22:59:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwV8A-0000aH-0E for dhcwg@ietf.org; Sun, 25 Nov 2007 22:59:34 -0500 Received: from mx04.gis.net ([208.218.130.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwV86-0000gH-Ol for dhcwg@ietf.org; Sun, 25 Nov 2007 22:59:33 -0500 Received: from [10.10.10.101] ([63.209.224.211]) by mx04.gis.net; Sun, 25 Nov 2007 22:58:54 -0500 Message-ID: <474A43DB.1010009@ntp.org> Date: Sun, 25 Nov 2007 22:56:11 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Brian Utterback Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <474A3297.5040907@sun.com> <018401c82fd7$9f632c50$6401a8c0@tsg1> <474A3C32.1020006@sun.com> In-Reply-To: <474A3C32.1020006@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, TS Glassey , Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Brian Utterback wrote: > TS Glassey wrote: >> >> I still don't know that the service is needed I have heard a couple of >> people mandate that they think this is necessary but in actuality I >> still haven't heard anything that makes this mandatory. Especially >> since without any pain at all its pretty easy to create a set of known >> NTP servers and just use the local DNS service to propagate these. WKS >> inside of DNS is a simple method that is time tested. >> >> Todd > > Okay, so your suggestion is to not have a DHCP NTP field at all, but to > have > the clients use WKS and DNS resolution to find servers. Fair enough. > > blu Actually SRV records are what should get used. WKS is rather obsolete. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 23:06:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwVEr-0005X2-AQ; Sun, 25 Nov 2007 23:06:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwVEq-0005Wt-HN for dhcwg@ietf.org; Sun, 25 Nov 2007 23:06:28 -0500 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwVEq-000421-5V for dhcwg@ietf.org; Sun, 25 Nov 2007 23:06:28 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=A6lMTWBl82WOL9Hj7yXOCP14KgECcnRGra7EFb/QCMWrI9GEMC+c9LoFzSCgbftA; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IwVEo-0006lP-98; Sun, 25 Nov 2007 23:06:26 -0500 Message-ID: <01b501c82fe1$b6f7a850$6401a8c0@tsg1> From: "TS Glassey" To: "Ted Lemon" , "Odonoghue, Karen F CIV NSWCDD, W13" References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Sun, 25 Nov 2007 20:03:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec795ede2818c4725d1cc60ccf06b4054dfd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Mark Andrews , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org ----- Original Message ----- From: "Ted Lemon" To: "TS Glassey" Cc: ; ; "Mark Andrews" ; "Richard Gayraud (rgayraud)" Sent: Sunday, November 25, 2007 7:14 PM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 > On Nov 25, 2007, at 8:54 PM, TS Glassey wrote: >> Sorry but reality is what it is, and adding this support to DHCP opens >> more problems than it solves. > > If one of the options here is for you guys to take your marbles and go > home, I'd be all in favor of that - I don't see this converging on a good > solution, and I'd rather that we have no solution for now than a bad > solution - we can always try again later. You guys remind me of a > first-time motorcycle passenger who freaks out when the bike leans over > in a turn, and tries to get it to stand back up. > Ted, opinions are wonderful, everyone has one, even you. As to the Motorcycle commentary - I used to race for Team Montessa so, I do know how to lean through a turn... and my commentary about the introduction of new risks to make the incidental world of the Systems/Network Administrator easier, I understand the goal its just the wrong way to go about it. Todd _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 23:06:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwVEx-0005aK-0g; Sun, 25 Nov 2007 23:06:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwVEt-0005YX-Rf for dhcwg@ietf.org; Sun, 25 Nov 2007 23:06:31 -0500 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwVEq-0000se-DN for dhcwg@ietf.org; Sun, 25 Nov 2007 23:06:31 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=sZj8f/NmvbgW85IT4FuC43HTAuBO0vRIriMEpWa60VQnLzzHVfBRx7AcYUCLD7aj; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IwVEp-0006lP-4z; Sun, 25 Nov 2007 23:06:27 -0500 Message-ID: <01b601c82fe1$b77d2c00$6401a8c0@tsg1> From: "TS Glassey" To: "Brian Utterback" References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <474A3297.5040907@sun.com> <018401c82fd7$9f632c50$6401a8c0@tsg1> <474A3C32.1020006@sun.com> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Sun, 25 Nov 2007 20:06:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec795ede2818c4725d1c63d1144f5eb46c13350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org BLU ----- Original Message ----- From: "Brian Utterback" To: "TS Glassey" Cc: "Ted Lemon" ; ; ; "Richard Gayraud (rgayraud)" Sent: Sunday, November 25, 2007 7:23 PM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 > TS Glassey wrote: >> >> I still don't know that the service is needed I have heard a couple of >> people mandate that they think this is necessary but in actuality I still >> haven't heard anything that makes this mandatory. Especially since >> without any pain at all its pretty easy to create a set of known NTP >> servers and just use the local DNS service to propagate these. WKS inside >> of DNS is a simple method that is time tested. >> >> Todd > > Okay, so your suggestion is to not have a DHCP NTP field at all, but to > have > the clients use WKS and DNS resolution to find servers. Fair enough. Yes and no. My suggestion is that the DCHP system could be used if it also had some reliable names which were predefined. My real suggestion is that we need a Time and Trust Service Discovery protocol which would work sort of like how DHCP and DNS work but that also allows for critical events to be pushed forward as well. This would also work for CRL and OCSP type queries to satisfy validity of the underlying certificate source. Todd > > blu > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 23:15:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwVNi-0003nc-0n; Sun, 25 Nov 2007 23:15:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwVNg-0003nQ-5g for dhcwg@ietf.org; Sun, 25 Nov 2007 23:15:36 -0500 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwVNd-00015Z-Mi for dhcwg@ietf.org; Sun, 25 Nov 2007 23:15:36 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ePnvWddwGOiSPcb4Xef6OrsbRRgS8STu7DUbhQQPetYDmnecjfk/GfBds75+Rm6G; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IwVNc-0001uk-I6; Sun, 25 Nov 2007 23:15:32 -0500 Message-ID: <01bf01c82fe2$fc8db980$6401a8c0@tsg1> From: "TS Glassey" To: "Danny Mayer" , "Brian Utterback" References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <474A3297.5040907@sun.com> <018401c82fd7$9f632c50$6401a8c0@tsg1> <474A3C32.1020006@sun.com> <474A43DB.1010009@ntp.org> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Sun, 25 Nov 2007 20:15:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79ac3504d96653ab1aa9c85441ac13d1e3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Danny I was trying to stay as compatible as possible, but yes in the Microsoft world Service Records (SRV's) are the current manner to do this. The problem I see is that SRV's cannot return the key as well as the address for secured service lookup. Todd ----- Original Message ----- From: "Danny Mayer" To: "Brian Utterback" Cc: "TS Glassey" ; ; ; "Ted Lemon" ; "Richard Gayraud (rgayraud)" Sent: Sunday, November 25, 2007 7:56 PM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 > Brian Utterback wrote: >> TS Glassey wrote: >>> >>> I still don't know that the service is needed I have heard a couple of >>> people mandate that they think this is necessary but in actuality I >>> still haven't heard anything that makes this mandatory. Especially >>> since without any pain at all its pretty easy to create a set of known >>> NTP servers and just use the local DNS service to propagate these. WKS >>> inside of DNS is a simple method that is time tested. >>> >>> Todd >> >> Okay, so your suggestion is to not have a DHCP NTP field at all, but to >> have >> the clients use WKS and DNS resolution to find servers. Fair enough. >> >> blu > > Actually SRV records are what should get used. WKS is rather obsolete. > > Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 23:27:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwVZC-0006X9-HF; Sun, 25 Nov 2007 23:27:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwVZ1-0006Qm-53 for dhcwg@ietf.org; Sun, 25 Nov 2007 23:27:20 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwVYy-0001Il-Je for dhcwg@ietf.org; Sun, 25 Nov 2007 23:27:19 -0500 Received: from [10.0.1.2] (cpe-67-9-133-15.austin.res.rr.com [67.9.133.15]) by toccata.fugue.com (Postfix) with ESMTP id 87680BC43D3; Sun, 25 Nov 2007 21:27:15 -0700 (MST) Message-Id: <1E401181-69B1-4DC9-BBDE-3DB8BE39C7D3@fugue.com> From: Ted Lemon To: TS Glassey In-Reply-To: <01bf01c82fe2$fc8db980$6401a8c0@tsg1> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Sun, 25 Nov 2007 22:27:14 -0600 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <474A3297.5040907@sun.com> <018401c82fd7$9f632c50$6401a8c0@tsg1> <474A3C32.1020006@sun.com> <474A43DB.1010009@ntp.org> <01bf01c82fe2$fc8db980$6401a8c0@tsg1> X-Mailer: Apple Mail (2.915) X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "ntpwg@lists.ntp.org" , Brian Utterback , "Richard Gayraud \(rgayraud\)" , "dhcwg@ietf.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 25, 2007, at 10:15 PM, TS Glassey wrote: > I was trying to stay as compatible as possible, but yes in the > Microsoft > world Service Records (SRV's) are the current manner to do this. The > problem I see is that SRV's cannot return the key as well as the > address for > secured service lookup. Are you guys seriously proposing using DNSSEC as a way to secure the keys to NTP? By how many orders of magnitude do you think this increases the value of the DNS root key? Based on the messages that I see flying by, with talk of "audit" and "keys", I don't even understand why we're having this discussion. If DHCP is the cornerstone of your security model, you are doomed. If DNSSEC is the cornerstone of your security model, you're putting all of your eggs in a single basket. It's no wonder we're not converging here - what you're proposing to do is essentially impossible! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 25 23:58:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwW3F-0005Y3-H5; Sun, 25 Nov 2007 23:58:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwW3E-0005Xx-A8 for dhcwg@ietf.org; Sun, 25 Nov 2007 23:58:32 -0500 Received: from mx05.gis.net ([208.218.130.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwW3A-0001y4-Uv for dhcwg@ietf.org; Sun, 25 Nov 2007 23:58:32 -0500 Received: from [10.10.10.101] ([63.209.224.211]) by mx05.gis.net; Sun, 25 Nov 2007 23:58:22 -0500 Message-ID: <474A51CB.4090500@ntp.org> Date: Sun, 25 Nov 2007 23:55:39 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ted Lemon Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <474A3297.5040907@sun.com> <018401c82fd7$9f632c50$6401a8c0@tsg1> <474A3C32.1020006@sun.com> <474A43DB.1010009@ntp.org> <01bf01c82fe2$fc8db980$6401a8c0@tsg1> <1E401181-69B1-4DC9-BBDE-3DB8BE39C7D3@fugue.com> In-Reply-To: <1E401181-69B1-4DC9-BBDE-3DB8BE39C7D3@fugue.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , TS Glassey , Brian Utterback , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ted Lemon wrote: > On Nov 25, 2007, at 10:15 PM, TS Glassey wrote: >> I was trying to stay as compatible as possible, but yes in the Microsoft >> world Service Records (SRV's) are the current manner to do this. The >> problem I see is that SRV's cannot return the key as well as the >> address for >> secured service lookup. > > Are you guys seriously proposing using DNSSEC as a way to secure the > keys to NTP? By how many orders of magnitude do you think this > increases the value of the DNS root key? > > Based on the messages that I see flying by, with talk of "audit" and > "keys", I don't even understand why we're having this discussion. If > DHCP is the cornerstone of your security model, you are doomed. If > DNSSEC is the cornerstone of your security model, you're putting all of > your eggs in a single basket. It's no wonder we're not converging here > - what you're proposing to do is essentially impossible! We are not suggesting this at all. His suggestion makes no sense to me either. At least we are on the same side for some things! Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 00:00:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwW5A-0007sE-Hf; Mon, 26 Nov 2007 00:00:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwW59-0007oZ-9z for dhcwg@ietf.org; Mon, 26 Nov 2007 00:00:31 -0500 Received: from mx05.gis.net ([208.218.130.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwW55-000215-Sk for dhcwg@ietf.org; Mon, 26 Nov 2007 00:00:31 -0500 Received: from [10.10.10.101] ([63.209.224.211]) by mx05.gis.net; Sun, 25 Nov 2007 23:59:41 -0500 Message-ID: <474A521A.2090905@ntp.org> Date: Sun, 25 Nov 2007 23:56:58 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ted Lemon Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Mark Andrews , TS Glassey , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ted, Let me try and outline the problem again and please come up with an idea which solves this. 1) The DHCP environment is divided into essentially two groups: Hardware like Netgear and Linksys routers and Software like ISC's DHCP Server and Nominum's Dynamic Configuration Server. IETF doesn't allow you to create a protocol which differentiate between these cases. The software side of the DHCP implementations are usually run by organizations for their internal use and are actively maintained. I have few worries about these since it's easy to deal with (relatively speaking) errors that the sysadmins make. The SOHO routers are different since the DHCP servers are built into the firmware and shipped in their 10's of thousands to individuals and small businesses who want wireless connections and routers but don't want to be in the business of configuring and maintaining them. So let's say Acme Routers ships a router with a builtin DHCP server which provides NTP server addresses to provide to the DHCP clients and they put just one address in it. Now say Starbucks gets all excited about how cheap they are and buys them for all their coffee stores. Now you have DHCP providing and amplication DDOS attack as all of those people sitting there laptops are all set up with the same NTP server address and sending NTP packets to the same NTP server. Note that in the UWisc/Netgear incident it was the NTP server built into the router that was the problem but it was only one server. Here we are having the router distributing the address to other systems which then do the dirty work and you'd get 10 times the effect of a Netgear incident. This is the problem that I'm trying to solve or rather mitigate. I refer you to the UWisc/Netgear incident paper that Dave Mills and Dave Plonka wrote: http://www.eecis.udel.edu/~mills/database/papers/ptti/ptti04a.pdf The brief slide version is here: http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.pdf It also discusses the loads on a number of other servers inclusing NIST and USNO PHK's incident with D-Link is written up here: http://news.bbc.co.uk/2/hi/technology/4906138.stm I await your suggestions on how to prevent the routers becoming amplifiers via DHCP to bombarding NTP servers. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 00:05:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwWAE-00030W-30; Mon, 26 Nov 2007 00:05:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwWAC-00030M-HB for dhcwg@ietf.org; Mon, 26 Nov 2007 00:05:44 -0500 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwWAC-00027P-2d for dhcwg@ietf.org; Mon, 26 Nov 2007 00:05:44 -0500 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id lAQ55V01028000; Mon, 26 Nov 2007 16:05:32 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200711260505.lAQ55V01028000@drugs.dv.isc.org> To: mayer@ntp.isc.org From: Mark Andrews Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 In-reply-to: Your message of "Sun, 25 Nov 2007 23:41:13 CDT." <474A4E69.8040408@ntp.isc.org> Date: Mon, 26 Nov 2007 16:05:30 +1100 X-Spam-Score: -1.4 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, TS Glassey , Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Danny this really is a non-issue. A SOHO DHCP server side will learn its values from the SOHO DHCP client side. SOHO DHCP servers do this today for lots of values it returns to the SOHO network. Today you have a check box on SOHO routers that says [ ] DNS servers learn from network. If it is not checked you get a dialog to fill in. Tomorrow you will have a check box on SOHO routers that says [ ] NTP servers learn from network. If it's not checked you will get a dialog to fill in. Similarly IPv6 PD requests will chain through multiple DHCP servers until you find one which will allocate the space requested. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 03:34:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwZQ1-0004cj-L9; Mon, 26 Nov 2007 03:34:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwZPy-0004ca-UP for dhcwg@ietf.org; Mon, 26 Nov 2007 03:34:14 -0500 Received: from intermail.se.dataphone.net ([212.37.1.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwZPy-0001oV-G3 for dhcwg@ietf.org; Mon, 26 Nov 2007 03:34:14 -0500 Received: from [213.115.152.226] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.2) with ESMTP id 51673984 for dhcwg@ietf.org; Mon, 26 Nov 2007 09:34:12 +0100 From: Bud Millwood Organization: Weird Solutions, Inc. To: dhcwg@ietf.org Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Mon, 26 Nov 2007 08:48:23 +0100 User-Agent: KMail/1.8 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> In-Reply-To: <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711260848.23497.budm@weird-solutions.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bud Millwood List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Monday 26 November 2007 01:50, TS Glassey wrote: > So Ted how does the DHCP server get refreshed to know that NTP Server "A" > is dead now? The server runs a keepalive for this service list (NTP). When an NTP server is down the list entry is marked as such and not given out until it's back online. No administrative intervention required unless all servers die. - Bud > Todd > > ----- Original Message ----- > From: "Ted Lemon" > To: "Mark Andrews" > Cc: ; "Danny Mayer" ; "Richard Gayraud > (rgayraud)" ; > Sent: Sunday, November 25, 2007 4:40 PM > Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) > OptionsforDHCPv6 > > > On Nov 25, 2007, at 6:09 PM, Mark Andrews wrote: > >> I would think that this should be a push operation from the dhcp > >> client rather than a pull operation. > > > > Sure, but it amounts to the same thing. This is trivial to do with > > the ISC DHCP client (which I presume is the one you use). It's also > > trivial to do on Linux with dbus. Mac OS X and Windows handle it > > differently still, but they already have mechanisms in place for doing > > this. So the point is that if the will exists to make it happen, > > it's trivial to make it happen. > > > > _______________________________________________ > > ntpwg mailing list > > ntpwg@lists.ntp.org > > https://lists.ntp.org/mailman/listinfo/ntpwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -- Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 04:20:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwa8Y-0001Md-1u; Mon, 26 Nov 2007 04:20:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwa8W-0001MY-N9 for dhcwg@ietf.org; Mon, 26 Nov 2007 04:20:16 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwa8P-0008ST-Jp for dhcwg@ietf.org; Mon, 26 Nov 2007 04:20:16 -0500 X-IronPort-AV: E=Sophos;i="4.21,466,1188770400"; d="scan'208";a="158743984" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2007 10:20:09 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAQ9K8C3023106; Mon, 26 Nov 2007 10:20:09 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAQ9JlZx013290; Mon, 26 Nov 2007 09:19:57 GMT Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 10:19:49 +0100 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 Subject: RE: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Mon, 26 Nov 2007 10:20:59 +0100 Message-ID: In-Reply-To: <474A4E69.8040408@ntp.isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Thread-Index: Acgv5xN1csyjGVFgRQ6q0vpw0iqvrwAIz83g References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A4E69.8040408@ntp.isc.org> From: "Benoit Lourdelet (blourdel)" To: X-OriginalArrivalTime: 26 Nov 2007 09:19:49.0039 (UTC) FILETIME=[7E385BF0:01C8300D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4686; t=1196068809; x=1196932809; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=blourdel@cisco.com; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20 |Subject:=20RE=3A=20[ntpwg]=20[dhcwg]=20Re=3A=20Network=20Time=20Protocol =20(NTP)=20OptionsforDHCPv6 |Sender:=20; bh=VgZcgdwKR6Q7mH/nvrI5hD58K3bkGYFzB8MIEJ5/LS4=; b=e9HyNGZvnHmqZR7Ilhec3SAfii89wpGZdiJbjF01sV0Bm0/BgFG6F9WBa9kRCWyk/RAnwJM3 uuOyk8m3pDqkCRDWs6tgFqFGHLOfC3A529vGQ7RSf2Fl0pgCVo5OS26k; Authentication-Results: ams-dkim-1; header.From=blourdel@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -3.7 (---) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Danny, I want to highlight that the UWisc/Netgear happened without DHCP and I suspect that a similar incident=20 may happen again. DHCP as you described it could be an amplification factor but with millions of CPE wrongly configured there is no need of DHCP to have things going wrong. Correctly deployed, an off-the-shelf SOHO router should not have any server hardcoded -You will never prevent people from doing bad thing on a CPE router anyway - and should receive its IP services server (including NTP) from the provider. For all other cases, Enterprise where the DHCP server is managed by IT people of the same administrative domain and ISP settop boxes with DHCP managed with the Telcos, an DHCPv6 NTP hardcoded address is not going to hurt anybody as a DHCP Client wont use an expired IP service address for ever. Mandating the use of site local address may complicate deployments in the case of company mergers in the initial stage. Again, the DHCP server is managed by people of the same administrative domain that are supposed to configure it with=20 correct IP addresses. The way NTP is deployed in many SP networks is to use a hierarchy of NTP server, so that the NTP server is very close to=20 NTP Client. In many case the client is pointing to an NTP server in the same Point Of Presence. In enterprise deployments, if IT bothers relying on NTP, they will deploy their own NTP servers and wont rely on public NTP servers. Needless to say that top of the hierarchy enterprise NTP servers wont use DHCP for configuration. Benoit > -----Original Message----- > From: ntpwg-bounces+blourdel=3Dcisco.com@lists.ntp.org=20 > [mailto:ntpwg-bounces+blourdel=3Dcisco.com@lists.ntp.org] On=20 > Behalf Of Danny Mayer > Sent: Monday, November 26, 2007 5:41 AM > To: Ted Lemon > Cc: ntpwg@lists.ntp.org; dhcwg@ietf.org; Richard Gayraud (rgayraud) > Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)=20 > OptionsforDHCPv6 >=20 > Ted, >=20 > Let me try and outline the problem again and please come up=20 > with an idea which solves this. >=20 > 1) The DHCP environment is divided into essentially two=20 > groups: Hardware like Netgear and Linksys routers and=20 > Software like ISC's DHCP Server and Nominum's Dynamic=20 > Configuration Server. IETF doesn't allow you to create a=20 > protocol which differentiate between these cases. >=20 > The software side of the DHCP implementations are usually run=20 > by organizations for their internal use and are actively=20 > maintained. I have few worries about these since it's easy to=20 > deal with (relatively > speaking) errors that the sysadmins make. >=20 > The SOHO routers are different since the DHCP servers are=20 > built into the firmware and shipped in their 10's of=20 > thousands to individuals and small businesses who want=20 > wireless connections and routers but don't want to be in the=20 > business of configuring and maintaining them. >=20 > So let's say Acme Routers ships a router with a builtin DHCP=20 > server which provides NTP server addresses to provide to the=20 > DHCP clients and they put just one address in it. Now say=20 > Starbucks gets all excited about how cheap they are and buys=20 > them for all their coffee stores. Now you have DHCP providing=20 > and amplication DDOS attack as all of those people sitting=20 > there laptops are all set up with the same NTP server address=20 > and sending NTP packets to the same NTP server. Note that in=20 > the UWisc/Netgear incident it was the NTP server built into=20 > the router that was the problem but it was only one server.=20 > Here we are having the router distributing the address to=20 > other systems which then do the dirty work and you'd get 10=20 > times the effect of a Netgear incident. This is the problem=20 > that I'm trying to solve or rather mitigate. >=20 > I refer you to the UWisc/Netgear incident paper that Dave=20 > Mills and Dave Plonka wrote: > http://www.eecis.udel.edu/~mills/database/papers/ptti/ptti04a.pdf > The brief slide version is here: > http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.pdf > It also discusses the loads on a number of other servers=20 > inclusing NIST and USNO >=20 > PHK's incident with D-Link is written up here: > http://news.bbc.co.uk/2/hi/technology/4906138.stm >=20 > I await your suggestions on how to prevent the routers=20 > becoming amplifiers via DHCP to bombarding NTP servers. >=20 > Danny > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 07:00:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwcd2-0008QW-9g; Mon, 26 Nov 2007 06:59:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwc7J-0007qE-On for dhcwg@ietf.org; Mon, 26 Nov 2007 06:27:09 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwc7J-00066i-3k for dhcwg@ietf.org; Mon, 26 Nov 2007 06:27:09 -0500 Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 11:27:07 +0000 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 Subject: RE: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Mon, 26 Nov 2007 11:27:06 -0000 Message-ID: <548EC156325C6340B2E85DF90CAE85860199F3ED@E03MVB3-UKBR.domain1.systemhost.net> In-Reply-To: <474A4E69.8040408@ntp.isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Thread-Index: Acgv5xDse9ztUO1RSae6MSf9gYBawQAOAheA From: To: , X-OriginalArrivalTime: 26 Nov 2007 11:27:07.0775 (UTC) FILETIME=[4742F8F0:01C8301F] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-Mailman-Approved-At: Mon, 26 Nov 2007 06:59:50 -0500 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, rgayraud@cisco.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Surely an ISP DNS must suffer the same issue. How do DNS implementations deal with the same problem given that the "attack" traffic then happens far more often.=20 -----Original Message----- From: ntpwg-bounces+anthony.flavin=3Dbt.com@lists.ntp.org [mailto:ntpwg-bounces+anthony.flavin=3Dbt.com@lists.ntp.org] On Behalf = Of Danny Mayer Sent: 26 November 2007 04:41 To: Ted Lemon Cc: ntpwg@lists.ntp.org; dhcwg@ietf.org; Richard Gayraud (rgayraud) Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Ted, Let me try and outline the problem again and please come up with an idea which solves this. 1) The DHCP environment is divided into essentially two groups: Hardware like Netgear and Linksys routers and Software like ISC's DHCP Server and Nominum's Dynamic Configuration Server. IETF doesn't allow you to create a protocol which differentiate between these cases. The software side of the DHCP implementations are usually run by organizations for their internal use and are actively maintained. I have few worries about these since it's easy to deal with (relatively speaking) errors that the sysadmins make. The SOHO routers are different since the DHCP servers are built into the firmware and shipped in their 10's of thousands to individuals and small businesses who want wireless connections and routers but don't want to be in the business of configuring and maintaining them. So let's say Acme Routers ships a router with a builtin DHCP server which provides NTP server addresses to provide to the DHCP clients and they put just one address in it. Now say Starbucks gets all excited about how cheap they are and buys them for all their coffee stores. Now you have DHCP providing and amplication DDOS attack as all of those people sitting there laptops are all set up with the same NTP server address and sending NTP packets to the same NTP server. Note that in the UWisc/Netgear incident it was the NTP server built into the router that was the problem but it was only one server. Here we are having the router distributing the address to other systems which then do the dirty work and you'd get 10 times the effect of a Netgear incident. This is the problem that I'm trying to solve or rather mitigate. I refer you to the UWisc/Netgear incident paper that Dave Mills and Dave Plonka wrote: http://www.eecis.udel.edu/~mills/database/papers/ptti/ptti04a.pdf The brief slide version is here: http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.pdf It also discusses the loads on a number of other servers inclusing NIST and USNO PHK's incident with D-Link is written up here: http://news.bbc.co.uk/2/hi/technology/4906138.stm I await your suggestions on how to prevent the routers becoming amplifiers via DHCP to bombarding NTP servers. Danny _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 07:00:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwcd2-0008QR-33; Mon, 26 Nov 2007 06:59:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuiaB-0002t3-HJ for dhcwg@ietf.org; Wed, 21 Nov 2007 00:57:07 -0500 Received: from bsdimp.com ([199.45.160.85] helo=harmony.bsdimp.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuiaA-0004Np-VT for dhcwg@ietf.org; Wed, 21 Nov 2007 00:57:07 -0500 Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lAL5uEOi049219; Tue, 20 Nov 2007 22:56:14 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 20 Nov 2007 22:57:00 -0700 (MST) Message-Id: <20071120.225700.1649769107.imp@bsdimp.com> To: David_Hankins@isc.org Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 From: "M. Warner Losh" In-Reply-To: <20071119225643.GI14750@isc.org> References: <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <20071119225643.GI14750@isc.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Mon, 26 Nov 2007 06:59:50 -0500 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org In message: <20071119225643.GI14750@isc.org> "David W. Hankins" writes: : I seem to recall he was actually sued by the : SOHO router manufacturer, because all their SOHO routers suddenly : started spitting errors and misbehaving when this free service was : withheld, but my memory is beyond its limits at this point. Poul-Henning Kamp wasn't sued by Linksys. He contacted them to get made whole for the damage their firmware caused to him in direct bandwidth costs. Linksys released new firmware and agreed to make him happy in other ways that was never released to the public. The problem of a hard-coded IPv4 address remains, but in this instance eventually the right thing happened. Or as close as one can get in today's less than ideal world. Warner _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 07:00:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwcd2-0008QW-9g; Mon, 26 Nov 2007 06:59:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwc7J-0007qE-On for dhcwg@ietf.org; Mon, 26 Nov 2007 06:27:09 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwc7J-00066i-3k for dhcwg@ietf.org; Mon, 26 Nov 2007 06:27:09 -0500 Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 11:27:07 +0000 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 Subject: RE: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Mon, 26 Nov 2007 11:27:06 -0000 Message-ID: <548EC156325C6340B2E85DF90CAE85860199F3ED@E03MVB3-UKBR.domain1.systemhost.net> In-Reply-To: <474A4E69.8040408@ntp.isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Thread-Index: Acgv5xDse9ztUO1RSae6MSf9gYBawQAOAheA From: To: , X-OriginalArrivalTime: 26 Nov 2007 11:27:07.0775 (UTC) FILETIME=[4742F8F0:01C8301F] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-Mailman-Approved-At: Mon, 26 Nov 2007 06:59:50 -0500 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, rgayraud@cisco.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Surely an ISP DNS must suffer the same issue. How do DNS implementations deal with the same problem given that the "attack" traffic then happens far more often.=20 -----Original Message----- From: ntpwg-bounces+anthony.flavin=3Dbt.com@lists.ntp.org [mailto:ntpwg-bounces+anthony.flavin=3Dbt.com@lists.ntp.org] On Behalf = Of Danny Mayer Sent: 26 November 2007 04:41 To: Ted Lemon Cc: ntpwg@lists.ntp.org; dhcwg@ietf.org; Richard Gayraud (rgayraud) Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Ted, Let me try and outline the problem again and please come up with an idea which solves this. 1) The DHCP environment is divided into essentially two groups: Hardware like Netgear and Linksys routers and Software like ISC's DHCP Server and Nominum's Dynamic Configuration Server. IETF doesn't allow you to create a protocol which differentiate between these cases. The software side of the DHCP implementations are usually run by organizations for their internal use and are actively maintained. I have few worries about these since it's easy to deal with (relatively speaking) errors that the sysadmins make. The SOHO routers are different since the DHCP servers are built into the firmware and shipped in their 10's of thousands to individuals and small businesses who want wireless connections and routers but don't want to be in the business of configuring and maintaining them. So let's say Acme Routers ships a router with a builtin DHCP server which provides NTP server addresses to provide to the DHCP clients and they put just one address in it. Now say Starbucks gets all excited about how cheap they are and buys them for all their coffee stores. Now you have DHCP providing and amplication DDOS attack as all of those people sitting there laptops are all set up with the same NTP server address and sending NTP packets to the same NTP server. Note that in the UWisc/Netgear incident it was the NTP server built into the router that was the problem but it was only one server. Here we are having the router distributing the address to other systems which then do the dirty work and you'd get 10 times the effect of a Netgear incident. This is the problem that I'm trying to solve or rather mitigate. I refer you to the UWisc/Netgear incident paper that Dave Mills and Dave Plonka wrote: http://www.eecis.udel.edu/~mills/database/papers/ptti/ptti04a.pdf The brief slide version is here: http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.pdf It also discusses the loads on a number of other servers inclusing NIST and USNO PHK's incident with D-Link is written up here: http://news.bbc.co.uk/2/hi/technology/4906138.stm I await your suggestions on how to prevent the routers becoming amplifiers via DHCP to bombarding NTP servers. Danny _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 07:00:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwcd2-0008QR-33; Mon, 26 Nov 2007 06:59:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuiaB-0002t3-HJ for dhcwg@ietf.org; Wed, 21 Nov 2007 00:57:07 -0500 Received: from bsdimp.com ([199.45.160.85] helo=harmony.bsdimp.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuiaA-0004Np-VT for dhcwg@ietf.org; Wed, 21 Nov 2007 00:57:07 -0500 Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lAL5uEOi049219; Tue, 20 Nov 2007 22:56:14 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 20 Nov 2007 22:57:00 -0700 (MST) Message-Id: <20071120.225700.1649769107.imp@bsdimp.com> To: David_Hankins@isc.org Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 From: "M. Warner Losh" In-Reply-To: <20071119225643.GI14750@isc.org> References: <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <20071119225643.GI14750@isc.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Mon, 26 Nov 2007 06:59:50 -0500 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org In message: <20071119225643.GI14750@isc.org> "David W. Hankins" writes: : I seem to recall he was actually sued by the : SOHO router manufacturer, because all their SOHO routers suddenly : started spitting errors and misbehaving when this free service was : withheld, but my memory is beyond its limits at this point. Poul-Henning Kamp wasn't sued by Linksys. He contacted them to get made whole for the damage their firmware caused to him in direct bandwidth costs. Linksys released new firmware and agreed to make him happy in other ways that was never released to the public. The problem of a hard-coded IPv4 address remains, but in this instance eventually the right thing happened. Or as close as one can get in today's less than ideal world. Warner _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 07:01:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwceq-0001TO-F6; Mon, 26 Nov 2007 07:01:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwcep-0001TI-1v for dhcwg@ietf.org; Mon, 26 Nov 2007 07:01:47 -0500 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwceh-0003rG-66 for dhcwg@ietf.org; Mon, 26 Nov 2007 07:01:47 -0500 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id lAQC1NS8060633; Mon, 26 Nov 2007 23:01:24 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200711261201.lAQC1NS8060633@drugs.dv.isc.org> To: anthony.flavin@bt.com From: Mark Andrews Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 In-reply-to: Your message of "Mon, 26 Nov 2007 11:27:06 -0000." <548EC156325C6340B2E85DF90CAE85860199F3ED@E03MVB3-UKBR.domain1.systemhost.net> Date: Mon, 26 Nov 2007 23:01:23 +1100 X-Spam-Score: -1.4 (-) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mayer@ntp.isc.org, ntpwg@lists.ntp.org, mellon@fugue.com, rgayraud@cisco.com, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > Surely an ISP DNS must suffer the same issue. How do DNS implementations > deal with the same problem given that the "attack" traffic then happens > far more often. If the SOHO boxs all handed out the same address for the DNS servers then there would be a problem. It reality there isn't because ISP's configure the DHCP servers to point to the ISP's caching DNS servers. The SOHO boxes just re advertise what they have learnt from upstream. ISP's will do similar things with NTP servers. They will point the DHCP clients to their NTP servers. SOHO routeres will just re advertise what they learnt. This is a non-issue. Mark > -----Original Message----- > From: ntpwg-bounces+anthony.flavin=bt.com@lists.ntp.org > [mailto:ntpwg-bounces+anthony.flavin=bt.com@lists.ntp.org] On Behalf Of > Danny Mayer > Sent: 26 November 2007 04:41 > To: Ted Lemon > Cc: ntpwg@lists.ntp.org; dhcwg@ietf.org; Richard Gayraud (rgayraud) > Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) > OptionsforDHCPv6 > > Ted, > > Let me try and outline the problem again and please come up with an idea > which solves this. > > 1) The DHCP environment is divided into essentially two groups: Hardware > like Netgear and Linksys routers and Software like ISC's DHCP Server and > Nominum's Dynamic Configuration Server. IETF doesn't allow you to create > a protocol which differentiate between these cases. > > The software side of the DHCP implementations are usually run by > organizations for their internal use and are actively maintained. I have > few worries about these since it's easy to deal with (relatively > speaking) errors that the sysadmins make. > > The SOHO routers are different since the DHCP servers are built into the > firmware and shipped in their 10's of thousands to individuals and small > businesses who want wireless connections and routers but don't want to > be in the business of configuring and maintaining them. > > So let's say Acme Routers ships a router with a builtin DHCP server > which provides NTP server addresses to provide to the DHCP clients and > they put just one address in it. Now say Starbucks gets all excited > about how cheap they are and buys them for all their coffee stores. Now > you have DHCP providing and amplication DDOS attack as all of those > people sitting there laptops are all set up with the same NTP server > address and sending NTP packets to the same NTP server. Note that in the > UWisc/Netgear incident it was the NTP server built into the router that > was the problem but it was only one server. Here we are having the > router distributing the address to other systems which then do the dirty > work and you'd get 10 times the effect of a Netgear incident. This is > the problem that I'm trying to solve or rather mitigate. > > I refer you to the UWisc/Netgear incident paper that Dave Mills and Dave > Plonka wrote: > http://www.eecis.udel.edu/~mills/database/papers/ptti/ptti04a.pdf > The brief slide version is here: > http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.pdf > It also discusses the loads on a number of other servers inclusing NIST > and USNO > > PHK's incident with D-Link is written up here: > http://news.bbc.co.uk/2/hi/technology/4906138.stm > > I await your suggestions on how to prevent the routers becoming > amplifiers via DHCP to bombarding NTP servers. > > Danny > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 09:21:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iweq4-00046K-9I; Mon, 26 Nov 2007 09:21:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iweq3-00046D-26 for dhcwg@ietf.org; Mon, 26 Nov 2007 09:21:31 -0500 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iweq2-0001Ry-Km for dhcwg@ietf.org; Mon, 26 Nov 2007 09:21:30 -0500 Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAQELIAN013855; Mon, 26 Nov 2007 14:21:18 GMT Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lAQELHev018930; Mon, 26 Nov 2007 09:21:18 -0500 (EST) Message-ID: <474AD65D.2010707@sun.com> Date: Mon, 26 Nov 2007 09:21:17 -0500 From: Brian Utterback User-Agent: Thunderbird 2.0.0.10pre (X11/20071118) MIME-Version: 1.0 To: TS Glassey Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <474A3297.5040907@sun.com> <018401c82fd7$9f632c50$6401a8c0@tsg1> <474A3C32.1020006@sun.com> <01b601c82fe1$b77d2c00$6401a8c0@tsg1> In-Reply-To: <01b601c82fe1$b77d2c00$6401a8c0@tsg1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org TS Glassey wrote: > My real suggestion is that we need a Time and Trust Service Discovery > protocol which would work sort of like how DHCP and DNS work but that also > allows for critical events to be pushed forward as well. This would also > work for CRL and OCSP type queries to satisfy validity of the underlying > certificate source. > > Todd > Sounds great to me, Todd. I really think that you should pursue that. I don't think that this is that protocol and I don't think it is fair to hold up this one because it isn't that one. Write a spec, make a prototype and publish them, and then we can talk about that one. -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 10:10:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfbI-0007yZ-FN; Mon, 26 Nov 2007 10:10:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuJkc-0007pa-Op; Mon, 19 Nov 2007 22:26:14 -0500 Received: from gura.nttv6.jp ([2001:218:1:1040::2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuJkc-00059F-8i; Mon, 19 Nov 2007 22:26:14 -0500 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 84EE3BDC20; Tue, 20 Nov 2007 12:26:13 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 5A2F06ECCA; Tue, 20 Nov 2007 12:26:13 +0900 (JST) Date: Tue, 20 Nov 2007 12:26:13 +0900 (JST) Message-Id: <20071120.122613.226764692.miyakawa@nttv6.jp> To: alper.yegin@yegin.org Subject: Re: [Int-area] Re: [dhcwg] Discussion of dhc WGrecharteringforDHCPauthentication From: Shin Miyakawa In-Reply-To: <20071120.122403.193720425.miyakawa@nttv6.jp> References: <473F3F45.4050204@gmail.com> <0MKp8S-1IuF4d142M-0005uP@mrelay.perfora.net> <20071120.122403.193720425.miyakawa@nttv6.jp> Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-Mailman-Approved-At: Mon, 26 Nov 2007 10:10:15 -0500 Cc: dhcwg@ietf.org, alexandru.petrescu@gmail.com, miyakawa@nttv6.jp, int-area@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org (due to some technical problem, I missed int-area ML. so please forgive me to send this message again.) From: "Alper Yegin" Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WGrecharteringforDHCPauthentication Date: Tue, 20 Nov 2007 00:26:23 +0200 > I need to let NTT folks answer that. Which means Me , Alper ? :-p > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > But Alper - can you cite how NTT is doing it? http://www.ipv6style.jp/en/statistics/services/index.shtml is a good reference what we're doing in Japan. Not only by NTT. Talking about ISP service, please see http://www.v6.ntt.net/index_e.html > > How many customers? We can not disclose without proper permission from company, sorry about that. > > How many addresses delivered to customer? > > What kind of addresses are delivered? Please look at RFC4241. Actually, we've modified a bit in addition to this model. Basically, we've added RA onto the uplink between CPE and Access Concentrator because of some operating system like Windows Vista uses the strong model for its network design. If I could have a chance, I am grad to tell about our architecture in Vancouvor in some proper place. > >What transition mechanism? No transition mechanism. Also, we've already commercialized "softwire" service named "OCNIPv6". Basically, this is as same as we've discussed within SOFTWIRE WG of IETF. > > I'm talking from a 2001 experience of actually picking up the phone and > > calling NTT and asking them for IPv6 access. > > > > All these things are important in order to really answer the question > > raised above. > > > > It may all be in that 'residential' keyword. How much 'residential' is > > a SOHO? What does 'residential' really mean in Japanese? SOHO as well as just an apartment or house. One my house in Tokyo had been equipped with residential IPv6/v4 dual ADSL service from my own company. I believe that this is residential :-) (Now I personally am using FTTH service from NTT as well with IPv6 softwire commercial service on it.) Best regards, Shin Miyakawa NTT Communications Corporation _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 10:10:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfbI-0007yz-OL; Mon, 26 Nov 2007 10:10:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwdYY-00051f-4g for dhcwg@ietf.org; Mon, 26 Nov 2007 07:59:22 -0500 Received: from exchdev.pega.com ([198.22.153.35] helo=exchdev.rpega.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwdYX-0007wv-Rb for dhcwg@ietf.org; Mon, 26 Nov 2007 07:59:22 -0500 Received: from [10.60.98.36] ([10.60.98.36]) by exchdev.rpega.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 07:59:16 -0500 Message-ID: <474AC280.30909@ntp.isc.org> Date: Mon, 26 Nov 2007 07:56:32 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "M. Warner Losh" Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 References: <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <20071119225643.GI14750@isc.org> <20071120.225700.1649769107.imp@bsdimp.com> In-Reply-To: <20071120.225700.1649769107.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2007 12:59:16.0724 (UTC) FILETIME=[26C5A340:01C8302C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Mon, 26 Nov 2007 10:10:15 -0500 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mayer@ntp.isc.org List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org M. Warner Losh wrote: > In message: <20071119225643.GI14750@isc.org> > "David W. Hankins" writes: > : I seem to recall he was actually sued by the > : SOHO router manufacturer, because all their SOHO routers suddenly > : started spitting errors and misbehaving when this free service was > : withheld, but my memory is beyond its limits at this point. > > Poul-Henning Kamp wasn't sued by Linksys. He contacted them to get > made whole for the damage their firmware caused to him in direct > bandwidth costs. Linksys released new firmware and agreed to make him > happy in other ways that was never released to the public. > It wasn't Linksys, it was D-Link. According to the note on his Web site Poul was satisfied with whatever was agreed upon. Danny > The problem of a hard-coded IPv4 address remains, but in this instance > eventually the right thing happened. Or as close as one can get in > today's less than ideal world. > > Warner _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 11:13:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgaV-0006Ca-TL; Mon, 26 Nov 2007 11:13:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgaU-0006CJ-LM for dhcwg@ietf.org; Mon, 26 Nov 2007 11:13:34 -0500 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwgaT-0004Tf-VP for dhcwg@ietf.org; Mon, 26 Nov 2007 11:13:34 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=qUmbrOct+U/15gyl6Hji8dgFjPOH0dr84AKv8IF/Rt7RqPyeIgLKn3SA/K0OJvpO; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IwgaM-0006zX-Bc; Mon, 26 Nov 2007 11:13:26 -0500 Message-ID: <003d01c83047$468ee400$6401a8c0@tsg1> From: "TS Glassey" To: , , References: <548EC156325C6340B2E85DF90CAE85860199F3ED@E03MVB3-UKBR.domain1.systemhost.net> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Mon, 26 Nov 2007 07:45:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec795a7e727c0be27db5ec7be53d3bb4cb8f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, rgayraud@cisco.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org ----- Original Message ----- From: To: ; Cc: ; ; Sent: Monday, November 26, 2007 3:27 AM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 > Surely an ISP DNS must suffer the same issue. How do DNS implementations > deal with the same problem given that the "attack" traffic then happens > far more often. > > -----Original Message----- > From: ntpwg-bounces+anthony.flavin=bt.com@lists.ntp.org > [mailto:ntpwg-bounces+anthony.flavin=bt.com@lists.ntp.org] On Behalf Of > Danny Mayer > Sent: 26 November 2007 04:41 > To: Ted Lemon > Cc: ntpwg@lists.ntp.org; dhcwg@ietf.org; Richard Gayraud (rgayraud) > Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) > OptionsforDHCPv6 > > Ted, > > Let me try and outline the problem again and please come up with an idea > which solves this. > > 1) The DHCP environment is divided into essentially two groups: Hardware > like Netgear and Linksys routers and Software like ISC's DHCP Server and > Nominum's Dynamic Configuration Server. IETF doesn't allow you to create > a protocol which differentiate between these cases. Which documents why the IETF is broken. Its run by people who do what they want to do rather than by folks who want any and all standards to be vetted and brought forth. If this wasnt true there would be a simple and well defined vetting process. > > The software side of the DHCP implementations are usually run by > organizations for their internal use and are actively maintained. I have > few worries about these since it's easy to deal with (relatively > speaking) errors that the sysadmins make. > > The SOHO routers are different since the DHCP servers are built into the > firmware and shipped in their 10's of thousands to individuals and small > businesses who want wireless connections and routers but don't want to > be in the business of configuring and maintaining them. > > So let's say Acme Routers ships a router with a builtin DHCP server > which provides NTP server addresses to provide to the DHCP clients and > they put just one address in it. OK... > Now say Starbucks gets all excited > about how cheap they are and buys them for all their coffee stores. yeah... but this is only twenty or thirty thousand nationwide... what's a real problem is where someone produces a CABLE MODEM which has hardcoded NTP service addresses programmed into the units, and that becomes 75,000 or more units per medium sized city. > Now > you have DHCP providing and amplication DDOS attack as all of those > people sitting there laptops are all set up with the same NTP server > address and sending NTP packets to the same NTP server. You mean like what happened to PHK, my and other Time Servers last year? > Note that in the > UWisc/Netgear incident it was the NTP server built into the router that > was the problem but it was only one server. Here we are having the > router distributing the address to other systems which then do the dirty > work and you'd get 10 times the effect of a Netgear incident. This is > the problem that I'm trying to solve or rather mitigate. NetGear was upright and stepped to the plate unlike the other suppliers, especially our friends in SoCal IMHO - http://en.wikipedia.org/wiki/NTP_vandalism > > I refer you to the UWisc/Netgear incident paper that Dave Mills and Dave > Plonka wrote: > http://www.eecis.udel.edu/~mills/database/papers/ptti/ptti04a.pdf > The brief slide version is here: > http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.pdf > It also discusses the loads on a number of other servers inclusing NIST > and USNO Having been a victim of the last flurry and other providers bashing of the public time servers let me ask how would they know what the loads on the server's are? They also didnt calculate the DNS overhead into the bigger picture as well, so its not just the NTP traffic, but the DNS overhead on the front side of the NTP transaction. The real issue here is the California Supreme Court ruling on whether IP addresses and Domain Names are protectable as IP's which are unique to those users. > > PHK's incident with D-Link is written up here: > http://news.bbc.co.uk/2/hi/technology/4906138.stm > > I await your suggestions on how to prevent the routers becoming > amplifiers via DHCP to bombarding NTP servers. NTP needs a server and server-policy discovery model. DHCP isnt it either, nor is DNS really, but they can both be used to prime the pump per se though. > > Danny > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 11:37:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwgxq-0006fc-6A; Mon, 26 Nov 2007 11:37:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwgxp-0006fL-9D for dhcwg@ietf.org; Mon, 26 Nov 2007 11:37:41 -0500 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwgxo-0005Lp-O3 for dhcwg@ietf.org; Mon, 26 Nov 2007 11:37:41 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=lv0VbZHmyNhQB/aRA5GI8Bq7RbcLLSNReKcHgP+esIiJ5NK0utF6q1fS9NtzEq9f; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Iwgxn-000790-So; Mon, 26 Nov 2007 11:37:40 -0500 Message-ID: <004901c8304a$a8dfede0$6401a8c0@tsg1> From: "TS Glassey" To: "Brian Utterback" References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <474A3297.5040907@sun.com> <018401c82fd7$9f632c50$6401a8c0@tsg1> <474A3C32.1020006@sun.com> <01b601c82fe1$b77d2c00$6401a8c0@tsg1> <474AD65D.2010707@sun.com> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Mon, 26 Nov 2007 08:37:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec793f2df527c21b5f6f8835f5f9a40d02e4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Ted Lemon , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org ----- Original Message ----- From: "Brian Utterback" To: "TS Glassey" Cc: ; ; "Ted Lemon" ; "Richard Gayraud (rgayraud)" Sent: Monday, November 26, 2007 6:21 AM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 > > > TS Glassey wrote: >> My real suggestion is that we need a Time and Trust Service Discovery >> protocol which would work sort of like how DHCP and DNS work but that >> also allows for critical events to be pushed forward as well. This would >> also work for CRL and OCSP type queries to satisfy validity of the >> underlying certificate source. >> >> Todd >> > > Sounds great to me, Todd. I really think that you should pursue that. I have - already. In fact there are several implementations already written too. One for Solaris and another port to OS/X. The problem is that I am not willing to give away any and all rights to this protocol specification as you folks have done by taking NTP into the IETF. Better yet, look at the continuously revised participation requirements in the IETF and you will realize that most of this and all WG member's have committed fraud in representing to the IETF that they have a legal status to represent their sponsor's IP rights. I.e the new rules per BCP78/79. > I don't think that this is that protocol and I don't think it is > fair to hold up this one because it isn't that one. My objection is in creating mandatory components of the NTP package which are not minimalistic. Implementing this code over DHCP would be a security nightmare from the Audit Perspective, so what I propose is that if you want to add this support - its you folks who make this a BCP for configuring and operating NTP. Todd > Write a spec, > make a prototype and publish them, and then we can talk about that > one. > > -- > blu > > "You've added a new disk. Do you want to replace your current > drive, protect your data from a drive failure or expand your > storage capacity?" - Disk management as it should be. > ---------------------------------------------------------------------- > Brian Utterback - Solaris RPE, Sun Microsystems, Inc. > Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 12:09:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhSA-0001Gf-4E; Mon, 26 Nov 2007 12:09:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhS8-0001GW-SS for dhcwg@ietf.org; Mon, 26 Nov 2007 12:09:00 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwhS0-00048E-GC for dhcwg@ietf.org; Mon, 26 Nov 2007 12:09:00 -0500 X-IronPort-AV: E=Sophos;i="4.21,468,1188770400"; d="scan'208";a="158808497" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2007 18:08:51 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAQH8pII008768; Mon, 26 Nov 2007 18:08:51 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAQH8kZb007412; Mon, 26 Nov 2007 17:08:47 GMT Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 18:08:47 +0100 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 Subject: RE: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 Date: Mon, 26 Nov 2007 18:10:00 +0100 Message-ID: In-Reply-To: <47445863.4000208@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 Thread-Index: AcgsWTKjavik0Bj5SHaEIj8EDwiasQD9VtSw References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com><4743B902.3030406@udel.edu> <47445863.4000208@cisco.com> From: "Benoit Lourdelet (blourdel)" To: "Mark Stapp (mjs)" , "David L. Mills" X-OriginalArrivalTime: 26 Nov 2007 17:08:47.0177 (UTC) FILETIME=[01DB7B90:01C8304F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3902; t=1196096931; x=1196960931; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=blourdel@cisco.com; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20 |Subject:=20RE=3A=20[ntpwg]=20[dhcwg]=20Re=3A=20Network=20Time=20Protocol =20(NTP)=20Options=09for=09DHCPv6 |Sender:=20; bh=CuygMrJz7h1yiPRPJOKG/vvb7GxbY5CpijzLdontxN8=; b=uiVqZRM4wAtN5YKJhIOUVvfKg2rO5XGqdkxvpZASkw102nfVJHLoTeNMVUv0Y9oftAjkymSv 9WTgu2RUyIIaC3ckqUIhxzXHKlGH1HqL37ujYBcK4/Q4rFb6szp8HukB; Authentication-Results: ams-dkim-2; header.From=blourdel@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Mark and David, If we consider the already defined DHCPv4 and DHCPv6 Options, IP services are, in (almost) all cases, passed as an address and not as a name. =20 If we come to the conclusion that FQDN is really mandatory for NTP, I don't see why we should not retrofit this to all existing IP services Options. Honestly, I would like the DHCP veterans to come forward and tell us why they made so many bad decisions in the past :-; Benoit > -----Original Message----- > From: Mark Stapp (mjs)=20 > Sent: Wednesday, November 21, 2007 5:10 PM > To: David L. Mills > Cc: ntpwg@lists.ntp.org; dhcwg@ietf.org > Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)=20 > Options for DHCPv6 >=20 > yes, this is another reason why the DHCP folks have generally=20 > used addresses in options. it just removes a dependency among=20 > the various clients in the system, and it doesn't usually=20 > have any significant drawback. >=20 > there seems to be a concern that delivering addresses via=20 > DHCP somehow makes them difficult to update over time. just=20 > to reiterate: it's often the case that the information at the=20 > DHCP server is updated. the updated information flows out to=20 > clients as they renew. if the lease timers were very long, a=20 > client who got NTP addresses and found itself having trouble=20 > with them all could also use the INFORMATION-REQUEST message=20 > to check whether the addresses were still valid, outside of=20 > the normal renewal timers. >=20 > -- Mark >=20 > David L. Mills wrote: > > Brian, > >=20 > > Trying to put out fires when the network is burning is a good=20 > > excercise in fault containment. When the DNS is broken and=20 > the repair=20 > > party arrives, it's good to know the gateway works even if DNS=20 > > doesn't. I'm not sure this exactly applies to NTP, but I sure would=20 > > like to see the NTP servers options include hard coded addresses. > >=20 > > Dave > >=20 > > Brian Utterback wrote: > >=20 > >> > >> Danny Mayer wrote: > >> > >>> There is *no* avantage to not sending a FQDN and plenty of=20 > >>> disadvantages to not doing so. > >>> Would you like a list of vendors who have hardcoded IP addresses=20 > >>> into their devices without permission of the operator of that NTP=20 > >>> server causing headaches for not just the owner of the NTP Server=20 > >>> but also for the users of those devices? The NTP reference=20 > >>> implementation expects the existence of a resolver so you haven't=20 > >>> gained anything. > >>> > >> > >> As already noted, there is an advantage, namely that the=20 > client does=20 > >> not have to have a resolver. And even if the reference=20 > implementation=20 > >> requires one (Is that really true? Even if no name resolution is > >> required?) DHCP should remain implementation agnostic. > >> > >> As far the "hard coded address" problem goes, I don't see that=20 > >> scenario as very likely. DHCP clients don't tend to remain up for=20 > >> very long periods. And you don't have the same IP addresses being=20 > >> served by thousands of DHCP servers. The thing to be careful of is=20 > >> that the DHCP server not be embedded and replicated with=20 > hard coded=20 > >> addresses, not that the clients only get IP addresses. > >> > >> That having been said, I would like to see a way to pass a=20 > FQDN as an=20 > >> option, perhaps passing both. Then you could have logic=20 > like "Here's=20 > >> both, use the name if you can, and use the address if you must." > >> > >=20 > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 12:15:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhYD-0004nL-Ni; Mon, 26 Nov 2007 12:15:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhYC-0004jb-D5 for dhcwg@ietf.org; Mon, 26 Nov 2007 12:15:16 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwhY4-0004Nn-3C for dhcwg@ietf.org; Mon, 26 Nov 2007 12:15:16 -0500 Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 17:15:07 +0000 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 Subject: RE: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)Options for DHCPv6 Date: Mon, 26 Nov 2007 17:15:05 -0000 Message-ID: <548EC156325C6340B2E85DF90CAE85860199F7B0@E03MVB3-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)Options for DHCPv6 Thread-Index: AcgsWTKjavik0Bj5SHaEIj8EDwiasQD9VtSwAABJxFA= From: To: , , X-OriginalArrivalTime: 26 Nov 2007 17:15:07.0259 (UTC) FILETIME=[E46764B0:01C8304F] X-Spam-Score: -1.0 (-) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org That's not really a surprise. A box that is powering up, needs IP addresses as it may not be able to resolve DNS yet. However DHCP is not restricted to passing addresses. Tony=20 -----Original Message----- From: ntpwg-bounces+anthony.flavin=3Dbt.com@lists.ntp.org [mailto:ntpwg-bounces+anthony.flavin=3Dbt.com@lists.ntp.org] On Behalf = Of Benoit Lourdelet (blourdel) Sent: 26 November 2007 17:10 To: Mark Stapp (mjs); David L. Mills Cc: ntpwg@lists.ntp.org; dhcwg@ietf.org Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)Options for DHCPv6 Mark and David, If we consider the already defined DHCPv4 and DHCPv6 Options, IP services are, in (almost) all cases, passed as an address and not as a name. =20 If we come to the conclusion that FQDN is really mandatory for NTP, I don't see why we should not retrofit this to all existing IP services Options. Honestly, I would like the DHCP veterans to come forward and tell us why they made so many bad decisions in the past :-; Benoit > -----Original Message----- > From: Mark Stapp (mjs) > Sent: Wednesday, November 21, 2007 5:10 PM > To: David L. Mills > Cc: ntpwg@lists.ntp.org; dhcwg@ietf.org > Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options=20 > for DHCPv6 >=20 > yes, this is another reason why the DHCP folks have generally used=20 > addresses in options. it just removes a dependency among the various=20 > clients in the system, and it doesn't usually have any significant=20 > drawback. >=20 > there seems to be a concern that delivering addresses via DHCP somehow > makes them difficult to update over time. just to reiterate: it's=20 > often the case that the information at the DHCP server is updated. the > updated information flows out to clients as they renew. if the lease=20 > timers were very long, a client who got NTP addresses and found itself > having trouble with them all could also use the INFORMATION-REQUEST=20 > message to check whether the addresses were still valid, outside of=20 > the normal renewal timers. >=20 > -- Mark >=20 > David L. Mills wrote: > > Brian, > >=20 > > Trying to put out fires when the network is burning is a good=20 > > excercise in fault containment. When the DNS is broken and > the repair > > party arrives, it's good to know the gateway works even if DNS=20 > > doesn't. I'm not sure this exactly applies to NTP, but I sure would=20 > > like to see the NTP servers options include hard coded addresses. > >=20 > > Dave > >=20 > > Brian Utterback wrote: > >=20 > >> > >> Danny Mayer wrote: > >> > >>> There is *no* avantage to not sending a FQDN and plenty of=20 > >>> disadvantages to not doing so. > >>> Would you like a list of vendors who have hardcoded IP addresses=20 > >>> into their devices without permission of the operator of that NTP=20 > >>> server causing headaches for not just the owner of the NTP Server=20 > >>> but also for the users of those devices? The NTP reference=20 > >>> implementation expects the existence of a resolver so you haven't=20 > >>> gained anything. > >>> > >> > >> As already noted, there is an advantage, namely that the > client does > >> not have to have a resolver. And even if the reference > implementation > >> requires one (Is that really true? Even if no name resolution is > >> required?) DHCP should remain implementation agnostic. > >> > >> As far the "hard coded address" problem goes, I don't see that=20 > >> scenario as very likely. DHCP clients don't tend to remain up for=20 > >> very long periods. And you don't have the same IP addresses being=20 > >> served by thousands of DHCP servers. The thing to be careful of is=20 > >> that the DHCP server not be embedded and replicated with > hard coded > >> addresses, not that the clients only get IP addresses. > >> > >> That having been said, I would like to see a way to pass a > FQDN as an > >> option, perhaps passing both. Then you could have logic > like "Here's > >> both, use the name if you can, and use the address if you must." > >> > >=20 > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 13:28:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwihG-0004mS-WE; Mon, 26 Nov 2007 13:28:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwihF-0004mL-2x for dhcwg@ietf.org; Mon, 26 Nov 2007 13:28:41 -0500 Received: from [2001:4f8:3:bb:20c:76ff:fe16:4040] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwihE-0007nA-N7 for dhcwg@ietf.org; Mon, 26 Nov 2007 13:28:41 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id 93B8E5A6ED; Mon, 26 Nov 2007 10:28:40 -0800 (PST) Date: Mon, 26 Nov 2007 10:28:40 -0800 From: "David W. Hankins" To: DHC WG Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Message-ID: <20071126182840.GF24311@isc.org> References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <20071119225643.GI14750@isc.org> <47479E8B.2060107@ntp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47479E8B.2060107@ntp.org> User-Agent: Mutt/1.5.9i X-Spam-Score: -0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "ntpwg@lists.ntp.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Fri, Nov 23, 2007 at 10:46:19PM -0500, Danny Mayer wrote: > DNS is required for the pool configuration option. IP addresses are > strongly discouraged from the server configuration option for the same > reasons. The only time I can see allowing DHCP provided IP addresses is > if those addresses are link-local or site-local. That way we'd guarantee > that they were not going to bombard a remote NTP server with requests. In this case, you would have to make similar requirements of any IP addresses delivered via the intermediaries between the DHCP option and ntp.conf, or else you really haven't gotten that gurantee. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 13:42:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwiuQ-0004Bq-Q0; Mon, 26 Nov 2007 13:42:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwiuP-00049j-BL for dhcwg@ietf.org; Mon, 26 Nov 2007 13:42:17 -0500 Received: from [2001:4f8:3:bb:20c:76ff:fe16:4040] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwiuO-0008AK-DU for dhcwg@ietf.org; Mon, 26 Nov 2007 13:42:17 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id 945C25A6ED; Mon, 26 Nov 2007 10:42:16 -0800 (PST) Date: Mon, 26 Nov 2007 10:42:16 -0800 From: "David W. Hankins" To: DHC WG Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Message-ID: <20071126184216.GG24311@isc.org> References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <4741D057.4070703@ntp.org> <20071119232225.GJ14750@isc.org> <47479E84.8080309@ntp.org> Mime-Version: 1.0 In-Reply-To: <47479E84.8080309@ntp.org> User-Agent: Mutt/1.5.9i X-Spam-Score: -0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: "ntpwg@lists.ntp.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1093283977==" Errors-To: dhcwg-bounces@ietf.org --===============1093283977== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JgQwtEuHJzHdouWu" Content-Disposition: inline --JgQwtEuHJzHdouWu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 23, 2007 at 10:46:12PM -0500, Danny Mayer wrote: > That's currently the situation with the reference implementation of > ntpd. It gets its configuration information and doesn't go back. You can You can classify this as an ntpd problem, or a system integration problem. In the former, you might want to accept a HUP sometimes. In the latter, all the tools to restart the daemon are already available. Whichever one you choose, you'll still get the job done. If ntpd accepts HUPs, maybe you can optimize 'keeping your clock synched' across reconfiguration events. > now. So for the DHCP client to have an influence on what it uses for > servers it either needs to use ntpdc, send private mode 7 NTP packets, > restart ntpd, or have some sort of interface for ntpd to get updated > values from the DHCP client. The client itself has no need to do this. The operating system's configuration management system which accepts DHCP input needs to solve this problem. For ISC, we call this "dhclient-script", and although we package several examples with our software I know of no actual operating systems that use them...they all cook their own scripts that integrate with their configuration management. Still, it is trivial; if [ x$new_ntp_servers !=3D x$old_ntp_servers ] ; then rewrite_ntp_conf() rcntp force-reload fi > Well, if ntpd can poke the DHCP client for new values, presumably it can > request new values from the DHCP server to pass back to ntpd. That's not > even defined. Presently, all the poking is in the opposite direction. What I was referring to here is that there are Server->Client messages that can suggest the client needs to update its config, rather than wait for the usual lease renewal timer to expire. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --JgQwtEuHJzHdouWu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHSxOIcXeLeWu2vmoRApG6AKCjqmezhbh5+zXegIHF6ISdh6UvoQCfW3aR L1zFd7Ojr3Jnhooq9CUXLiM= =vRKP -----END PGP SIGNATURE----- --JgQwtEuHJzHdouWu-- --===============1093283977== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1093283977==-- From dhcwg-bounces@ietf.org Mon Nov 26 14:03:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjEg-0005qN-WA; Mon, 26 Nov 2007 14:03:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjEf-0005TE-DM for dhcwg@ietf.org; Mon, 26 Nov 2007 14:03:13 -0500 Received: from [2001:4f8:3:bb:20c:76ff:fe16:4040] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwjEe-0000Gx-ER for dhcwg@ietf.org; Mon, 26 Nov 2007 14:03:13 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id A6C365A6ED; Mon, 26 Nov 2007 11:03:12 -0800 (PST) Date: Mon, 26 Nov 2007 11:03:12 -0800 From: "David W. Hankins" To: DHC WG Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Message-ID: <20071126190312.GI24311@isc.org> References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> Mime-Version: 1.0 In-Reply-To: <474A521A.2090905@ntp.org> User-Agent: Mutt/1.5.9i X-Spam-Score: -0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ntpwg@lists.ntp.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0137237833==" Errors-To: dhcwg-bounces@ietf.org --===============0137237833== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XuV1QlJbYrcVoo+x" Content-Disposition: inline --XuV1QlJbYrcVoo+x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 25, 2007 at 11:56:58PM -0500, Danny Mayer wrote: > I refer you to the UWisc/Netgear incident paper that Dave Mills and Dave > Plonka wrote: > http://www.eecis.udel.edu/~mills/database/papers/ptti/ptti04a.pdf > The brief slide version is here: > http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.pdf > It also discusses the loads on a number of other servers inclusing NIST > and USNO >=20 > PHK's incident with D-Link is written up here: > http://news.bbc.co.uk/2/hi/technology/4906138.stm Yes, I thought this was a subtext of this discussion, and in my opinion is more important than any of the security subdiscussions. It is also good to have my facts straightened, I was going from memory before. > I await your suggestions on how to prevent the routers becoming > amplifiers via DHCP to bombarding NTP servers. I do not believe there is any reasonable way we can provide this with complete assuredness. It may appear that if you gave the DNS name via DHCP that the clock's administrator can now do clever things with DNS replies to ease the pain on the individual clocks. So mitigation tools may exist. However it also opens the doorway for a clock manufacturer to set the static value to a domain name they control - and deliver A records for other folks' clocks. You're screwed either way...in this case, you have some control over firmware that has not been upgraded. So my current recommendation is still to use binary IP addresses, and track Ralph Drom's existing draft (which covers both v4 and v6, I also stand corrected), in carefully explaining how a DHCP server supplying it is expected to come by the configuration values: Either manually supplied by the operator, or reflecting options gained upstream. No default values. It's my estimation that this is the best compromise between managing the risk of DDOS and scaling the DHCP protocol. But I believe that the NTP community is now very well versed in the concerns and facts surrounding this case, and I look forward to reading your draft - whatever it might say. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --XuV1QlJbYrcVoo+x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHSxhwcXeLeWu2vmoRApoPAJ0UT9e5pkmlkymCYrfqNTRz/hF8WACeNKoy MC7WZj6KO1cK4QnLosLoQjM= =4zlO -----END PGP SIGNATURE----- --XuV1QlJbYrcVoo+x-- --===============0137237833== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0137237833==-- From dhcwg-bounces@ietf.org Mon Nov 26 14:08:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjJi-0005FI-Ta; Mon, 26 Nov 2007 14:08:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjJh-0005F9-C8 for dhcwg@ietf.org; Mon, 26 Nov 2007 14:08:25 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwjJd-0000RU-NF for dhcwg@ietf.org; Mon, 26 Nov 2007 14:08:25 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 26 Nov 2007 14:08:22 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAQJ8LJb011413; Mon, 26 Nov 2007 14:08:21 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAQJ8Fxl029156; Mon, 26 Nov 2007 19:08:16 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 14:08:14 -0500 Received: from [161.44.65.124] ([161.44.65.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 14:08:14 -0500 Message-ID: <474B199E.3060700@cisco.com> Date: Mon, 26 Nov 2007 14:08:14 -0500 From: Mark Stapp User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Benoit Lourdelet (blourdel)" Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com><4743B902.3030406@udel.edu> <47445863.4000208@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2007 19:08:14.0154 (UTC) FILETIME=[B1B562A0:01C8305F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4932; t=1196104101; x=1196968101; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20[ntpwg]=20[dhcwg]=20Re=3A=20Network=20Time=20Protocol =20(NTP)=20Options=09for=09DHCPv6 |Sender:=20 |To:=20=22Benoit=20Lourdelet=20(blourdel)=22=20; bh=CtQbYVYMw8iTjckV8Az8D51cjf4xaX7fRNAcJLrd2hA=; b=Nfg9PkDiZu/4YH2ZHObMsefd1Tlxt0ygqrTSfwndde9aNd85ShRF7sExcv8aoTU8EMeOsocw gdQCaqc1+7L6tkvOHHpFJU7/qQD0EFA66q98rwZIqOjI9DQ8Qhiw+VVp; Authentication-Results: rtp-dkim-2; header.From=mjs@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "David L. Mills" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org making it possible to convey NTP servers in dhcpv6 doesn't seem to me to be any different than conveying them in dhcpv4 was. that was done something like ten years ago, and as far as I know that hasn't been a problem. I do wonder why some folks seem to think that using DNS names would somehow be "safer" than using v6 addresses. if someone shipped a server with a canned list of DNS names for NTP servers, there would be a problem until the owners of the NTP servers named moved them. I don't see how that'd be any better than the analogous mistake involving IP addresses. shipping a DHCP server with a canned configuration would not be good, so let's hope it doesn't happen. Mark Andrews's email seems to me to summarize what happens: 'home' routers have a dhcp client face and a dhcp server face, and use the client to populate the server. aside from the catastrophe hypothetical, is there any really strong reason - anything to do with the NTP protocol - that would prevent the use of ipv6 addresses? Thanks, Mark Benoit Lourdelet (blourdel) wrote: > Mark and David, > > If we consider the already defined DHCPv4 and DHCPv6 Options, IP > services are, in (almost) all cases, passed as an address and not as a > name. > If we come to the conclusion that FQDN is really mandatory for NTP, I > don't see why we should not retrofit this to all existing IP services > Options. > > Honestly, I would like the DHCP veterans to come forward and tell us why > they made so many bad decisions in the past :-; > > Benoit > >> -----Original Message----- >> From: Mark Stapp (mjs) >> Sent: Wednesday, November 21, 2007 5:10 PM >> To: David L. Mills >> Cc: ntpwg@lists.ntp.org; dhcwg@ietf.org >> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) >> Options for DHCPv6 >> >> yes, this is another reason why the DHCP folks have generally >> used addresses in options. it just removes a dependency among >> the various clients in the system, and it doesn't usually >> have any significant drawback. >> >> there seems to be a concern that delivering addresses via >> DHCP somehow makes them difficult to update over time. just >> to reiterate: it's often the case that the information at the >> DHCP server is updated. the updated information flows out to >> clients as they renew. if the lease timers were very long, a >> client who got NTP addresses and found itself having trouble >> with them all could also use the INFORMATION-REQUEST message >> to check whether the addresses were still valid, outside of >> the normal renewal timers. >> >> -- Mark >> >> David L. Mills wrote: >>> Brian, >>> >>> Trying to put out fires when the network is burning is a good >>> excercise in fault containment. When the DNS is broken and >> the repair >>> party arrives, it's good to know the gateway works even if DNS >>> doesn't. I'm not sure this exactly applies to NTP, but I sure would >>> like to see the NTP servers options include hard coded addresses. >>> >>> Dave >>> >>> Brian Utterback wrote: >>> >>>> Danny Mayer wrote: >>>> >>>>> There is *no* avantage to not sending a FQDN and plenty of >>>>> disadvantages to not doing so. >>>>> Would you like a list of vendors who have hardcoded IP addresses >>>>> into their devices without permission of the operator of that NTP >>>>> server causing headaches for not just the owner of the NTP Server >>>>> but also for the users of those devices? The NTP reference >>>>> implementation expects the existence of a resolver so you haven't >>>>> gained anything. >>>>> >>>> As already noted, there is an advantage, namely that the >> client does >>>> not have to have a resolver. And even if the reference >> implementation >>>> requires one (Is that really true? Even if no name resolution is >>>> required?) DHCP should remain implementation agnostic. >>>> >>>> As far the "hard coded address" problem goes, I don't see that >>>> scenario as very likely. DHCP clients don't tend to remain up for >>>> very long periods. And you don't have the same IP addresses being >>>> served by thousands of DHCP servers. The thing to be careful of is >>>> that the DHCP server not be embedded and replicated with >> hard coded >>>> addresses, not that the clients only get IP addresses. >>>> >>>> That having been said, I would like to see a way to pass a >> FQDN as an >>>> option, perhaps passing both. Then you could have logic >> like "Here's >>>> both, use the name if you can, and use the address if you must." >>>> >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dhcwg >>> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/dhcwg >> > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 14:14:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjPr-00010I-RH; Mon, 26 Nov 2007 14:14:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjPr-000108-1e for dhcwg@ietf.org; Mon, 26 Nov 2007 14:14:47 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwjPq-0002a7-H2 for dhcwg@ietf.org; Mon, 26 Nov 2007 14:14:46 -0500 Received: from [10.0.1.2] (cpe-67-9-133-15.austin.res.rr.com [67.9.133.15]) by toccata.fugue.com (Postfix) with ESMTP id 4DF56BC44C1; Mon, 26 Nov 2007 12:14:45 -0700 (MST) Message-Id: From: Ted Lemon To: "dhcwg@ietf.org WG" In-Reply-To: <474A521A.2090905@ntp.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Mon, 26 Nov 2007 13:14:44 -0600 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.3 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ntpwg@lists.ntp.org, TS Glassey , Mark Andrews , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > So let's say Acme Routers ships a router with a builtin DHCP server > which provides NTP server addresses to provide to the DHCP clients and > they put just one address in it. There simply is no defense against this. If a vendor of a broadly- distributed device does something stupid, someone gets shafted. You can write a requirement into the draft, and if they read it and follow it, that's really great, but my experience is that people skim drafts - they don't read them carefully. They read carefully when something breaks and they have to figure out what they did wrong, but for a case like this, it won't be obviously broken until there are millions of units in the field all providing the same information. So yes, by all means put a paragraph like this in the draft: DHCP servers MUST NOT contain a default or predefined value for the NTP option. DHCP servers MUST NOT send an NTP option unless a value has been explicitly configured by an administrator or end user. The best defense you have against people doing this is that the NTP mass murder problem has made the news a couple of times, and people have been sued over it. So a sensible vendor of SOHO equipment or cable modems is going to do the right thing, because they don't want to get sued. Furthermore, CableLabs has a process for doing conformance testing, so if you want to be really sure that this never happens again, you should work with them to add this to their requirements and their certification process. At that point, a device wouldn't be able to be certified if it did the wrong thing, and this would be a real and meaningful protection for you. But the main point that I keep making and that people keep ignoring is that this problem is not solved by using a domain name in place of an IP address. Using the domain name simply means that the place where the badness would occur is different. It's still a problem for the SOHO box or cable modem to be preconfigured with a name like "NTP.POMME.FR" - the only difference is that in that case not only will the NTP server at NTP.POMME.FR get slammed, but also the name server for NTP.POMME.FR will get slammed. So my point is that whether we use an IP address or a domain name, the same problem still occurs. So the fact that the problem exists can't be used as a justification for using one over the other. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 14:36:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwjkj-000247-Ht; Mon, 26 Nov 2007 14:36:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwjki-00023e-NV for dhcwg@ietf.org; Mon, 26 Nov 2007 14:36:20 -0500 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwjke-0001GP-I8 for dhcwg@ietf.org; Mon, 26 Nov 2007 14:36:20 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=DNeSBvB8ManoUl3fQHeVL+jTTykv6SI7LIcxwbXrOCBbwWtRMVjyNaxkI+MSyGr3; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Iwjkd-00013G-Il; Mon, 26 Nov 2007 14:36:15 -0500 Message-ID: <010901c83063$9bc23230$6401a8c0@tsg1> From: "TS Glassey" To: "Ted Lemon" , References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Mon, 26 Nov 2007 11:35:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79c45484a4dc70c5ef4a6527fd1556ee39350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ntpwg@lists.ntp.org, Mark Andrews , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ted if that is all you are doing here then lets also send this to the NEA people too... Todd ----- Original Message ----- From: "Ted Lemon" To: Cc: ; "Mark Andrews" ; "TS Glassey" ; "Richard Gayraud (rgayraud)" Sent: Monday, November 26, 2007 11:14 AM Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 >> So let's say Acme Routers ships a router with a builtin DHCP server >> which provides NTP server addresses to provide to the DHCP clients and >> they put just one address in it. > > There simply is no defense against this. If a vendor of a broadly- > distributed device does something stupid, someone gets shafted. > > You can write a requirement into the draft, and if they read it and > follow it, that's really great, but my experience is that people skim > drafts - they don't read them carefully. They read carefully when > something breaks and they have to figure out what they did wrong, but for > a case like this, it won't be obviously broken until there are millions > of units in the field all providing the same information. > > So yes, by all means put a paragraph like this in the draft: > > DHCP servers MUST NOT contain a default or predefined value for the NTP > option. DHCP servers MUST NOT send an NTP option unless a value has > been explicitly configured by an administrator or end user. > > The best defense you have against people doing this is that the NTP mass > murder problem has made the news a couple of times, and people have been > sued over it. So a sensible vendor of SOHO equipment or cable modems is > going to do the right thing, because they don't want to get sued. > > Furthermore, CableLabs has a process for doing conformance testing, so if > you want to be really sure that this never happens again, you should work > with them to add this to their requirements and their certification > process. At that point, a device wouldn't be able to be certified if it > did the wrong thing, and this would be a real and meaningful protection > for you. > > But the main point that I keep making and that people keep ignoring is > that this problem is not solved by using a domain name in place of an IP > address. Using the domain name simply means that the place where the > badness would occur is different. It's still a problem for the SOHO box > or cable modem to be preconfigured with a name like "NTP.POMME.FR" - the > only difference is that in that case not only will the NTP server at > NTP.POMME.FR get slammed, but also the name server for NTP.POMME.FR will > get slammed. > > So my point is that whether we use an IP address or a domain name, the > same problem still occurs. So the fact that the problem exists can't be > used as a justification for using one over the other. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 14:52:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwk0X-0004ot-6t; Mon, 26 Nov 2007 14:52:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwk0V-0004oZ-7G for dhcwg@ietf.org; Mon, 26 Nov 2007 14:52:39 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwk0S-0001dP-7p for dhcwg@ietf.org; Mon, 26 Nov 2007 14:52:39 -0500 Received: from [10.0.1.2] (cpe-67-9-133-15.austin.res.rr.com [67.9.133.15]) by toccata.fugue.com (Postfix) with ESMTP id 46EE91B8C001; Mon, 26 Nov 2007 12:52:35 -0700 (MST) Message-Id: From: Ted Lemon To: TS Glassey In-Reply-To: <010901c83063$9bc23230$6401a8c0@tsg1> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Mon, 26 Nov 2007 13:52:34 -0600 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> <010901c83063$9bc23230$6401a8c0@tsg1> X-Mailer: Apple Mail (2.915) X-Spam-Score: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , Mark Andrews , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 26, 2007, at 1:35 PM, TS Glassey wrote: > Ted if that is all you are doing here then lets also send this to > the NEA > people too... It would be really great if instead of shooting these offhand, cryptic comments out whenever I send you a thoughtful explanation of why I don't agree with what you want to do, you explain in clear, plain english why what I said didn't make sense to you, or what mistake I made in my thinking that means that what I said isn't correct. I'm sure these quips seem funny and enjoyable to you, but to me they're just so much nonsense. They certainly don't serve to advance your agenda, whatever it is. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 15:47:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwkrI-0005JR-IK; Mon, 26 Nov 2007 15:47:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwkrH-0005JG-7m for dhcwg@ietf.org; Mon, 26 Nov 2007 15:47:11 -0500 Received: from exchdev.pega.com ([198.22.153.35] helo=exchdev.rpega.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwkrG-0004fJ-Tl for dhcwg@ietf.org; Mon, 26 Nov 2007 15:47:11 -0500 Received: from [10.60.98.36] ([10.60.98.36]) by exchdev.rpega.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 15:47:04 -0500 Message-ID: <474B3023.2080303@ntp.org> Date: Mon, 26 Nov 2007 15:44:19 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ted Lemon Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 References: <200711260505.lAQ55V01028000@drugs.dv.isc.org> In-Reply-To: <200711260505.lAQ55V01028000@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2007 20:47:04.0658 (UTC) FILETIME=[80907B20:01C8306D] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Mark Andrews , "Richard Gayraud \(rgayraud\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I'd like to apologize to Ted over this and thank Mark for his input. I hadn't realized until Mark piped up with his response that these servers were getting all of their information from upstream and therefore there was always some sort of human at the end of the chain actively managing this in the SOHO routers. I hadn't wanted to get into the details of how DHCP servers worked but it was crucial for an understanding of the configuration mechanism. So I withdraw my objections to using IPv6 addresses in these options but I strongly recommend a sentence or two be added to the Security section to warn people about the amplifying effects of provisioning NTP server addresses to clients in this way and their potential for DDOS attacks. Danny Mark Andrews wrote: > Danny this really is a non-issue. > > A SOHO DHCP server side will learn its values from the > SOHO DHCP client side. SOHO DHCP servers do this today > for lots of values it returns to the SOHO network. > > Today you have a check box on SOHO routers that says > [ ] DNS servers learn from network. > If it is not checked you get a dialog to fill in. > > Tomorrow you will have a check box on SOHO routers that says > [ ] NTP servers learn from network. > If it's not checked you will get a dialog to fill in. > > Similarly IPv6 PD requests will chain through multiple DHCP > servers until you find one which will allocate the space requested. > > Mark _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 16:31:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlXh-0007MW-DE; Mon, 26 Nov 2007 16:31:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlXf-0007MH-VQ for dhcwg@ietf.org; Mon, 26 Nov 2007 16:30:59 -0500 Received: from whimsy.udel.edu ([128.4.2.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwlXc-0005sc-Q4 for dhcwg@ietf.org; Mon, 26 Nov 2007 16:30:59 -0500 Received: by whimsy.udel.edu (Postfix, from userid 62) id 04CB916A9; Mon, 26 Nov 2007 21:30:56 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id 7C136169B; Mon, 26 Nov 2007 21:30:52 +0000 (UTC) Message-ID: <474B3B0A.40608@udel.edu> Date: Mon, 26 Nov 2007 21:30:50 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: ntpwg@lists.ntp.org, dhcwg@ietf.org Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> In-Reply-To: <474A521A.2090905@ntp.org> X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Danny, There are two mitigating factors at work here, both mentioned in rfc4330. First, if the router hardcodes anything, use a DNS name, not an address. Second, any hardcoded name/address must point to a resource operated by the manufacturer or another site only with permission of the operator. Dave Danny Mayer wrote: > Ted, > > Let me try and outline the problem again and please come up with an idea > which solves this. > > 1) The DHCP environment is divided into essentially two groups: Hardware > like Netgear and Linksys routers and Software like ISC's DHCP Server and > Nominum's Dynamic Configuration Server. IETF doesn't allow you to create > a protocol which differentiate between these cases. > > The software side of the DHCP implementations are usually run by > organizations for their internal use and are actively maintained. I have > few worries about these since it's easy to deal with (relatively > speaking) errors that the sysadmins make. > > The SOHO routers are different since the DHCP servers are built into the > firmware and shipped in their 10's of thousands to individuals and small > businesses who want wireless connections and routers but don't want to > be in the business of configuring and maintaining them. > > So let's say Acme Routers ships a router with a builtin DHCP server > which provides NTP server addresses to provide to the DHCP clients and > they put just one address in it. Now say Starbucks gets all excited > about how cheap they are and buys them for all their coffee stores. Now > you have DHCP providing and amplication DDOS attack as all of those > people sitting there laptops are all set up with the same NTP server > address and sending NTP packets to the same NTP server. Note that in the > UWisc/Netgear incident it was the NTP server built into the router that > was the problem but it was only one server. Here we are having the > router distributing the address to other systems which then do the dirty > work and you'd get 10 times the effect of a Netgear incident. This is > the problem that I'm trying to solve or rather mitigate. > > I refer you to the UWisc/Netgear incident paper that Dave Mills and Dave > Plonka wrote: > http://www.eecis.udel.edu/~mills/database/papers/ptti/ptti04a.pdf > The brief slide version is here: > http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.pdf > It also discusses the loads on a number of other servers inclusing NIST > and USNO > > PHK's incident with D-Link is written up here: > http://news.bbc.co.uk/2/hi/technology/4906138.stm > > I await your suggestions on how to prevent the routers becoming > amplifiers via DHCP to bombarding NTP servers. > > Danny > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 16:41:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwlhi-0002Cg-Iw; Mon, 26 Nov 2007 16:41:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwlhh-0002CY-CT for dhcwg@ietf.org; Mon, 26 Nov 2007 16:41:21 -0500 Received: from whimsy.udel.edu ([128.4.2.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwlhe-0007bg-JW for dhcwg@ietf.org; Mon, 26 Nov 2007 16:41:21 -0500 Received: by whimsy.udel.edu (Postfix, from userid 62) id 2C30E16A9; Mon, 26 Nov 2007 21:41:18 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id AEF38169B; Mon, 26 Nov 2007 21:41:15 +0000 (UTC) Message-ID: <474B3D79.3060703@udel.edu> Date: Mon, 26 Nov 2007 21:41:13 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: ntpwg@lists.ntp.org, dhcwg@ietf.org Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <474A3939.4090202@ntp.org> In-Reply-To: <474A3939.4090202@ntp.org> X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Danny, FYI, in the current implementation it is possible to send configuration commands in file syntax from ntpq (mode 6). This is preferred as the commands and responses are in human readable ASCII. This is what prompted my suggestion that the DFCP NTP response could well be in the form or a preprogrammed mode-6 command and could be some other ASCII string if something other than current NTP is involved. Dave Danny Mayer wrote: > Ted Lemon wrote: > >> On Nov 25, 2007, at 6:09 PM, Mark Andrews wrote: >> >>> I would think that this should be a push operation from the dhcp >>> client rather than a pull operation. >> >> Sure, but it amounts to the same thing. This is trivial to do with >> the ISC DHCP client (which I presume is the one you use). It's also >> trivial to do on Linux with dbus. Mac OS X and Windows handle it >> differently still, but they already have mechanisms in place for doing >> this. So the point is that if the will exists to make it happen, >> it's trivial to make it happen. > > > It's trivial to send a private mode 7 NTP packet (along with an > appropriate password) to the reference implementation of ntpd telling it > to add or remove a server from its list of servers to use. As far as I > know only ntpdc does this currently and it's not a DHC client. > > Danny > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 26 22:03:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwqjb-00042q-My; Mon, 26 Nov 2007 22:03:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwqjZ-00042Q-E7 for dhcwg@ietf.org; Mon, 26 Nov 2007 22:03:37 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwqjY-0002rt-Q7 for dhcwg@ietf.org; Mon, 26 Nov 2007 22:03:37 -0500 Received: from epmmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JS5001N89TOD3@mailout3.samsung.com> for dhcwg@ietf.org; Tue, 27 Nov 2007 12:03:24 +0900 (KST) Received: from samsungcf414c4 ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JS500M4L9TP18@mmp2.samsung.com> for dhcwg@ietf.org; Tue, 27 Nov 2007 12:03:25 +0900 (KST) Date: Tue, 27 Nov 2007 12:03:07 +0900 From: Daniel Park In-reply-to: <6DCDA360-5BED-43C5-A5C3-030A7CF2EDC3@cisco.com> To: 'DHC WG' Message-id: <0JS500M4O9TP18@mmp2.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcgrxnNrbRz4driFSQKY7Mi9BLDi6QE2t8Fg X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [dhcwg] Q for draft-krishnan-dhc-ndc-option-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Just curious what happen if IPv6 Prefix Option and ND Prefix Information Option are in use at the same time ? > Neighbor Discovery Information over DHCP S. Krishnan 15 > minutes > > Initial discussion for consideration as WG work item Daniel Park [at] SAMSUNG Electronics _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 04:05:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwwNV-0003gh-7i; Tue, 27 Nov 2007 04:05:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwwNU-0003g4-1I for dhcwg@ietf.org; Tue, 27 Nov 2007 04:05:12 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwwNR-00008B-H6 for dhcwg@ietf.org; Tue, 27 Nov 2007 04:05:09 -0500 Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 09:05:08 +0000 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 Subject: RE: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Tue, 27 Nov 2007 09:05:05 -0000 Message-ID: <548EC156325C6340B2E85DF90CAE85860199F92F@E03MVB3-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Thread-Index: AcgwxlROjJgk+C+bSd6iFn+YYhixpwADeuzQ From: To: , X-OriginalArrivalTime: 27 Nov 2007 09:05:08.0044 (UTC) FILETIME=[9B84F0C0:01C830D4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: mayer@ntp.isc.org, ntpwg@lists.ntp.org, mellon@fugue.com, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Completely wrong. I can assure you that we do run our own NTP servers, and our customer routers are pre-configured with a Name not an IP address to get to them. We let our DNS servers sort out the load balancing issues (if we ever get any). It's working fine, and several hundred-thousand clients can't be wrong! =20 Tony Flavin -----Original Message----- From: Brad Knowles [mailto:brad@shub-internet.org]=20 Sent: 27 November 2007 07:01 To: Mark Andrews; Flavin,AJ,Tony,DMJ R Cc: mayer@ntp.isc.org; ntpwg@lists.ntp.org; mellon@fugue.com; rgayraud@cisco.com; dhcwg@ietf.org Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 On 11/26/07, Mark Andrews wrote: > ISP's will do similar things with NTP servers. They will point > the DHCP clients to their NTP servers. SOHO routeres will just > re advertise what they learnt. No, the ISPs don't work this way. I have yet to see many ISPs that have demonstrated any capacity or interest in setting up their own NTP server. If they use NTP at all, in almost all cases they rely on external NTP servers. It is these same external servers that they would plug into their DHCP servers (because they can't be bothered to run their own NTP servers), and which would then be passed on to the clients. Which leads us to the mess that Danny is trying to help prevent. > This is a non-issue. I'm not convinced of that. -- Brad Knowles LinkedIn Profile: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 08:21:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0Na-0002Eg-U4; Tue, 27 Nov 2007 08:21:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0NZ-0002ER-E2 for dhcwg@ietf.org; Tue, 27 Nov 2007 08:21:33 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix0NX-0000Hm-VL for dhcwg@ietf.org; Tue, 27 Nov 2007 08:21:33 -0500 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id lARDLUGj011892; Tue, 27 Nov 2007 07:21:30 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 07:21:30 -0600 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 07:21:30 -0600 Message-ID: <474C1A1C.7020404@ericsson.com> Date: Tue, 27 Nov 2007 08:22:36 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Daniel Park Subject: Re: [dhcwg] Q for draft-krishnan-dhc-ndc-option-00 References: <0JS500M4O9TP18@mmp2.samsung.com> In-Reply-To: <0JS500M4O9TP18@mmp2.samsung.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2007 13:21:30.0510 (UTC) FILETIME=[6C2EFAE0:01C830F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'DHC WG' X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi Daniel, I was also thinking a lot about this, and I could not find a satisfactory answer. This problem has always existed and needs to be fixed by administrative solutions. I think this is related to site policy and not for IETF to specify what to do. I was thinking about writing a draft that just specifies this issue (clash between info gleamed from stateless RA based methods and DHCP based methods) and advises admins to come up with a policy that specifies the precedence on client machines. Thanks Suresh Daniel Park wrote: > Just curious what happen if IPv6 Prefix Option and ND Prefix Information > Option are in use at the same time ? > > >> Neighbor Discovery Information over DHCP S. Krishnan 15 >> minutes >> >> Initial discussion for consideration as WG work item > > > > Daniel Park [at] SAMSUNG Electronics > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 08:55:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0u2-0008EW-F6; Tue, 27 Nov 2007 08:55:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0u1-0008BR-La for dhcwg@ietf.org; Tue, 27 Nov 2007 08:55:05 -0500 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix0u1-0005Jx-99 for dhcwg@ietf.org; Tue, 27 Nov 2007 08:55:05 -0500 Received: by py-out-1112.google.com with SMTP id d32so4049436pye for ; Tue, 27 Nov 2007 05:55:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ZxFY3WRB4QpSZSqx8Qw0KbDmk++IdXUjvsWw+DRy8Q8=; b=ww57BYzhlFxiDLBjjtfKuXwJnkh3EHr/zAfmF1NUA+dFtlw6qM8tVgasob7P+RfmTU/Dk+oEZKmN7R1Av+3YPbZOVut8eygVtTsQhnrrJH7+nfm2aDKryoAU2F0UKIXVV/ZGvcTn7IDSw7ueUAOtxOJ8CPoEeM5mC5A2Dk9mbWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ljGfr6cFGJTkHd5wPt/MZtvVax5sf9Gubqr9g//2ewcHjDxQ9f41fXz9BEdBNqBjwpREbv2YkuVZ2a7ylEZnKHzv05toExrSZXXUBizrGW8UI9S6mhnfBse+raC0FSvbjkTxpA+MudOFyooPEFtvrICnE2pEcuFWJz2gB65mgeA= Received: by 10.65.216.19 with SMTP id t19mr8737331qbq.1196171701777; Tue, 27 Nov 2007 05:55:01 -0800 (PST) Received: by 10.65.241.3 with HTTP; Tue, 27 Nov 2007 05:55:01 -0800 (PST) Message-ID: <1d38a3350711270555o2562bacdhc87b899c7ad897ce@mail.gmail.com> Date: Tue, 27 Nov 2007 21:55:01 +0800 From: "Hui Deng" To: "anthony.flavin@bt.com" Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 In-Reply-To: <548EC156325C6340B2E85DF90CAE85860199F92F@E03MVB3-UKBR.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <548EC156325C6340B2E85DF90CAE85860199F92F@E03MVB3-UKBR.domain1.systemhost.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Mark_Andrews@isc.org, mayer@ntp.isc.org, mellon@fugue.com, ntpwg@lists.ntp.org, brad@shub-internet.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > I can assure you that we do run our own NTP servers, and our customer > routers are pre-configured with a Name not an IP address to get to them. > We let our DNS servers sort out the load balancing issues (if we ever > get any). Yes, I would like to agree that DNS servers could do solve such kind of load balancing issue. -Hui > > It's working fine, and several hundred-thousand clients can't be wrong! > > Tony Flavin > > -----Original Message----- > From: Brad Knowles [mailto:brad@shub-internet.org] > Sent: 27 November 2007 07:01 > To: Mark Andrews; Flavin,AJ,Tony,DMJ R > Cc: mayer@ntp.isc.org; ntpwg@lists.ntp.org; mellon@fugue.com; > rgayraud@cisco.com; dhcwg@ietf.org > Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) > OptionsforDHCPv6 > > On 11/26/07, Mark Andrews wrote: > > > ISP's will do similar things with NTP servers. They will point > > the DHCP clients to their NTP servers. SOHO routeres will just > > re advertise what they learnt. > > No, the ISPs don't work this way. I have yet to see many ISPs that have > demonstrated any capacity or interest in setting up their own NTP > server. If they use NTP at all, in almost all cases they rely on > external NTP servers. It is these same external servers that they would > plug into their DHCP servers (because they can't be bothered to run > their own NTP servers), and which would then be passed on to the > clients. > > Which leads us to the mess that Danny is trying to help prevent. > > > This is a non-issue. > > I'm not convinced of that. > > -- > Brad Knowles > LinkedIn Profile: > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 08:55:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0uQ-00012K-50; Tue, 27 Nov 2007 08:55:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0uO-000109-At for dhcwg@ietf.org; Tue, 27 Nov 2007 08:55:28 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix0uN-0005PN-V5 for dhcwg@ietf.org; Tue, 27 Nov 2007 08:55:28 -0500 Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lARDtQEm003604; Tue, 27 Nov 2007 13:55:26 GMT Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lARDtPOr006517; Tue, 27 Nov 2007 08:55:26 -0500 (EST) Message-ID: <474C21CD.7060408@sun.com> Date: Tue, 27 Nov 2007 08:55:25 -0500 From: Brian Utterback User-Agent: Thunderbird 2.0.0.10pre (X11/20071125) MIME-Version: 1.0 To: Brad Knowles Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <4743B902.3030406@udel.edu> <47445863.4000208@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , Mark Stapp X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Brad Knowles wrote: > Which implies that the NTP client now needs to become fully DHCP aware. > Maybe. Maybe not. Simply make the requirement and let the implementation decide how to fulfill it. The reality is that the current reference implementation is pretty robust around restarting the daemon. If the kernel discipline is in use, the latest frequency correction will continue to be in effect even during the downtime. Simply have the DHCP subsystem create a new config file and restart. Or use the ntpq/ntpdc facility to let the DHCP subsystem do dynamic reconfiguration. Or use another interface between the two that is more suitable for the purpose (since the ntpq/ntpdc interface is somewhat fragile as an internal interface). Or make the ntpd daemon itself DHCP aware. There lots of possibilities. -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 09:03:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix12Y-00006T-Ga; Tue, 27 Nov 2007 09:03:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix12X-00006C-Ca for dhcwg@ietf.org; Tue, 27 Nov 2007 09:03:53 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix12W-00011t-Sj for dhcwg@ietf.org; Tue, 27 Nov 2007 09:03:53 -0500 Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lARE3o3J008380; Tue, 27 Nov 2007 14:03:50 GMT Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lARE3niK008704; Tue, 27 Nov 2007 09:03:50 -0500 (EST) Message-ID: <474C23C5.9030407@sun.com> Date: Tue, 27 Nov 2007 09:03:49 -0500 From: Brian Utterback User-Agent: Thunderbird 2.0.0.10pre (X11/20071125) MIME-Version: 1.0 To: anthony.flavin@bt.com Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 References: <548EC156325C6340B2E85DF90CAE85860199F92F@E03MVB3-UKBR.domain1.systemhost.net> In-Reply-To: <548EC156325C6340B2E85DF90CAE85860199F92F@E03MVB3-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Mark_Andrews@isc.org, mayer@ntp.isc.org, mellon@fugue.com, ntpwg@lists.ntp.org, brad@shub-internet.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Well, kudos to ISP's that do it right. My experience is that most of them are not nearly as responsible. None of the last three ISP's I have used at home (all in the U.S. top ten) even provided NTP servers, let alone served them up in DHCP options. Of course, none of the last 4 routers I used would have done anything with them if they had. anthony.flavin@bt.com wrote: > Completely wrong. > > I can assure you that we do run our own NTP servers, and our customer > routers are pre-configured with a Name not an IP address to get to them. > We let our DNS servers sort out the load balancing issues (if we ever > get any). > > It's working fine, and several hundred-thousand clients can't be wrong! > > Tony Flavin > > -----Original Message----- > From: Brad Knowles [mailto:brad@shub-internet.org] > Sent: 27 November 2007 07:01 > To: Mark Andrews; Flavin,AJ,Tony,DMJ R > Cc: mayer@ntp.isc.org; ntpwg@lists.ntp.org; mellon@fugue.com; > rgayraud@cisco.com; dhcwg@ietf.org > Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) > OptionsforDHCPv6 > > On 11/26/07, Mark Andrews wrote: > >> ISP's will do similar things with NTP servers. They will point >> the DHCP clients to their NTP servers. SOHO routeres will just >> re advertise what they learnt. > > No, the ISPs don't work this way. I have yet to see many ISPs that have > demonstrated any capacity or interest in setting up their own NTP > server. If they use NTP at all, in almost all cases they rely on > external NTP servers. It is these same external servers that they would > plug into their DHCP servers (because they can't be bothered to run > their own NTP servers), and which would then be passed on to the > clients. > > Which leads us to the mess that Danny is trying to help prevent. > >> This is a non-issue. > > I'm not convinced of that. > > -- > Brad Knowles > LinkedIn Profile: > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 09:07:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix15v-0003Gh-86; Tue, 27 Nov 2007 09:07:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix15u-0003F0-AT for dhcwg@ietf.org; Tue, 27 Nov 2007 09:07:22 -0500 Received: from exchdev.pega.com ([198.22.153.35] helo=exchdev.rpega.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix15t-0001YI-Pk for dhcwg@ietf.org; Tue, 27 Nov 2007 09:07:22 -0500 Received: from [10.60.98.36] ([10.60.98.36]) by exchdev.rpega.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 09:07:21 -0500 Message-ID: <474C23F2.9060301@ntp.org> Date: Tue, 27 Nov 2007 09:04:34 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "David W. Hankins" Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <4741D057.4070703@ntp.org> <20071119232225.GJ14750@isc.org> <47479E84.8080309@ntp.org> <20071126184216.GG24311@isc.org> In-Reply-To: <20071126184216.GG24311@isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2007 14:07:21.0183 (UTC) FILETIME=[D3B65EF0:01C830FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "ntpwg@lists.ntp.org" , DHC WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org David W. Hankins wrote: > On Fri, Nov 23, 2007 at 10:46:12PM -0500, Danny Mayer wrote: >> That's currently the situation with the reference implementation of >> ntpd. It gets its configuration information and doesn't go back. You can > > You can classify this as an ntpd problem, or a system integration > problem. > It's an ntpd problem though we have several methods of updating the server using ntpdc and ntpq. > In the former, you might want to accept a HUP sometimes. In the > latter, all the tools to restart the daemon are already available. > > Whichever one you choose, you'll still get the job done. If ntpd > accepts HUPs, maybe you can optimize 'keeping your clock synched' > across reconfiguration events. > We really do *not* want to use HUP since that causes a restart and that's a bad idea for ntpd which is designed to be long-running. It frequently takes several hours for it to settle now into a stable state and disciplining the clock. A HUP would disrupt this. Rereading the configuration file is not straightforward either as you could well be changing its operational behavior and not just changing server settings. For what you are talking about with the DHCP provided NTP server addresses you really only need something like ntpdc -c "add server ..." comands. >> now. So for the DHCP client to have an influence on what it uses for >> servers it either needs to use ntpdc, send private mode 7 NTP packets, >> restart ntpd, or have some sort of interface for ntpd to get updated >> values from the DHCP client. > > The client itself has no need to do this. The operating system's > configuration management system which accepts DHCP input needs to > solve this problem. Sorry, that's what I meant. > For ISC, we call this "dhclient-script", and although we package > several examples with our software I know of no actual operating > systems that use them...they all cook their own scripts that > integrate with their configuration management. > > Still, it is trivial; > > if [ x$new_ntp_servers != x$old_ntp_servers ] ; then > rewrite_ntp_conf() > rcntp force-reload > fi > >> Well, if ntpd can poke the DHCP client for new values, presumably it can >> request new values from the DHCP server to pass back to ntpd. That's not >> even defined. > > Presently, all the poking is in the opposite direction. What I was > referring to here is that there are Server->Client messages that can > suggest the client needs to update its config, rather than wait for > the usual lease renewal timer to expire. If the address provided by DHCP is not providing NTP service ntpd will drop it. So in this case it has no recourse. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 09:14:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1CM-00083q-9K; Tue, 27 Nov 2007 09:14:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1CL-00083j-RE for dhcwg@ietf.org; Tue, 27 Nov 2007 09:14:01 -0500 Received: from exchdev.pega.com ([198.22.153.35] helo=exchdev.rpega.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix1CL-0002eD-I9 for dhcwg@ietf.org; Tue, 27 Nov 2007 09:14:01 -0500 Received: from [10.60.98.36] ([10.60.98.36]) by exchdev.rpega.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 09:14:01 -0500 Message-ID: <474C2582.8090804@ntp.org> Date: Tue, 27 Nov 2007 09:11:14 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "David W. Hankins" Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> <20071126190312.GI24311@isc.org> In-Reply-To: <20071126190312.GI24311@isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2007 14:14:01.0058 (UTC) FILETIME=[C20E7420:01C830FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ntpwg@lists.ntp.org, DHC WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org David W. Hankins wrote: > I do not believe there is any reasonable way we can provide this > with complete assuredness. > > It may appear that if you gave the DNS name via DHCP that the clock's > administrator can now do clever things with DNS replies to ease the > pain on the individual clocks. So mitigation tools may exist. > > However it also opens the doorway for a clock manufacturer to set > the static value to a domain name they control - and deliver A records > for other folks' clocks. > With the pool config option you can now point to the pool (pool.ntp.org) and each time you make a query you will get a different list of addresses to use. The pool also is grouped into areas and countries and provides a much better loading on the NTP servers in the list. ntpd will configure up to 10 of these addresses to use. > You're screwed either way...in this case, you have some control over > firmware that has not been upgraded. > We prefer the pool. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 09:21:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1Jf-0007y0-Bi; Tue, 27 Nov 2007 09:21:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1Je-0007xJ-Ml for dhcwg@ietf.org; Tue, 27 Nov 2007 09:21:34 -0500 Received: from exchdev.pega.com ([198.22.153.35] helo=exchdev.rpega.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix1Je-0004St-Cz for dhcwg@ietf.org; Tue, 27 Nov 2007 09:21:34 -0500 Received: from [10.60.98.36] ([10.60.98.36]) by exchdev.rpega.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 09:21:33 -0500 Message-ID: <474C2747.6000300@ntp.org> Date: Tue, 27 Nov 2007 09:18:47 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mark Stapp Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com><4743B902.3030406@udel.edu> <47445863.4000208@cisco.com> <474B199E.3060700@cisco.com> In-Reply-To: <474B199E.3060700@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2007 14:21:33.0871 (UTC) FILETIME=[CFF43BF0:01C83100] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "David L. Mills" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Mark Stapp wrote: > > making it possible to convey NTP servers in dhcpv6 doesn't seem to me to > be any different than conveying them in dhcpv4 was. that was done > something like ten years ago, and as far as I know that hasn't been a > problem. > > I do wonder why some folks seem to think that using DNS names would > somehow be "safer" than using v6 addresses. if someone shipped a server > with a canned list of DNS names for NTP servers, there would be a > problem until the owners of the NTP servers named moved them. I don't > see how that'd be any better than the analogous mistake involving IP > addresses. > Because with the pool you are likely to get a different list of addresses every time you ask (modulo caching DNS Servers of course). > shipping a DHCP server with a canned configuration would not be good, so > let's hope it doesn't happen. Mark Andrews's email seems to me to > summarize what happens: 'home' routers have a dhcp client face and a > dhcp server face, and use the client to populate the server. > > aside from the catastrophe hypothetical, is there any really strong > reason - anything to do with the NTP protocol - that would prevent the > use of ipv6 addresses? > ntpd fully supports IPv4 and IPv6 addresses. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 12:42:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4SI-0006Zn-Mm; Tue, 27 Nov 2007 12:42:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4SG-0006ZQ-SQ; Tue, 27 Nov 2007 12:42:40 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix4SG-0000vR-I0; Tue, 27 Nov 2007 12:42:40 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 27 Nov 2007 12:42:39 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lARHgeeZ010139; Tue, 27 Nov 2007 12:42:40 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lARHgCBs011740; Tue, 27 Nov 2007 17:42:31 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 12:42:16 -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 Subject: RE: [dhcwg] Q for draft-krishnan-dhc-ndc-option-00 Date: Tue, 27 Nov 2007 12:44:08 -0500 Message-ID: In-reply-to: <0JS500M4O9TP18@mmp2.samsung.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Q for draft-krishnan-dhc-ndc-option-00 Thread-Index: AcgrxnNrbRz4driFSQKY7Mi9BLDi6QE2t8FgAB7JReA= From: "Wes Beebee (wbeebee)" To: "Daniel Park" , "DHC WG" X-OriginalArrivalTime: 27 Nov 2007 17:42:16.0760 (UTC) FILETIME=[DA134380:01C8311C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=956; t=1196185360; x=1197049360; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Q=20for=20draft-krishnan-dhc-ndc-option-00 |Sender:=20 |To:=20=22Daniel=20Park=22=20, =20=22DHC=20WG=22 =20; bh=wWOwrdLxETdiWZztTPuXFvLdsfbGqVZ3aBeu608cFVw=; b=LJFwdEJgKebIzCka0SVeqHiEEm9/kWRswjC/SUa/gc8sDmBGO+hD4MNJP0ObyIJdEriu+YJg i4E34pPE8fxzDCxpIghh8aJVn8mgdox1ecE17WzTGl+RLupm/rm8JUOd; Authentication-Results: rtp-dkim-2; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipv6@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org If we're now going to make major changes to the core of IPv6 and combine ND and=20 DHCP at this late hour, then it would probably be a good idea to involve all the stakeholders in this decision - so I'm widening the audience to the IPv6 ND team for comment. - Wes -----Original Message----- From: Daniel Park [mailto:soohong.park@samsung.com]=20 Sent: Monday, November 26, 2007 10:03 PM To: 'DHC WG' Subject: [dhcwg] Q for draft-krishnan-dhc-ndc-option-00 Just curious what happen if IPv6 Prefix Option and ND Prefix Information Option are in use at the same time ? > Neighbor Discovery Information over DHCP S. Krishnan 15 =20 > minutes > > Initial discussion for consideration as WG work item Daniel Park [at] SAMSUNG Electronics _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 12:49:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4ZB-0002Ps-E7; Tue, 27 Nov 2007 12:49:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4Z9-0002Oi-FG; Tue, 27 Nov 2007 12:49:47 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix4Z9-0002bE-2F; Tue, 27 Nov 2007 12:49:47 -0500 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id lARHnjKn013087; Tue, 27 Nov 2007 11:49:45 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 11:49:45 -0600 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 11:49:44 -0600 Message-ID: <474C58FB.5030706@ericsson.com> Date: Tue, 27 Nov 2007 12:50:51 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "Wes Beebee (wbeebee)" Subject: Re: [dhcwg] Q for draft-krishnan-dhc-ndc-option-00 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2007 17:49:44.0826 (UTC) FILETIME=[E524B5A0:01C8311D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: DHC WG , ipv6@ietf.org, Daniel Park X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi Wes, I just want to clarify something. I am not trying to combine ND and DHCP. I am just trying to eliminate redundant standardization of the same info in two ways and redundant client implementations to process these. Thanks Suresh Wes Beebee (wbeebee) wrote: > If we're now going to make major changes to the core of IPv6 and combine > ND and > DHCP at this late hour, then it would probably be a good idea to involve > all the > stakeholders in this decision - so I'm widening the audience to the IPv6 > ND team > for comment. > > - Wes > > -----Original Message----- > From: Daniel Park [mailto:soohong.park@samsung.com] > Sent: Monday, November 26, 2007 10:03 PM > To: 'DHC WG' > Subject: [dhcwg] Q for draft-krishnan-dhc-ndc-option-00 > > Just curious what happen if IPv6 Prefix Option and ND Prefix Information > Option are in use at the same time ? > > >> Neighbor Discovery Information over DHCP S. Krishnan 15 >> minutes >> >> Initial discussion for consideration as WG work item > > > > Daniel Park [at] SAMSUNG Electronics > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 12:54:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4e4-0001vE-JT; Tue, 27 Nov 2007 12:54:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4e3-0001v1-J2 for dhcwg@ietf.org; Tue, 27 Nov 2007 12:54:51 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix4e3-0006Cu-7W for dhcwg@ietf.org; Tue, 27 Nov 2007 12:54:51 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Nov 2007 12:54:40 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lARHseoQ024945; Tue, 27 Nov 2007 12:54:40 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lARHsK1E014080; Tue, 27 Nov 2007 17:54:40 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 12:54:31 -0500 Received: from [161.44.65.201] ([161.44.65.201]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 12:54:31 -0500 Message-Id: <4EEE6EF0-CE54-4A2C-B0E5-54A6EDEABB3B@cisco.com> From: Ralph Droms To: Wes Beebee (wbeebee) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [dhcwg] Q for draft-krishnan-dhc-ndc-option-00 Date: Tue, 27 Nov 2007 12:54:35 -0500 References: X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 27 Nov 2007 17:54:31.0462 (UTC) FILETIME=[8FFDE460:01C8311E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1488; t=1196186080; x=1197050080; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20Q=20for=20draft-krishnan-dhc-ndc-option-00 |Sender:=20 |To:=20Wes=20Beebee=20(wbeebee)=20; bh=dwg683COPLoAf7+G/dd6vf6zttYGqofHqmSAesuyVic=; b=DasbGqQoxCp/HtVWfHJmj62G2LUHXwGUucd2BjWieJUxohmFw+o7rja/Pb00O3Hgk+22PshU +NcJU61eQDFKsqurxR8loWHvJzHuZy3efEc2WVFFk5hmRGxXvYPZUuC+; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: DHC WG , Venaas Stig X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Wes - Stig and I are aware of the broader scope of this discussion and have been in touch with the Internet ADs to make sure this draft and the related draft draft-krishnan-intarea-ra-dhcp-00 are discussed as Internet Area topics. - Ralph On Nov 27, 2007, at Nov 27, 2007,12:44 PM, Wes Beebee (wbeebee) wrote: > If we're now going to make major changes to the core of IPv6 and > combine > ND and > DHCP at this late hour, then it would probably be a good idea to > involve > all the > stakeholders in this decision - so I'm widening the audience to the > IPv6 > ND team > for comment. > > - Wes > > -----Original Message----- > From: Daniel Park [mailto:soohong.park@samsung.com] > Sent: Monday, November 26, 2007 10:03 PM > To: 'DHC WG' > Subject: [dhcwg] Q for draft-krishnan-dhc-ndc-option-00 > > Just curious what happen if IPv6 Prefix Option and ND Prefix > Information > Option are in use at the same time ? > > >> Neighbor Discovery Information over DHCP S. Krishnan 15 >> minutes >> >> Initial discussion for consideration as WG work item > > > > Daniel Park [at] SAMSUNG Electronics > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 13:19:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix51n-0000Iq-4Q; Tue, 27 Nov 2007 13:19:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix51m-0000Ii-77 for dhcwg@ietf.org; Tue, 27 Nov 2007 13:19:22 -0500 Received: from exchdev.pega.com ([198.22.153.35] helo=exchdev.rpega.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix51j-0000Ty-7U for dhcwg@ietf.org; Tue, 27 Nov 2007 13:19:22 -0500 Received: from [10.60.98.36] ([10.60.98.36]) by exchdev.rpega.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 13:19:18 -0500 Message-ID: <474C5EFF.8050100@ntp.org> Date: Tue, 27 Nov 2007 13:16:31 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mark Stapp Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com><4743B902.3030406@udel.edu> <47445863.4000208@cisco.com> <474B199E.3060700@cisco.com> In-Reply-To: <474B199E.3060700@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2007 18:19:18.0598 (UTC) FILETIME=[0664D660:01C83122] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Mark Stapp wrote: > making it possible to convey NTP servers in dhcpv6 doesn't seem to me to > be any different than conveying them in dhcpv4 was. that was done > something like ten years ago, and as far as I know that hasn't been a > problem. > > I do wonder why some folks seem to think that using DNS names would > somehow be "safer" than using v6 addresses. if someone shipped a server > with a canned list of DNS names for NTP servers, there would be a > problem until the owners of the NTP servers named moved them. I don't > see how that'd be any better than the analogous mistake involving IP > addresses. > Mark, Slipping on my DNS hat for a moment, the whole point of DNS is that you don't have to hardcode IP addresses in everything. You also benefit by being able to put more than one IP address for the same name. It's safer because the admin of the server doesn't have to worry when he moves a service from on server to another. All he/she has to do is update the DNS and not notify 1 million or so people that it's been moved. Can you imagine moving a web server without it? > shipping a DHCP server with a canned configuration would not be good, so > let's hope it doesn't happen. Mark Andrews's email seems to me to > summarize what happens: 'home' routers have a dhcp client face and a > dhcp server face, and use the client to populate the server. > > aside from the catastrophe hypothetical, is there any really strong > reason - anything to do with the NTP protocol - that would prevent the > use of ipv6 addresses? > It does use IPv6 addresses when it's presented with one. Now what happens if that address is not running an NTP server? With DNS you can get more than one address back and try another address or requery the DNS to see if the address changed. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 14:22:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix60e-00071P-IL; Tue, 27 Nov 2007 14:22:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix60d-000712-VR for dhcwg@ietf.org; Tue, 27 Nov 2007 14:22:15 -0500 Received: from [2001:4f8:3:bb:20c:76ff:fe16:4040] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix60d-0007ju-Hh for dhcwg@ietf.org; Tue, 27 Nov 2007 14:22:15 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id 6EA867E03; Tue, 27 Nov 2007 11:22:15 -0800 (PST) Date: Tue, 27 Nov 2007 11:22:15 -0800 From: "David W. Hankins" To: DHC WG Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Message-ID: <20071127192215.GC30466@isc.org> References: <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <4741D057.4070703@ntp.org> <20071119232225.GJ14750@isc.org> <47479E84.8080309@ntp.org> <20071126184216.GG24311@isc.org> <474C23F2.9060301@ntp.org> Mime-Version: 1.0 In-Reply-To: <474C23F2.9060301@ntp.org> User-Agent: Mutt/1.5.9i X-Spam-Score: -0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "ntpwg@lists.ntp.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1521792261==" Errors-To: dhcwg-bounces@ietf.org --===============1521792261== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9Ek0hoCL9XbhcSqy" Content-Disposition: inline --9Ek0hoCL9XbhcSqy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 27, 2007 at 09:04:34AM -0500, Danny Mayer wrote: > If the address provided by DHCP is not providing NTP service ntpd will > drop it. So in this case it has no recourse. That's correct; there is no recourse and in DHCP's philosphy there shouldn't be. DHCP delivers a configuration state with an expiration time and renewal time. If that configuration is incorrect or flawed or unusable at some point in its advertised lifetime (as set by the operator of the DHCP server), it isn't a problem that can be solved by going back to the well; the configuration is likely to have not changed. Going back to the well without some indication (the reconfigure extensions) just creates useless traffic. The theory is that DHCP server operators use lease lifetimes as a tool for limiting stale configuration and for scheduling outages and configuration changes (reducing the lease lifetimes as changeovers approach). I have a vague feeling that you've found the way to express a need for this DHCP option to be configured via DNS names. As I stated before, I reserve any judgement until there's a draft. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --9Ek0hoCL9XbhcSqy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHTG5ncXeLeWu2vmoRAqwBAJ4xlA3AZwHXxJCKKIOzOao5Rq2KqQCfaLLO /ce1WCOoPtp0wm+63IyByzs= =3yJd -----END PGP SIGNATURE----- --9Ek0hoCL9XbhcSqy-- --===============1521792261== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1521792261==-- From dhcwg-bounces@ietf.org Tue Nov 27 14:39:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6HC-0003Tf-4V; Tue, 27 Nov 2007 14:39:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6HA-0003TJ-TP for dhcwg@ietf.org; Tue, 27 Nov 2007 14:39:20 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix6H9-0001IX-4U for dhcwg@ietf.org; Tue, 27 Nov 2007 14:39:20 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 27 Nov 2007 14:39:19 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lARJdIUY009249; Tue, 27 Nov 2007 14:39:18 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lARJd80i025990; Tue, 27 Nov 2007 19:39:13 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 14:39:08 -0500 Received: from [161.44.65.124] ([161.44.65.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 14:39:07 -0500 Message-ID: <474C725B.2050006@cisco.com> Date: Tue, 27 Nov 2007 14:39:07 -0500 From: Mark Stapp User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Danny Mayer Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com><4743B902.3030406@udel.edu> <47445863.4000208@cisco.com> <474B199E.3060700@cisco.com> <474C5EFF.8050100@ntp.org> In-Reply-To: <474C5EFF.8050100@ntp.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2007 19:39:08.0030 (UTC) FILETIME=[2D1E29E0:01C8312D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3017; t=1196192358; x=1197056358; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20[ntpwg]=20[dhcwg]=20Re=3A=20Network=20Time=20Protocol =20(NTP)=09Options=09for=09DHCPv6 |Sender:=20 |To:=20Danny=20Mayer=20; bh=LTuH+y7JrYFTqLUQhhVItSWMg6nCPWld64zwbUHju9I=; b=NnKYf8wxGmUBm3braMAVsjgtMhmnOiH84eixoHXjFnZ8+XKge5vQQSrM7IKtOuSYB0CY1XyY OuNhdApnrL3IfyQP6o654ldcJie2bgGXtqFzHhevjZJHEdZyJCuzU3nT; Authentication-Results: rtp-dkim-2; header.From=mjs@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org yes, I think I understand the issue. it's certainly ok to have an option payload that uses DNS names if that's what the service needs to use. I was only trying to clarify whether it was possible to use addresses or not, since it's only possible to use addresses in the dhcpv4 form of the option. maybe what's happening is that the dhcp folks are hearing: "well, yes, the dhcpv4 option used addresses, but that's not really being used in the real world much, so let's not do the v6 option that way." if that's what's happening, it's certainly possible to develop an option format using DNS names. are there circumstances where addresses would be preferred or necessary, or would DNS names _always_ be useable? my intuition is that there are probably some cases where it might be necessary to supply addresses, so it might be safest to develop an encoding that permits both. we have examples of things like that: the SIP servers option (RFC3361) allows a list of _either_ addresses or names, and the use of suboptions would allow mixed lists. -- Mark Danny Mayer wrote: > Mark Stapp wrote: >> making it possible to convey NTP servers in dhcpv6 doesn't seem to me to >> be any different than conveying them in dhcpv4 was. that was done >> something like ten years ago, and as far as I know that hasn't been a >> problem. >> >> I do wonder why some folks seem to think that using DNS names would >> somehow be "safer" than using v6 addresses. if someone shipped a server >> with a canned list of DNS names for NTP servers, there would be a >> problem until the owners of the NTP servers named moved them. I don't >> see how that'd be any better than the analogous mistake involving IP >> addresses. >> > > Mark, > > Slipping on my DNS hat for a moment, the whole point of DNS is that you > don't have to hardcode IP addresses in everything. You also benefit by > being able to put more than one IP address for the same name. It's safer > because the admin of the server doesn't have to worry when he moves a > service from on server to another. All he/she has to do is update the > DNS and not notify 1 million or so people that it's been moved. Can you > imagine moving a web server without it? > >> shipping a DHCP server with a canned configuration would not be good, so >> let's hope it doesn't happen. Mark Andrews's email seems to me to >> summarize what happens: 'home' routers have a dhcp client face and a >> dhcp server face, and use the client to populate the server. >> >> aside from the catastrophe hypothetical, is there any really strong >> reason - anything to do with the NTP protocol - that would prevent the >> use of ipv6 addresses? >> > > It does use IPv6 addresses when it's presented with one. Now what > happens if that address is not running an NTP server? With DNS you can > get more than one address back and try another address or requery the > DNS to see if the address changed. > > Danny > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 15:57:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7UE-0005nn-Hv; Tue, 27 Nov 2007 15:56:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7UC-0005li-Ts for dhcwg@ietf.org; Tue, 27 Nov 2007 15:56:53 -0500 Received: from exprod7og104.obsmtp.com ([64.18.2.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix7UC-0000uT-Dn for dhcwg@ietf.org; Tue, 27 Nov 2007 15:56:52 -0500 Received: from source ([81.200.64.181]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Tue, 27 Nov 2007 12:56:49 PST Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 302A05689A; Tue, 27 Nov 2007 12:21:22 -0800 (PST) (envelope-from mellon@nominum.com) X-Spam-Status: No, hits=0.0 required=8.4 tests=CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: 0.000 X-Spam-Level: Received: from [10.71.0.243] ([12.4.29.2]) (authenticated user mellon@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 27 Nov 2007 12:21:21 -0800 Message-Id: From: Ted Lemon To: David W. Hankins In-Reply-To: <20071127192215.GC30466@isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6 Date: Tue, 27 Nov 2007 15:21:20 -0500 References: <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <4741D057.4070703@ntp.org> <20071119232225.GJ14750@isc.org> <47479E84.8080309@ntp.org> <20071126184216.GG24311@isc.org> <474C23F2.9060301@ntp.org> <20071127192215.GC30466@isc.org> X-Mailer: Apple Mail (2.915) X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "ntpwg@lists.ntp.org" , DHC WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 27, 2007, at 2:22 PM, David W. Hankins wrote: >> If the address provided by DHCP is not providing NTP service ntpd >> will >> drop it. So in this case it has no recourse. > > That's correct; there is no recourse and in DHCP's philosphy there > shouldn't be. Just to be clear, most DHCP options provide lists of IP addresses, not single IP addresses, so it amounts to the same thing. Indeed, in every server of which I am aware, if you configure the DHCP server with a domain name that resolves to multiple IP addresses, and the option so configured supports multiple IP addresses, then the DHCP server sends each IP address. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 16:00:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7Xm-0002lP-7N; Tue, 27 Nov 2007 16:00:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7Xk-0002l2-NW for dhcwg@ietf.org; Tue, 27 Nov 2007 16:00:32 -0500 Received: from whimsy.udel.edu ([128.4.2.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix7Xj-0001y5-Li for dhcwg@ietf.org; Tue, 27 Nov 2007 16:00:32 -0500 Received: by whimsy.udel.edu (Postfix, from userid 62) id C422216D4; Tue, 27 Nov 2007 21:00:20 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id CE0BD166C; Tue, 27 Nov 2007 21:00:17 +0000 (UTC) Message-ID: <474C855F.6080609@udel.edu> Date: Tue, 27 Nov 2007 21:00:15 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: "dhcwg@ietf.org WG" , ntpwg@lists.ntp.org Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> In-Reply-To: X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Brad, The advice to use DNS which is in the RFC and web lists is so folks can change the NT server IP address from time to time and update the DNS accordingly. If the DHCP server followed that advice, it would occasionally re-resolve the name and pass the new IP address to its clients. It is not at all clear that this advice is followed in the real world. Dave Brad Knowles wrote: > On 11/26/07, Ted Lemon wrote: > >> But the main point that I keep making and that people keep ignoring is >> that this problem is not solved by using a domain name in place of an >> IP address. Using the domain name simply means that the place where >> the badness would occur is different. It's still a problem for the >> SOHO box or cable modem to be preconfigured with a name like >> "NTP.POMME.FR" - the only difference is that in that case not only >> will the NTP server at NTP.POMME.FR get slammed, but also the name >> server for NTP.POMME.FR will get slammed. > > > Not true. The NS and A records for NTP.POMME.FR will presumably have > a lifetime that is measured in hundreds, thousands, tens of > thousands, or maybe even hundreds of thousands of seconds, and they > will be cached on the remote end. > > However, each and every one of those hundreds of thousands or > millions of misconfigured NTP clients will be pounding the > NTP.POMME.FR machine once every sixty seconds or so, unless they've > managed to back off to just pounding it ever thousand seconds or so. > If they're misconfigured, or the machine is not responding, they may > pound it every second -- or maybe many hundreds of times per second. > > There's a huge difference here. Like, orders of magnitude. Possibly > many orders of magnitude. > >> So my point is that whether we use an IP address or a domain name, the >> same problem still occurs. So the fact that the problem exists can't >> be used as a justification for using one over the other. > > > The difference is that once an IP address is given out, it can't be > changed to point somewhere else. > > Once a name is given out, it can always be changed to point to a > different IP address. The current reference implementation would not > re-resolve that name into the new IP address, but at least all > new(er) instances would catch the new IP address, and life would be > able to continue. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 18:09:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9Ys-0005JK-Om; Tue, 27 Nov 2007 18:09:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9Yq-0005EY-PX for dhcwg@ietf.org; Tue, 27 Nov 2007 18:09:49 -0500 Received: from exprod7og103.obsmtp.com ([64.18.2.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix9Yp-0002lW-Rj for dhcwg@ietf.org; Tue, 27 Nov 2007 18:09:48 -0500 Received: from source ([81.200.64.181]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Tue, 27 Nov 2007 15:09:42 PST Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id EAA8A56884; Tue, 27 Nov 2007 15:09:41 -0800 (PST) (envelope-from mellon@nominum.com) X-Spam-Status: No, hits=0.0 required=8.4 tests=CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: 0.000 X-Spam-Level: Received: from [10.71.0.243] ([12.4.29.2]) (authenticated user mellon@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 27 Nov 2007 15:09:40 -0800 Message-Id: From: Ted Lemon To: David L. Mills In-Reply-To: <474C855F.6080609@udel.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Tue, 27 Nov 2007 18:09:40 -0500 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> <474C855F.6080609@udel.edu> X-Mailer: Apple Mail (2.915) X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org WG" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 27, 2007, at 4:00 PM, David L. Mills wrote: > If the DHCP server followed that advice, it would > occasionally re-resolve the name and pass the new IP address to its > clients. It is not at all clear that this advice is followed in the > real > world. It is followed, actually. E.g., the Nominum DHCP server (DCS) just looks the name up every time, under the assumption that the caching name server is going to perform better than any ad hoc resolver we might stuff into the DHCP server. The ISC DHCP server caches names for an hour - a decision I made when caching name servers weren't as good as they are now, and when I was a lot more naive about DNS than I am now. I can't speak for the other vendors, so you'd have to ask them, but I'd be really surprised if they didn't do the same thing - if you cache the value, you have to cache it some/where/ - it's not quite the same as when a server looks up an address in the DNS so that it can connect to that address. I don't know what SOHO routers do, in general - it would be interesting to investigate. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 19:43:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxB10-0004tj-C4; Tue, 27 Nov 2007 19:42:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxB0z-0004tR-6e for dhcwg@ietf.org; Tue, 27 Nov 2007 19:42:57 -0500 Received: from mx.isc.org ([2001:4f8:0:2::1c]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxB0y-0000AD-Nm for dhcwg@ietf.org; Tue, 27 Nov 2007 19:42:57 -0500 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 87D71114074; Wed, 28 Nov 2007 00:42:55 +0000 (UTC) (envelope-from Shane_Kerr@isc.org) Received: from [204.152.189.28] (dhcp-wi-28.sql1.isc.org [204.152.189.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 22113E6056; Wed, 28 Nov 2007 00:42:56 +0000 (UTC) (envelope-from shane@isc.org) Message-ID: <474CB98F.7050603@isc.org> Date: Wed, 28 Nov 2007 01:42:55 +0100 From: Shane Kerr Organization: ISC User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: dhcwg@ietf.org X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.9 (---) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ntpwg@lists.ntp.org Subject: [dhcwg] DNSSEC in names vs. numbers for NTP server information in DHCP X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shane_kerr@isc.org List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, I was reading the long, long, long thread(s) about putting NTP information into DHCP, and the focus on whether DHCP servers should provide names or IP addresses for NTP servers. It occurs to me that DNSSEC requires accurate time. So, we have a bit of a bootstrapping issue if we ever decide to secure DNS zones that contain NTP servers in them and expect clients to use the server names to find them. It seems like we have to provide IP addresses for NTP servers for this reason. - -- Shane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHTLmLMsfZxBO4kbQRAvdVAJ4j3CdU7WOIobV7/1shw6nNaX+j9wCfQgY9 Tu1+WtSfMikoNqked4ceQxc= =WxZu -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 19:50:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxB8i-0003yc-4T; Tue, 27 Nov 2007 19:50:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxB8h-0003yP-9E for dhcwg@ietf.org; Tue, 27 Nov 2007 19:50:55 -0500 Received: from mail1.ntp.org ([204.152.184.126]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxB8g-0005OF-T7 for dhcwg@ietf.org; Tue, 27 Nov 2007 19:50:55 -0500 Received: from localhost (localhost [127.0.0.1]) by mail1.ntp.org (Postfix) with ESMTP id 4DE1839DBF; Wed, 28 Nov 2007 00:50:54 +0000 (UTC) (envelope-from stenn@ntp1.ntp.org) Received: from mail1.ntp.org ([127.0.0.1]) by localhost (ntp1.isc.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13107-02; Wed, 28 Nov 2007 00:50:31 +0000 (UTC) Received: from ntp1.ntp.org (localhost [127.0.0.1]) by mail1.ntp.org (Postfix) with ESMTP; Wed, 28 Nov 2007 00:50:29 +0000 (UTC) (envelope-from stenn@ntp1.ntp.org) To: shane_kerr@isc.org In-Reply-To: Message from Shane Kerr of "Wed, 28 Nov 2007 01:42:55 +0100." <474CB98F.7050603@isc.org> X-Mailer: MH-E 7.4.2; nmh 1.0.4; XEmacs 21.4 (patch 14) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 28 Nov 2007 00:50:29 +0000 From: Harlan Stenn X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on ntp1.isc.org Message-Id: <20071128005054.4DE1839DBF@mail1.ntp.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org Subject: [dhcwg] Re: [ntpwg] DNSSEC in names vs. numbers for NTP server information in DHCP X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Shane wrote: > It occurs to me that DNSSEC requires accurate time. So, we have a bit > of a bootstrapping issue if we ever decide to secure DNS zones that > contain NTP servers in them and expect clients to use the server names > to find them. > It seems like we have to provide IP addresses for NTP servers for this > reason. In that scenario, yes, that would appear to be the best policy. If one is going to use DHCP to offer NTP configuration information there are good reasons to provide IP addresses to certain hosts. Similarly, there are good reasons to provide names to other hosts. Indeed, one may wish to provide a list of servers using a combination of names and IP addresses. But this is all true for ntp configuration in general - the same issues occur regardless of where the configuration information comes from. H _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 20:01:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxBIp-0002rA-Cv; Tue, 27 Nov 2007 20:01:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxBIo-0002qj-C3 for dhcwg@ietf.org; Tue, 27 Nov 2007 20:01:22 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxBIn-00083P-N3 for dhcwg@ietf.org; Tue, 27 Nov 2007 20:01:22 -0500 Received: (qmail 91338 invoked from network); 28 Nov 2007 01:30:01 -0000 Received: from softbank219001188012.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.12) by necom830.hpcl.titech.ac.jp with SMTP; 28 Nov 2007 01:30:01 -0000 Message-ID: <474CBDD3.6060908@necom830.hpcl.titech.ac.jp> Date: Wed, 28 Nov 2007 10:01:07 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: shane_kerr@isc.org Subject: Re: [dhcwg] DNSSEC in names vs. numbers for NTP server information in DHCP References: <474CB98F.7050603@isc.org> In-Reply-To: <474CB98F.7050603@isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Shane Kerr wrote: > It occurs to me that DNSSEC requires accurate time. DNSSEC requires *SECURE* accurate time. > It seems like we have to provide IP addresses for NTP servers for this reason. It is required that DHCP clients and NTP servers allocated by DHCP *SECURELY* share some information for the DHCP clients authenticate the NTP servers. It, in practice, means shared authentication information must be hand configured in the DHCP clients and associated NTP servers, which means there is no need for DHCP service provide NTP server for secure DNS. Masataka Ohta PS Still, secure DNS is only weakly secure , that is, as secure as plain DNS that there is no reason to deploy it. That is, just as plain DNS is vulnerable to compromised intermediate entities such as ISPs or zone admins, secure DNS is vulnerable to compromised intermediate entities of zone admins or NTP servers. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 20:22:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxBd3-0007gJ-61; Tue, 27 Nov 2007 20:22:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxBd1-0007fi-Jc for dhcwg@ietf.org; Tue, 27 Nov 2007 20:22:15 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxBcz-00008S-Ju for dhcwg@ietf.org; Tue, 27 Nov 2007 20:22:15 -0500 Received: from epmmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JS600HMVZT0HQ@mailout1.samsung.com> for dhcwg@ietf.org; Wed, 28 Nov 2007 10:22:12 +0900 (KST) Received: from samsungcf414c4 ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JS600DGMZT0SB@mmp1.samsung.com> for dhcwg@ietf.org; Wed, 28 Nov 2007 10:22:12 +0900 (KST) Date: Wed, 28 Nov 2007 10:22:11 +0900 From: Daniel Park Subject: RE: [dhcwg] Q for draft-krishnan-dhc-ndc-option-00 In-reply-to: <474C1A1C.7020404@ericsson.com> To: 'Suresh Krishnan' Message-id: <0JS600DGNZT0SB@mmp1.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acgw+G7ctKFLofjoRqKony+W2JaSiwAY234Q X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: 'DHC WG' X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org one approach is not to define *Prefix Information* in your document and goes to others ND optional information. Although it seems admin issue, I don't think we need to have a redundant method for getting *Prefix Information*... RFC3633 lives up to *IPv6 Prefix Configuration*. Daniel Park > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] > Sent: Tuesday, November 27, 2007 10:23 PM > To: Daniel Park > Cc: 'DHC WG' > Subject: Re: [dhcwg] Q for draft-krishnan-dhc-ndc-option-00 > > Hi Daniel, > I was also thinking a lot about this, and I could not find > a satisfactory answer. This problem has always existed and > needs to be fixed by administrative solutions. I think this > is related to site policy and not for IETF to specify what to > do. I was thinking about writing a draft that just specifies > this issue (clash between info gleamed from stateless RA > based methods and DHCP based methods) and advises admins to > come up with a policy that specifies the precedence on client > machines. > > Thanks > Suresh > > Daniel Park wrote: > > Just curious what happen if IPv6 Prefix Option and ND > Prefix Information > > Option are in use at the same time ? > > > > > >> Neighbor Discovery Information over DHCP S. > Krishnan 15 > >> minutes > >> > >> Initial discussion for consideration as WG work item > > > > > > > > Daniel Park [at] SAMSUNG Electronics > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 22:03:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxDD1-0004MT-CM; Tue, 27 Nov 2007 22:03:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxDD0-0004Ka-08 for dhcwg@ietf.org; Tue, 27 Nov 2007 22:03:30 -0500 Received: from mx04.gis.net ([208.218.130.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxDCz-0006pl-LX for dhcwg@ietf.org; Tue, 27 Nov 2007 22:03:29 -0500 Received: from [10.10.10.101] ([63.209.224.211]) by mx04.gis.net; Tue, 27 Nov 2007 22:03:24 -0500 Message-ID: <474CD9D2.3050405@ntp.org> Date: Tue, 27 Nov 2007 22:00:34 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ted Lemon Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> <474C855F.6080609@udel.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org WG" , "David L. Mills" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ted Lemon wrote: > On Nov 27, 2007, at 4:00 PM, David L. Mills wrote: >> If the DHCP server followed that advice, it would >> occasionally re-resolve the name and pass the new IP address to its >> clients. It is not at all clear that this advice is followed in the real >> world. > > It is followed, actually. E.g., the Nominum DHCP server (DCS) just > looks the name up every time, under the assumption that the caching name > server is going to perform better than any ad hoc resolver we might > stuff into the DHCP server. The ISC DHCP server caches names for an > hour - a decision I made when caching name servers weren't as good as > they are now, and when I was a lot more naive about DNS than I am now. > I can't speak for the other vendors, so you'd have to ask them, but I'd > be really surprised if they didn't do the same thing - if you cache the > value, you have to cache it some/where/ - it's not quite the same as > when a server looks up an address in the DNS so that it can connect to > that address. > This was the next question to ask of course. How many of the addresses in the reply are cached for distribution as appropriate? With the pool config option we use as many as 10 returned from the DNS query. How many of these would we expect to get if we relied on DHCP to supply those IP addresses. > I don't know what SOHO routers do, in general - it would be interesting > to investigate. Volunteers? Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 27 23:24:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxETa-0000eA-2F; Tue, 27 Nov 2007 23:24:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxETZ-0000e4-6L for dhcwg@ietf.org; Tue, 27 Nov 2007 23:24:41 -0500 Received: from mx04.gis.net ([208.218.130.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxETY-0000eq-PS for dhcwg@ietf.org; Tue, 27 Nov 2007 23:24:41 -0500 Received: from [10.10.10.101] ([63.209.224.211]) by mx04.gis.net; Tue, 27 Nov 2007 23:24:18 -0500 Message-ID: <474CECCD.6090707@ntp.org> Date: Tue, 27 Nov 2007 23:21:33 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: shane_kerr@isc.org Subject: Re: [dhcwg] DNSSEC in names vs. numbers for NTP server information in DHCP References: <474CB98F.7050603@isc.org> In-Reply-To: <474CB98F.7050603@isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Shane Kerr wrote: > All, > > I was reading the long, long, long thread(s) about putting NTP information into > DHCP, and the focus on whether DHCP servers should provide names or IP addresses > for NTP servers. > > It occurs to me that DNSSEC requires accurate time. So, we have a bit of a > bootstrapping issue if we ever decide to secure DNS zones that contain NTP > servers in them and expect clients to use the server names to find them. > > It seems like we have to provide IP addresses for NTP servers for this reason. > I'm not sure which hat to wear on this one. The first question is 1) how accurate? Within 5 minutes like TSIG? 2) I assume that this is both ends relative to each other? We always had a bootstrapping issue. It's only now becoming obvious. I had mentioned this in a previous message. One way of avoiding the accurate time issue is to use a refclock on the system and have NTP get its time from there. There are actually three different parts of this: 1) DNS Servers using DNSSEC for the zone in which they are authorative These will have static IP addresses and DHCP would presumably not be involved (though no doubt can provide other data). I would expect that it would be set up manually to have ntpd to use servers specified by the sysadmin. 2) Caching DNSSEC-aware servers These are presumably the servers responsible for supplying the answers to the ultimate clients. These would also presumably have static IP addresses and not use DHCP. They too could be manually configured to use NTP from their own resources but could conceivably get information from DHCP servers. 3) The clients themselves using a DNSSEC-enabled resolver. These are likely to be provisioned with IP addresses, DNS server addresses, etc. and presumably get their information from DHCP. These clients are the most vunerable since presumably the NTP server would be provisioned by DHCP which would need to make sure that they receive authenticated data. That's the chicken and egg problem since they presumably need an accurate time before communicating with the DHCP server to get information about the NTP server addresses to use. If you are concerned enough to use DNSSEC you presumably are concerned enough to use only authenticatable NTP servers and that means using autokey protocol (now in IETF draft). That requires a key and it needs to be distributed OOB. The key could potentially be distributed by DHCP but you also need to protect the key from modification in flight which presumably needs DHCP authenticationc and encryption if that's the distribution method. The trick here is to figure out which piece to set up first. Ideas? Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 04:13:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxIys-00061O-IG; Wed, 28 Nov 2007 04:13:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxIyq-00061D-QK for dhcwg@ietf.org; Wed, 28 Nov 2007 04:13:16 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxIyo-0000ZP-OS for dhcwg@ietf.org; Wed, 28 Nov 2007 04:13:16 -0500 Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 09:13:13 +0000 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 Subject: RE: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Wed, 28 Nov 2007 09:13:12 -0000 Message-ID: <548EC156325C6340B2E85DF90CAE8586019A0008@E03MVB3-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Thread-Index: AcgxJtt/HXk4zluxSFOu9g5fEnM/EQAd8H0g From: To: , X-OriginalArrivalTime: 28 Nov 2007 09:13:13.0563 (UTC) FILETIME=[E75302B0:01C8319E] X-Spam-Score: -0.7 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: mayer@ntp.isc.org, ntpwg@lists.ntp.org, mellon@fugue.com, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Perhaps some other ISP's involved with the NTPWG would care to comment on whether or not the poor practice of the past is still in place, or being replaced with best practice (which is to install their own servers, or reach an agreement for the use of somebody else's).=20 -----Original Message----- From: Brad Knowles [mailto:brad@shub-internet.org]=20 Sent: 27 November 2007 18:42 To: Flavin,AJ,Tony,DMJ R; brad@shub-internet.org; Mark_Andrews@isc.org Cc: mayer@ntp.isc.org; ntpwg@lists.ntp.org; mellon@fugue.com; rgayraud@cisco.com; dhcwg@ietf.org Subject: RE: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 On 11/27/07, wrote: > Completely wrong. My statement was with regards to most ISPs that I have experience with or or where we have had reports from others. Your specific ISP was not necessarily included in that statement.=20 Therefore, your single solitary counter-example does not necessarily disprove anything. > I can assure you that we do run our own NTP servers, and our customer > routers are pre-configured with a Name not an IP address to get to them. > We let our DNS servers sort out the load balancing issues (if we ever > get any). You're just one ISP. You do not comprise the whole of all ISPs on the planet. > It's working fine, and several hundred-thousand clients can't be wrong! And I personally worked at AOL (tens of millions of customers) and the largest ISP in Belgium (over a million customers), and I've consulted at other ISPs around the world. We've also had reports regarding a number of other ISPs around the world. Your one counter example does not disprove our experience. -- Brad Knowles LinkedIn Profile: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 04:36:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJLl-00036l-9k; Wed, 28 Nov 2007 04:36:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJLj-00036a-K8 for dhcwg@ietf.org; Wed, 28 Nov 2007 04:36:55 -0500 Received: from mx.isc.org ([2001:4f8:0:2::1c]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxJLj-0001x5-6q for dhcwg@ietf.org; Wed, 28 Nov 2007 04:36:55 -0500 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 0EA38114069 for ; Wed, 28 Nov 2007 09:36:54 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 764ABE6056 for ; Wed, 28 Nov 2007 09:36:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id lAS9Ulk7065582; Wed, 28 Nov 2007 20:30:56 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200711280930.lAS9Ulk7065582@drugs.dv.isc.org> To: anthony.flavin@bt.com From: Mark Andrews Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 In-reply-to: Your message of "Wed, 28 Nov 2007 09:13:12 -0000." <548EC156325C6340B2E85DF90CAE8586019A0008@E03MVB3-UKBR.domain1.systemhost.net> Date: Wed, 28 Nov 2007 20:30:47 +1100 X-Spam-Score: -1.1 (-) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: mayer@ntp.isc.org, mellon@fugue.com, ntpwg@lists.ntp.org, brad@shub-internet.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org They are not the only ISP that supplies time. Optus does and I'm pretty sure Telstra also does. My home box is sync'd to a Optus NTP server. Mark > Perhaps some other ISP's involved with the NTPWG would care to comment > on whether or not the poor practice of the past is still in place, or > being replaced with best practice (which is to install their own > servers, or reach an agreement for the use of somebody else's).=20 > > -----Original Message----- > From: Brad Knowles [mailto:brad@shub-internet.org]=20 > Sent: 27 November 2007 18:42 > To: Flavin,AJ,Tony,DMJ R; brad@shub-internet.org; Mark_Andrews@isc.org > Cc: mayer@ntp.isc.org; ntpwg@lists.ntp.org; mellon@fugue.com; > rgayraud@cisco.com; dhcwg@ietf.org > Subject: RE: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) > OptionsforDHCPv6 > > On 11/27/07, wrote: > > > Completely wrong. > > My statement was with regards to most ISPs that I have experience with > or or where we have had reports from others. > > Your specific ISP was not necessarily included in that statement.=20 > Therefore, your single solitary counter-example does not necessarily > disprove anything. > > > I can assure you that we do run our own NTP servers, and our customer > > > routers are pre-configured with a Name not an IP address to get to > them. > > We let our DNS servers sort out the load balancing issues (if we ever > > > get any). > > You're just one ISP. You do not comprise the whole of all ISPs on the > planet. > > > It's working fine, and several hundred-thousand clients can't be > wrong! > > And I personally worked at AOL (tens of millions of customers) and the > largest ISP in Belgium (over a million customers), and I've consulted at > other ISPs around the world. We've also had reports regarding a number > of other ISPs around the world. > > Your one counter example does not disprove our experience. > > -- > Brad Knowles > LinkedIn Profile: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 08:55:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNNi-0006Ta-2d; Wed, 28 Nov 2007 08:55:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwvtx-0001yr-0w for dhcwg@ietf.org; Tue, 27 Nov 2007 03:34:41 -0500 Received: from ip-64-139-1-69.sjc.megapath.net ([64.139.1.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwvtr-0002Za-S2 for dhcwg@ietf.org; Tue, 27 Nov 2007 03:34:41 -0500 Received: by ip-64-139-1-69.sjc.megapath.net (Postfix, from userid 500) id B2AFDBE31; Tue, 27 Nov 2007 00:34:34 -0800 (PST) Received: from glypnod (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id A1281BE2F; Tue, 27 Nov 2007 00:34:34 -0800 (PST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: Brad Knowles From: Hal Murray Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 In-Reply-To: Message from Brad Knowles of "Tue, 27 Nov 2007 01:32:42 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Nov 2007 00:34:33 -0800 Message-Id: <20071127083434.B2AFDBE31@ip-64-139-1-69.sjc.megapath.net> X-Spam-Score: 3.5 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Wed, 28 Nov 2007 08:55:11 -0500 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , hmurray@megapathdsl.net X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > Which implies that the NTP client now needs to become fully DHCP aware. I was going to say something like that too... But I poked around a bit. One alternative is that the DHCP client is NTP aware. :) /sbin/dhclient-script on my Linux box stuffs server lines into ntp.conf I think it's smart enough to restart ntpd if the list of ntp servers changes. I didn't check all the fine print or try to test it. Ugly, but probably good enough. A comment says dhclient-script came from NetBSD so others have probably copied the idea. -- These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 08:55:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNNj-0006XR-AE; Wed, 28 Nov 2007 08:55:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJyU-0005eo-Qb for dhcwg@ietf.org; Wed, 28 Nov 2007 05:16:58 -0500 Received: from smtp102.his.com ([216.194.225.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxJyU-0008QC-A4 for dhcwg@ietf.org; Wed, 28 Nov 2007 05:16:58 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp102.his.com (Postfix) with ESMTP id DF77613E42F3; Wed, 28 Nov 2007 05:16:57 -0500 (EST) Received: from smtp102.his.com ([216.194.225.125]) by localhost (smtp102.his.com [216.194.225.125]) (amavisd-new, port 10024) with ESMTP id 04534-10; Wed, 28 Nov 2007 05:16:55 -0500 (EST) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by smtp102.his.com (Postfix) with ESMTP id A877E13E41E9; Wed, 28 Nov 2007 05:16:55 -0500 (EST) Received: from [192.168.1.101] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.13.1/8.12.3) with ESMTP id lASAGrD0054669; WedFrom dhcwg-bounces@ietf.org Wed Nov 28 08:55:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNNi-0006Ta-2d; Wed, 28 Nov 2007 08:55:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwvtx-0001yr-0w for dhcwg@ietf.org; Tue, 27 Nov 2007 03:34:41 -0500 Received: from ip-64-139-1-69.sjc.megapath.net ([64.139.1.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwvtr-0002Za-S2 for dhcwg@ietf.org; Tue, 27 Nov 2007 03:34:41 -0500 Received: by ip-64-139-1-69.sjc.megapath.net (Postfix, from userid 500) id B2AFDBE31; Tue, 27 Nov 2007 00:34:34 -0800 (PST) Received: from glypnod (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id A1281BE2F; Tue, 27 Nov 2007 00:34:34 -0800 (PST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: Brad Knowles From: Hal Murray Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 In-Reply-To: Message from Brad Knowles of "Tue, 27 Nov 2007 01:32:42 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Nov 2007 00:34:33 -0800 Message-Id: <20071127083434.B2AFDBE31@ip-64-139-1-69.sjc.megapath.net> X-Spam-Score: 3.5 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Wed, 28 Nov 2007 08:55:11 -0500 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , hmurray@megapathdsl.net X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > Which implies that the NTP client now needs to become fully DHCP aware. I was going to say something like that too... But I poked around a bit. One alternative is that the DHCP client is NTP aware. :) /sbin/dhclient-script on my Linux box stuffs server lines into ntp.conf I think it's smart enough to restart ntpd if the list of ntp servers changes. I didn't check all the fine print or try to test it. Ugly, but probably good enough. A comment says dhclient-script came from NetBSD so others have probably copied the idea. -- These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 08:55:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNNj-0006XR-AE; Wed, 28 Nov 2007 08:55:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJyU-0005eo-Qb for dhcwg@ietf.org; Wed, 28 Nov 2007 05:16:58 -0500 Received: from smtp102.his.com ([216.194.225.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxJyU-0008QC-A4 for dhcwg@ietf.org; Wed, 28 Nov 2007 05:16:58 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp102.his.com (Postfix) with ESMTP id DF77613E42F3; Wed, 28 Nov 2007 05:16:57 -0500 (EST) Received: from smtp102.his.com ([216.194.225.125]) by localhost (smtp102.his.com [216.194.225.125]) (amavisd-new, port 10024) with ESMTP id 04534-10; Wed, 28 Nov 2007 05:16:55 -0500 (EST) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by smtp102.his.com (Postfix) with ESMTP id A877E13E41E9; Wed, 28 Nov 2007 05:16:55 -0500 (EST) Received: from [192.168.1.101] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.13.1/8.12.3) with ESMTP id lASAGrD0054669; WedFrom dhcwg-bounces@ietf.org Wed Nov 28 08:55:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNNi-0006Ta-2d; Wed, 28 Nov 2007 08:55:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwvtx-0001yr-0w for dhcwg@ietf.org; Tue, 27 Nov 2007 03:34:41 -0500 Received: from ip-64-139-1-69.sjc.megapath.net ([64.139.1.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwvtr-0002Za-S2 for dhcwg@ietf.org; Tue, 27 Nov 2007 03:34:41 -0500 Received: by ip-64-139-1-69.sjc.megapath.net (Postfix, from userid 500) id B2AFDBE31; Tue, 27 Nov 2007 00:34:34 -0800 (PST) Received: from glypnod (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id A1281BE2F; Tue, 27 Nov 2007 00:34:34 -0800 (PST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: Brad Knowles From: Hal Murray Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 In-Reply-To: Message from Brad Knowles of "Tue, 27 Nov 2007 01:32:42 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Nov 2007 00:34:33 -0800 Message-Id: <20071127083434.B2AFDBE31@ip-64-139-1-69.sjc.megapath.net> X-Spam-Score: 3.5 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Wed, 28 Nov 2007 08:55:11 -0500 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" , hmurray@megapathdsl.net X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > Which implies that the NTP client now needs to become fully DHCP aware. I was going to say something like that too... But I poked around a bit. One alternative is that the DHCP client is NTP aware. :) /sbin/dhclient-script on my Linux box stuffs server lines into ntp.conf I think it's smart enough to restart ntpd if the list of ntp servers changes. I didn't check all the fine print or try to test it. Ugly, but probably good enough. A comment says dhclient-script came from NetBSD so others have probably copied the idea. -- These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 08:55:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNNj-0006XR-AE; Wed, 28 Nov 2007 08:55:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJyU-0005eo-Qb for dhcwg@ietf.org; Wed, 28 Nov 2007 05:16:58 -0500 Received: from smtp102.his.com ([216.194.225.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxJyU-0008QC-A4 for dhcwg@ietf.org; Wed, 28 Nov 2007 05:16:58 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp102.his.com (Postfix) with ESMTP id DF77613E42F3; Wed, 28 Nov 2007 05:16:57 -0500 (EST) Received: from smtp102.his.com ([216.194.225.125]) by localhost (smtp102.his.com [216.194.225.125]) (amavisd-new, port 10024) with ESMTP id 04534-10; Wed, 28 Nov 2007 05:16:55 -0500 (EST) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by smtp102.his.com (Postfix) with ESMTP id A877E13E41E9; Wed, 28 Nov 2007 05:16:55 -0500 (EST) Received: from [192.168.1.101] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.13.1/8.12.3) with ESMTP id lASAGrD0054669; Wed, 28 Nov 2007 05:16:54 -0500 (EST) (envelope-from brad@shub-internet.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200711280930.lAS9Ulk7065582@drugs.dv.isc.org> References: <200711280930.lAS9Ulk7065582@drugs.dv.isc.org> Date: Wed, 28 Nov 2007 04:14:21 -0600 To: Mark Andrews , anthony.flavin@bt.com From: Brad Knowles Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: Debian amavisd-new at smtp502.his.com X-Spam-Status: No, score=-4.342 tagged_above=-99 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.057, BAYES_00=-2.599] X-Spam-Score: -4.342 X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Wed, 28 Nov 2007 08:55:11 -0500 Cc: mayer@ntp.isc.org, ntpwg@lists.ntp.org, brad@shub-internet.org, mellon@fugue.com, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On 11/28/07, Mark Andrews wrote: > They are not the only ISP that supplies time. Optus does and > I'm pretty sure Telstra also does. My home box is sync'd to > a Optus NTP server. I know that XS4ALL.nl also provides time servers for their clients (I know this because I am also the primary active member of the postmaster services team for python.org, which is hosted at XS4ALL), but elsewhere in Belgium and the Netherlands and most of continental Europe, I believe that kind of thing is pretty rare. In my experience, it's even more rare in the less well-developed parts of Europe. I believe that we have some representatives from RIPE and perhaps also some other registrars, registries, and other related organizations. It would be interesting if we could get some data from them. Failing that, I've got plenty of contacts over at RIPE, and I'm sure I could drop them a line. I figure others on this list probably have better contacts with some of the other organizations. We should also talk to Ask Bjorn Hansen, since he's likely to have contact with a lot of places around the world in his role as the coordinator of the pool.ntp.org project. -- Brad Knowles LinkedIn Profile: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 08:55:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNNh-0006TE-F4; Wed, 28 Nov 2007 08:55:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwumX-0001Jl-GD for dhcwg@ietf.org; Tue, 27 Nov 2007 02:22:57 -0500 Received: from smtp102.his.com ([216.194.225.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwumX-0007Bl-3a for dhcwg@ietf.org; Tue, 27 Nov 2007 02:22:57 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp102.his.com (Postfix) with ESMTP id D172813E41EF; Tue, 27 Nov 2007 02:22:56 -0500 (EST) Received: from smtp102.his.com ([216.194.225.125]) by localhost (smtp102.his.com [216.194.225.125]) (amavisd-new, port 10024) with ESMTP id 24656-02-2; Tue, 27 Nov 2007 02:22:54 -0500 (EST) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by smtp102.his.com (Postfix) with ESMTP id 8E3B113E41DE; Tue, 27 Nov 2007 02:22:54 -0500 (EST) Received: from [192.168.1.101] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.13.1/8.12.3) with ESMTP id lAR7MjBg091113; Tue, 27 Nov 2007 02:22:53 , 28 Nov 2007 05:16:54 -0500 (EST) (envelope-from brad@shub-internet.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200711280930.lAS9Ulk7065582@drugs.dv.isc.org> References: <200711280930.lAS9Ulk7065582@drugs.dv.isc.org> Date: Wed, 28 Nov 2007 04:14:21 -0600 To: Mark Andrews , anthony.flavin@bt.com From: Brad Knowles Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: Debian amavisd-new at smtp502.his.com X-Spam-Status: No, score=-4.342 tagged_above=-99 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.057, BAYES_00=-2.599] X-Spam-Score: -4.342 X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Wed, 28 Nov 2007 08:55:11 -0500 Cc: mayer@ntp.isc.org, ntpwg@lists.ntp.org, brad@shub-internet.org, mellon@fugue.com, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On 11/28/07, Mark Andrews wrote: > They are not the only ISP that supplies time. Optus does and > I'm pretty sure Telstra also does. My home box is sync'd to > a Optus NTP server. I know that XS4ALL.nl also provides time servers for their clients (I know this because I am also the primary active member of the postmaster services team for python.org, which is hosted at XS4ALL), but elsewhere in Belgium and the Netherlands and most of continental Europe, I believe that kind of thing is pretty rare. In my experience, it's even more rare in the less well-developed parts of Europe. I believe that we have some representatives from RIPE and perhaps also some other registrars, registries, and other related organizations. It would be interesting if we could get some data from them. Failing that, I've got plenty of contacts over at RIPE, and I'm sure I could drop them a line. I figure others on this list probably have better contacts with some of the other organizations. We should also talk to Ask Bjorn Hansen, since he's likely to have contact with a lot of places around the world in his role as the coordinator of the pool.ntp.org project. -- Brad Knowles LinkedIn Profile: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 08:55:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNNh-0006TE-F4; Wed, 28 Nov 2007 08:55:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwumX-0001Jl-GD for dhcwg@ietf.org; Tue, 27 Nov 2007 02:22:57 -0500 Received: from smtp102.his.com ([216.194.225.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwumX-0007Bl-3a for dhcwg@ietf.org; Tue, 27 Nov 2007 02:22:57 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp102.his.com (Postfix) with ESMTP id D172813E41EF; Tue, 27 Nov 2007 02:22:56 -0500 (EST) Received: from smtp102.his.com ([216.194.225.125]) by localhost (smtp102.his.com [216.194.225.125]) (amavisd-new, port 10024) with ESMTP id 24656-02-2; Tue, 27 Nov 2007 02:22:54 -0500 (EST) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by smtp102.his.com (Postfix) with ESMTP id 8E3B113E41DE; Tue, 27 Nov 2007 02:22:54 -0500 (EST) Received: from [192.168.1.101] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.13.1/8.12.3) with ESMTP id lAR7MjBg091113; Tue, 27 Nov 2007 02:22:53 , 28 Nov 2007 05:16:54 -0500 (EST) (envelope-from brad@shub-internet.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200711280930.lAS9Ulk7065582@drugs.dv.isc.org> References: <200711280930.lAS9Ulk7065582@drugs.dv.isc.org> Date: Wed, 28 Nov 2007 04:14:21 -0600 To: Mark Andrews , anthony.flavin@bt.com From: Brad Knowles Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: Debian amavisd-new at smtp502.his.com X-Spam-Status: No, score=-4.342 tagged_above=-99 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.057, BAYES_00=-2.599] X-Spam-Score: -4.342 X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Wed, 28 Nov 2007 08:55:11 -0500 Cc: mayer@ntp.isc.org, ntpwg@lists.ntp.org, brad@shub-internet.org, mellon@fugue.com, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On 11/28/07, Mark Andrews wrote: > They are not the only ISP that supplies time. Optus does and > I'm pretty sure Telstra also does. My home box is sync'd to > a Optus NTP server. I know that XS4ALL.nl also provides time servers for their clients (I know this because I am also the primary active member of the postmaster services team for python.org, which is hosted at XS4ALL), but elsewhere in Belgium and the Netherlands and most of continental Europe, I believe that kind of thing is pretty rare. In my experience, it's even more rare in the less well-developed parts of Europe. I believe that we have some representatives from RIPE and perhaps also some other registrars, registries, and other related organizations. It would be interesting if we could get some data from them. Failing that, I've got plenty of contacts over at RIPE, and I'm sure I could drop them a line. I figure others on this list probably have better contacts with some of the other organizations. We should also talk to Ask Bjorn Hansen, since he's likely to have contact with a lot of places around the world in his role as the coordinator of the pool.ntp.org project. -- Brad Knowles LinkedIn Profile: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 08:55:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNNh-0006TE-F4; Wed, 28 Nov 2007 08:55:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwumX-0001Jl-GD for dhcwg@ietf.org; Tue, 27 Nov 2007 02:22:57 -0500 Received: from smtp102.his.com ([216.194.225.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwumX-0007Bl-3a for dhcwg@ietf.org; Tue, 27 Nov 2007 02:22:57 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp102.his.com (Postfix) with ESMTP id D172813E41EF; Tue, 27 Nov 2007 02:22:56 -0500 (EST) Received: from smtp102.his.com ([216.194.225.125]) by localhost (smtp102.his.com [216.194.225.125]) (amavisd-new, port 10024) with ESMTP id 24656-02-2; Tue, 27 Nov 2007 02:22:54 -0500 (EST) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by smtp102.his.com (Postfix) with ESMTP id 8E3B113E41DE; Tue, 27 Nov 2007 02:22:54 -0500 (EST) Received: from [192.168.1.101] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.13.1/8.12.3) with ESMTP id lAR7MjBg091113; Tue, 27 Nov 2007 02:22:53 -0500 (EST) (envelope-from brad@shub-internet.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> Date: Tue, 27 Nov 2007 01:08:28 -0600 To: Ted Lemon , "dhcwg@ietf.org WG" From: Brad Knowles Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: Debian amavisd-new at smtp502.his.com X-Spam-Status: No, score=-4.342 tagged_above=-99 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.057, BAYES_00=-2.599] X-Spam-Score: -4.342 X-Spam-Level: X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Wed, 28 Nov 2007 08:55:11 -0500 Cc: ntpwg@lists.ntp.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On 11/26/07, Ted Lemon wrote: > But the main point that I keep making and that people keep ignoring is > that this problem is not solved by using a domain name in place of an > IP address. Using the domain name simply means that the place where > the badness would occur is different. It's still a problem for the > SOHO box or cable modem to be preconfigured with a name like > "NTP.POMME.FR" - the only difference is that in that case not only > will the NTP server at NTP.POMME.FR get slammed, but also the name > server for NTP.POMME.FR will get slammed. Not true. The NS and A records for NTP.POMME.FR will presumably have a lifetime that is measured in hundreds, thousands, tens of thousands, or maybe even hundreds of thousands of seconds, and they will be cached on the remote end. However, each and every one of those hundreds of thousands or millions of misconfigured NTP clients will be pounding the NTP.POMME.FR machine once every sixty seconds or so, unless they've managed to back off to just pounding it ever thousand seconds or so. If they're misconfigured, or the machine is not responding, they may pound it every second -- or maybe many hundreds of times per second. There's a huge difference here. Like, orders of magnitude. Possibly many orders of magnitude. > So my point is that whether we use an IP address or a domain name, the > same problem still occurs. So the fact that the problem exists can't > be used as a justification for using one over the other. The difference is that once an IP address is given out, it can't be changed to point somewhere else. Once a name is given out, it can always be changed to point to a different IP address. The current reference implementation would not re-resolve that name into the new IP address, but at least all new(er) instances would catch the new IP address, and life would be able to continue. -- Brad Knowles LinkedIn Profile: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg -0500 (EST) (envelope-from brad@shub-internet.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> Date: Tue, 27 Nov 2007 01:08:28 -0600 To: Ted Lemon , "dhcwg@ietf.org WG" From: Brad Knowles Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: Debian amavisd-new at smtp502.his.com X-Spam-Status: No, score=-4.342 tagged_above=-99 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.057, BAYES_00=-2.599] X-Spam-Score: -4.342 X-Spam-Level: X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Wed, 28 Nov 2007 08:55:11 -0500 Cc: ntpwg@lists.ntp.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On 11/26/07, Ted Lemon wrote: > But the main point that I keep making and that people keep ignoring is > that this problem is not solved by using a domain name in place of an > IP address. Using the domain name simply means that the place where > the badness would occur is different. It's still a problem for the > SOHO box or cable modem to be preconfigured with a name like > "NTP.POMME.FR" - the only difference is that in that case not only > will the NTP server at NTP.POMME.FR get slammed, but also the name > server for NTP.POMME.FR will get slammed. Not true. The NS and A records for NTP.POMME.FR will presumably have a lifetime that is measured in hundreds, thousands, tens of thousands, or maybe even hundreds of thousands of seconds, and they will be cached on the remote end. However, each and every one of those hundreds of thousands or millions of misconfigured NTP clients will be pounding the NTP.POMME.FR machine once every sixty seconds or so, unless they've managed to back off to just pounding it ever thousand seconds or so. If they're misconfigured, or the machine is not responding, they may pound it every second -- or maybe many hundreds of times per second. There's a huge difference here. Like, orders of magnitude. Possibly many orders of magnitude. > So my point is that whether we use an IP address or a domain name, the > same problem still occurs. So the fact that the problem exists can't > be used as a justification for using one over the other. The difference is that once an IP address is given out, it can't be changed to point somewhere else. Once a name is given out, it can always be changed to point to a different IP address. The current reference implementation would not re-resolve that name into the new IP address, but at least all new(er) instances would catch the new IP address, and life would be able to continue. -- Brad Knowles LinkedIn Profile: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg -0500 (EST) (envelope-from brad@shub-internet.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> Date: Tue, 27 Nov 2007 01:08:28 -0600 To: Ted Lemon , "dhcwg@ietf.org WG" From: Brad Knowles Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: Debian amavisd-new at smtp502.his.com X-Spam-Status: No, score=-4.342 tagged_above=-99 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.057, BAYES_00=-2.599] X-Spam-Score: -4.342 X-Spam-Level: X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Wed, 28 Nov 2007 08:55:11 -0500 Cc: ntpwg@lists.ntp.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On 11/26/07, Ted Lemon wrote: > But the main point that I keep making and that people keep ignoring is > that this problem is not solved by using a domain name in place of an > IP address. Using the domain name simply means that the place where > the badness would occur is different. It's still a problem for the > SOHO box or cable modem to be preconfigured with a name like > "NTP.POMME.FR" - the only difference is that in that case not only > will the NTP server at NTP.POMME.FR get slammed, but also the name > server for NTP.POMME.FR will get slammed. Not true. The NS and A records for NTP.POMME.FR will presumably have a lifetime that is measured in hundreds, thousands, tens of thousands, or maybe even hundreds of thousands of seconds, and they will be cached on the remote end. However, each and every one of those hundreds of thousands or millions of misconfigured NTP clients will be pounding the NTP.POMME.FR machine once every sixty seconds or so, unless they've managed to back off to just pounding it ever thousand seconds or so. If they're misconfigured, or the machine is not responding, they may pound it every second -- or maybe many hundreds of times per second. There's a huge difference here. Like, orders of magnitude. Possibly many orders of magnitude. > So my point is that whether we use an IP address or a domain name, the > same problem still occurs. So the fact that the problem exists can't > be used as a justification for using one over the other. The difference is that once an IP address is given out, it can't be changed to point somewhere else. Once a name is given out, it can always be changed to point to a different IP address. The current reference implementation would not re-resolve that name into the new IP address, but at least all new(er) instances would catch the new IP address, and life would be able to continue. -- Brad Knowles LinkedIn Profile: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 08:55:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNNi-0006Tv-Gi; Wed, 28 Nov 2007 08:55:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5ZF-00056P-70 for dhcwg@ietf.org; Tue, 27 Nov 2007 13:53:57 -0500 Received: from smtp102.his.com ([216.194.225.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix5ZA-00078O-A9 for dhcwg@ietf.org; Tue, 27 Nov 2007 13:53:52 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp102.his.com (Postfix) with ESMTP id F32D413E4286; Tue, 27 Nov 2007 13:53:51 -0500 (EST) Received: from smtp102.his.com ([216.194.225.125]) by localhost (smtp102.his.com [216.194.225.125]) (amavisd-new, port 10024) with ESMTP id 15857-06; Tue, 27 Nov 2007 13:53:48 -0500 (EST) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by smtp102.his.com (Postfix) with ESMTP id B0FE413E42ED; Tue, 27 Nov 2007 13:53:48 -0500 (EST) Received: from [192.168.1.101] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.13.1/8.12.3) with ESMTP id lARIrkEL018716; Tue, 27 Nov 2007 13:53:47 -0500 (EST) (envelope-from brad@shub-internet.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <548EC156325C6340B2E85DF90CAE85860199F92F@E03MVB3-UKBR.domain1.systemhost. net> References: <548EC156325C6340B2E85DF90CAE85860199F92F@E03MVB3-UKBR.domain1.systemhost. net> Date: Tue, 27 Nov 2007 12:42:21 -0600 To: , , From: Brad Knowles Subject: RE: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: Debian amavisd-new at smtp502.his.com X-Spam-Status: No, score=-4.342 tagged_above=-99 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.057, BAYES_00=-2.599] X-Spam-Score: -4.342 X-Spam-Level: X-Spam-Score: -0.7 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Wed, 28 Nov 2007 08:55:11 -0500 Cc: mayer@ntp.isc.org, ntpwg@lists.ntp.org, mellon@fugue.com, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On 11/27/07, wrote: > Completely wrong. My statement was with regards to most ISPs that I have experience with or or where we have had reports from others. Your specific ISP was not necessarily included in that statement. Therefore, your single solitary counter-example does not necessarily disprove anything. > I can assure you that we do run our own NTP servers, and our customer > routers are pre-configured with a Name not an IP address to get to them. > We let our DNS servers sort out the load balancing issues (if we ever > get any). You're just one ISP. You do not comprise the whole of all ISPs on the planet. > It's working fine, and several hundred-thousand clients can't be wrong! And I personally worked at AOL (tens of millions of customers) and the largest ISP in Belgium (over a million customers), and I've consulted at other ISPs around the world. We've also had reports regarding a number of other ISPs around the world. Your one counter example does not disprove our experience. -- Brad Knowles LinkedIn Profile: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 08:55:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNNh-0006TV-SW; Wed, 28 Nov 2007 08:55:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwv1w-0000Ql-CZ for dhcwg@ietf.org; Tue, 27 Nov 2007 02:38:52 -0500 Received: from smtp102.his.com ([216.194.225.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwv1w-0008UR-0W for dhcwg@ietf.org; Tue, 27 Nov 2007 02:38:52 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp102.his.com (Postfix) with ESMTP id D91A013E42B6; Tue, 27 Nov 2007 02:38:51 -0500 (EST) Received: from smtp102.his.com ([216.194.225.125]) by localhost (smtp102.his.com [216.194.225.125]) (amavisd-new, port 10024) with ESMTP id 27776-03; Tue, 27 Nov 2007 02:38:48 -0500 (EST) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by smtp102.his.com (Postfix) with ESMTP id C4D9F13E42AF; Tue, 27 Nov 2007 02:38:48 -0500 (EST) Received: from [192.168.1.101] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.13.1/8.12.3) with ESMTP id lAR7ciQT091568; Tue, 27 Nov 2007 02:38:47 -0500 (EST) (envelope-from brad@shub-internet.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <474B199E.3060700@cisco.com> References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com><4743B902.3030406@udel.edu> <47445863.4000208@cisco.com> <474B199E.3060700@cisco.com> Date: Tue, 27 Nov 2007 01:38:36 -0600 To: Mark Stapp , "Benoit Lourdelet (blourdel)" From: Brad Knowles Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: Debian amavisd-new at smtp502.his.com X-Spam-Status: No, score=-3.907 tagged_above=-99 required=5 tests=[ALL_TRUSTED=-1.8, AWL=-0.378, BAYES_00=-2.599, SUBJ_HAS_SPACES=0.87] X-Spam-Score: -3.907 X-Spam-Level: X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Wed, 28 Nov 2007 08:55:11 -0500 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On 11/26/07, Mark Stapp wrote: > I do wonder why some folks seem to think that using DNS names would > somehow be "safer" than using v6 addresses. if someone shipped a server > with a canned list of DNS names for NTP servers, there would be a > problem until the owners of the NTP servers named moved them. I don't > see how that'd be any better than the analogous mistake involving IP > addresses. If the name was "pool.ntp.org", today that load would be spread over more than 1500 hosts around the world, and we hope that there will be many more participants in the pool in the future. Moreover, Ask Bjorn Hansen has apparently done a fairly good job of building a robust load-balancing nameserver architecture for this system, and so far as I know would be able to handle a UWisc or PHK-scale disaster plus the "normal" load. Now, 1500 versus millions of misconfigured clients, that's not such a great bet. But it's orders of magnitude better than just a single IP address. > aside from the catastrophe hypothetical, is there any really strong > reason - anything to do with the NTP protocol - that would prevent the > use of ipv6 addresses? At the technical level, no. IP addresses (of both forms) and names should have no technical difference. Of course, this assumes that if you're handing out IPv6 addresses that you'll have full IPv6 stacks on both sides and a fully IPv6-compatible network underneath, and if you hand out IPv4 addresses that you're connected to the appropriate IPv4 network (and not isolated on some IPv6-only island), but that's a different matter. At the practical operations level, yes. See above. -- Brad Knowles LinkedIn Profile: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 08:55:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNNh-0006T5-5w; Wed, 28 Nov 2007 08:55:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwumX-0001Jj-Ew for dhcwg@ietf.org; Tue, 27 Nov 2007 02:22:57 -0500 Received: from smtp102.his.com ([216.194.225.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwumU-0004YJ-6T for dhcwg@ietf.org; Tue, 27 Nov 2007 02:22:57 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp102.his.com (Postfix) with ESMTP id F02E513E4292; Tue, 27 Nov 2007 02:22:53 -0500 (EST) Received: from smtp102.his.com ([216.194.225.125]) by localhost (smtp102.his.com [216.194.225.125]) (amavisd-new, port 10024) with ESMTP id 19868-09; Tue, 27 Nov 2007 02:22:51 -0500 (EST) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by smtp102.his.com (Postfix) with ESMTP id 4607113E41D1; Tue, 27 Nov 2007 02:22:51 -0500 (EST) Received: from [192.168.1.101] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.13.1/8.12.3) with ESMTP id lAR7MjBe091113; Tue, 27 Nov 2007 02:22:49 -0500 (EST) (envelope-from brad@shub-internet.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200711261201.lAQC1NS8060633@drugs.dv.isc.org> References: <200711261201.lAQC1NS8060633@drugs.dv.isc.org> Date: Tue, 27 Nov 2007 01:01:04 -0600 To: Mark Andrews , anthony.flavin@bt.com From: Brad Knowles Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: Debian amavisd-new at smtp502.his.com X-Spam-Status: No, score=-4.342 tagged_above=-99 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.057, BAYES_00=-2.599] X-Spam-Score: -4.342 X-Spam-Level: X-Spam-Score: -1.0 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Wed, 28 Nov 2007 08:55:11 -0500 Cc: mayer@ntp.isc.org, ntpwg@lists.ntp.org, mellon@fugue.com, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On 11/26/07, Mark Andrews wrote: > ISP's will do similar things with NTP servers. They will point > the DHCP clients to their NTP servers. SOHO routeres will just > re advertise what they learnt. No, the ISPs don't work this way. I have yet to see many ISPs that have demonstrated any capacity or interest in setting up their own NTP server. If they use NTP at all, in almost all cases they rely on external NTP servers. It is these same external servers that they would plug into their DHCP servers (because they can't be bothered to run their own NTP servers), and which would then be passed on to the clients. Which leads us to the mess that Danny is trying to help prevent. > This is a non-issue. I'm not convinced of that. -- Brad Knowles LinkedIn Profile: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 08:55:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNNi-0006Tg-9Y; Wed, 28 Nov 2007 08:55:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwwHR-0006vH-Dt for dhcwg@ietf.org; Tue, 27 Nov 2007 03:58:57 -0500 Received: from ip-64-139-1-69.sjc.megapath.net ([64.139.1.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwwHL-0004yv-0P for dhcwg@ietf.org; Tue, 27 Nov 2007 03:58:57 -0500 Received: by ip-64-139-1-69.sjc.megapath.net (Postfix, from userid 500) id 49A24BE31; Tue, 27 Nov 2007 00:58:50 -0800 (PST) Received: from glypnod (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 3D98FBE2F; Tue, 27 Nov 2007 00:58:50 -0800 (PST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: Mark Stapp From: Hal Murray Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 In-Reply-To: Message from Mark Stapp of "Mon, 26 Nov 2007 14:08:14 EST." <474B199E.3060700@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Nov 2007 00:58:49 -0800 Message-Id: <20071127085850.49A24BE31@ip-64-139-1-69.sjc.megapath.net> X-Spam-Score: 3.5 (+++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-Mailman-Approved-At: Wed, 28 Nov 2007 08:55:11 -0500 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Hal Murray X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org > I do wonder why some folks seem to think that using DNS names would > somehow be "safer" than using v6 addresses. if someone shipped a > server with a canned list of DNS names for NTP servers, there would > be a problem until the owners of the NTP servers named moved them. I > don't see how that'd be any better than the analogous mistake > involving IP addresses. I think that suggestion is coming from the NTP community rather than DHCP. Using names rather than addresses provides a layer of indirection which is a powerful tool for recovering from screwups. If Joe-Idiot hard wires 123.123.123.123 into his dumb box and then ships a zillion units, the guy who owns 123.123.123.123 is screwed. Updating the firmware on enough units to make a difference won't ever happen. If ntp.example.com gets wired in, you at least have a chance to play DNS games to distribute the load. > shipping a DHCP server with a canned configuration would not be good, > so let's hope it doesn't happen. Mark Andrews's email seems to me to > summarize what happens: 'home' routers have a dhcp client face and a > dhcp server face, and use the client to populate the server. That's another form of indirection. It seems like a sensible approach to me. On the other hand, a lot of boxes were shipped that didn't work that way. For those who haven't read it, Wikipedia has a good summary of the NTP mess: http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse This problem has code in (at least) two places: One is the DHCP server. The other is the NTP client. Either can screw it up. The examples on the Wiki page didn't involve DHCP but a simple screwup in a DHCP server could generate similar results. The obvious example is that if somebody has a NTP server address they are using for an internal NTP client and it is hard wired, they could easily use the same variable when they need something to stuff into a DHCP packet. My vote would be to add some extra wording to emphasize this area. Just saying "MUST" is too likely to get ignored. I think the key idea is that you have to be very careful if the addresses (or names) you are giving out are not on your network. As far as I can tell, all of this discussion holds for both IPv4 and IPv6. I have no strong opinions on name vs address. The extra level of indirection might be important. On the other hand, it might be simpler to cleanly document and correctly implement a system that didn't have that extra layer of complexity. -- These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 08:55:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNNh-0006TP-Lp; Wed, 28 Nov 2007 08:55:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwv1s-0000OQ-Ov for dhcwg@ietf.org; Tue, 27 Nov 2007 02:38:48 -0500 Received: from smtp102.his.com ([216.194.225.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwv1s-0008U2-C4 for dhcwg@ietf.org; Tue, 27 Nov 2007 02:38:48 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp102.his.com (Postfix) with ESMTP id 0EEDB13E42AD; Tue, 27 Nov 2007 02:38:48 -0500 (EST) Received: from smtp102.his.com ([216.194.225.125]) by localhost (smtp102.his.com [216.194.225.125]) (amavisd-new, port 10024) with ESMTP id 26136-04; Tue, 27 Nov 2007 02:38:45 -0500 (EST) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by smtp102.his.com (Postfix) with ESMTP id AC83113E42AF; Tue, 27 Nov 2007 02:38:45 -0500 (EST) Received: from [192.168.1.101] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.13.1/8.12.3) with ESMTP id lAR7ciQR091568; Tue, 27 Nov 2007 02:38:44 -0500 (EST) (envelope-from brad@shub-internet.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <47445863.4000208@cisco.com> References: <4733482A.7020302@sun.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <4743B902.3030406@udel.edu> <47445863.4000208@cisco.com> Date: Tue, 27 Nov 2007 01:32:42 -0600 To: Mark Stapp From: Brad Knowles Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: Debian amavisd-new at smtp502.his.com X-Spam-Status: No, score=-3.907 tagged_above=-99 required=5 tests=[ALL_TRUSTED=-1.8, AWL=-0.378, BAYES_00=-2.599, SUBJ_HAS_SPACES=0.87] X-Spam-Score: -3.907 X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Wed, 28 Nov 2007 08:55:11 -0500 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On 11/21/07, Mark Stapp wrote: > there seems to be a concern that delivering addresses via DHCP somehow > makes them difficult to update over time. just to reiterate: it's often > the case that the information at the DHCP server is updated. the updated > information flows out to clients as they renew. But in the case of NTP clients, that assumes that they know that there is a renewal, and that they need to update their configuration. Which seems to imply that there would need to be something in the NTP protocol standard that says something like: If you got your other-protocol-specific configuration via DHCP, then you need to make sure that you're fully DHCP-aware and that you pick up all changes when the DHCP client renews the lease. > if the lease timers were > very long, a client who got NTP addresses and found itself having > trouble with them all could also use the INFORMATION-REQUEST message to > check whether the addresses were still valid, outside of the normal > renewal timers. Which implies that the NTP client now needs to become fully DHCP aware. NTP is a weird beast. It's not like a mail or news server, which can pretty much always continue to use the same upstream server as defined in the configuration file, and never needs to worry about watching for DHCP lease renewals. NTP is one of those layer 2.5 things that doesn't have the name Cisco branded on the side, and doesn't look like a router, switch, or hub, and therefore your traditional network admins may not understand it. It also doesn't have the name Microsoft or Sun stamped on the side, and therefore your traditional host administrators aren't necessarily going to know anything about it. This is a piece of network systems infrastructure which acts as glue at the interface between the network itself and the hosts on the network, and since it's an edge case on both sides of the equation, we need to be careful in how we handle it. -- Brad Knowles LinkedIn Profile: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 09:43:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxO8a-0005P0-6j; Wed, 28 Nov 2007 09:43:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxO8Y-0005LV-RI for dhcwg@ietf.org; Wed, 28 Nov 2007 09:43:38 -0500 Received: from exprod7og109.obsmtp.com ([64.18.2.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxO8Y-00015q-Ez for dhcwg@ietf.org; Wed, 28 Nov 2007 09:43:38 -0500 Received: from source ([81.200.64.181]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Wed, 28 Nov 2007 06:43:33 PST Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 8A30A56835; Wed, 28 Nov 2007 06:43:33 -0800 (PST) (envelope-from mellon@nominum.com) X-Spam-Status: No, hits=0.0 required=8.4 tests=CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: 0.000 X-Spam-Level: Received: from [10.71.0.243] ([12.4.29.2]) (authenticated user mellon@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 28 Nov 2007 06:43:31 -0800 Message-Id: <58A01A8E-A7A8-4F79-AEDC-3D1E372F6AF0@nominum.com> From: Ted Lemon To: Danny Mayer In-Reply-To: <474CD9D2.3050405@ntp.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Wed, 28 Nov 2007 09:43:29 -0500 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> <474C855F.6080609@udel.edu> <474CD9D2.3050405@ntp.org> X-Mailer: Apple Mail (2.915) X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "ntpwg@lists.ntp.org" , "dhcwg@ietf.org WG" , Ted Lemon , "David L. Mills" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 27, 2007, at 10:00 PM, Danny Mayer wrote: > How many > of these would we expect to get if we relied on DHCP to supply those > IP > addresses. Ten. > Volunteers? There are so many of them - it's not really as easy as that. That's why I was suggesting working with cablelabs - since the last time there was a big meltdown it was a cable modem that did it, it would be good to get them on board for compliance testing. Right now, as far as I know there aren't any SOHO routers that even support the NTP option, so it's sort of a non-issue. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 10:10:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOYI-0003I2-2w; Wed, 28 Nov 2007 10:10:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOYG-0003HX-2M for dhcwg@ietf.org; Wed, 28 Nov 2007 10:10:13 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxOYE-0000Fx-Cg for dhcwg@ietf.org; Wed, 28 Nov 2007 10:10:12 -0500 Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 15:09:54 +0000 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 Subject: RE: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Wed, 28 Nov 2007 15:09:34 -0000 Message-ID: <548EC156325C6340B2E85DF90CAE8586019F24D7@E03MVB3-UKBR.domain1.systemhost.net> In-Reply-To: <58A01A8E-A7A8-4F79-AEDC-3D1E372F6AF0@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Thread-Index: AcgxziyNn2YRqTvlTRilEkJFyLPStAAAla1A From: To: , X-OriginalArrivalTime: 28 Nov 2007 15:09:54.0545 (UTC) FILETIME=[BB4DB610:01C831D0] X-Spam-Score: -1.0 (-) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Also many SOHO routers only use SNTP, so just query the first in the list they are given. Not many become a NTP server for the home network, so ALL home devices would need to have this information filtered down to them. Tony=20 -----Original Message----- From: ntpwg-bounces+anthony.flavin=3Dbt.com@lists.ntp.org [mailto:ntpwg-bounces+anthony.flavin=3Dbt.com@lists.ntp.org] On Behalf = Of Ted Lemon Sent: 28 November 2007 14:43 To: Danny Mayer Cc: ntpwg@lists.ntp.org; dhcwg@ietf.org WG; Ted Lemon Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 On Nov 27, 2007, at 10:00 PM, Danny Mayer wrote: > How many > of these would we expect to get if we relied on DHCP to supply those=20 > IP addresses. Ten. > Volunteers? There are so many of them - it's not really as easy as that. That's =20 why I was suggesting working with cablelabs - since the last time there was a big meltdown it was a cable modem that did it, it would be good to get them on board for compliance testing. Right now, as far as I know there aren't any SOHO routers that even support the NTP option, so it's sort of a non-issue. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 12:11:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxQRs-0007qL-Sx; Wed, 28 Nov 2007 12:11:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxQRs-0007pq-4r for dhcwg@ietf.org; Wed, 28 Nov 2007 12:11:44 -0500 Received: from [2001:4f8:3:bb:20c:76ff:fe16:4040] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxQRr-0006h4-Q4 for dhcwg@ietf.org; Wed, 28 Nov 2007 12:11:44 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id D71105A6EE; Wed, 28 Nov 2007 09:11:43 -0800 (PST) Date: Wed, 28 Nov 2007 09:11:43 -0800 From: "David W. Hankins" To: DHC WG Subject: Re: [dhcwg] DNSSEC in names vs. numbers for NTP server information in DHCP Message-ID: <20071128171143.GA29196@isc.org> References: <474CB98F.7050603@isc.org> Mime-Version: 1.0 In-Reply-To: <474CB98F.7050603@isc.org> User-Agent: Mutt/1.5.9i X-Spam-Score: -0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ntpwg@lists.ntp.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0031161649==" Errors-To: dhcwg-bounces@ietf.org --===============0031161649== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 28, 2007 at 01:42:55AM +0100, Shane Kerr wrote: > It seems like we have to provide IP addresses for NTP servers for this re= ason. IP addresses are no more innately secure than non-DNSSEC'd domain names. So I don't see how this is different from disabling DNSSEC validation until the clock is synchronized to the man in the middle. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHTaFPcXeLeWu2vmoRAhe1AJsHeqG3Ve1cIM3E3KHAhrOoWJ0QvQCgrGkr daiWrRErFW5v5K7fazLD5no= =njRx -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- --===============0031161649== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0031161649==-- From dhcwg-bounces@ietf.org Wed Nov 28 12:31:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxQlJ-00023M-T3; Wed, 28 Nov 2007 12:31:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxQlJ-000238-2L for dhcwg@ietf.org; Wed, 28 Nov 2007 12:31:49 -0500 Received: from [2001:4f8:3:bb:20c:76ff:fe16:4040] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxQlI-0000vf-ME for dhcwg@ietf.org; Wed, 28 Nov 2007 12:31:49 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id DA7485A6ED; Wed, 28 Nov 2007 09:31:48 -0800 (PST) Date: Wed, 28 Nov 2007 09:31:48 -0800 From: "David W. Hankins" To: DHC WG Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Message-ID: <20071128173148.GB29196@isc.org> References: <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> <474C855F.6080609@udel.edu> <474CD9D2.3050405@ntp.org> Mime-Version: 1.0 In-Reply-To: <474CD9D2.3050405@ntp.org> User-Agent: Mutt/1.5.9i X-Spam-Score: -0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: "ntpwg@lists.ntp.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2031281533==" Errors-To: dhcwg-bounces@ietf.org --===============2031281533== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 27, 2007 at 10:00:34PM -0500, Danny Mayer wrote: > This was the next question to ask of course. How many of the addresses > in the reply are cached for distribution as appropriate? With the pool Precisely as many as appear in the DNS reply. There is no upper or arbitrary limit internally, so DNS limits apply. If the query is made via TCP, I understand the DNS reply packet can be up to 64KB, of which a subset would be actual answers. Note that although the construction of the option contents from DNS names has no internal limit, the resulting data buffer may be too large to fit into a DHCP reply packet (~312 bytes, possibly another 192 bytes) particularly with other higher priority configuration values present. In this situation, the data is omitted entirely rather than truncated for inclusion. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHTaYEcXeLeWu2vmoRAsIVAKC9KkM3Ir8rfocsElYQ47tLbQPjlACfbIgP 48L3jKxcpk4kxQhaWHS8ygA= =0Yx9 -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ-- --===============2031281533== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============2031281533==-- From dhcwg-bounces@ietf.org Wed Nov 28 13:48:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxRxN-0008Fo-V2; Wed, 28 Nov 2007 13:48:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxRxN-0008Fe-0s for dhcwg@ietf.org; Wed, 28 Nov 2007 13:48:21 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxRxL-00021y-IV for dhcwg@ietf.org; Wed, 28 Nov 2007 13:48:21 -0500 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id lASImFtx030131; Wed, 28 Nov 2007 12:48:18 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 12:48:17 -0600 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 12:48:16 -0600 Message-ID: <474DB834.2030303@ericsson.com> Date: Wed, 28 Nov 2007 13:49:24 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Daniel Park Subject: Re: [dhcwg] Q for draft-krishnan-dhc-ndc-option-00 References: <0JS600DGNZT0SB@mmp1.samsung.com> In-Reply-To: <0JS600DGNZT0SB@mmp1.samsung.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2007 18:48:16.0934 (UTC) FILETIME=[3CEF9C60:01C831EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 'DHC WG' X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi Daniel, Daniel Park wrote: > one approach is not to define *Prefix Information* in your document and goes It is not clear to me what you mean here.I am pretty sure that I have not defined prefix information in the document. My goal is to avoid the exact thing you are pointing out: use two incompatible ways to do the same thing. I think this draft is something that will help us go in that direction (i.e. standardize configuration options only once). > to others ND optional information. Although it seems admin issue, I don't > think we need to have a redundant method for getting *Prefix Information*... > RFC3633 lives up to *IPv6 Prefix Configuration*. For existing DHCP and ND options that are already duplicated (prefixes, DNS...): Well, that ship has sailed, and it is upto admin policy to set the precedence as I said in my earlier mail. If you think a technical solution is possible, I would be interested in learning about it. Thanks Suresh _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 14:24:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSVy-0000K0-3b; Wed, 28 Nov 2007 14:24:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSVv-0008G9-T4 for dhcwg@ietf.org; Wed, 28 Nov 2007 14:24:03 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxSVv-0000zo-Gx for dhcwg@ietf.org; Wed, 28 Nov 2007 14:24:03 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 28 Nov 2007 14:24:02 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lASJO3Nh003888; Wed, 28 Nov 2007 14:24:03 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lASJNUC2004316; Wed, 28 Nov 2007 19:23:57 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 14:23:41 -0500 Received: from [161.44.65.179] ([161.44.65.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 14:23:41 -0500 Message-ID: <474DC03F.3020106@cisco.com> Date: Wed, 28 Nov 2007 14:23:43 -0500 From: Josh Littlefield Organization: Cisco Systems User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ted Lemon Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> <474C855F.6080609@udel.edu> <474CD9D2.3050405@ntp.org> <58A01A8E-A7A8-4F79-AEDC-3D1E372F6AF0@nominum.com> In-Reply-To: <58A01A8E-A7A8-4F79-AEDC-3D1E372F6AF0@nominum.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2007 19:23:41.0413 (UTC) FILETIME=[2F396150:01C831F4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1429; t=1196277843; x=1197141843; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=joshl@cisco.com; z=From:=20Josh=20Littlefield=20 |Subject:=20Re=3A=20[ntpwg]=20[dhcwg]=20Re=3A=20Network=20Time=20Protocol =20(NTP)=20OptionsforDHCPv6 |Sender:=20 |To:=20Ted=20Lemon=20; bh=hu/7IgiaGwJEUf9aGRMchm6Qr/FMtga6UAMhN2ZINXg=; b=pU6dRv089M9Lhika0DsNmRZXhBpOrfN7wjZ5xqeBgps+G3CmBDIsG1DmbG9PPXlsyNv3SndR M/m8wJkiKppM83Olo6EwJ6eFoXl8iIjg7mgPKUQ2TGA1H+KcIZ3Cy/1+; Authentication-Results: rtp-dkim-1; header.From=joshl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "ntpwg@lists.ntp.org" , "David L. Mills" , "dhcwg@ietf.org WG" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ted Lemon wrote: > On Nov 27, 2007, at 10:00 PM, Danny Mayer wrote: >> How many >> of these would we expect to get if we relied on DHCP to supply those IP >> addresses. > > Ten. > >> Volunteers? > > There are so many of them - it's not really as easy as that. That's > why I was suggesting working with cablelabs - since the last time > there was a big meltdown it was a cable modem that did it, it would be > good to get them on board for compliance testing. I have to ask, what would a cable modem have to do with anything. Cable modems do not use NTP (you can go read the DOCSIS spec to confirm that if you like.) CableHome and PacketCable also do not use NTP. They all use RFC 868 TOD. Perhaps you're confusing a problematic proprierary router that happens to embed a standard cable modem, with a standard cable modem. -josh > > Right now, as far as I know there aren't any SOHO routers that even > support the NTP option, so it's sort of a non-issue. > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 14:30:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSbu-00009U-Rz; Wed, 28 Nov 2007 14:30:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSbt-00008v-9a for dhcwg@ietf.org; Wed, 28 Nov 2007 14:30:13 -0500 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxSbs-0007JR-Sw for dhcwg@ietf.org; Wed, 28 Nov 2007 14:30:13 -0500 Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.10562351; Wed, 28 Nov 2007 14:29:43 -0500 Received: from NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 14:29:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Wed, 28 Nov 2007 14:28:53 -0500 Message-ID: <997BC128AE961E4A8B880CD7442D94800159BB37@NJCHLEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Thread-Index: Acgx9Et6DI1RzzuoQ7iFBvGEU1XB9AAAJ2Ne References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> <474C855F.6080609@udel.edu> <474CD9D2.3050405@ntp.org> <58A01A8E-A7A8-4F79-AEDC-3D1E372F6AF0@nominum.com> <474DC03F.3020106@cisco.com> From: "Brzozowski, John" To: "Josh Littlefield" , "Ted Lemon" X-OriginalArrivalTime: 28 Nov 2007 19:29:44.0277 (UTC) FILETIME=[07820850:01C831F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "David L. Mills" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org DOCSIS and PacketCable for certain do not use NTP. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 John Jason Brzozowski (CISSP, RHCT) Comcast Corporation e) mailto:john_brzozowski@cable.comcast.com m) 609-377-6594 p) 856-324-2671 dc) 168*45683*22 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Josh Littlefield [mailto:joshl@cisco.com] Sent: Wed 11/28/2007 2:23 PM To: Ted Lemon Cc: ntpwg@lists.ntp.org; David L. Mills; dhcwg@ietf.org WG Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) = OptionsforDHCPv6 =20 Ted Lemon wrote: > On Nov 27, 2007, at 10:00 PM, Danny Mayer wrote: >> How many >> of these would we expect to get if we relied on DHCP to supply those = IP >> addresses. > > Ten. > >> Volunteers? > > There are so many of them - it's not really as easy as that. That's > why I was suggesting working with cablelabs - since the last time > there was a big meltdown it was a cable modem that did it, it would be > good to get them on board for compliance testing. I have to ask, what would a cable modem have to do with anything. Cable modems do not use NTP (you can go read the DOCSIS spec to confirm that if you like.) CableHome and PacketCable also do not use NTP. They all use RFC 868 TOD. Perhaps you're confusing a problematic proprierary router that happens to embed a standard cable modem, with a standard cable modem. -josh > > Right now, as far as I know there aren't any SOHO routers that even > support the NTP option, so it's sort of a non-issue. > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 15:32:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxTZr-0005vR-FZ; Wed, 28 Nov 2007 15:32:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxTZq-0005qQ-28 for dhcwg@ietf.org; Wed, 28 Nov 2007 15:32:10 -0500 Received: from exprod7og105.obsmtp.com ([64.18.2.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxTZp-0000yf-MX for dhcwg@ietf.org; Wed, 28 Nov 2007 15:32:10 -0500 Received: from source ([81.200.64.181]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Wed, 28 Nov 2007 12:32:00 PST Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 60CBF56835; Wed, 28 Nov 2007 12:32:00 -0800 (PST) (envelope-from mellon@nominum.com) X-Spam-Status: No, hits=0.0 required=8.4 tests=CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: 0.000 X-Spam-Level: Received: from [10.0.1.6] ([66.108.142.160]) (authenticated user mellon@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 28 Nov 2007 12:31:58 -0800 Message-Id: From: Ted Lemon To: Josh Littlefield In-Reply-To: <474DC03F.3020106@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Wed, 28 Nov 2007 15:31:53 -0500 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> <474C855F.6080609@udel.edu> <474CD9D2.3050405@ntp.org> <58A01A8E-A7A8-4F79-AEDC-3D1E372F6AF0@nominum.com> <474DC03F.3020106@cisco.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: "ntpwg@lists.ntp.org" , "David L. Mills" , Ted Lemon , "dhcwg@ietf.org WG" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 28, 2007, at 2:23 PM, Josh Littlefield wrote: > Perhaps you're confusing a problematic proprierary router that happens > to embed a standard cable modem, with a standard cable modem. That could certainly be the case. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 15:32:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxTaH-0006RE-Dp; Wed, 28 Nov 2007 15:32:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxTaF-0006Qp-JJ for dhcwg@ietf.org; Wed, 28 Nov 2007 15:32:35 -0500 Received: from exprod7og110.obsmtp.com ([64.18.2.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxTaE-00013q-16 for dhcwg@ietf.org; Wed, 28 Nov 2007 15:32:35 -0500 Received: from source ([81.200.64.181]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Wed, 28 Nov 2007 12:32:30 PST Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 3D8A85684B; Wed, 28 Nov 2007 12:32:30 -0800 (PST) (envelope-from mellon@nominum.com) X-Spam-Status: No, hits=0.0 required=8.4 tests=CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: 0.000 X-Spam-Level: Received: from [10.0.1.6] ([66.108.142.160]) (authenticated user mellon@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 28 Nov 2007 12:32:28 -0800 Message-Id: From: Ted Lemon To: Josh Littlefield In-Reply-To: <474DC03F.3020106@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Wed, 28 Nov 2007 15:31:53 -0500 References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> <474C855F.6080609@udel.edu> <474CD9D2.3050405@ntp.org> <58A01A8E-A7A8-4F79-AEDC-3D1E372F6AF0@nominum.com> <474DC03F.3020106@cisco.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: "ntpwg@lists.ntp.org" , "David L. Mills" , Ted Lemon , "dhcwg@ietf.org WG" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 28, 2007, at 2:23 PM, Josh Littlefield wrote: > Perhaps you're confusing a problematic proprierary router that happens > to embed a standard cable modem, with a standard cable modem. That could certainly be the case. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 17:21:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVHZ-0004Ak-3b; Wed, 28 Nov 2007 17:21:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVHX-0004Af-Vr for dhcwg@ietf.org; Wed, 28 Nov 2007 17:21:24 -0500 Received: from intermail.se.dataphone.net ([212.37.1.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxVHX-0002vi-JB for dhcwg@ietf.org; Wed, 28 Nov 2007 17:21:23 -0500 Received: from [213.115.152.226] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.2) with ESMTP id 51871653 for dhcwg@ietf.org; Wed, 28 Nov 2007 23:21:21 +0100 From: Bud Millwood Organization: Weird Solutions, Inc. To: dhcwg@ietf.org Subject: Re: [dhcwg] Network Time Protocol (NTP) Options for DHCPv6 Date: Wed, 28 Nov 2007 22:35:17 +0100 User-Agent: KMail/1.8 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200711282235.17331.budm@weird-solutions.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bud Millwood List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org How many DHCP options are normally configured to point to services outside of the operator's domain? How many public SIP servers are there, for example? As a server writer I have a built-in aversion to changing the way we distribute location of services, but in this case it seems justified to use a DNS name simply because the de-facto standard, as far as I can tell, is to point clients outside the admin-controlled domain. So maybe the projected use of the service has a real bearing on this discussion. I've read this thread a little quickly, but it seems that we could end up passing multiple NTP server IP addresses to DHCP clients. If so, then the packet space argument against DNS names starts to break down the more addreses you distribute. At some point it would be less space to send the DNS name than a list of n addresses. And as for the argument that a DNS name requires a resolver on the client: how big of an issue is this, really? How many devices are really likely to want to sync their clocks over NTP but not have even a rudimentary resolver? - Bud Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 17:29:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVPU-0007WE-Ot; Wed, 28 Nov 2007 17:29:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVPS-0007W8-Ts for dhcwg@ietf.org; Wed, 28 Nov 2007 17:29:34 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxVPQ-0007CP-QB for dhcwg@ietf.org; Wed, 28 Nov 2007 17:29:34 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 28 Nov 2007 17:29:32 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lASMTWl1006694; Wed, 28 Nov 2007 17:29:32 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lASMTL0i007890; Wed, 28 Nov 2007 22:29:23 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 17:29:16 -0500 Received: from [10.86.241.216] ([10.86.241.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 17:29:16 -0500 Message-ID: <474DEBBC.4000306@cisco.com> Date: Wed, 28 Nov 2007 17:29:16 -0500 From: Mark Stapp User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Bud Millwood Subject: Re: [dhcwg] Network Time Protocol (NTP) Options for DHCPv6 References: <200711282235.17331.budm@weird-solutions.com> In-Reply-To: <200711282235.17331.budm@weird-solutions.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2007 22:29:16.0436 (UTC) FILETIME=[1C370D40:01C8320E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1744; t=1196288972; x=1197152972; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20[dhcwg]=20Network=20Time=20Protocol=20(NTP)=20Options =20for=20DHCPv6 |Sender:=20 |To:=20Bud=20Millwood=20; bh=s3QCiuXm97l340Q64Rr89kyU4OT2bGcm1B8O+hK5Wxw=; b=pI//1vcsSIyzw56DBm5h5sQcMmozXozpkjcrCfwXkS0QeI5ri44RgQh6huBjRXMGRM1GK8sP deH9o+ZB4SZUGtNW2DroY+3/jZjjQ6Vbj7KHb6jmO5rI9ZbKahzOaPcH; Authentication-Results: rtp-dkim-2; header.From=mjs@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org the suggestion's out there that it might be better if the option allowed for lists of addresses or names - or both. there do seem to be valid cases for both kinds of data: DNS names for load-balancing or use of the 'pool', addresses for situations where a resolver may not be available. -- Mark Bud Millwood wrote: > How many DHCP options are normally configured to point to services outside of > the operator's domain? How many public SIP servers are there, for example? > > As a server writer I have a built-in aversion to changing the way we > distribute location of services, but in this case it seems justified to use a > DNS name simply because the de-facto standard, as far as I can tell, is to > point clients outside the admin-controlled domain. So maybe the projected use > of the service has a real bearing on this discussion. > > I've read this thread a little quickly, but it seems that we could end up > passing multiple NTP server IP addresses to DHCP clients. If so, then the > packet space argument against DNS names starts to break down the more > addreses you distribute. At some point it would be less space to send the DNS > name than a list of n addresses. > > And as for the argument that a DNS name requires a resolver on the client: how > big of an issue is this, really? How many devices are really likely to want > to sync their clocks over NTP but not have even a rudimentary resolver? > > - Bud > > Bud Millwood > Weird Solutions, Inc. > http://www.weird-solutions.com > tel: +46 8 758 3700 > fax: +46 8 758 3687 > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 17:35:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVVQ-0003l9-Ut; Wed, 28 Nov 2007 17:35:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVVP-0003hg-O1 for dhcwg@ietf.org; Wed, 28 Nov 2007 17:35:43 -0500 Received: from exprod7og101.obsmtp.com ([64.18.2.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxVVP-0003XW-7T for dhcwg@ietf.org; Wed, 28 Nov 2007 17:35:43 -0500 Received: from source ([81.200.64.181]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Wed, 28 Nov 2007 14:35:40 PST Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 7666456840; Wed, 28 Nov 2007 14:35:40 -0800 (PST) (envelope-from mellon@nominum.com) X-Spam-Status: No, hits=0.0 required=8.4 tests=CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: 0.000 X-Spam-Level: Received: from [10.0.1.6] ([66.108.142.160]) (authenticated user mellon@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 28 Nov 2007 14:35:39 -0800 Message-Id: <384B1789-85D1-43E5-BC6C-60CD877710F4@nominum.com> From: Ted Lemon To: Bud Millwood In-Reply-To: <200711282235.17331.budm@weird-solutions.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [dhcwg] Network Time Protocol (NTP) Options for DHCPv6 Date: Wed, 28 Nov 2007 17:35:38 -0500 References: <200711282235.17331.budm@weird-solutions.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: "dhcwg@ietf.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Nov 28, 2007, at 4:35 PM, Bud Millwood wrote: > As a server writer I have a built-in aversion to changing the way we > distribute location of services, but in this case it seems justified > to use a > DNS name simply because the de-facto standard, as far as I can tell, > is to > point clients outside the admin-controlled domain. I don't know, this seems backwards to me. I think that the point of typing a configuration into a DHCP server would be a great opportunity for a network administrator to stop and think, "do we really want to point people off our network?" I think very few ISPs would deliberately make that choice - the reason they aren't currently providing NTP service is that they aren't telling people which NTP server to contact, and most users don't even know what NTP is. It's not that they have made a decision to provide NTP service using some other site's NTP server. This is a different situation from a router vendor putting a default value in, in the sense that an ISP providing configuration information is actively advising their customer to do something, whereas a router vendor is just doing it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 18:19:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWBy-0001qa-SD; Wed, 28 Nov 2007 18:19:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWBx-0001oa-P5 for dhcwg@ietf.org; Wed, 28 Nov 2007 18:19:41 -0500 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxWBx-0005M0-DZ for dhcwg@ietf.org; Wed, 28 Nov 2007 18:19:41 -0500 Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.10579892; Wed, 28 Nov 2007 18:19:29 -0500 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 18:19:29 -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 Subject: RE: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Date: Wed, 28 Nov 2007 18:19:29 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 Thread-Index: Acgx/dNBL+jweZ5BREys+aH6bjFy8gAFPBMQ References: <200711260009.lAQ092va059077@drugs.dv.isc.org><014d01c82fc6$6b1ecd70$6401a8c0@tsg1><5C093633-A256-4059-AA10-1800F62F522A@fugue.com><017901c82fd4$9cad3b70$6401a8c0@tsg1><018501c82fd7$9ff707e0$6401a8c0@tsg1> <474A521A.2090905@ntp.org> <474C855F.6080609@udel.edu><474CD9D2.3050405@ntp.org><58A01A8E-A7A8-4F79-AEDC-3D1E372F6AF0@nominum.com><474DC03F.3020106@cisco.com> From: "Woundy, Richard" To: "Ted Lemon" , "Josh Littlefield" X-OriginalArrivalTime: 28 Nov 2007 23:19:29.0447 (UTC) FILETIME=[201C0B70:01C83215] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "David L. Mills" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Looking at several of the models mentioned http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse, it appears that most (if not all of) the "cable/DSL routers" are really dual-port Ethernet routers that would sit downstream of a cable modem or DSL CPE, in the subscriber's home network. Two examples: Netgear HR314 Cable/DSL High-Speed Wireless Router http://kbserver.netgear.com/datasheets/HR314_ds_v3.pdf SMC7004VBR Barricade(tm) Cable/DSL Broadband Router http://www.smc.com/files/AN/ds_SMC7004VBR.pdf (I couldn't find the D-Link model.) These devices would look like subscriber computers from the broadband provider's perspective. Since these devices don't connect directly to the cable network, they wouldn't be tested by CableLabs for conformance to specifications like DOCSIS, because such specifications wouldn't apply. -- Rich -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Wednesday, November 28, 2007 3:32 PM To: Josh Littlefield Cc: ntpwg@lists.ntp.org; David L. Mills; Ted Lemon; dhcwg@ietf.org WG Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 On Nov 28, 2007, at 2:23 PM, Josh Littlefield wrote: > Perhaps you're confusing a problematic proprierary router that happens > to embed a standard cable modem, with a standard cable modem. That could certainly be the case. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 28 19:15:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxX44-0004JT-JO; Wed, 28 Nov 2007 19:15:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxX43-0004Iw-8X for dhcwg@ietf.org; Wed, 28 Nov 2007 19:15:35 -0500 Received: from whimsy.udel.edu ([128.4.2.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxX41-0002ap-GF for dhcwg@ietf.org; Wed, 28 Nov 2007 19:15:35 -0500 Received: by whimsy.udel.edu (Postfix, from userid 62) id B0FFA16DF; Thu, 29 Nov 2007 00:15:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id B842016DD; Thu, 29 Nov 2007 00:15:29 +0000 (UTC) Message-ID: <474E049E.5010301@udel.edu> Date: Thu, 29 Nov 2007 00:15:26 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: dhcwg@ietf.org, ntpwg@lists.ntp.org References: <474CB98F.7050603@isc.org> In-Reply-To: <474CB98F.7050603@isc.org> X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [dhcwg] Re: [ntpwg] DNSSEC in names vs. numbers for NTP server information in DHCP X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Shane, One of the reasons Autokey avoids DNS is the time issue you mention. However, so far as I know, DNS does not require absolute time, only time intervals. To authenticate DNSSEC, the certificate lifetimes must be valid, and that requires authentic time. This is something like Autokey, in that the protocol must be able to start in speculative mode and confirm success only when all the marbles are on the table. Dave Shane Kerr wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > All, > > I was reading the long, long, long thread(s) about putting NTP > information into > DHCP, and the focus on whether DHCP servers should provide names or IP > addresses > for NTP servers. > > It occurs to me that DNSSEC requires accurate time. So, we have a bit of a > bootstrapping issue if we ever decide to secure DNS zones that contain NTP > servers in them and expect clients to use the server names to find them. > > It seems like we have to provide IP addresses for NTP servers for this > reason. > > - -- > Shane > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHTLmLMsfZxBO4kbQRAvdVAJ4j3CdU7WOIobV7/1shw6nNaX+j9wCfQgY9 > Tu1+WtSfMikoNqked4ceQxc= > =WxZu > -----END PGP SIGNATURE----- > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 29 01:40:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixd4L-00078X-PV; Thu, 29 Nov 2007 01:40:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixd4J-00078C-Ex for dhcwg@ietf.org; Thu, 29 Nov 2007 01:40:15 -0500 Received: from mx05.gis.net ([208.218.130.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixd4J-0007cG-4r for dhcwg@ietf.org; Thu, 29 Nov 2007 01:40:15 -0500 Received: from [10.10.10.101] ([63.209.224.211]) by mx05.gis.net; Thu, 29 Nov 2007 01:40:01 -0500 Message-ID: <474E5E16.5060003@ntp.org> Date: Thu, 29 Nov 2007 01:37:10 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ted Lemon Subject: Re: [dhcwg] Network Time Protocol (NTP) Options for DHCPv6 References: <200711282235.17331.budm@weird-solutions.com> <384B1789-85D1-43E5-BC6C-60CD877710F4@nominum.com> In-Reply-To: <384B1789-85D1-43E5-BC6C-60CD877710F4@nominum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: "dhcwg@ietf.org" , NTP Working Group , Bud Millwood X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ted Lemon wrote: > This is a different situation from a router vendor putting a default > value in, in the sense that an ISP providing configuration information > is actively advising their customer to do something, whereas a router > vendor is just doing it. Unfortunately it looks like yet another router vendor is doing this. Information about this showed up in my email this afternoon. It's the reason that I'm so leary of just having IP addresses. It's virtually impossible to get the firmware updated in already shipped routers. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 29 09:53:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixklm-0002Q1-P3; Thu, 29 Nov 2007 09:53:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixklk-0002Oq-AN; Thu, 29 Nov 2007 09:53:36 -0500 Received: from p130.piuha.net ([2001:14b8:400::130] helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixklk-00013J-29; Thu, 29 Nov 2007 09:53:36 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 5FE59198682; Thu, 29 Nov 2007 16:53:35 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 1003619867C; Thu, 29 Nov 2007 16:53:35 +0200 (EET) Message-ID: <474ED26F.8080705@piuha.net> Date: Thu, 29 Nov 2007 16:53:35 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: ric@cisco.com, Alper Yegin Subject: SAVA arguments (Was: Re: [Int-area] Re: [dhcwg] Discussion of dhc WGrecharteringforDHCPauthentication) References: <0MKp8S-1Is4bk42Da-0005t9@mrelay.perfora.net> <473A31FF.20504@cisco.com> In-Reply-To: <473A31FF.20504@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: dhcwg@ietf.org, 'Internet Area' X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ric, Alper, "SAVA" as in the IETF effort? Or the specific approach that DSL networks use to guard against address spoofing? I think the latter... lets keep the SAVA arguments out of this discussion. There's a BOF in this IETF about this, and it is far too early to state anything about the end results. But so far all the designs we have talked about in that group for IPv6 have involved support for both stateless and DHCP. Jari _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 29 10:40:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxlUf-0002xW-7P; Thu, 29 Nov 2007 10:40:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxlUe-0002xK-Dd for dhcwg@ietf.org; Thu, 29 Nov 2007 10:40:00 -0500 Received: from web84107.mail.mud.yahoo.com ([68.142.206.194]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxlUc-0002Xw-8x for dhcwg@ietf.org; Thu, 29 Nov 2007 10:40:00 -0500 Received: (qmail 96469 invoked by uid 60001); 29 Nov 2007 15:39:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=Kbw7lrsJID5QRUxyZJHzzG84QpyfzmYPBruJUJZux81H2BGU0Ym4ELLHDA1nShftXGF5nDL/l7POc6XmErHwz0dmlIPVA8Nc3TURtHxlvtrI4D1CV91I1b+6teBy1pMnooM3Hjk2nJB+eP24Al4/gNgY0uxy5Vq0gS/aRkoSD2k=; X-YMail-OSG: ojSZGoIVM1nK2_GMOp1JApV5iPKIX9yWpMW5FeF7a954HK9.dib_0jJsv3J36hKhGI.P3ETjikhrNo1qg.s2zSmtpTZJcjuMzuArsMCukx.0q_8- Received: from [206.16.17.212] by web84107.mail.mud.yahoo.com via HTTP; Thu, 29 Nov 2007 07:39:57 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.152 Date: Thu, 29 Nov 2007 07:39:57 -0800 (PST) From: Behcet Sarikaya Subject: Re: [dhcwg] Fwd: I-D Action:draft-sarikaya-16ng-prefix-delegation-02.txt To: Ralph Droms MIME-Version: 1.0 Message-ID: <760131.96357.qm@web84107.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0685684638==" Errors-To: dhcwg-bounces@ietf.org --===============0685684638== Content-Type: multipart/alternative; boundary="0-1496209031-1196350797=:96357" --0-1496209031-1196350797=:96357 Content-Type: text/plain; charset=us-ascii Dear all, In this draft, we are proposing DHCP Relay to support DHCP Prefix Delegation. In order to do that we suggest an internal DHCP Client in DHCP Relay entity. Your comments on this will be appreciated. Regards, Behcet ----- Original Message ---- From: Ralph Droms To: dhcwg@ietf.org Sent: Saturday, November 17, 2007 10:47:57 AM Subject: [dhcwg] Fwd: I-D Action:draft-sarikaya-16ng-prefix-delegation-02.txt Might be good to get dhc WG review of this doc. - Ralph Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: November 17, 2007 11:40:02 AM EST > To: i-d-announce@ietf.org > Subject: I-D Action:draft-sarikaya-16ng-prefix-delegation-02.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Using DHCPv6 for Prefix Delegation in IEEE > 802.16 Networks > Author(s) : F. Xia, B. Sarikaya > Filename : draft-sarikaya-16ng-prefix-delegation-02.txt > Pages : 12 > Date : 2007-11-17 > > In the 802.16 Per-MS interface prefix model, one prefix can only be > assigned to one interface of a mobile station by an access router and > different mobile stations can't share a prefix. Managing Per-MS > interface prefixes is likely to increase the processing load at the > access router. Based on the idea that DHCPv6 servers can manage > prefixes as well as addresses, we propose a new technique in which > the access router offloads delegation and release tasks of the > prefixes to an DHCPv6 server. The access router first requests a > prefix for an incoming mobile station to the DHCPv6 server. The > access router next advertises the prefix information to the mobile > station with a Router Advertisement message. When the mobile station > hands off, the prefix is returned to the DHCPv6 server. We also > describe how AAA servers can help in prefix delegation. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sarikaya-16ng-prefix- > delegation-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-sarikaya-16ng-prefix-delegation-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-sarikaya-16ng-prefix-delegation-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-11-17113125.I-D\@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --0-1496209031-1196350797=:96357 Content-Type: text/html; charset=us-ascii

Dear all,
  In this draft, we are proposing DHCP Relay to support DHCP Prefix Delegation. In order to do that we suggest an internal DHCP Client in DHCP Relay entity.
  Your comments on this will be appreciated.

Regards,

Behcet

----- Original Message ----
From: Ralph Droms <rdroms@cisco.com>
To: dhcwg@ietf.org
Sent: Saturday, November 17, 2007 10:47:57 AM
Subject: [dhcwg] Fwd: I-D Action:draft-sarikaya-16ng-prefix-delegation-02.txt

Might be good to get dhc WG review of this doc.

- Ralph


Begin forwarded message:

> From: Internet-Drafts@ietf.org
> Date: November 17, 2007 11:40:02 AM EST
> To: i-d-announce@ietf.org
> Subject: I-D Action:draft-sarikaya-16ng-prefix-delegation-02.txt
> Reply-To: internet-drafts@ietf.org
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>     Title          : Using DHCPv6 for Prefix Delegation in IEEE 
> 802.16 Networks
>     Author(s)      : F. Xia, B. Sarikaya
>     Filename        : draft-sarikaya-16ng-prefix-delegation-02.txt
>     Pages          : 12
>     Date            : 2007-11-17
>
> In the 802.16 Per-MS interface prefix model, one prefix can only be
> assigned to one interface of a mobile station by an access router and
> different mobile stations can't share a prefix.  Managing Per-MS
> interface prefixes is likely to increase the processing load at the
> access router.  Based on the idea that DHCPv6 servers can manage
> prefixes as well as addresses, we propose a new technique in which
> the access router offloads delegation and release tasks of the
> prefixes to an DHCPv6 server.  The access router first requests a
> prefix for an incoming mobile station to the DHCPv6 server.  The
> access router next advertises the prefix information to the mobile
> station with a Router Advertisement message.  When the mobile station
> hands off, the prefix is returned to the DHCPv6 server.  We also
> describe how AAA servers can help in prefix delegation.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-sarikaya-16ng-prefix-
> delegation-02.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
>     "get draft-sarikaya-16ng-prefix-delegation-02.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>     mailserv@ietf.org.
> In the body type:
>     "FILE /internet-drafts/draft-sarikaya-16ng-prefix-delegation-02.txt".
>
> NOTE:  The mail server at ietf.org can return the document in
>     MIME-encoded form by using the "mpack" utility.  To use this
>     feature, insert the command "ENCODING mime" before the "FILE"
>     command.  To decode the response(s), you will need "munpack" or
>     a MIME-compliant mail reader.  Different MIME-compliant mail readers
>     exhibit different behavior, especially when dealing with
>     "multipart" MIME messages (i.e. documents which have been split
>     up into multiple messages), so check your local documentation on
>     how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <2007-11-17113125.I-D\@ietf.org>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/i-d-announce

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

--0-1496209031-1196350797=:96357-- --===============0685684638== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0685684638==-- From dhcwg-bounces@ietf.org Thu Nov 29 11:02:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxlqR-0006pe-9a; Thu, 29 Nov 2007 11:02:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxlqP-0006pH-Ki for dhcwg@ietf.org; Thu, 29 Nov 2007 11:02:29 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxlqN-0006Gc-IW for dhcwg@ietf.org; Thu, 29 Nov 2007 11:02:29 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=R38GWGZOS5nuE/Z0sxc+XzRsD6FqwG3blEqXH25/Zscpa/8fv35AUfjhf3uIuWB1; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IxlqI-000237-CB; Thu, 29 Nov 2007 11:02:22 -0500 Message-ID: <002a01c832a1$39e9b480$6501a8c0@tsg1> From: "TS Glassey" To: "Danny Mayer" , References: <474CB98F.7050603@isc.org> <474CECCD.6090707@ntp.org> Subject: Re: [ntpwg] [dhcwg] DNSSEC in names vs. numbers for NTP server information in DHCP Date: Thu, 29 Nov 2007 07:56:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79a05707572786dd486d936b2bb8d982d3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Shane/Danny As another possible solution here, let me ask, would it make sense to also setup a default Multicast type configuration for use in sites that support pre-host registration*** through DHCP... It seems like as setting the DHCP server itself could be peered with the NTP Server they represent, and as such it itself could serve a dual role, not per se setting open-client requests through NTP but through the DHCP listener. If the intent is to provide an unsecured time source for calibrating the operating clocks of un-plumbed hosts, then perhaps a multicast type deployment would work through DHCP for this. Also DHCP could easily be setup to do a two layer process, wherein it presets the client to a 'rudimentary' state where it could communicate with an authentication server to qualify and permit its entrance into a network. FWIW - I have an updated I-D for DHCP which adds this two layer process, and the security model it produces is pretty strong. If anyone is interested drop me a note offlist and I will send it to you. Todd Glassey ----- Original Message ----- From: "Danny Mayer" To: Cc: ; Sent: Tuesday, November 27, 2007 8:21 PM Subject: Re: [ntpwg] [dhcwg] DNSSEC in names vs. numbers for NTP server information in DHCP > Shane Kerr wrote: >> All, >> >> I was reading the long, long, long thread(s) about putting NTP >> information into >> DHCP, and the focus on whether DHCP servers should provide names or IP >> addresses >> for NTP servers. >> >> It occurs to me that DNSSEC requires accurate time. So, we have a bit of >> a >> bootstrapping issue if we ever decide to secure DNS zones that contain >> NTP >> servers in them and expect clients to use the server names to find them. >> >> It seems like we have to provide IP addresses for NTP servers for this >> reason. >> > > I'm not sure which hat to wear on this one. The first question is > 1) how accurate? Within 5 minutes like TSIG? > 2) I assume that this is both ends relative to each other? > > We always had a bootstrapping issue. It's only now becoming obvious. I > had mentioned this in a previous message. One way of avoiding the > accurate time issue is to use a refclock on the system and have NTP get > its time from there. > > There are actually three different parts of this: > 1) DNS Servers using DNSSEC for the zone in which they are authorative > These will have static IP addresses and DHCP would presumably not be > involved (though no doubt can provide other data). I would expect that > it would be set up manually to have ntpd to use servers specified by the > sysadmin. > > 2) Caching DNSSEC-aware servers > These are presumably the servers responsible for supplying the answers > to the ultimate clients. These would also presumably have static IP > addresses and not use DHCP. They too could be manually configured to use > NTP from their own resources but could conceivably get information from > DHCP servers. > > 3) The clients themselves using a DNSSEC-enabled resolver. These are > likely to be provisioned with IP addresses, DNS server addresses, etc. > and presumably get their information from DHCP. These clients are the > most vunerable since presumably the NTP server would be provisioned by > DHCP which would need to make sure that they receive authenticated data. > That's the chicken and egg problem since they presumably need an > accurate time before communicating with the DHCP server to get > information about the NTP server addresses to use. If you are concerned > enough to use DNSSEC you presumably are concerned enough to use only > authenticatable NTP servers and that means using autokey protocol (now > in IETF draft). That requires a key and it needs to be distributed OOB. > The key could potentially be distributed by DHCP but you also need to > protect the key from modification in flight which presumably needs DHCP > authenticationc and encryption if that's the distribution method. The > trick here is to figure out which piece to set up first. > > Ideas? > > Danny > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 29 11:06:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixluk-0001sW-SN; Thu, 29 Nov 2007 11:06:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixluk-0001p7-7K for dhcwg@ietf.org; Thu, 29 Nov 2007 11:06:58 -0500 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixlui-00072y-Bv for dhcwg@ietf.org; Thu, 29 Nov 2007 11:06:58 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=A4o57OpyUSuAujYfA0p2DP30vRkIlpNjupqN161zCiS2yDj56dMo/OD6dhkmA8IH; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IxluQ-0007qo-IW; Thu, 29 Nov 2007 11:06:38 -0500 Message-ID: <003401c832a1$d2bc2c10$6501a8c0@tsg1> From: "TS Glassey" To: "Masataka Ohta" , References: <474CB98F.7050603@isc.org> <474CBDD3.6060908@necom830.hpcl.titech.ac.jp> Subject: Re: [ntpwg] [dhcwg] DNSSEC in names vs. numbers for NTP server information in DHCP Date: Thu, 29 Nov 2007 08:06:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79c57d546b97c38ccacaa582bc764b67f4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Ohta-san, ----- Original Message ----- From: "Masataka Ohta" To: Cc: ; Sent: Tuesday, November 27, 2007 5:01 PM Subject: Re: [ntpwg] [dhcwg] DNSSEC in names vs. numbers for NTP server information in DHCP > Shane Kerr wrote: > >> It occurs to me that DNSSEC requires accurate time. > > DNSSEC requires *SECURE* accurate time. yes. > >> It seems like we have to provide IP addresses for NTP servers for this >> reason. Not necessarily, but rather a secured timesetting event which operated inside the DHCP process context. > > It is required that DHCP clients and NTP servers allocated by DHCP > *SECURELY* share some information for the DHCP clients authenticate > the NTP servers. meaning that the DHCP Server itself should also double as the NTP Server for its client only. That is the best solution possible with the way DHCP works now. > > It, in practice, means shared authentication information must be hand > configured in the DHCP clients and associated NTP servers, which > means there is no need for DHCP service provide NTP server for secure > DNS. yes it would. The idea that the DHCP server also double for setting the time of day of the requesting DHCP client is a good idea too. > > Masataka Ohta > > PS > > Still, secure DNS is only weakly secure , that is, as secure as > plain DNS that there is no reason to deploy it. That is, just as > plain DNS is vulnerable to compromised intermediate entities such > as ISPs or zone admins, secure DNS is vulnerable to compromised > intermediate entities of zone admins or NTP servers. > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 29 12:37:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxnK2-0005LL-5r; Thu, 29 Nov 2007 12:37:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxnK0-0005Kv-IC for dhcwg@ietf.org; Thu, 29 Nov 2007 12:37:09 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxnJz-0004qR-Bi for dhcwg@ietf.org; Thu, 29 Nov 2007 12:37:08 -0500 X-IronPort-AV: E=Sophos;i="4.23,230,1194217200"; d="scan'208";a="159156589" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Nov 2007 18:37:02 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lATHb2db017431; Thu, 29 Nov 2007 18:37:02 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lATHax3Z019738; Thu, 29 Nov 2007 17:36:59 GMT Received: from xmb-ams-331.cisco.com ([144.254.231.76]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 18:36:59 +0100 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 Subject: RE: [ntpwg] [dhcwg] Network Time Protocol (NTP) OptionsforDHCPv6 Date: Thu, 29 Nov 2007 18:36:58 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ntpwg] [dhcwg] Network Time Protocol (NTP) OptionsforDHCPv6 Thread-Index: Acgx/dNBL+jweZ5BREys+aH6bjFy8gAFPBMQACbhibA= References: From: "Richard Gayraud (rgayraud)" To: , X-OriginalArrivalTime: 29 Nov 2007 17:36:59.0879 (UTC) FILETIME=[72068F70:01C832AE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9156; t=1196357822; x=1197221822; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rgayraud@cisco.com; z=From:=20=22Richard=20Gayraud=20(rgayraud)=22=20 |Subject:=20RE=3A=20[ntpwg]=20[dhcwg]=20Network=20Time=20Protocol=20(NTP) =20OptionsforDHCPv6 |Sender:=20; bh=8G91nbpB4pm5IwXR7qKnKyebK21Y9F9jBy/kO5CCHm4=; b=BBCDB34cnkuicILQ/zQcZZ5U7+7qhb6pyf2UOmzNrE67fTZG4huRamu5XOpJvkOC/K1LUz5Z iYux6IofwDuvsyEJoeXwed+GErXcYjHV0ViOdelhtRw5PiVhf09SDapo; Authentication-Results: ams-dkim-1; header.From=rgayraud@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hello All, Thank you very much for all your comments about our draft.=20 Benoit and I did not expect such a passionate discussion when we=20 submitted it 3 weeks ago. With this email, I would like to summarize the current=20 situation, objections, issues, and possible solutions. We will=20 try to take into account as much as possible of the remarks and=20 questions. The possibility of an increased risk of catastrophic=20 event will be considered very carefully and will be mitigated. First of all, I would like to expose again the motivation for=20 this work (I believe there was some confusion about the=20 rationale for it): System administrators like to configure a large number of hosts=20 from a centralized DHCP server. Today, DHCP is a protocol of=20 choice for remote configuration of IP hosts. DHCPv6 is lacking=20 the ability to configure NTP clients. This is our main=20 motivation. So, this work is not intended to address some=20 hypothetical NTP requirement to improve its peer discovery=20 mechanisms. Instead, this work is intended to address a DHCPv6=20 need to include NTP configuration. In other words, we are=20 working in the context of DHCPv6, to make it more comprehensive.=20 One may argue that some other protocol than DHCP might be more=20 suitable for this, but our precise purpose is to extend DHCPv6=20 expressiveness. This is not a replacement for existing NTP configuration=20 mechanisms. This will simplify the work of system administrators=20 (or ISPs) by allowing global, remote configuration of NTP=20 clients, instead of individual, per-host configuration of the=20 ntpd.conf file.=20 We try to be implementation agnostic. As someone mentioned,=20 the parameters we selected exist in the reference implementation, but they are also clearly defined as part of the NTPv4=20 specification. The relevance of these parameters in DHCP=20 will be discussed. Some of will be removed, some will be added=20 (I encourage people in the NTP WG to propose some other useful=20 parameters). All depends on the level of expressiveness we want=20 to give to DHCP regarding NTP. In any case, all parameters will=20 be optional (in the same way they are in ntpd.conf). Only the=20 server identity will be required (IP address or FQDN depending=20 on the outcome of the discussion about this). That being said, I tried to collect all the issues you raised in=20 a sort of 'dashboard' that I will update. =09 Issue #1: DHCPv6 NTP option may trigger some catastrophic event --------------------------------------------------------------- This is similar to what happened in the past with hardcoded NTP=20 servers IP addresses in SOHO routers. We can imagine that a=20 badly designed SOHO equipment with an embedded DHCP server would=20 advertise a hardcoded address over the SOHO LAN. There has been=20 no consensus yet about the validity of this scenario: - Some people think adding the possibility to carry an FQDN=20 instead of an IP address will solve this, - Others think FQDN will not solve the issue but move it to the=20 DNS system, (though it might reduce the amplitude of the issue=20 due to the distributed nature of DNS), - Others think this is a non-issue as DHCP servers in SOHO=20 equipments only redistribute information they got from their=20 client side. Bigger DHCP servers are manually configured.=20 =20 The same problem would happen to DNS servers if SOHO equipments=20 would contain hardcoded DNS servers addresses. But in the case=20 of DNS, DHCP have contributed to avoid the issue rather than=20 amplifying it (please refer to the 2 messages Mark Andrews sent on sunday and monday for details). Unless we all agree with Mark Andrews that this is a non-issue,=20 we need to fully understand the exact use case involved if this=20 problem can happen, and provide a way to avoid it. Next week=20 discussions might be a good opportunity to clarify this. =3D> Possible solutions include: - use of FQDN, - add clear statement an NTP server IP address MUST NOT be=20 hardcoded in a DHCP servers, unless it points to an equipments=20 operated by the vendor. describe the risk in the document=20 itself - mandatory use of FQDN ? - aren't KOD packets part of the solution ? (This draft only=20 addresses NTPv4 clients with IPv6 connectivity). Maybe we=20 can enforce support for KOD for clients supporting DHCP NTP=20 configuration. Issue #2: Use of FQDN should be allowed for DNS indirection ----------------------------------------------------------- Regardless the outcome of Issue #1, there seems to be some=20 interest in the community to carry either an IP address or an=20 FQDN (ntpd.conf also offers FQDN as a way to specify server=20 identity). We could re-define the option syntax to use sub-options. FQDN=20 and Server address being 2 possible sub-options. Other=20 parameters (if suitable) could also be defined as sub-options. Issue #3: Irrelevant parameters (maxpoll/minpoll/burst/iburst) -------------------------------------------------------------- When writing the first version of this draft, one of our goals=20 was to allow better control of the tradeoff between NTP clock=20 precision and traffic generated over a LAN. IPv6 has a large=20 address space, and an IPv6 subnet can contain a huge number of=20 hosts. Thus, it may be suitable to reduce the amount of traffic=20 generated by NTP clients. On the other hand, some deployments=20 may require fast and precise clock synchronization. Hence the=20 Maxpoll, Minpoll, Burst and IBurst parameters. Again, these are=20 not mandatory and will rarely be used. - some people says you have to be an expert to set these=20 parameters and these should not be opened. =3D> I do not understand why theworkstation users (controlling=20 their individual ntpd.conf file) would be more skilled to=20 set these parameters than network administrators (controlling the DHCP server)?=20 If some parameter is questionable in a DHCP option, I think it=20 is also questionable as an ntpd.conf option. Isn't it? I do remember examples of customers requesting that their NTP=20 clients quickly sync (and acquire time) on startup. If the network=20 administrator wants NTP this kind of behavior, he will set the=20 Burst flag to reach fast NTP convergence. Anything I missed here? Issue #4: "maxpoll is useless" ------------------------------ Even people who like additional parameters, agree to say that=20 maxpoll is useless (Brian, Dave). Could you explain why this is=20 useless?. Issue #5: "delay is useless" ---------------------------- The delay field serves as a trigger to enable/disable the=20 client volley in multicast mode. Again, I don't understand why=20 this is useless. The goal of this parameter is not to have the=20 DHCP server to measure the network delay. It is simply to allow=20 the network administrator to manually configure a constant delay=20 to compensate for having no volley (please refer to =20 http://www.cis.udel.edu/~mills/ntp/html/confopt.html where the 'broadcastdelay' option has a similar purpose). I believe the=20 default 4ms might not be suitable for all network topologies. Issue #6: "multiple instances versus list of addresses" ------------------------------------------------------- The use of multiple instances of the same DHCP option to=20 advertise several NTP servers seems to be somewhat confusing.=20 Depending on the decision made for other issues, we will=20 probably change the syntax of the options (or sub-options if=20 any). Having a list of "struct" or "records" is not usual in DHCP and=20 it is not guaranteed that implementations will support it. This=20 is why we opted for the simpler "multiple instances option" as=20 we have some per-server configuration parameters (Key-ID, issue=20 #7, might become another one). Any suggestion for a better=20 syntax allowing a list of "struct" to be carried over DHCPv6 is=20 welcome. The sub-option syntax would enable easier future evolutions, but=20 it seems difficult to use it to attach per-server parameters like Burst or Key-ID (unless we consider the order of sub-options to=20 be relevant, which is a bit weird, isn't it?). Issue #7: Key ID ---------------- Some people suggest it might be useful to carry a Key ID with=20 each server name/address. There is no opposition to this I=20 believe. =09 Issue #8: Carrying an URL for a config file ------------------------------------------- This has been suggested a few times, but has 2 major drawbacks: - It requires the client to be ftp/tftp/http-enabled (a lot=20 of complexity on the client), =20 - It would be implementation dependant, If sub-options are used in the DHCP message, we will certainly=20 have the same level of flexibility.=20 ---- Please tell me if I made any mistakes, I would like to converge=20 on a comprehensive list of issues. Thanks you very much, Richard. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 29 14:21:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxoxM-0000tJ-RJ; Thu, 29 Nov 2007 14:21:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxoxL-0000iY-Dz for dhcwg@ietf.org; Thu, 29 Nov 2007 14:21:51 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxoxK-0001PC-JX for dhcwg@ietf.org; Thu, 29 Nov 2007 14:21:51 -0500 Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lATJLmwX010852; Thu, 29 Nov 2007 19:21:48 GMT Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lATJLliX041111; Thu, 29 Nov 2007 14:21:48 -0500 (EST) Message-ID: <474F114B.10806@sun.com> Date: Thu, 29 Nov 2007 14:21:47 -0500 From: Brian Utterback User-Agent: Thunderbird 2.0.0.10pre (X11/20071125) MIME-Version: 1.0 To: "Richard Gayraud (rgayraud)" Subject: Re: [ntpwg] [dhcwg] Network Time Protocol (NTP) OptionsforDHCPv6 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Richard Gayraud (rgayraud) wrote: > Issue #3: Irrelevant parameters (maxpoll/minpoll/burst/iburst) > -------------------------------------------------------------- > > When writing the first version of this draft, one of our goals > was to allow better control of the tradeoff between NTP clock > precision and traffic generated over a LAN. IPv6 has a large > address space, and an IPv6 subnet can contain a huge number of > hosts. Thus, it may be suitable to reduce the amount of traffic > generated by NTP clients. On the other hand, some deployments > may require fast and precise clock synchronization. Hence the > Maxpoll, Minpoll, Burst and IBurst parameters. Again, these are > not mandatory and will rarely be used. > > - some people says you have to be an expert to set these > parameters and these should not be opened. > > => I do not understand why theworkstation users (controlling > their individual ntpd.conf file) would be more skilled to > set these parameters than network administrators (controlling > the DHCP server)? The ntp.conf file is overly flexible for most users and gives more than enough rope to hang yourself mightily if youstart to stray from the usual settings. We strongly discourage the use of maxpoll and minpoll by naive users. Likewise you should never configure burst unless you know what you are doing. On the other hand, you should probably always configure iburst and I suspect that it will someday morph into a noiburst option with iburst being the default. > > If some parameter is questionable in a DHCP option, I think it > is also questionable as an ntpd.conf option. Isn't it? Yep. There are a boat load of questionable parameters in the ntp.conf file. > > I do remember examples of customers requesting that their NTP > clients quickly sync (and acquire time) on startup. If the network > administrator wants NTP this kind of behavior, he will set the > Burst flag to reach fast NTP convergence. Anything I missed here? That would be iburst, not burst. > > > Issue #4: "maxpoll is useless" > ------------------------------ > > Even people who like additional parameters, agree to say that > maxpoll is useless (Brian, Dave). Could you explain why this is > useless?. Two reasons. First, the general reason that you should not be specifying minpoll and maxpoll, is that it is unnecessary and detrimental to the time keeping. Any reasonable client will use the optimum polling period. Shorter poll intervals do not necessarily give you more accuracy, nor longer ones less. There is an optimum poll period that the client calculates and given the likely round trip times in most DHCP configurations, that optimum will already be in between the current min and max polls. While having a minpoll makes a bit of sense, (i.e. do not poll more often then *this*) maxpoll doesn't make sense at all. If you lower it, then you are saying "do not poll less often than *this*, even though you would like to." This is essentially saying to use more resources than you would like to, so that you get lower quality time synch. Making the maxpoll higher than the default likewise doesn't make much sense, since it is unlikely that the clients will get higher than the default anyway. As long as the clients are in between the min and max, it is best to let them do their own thing. > > > Issue #5: "delay is useless" > ---------------------------- > > The delay field serves as a trigger to enable/disable the > client volley in multicast mode. Again, I don't understand why > this is useless. The goal of this parameter is not to have the > DHCP server to measure the network delay. It is simply to allow > the network administrator to manually configure a constant delay > to compensate for having no volley (please refer to > http://www.cis.udel.edu/~mills/ntp/html/confopt.html where the > 'broadcastdelay' option has a similar purpose). I believe the > default 4ms might not be suitable for all network topologies. Well, the problem is that the correct delay could be different for different clients, and is difficult to determine by hand. I am conflicted. While I agree it would be nice to be able to tell the clients not to volley, you can't easily get the right value, meaning you should probably allow the client to volley. -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 29 14:32:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixp7b-0001jC-DY; Thu, 29 Nov 2007 14:32:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixp7a-0001j5-DR for dhcwg@ietf.org; Thu, 29 Nov 2007 14:32:26 -0500 Received: from smtp102.his.com ([216.194.225.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixp7Z-0003D8-FV for dhcwg@ietf.org; Thu, 29 Nov 2007 14:32:26 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp102.his.com (Postfix) with ESMTP id 3793513E42EE; Thu, 29 Nov 2007 14:32:25 -0500 (EST) Received: from smtp102.his.com ([216.194.225.125]) by localhost (smtp102.his.com [216.194.225.125]) (amavisd-new, port 10024) with ESMTP id 06842-05; Thu, 29 Nov 2007 14:32:22 -0500 (EST) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by smtp102.his.com (Postfix) with ESMTP id 3305813E42E4; Thu, 29 Nov 2007 14:32:22 -0500 (EST) Received: from [192.168.1.101] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.13.1/8.12.3) with ESMTP id lATJWItu093107; Thu, 29 Nov 2007 14:32:21 -0500 (EST) (envelope-from brad@shub-internet.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 29 Nov 2007 13:31:56 -0600 To: "Richard Gayraud (rgayraud)" , , From: Brad Knowles Subject: Re: [ntpwg] [dhcwg] Network Time Protocol (NTP) OptionsforDHCPv6 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: Debian amavisd-new at smtp502.his.com X-Spam-Status: No, score=-4.342 tagged_above=-99 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.057, BAYES_00=-2.599] X-Spam-Score: -4.342 X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On 11/29/07, Richard Gayraud (rgayraud) wrote: > - aren't KOD packets part of the solution ? (This draft only > addresses NTPv4 clients with IPv6 connectivity). Maybe we > can enforce support for KOD for clients supporting DHCP NTP > configuration. Unfortunately, many clients ignore KOD. We can't depend on this being the ultimate saviour in UWisc-type events. > Issue #3: Irrelevant parameters (maxpoll/minpoll/burst/iburst) > -------------------------------------------------------------- > > When writing the first version of this draft, one of our goals > was to allow better control of the tradeoff between NTP clock > precision and traffic generated over a LAN. IPv6 has a large > address space, and an IPv6 subnet can contain a huge number of > hosts. Thus, it may be suitable to reduce the amount of traffic > generated by NTP clients. On the other hand, some deployments > may require fast and precise clock synchronization. Hence the > Maxpoll, Minpoll, Burst and IBurst parameters. Again, these are > not mandatory and will rarely be used. As I see it, the bigger problem is that there is an amazing amount of potential complexity in the configuration file syntax of the Reference Implementation, and 99.99% of sites don't need that much complexity. Therefore, I believe it would be a serious mistake to try to encode any significant amount of that complexity into DHCP. Moreover, since the configuration file syntax is not standardized in an RFC (as the NTP protocol is), you would be encoding a proprietary implementation into your protocol standard. I think the IETF should be violently opposed to doing such a thing. > => I do not understand why theworkstation users (controlling > their individual ntpd.conf file) would be more skilled to > set these parameters than network administrators (controlling > the DHCP server)? They wouldn't. > If some parameter is questionable in a DHCP option, I think it > is also questionable as an ntpd.conf option. Isn't it? This isn't a transitive case. A implies B and C implies D does not necessarily mean that A implies D. The difference is that we have an entire file to work with, and it's up to us how complex to make that process. We're not trying to encode everything into 512 bits, or even just the "important" parts. We're also not trying to publish the syntax for all NTP clients as an RFC -- this is just our own internal proprietary implementation, and doesn't have anything to do with the NTP protocol standard. Other NTP clients are welcome to support a similar syntax (if they like), or they could do something totally different. So long as they properly implement the protocol itself, it shouldn't matter what configuration file options and syntax they use. > I do remember examples of customers requesting that their NTP > clients quickly sync (and acquire time) on startup. If the network > administrator wants NTP this kind of behavior, he will set the > Burst flag to reach fast NTP convergence. Anything I missed here? Using "burst" is inherently bad, unless you own all the resources on both sides of the table, and even then it's probably not such a good idea in most cases. This is not a nuclear weapon you want to give to J. Random Network Admin, or J. Random Embedded Vendor, or anyone else for that matter. Using "iburst" is generally considered to be okay, since it only does a burst of packets on startup, and then operates normally afterwards. But in this case, we could argue that we could safely assume that iburst should be used in all DHCPv6-derived client configurations, and simply drop the entire "burst" or "iburst" configuration option altogether. In fact, I would argue that most of the configuration options are unlikely to be useful in the general case. They have accumulated over the decades as the protocol and the Reference Implementation have evolved, mostly to solve one or another edge case, and over the decades we've had a lot of these edge cases. In some circumstances, after years of experience with the NTP protocol as it has evolved, and the Reference Implementation and how it has evolved, we've concluded that the assumptions we made years ago are no longer valid. However, we're caught in a straight-jacket that we created for ourselves at the time because we could not see the potential need for any other view of the situation at that point. So, we have a lot of legacy cruft that has accumulated. I really don't think that you want to try to incorporate our old legacy cruft into your new protocol standard. Keep in mind that the legacy cruft I'm talking about doesn't have anything to do with the NTP protocol itself, it has to do with certain assumptions at various different points in the code that implements the operations related to the protocol, and other clients or servers could easily make different assumptions and yet still have fully interoperable implementations of the NTP protocol standard. > Issue #6: "multiple instances versus list of addresses" > ------------------------------------------------------- > > The use of multiple instances of the same DHCP option to > advertise several NTP servers seems to be somewhat confusing. > Depending on the decision made for other issues, we will > probably change the syntax of the options (or sub-options if > any). I'm not getting this point at all. Can you elaborate? > Issue #8: Carrying an URL for a config file > ------------------------------------------- > > This has been suggested a few times, but has 2 major drawbacks: > > - It requires the client to be ftp/tftp/http-enabled (a lot > of complexity on the client), > > - It would be implementation dependant, This is part of why I like the idea of a Simple NTP Configuration Service. I believe it could be much simpler and easier to implement than FTP, TFTP, or HTTP. And it would let us keep all the NTP configuration complexity outside of the DHCP protocol. > If sub-options are used in the DHCP message, we will certainly > have the same level of flexibility. Um, I don't think that your DHCP messages can be as long as our configuration files. I wouldn't make any claims about your ability to have the same level of flexibility unless you want to include the full syntax of the proprietary configuration files that we support in the Reference Implementation. I'm not sure how that lexer and parser are built, but I imagine it shouldn't be a problem to contribute that to a willing recipient project. That said, I really don't think you want to try to implement anything remotely close to the full complexity of our configuration files, and I really don't think you want to implement anything that does not have it's own IETF standards-track RFC to guide you and associated working group with which to liaise. Since none of the configuration file options you've mentioned have anything to do with the NTP protocol per se, I think you'd at least need to wait until some group takes up the task of standardizing the configuration file options and syntax for all NTP servers and clients -- including, but not limited to, the Reference Implementation. There's one common theme here: Standard Protocol != Proprietary Configuration File Options/Syntax One of these you can work with and interface with as part of your standard. The other, I don't think so. You don't encode Cisco router configuration file syntax into the DHCP standard (do you?), and I wouldn't suggest trying to do the same for NTP or the NTP Reference Implementation. -- Brad Knowles LinkedIn Profile: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 29 14:37:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxpBy-0002h5-Fi; Thu, 29 Nov 2007 14:36:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxpBx-0002gu-9u for dhcwg@ietf.org; Thu, 29 Nov 2007 14:36:57 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxpBv-0003X2-Vr for dhcwg@ietf.org; Thu, 29 Nov 2007 14:36:56 -0500 Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 19:36:55 +0000 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 Subject: RE: [ntpwg] [dhcwg] Network Time Protocol (NTP) OptionsforDHCPv6 Date: Thu, 29 Nov 2007 19:37:10 -0000 Message-ID: <548EC156325C6340B2E85DF90CAE8586019F2CE4@E03MVB3-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ntpwg] [dhcwg] Network Time Protocol (NTP) OptionsforDHCPv6 Thread-Index: AcgyvrnxKXfc3K+sQy6AcBF7s2JXJAAAECrg From: To: , , , X-OriginalArrivalTime: 29 Nov 2007 19:36:55.0521 (UTC) FILETIME=[32F66510:01C832BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org And not easy to implement where you have many thousands of clients as you have to monitor each one individually to determine whether it is behaving correctly and hence whether to send it the KOD. Tony Flavin -----Original Message----- From: ntpwg-bounces+anthony.flavin=3Dbt.com@lists.ntp.org [mailto:ntpwg-bounces+anthony.flavin=3Dbt.com@lists.ntp.org] On Behalf = Of Brad Knowles Sent: 29 November 2007 19:32 To: Richard Gayraud (rgayraud); ntpwg@lists.ntp.org; dhcwg@ietf.org Subject: Re: [ntpwg] [dhcwg] Network Time Protocol (NTP) OptionsforDHCPv6 On 11/29/07, Richard Gayraud (rgayraud) wrote: > - aren't KOD packets part of the solution ? (This draft only > addresses NTPv4 clients with IPv6 connectivity). Maybe we > can enforce support for KOD for clients supporting DHCP NTP > configuration. Unfortunately, many clients ignore KOD. We can't depend on this being the ultimate saviour in UWisc-type events. > Issue #3: Irrelevant parameters (maxpoll/minpoll/burst/iburst) > -------------------------------------------------------------- > > When writing the first version of this draft, one of our goals was=20 > to allow better control of the tradeoff between NTP clock precision=20 > and traffic generated over a LAN. IPv6 has a large address space, and > an IPv6 subnet can contain a huge number of hosts. Thus, it may be=20 > suitable to reduce the amount of traffic generated by NTP clients. On > the other hand, some deployments may require fast and precise clock=20 > synchronization. Hence the Maxpoll, Minpoll, Burst and IBurst=20 > parameters. Again, these are not mandatory and will rarely be used. As I see it, the bigger problem is that there is an amazing amount of potential complexity in the configuration file syntax of the Reference Implementation, and 99.99% of sites don't need that much complexity. Therefore, I believe it would be a serious mistake to try to encode any significant amount of that complexity into DHCP. Moreover, since the configuration file syntax is not standardized in an RFC (as the NTP protocol is), you would be encoding a proprietary implementation into your protocol standard. I think the IETF should be violently opposed to doing such a thing. > =3D> I do not understand why theworkstation users (controlling > their individual ntpd.conf file) would be more skilled to > set these parameters than network administrators (controlling > the DHCP server)? They wouldn't. > If some parameter is questionable in a DHCP option, I think it is=20 > also questionable as an ntpd.conf option. Isn't it? This isn't a transitive case. A implies B and C implies D does not necessarily mean that A implies D. The difference is that we have an entire file to work with, and it's up to us how complex to make that process. We're not trying to encode everything into 512 bits, or even just the "important" parts. We're also not trying to publish the syntax for all NTP clients as an RFC -- this is just our own internal proprietary implementation, and doesn't have anything to do with the NTP protocol standard. Other NTP clients are welcome to support a similar syntax (if they like), or they could do something totally different. So long as they properly implement the protocol itself, it shouldn't matter what configuration file options and syntax they use. > I do remember examples of customers requesting that their NTP =20 > clients quickly sync (and acquire time) on startup. If the network =20 > administrator wants NTP this kind of behavior, he will set the Burst=20 > flag to reach fast NTP convergence. Anything I missed here? Using "burst" is inherently bad, unless you own all the resources on both sides of the table, and even then it's probably not such a good idea in most cases. This is not a nuclear weapon you want to give to J. Random Network Admin, or J. Random Embedded Vendor, or anyone else for that matter. Using "iburst" is generally considered to be okay, since it only does a burst of packets on startup, and then operates normally afterwards.=20 But in this case, we could argue that we could safely assume that iburst should be used in all DHCPv6-derived client configurations, and simply drop the entire "burst" or "iburst" configuration option altogether. In fact, I would argue that most of the configuration options are unlikely to be useful in the general case. They have accumulated over the decades as the protocol and the Reference Implementation have evolved, mostly to solve one or another edge case, and over the decades we've had a lot of these edge cases. In some circumstances, after years of experience with the NTP protocol as it has evolved, and the Reference Implementation and how it has evolved, we've concluded that the assumptions we made years ago are no longer valid. However, we're caught in a straight-jacket that we created for ourselves at the time because we could not see the potential need for any other view of the situation at that point.=20 So, we have a lot of legacy cruft that has accumulated. I really don't think that you want to try to incorporate our old legacy cruft into your new protocol standard. Keep in mind that the legacy cruft I'm talking about doesn't have anything to do with the NTP protocol itself, it has to do with certain assumptions at various different points in the code that implements the operations related to the protocol, and other clients or servers could easily make different assumptions and yet still have fully interoperable implementations of the NTP protocol standard. > Issue #6: "multiple instances versus list of addresses" > ------------------------------------------------------- > > The use of multiple instances of the same DHCP option to advertise=20 > several NTP servers seems to be somewhat confusing. > Depending on the decision made for other issues, we will probably=20 > change the syntax of the options (or sub-options if any). I'm not getting this point at all. Can you elaborate? > Issue #8: Carrying an URL for a config file > ------------------------------------------- > > This has been suggested a few times, but has 2 major drawbacks: > > - It requires the client to be ftp/tftp/http-enabled (a lot > of complexity on the client), > > - It would be implementation dependant, This is part of why I like the idea of a Simple NTP Configuration Service. I believe it could be much simpler and easier to implement than FTP, TFTP, or HTTP. And it would let us keep all the NTP configuration complexity outside of the DHCP protocol. > If sub-options are used in the DHCP message, we will certainly have=20 > the same level of flexibility. Um, I don't think that your DHCP messages can be as long as our configuration files. I wouldn't make any claims about your ability to have the same level of flexibility unless you want to include the full syntax of the proprietary configuration files that we support in the Reference Implementation. I'm not sure how that lexer and parser are built, but I imagine it shouldn't be a problem to contribute that to a willing recipient project. That said, I really don't think you want to try to implement anything remotely close to the full complexity of our configuration files, and I really don't think you want to implement anything that does not have it's own IETF standards-track RFC to guide you and associated working group with which to liaise. Since none of the configuration file options you've mentioned have anything to do with the NTP protocol per se, I think you'd at least need to wait until some group takes up the task of standardizing the configuration file options and syntax for all NTP servers and clients -- including, but not limited to, the Reference Implementation. There's one common theme here: Standard Protocol !=3D Proprietary Configuration File Options/Syntax One of these you can work with and interface with as part of your standard. The other, I don't think so. You don't encode Cisco router configuration file syntax into the DHCP standard (do you?), and I wouldn't suggest trying to do the same for NTP or the NTP Reference Implementation. -- Brad Knowles LinkedIn Profile: _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 29 22:40:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwiC-00013H-Ha; Thu, 29 Nov 2007 22:38:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwiC-000136-42 for dhcwg@ietf.org; Thu, 29 Nov 2007 22:38:44 -0500 Received: from mx04.gis.net ([208.218.130.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxwiB-00024K-QG for dhcwg@ietf.org; Thu, 29 Nov 2007 22:38:44 -0500 Received: from [10.10.10.101] ([63.209.224.211]) by mx04.gis.net; Thu, 29 Nov 2007 22:38:38 -0500 Message-ID: <474F8511.6070109@ntp.org> Date: Thu, 29 Nov 2007 22:35:45 -0500 From: Danny Mayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: anthony.flavin@bt.com Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6 References: <548EC156325C6340B2E85DF90CAE8586019A0008@E03MVB3-UKBR.domain1.systemhost.net> In-Reply-To: <548EC156325C6340B2E85DF90CAE8586019A0008@E03MVB3-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Mark_Andrews@isc.org, ntpwg@lists.ntp.org, mellon@fugue.com, brad@shub-internet.org, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org anthony.flavin@bt.com wrote: > Perhaps some other ISP's involved with the NTPWG would care to comment > on whether or not the poor practice of the past is still in place, or > being replaced with best practice (which is to install their own > servers, or reach an agreement for the use of somebody else's). I suspect that an ISP that is interested enough to be involved with the NTP WG will be running their own NTP servers. Danny _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 30 06:29:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy43Y-00043N-Us; Fri, 30 Nov 2007 06:29:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy43Y-00043G-7I for dhcwg@ietf.org; Fri, 30 Nov 2007 06:29:16 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy43X-000113-QC for dhcwg@ietf.org; Fri, 30 Nov 2007 06:29:16 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 Nov 2007 06:29:15 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAUBTFCC022598 for ; Fri, 30 Nov 2007 06:29:15 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAUBTFBa015343 for ; Fri, 30 Nov 2007 11:29:15 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 06:29:15 -0500 Received: from [192.168.1.101] ([10.86.240.192]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 06:29:14 -0500 Message-Id: <3937F410-B1F7-40F7-A6A9-7CA3655A2A9D@cisco.com> From: Ralph Droms To: DHC WG In-Reply-To: <6DCDA360-5BED-43C5-A5C3-030A7CF2EDC3@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 30 Nov 2007 06:29:12 -0500 References: <6DCDA360-5BED-43C5-A5C3-030A7CF2EDC3@cisco.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 30 Nov 2007 11:29:15.0346 (UTC) FILETIME=[3CF3C320:01C83344] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3111; t=1196422155; x=1197286155; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20dhc=20WG=20meeting=20agenda=20-=20REMINDER! |Sender:=20 |To:=20DHC=20WG=20; bh=IgU5utKslXHadJNDCPoR84m98ovOV31XsEDirOipWZ4=; b=UVMKJTJW1gsUuyIIHEJHkZo4dCKnOvT4twqDMWjYa28bjsPNakSpOoNPHOi6B5hIDFXhbbYP fffn/2vIsIu7BPQfby8fWBwMV/k6FBLAMSPJIClhly6nlXGSCna9so0W; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [dhcwg] Re: dhc WG meeting agenda - REMINDER! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org REMINDER!!! Presenters - we have only received presentation materials for two presentations. Please forward a copy of your presentations (PDF preferred) to dhcwg-chairs@ietf.org before 1700EST today. Avoid repeating details in your presentation that are spelled out in your I- D. Focus on high-level architecture, design questions and other issues related to the WG action. Latest revised draft included below... Note that we have a *very* tight schedule. Be sure to read the drafts prior to the WG meeting and be prepared with questions directed toward the desired WG action. - Ralph DHC WG DRAFT agenda - IETF 70 1300-1500 2007-12-04 (Tue) (Last revised 2007-11-21 10:35 AM ET) ------------------------------------- Administrivia Venaas/Droms 10 minutes Agenda bashing; blue sheets; scribe; Jabber scribe Draft last call and adoption announcements Venaas/Droms 05 minutes RFC 3942 status update B. Volz 05 minutes Progressing two drafts under RFC 3942 R. Droms 10 minutes Virtual Subnet Selection Option R. Johnson 05 minutes Review changes prior ot WG last call Virtual Subnet Selection RAIO Sub-Option K. Kinnear 05 minutes Review changes prior ot WG last call Container Option for Server Configuration R. Droms 10 minutes Accept as WG work item? DHCPv6 Bulk Leasequery M. Stapp 10 minutes Initial discussion Layer 2 Relay Agent Information B. Joshi 15 minutes Followup discussion of revised draft DHCPv6 Delegation of Certificates Option TBD 10 minutes Initial discussion for consideration as WG work item NTP Options for DHCPv6 B. Lourdelet 05 minutes Initial discussion and input to ntp WG Rebind Capability in DHCPv6 Reconfigure Msgs R. Droms 10 minutes Ready for WG last call? Service Identfiers List Option for DHCPv6 H. Deng 10 minutes Initial discussion for consideration as WG work item Neighbor Discovery Information over DHCP S. Krishnan 10 minutes Initial discussion for consideration as WG work item ----------- 120 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 30 18:12:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyF1z-0001d4-86; Fri, 30 Nov 2007 18:12:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyF1x-0001cN-9J for dhcwg@ietf.org; Fri, 30 Nov 2007 18:12:21 -0500 Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyF1w-0005Sq-KD for dhcwg@ietf.org; Fri, 30 Nov 2007 18:12:21 -0500 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id 39056310D2B; Fri, 30 Nov 2007 23:12:35 +0000 (UTC) X-Authenticated-Name: entitycyber X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from MDC-ALPB-G4-2.local (c-66-30-12-53.hsd1.ma.comcast.net [66.30.12.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Fri, 30 Nov 2007 23:12:35 +0000 (UTC) Message-ID: <475098D1.1040808@etherboot.org> Date: Fri, 30 Nov 2007 18:12:17 -0500 From: Marty Connor User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: DHC WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [dhcwg] Etherboot Project use of DHCP options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hello, First let me apologize for the lateness of this message. We have been uncertain how to proceed regarding the DHCP options that our project ( Etherboot Project, http://etherboot.org/ ) is using. At the strong suggestion of a colleague I am writing to give status of our current and planned usage of tentatively assigned DHCP options, and to ask for guidance from members of this list on how we should proceed to properly document our use of them. For those that might not be familiar with our project please allow me to give a brief introduction. The Etherboot Project has existed since about 1993. Our primary purpose has been to create and support Open Source network booting. Our most well-known network booting software is known as Etherboot. In the 14 year history of the project there have been three Project Leaders: Markus Gutschke, Ken Yap, and myself (Marty Connor). Each of us has worked to expand the capabilities of Etherboot, and in the last few years we have created a new network bootloader called gPXE. gPXE blends features of Etherboot with features of PXE, and adds some extensions not present in either specification. Etherboot's method of network booting predates the PXE specification and differs from it significantly. From using pre-wrapped binaries in NBI (Network Boot Image) format to handling of DHCP options. There is a large installed base of systems which use Etherboot BIOS Expansion ROMs or other media to network boot various operating systems. In 1999 we created the website: http://rom-o-matic.net/ To distribute free, on-demand, custom Etherboot ROM images. To date approximately 2,000,000 Etherboot images have been downloaded. This total does not include ROMs created by downloading Etherboot from SourceForge.net or by simply copying an existing image. In 2002 we began an effort to add PXE compatibility to Etherboot. This involved adding the PXE API to Etherboot, while maintaining support for legacy features. The current release of Etherboot (5.4.3) is capable of functioning as PXE boot ROM, with certain limitations. Etherboot is capable of loading PXELINUX, running RIS and other PXE NBPs and has proven useful for many applications, from network booting supercomputer clusters to enabling thin-client computing using economical hardware. In 2005 we began work on a rewrite of Etherboot called gPXE. Our aim was to create a bootloader that stronger compliance with the PXE specification with extensions that make sense for contemporary networking. Since 2005 (which is is when I became Project Leader), we have focussed most of our development energy on gPXE, and have made significant progress. gPXE is capable of both traditional PXE operation (DHCP+TFTP) plus a number of modern network booting methods, such as: * HTTP(S) booting * iSCSI booting * AoE booting Some of these network protocols required the addition of custom TCP stack for transport. We also added DNS support and URL parsing to support multiple protocols. That's a long preamble, but hopefully will give a sense of the level of effort we have invested in our software, and how many people have come to rely on it. Referring to the following document: http://www.iana.org/assignments/bootp-dhcp-parameters I note that Etherboot is mentioned in four places: 128 Etherboot signature. 6 bytes: E4:45:74:68:00:00 150 Etherboot 175 Etherboot (Tentatively Assigned - 23 Jun 2005) 177 Etherboot (Tentatively Assigned - 23 Jun 2005) The first two (128 and 150) are in wide use. Option 150 is where options for our Etherboot bootloader have long been encapsulated. We also use 129 for passing kernel options in Etherboot. I note that former Project Leader Ken Yap and former developer Timothy Legge had begun work on securing options 175 and 177: http://www3.ietf.org/proceedings/05aug/slides/dhc-7.pdf As early as 2002 when work on incorporating PXE into Etherboot we began using Option 175 for encapsulation as this message from our Lead Developer, Michael Brown explains: http://osdir.com/ml/network.etherboot.devel/2002-05/msg00032.html Our usage of Option 175 continues in gPXE. Our use of Option 177 is less clear. We need to do further research to understand our motivation for requesting that option and how we are currently using it. So, in summary: * We are doing research into our use of DHCP options * We will work on an RFC draft for our usage * Any pointers would be appreciated. Thank you for any and all feedback regarding our situation. I once more apologize for the lateness of this communication, and thank you in advance for your thoughts. Regards, Marty _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg