Re: [dhcwg] SLAAC and DDNS

[Ralph Droms <[e-mail]>]

I think we could use a little DNS expertise in this conversation.  The  
thread (it's not terribly long) starts at:

http://www.ietf.org/mail-archive/web/dhcwg/current/msg09635.html

What are your thoughts on using DHCPv6 Information-Request to update  
DNS RRs for a host that uses SLAAC?

- Ralph

On Feb 27, 2009, at 11:01 AM 2/27/09, <[e-mail]> <[e-mail] 
 > wrote:

> There has been some discussions on the ISC DHCP mailing list about  
> folks wanting to perform DDNS in an environment where clients are  
> doing stateless address auto-config.  One solution offered is that  
> the client perform the update after it gets the DNS server(s) and  
> domain(s) from a stateless DHCPv6 server.
>
> I think the only drawback to this solution is that doing DDNS  
> updates from the client makes it difficult to secure the updates  
> using TSIG, for example.  Distributing the TSIG key(s) to the  
> clients is really not an option in most cases.  However, there is  
> tremendous benefit to supporting DDNS in a SLAAC (stateless address  
> auto-config) environment.  One option would be to require client to  
> put their FQDN option in the Info-Request message sent to a  
> stateless DHCPv6 server.  The source address of the Info-Request  
> message is the client's SLAAC address, so the stateless DHCPv6  
> server would know the IP, and if the FQDN option were included, it  
> would have enough information to update both the AAAA and PTR  
> records.  The problem here is that a stateless DHCPv6 server will  
> not know when the records should be removed from DNS, but stale  
> records could be cleaned via some other "scavenging" mechanism.
>
> Is there any interest in this approach?  If so, I would consider  
> writing a draft to include the FQDN option in Info-Request messages.
>
> Regards,
> Greg Rabil
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 903683A6A12; Wed,  4 Feb 2009 02:30:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed,  4 Feb 2009 02:30:01 -0800 (PST)
Cc: [e-mail]
Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-03.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 10:30:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.


	Title           : DHCPv6 option for network boot
	Author(s)       : T. Huth, et al.
	Filename        : draft-ietf-dhc-dhcpv6-opt-netboot-03.txt
	Pages           : 11
	Date            : 2009-02-04

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a
framework for passing configuration information to nodes on a
network.  This document describes new options for DHCPv6 which are
required for booting a node from the network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-netboot-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-dhc-dhcpv6-opt-netboot-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E71753A6881 for <[e-mail]>; Wed,  4 Feb 2009 02:54:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqtrN52ElYRX for <[e-mail]>; Wed,  4 Feb 2009 02:54:47 -0800 (PST)
Received: from mtagate8.de.ibm.com (mtagate8.de.ibm.com [195.212.29.157]) by core3.amsl.com (Postfix) with ESMTP id CB88D3A6A9B for <[e-mail]>; Wed,  4 Feb 2009 02:54:46 -0800 (PST)
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate8.de.ibm.com (8.13.8/8.13.8) with ESMTP id n14Arjbb087448 for <[e-mail]>; Wed, 4 Feb 2009 10:53:45 GMT
Received: from d12av06.megacenter.de.ibm.com (d12av06.megacenter.de.ibm.com [9.149.165.230]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n14Arj8j4235492 for <[e-mail]>; Wed, 4 Feb 2009 11:53:45 +0100
Received: from d12av06.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av06.megacenter.de.ibm.com (8.13.1/8.13.3) with ESMTP id n14Arj1P022010 for <[e-mail]>; Wed, 4 Feb 2009 11:53:45 +0100
Received: from d12ml072.megacenter.de.ibm.com (d12ml072.megacenter.de.ibm.com [9.149.166.115]) by d12av06.megacenter.de.ibm.com (8.13.1/8.12.11) with ESMTP id n14ArjYr022003 for <[e-mail]>; Wed, 4 Feb 2009 11:53:45 +0100
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-KeepSent: AC316394:4AD008A6-C1257553:003A2E7E; type=4; name=$KeepSent
To: [e-mail]
X-Mailer: Lotus Notes Build V85_09252008 September 25, 2008
Message-ID: <[e-mail]>
From: Thomas Huth <[e-mail]>
Date: Wed, 4 Feb 2009 11:53:36 +0100
X-MIMETrack: Serialize by Router on D12ML072/12/M/IBM(Release 8.0.1|February 07, 2008) at 04/02/2009 11:53:44
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-03.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 10:54:48 -0000

[e-mail] wrote on 04.02.2009 11:30:01:
>
> 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 G=
roup

> of the IETF.
>
>
>    Title           : DHCPv6 option for network boot
>    Author(s)       : T. Huth, et al.
>    Filename        : draft-ietf-dhc-dhcpv6-opt-netboot-03.txt
>    Pages           : 11
>    Date            : 2009-02-04
>
> The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a
> framework for passing configuration information to nodes on a
> network.  This document describes new options for DHCPv6 which are
> required for booting a node from the network.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-netboot-0=
3.txt



This new version of the draft is now the combined effort to get best ou=
t of
both previous drafts, draft-ietf-dhc-dhcpv6-opt-netboot-02.txt and
draft-zimmer-dhc-dhcpv6-remote-boot-options-01.txt. Please review and
provide feedback!

There are still some open topics that we currently discuss:

1) How should a client handle multiple replies with boot options from
different servers when doing stateless DHCPv6 ?

2) How to deal best with multiple network interfaces in one machine (tr=
y to
boot in parallel? how to handle multiple replies again?)

3) Should there be a way how the client could ask the server for a
supported boot protocol (TFTP, HTTP, iSCSI, ...) and if so how??)

4) Is there still the need for a "Next Server Address" option in certai=
n
boot scenarios (see draft-zimmer-dhc-dhcpv6-remote-boot-options-01.txt)=


If somebody has good ideas about one of these topics, please feel free =
to
share your thoughts!


Mit freundlichen Gr=FC=DFen / Kind regards,
=A0=A0 Thomas Huth=




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BC9528C1CB for <[e-mail]>; Wed,  4 Feb 2009 05:22:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNDmfo78YQih for <[e-mail]>; Wed,  4 Feb 2009 05:22:33 -0800 (PST)
Received: from cl34.gs02.gridserver.com (cl34.gs02.gridserver.com [64.13.232.43]) by core3.amsl.com (Postfix) with ESMTP id 5C1DC28C194 for <[e-mail]>; Wed,  4 Feb 2009 05:22:33 -0800 (PST)
Received: from static-213-115-152-226.sme.bredbandsbolaget.se ([213.115.152.226]:56368 helo=offset.weird.se) by cl34.gs02.gridserver.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.63) (envelope-from <[e-mail]>) id 1LUhhl-0008CH-7g; Wed, 04 Feb 2009 05:22:13 -0800
From: Bud Millwood <[e-mail]>
Organization: Weird Solutions, Inc.
To: [e-mail]
Date: Wed, 4 Feb 2009 14:17:40 +0100
User-Agent: KMail/1.9.9
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Authenticated-User: 39280 [e-mail]
Cc: Thomas Huth <[e-mail]>
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-03.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Bud Millwood <[e-mail]>
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 13:22:34 -0000

On Wednesday 04 February 2009, Thomas Huth wrote:

> > A URL for this Internet-Draft is:
>
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-netboot-03.=
tx
>t

There's a big FIXME in section 3.3.

> 3) Should there be a way how the client could ask the server for a
> supported boot protocol (TFTP, HTTP, iSCSI, ...) and if so how??)

Hmm.. my hunch is that this feature should be put on the back burner until=
=20
there's a demonstrated need for it.

Also, most servers can distinguish between different types of devices anywa=
y,=20
so they can vary the boot protocol based on things like vendor id, user=20
class, or any number of other criteria. That might be enough distinction to=
=20
work just fine.

> 4) Is there still the need for a "Next Server Address" option in certain
> boot scenarios (see draft-zimmer-dhc-dhcpv6-remote-boot-options-01.txt)

Why would you need a Next Server address if you can just encode the server =
in=20
the URL?

=2D Bud

> This new version of the draft is now the combined effort to get best out =
of
> both previous drafts, draft-ietf-dhc-dhcpv6-opt-netboot-02.txt and
> draft-zimmer-dhc-dhcpv6-remote-boot-options-01.txt. Please review and
> provide feedback!
>
> There are still some open topics that we currently discuss:
>
> 1) How should a client handle multiple replies with boot options from
> different servers when doing stateless DHCPv6 ?
>
> 2) How to deal best with multiple network interfaces in one machine (try =
to
> boot in parallel? how to handle multiple replies again?)
>
> 3) Should there be a way how the client could ask the server for a
> supported boot protocol (TFTP, HTTP, iSCSI, ...) and if so how??)
>
> 4) Is there still the need for a "Next Server Address" option in certain
> boot scenarios (see draft-zimmer-dhc-dhcpv6-remote-boot-options-01.txt)
>
> If somebody has good ideas about one of these topics, please feel free to
> share your thoughts!
>
>
> Mit freundlichen Gr=FC=DFen / Kind regards,
> =A0=A0 Thomas Huth
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg



=2D-=20
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: [phone]
fax: [phone]


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id E402B28C0DB; Wed,  4 Feb 2009 12:45:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed,  4 Feb 2009 12:45:01 -0800 (PST)
Cc: [e-mail]
Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-srsn-option-02.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 20:45:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.


	Title           : DHCPv6 Server Reply Sequence Number Option
	Author(s)       : B. Volz, R. Droms
	Filename        : draft-ietf-dhc-dhcpv6-srsn-option-02.txt
	Pages           : 7
	Date            : 2009-02-04

This memo defines the Server Reply Sequence Number option for the
Dynamic Host Configuration Protocol for IPv6 (DHCPv6).  This option
is sent from a DHCPv6 server to a DHCPv6 relay agent to allow a relay
agent to detect proper sequencing of Relay-Reply messages that could
be delivered out of order.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-srsn-option-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-dhc-dhcpv6-srsn-option-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 895ED3A6940; Thu,  5 Feb 2009 00:24:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.959
X-Spam-Level: 
X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.640,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0ibPJ-iUSzA; Thu,  5 Feb 2009 00:24:41 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 713AD3A6870; Thu,  5 Feb 2009 00:24:41 -0800 (PST)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Thu, 05 Feb 2009 16:24:19 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Thu, 05 Feb 2009 16:24:19 +0800 (CST)
Received: from s00102542 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]>; Thu, 05 Feb 2009 16:24:19 +0800 (CST)
Date: Thu, 05 Feb 2009 16:24:18 +0800
From: Sean Shen <[e-mail]>
In-reply-to: <[e-mail]>
To: 'Damien Neil' <[e-mail]>, 'DHC-WG WG' <[e-mail]>, [e-mail]
Message-id: <027a01c9876b$23ec02d0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acl8cAKv7yxtqtRSRp6NcUBgXJJdjwK9kcJA
Subject: Re: [dhcwg] [CGA-EXT] "Secure DHCPv6 Using	CGAs"draft-jiang-dhc-secure-dhcpv6-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 08:24:42 -0000

Hi, Damien,
Sorry for the late response, I almost missed your email among tons of emails
after the long holiday. Please see in lines:

>On Jan 21, 2009, at 6:04 PM, Sean Shen wrote:
>>> I think you need to step back and figure out exactly what problem 
>>> you're trying to solve by adding this capability. Just beause we 
>>> could do something, doesn't mean we should.
>> The motivation and benefit (including advantages in relay scenarios 
>> and IP
>> binding) is described in section 3 of the draft.
>
>It's possible that this is just my lack of experience with 
>CGAs speaking, but section 3 hasn't enlightened me on the 
>benefit of this proposal.
Thanks for the comments. Based on the discussion recently, we are improving
the document by addressing the issues, including giving more and clearer
statement of benefit of the proposal. 

>My understanding is that CGA authentication will permit a 
>client to verify that a DHCP message received from a server 
>with a given address was, in fact, sent by the server with 
>that address.  Is there a mechanism, however, which permits 
>the client to verify that this server is authorized to act as 
>a DHCP server?  If not, what security is added by signing the message?
You are right that a public key itself does not include authorization info.
But it does not mean a malicious server is free to do configuration without
being punished. The characteristic of public key cryptosystem is that a pk
owner will be will be responsible for what he signed via his private key.
The pk owner surely can use his private key to play evil, but he will get
caught. For example, practically I can easily cheat on someone by using my
real identity, but I will never do that.
Attribute certificates include authorization info, but they are not included
in current CGA definitions, neither has I found its very necessary so far.
Thanks for your comments.

Best,

Sean 





Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A42A028C173 for <[e-mail]>; Thu,  5 Feb 2009 15:01:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.373
X-Spam-Level: 
X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlZp2pivfxXS for <[e-mail]>; Thu,  5 Feb 2009 15:01:34 -0800 (PST)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id CB7AC28C177 for <[e-mail]>; Thu,  5 Feb 2009 15:01:33 -0800 (PST)
X-SEF-Processed: 5_0_0_910__2009_02_05_17_20_45
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 05 Feb 2009 17:20:45 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 17:01:34 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Thu, 5 Feb 2009 17:01:32 -0600
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-geopriv-lis-discovery updated based on DHC comments
Thread-Index: AcmH5bAkD2EqsrXkT8qeZTuSiZzBBA==
From: "Thomson, Martin" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 05 Feb 2009 23:01:35.0107 (UTC) FILETIME=[B1720530:01C987E5]
Subject: [dhcwg] draft-ietf-geopriv-lis-discovery updated based on DHC comments
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 23:01:34 -0000

SGkgRm9sa3MsDQoNClRoYW5rcyB0byB0aG9zZSB3aG8gcmVzcG9uZGVkIHRvIHRoZSBwcmV2aW91
cyB0aHJlYWQgb24gdGhlIEdFT1BSSVYgbGlzIGRpc2NvdmVyeSBkb2N1bWVudC4NCg0KSSd2ZSBz
dWJtaXR0ZWQgdmVyc2lvbiAtMDYgb2YgdGhlIGRvY3VtZW50IHRoYXQgYXR0ZW1wdHMgdG8gYWNj
b21tb2RhdGUgdGhlIHN1Z2dlc3Rpb25zIG1hZGUgYnkgbWVtYmVycyBvZiB0aGlzIGdyb3VwLiAg
VGhlIG5ldyBkb2N1bWVudCB1c2VzIHR3byBzZXBhcmF0ZSBvcHRpb25zIHdpdGggc2ltcGxpZmll
ZCBmb3JtYXQuDQoNCjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWdlb3By
aXYtbGlzLWRpc2NvdmVyeS0wNj4NCg0KQ2hlZXJzLA0KTWFydGluDQoNCg0KLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNp
Z25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJp
ZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSBy
ZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVs
eSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlz
IGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NClttZjJdDQo=



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AAF33A67B6 for <[e-mail]>; Fri,  6 Feb 2009 00:27:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bckXl7R-WlYX for <[e-mail]>; Fri,  6 Feb 2009 00:27:26 -0800 (PST)
Received: from cl38.gs02.gridserver.com (cl38.gs02.gridserver.com [64.13.232.47]) by core3.amsl.com (Postfix) with ESMTP id B2F523A68C1 for <[e-mail]>; Fri,  6 Feb 2009 00:27:26 -0800 (PST)
Received: from static-213-115-152-226.sme.bredbandsbolaget.se ([213.115.152.226]:49173 helo=offset.weird.se) by cl38.gs02.gridserver.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.63) (envelope-from <[e-mail]>) id 1LVM3c-0001vZ-1c for [e-mail]; Fri, 06 Feb 2009 00:27:28 -0800
From: Bud Millwood <[e-mail]>
Organization: Weird Solutions, Inc.
To: [e-mail]
Date: Fri, 6 Feb 2009 09:22:41 +0100
User-Agent: KMail/1.9.9
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Authenticated-User: 39280 [e-mail]
Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated based on DHC comments
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Bud Millwood <[e-mail]>
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 08:27:27 -0000

> <http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-06>

>  Length:  The length of the entire LIS certificate fingerprints option
>      in octets.  This option MAY be zero length, indicating the absence
>      of fingerprint information.

Does the absence of an LIS_CERT_FP option indicate the same thing as when the 
option is present but has zero length? If so, that should be documented.

Also, does anyone know if there is an IANA registry for numeric designations 
for hash function types?

- Bud

> Cheers,
> Martin
>
>
> ---------------------------------------------------------------------------
>--------------------- This message is for the designated recipient only and
> may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> ---------------------------------------------------------------------------
>--------------------- [mf2]
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg



-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: [phone]
fax: [phone]


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39903A6B68 for <[e-mail]>; Fri,  6 Feb 2009 00:44:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.385
X-Spam-Level: 
X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8103IYw46jGL for <[e-mail]>; Fri,  6 Feb 2009 00:44:37 -0800 (PST)
Received: from smtpout09.prod.mesa1.secureserver.net (smtpout09-04.prod.mesa1.secureserver.net [64.202.165.17]) by core3.amsl.com (Postfix) with SMTP id EA2E33A6B71 for <[e-mail]>; Fri,  6 Feb 2009 00:44:36 -0800 (PST)
Received: (qmail 24432 invoked from network); 6 Feb 2009 08:44:38 -0000
Received: from unknown (124.120.226.104) by smtpout09-04.prod.mesa1.secureserver.net (64.202.165.17) with ESMTP; 06 Feb 2009 08:44:38 -0000
From: "Glen Zorn" <[e-mail]>
To: "'Bud Millwood'" <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Fri, 6 Feb 2009 15:44:06 +0700
Organization: Network Zen
Message-ID: <003901c98837$147d3ae0$3d77b0a0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmINMO3X2LqXz4ASgmYbM44mizrvgAAb0ew
Content-Language: en-us
Cc: [e-mail]
Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated based on DHC	comments
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 08:44:37 -0000

Bud Millwood [mailto:[e-mail]] writes:

...

> Also, does anyone know if there is an IANA registry for numeric
> designations
> for hash function types?

Yup, several, for DNSSEC, PGP & TLS, at least.

...



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324D928C20D for <[e-mail]>; Fri,  6 Feb 2009 04:36:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf4jBXdwTlu3 for <[e-mail]>; Fri,  6 Feb 2009 04:36:56 -0800 (PST)
Received: from cl40.gs02.gridserver.com (cl40.gs02.gridserver.com [64.13.232.49]) by core3.amsl.com (Postfix) with ESMTP id 7C22E28C1FD for <[e-mail]>; Fri,  6 Feb 2009 04:36:56 -0800 (PST)
Received: from static-213-115-152-226.sme.bredbandsbolaget.se ([213.115.152.226]:57663 helo=offset.weird.se) by cl40.gs02.gridserver.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.63) (envelope-from <[e-mail]>) id 1LVPx2-0005FK-Af; Fri, 06 Feb 2009 04:36:56 -0800
From: Bud Millwood <[e-mail]>
Organization: Weird Solutions, Inc.
To: [e-mail]
Date: Fri, 6 Feb 2009 13:32:01 +0100
User-Agent: KMail/1.9.9
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Authenticated-User: 39280 [e-mail]
Cc: Thomas Huth <[e-mail]>
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-03.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Bud Millwood <[e-mail]>
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 12:36:57 -0000

Thomas:

I've been thinking about the boot file URL encoding and have some concerns. 
Specifically, this text:

>   bootfile-url      This ASCII string is the URL (conforming to
>                     [RFC3986]) for a boot file.  This string starts
>                     with the protocol which is used for downloading.
>                     Separated by "://", the hostname or IPv6 address of
>                     the server hosting the boot file follows, and then
>                     the path, file name and query parts of the URL.
>                     The string is not null-terminated.

In DHCPv4, the boot file was an opaque value that was passed unmodified to the 
boot server, but with this proposal the client is required to parse the boot 
file URL. Suppose we have this URL:

tftp://192.168.1.1//somefile.bin

Will the client correctly understand that the boot file is "/somefile.bin" and 
not "somefile.bin"?

And what about this one (the boot file name below is not contrived, our TFTP 
server supports it)

tftp://192.168.1.1/file://myfile.bin

I know that these things should work correctly in the field, but in practice 
they often get screwed up.

I would prefer that the boot file name actually be separate enough to be 
*truly* opaque.

- Bud


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 36EE13A6C2A; Fri,  6 Feb 2009 18:15:00 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri,  6 Feb 2009 18:15:01 -0800 (PST)
Cc: [e-mail]
Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-agentopt-delegate-03.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2009 02:15:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.


	Title           : DHCPv6 Relay Agent Assignment Notification (RAAN) Option
	Author(s)       : R. Droms, B. Volz
	Filename        : draft-ietf-dhc-dhcpv6-agentopt-delegate-03.txt
	Pages           : 8
	Date            : 2009-02-06

The DHCP Relay Agent Assignment Notification (RAAN) option is sent
from a DHCP server to a DHCP relay agent to inform the relay agent of
IPv6 addresses that have been assigned or IPv6 prefixes that have
been delegated to DHCP clients.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-agentopt-delegate-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-dhc-dhcpv6-agentopt-delegate-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D18D3A6A58 for <[e-mail]>; Sat,  7 Feb 2009 11:22:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.09
X-Spam-Level: 
X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=0.509,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyhfyffLlJSd for <[e-mail]>; Sat,  7 Feb 2009 11:22:30 -0800 (PST)
Received: from mail2.ntp.org (mail2.ntp.org [204.152.184.138]) by core3.amsl.com (Postfix) with ESMTP id 380983A6D0F for <[e-mail]>; Sat,  7 Feb 2009 11:22:21 -0800 (PST)
Received: from mail.antoniuk.md (mail.antoniuk.md [65.86.158.146]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.ntp.org (Postfix) with ESMTP id 7AC47398E1; Sat,  7 Feb 2009 19:22:21 +0000 (UTC) (envelope-from [e-mail])
Received: from cust-63-209-224-151.bos-dynamic.gis.net ([63.209.224.151] helo=[10.10.10.100]) by mail.antoniuk.md with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <[e-mail]>) id 1LVskW-0000O3-H7; Sat, 07 Feb 2009 14:21:56 -0500
Message-ID: <[e-mail]>
Date: Sat, 07 Feb 2009 14:21:53 -0500
From: Danny Mayer <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Bud Millwood <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-kostecke.net-MailScanner: Found to be clean
X-kostecke.net-MailScanner-From: [e-mail]
Cc: [e-mail], Thomas Huth <[e-mail]>
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-03.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2009 19:22:31 -0000

Bud Millwood wrote:
> Thomas:
> 
> I've been thinking about the boot file URL encoding and have some concerns. 
> Specifically, this text:
> 
>>   bootfile-url      This ASCII string is the URL (conforming to
>>                     [RFC3986]) for a boot file.  This string starts
>>                     with the protocol which is used for downloading.
>>                     Separated by "://", the hostname or IPv6 address of
>>                     the server hosting the boot file follows, and then
>>                     the path, file name and query parts of the URL.
>>                     The string is not null-terminated.
> 
> In DHCPv4, the boot file was an opaque value that was passed unmodified to the 
> boot server, but with this proposal the client is required to parse the boot 
> file URL. Suppose we have this URL:
> 
> tftp://192.168.1.1//somefile.bin

This makes no sense. The URL specifies a path from the root of the
server handling the tftp protocol. This is by design. For obvious
security reasons you should not not be able to get to the root of the
file system.

> 
> Will the client correctly understand that the boot file is "/somefile.bin" and 
> not "somefile.bin"?

No. That's not how URL's are supposed to work.

> 
> And what about this one (the boot file name below is not contrived, our TFTP 
> server supports it)
> 
> tftp://192.168.1.1/file://myfile.bin
> 
> I know that these things should work correctly in the field, but in practice 
> they often get screwed up.

Then I would strongly recommend that you remove that daemon from your
server since you have opened a huge security hole in your server.

Danny


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931D73A6ACA for <[e-mail]>; Sun,  8 Feb 2009 14:26:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.376
X-Spam-Level: 
X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBe5yhQ+0n3H for <[e-mail]>; Sun,  8 Feb 2009 14:26:07 -0800 (PST)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 7C6403A6AAA for <[e-mail]>; Sun,  8 Feb 2009 14:26:06 -0800 (PST)
X-SEF-Processed: 5_0_0_910__2009_02_08_16_45_24
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 08 Feb 2009 16:45:24 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Feb 2009 16:26:11 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Sun, 8 Feb 2009 16:26:08 -0600
Message-ID: <[e-mail]>
In-Reply-To: <003901c98837$147d3ae0$3d77b0a0$@net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] draft-ietf-geopriv-lis-discovery updated based onDHC	comments
Thread-Index: AcmINMO3X2LqXz4ASgmYbM44mizrvgAAb0ewAIEAN5A=
References: <[e-mail]><[e-mail]> <003901c98837$147d3ae0$3d77b0a0$@net>
From: "Thomson, Martin" <[e-mail]>
To: "Glen Zorn" <[e-mail]>, "Bud Millwood" <[e-mail]>
X-OriginalArrivalTime: 08 Feb 2009 22:26:11.0197 (UTC) FILETIME=[3EBC52D0:01C98A3C]
Cc: [e-mail]
Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated based onDHC	comments
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 22:26:08 -0000

SXQgc2VlbXMgdGhhdCBJIHNob3VsZCBwYXkgbW9yZSBhdHRlbnRpb24gLSB1bnRpbCB0b2RheSwg
SSB3YXMgc3VyZSB0aGF0IFRMUyB1c2VkIGFuIE9JRCAobGlrZSBYLjUwOSkuICBTZWVtcyBsaWtl
IGFub3RoZXIgdXBkYXRlIGlzIGluIG9yZGVyOiBJIGp1c3QgImZvdW5kIiA8aHR0cDovL2lhbmEu
b3JnL2Fzc2lnbm1lbnRzL3Rscy1wYXJhbWV0ZXJzL3Rscy1wYXJhbWV0ZXJzLnhodG1sI3Rscy1w
YXJhbWV0ZXJzLTE3Pi4NCg0KVGhhdCdzIGdvb2QsIGJlY2F1c2UgdGhlIG9wdGlvbiB3aWxsIHNp
bXBseSBoYXZlIGEgInN1Yi1vcHRpb24iIHR5cGUgZm9ybWF0LCB3aXRoIGFuIGV4cGxpY2l0IGlu
ZGljYXRvciBmb3IgIm5vbmUiLCB3aGljaCBoZWxwcyB0byBhbnN3ZXIgQnVkJ3Mgb3RoZXIgcXVl
c3Rpb24gbW9yZSBleHBsaWNpdGx5LiAgKFRoZSBhbnN3ZXIgaXMgaW4gdGhlIGRvY3VtZW50IGFs
cmVhZHksIGJ1dCB0aGlzIGlzIGJldHRlci4pDQoNCkNoZWVycywNCk1hcnRpbg0KDQo+IC0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21h
aWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgR2xlbiBab3JuDQo+
IFNlbnQ6IEZyaWRheSwgNiBGZWJydWFyeSAyMDA5IDc6NDQgUE0NCj4gVG86ICdCdWQgTWlsbHdv
b2QnDQo+IENjOiBkaGN3Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2RoY3dnXSBkcmFmdC1p
ZXRmLWdlb3ByaXYtbGlzLWRpc2NvdmVyeSB1cGRhdGVkIGJhc2VkDQo+IG9uREhDIGNvbW1lbnRz
DQo+IA0KPiBCdWQgTWlsbHdvb2QgW21haWx0bzpidWRtQHdlaXJkLXNvbHV0aW9ucy5jb21dIHdy
aXRlczoNCj4gDQo+IC4uLg0KPiANCj4gPiBBbHNvLCBkb2VzIGFueW9uZSBrbm93IGlmIHRoZXJl
IGlzIGFuIElBTkEgcmVnaXN0cnkgZm9yIG51bWVyaWMNCj4gPiBkZXNpZ25hdGlvbnMNCj4gPiBm
b3IgaGFzaCBmdW5jdGlvbiB0eXBlcz8NCj4gDQo+IFl1cCwgc2V2ZXJhbCwgZm9yIEROU1NFQywg
UEdQICYgVExTLCBhdCBsZWFzdC4NCj4gDQo+IC4uLg0KPiANCj4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGhjd2cgbWFpbGluZyBsaXN0DQo+IGRo
Y3dnQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhj
d2cNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3Nh
Z2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4g
cHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9u
LiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg
c2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhv
cml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo=



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CE0A3A6898 for <[e-mail]>; Sun,  8 Feb 2009 20:37:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.38
X-Spam-Level: 
X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFc62Kg4w8aL for <[e-mail]>; Sun,  8 Feb 2009 20:37:25 -0800 (PST)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id DDA813A67A3 for <[e-mail]>; Sun,  8 Feb 2009 20:37:24 -0800 (PST)
X-SEF-Processed: 5_0_0_910__2009_02_08_22_56_42
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 08 Feb 2009 22:56:42 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Feb 2009 22:37:28 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Sun, 8 Feb 2009 22:37:26 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] draft-ietf-geopriv-lis-discovery updated basedonDHC	comments
Thread-Index: AcmINMO3X2LqXz4ASgmYbM44mizrvgAAb0ewAIEAN5AADVHWIA==
References: <[e-mail]><[e-mail]><003901c98837$147d3ae0$3d77b0a0$@net> <[e-mail]>
From: "Thomson, Martin" <[e-mail]>
To: "Thomson, Martin" <[e-mail]>, "Glen Zorn" <[e-mail]>, "Bud Millwood" <[e-mail]>
X-OriginalArrivalTime: 09 Feb 2009 04:37:28.0271 (UTC) FILETIME=[1CE80DF0:01C98A70]
Cc: [e-mail]
Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated basedonDHC	comments
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 04:37:26 -0000

SSd2ZSBqdXN0IHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gdGhhdCB1c2VzIHRoZSBzaW5nbGUgb2N0
ZXQgY29kZSBwb2ludCBmcm9tIFRMUyB0byBpZGVudGlmeSBoYXNoZXMgKHR3byBmb3IgREhDUHY2
IHNvIHRoYXQgdGhleSBsb29rIGxpa2Ugc3ViLW9wdGlvbnMpLiAgSSd2ZSBhbHNvIHRha2VuIGFu
b3RoZXIgcGFzcyBhdCB0aGUgdGV4dCBpbiBhbiBlZmZvcnQgdG8gbWFrZSBpdCBlYXNpZXIgdG8g
dW5kZXJzdGFuZCAoYW5kIHRvIGFkZHJlc3MgQnVkJ3MgcXVlc3Rpb24gbW9yZSBleHBsaWNpdGx5
KS4NCg0KPGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZ2Vv
cHJpdi1saXMtZGlzY292ZXJ5LTA3LnR4dD4NCg0KVGEsDQpNYXJ0aW4NCg0KPiAtLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86
ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIFRob21zb24sIE1hcnRpbg0K
PiBTZW50OiBNb25kYXksIDkgRmVicnVhcnkgMjAwOSA5OjI2IEFNDQo+IFRvOiBHbGVuIFpvcm47
IEJ1ZCBNaWxsd29vZA0KPiBDYzogZGhjd2dAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkaGN3
Z10gZHJhZnQtaWV0Zi1nZW9wcml2LWxpcy1kaXNjb3ZlcnkgdXBkYXRlZA0KPiBiYXNlZG9uREhD
IGNvbW1lbnRzDQo+IA0KPiBJdCBzZWVtcyB0aGF0IEkgc2hvdWxkIHBheSBtb3JlIGF0dGVudGlv
biAtIHVudGlsIHRvZGF5LCBJIHdhcyBzdXJlDQo+IHRoYXQgVExTIHVzZWQgYW4gT0lEIChsaWtl
IFguNTA5KS4gIFNlZW1zIGxpa2UgYW5vdGhlciB1cGRhdGUgaXMgaW4NCj4gb3JkZXI6IEkganVz
dCAiZm91bmQiIDxodHRwOi8vaWFuYS5vcmcvYXNzaWdubWVudHMvdGxzLXBhcmFtZXRlcnMvdGxz
LQ0KPiBwYXJhbWV0ZXJzLnhodG1sI3Rscy1wYXJhbWV0ZXJzLTE3Pi4NCj4gDQo+IFRoYXQncyBn
b29kLCBiZWNhdXNlIHRoZSBvcHRpb24gd2lsbCBzaW1wbHkgaGF2ZSBhICJzdWItb3B0aW9uIiB0
eXBlDQo+IGZvcm1hdCwgd2l0aCBhbiBleHBsaWNpdCBpbmRpY2F0b3IgZm9yICJub25lIiwgd2hp
Y2ggaGVscHMgdG8gYW5zd2VyDQo+IEJ1ZCdzIG90aGVyIHF1ZXN0aW9uIG1vcmUgZXhwbGljaXRs
eS4gIChUaGUgYW5zd2VyIGlzIGluIHRoZSBkb2N1bWVudA0KPiBhbHJlYWR5LCBidXQgdGhpcyBp
cyBiZXR0ZXIuKQ0KPiANCj4gQ2hlZXJzLA0KPiBNYXJ0aW4NCj4gDQo+ID4gLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86
ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmDQo+ID4gT2YgR2xlbiBab3JuDQo+
ID4gU2VudDogRnJpZGF5LCA2IEZlYnJ1YXJ5IDIwMDkgNzo0NCBQTQ0KPiA+IFRvOiAnQnVkIE1p
bGx3b29kJw0KPiA+IENjOiBkaGN3Z0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbZGhjd2dd
IGRyYWZ0LWlldGYtZ2VvcHJpdi1saXMtZGlzY292ZXJ5IHVwZGF0ZWQgYmFzZWQNCj4gPiBvbkRI
QyBjb21tZW50cw0KPiA+DQo+ID4gQnVkIE1pbGx3b29kIFttYWlsdG86YnVkbUB3ZWlyZC1zb2x1
dGlvbnMuY29tXSB3cml0ZXM6DQo+ID4NCj4gPiAuLi4NCj4gPg0KPiA+ID4gQWxzbywgZG9lcyBh
bnlvbmUga25vdyBpZiB0aGVyZSBpcyBhbiBJQU5BIHJlZ2lzdHJ5IGZvciBudW1lcmljDQo+ID4g
PiBkZXNpZ25hdGlvbnMNCj4gPiA+IGZvciBoYXNoIGZ1bmN0aW9uIHR5cGVzPw0KPiA+DQo+ID4g
WXVwLCBzZXZlcmFsLCBmb3IgRE5TU0VDLCBQR1AgJiBUTFMsIGF0IGxlYXN0Lg0KPiA+DQo+ID4g
Li4uDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPiA+IGRoY3dnIG1haWxpbmcgbGlzdA0KPiA+IGRoY3dnQGlldGYub3JnDQo+ID4gaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KPiANCj4gLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBUaGlzIG1lc3NhZ2UgaXMgZm9y
IHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCj4gY29udGFpbiBwcml2aWxl
Z2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uDQo+IElm
IHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIN
Cj4gaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVk
IHVzZSBvZg0KPiB0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQo+IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gW21mMl0NCj4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGhjd2cgbWFpbGluZyBsaXN0DQo+IGRo
Y3dnQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhj
d2cNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3Nh
Z2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4g
cHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9u
LiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg
c2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhv
cml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo=



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246B33A6B86 for <[e-mail]>; Mon,  9 Feb 2009 02:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSZUu6aS2Ubo for <[e-mail]>; Mon,  9 Feb 2009 02:26:16 -0800 (PST)
Received: from mtagate3.de.ibm.com (mtagate3.de.ibm.com [195.212.29.152]) by core3.amsl.com (Postfix) with ESMTP id 031653A6B7D for <[e-mail]>; Mon,  9 Feb 2009 02:26:15 -0800 (PST)
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.14.3/8.13.8) with ESMTP id n19AQIn0165596 for <[e-mail]>; Mon, 9 Feb 2009 10:26:18 GMT
Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n19AQBSL3555540 for <[e-mail]>; Mon, 9 Feb 2009 11:26:17 +0100
Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n19AQBVu002672 for <[e-mail]>; Mon, 9 Feb 2009 11:26:11 +0100
Received: from d12ml072.megacenter.de.ibm.com (d12ml072.megacenter.de.ibm.com [9.149.166.115]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n19AQBpR002665 for <[e-mail]>; Mon, 9 Feb 2009 11:26:11 +0100
In-Reply-To: <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
X-KeepSent: 05007D64:1A32FA9F-C1257558:0038ADEC; type=4; name=$KeepSent
To: [e-mail]
X-Mailer: Lotus Notes Build V85_09252008 September 25, 2008
Message-ID: <[e-mail]>
From: Thomas Huth <[e-mail]>
Date: Mon, 9 Feb 2009 11:25:53 +0100
X-MIMETrack: Serialize by Router on D12ML072/12/M/IBM(Release 8.0.1|February 07, 2008) at 09/02/2009 11:26:11
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-03.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 10:26:17 -0000

[e-mail] wrote on 07.02.2009 20:21:53:

> Bud Millwood wrote:
> > I've been thinking about the boot file URL encoding and have some
concerns.
> > Specifically, this text:
> >
> >>   bootfile-url      This ASCII string is the URL (conforming to
> >>                     [RFC3986]) for a boot file.  This string starts
> >>                     with the protocol which is used for downloading.
> >>                     Separated by "://", the hostname or IPv6 address
of
> >>                     the server hosting the boot file follows, and then
> >>                     the path, file name and query parts of the URL.
> >>                     The string is not null-terminated.
> >
> > In DHCPv4, the boot file was an opaque value that was passed unmodified
to the
> > boot server, but with this proposal the client is required to parse the
boot
> > file URL. Suppose we have this URL:
> >
> > tftp://192.168.1.1//somefile.bin
>
> This makes no sense. The URL specifies a path from the root of the
> server handling the tftp protocol. This is by design. For obvious
> security reasons you should not not be able to get to the root of the
> file system.

Right, thanks for pointing that out, Danny!
By the way, the valid TFTP URL layout is described in RFC 3617:

http://tools.ietf.org/html/rfc3617

If you put something else into the URL field, you're out of spec, so the
results
might heavily depend on the implementation of your TFTP server.

 Thomas



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74DCF28C1C7 for <[e-mail]>; Tue, 10 Feb 2009 05:57:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANPQgXr8FIPo for <[e-mail]>; Tue, 10 Feb 2009 05:57:43 -0800 (PST)
Received: from cl40.gs02.gridserver.com (cl40.gs02.gridserver.com [64.13.232.49]) by core3.amsl.com (Postfix) with ESMTP id A8C2B28C1C5 for <[e-mail]>; Tue, 10 Feb 2009 05:57:43 -0800 (PST)
Received: from static-213-115-152-226.sme.bredbandsbolaget.se ([213.115.152.226]:59546 helo=offset.weird.se) by cl40.gs02.gridserver.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.63) (envelope-from <[e-mail]>) id 1LWt7R-00025P-7T; Tue, 10 Feb 2009 05:57:45 -0800
From: Bud Millwood <[e-mail]>
Organization: Weird Solutions, Inc.
To: Danny Mayer <[e-mail]>
Date: Tue, 10 Feb 2009 14:52:09 +0100
User-Agent: KMail/1.9.9
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Authenticated-User: 39280 [e-mail]
Cc: [e-mail], Thomas Huth <[e-mail]>
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-03.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Bud Millwood <[e-mail]>
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 10 Feb 2009 13:57:44 -0000

On Saturday 07 February 2009, Danny Mayer wrote:
> Bud Millwood wrote:
> > Thomas:
> >
> > I've been thinking about the boot file URL encoding and have some
> > concerns.
> >
> > Specifically, this text:
> >>   bootfile-url      This ASCII string is the URL (conforming to
> >>                     [RFC3986]) for a boot file.  This string starts
> >>                     with the protocol which is used for downloading.
> >>                     Separated by "://", the hostname or IPv6 address of
> >>                     the server hosting the boot file follows, and then
> >>                     the path, file name and query parts of the URL.
> >>                     The string is not null-terminated.
> >
> > In DHCPv4, the boot file was an opaque value that was passed unmodified
> > to the boot server, but with this proposal the client is required to
> > parse the boot file URL. Suppose we have this URL:
> >
> > tftp://192.168.1.1//somefile.bin
>
> This makes no sense. The URL specifies a path from the root of the
> server handling the tftp protocol. This is by design. For obvious
> security reasons you should not not be able to get to the root of the
> file system.
>
> > Will the client correctly understand that the boot file is
> > "/somefile.bin" and not "somefile.bin"?
>
> No. That's not how URL's are supposed to work.

I don't think a TFTP server *should* allow access to the root of the file 
system, but with this format it cannot. But after a little more thought, I 
don't think this is a real issue, so I withdraw this concern.

> > And what about this one (the boot file name below is not contrived, our
> > TFTP server supports it)
> >
> > tftp://192.168.1.1/file://myfile.bin
> >
> > I know that these things should work correctly in the field, but in
> > practice they often get screwed up.
>
> Then I would strongly recommend that you remove that daemon from your
> server since you have opened a huge security hole in your server.

The example 'tftp://192.168.1.1/file://myfile.bin' is not a security hole 
because the file name 'myfile.bin' is not referencing the root of the file 
system, and the server is not obeying rooted file names by default anyway, so 
there's nothing to see here.

My point here (the second point) was simply that 'file://myfile.bin' is a 
*file name* that we can currently accept, but I think we'd be better off 
exporting these sub-protocols as virtual file systems instead, such 
as /file, /dynamic, etc. Much cleaner and more standardized.

So I withdraw the second concern, too.

- Bud


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13133A6BEE for <[e-mail]>; Tue, 10 Feb 2009 06:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i--vwu9+cBF9 for <[e-mail]>; Tue, 10 Feb 2009 06:47:15 -0800 (PST)
Received: from cl16.gs02.gridserver.com (cl16.gs02.gridserver.com [64.13.232.25]) by core3.amsl.com (Postfix) with ESMTP id 910C83A6C77 for <[e-mail]>; Tue, 10 Feb 2009 06:47:15 -0800 (PST)
Received: from static-213-115-152-226.sme.bredbandsbolaget.se ([213.115.152.226]:56319 helo=offset.weird.se) by cl16.gs02.gridserver.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.63) (envelope-from <[e-mail]>) id 1LWttO-0004cx-C1; Tue, 10 Feb 2009 06:47:18 -0800
From: Bud Millwood <[e-mail]>
Organization: Weird Solutions, Inc.
To: [e-mail]
Date: Tue, 10 Feb 2009 15:41:47 +0100
User-Agent: KMail/1.9.9
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Authenticated-User: 39280 [e-mail]
Cc: "Thomson, Martin" <[e-mail]>
Subject: Re: [dhcwg] =?iso-8859-1?q?draft-ietf-geopriv-lis-discovery_updated_b?= =?iso-8859-1?q?asedonDHC=09comments?=
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Bud Millwood <[e-mail]>
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 10 Feb 2009 14:47:16 -0000

On Monday 09 February 2009, Thomson, Martin wrote:
> I've just uploaded a new version that uses the single octet code point from
> TLS to identify hashes (two for DHCPv6 so that they look like sub-options).
>  I've also taken another pass at the text in an effort to make it easier to
> understand (and to address Bud's question more explicitly).
>
> <http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lis-discovery-07.tx
>t>

I've been looking over this new draft, and it's getting better but there's a 
technicality:

"Fingerprint-Sub-Options:  A series of one or more sub-options, as shown in 
Figure 4."

These are not (yet) true sub-options in that they don't have an assigned DHCP 
(sub)option number. They look like sub-options, because they have a hash 
algorithm number where the DHCP option number would be, but that's not really 
the same thing.

I think you need to declare each DHCP suboption supported. No difference from 
the format described, but simply declaring the suboption number for each 
supported hash algorithm, and maybe stating somewhere that these suboptions 
are attempting to provide a one-to-one correspondence to the IANA hash 
numbers.

- Bud

> Ta,
> Martin
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Thomson, Martin
> > Sent: Monday, 9 February 2009 9:26 AM
> > To: Glen Zorn; Bud Millwood
> > Cc: [e-mail]
> > Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated
> > basedonDHC comments
> >
> > It seems that I should pay more attention - until today, I was sure
> > that TLS used an OID (like X.509).  Seems like another update is in
> > order: I just "found" <http://iana.org/assignments/tls-parameters/tls-
> > parameters.xhtml#tls-parameters-17>.
> >
> > That's good, because the option will simply have a "sub-option" type
> > format, with an explicit indicator for "none", which helps to answer
> > Bud's other question more explicitly.  (The answer is in the document
> > already, but this is better.)
> >
> > Cheers,
> > Martin
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> >
> > Behalf
> >
> > > Of Glen Zorn
> > > Sent: Friday, 6 February 2009 7:44 PM
> > > To: 'Bud Millwood'
> > > Cc: [e-mail]
> > > Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated based
> > > onDHC comments
> > >
> > > Bud Millwood [mailto:[e-mail]] writes:
> > >
> > > ...
> > >
> > > > Also, does anyone know if there is an IANA registry for numeric
> > > > designations
> > > > for hash function types?
> > >
> > > Yup, several, for DNSSEC, PGP & TLS, at least.
> > >
> > > ...
> > >
> > > _______________________________________________
> > > dhcwg mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dhcwg
> >
> > -----------------------------------------------------------------------
> > -------------------------
> > This message is for the designated recipient only and may
> > contain privileged, proprietary, or otherwise private information.
> > If you have received it in error, please notify the sender
> > immediately and delete the original.  Any unauthorized use of
> > this email is prohibited.
> > -----------------------------------------------------------------------
> > -------------------------
> > [mf2]
> > _______________________________________________
> > dhcwg mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dhcwg
>
> ---------------------------------------------------------------------------
>--------------------- This message is for the designated recipient only and
> may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> ---------------------------------------------------------------------------
>--------------------- [mf2]
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg



-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: [phone]
fax: [phone]


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6803A68F7 for <[e-mail]>; Tue, 10 Feb 2009 16:17:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.389
X-Spam-Level: 
X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ0yn2LwdiTq for <[e-mail]>; Tue, 10 Feb 2009 16:17:40 -0800 (PST)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id E10293A6835 for <[e-mail]>; Tue, 10 Feb 2009 16:17:39 -0800 (PST)
X-SEF-Processed: 5_0_0_910__2009_02_10_18_36_57
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 10 Feb 2009 18:36:57 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Feb 2009 18:17:40 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Tue, 10 Feb 2009 18:17:39 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] draft-ietf-geopriv-lis-discovery updated basedonDHC	comments
Thread-Index: AcmLjnoAWufddxgSTtqT+/03sUyNgQATveTA
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Thomson, Martin" <[e-mail]>
To: "Bud Millwood" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 11 Feb 2009 00:17:40.0991 (UTC) FILETIME=[26FD60F0:01C98BDE]
Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated basedonDHC	comments
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 11 Feb 2009 00:17:41 -0000

SGkgQnVkLA0KDQpUaGFua3MgZm9yIHRoZSBmZWVkYmFjay4gIEknbGwgYWRkcmVzcyB0aGlzIGlu
IHRoZSBuZXh0IHJldmlzaW9uLCB3aGljaCBtaWdodCBoYXZlIHRvIHdhaXQgdW50aWwgYWZ0ZXIg
U0YuDQoNCkZvciBteSBiZW5lZml0LCBob3cgZG8geW91IGRpc3Rpbmd1aXNoIGJldHdlZW4gc3Vi
LW9wdGlvbnMgYW5kIHdoYXQgYXBwZWFycyB0byBiZSBzdWItb3B0aW9ucz8gIEkgYXNzdW1lIHRo
YXQgeW91IGFyZSBhbGx1ZGluZyB0byBzb21lIHNvcnQgb2YgZXN0YWJsaXNoZWQgY29udmVudGlv
biBmb3IgdXNlIG9mIHN1Yi1vcHRpb25zIHRoYXQgaXMgZm9sbG93ZWQsIHN1Y2ggYXMgZm9ybWFs
IHJlZ2lzdHJhdGlvbiBvZiBjb2Rlcy4NCg0KSSdkIGxpa2UgdG8gYXZvaWQgZW51bWVyYXRpbmcg
dGhlIGNvZGVzLiAgVGhhdCBpbXBsaWVzIHRoYXQgdXBkYXRlcyB0byB0aGUgVExTIHJlZ2lzdHJ5
IGFsc28gcmVxdWlyZSB1cGRhdGVzIHRvIHRoaXMgZG9jdW1lbnQuICBEbyB5b3UgaGF2ZSBhbnkg
c3VnZ2VzdGlvbnM/DQoNCkNoZWVycywNCk1hcnRpbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+IEZyb206IEJ1ZCBNaWxsd29vZCBbbWFpbHRvOmJ1ZG1Ad2VpcmQtc29sdXRpb25z
LmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCAxMSBGZWJydWFyeSAyMDA5IDE6NDIgQU0NCj4gVG86
IGRoY3dnQGlldGYub3JnDQo+IENjOiBUaG9tc29uLCBNYXJ0aW47IEdsZW4gWm9ybg0KPiBTdWJq
ZWN0OiBSZTogW2RoY3dnXSBkcmFmdC1pZXRmLWdlb3ByaXYtbGlzLWRpc2NvdmVyeSB1cGRhdGVk
DQo+IGJhc2Vkb25ESEMgY29tbWVudHMNCj4gDQo+IE9uIE1vbmRheSAwOSBGZWJydWFyeSAyMDA5
LCBUaG9tc29uLCBNYXJ0aW4gd3JvdGU6DQo+ID4gSSd2ZSBqdXN0IHVwbG9hZGVkIGEgbmV3IHZl
cnNpb24gdGhhdCB1c2VzIHRoZSBzaW5nbGUgb2N0ZXQgY29kZQ0KPiBwb2ludCBmcm9tDQo+ID4g
VExTIHRvIGlkZW50aWZ5IGhhc2hlcyAodHdvIGZvciBESENQdjYgc28gdGhhdCB0aGV5IGxvb2sg
bGlrZSBzdWItDQo+IG9wdGlvbnMpLg0KPiA+ICBJJ3ZlIGFsc28gdGFrZW4gYW5vdGhlciBwYXNz
IGF0IHRoZSB0ZXh0IGluIGFuIGVmZm9ydCB0byBtYWtlIGl0DQo+IGVhc2llciB0bw0KPiA+IHVu
ZGVyc3RhbmQgKGFuZCB0byBhZGRyZXNzIEJ1ZCdzIHF1ZXN0aW9uIG1vcmUgZXhwbGljaXRseSku
DQo+ID4NCj4gPiA8aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0
Zi1nZW9wcml2LWxpcy0NCj4gZGlzY292ZXJ5LTA3LnR4DQo+ID50Pg0KPiANCj4gSSd2ZSBiZWVu
IGxvb2tpbmcgb3ZlciB0aGlzIG5ldyBkcmFmdCwgYW5kIGl0J3MgZ2V0dGluZyBiZXR0ZXIgYnV0
DQo+IHRoZXJlJ3MgYQ0KPiB0ZWNobmljYWxpdHk6DQo+IA0KPiAiRmluZ2VycHJpbnQtU3ViLU9w
dGlvbnM6ICBBIHNlcmllcyBvZiBvbmUgb3IgbW9yZSBzdWItb3B0aW9ucywgYXMNCj4gc2hvd24g
aW4NCj4gRmlndXJlIDQuIg0KPiANCj4gVGhlc2UgYXJlIG5vdCAoeWV0KSB0cnVlIHN1Yi1vcHRp
b25zIGluIHRoYXQgdGhleSBkb24ndCBoYXZlIGFuDQo+IGFzc2lnbmVkIERIQ1ANCj4gKHN1Yilv
cHRpb24gbnVtYmVyLiBUaGV5IGxvb2sgbGlrZSBzdWItb3B0aW9ucywgYmVjYXVzZSB0aGV5IGhh
dmUgYQ0KPiBoYXNoDQo+IGFsZ29yaXRobSBudW1iZXIgd2hlcmUgdGhlIERIQ1Agb3B0aW9uIG51
bWJlciB3b3VsZCBiZSwgYnV0IHRoYXQncyBub3QNCj4gcmVhbGx5DQo+IHRoZSBzYW1lIHRoaW5n
Lg0KPiANCj4gSSB0aGluayB5b3UgbmVlZCB0byBkZWNsYXJlIGVhY2ggREhDUCBzdWJvcHRpb24g
c3VwcG9ydGVkLiBObw0KPiBkaWZmZXJlbmNlIGZyb20NCj4gdGhlIGZvcm1hdCBkZXNjcmliZWQs
IGJ1dCBzaW1wbHkgZGVjbGFyaW5nIHRoZSBzdWJvcHRpb24gbnVtYmVyIGZvcg0KPiBlYWNoDQo+
IHN1cHBvcnRlZCBoYXNoIGFsZ29yaXRobSwgYW5kIG1heWJlIHN0YXRpbmcgc29tZXdoZXJlIHRo
YXQgdGhlc2UNCj4gc3Vib3B0aW9ucw0KPiBhcmUgYXR0ZW1wdGluZyB0byBwcm92aWRlIGEgb25l
LXRvLW9uZSBjb3JyZXNwb25kZW5jZSB0byB0aGUgSUFOQSBoYXNoDQo+IG51bWJlcnMuDQo+IA0K
PiAtIEJ1ZA0KPiANCj4gPiBUYSwNCj4gPiBNYXJ0aW4NCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0
bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYNCj4gPiA+IE9mIFRob21zb24s
IE1hcnRpbg0KPiA+ID4gU2VudDogTW9uZGF5LCA5IEZlYnJ1YXJ5IDIwMDkgOToyNiBBTQ0KPiA+
ID4gVG86IEdsZW4gWm9ybjsgQnVkIE1pbGx3b29kDQo+ID4gPiBDYzogZGhjd2dAaWV0Zi5vcmcN
Cj4gPiA+IFN1YmplY3Q6IFJlOiBbZGhjd2ddIGRyYWZ0LWlldGYtZ2VvcHJpdi1saXMtZGlzY292
ZXJ5IHVwZGF0ZWQNCj4gPiA+IGJhc2Vkb25ESEMgY29tbWVudHMNCj4gPiA+DQo+ID4gPiBJdCBz
ZWVtcyB0aGF0IEkgc2hvdWxkIHBheSBtb3JlIGF0dGVudGlvbiAtIHVudGlsIHRvZGF5LCBJIHdh
cyBzdXJlDQo+ID4gPiB0aGF0IFRMUyB1c2VkIGFuIE9JRCAobGlrZSBYLjUwOSkuICBTZWVtcyBs
aWtlIGFub3RoZXIgdXBkYXRlIGlzIGluDQo+ID4gPiBvcmRlcjogSSBqdXN0ICJmb3VuZCIgPGh0
dHA6Ly9pYW5hLm9yZy9hc3NpZ25tZW50cy90bHMtDQo+IHBhcmFtZXRlcnMvdGxzLQ0KPiA+ID4g
cGFyYW1ldGVycy54aHRtbCN0bHMtcGFyYW1ldGVycy0xNz4uDQo+ID4gPg0KPiA+ID4gVGhhdCdz
IGdvb2QsIGJlY2F1c2UgdGhlIG9wdGlvbiB3aWxsIHNpbXBseSBoYXZlIGEgInN1Yi1vcHRpb24i
DQo+IHR5cGUNCj4gPiA+IGZvcm1hdCwgd2l0aCBhbiBleHBsaWNpdCBpbmRpY2F0b3IgZm9yICJu
b25lIiwgd2hpY2ggaGVscHMgdG8NCj4gYW5zd2VyDQo+ID4gPiBCdWQncyBvdGhlciBxdWVzdGlv
biBtb3JlIGV4cGxpY2l0bHkuICAoVGhlIGFuc3dlciBpcyBpbiB0aGUNCj4gZG9jdW1lbnQNCj4g
PiA+IGFscmVhZHksIGJ1dCB0aGlzIGlzIGJldHRlci4pDQo+ID4gPg0KPiA+ID4gQ2hlZXJzLA0K
PiA+ID4gTWFydGluDQo+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
PiA+ID4gPiBGcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91bmNl
c0BpZXRmLm9yZ10gT24NCj4gPiA+DQo+ID4gPiBCZWhhbGYNCj4gPiA+DQo+ID4gPiA+IE9mIEds
ZW4gWm9ybg0KPiA+ID4gPiBTZW50OiBGcmlkYXksIDYgRmVicnVhcnkgMjAwOSA3OjQ0IFBNDQo+
ID4gPiA+IFRvOiAnQnVkIE1pbGx3b29kJw0KPiA+ID4gPiBDYzogZGhjd2dAaWV0Zi5vcmcNCj4g
PiA+ID4gU3ViamVjdDogUmU6IFtkaGN3Z10gZHJhZnQtaWV0Zi1nZW9wcml2LWxpcy1kaXNjb3Zl
cnkgdXBkYXRlZA0KPiBiYXNlZA0KPiA+ID4gPiBvbkRIQyBjb21tZW50cw0KPiA+ID4gPg0KPiA+
ID4gPiBCdWQgTWlsbHdvb2QgW21haWx0bzpidWRtQHdlaXJkLXNvbHV0aW9ucy5jb21dIHdyaXRl
czoNCj4gPiA+ID4NCj4gPiA+ID4gLi4uDQo+ID4gPiA+DQo+ID4gPiA+ID4gQWxzbywgZG9lcyBh
bnlvbmUga25vdyBpZiB0aGVyZSBpcyBhbiBJQU5BIHJlZ2lzdHJ5IGZvciBudW1lcmljDQo+ID4g
PiA+ID4gZGVzaWduYXRpb25zDQo+ID4gPiA+ID4gZm9yIGhhc2ggZnVuY3Rpb24gdHlwZXM/DQo+
ID4gPiA+DQo+ID4gPiA+IFl1cCwgc2V2ZXJhbCwgZm9yIEROU1NFQywgUEdQICYgVExTLCBhdCBs
ZWFzdC4NCj4gPiA+ID4NCj4gPiA+ID4gLi4uDQo+ID4gPiA+DQo+ID4gPiA+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IGRoY3dnIG1haWxp
bmcgbGlzdA0KPiA+ID4gPiBkaGN3Z0BpZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+ID4gPg0KPiA+ID4gLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAt
LS0tDQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiBUaGlzIG1lc3NhZ2Ug
aXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCj4gPiA+IGNvbnRh
aW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0
aW9uLg0KPiA+ID4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3Rp
ZnkgdGhlIHNlbmRlcg0KPiA+ID4gaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwu
ICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KPiA+ID4gdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVk
Lg0KPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tDQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQo+ID4gPiBbbWYyXQ0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCj4gPiA+IGRoY3dnIG1haWxpbmcgbGlzdA0KPiA+ID4gZGhjd2dAaWV0
Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cN
Cj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0NCj4gPi0tLS0tLS0tLS0tLS0tLS0tLS0t
LSBUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudA0KPiBvbmx5IGFu
ZA0KPiA+IG1heQ0KPiA+IGNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVy
d2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLg0KPiA+IElmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGlu
IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCj4gPiBpbW1lZGlhdGVseSBhbmQgZGVs
ZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQo+ID4gdGhpcyBlbWFp
bCBpcyBwcm9oaWJpdGVkLg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0NCj4gPi0tLS0tLS0t
LS0tLS0tLS0tLS0tLSBbbWYyXQ0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+ID4gZGhjd2cgbWFpbGluZyBsaXN0DQo+ID4gZGhjd2dAaWV0Zi5v
cmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+IA0K
PiANCj4gDQo+IC0tDQo+IEJ1ZCBNaWxsd29vZA0KPiBXZWlyZCBTb2x1dGlvbnMsIEluYy4NCj4g
aHR0cDovL3d3dy53ZWlyZC1zb2x1dGlvbnMuY29tDQo+IHRlbDogKzQ2IDggNzU4IDM3MDANCj4g
ZmF4OiArNDYgOCA3NTggMzY4Nw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkg
YW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHBy
aXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBw
bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdp
bmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4N
Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg==



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63483A67B4 for <[e-mail]>; Wed, 11 Feb 2009 01:34:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScPW-cnWQa53 for <[e-mail]>; Wed, 11 Feb 2009 01:34:56 -0800 (PST)
Received: from cl36.gs02.gridserver.com (cl36.gs02.gridserver.com [64.13.232.45]) by core3.amsl.com (Postfix) with ESMTP id 9D7AB3A63D3 for <[e-mail]>; Wed, 11 Feb 2009 01:34:56 -0800 (PST)
Received: from static-213-115-152-226.sme.bredbandsbolaget.se ([213.115.152.226]:57643 helo=offset.weird.se) by cl36.gs02.gridserver.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.63) (envelope-from <[e-mail]>) id 1LXBUi-0005py-DF; Wed, 11 Feb 2009 01:35:00 -0800
From: Bud Millwood <[e-mail]>
Organization: Weird Solutions, Inc.
To: [e-mail]
Date: Wed, 11 Feb 2009 10:27:23 +0100
User-Agent: KMail/1.9.9
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Authenticated-User: 39280 [e-mail]
Cc: "Thomson, Martin" <[e-mail]>
Subject: Re: [dhcwg] =?iso-8859-1?q?draft-ietf-geopriv-lis-discovery_updated_b?= =?iso-8859-1?q?asedonDHC=09comments?=
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Bud Millwood <[e-mail]>
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 11 Feb 2009 09:34:58 -0000

On Wednesday 11 February 2009, Thomson, Martin wrote:
> Hi Bud,
>
> Thanks for the feedback.  I'll address this in the next revision, which
> might have to wait until after SF.
>
> For my benefit, how do you distinguish between sub-options and what appears
> to be sub-options?  I assume that you are alluding to some sort of
> established convention for use of sub-options that is followed, such as
> formal registration of codes.

Yep, I was referring to the formal registration of the option codes.

> I'd like to avoid enumerating the codes.  That implies that updates to the
> TLS registry also require updates to this document.  Do you have any
> suggestions?

We just spent a little time here looking at ways to encode this option 
(LIS_CERT_FP), and our conclusion is that the format you've described is 
probably the cleanest and will have the widest deployment. The other 
possibilities for encoding this option seem contrived, and all for the 
purpose of not enumerating the DHCP suboption codes.

I'm not aware of any DHCP option or suboption that's meant to be inter-vendor 
operable that does not explicitly state the DHCP option code in a DHCP 
standards document.

It seems to me that your best bet is to enumerate the IANA hash algorithm 
values as DHCP suboption codes. :(

- Bud

> Cheers,
> Martin
>
> > -----Original Message-----
> > From: Bud Millwood [mailto:[e-mail]]
> > Sent: Wednesday, 11 February 2009 1:42 AM
> > To: [e-mail]
> > Cc: Thomson, Martin; Glen Zorn
> > Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated
> > basedonDHC comments
> >
> > On Monday 09 February 2009, Thomson, Martin wrote:
> > > I've just uploaded a new version that uses the single octet code
> >
> > point from
> >
> > > TLS to identify hashes (two for DHCPv6 so that they look like sub-
> >
> > options).
> >
> > >  I've also taken another pass at the text in an effort to make it
> >
> > easier to
> >
> > > understand (and to address Bud's question more explicitly).
> > >
> > > <http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lis-
> >
> > discovery-07.tx
> >
> > >t>
> >
> > I've been looking over this new draft, and it's getting better but
> > there's a
> > technicality:
> >
> > "Fingerprint-Sub-Options:  A series of one or more sub-options, as
> > shown in
> > Figure 4."
> >
> > These are not (yet) true sub-options in that they don't have an
> > assigned DHCP
> > (sub)option number. They look like sub-options, because they have a
> > hash
> > algorithm number where the DHCP option number would be, but that's not
> > really
> > the same thing.
> >
> > I think you need to declare each DHCP suboption supported. No
> > difference from
> > the format described, but simply declaring the suboption number for
> > each
> > supported hash algorithm, and maybe stating somewhere that these
> > suboptions
> > are attempting to provide a one-to-one correspondence to the IANA hash
> > numbers.
> >
> > - Bud
> >
> > > Ta,
> > > Martin
> > >
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:[e-mail]] On
> >
> > Behalf
> >
> > > > Of Thomson, Martin
> > > > Sent: Monday, 9 February 2009 9:26 AM
> > > > To: Glen Zorn; Bud Millwood
> > > > Cc: [e-mail]
> > > > Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated
> > > > basedonDHC comments
> > > >
> > > > It seems that I should pay more attention - until today, I was sure
> > > > that TLS used an OID (like X.509).  Seems like another update is in
> > > > order: I just "found" <http://iana.org/assignments/tls-
> >
> > parameters/tls-
> >
> > > > parameters.xhtml#tls-parameters-17>.
> > > >
> > > > That's good, because the option will simply have a "sub-option"
> >
> > type
> >
> > > > format, with an explicit indicator for "none", which helps to
> >
> > answer
> >
> > > > Bud's other question more explicitly.  (The answer is in the
> >
> > document
> >
> > > > already, but this is better.)
> > > >
> > > > Cheers,
> > > > Martin
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail] [mailto:[e-mail]] On
> > > >
> > > > Behalf
> > > >
> > > > > Of Glen Zorn
> > > > > Sent: Friday, 6 February 2009 7:44 PM
> > > > > To: 'Bud Millwood'
> > > > > Cc: [e-mail]
> > > > > Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated
> >
> > based
> >
> > > > > onDHC comments
> > > > >
> > > > > Bud Millwood [mailto:[e-mail]] writes:
> > > > >
> > > > > ...
> > > > >
> > > > > > Also, does anyone know if there is an IANA registry for numeric
> > > > > > designations
> > > > > > for hash function types?
> > > > >
> > > > > Yup, several, for DNSSEC, PGP & TLS, at least.
> > > > >
> > > > > ...
> > > > >
> > > > > _______________________________________________
> > > > > dhcwg mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/dhcwg
> > > >
> > > > -------------------------------------------------------------------
> >
> > ----
> >
> > > > -------------------------
> > > > This message is for the designated recipient only and may
> > > > contain privileged, proprietary, or otherwise private information.
> > > > If you have received it in error, please notify the sender
> > > > immediately and delete the original.  Any unauthorized use of
> > > > this email is prohibited.
> > > > -------------------------------------------------------------------
> >
> > ----
> >
> > > > -------------------------
> > > > [mf2]
> > > > _______________________________________________
> > > > dhcwg mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/dhcwg
> > >
> > > ---------------------------------------------------------------------
> >
> > ------
> >
> > >--------------------- This message is for the designated recipient
> >
> > only and
> >
> > > may
> > > contain privileged, proprietary, or otherwise private information.
> > > If you have received it in error, please notify the sender
> > > immediately and delete the original.  Any unauthorized use of
> > > this email is prohibited.
> > > ---------------------------------------------------------------------
> >
> > ------
> >
> > >--------------------- [mf2]
> > > _______________________________________________
> > > dhcwg mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dhcwg
> >
> > --
> > Bud Millwood
> > Weird Solutions, Inc.
> > http://www.weird-solutions.com
> > tel: [phone]
> > fax: [phone]
>
> ---------------------------------------------------------------------------
>--------------------- This message is for the designated recipient only and
> may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> ---------------------------------------------------------------------------
>--------------------- [mf2]
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg



-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: [phone]
fax: [phone]


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1621A3A6930; Thu, 12 Feb 2009 00:12:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-tu-ExZZ4tk; Thu, 12 Feb 2009 00:12:31 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6FE443A680A; Thu, 12 Feb 2009 00:12:31 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.38,196,1233532800"; d="scan'208";a="247967503"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 Feb 2009 08:12:36 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1C8CaUe016692;  Thu, 12 Feb 2009 00:12:36 -0800
Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1C8CaL4025713; Thu, 12 Feb 2009 08:12:36 GMT
Date: Thu, 12 Feb 2009 00:12:36 -0800 (PST)
From: Sri Gundavelli <[e-mail]>
To: Ralph Droms <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11672; t=1234426356; x=1235290356; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Sri=20Gundavelli=20<[e-mail]> |Subject:=20Re=3A=20[dhcwg]=20Review=20of=20draft-ietf-netl mm-pmip6-ipv4-support |Sender:=20; bh=bhBB2cw7i3BVa7brFAgnu7x/2+UoGKAz/k+s4wE2CEs=; b=YmOsbC7MGNrNSlAmoF/5T6seLY7PqUOD+eviwbH0LRer9c7Brbs4reGbCK 2+9L05BsMHyPQIYPmuabA9IcLCor+k5G8wa5Ue+BcmLRpGaYE+nchPhMKYq5 f3UOPUR9zt;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
Cc: Dhcwg WG <[e-mail]>, [e-mail], Ryuji Wakikawa <[e-mail]>
Subject: Re: [dhcwg] Review of draft-ietf-netlmm-pmip6-ipv4-support
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2009 08:12:33 -0000

Hi Ralph,

Sorry for the late reply. I seemed to have missed this... my error.
Please see inline.

On Tue, 3 Feb 2009, Ralph Droms wrote:

>
> On Feb 3, 2009, at 12:25 AM 2/3/09, Sri Gundavelli wrote:
>
>> 
>> Hi Ralph,
>> 
>> Thanks for the review. Please see inline.
>> 
>> 
>> 
>> On Mon, 2 Feb 2009, Sri Gundavelli wrote:
>> 
>> > 
>> > From: Ralph Droms <[e-mail]>
>> > To: Dhcwg WG <[e-mail]>
>> > Sent: Monday, February 2, 2009 12:54:01 PM
>> > Subject: [dhcwg] *THIRD TRY* Re: Review of 
>> > draft-ietf-netlmm-pmip6-ipv4-support
>> > 
>> > Here's my review of 
>> > http://tools.ietf.org/html/draft-ietf-netlmm-pmip6-ipv4-support-09 ; Jari 
>> > could use any additional comments in addition to my input.
>> > 
>> > The idea behind Proxy Mobile IPv6 is to provide "transparent" mobility 
>> > support for hosts, allowing them to switch attachment points without 
>> > invoking IPv6 mobility on the host.  This draft suggests extensions to to 
>> > Proxy Mobile IPv6 to allow the same sort of mobility for IPv4 hosts using 
>> > the Proxy Mobile IPv6 infrastructure.
>> > 
>> > Focusing on the use of DHCP in the draft ... unless I misunderstand the 
>> > way in which change-of-attachment/handoff will work, I think the text 
>> > labeled "IPv4 Home Address Renewal with a different DHCP server (After 
>> > Handoff):" in section 3.4.1 needs to be revised and a new section needs 
>> > to be added to section 3.4.2.
>> > 
>> 
>> Ok, We can organize it better, will try to break that into a section.
>
> I don't see any text in 3.4.2 that addresses the problem of address renewal 
> through a new relay agent (and, potentially, a new server).  I think that 
> text needs to be added.  In general, the same scenarios apply to both 
> sections 3.4.1 and 3.4.2, so I would expect both sections would be structured 
> pretty much the same.
>

For both Section 3.4.1 and 3.4.2, Co-locoted Relay or Server mode, we have
covererd the cases of Initil Address Renewal, Address Renewal when no
handoff and Address renewal after the handoff. We have stated the
requirements on how to make it work, probably we need to add any text on
the potential issues. Sure, will add this.



>> > I don't think the scenario described under "IPv4 Home Address Renewal 
>> > with a different DHCP server (After Handoff):" will ever occur, unless 
>> > the mobile host can somehow switch attachment points without notifying 
>> > the DHCP client to cause the client to go into INIT-REBOOT state. 
>> > Therefor, I think the associated text should be replaced with text that 
>> > describes the scenario in which the mobile host has switched attachment 
>> > points and broadcasts a DHCPREQUEST in INIT-REBOOT state.  Section 3.4.2 
>> > needs to be extended with similar text that describes the scenario in 
>> > which the mobile host has switched attachment.
>> > 
>> 
>> For the link-layers where this protocol be deployed will ensure the
>> mobile does not detect a link change, Ex: when the access link is
>> a PPP link, the handoff will ensure the mobile does not detect link
>> change and so it should not go into INIT-REBOOT state, rather should
>> perorm a DHCP renew.
>
> Hm.  Well, OK, then that scenario should be described or a reference cited, 
> as it wasn't obvious to me.  Will PPP always be in use - and if PPP is used, 
> will DHCP still be used for address assignment?  If PPP is in use, where is 
> the endpoint of the PPP tunnel?  To mask a switch of attachment points, 
> wouldn't the PPP endpoint have to be in the mobile node?  Which, in turn, 
> means that any DHCP traffic would traverse the PPP tunnel, bypassing the MAG? 
> Or am I totally confused?
>

If the underneath layer-2 technology, makes the mobile not detect the
handoff, the mobile after handoff should not reset any of its protocol
states. Depends on the access technology, PPP with PPP session context
transfer is one mode. We can state the requirements around this and else
the potential issue of client DHCP state reset. Will add some text.


> In any event, if the mobile node can, in some scenarios, detect link 
> attachment, text for the link reattachment case needs to be added.
>

Sure

>> > Unless I just missed the text, it would be good to clarify that the "IPv4 
>> > Default-Router Address" received from the LMA needs to be forwarded 
>> > through DHCP to the mobile host.  How does the DHCP server determine the 
>> > subnet mask to send to the mobile host?  Might be helpful to add a table 
>> > with the required options and the sources of the values for those 
>> > options.
>> > 
>> 
>> The prefix length is present in the IPv4 Home Address option. This
>> is carried in the PMIP flows for allowing the MAG to be a default
>> router. The assignment of the same in DHCP flows is assumed.
>
> OK, for clarity I recommend adding text that explicitly lists what options 
> are required in the DHCP exchange between the mobile node and the DHCP server 
> and how those options such as Router, Subnet Mask, IP Address Lease Time and 
> Server Identifier are determined.
>
> I just noticed that this text from section 3.4.1 appears to be wrong:
>
>      The server
>      address, 'siaddr' field of the DHCPOFFER message, will be set to
>      the mobile node's default-router address.
>

We probably discussed this a year back with you. By setting the siaddr
to the def-router address for that mobile, we are forcing the same address
for the server on any link.


> It should refer, I think, to the Router option, not the 'siaddr' field.
>
>> > Editorial aside - and it may be too late to change at this point - why 
>> > bother with "alignment"?  Is there really an advantage to putting data 
>> > values on 32-bit boundaries these days in a control protocol?
>> > 
>> 
>> I assume this is about the IPv4 Default-Router address option. We did
>> not make any efforts to achieve that, just put the reserved field in
>> between.
>
> OK.
>
>> > How does the MAG identify the LMA for the host?
>> > 
>> 
>> This is from the policy profile, as specified in RFC-5213.
>
> OK.
>
>> > Sections 3.4.1 and 3.4.2 (Figures 6 and 7) show different orders for the 
>> > DHCPDISCOVER and Proxy Mobile IPv6 signaling events.  The text for the 
>> > figures explains that these messages can occur in any order.  In what 
>> > situation would the Proxy Mobile IPv6 signaling begin before the 
>> > DHCPDISCOVER is received?  If, in section 3.4.1, the Proxy Mobile IPv6 
>> > signaling can take place before the DHCPDISCOVER is received by the DHCP 
>> > server, doesn't the DHCP server have to check to see if it already has an 
>> > IPv4 address for the mobile host, as suggested in this text from section 
>> > 3.4.2: "check if there is already an assigned IPv4 home address for the 
>> > mobile node from the local mobility anchor"?
>> > 
>> 
>> > How do DHCP address lease times and address assignments from LMAs 
>> > interact?
>> 
>> We probably should add a note on keeping the DHCP address lease time
>> lower than the PMIPv6 binding life time, as we did in RFC-5213. We
>> will add a note on this relation.
>
> It might be possible to use T1 effectively here, to force the mobile node to 
> confirm its lease in the case where the DHCP lease extends beyond the binding 
> lifetime.
>
> However, there are a couple of fundamental coordination problems.  First, if 
> DHCPFORCERENEW is not available, the DHCP address lease or T1 time must be 
> coordinated to cause the mobile node to contact the DHCP service very soon 
> after the potential binding lifetime expiration.  That is, the mobile node 
> must poll the DHCP service soon after binding lifetime expires to minimize 
> the time during which the mobile node continues to use the address with 
> expired binding.
>
> The second problem is coordinating the binding lifetimes and DHCP leases 
> through the DHCP server.  You need to explain how the DHCP server is made 
> aware of the binding lifetime so it returns the appropriate lease information 
> to the mobile node.
>

As in 5213, we can have this as a out of band requirement, to
ensure the lease lifetimes and binding lifetimes have relation. Even
other wise, for the case when the binding lifetime expires and even
when there is active DHCP lease, the MAG can pretty much tear down
the p2p link and force the client to reset its DHCP state.



>> > Section 3.4.1 mentions the use of DHCPFORCERENEW, which is not 
>> > universally implemented today.
>> > 
>> 
>> Sure. We did take that into consideration and provided few alternative
>> approaches of handling this.
>
> I don't see any alternative to the use of DHCPFORCERENEW in the case where 
> the binding lifetime is not extended (e.g., last paragraph of section 3.4.1).
>

Right after RFC page 27, we have listed two approaches, the use of fixed
DHCP server address and the Forcerenew option. I think, we need to
structure this sub sections, as you pointed out.


> This text in section 3.4.1 seems to assume the mobile node implements 
> DHCPFORCERENEW:
>
>   o  If the mobile access gateway on the access link receives any DHCP
>      messages from the mobile node unicasted to a server address that
>      is not locally configured, the mobile access gateway can unicast
>      FORCERENEW message [RFC-3203] to the mobile node as shown in
>      Figure 6-2).  This will force the mobile node to update the DHCP
>      server address with the address of the mobile access gateway on
>      the new link.  However, if the FORCERENEW message [RFC-3203] is
>      also not supported by the DHCP server on the mobile access
>      gateway, then that DHCPREQUEST message can be ignored.  This will
>      force the mobile node to enter the DHCP REBINDING state [RFC-2131]
>      and start the DHCPDISCOVER phase again.
>
> ...it mentions the case in which the server does not implement 
> DHCPFORCERENEW, but does not mention the case in which the mobile node does 
> not implement DHCPFORCERENEW.  The text also does not mention that the mobile 
> node will not move to REBINDING state until time T2, which may be a 
> significant delay.
>
> That observation suggests a way to avoid DHCPOFORCERENEW - set time T2 to be 
> shortly after T1 to force the mobile node into REBINDING state quickly.  I 
> would advise setting T2 to be one second later than T1 - in theory, T2 could 
> be set to occur at the same time (or even before!) T1 ... but I won't 
> guarantee that all DHCP clients will handle T2 <= T1 correctly.
>
> I assume the binding can expire in the DHCP scenario described in section 
> 3.4.2 as well; how will binding expiration be handled in that scenario? 
> Spec., how will the DHCP server know when the binding expires so it can send 
> a DHCPFORCERENEW?
>

The MAG can tear the link down and force the client to init state. We will
add this for both 3.4.1 and 3.4.2


>> > Does the text about DHCPRELEASE in section 3.4.2 also apply to section 
>> > 3.4.1?
>> 
>> Yes. In both the modes of operation, the MAG's behaviour of session
>> disconnect when it detects the mobile node releasing the address
>> is same.
>
> OK, so the text in 3.4.2 should be pulled out to a section that applies to 
> both scenarios, or it should be duplicated in section 3.4.1.
>
>> Thanks again for the review.
>> 
>> Regards
>> Sri
>
> Hope these comments are helpful...
>

Absolutely. Thanks for your review.

Regards
Sri

> - Ralph
>
>
>
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9259628C10A for <[e-mail]>; Fri, 13 Feb 2009 16:34:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uREV-US7Vpnt for <[e-mail]>; Fri, 13 Feb 2009 16:34:17 -0800 (PST)
Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by core3.amsl.com (Postfix) with ESMTP id 0F5A928C104 for <[e-mail]>; Fri, 13 Feb 2009 16:34:17 -0800 (PST)
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 ESMTPS id 94F6C11401F for <[e-mail]>; Sat, 14 Feb 2009 00:34:15 +0000 (UTC) (envelope-from [e-mail])
Received: by farside.isc.org (Postfix, from userid 10292) id 70A49E6073; Sat, 14 Feb 2009 00:34:15 +0000 (UTC)
Date: Sat, 14 Feb 2009 00:34:15 +0000
From: Evan Hunt <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Subject: [dhcwg] draft-hunt-dhcpv6-clarify-mrc-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 14 Feb 2009 00:34:18 -0000

Hello everyone,

About a year ago--I believe it was at the DHCPv6 Bakeoff held in Vancouver
after IETF 70--Francis Dupont and David Hankins noted that some DHCPv6
implementations were failing the Tahi test suite due to a disagreement
over the precise meaning of the MRC variable in RFC 3315.

I've just submitted a short draft describing the problem and suggesting a
resolution.  Feedback welcome.  It's my first I-D, so be gentle with me.


-- Forwarded message from IETF I-D Submission Tool <[e-mail]> --
From: IETF I-D Submission Tool <[e-mail]>
Subject: New Version Notification for draft-hunt-dhcpv6-clarify-mrc-00 
Date: Fri, 13 Feb 2009 16:27:27 -0800 (PST)


A new version of I-D, draft-hunt-dhcpv6-clarify-mrc-00.txt has been successfuly submitted by Evan Hunt and posted to the IETF repository.

Filename:	 draft-hunt-dhcpv6-clarify-mrc
Revision:	 00
Title:		 DHCPv6 MRC Clarification
Creation_date:	 2009-02-13
WG ID:		 Independent Submission
Number_of_pages: 4

Abstract:
The definition of the Maximum Retransmission Count (MRC) variable
described in RFC 3315 is clarified to resolve an ambiguity.
                                                                                  


The IETF Secretariat.
-- End forwarded message --

-- 
Evan Hunt -- [e-mail]
Internet Systems Consortium, Inc.


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 0105C3A682A; Fri, 13 Feb 2009 17:00:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri, 13 Feb 2009 17:00:02 -0800 (PST)
Cc: [e-mail]
Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv4-bulk-leasequery-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 14 Feb 2009 01:00:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.


	Title           : Bulk DHCPv4 Lease Query
	Author(s)       : K. Kinnear, et al.
	Filename        : draft-ietf-dhc-dhcpv4-bulk-leasequery-00.txt
	Pages           : 43
	Date            : 2009-02-13

The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been
extended with a Leasequery capability that allows a requestor to
request information about DHCPv4 bindings.  That mechanism is limited
to queries for individual bindings.  In some situations individual
binding queries may not be efficient, or even possible.  This
document expands on the DHCPv4 Leasequery protocol to allow for bulk
transfer of DHCPv4 address binding data via TCP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-bulk-leasequery-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-dhc-dhcpv4-bulk-leasequery-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856973A6925 for <[e-mail]>; Sun, 15 Feb 2009 10:53:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.907
X-Spam-Level: 
X-Spam-Status: No, score=-4.907 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJ6CJghe2WYx for <[e-mail]>; Sun, 15 Feb 2009 10:53:03 -0800 (PST)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 9E9213A6824 for <[e-mail]>; Sun, 15 Feb 2009 10:53:03 -0800 (PST)
Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP  id 5503620.27335905; Sun, 15 Feb 2009 13:52:38 -0500
Received: from NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Feb 2009 13:52:37 -0500
Received: from 68.44.29.26 ([68.44.29.26]) by NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Sun, 15 Feb 2009 18:52:37 +0000
User-Agent: Microsoft-Entourage/12.10.0.080409
Date: Sun, 15 Feb 2009 13:52:34 -0500
From: John Jason Brzozowski <[e-mail]>
To: dhc WG <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Request for Agenda Items
Thread-Index: AcmPno/7YYN1l39ws0SttRGMlLd56Q==
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 15 Feb 2009 18:52:37.0611 (UTC) FILETIME=[922283B0:01C98F9E]
Cc: dhc Chairs <[e-mail]>
Subject: [dhcwg] Request for Agenda Items
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 15 Feb 2009 18:53:04 -0000

Please send your requests for agenda items to Ralph and myself for the
IETF74 dhc WG meeting.

Thanks,

Ralph and John



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0B1F3A68B2 for <[e-mail]>; Tue, 17 Feb 2009 00:58:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe+X1sim9Wvn for <[e-mail]>; Tue, 17 Feb 2009 00:58:35 -0800 (PST)
Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 1E3133A6877 for <[e-mail]>; Tue, 17 Feb 2009 00:58:35 -0800 (PST)
Received: by yw-out-2324.google.com with SMTP id 5so2719707ywh.49 for <[e-mail]>; Tue, 17 Feb 2009 00:58:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=jaa8zWOXi5gB6h1WrHdKbyuGxFaIm25u6o14o/hYr5k=; b=stm0guF6ZUgU1z9+g4O7Q7de+YJaSqIDe8f0QCUt3I7+HK0QKDrs/lbmDrN9RF6qp8 AEiKnlyHu0mS1rWV8IiZfzWWueK0bKg/OpY8Ay14h1J4F7jZcKg+AOVu4Lx1verbDnjm JC6DbumLNBBzyNdvT9zMYXBigWpVjfwlnL4i4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EcZGnzSLWblq3Ae6X/kxHUwSzROpOhKH/5+WrZQv4OQRPmJWfVlN+kXa2ol7wu8/WO M7+s/h+RL1l3E4QMsZmw9kmhOsVII5/9gVwJl46uUHYqJxrsZD6OHq+LiA7HNQfZMWRG J2I0DOjjx36LwKXVH0/JDs8cfrXc+SL4SijQQ=
MIME-Version: 1.0
Received: by 10.100.173.18 with SMTP id v18mr7502769ane.17.1234861125336; Tue,  17 Feb 2009 00:58:45 -0800 (PST)
Date: Tue, 17 Feb 2009 16:58:45 +0800
Message-ID: <[e-mail]>
From: Peny Yang <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: McCann Peter-A001034 <[e-mail]>
Subject: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 17 Feb 2009 08:58:35 -0000

Hi, DHC Folks:

I have a question on the DHCPv4 server behavior for DHCPINFORM.
When the server receives DHCPINFORM with non-zero ciaddr and non-zero
giaddr respectively, which address should server send DHCPACK to? To
client (ciaddr)? Or to DHCP relay node (giaddr)?

It seems current RFC2131 has somewhat conflicting statements:

===>in section 3.4, it was said
The servers SHOULD unicast the DHCPACK reply to the address given in
the 'ciaddr' field of the DHCPINFORM message.

===>in section 4.1, it was said:
If the 'giaddr' field in a DHCP message from a client is non-zero, the
server sends any return messages to the 'DHCP server' port on the
BOOTP relay agent whose address appears in 'giaddr'

And, I checked the dhcpd implementation, ciaddr is chosen in this case.

I am a little confused on which way to follow. Your help is appreciated.

Thanks
BRG
Peny


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9FCA3A6954 for <[e-mail]>; Tue, 17 Feb 2009 06:26:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.604
X-Spam-Level: 
X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgoTPqfYy58Y for <[e-mail]>; Tue, 17 Feb 2009 06:26:26 -0800 (PST)
Received: from web95301.mail.in2.yahoo.com (web95301.mail.in2.yahoo.com [203.104.18.201]) by core3.amsl.com (Postfix) with SMTP id F08AA3A67A5 for <[e-mail]>; Tue, 17 Feb 2009 06:26:25 -0800 (PST)
Received: (qmail 93627 invoked by uid 60001); 17 Feb 2009 14:26:35 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=W8RSBRFSuHUlKzoaDx/oRJXHSSi9otvwAAqCseMJT4o+lU81bJMu74EeReUkUMQ6P2G593v4jdofCwvYNVS3CbN4+ln4fy9etkl/gE5rMyivz1T1wGcc58HIZYGwm6TvZClkbocB389sLYXN25fJB0fhlZ9kfyNwgnCU3hjiSVM=;
X-YMail-OSG: ZePPl_QVM1mOEsD4bD2JFaJzfht1f_MT3JUzUyrZb2NGrZT3F0R_9hqIFqNYSIJERMUJGWky8RuySlhBaDaOigDST5M_dyI2DRqlokkotvzr2HGvdf6cRizP7XX4pV4berFjko2aaofFC2DQY8deXzqh0fol9MJLZETK3UoA3Y2Vw0_TI7m46s4cPjlg_GuwxhchVb_t0qDJgOU-
Received: from [72.163.216.217] by web95301.mail.in2.yahoo.com via HTTP; Tue, 17 Feb 2009 19:56:34 IST
X-Mailer: YahooMailWebService/0.7.260.1
Date: Tue, 17 Feb 2009 19:56:34 +0530 (IST)
From: GAURAV HALWASIA <[e-mail]>
To: [e-mail], Peny Yang <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1709203283-1234880794=:93390"
Message-ID: <[e-mail]>
Cc: McCann Peter-A001034 <[e-mail]>
Subject: Re: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 17 Feb 2009 14:26:27 -0000

--0-1709203283-1234880794=:93390
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Peny,
=C2=A0
There is a clarify draft on DHCPINFORM in ietf.
http://ietfreport.isoc.org/all-ids/draft-dhankins-dhcpinform-clarify-00.txt
=C2=A0
=C2=A0
The draft clearly indicates that DHCP server should send an unicast reply t=
o the "ciaddr" if present. In "ciaddr" is 0, then the ACK should be unicast=
ed to the "giaddr".=C2=A0

<snip>
=C2=A0Next, the DHCPv4 server MUST determine the "reply IPv4 address and
=C2=A0=C2=A0 port" according to the following priority list:

=C2=A0=C2=A0 1.=C2=A0 The 'ciaddr' field and port 68 ('DHCP client'), if it=
 is nonzero.

=C2=A0=C2=A0 2.=C2=A0 The 'giaddr' field and port 67 ('DHCP server'), if it=
 is nonzero.
=C2=A0</snip>

=C2=A0
Thanks,
Gaurav

--- On Tue, 17/2/09, Peny Yang <[e-mail]> wrote:

From: Peny Yang <[e-mail]>
Subject: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM
To: [e-mail]
Cc: "McCann Peter-A001034" <[e-mail]>
Date: Tuesday, 17 February, 2009, 2:28 PM

Hi, DHC Folks:

I have a question on the DHCPv4 server behavior for DHCPINFORM.
When the server receives DHCPINFORM with non-zero ciaddr and non-zero
giaddr respectively, which address should server send DHCPACK to? To
client (ciaddr)? Or to DHCP relay node (giaddr)?

It seems current RFC2131 has somewhat conflicting statements:

=3D=3D=3D>in section 3.4, it was said
The servers SHOULD unicast the DHCPACK reply to the address given in
the 'ciaddr' field of the DHCPINFORM message.

=3D=3D=3D>in section 4.1, it was said:
If the 'giaddr' field in a DHCP message from a client is non-zero, the
server sends any return messages to the 'DHCP server' port on the
BOOTP relay agent whose address appears in 'giaddr'

And, I checked the dhcpd implementation, ciaddr is chosen in this case.

I am a little confused on which way to follow. Your help is appreciated.

Thanks
BRG
Peny
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg
=0A=0A=0A      Get perfect Email ID for your Resume. Grab now http://in.pro=
mos.yahoo.com/address
--0-1709203283-1234880794=:93390
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV>Hi Peny,</DIV>
<DIV>&nbsp;</DIV>
<DIV>There is a clarify draft on DHCPINFORM in ietf.</DIV>
<DIV><A href=3D"http://ietfreport.isoc.org/all-ids/draft-dhankins-dhcpinfor=
m-clarify-00.txt">http://ietfreport.isoc.org/all-ids/draft-dhankins-dhcpinf=
orm-clarify-00.txt</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>The draft clearly indicates that DHCP server should send an unicast re=
ply to the "ciaddr" if present. In "ciaddr" is 0, then the ACK should be un=
icasted to the "giaddr".&nbsp;<BR><SNIP></DIV>
<DIV>&lt;snip&gt;<BR>&nbsp;Next, the DHCPv4 server MUST determine the "repl=
y IPv4 address and<BR>&nbsp;&nbsp; port" according to the following priorit=
y list:<BR><BR>&nbsp;&nbsp; 1.&nbsp; The 'ciaddr' field and port 68 ('DHCP =
client'), if it is nonzero.<BR><BR>&nbsp;&nbsp; 2.&nbsp; The 'giaddr' field=
 and port 67 ('DHCP server'), if it is nonzero.<BR></SNIP>&nbsp;&lt;/snip&g=
t;<BR></DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,</DIV>
<DIV>Gaurav<BR><BR>--- On <B>Tue, 17/2/09, Peny Yang <I>&lt;peng.yang.chn@g=
mail.com&gt;</I></B> wrote:<BR></DIV>
<BLOCKQUOTE style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(=
16,16,255) 2px solid">From: Peny Yang &lt;[e-mail]&gt;<BR>Su=
bject: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM<BR>To: dhc=
[e-mail]<BR>Cc: "McCann Peter-A001034" &lt;[e-mail]&gt;<=
BR>Date: Tuesday, 17 February, 2009, 2:28 PM<BR><BR><PRE>Hi, DHC Folks:

I have a question on the DHCPv4 server behavior for DHCPINFORM.
When the server receives DHCPINFORM with non-zero ciaddr and non-zero
giaddr respectively, which address should server send DHCPACK to? To
client (ciaddr)? Or to DHCP relay node (giaddr)?

It seems current RFC2131 has somewhat conflicting statements:

=3D=3D=3D&gt;in section 3.4, it was said
The servers SHOULD unicast the DHCPACK reply to the address given in
the 'ciaddr' field of the DHCPINFORM message.

=3D=3D=3D&gt;in section 4.1, it was said:
If the 'giaddr' field in a DHCP message from a client is non-zero, the
server sends any return messages to the 'DHCP server' port on the
BOOTP relay agent whose address appears in 'giaddr'

And, I checked the dhcpd implementation, ciaddr is chosen in this case.

I am a little confused on which way to follow. Your help is appreciated.

Thanks
BRG
Peny
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg
</PRE></BLOCKQUOTE></td></tr></table><br>=0A      <!--3--><hr size=3D1></hr=
> Get rid of Add-Ons in your email ID. Get [e-mail]. <a href=
=3D"http://in.rd.yahoo.com/tagline_dbid_7/*http://in.promos.yahoo.com/addre=
ss" target=3D"_blank">Sign up now!</a>
--0-1709203283-1234880794=:93390--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC85B3A6A84 for <[e-mail]>; Tue, 17 Feb 2009 09:06:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level: 
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfQbJthBHplI for <[e-mail]>; Tue, 17 Feb 2009 09:06:47 -0800 (PST)
Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id 1752C3A68C0 for <[e-mail]>; Tue, 17 Feb 2009 09:06:46 -0800 (PST)
Received: from hcf.isc.org (dhcp-186.sql1.isc.org [204.152.187.186]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id n1HH6nH8012809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 09:06:50 -0800
Received: by hcf.isc.org (Postfix, from userid 10200) id C0CA757354; Tue, 17 Feb 2009 09:08:47 -0800 (PST)
Date: Tue, 17 Feb 2009 09:08:47 -0800
From: "David W. Hankins" <[e-mail]>
To: Peny Yang <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn"
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: DHC WG <[e-mail]>
Subject: Re: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 17 Feb 2009 17:06:47 -0000

--bp/iNruPH9dso1Pn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 17, 2009 at 04:58:45PM +0800, Peny Yang wrote:
> I have a question on the DHCPv4 server behavior for DHCPINFORM.
> When the server receives DHCPINFORM with non-zero ciaddr and non-zero
> giaddr respectively, which address should server send DHCPACK to? To
> client (ciaddr)? Or to DHCP relay node (giaddr)?

Hi Peny,

One of the things I noticed while writing the dhcpinform-clarify
first draft (I really should get the WG item version in...) was that
you can't unicast reply to clients via BOOTP relay agents (giaddr).

The trouble is that BOOTP relay agents will forward the unicast on
to the MAC:IP of chaddr:yiaddr field contents.  Even if chaddr is
filled in by the client (and consquently echoed by the server),
yiaddr must be zeroed in DHCPINFORM exchanges, as DHCPINFORM is not
used to assign addresses.

This asks the relay agent to unicast the reply to the all-zeroes IP
address.  :(

So it is most preferable to unicast directly to ciaddr (as you
pointed out, the only normative language on the subject of DHCPINFORM
in RFC 2131!).  This is the only thing that I think the WG is sure
about on the subject, or at least no one has disagreed with.  It is
only if ciaddr is zero that you might "consider other methods," which
I list by priority in my draft, but there has not been a great deal of
agreement.  The opposing view is that any ciaddr-zeroed DHCPINFORM
must be dropped.

I hope this helps.

--=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

--bp/iNruPH9dso1Pn
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkma7x4ACgkQcXeLeWu2vmqhAgCePkDYOFepl/hy34ESHZ0SAT4j
FTkAoIUM8Of6fM1sgI6oU1WdVPMFP83Q
=M774
-----END PGP SIGNATURE-----

--bp/iNruPH9dso1Pn--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769DA28C101 for <[e-mail]>; Tue, 17 Feb 2009 10:26:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmF8A3bWaJLS for <[e-mail]>; Tue, 17 Feb 2009 10:26:42 -0800 (PST)
Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id AFB923A6C2A for <[e-mail]>; Tue, 17 Feb 2009 10:26:42 -0800 (PST)
Received: from hcf.isc.org (dhcp-186.sql1.isc.org [204.152.187.186]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id n1HIQoUQ015680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 17 Feb 2009 10:26:51 -0800
Received: by hcf.isc.org (Postfix, from userid 10200) id 75E8157354; Tue, 17 Feb 2009 10:28:48 -0800 (PST)
Date: Tue, 17 Feb 2009 10:28:48 -0800
From: "David W. Hankins" <[e-mail]>
To: DHC WG <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wq9mPyueHGvFACwf"
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.17 (2007-11-01)
Subject: Re: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 17 Feb 2009 18:26:43 -0000

--wq9mPyueHGvFACwf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 17, 2009 at 09:23:05AM -0800, Andre Kostur wrote:
> Wouldn't sending to the CIADDR fail in MPLS-type deployments?  I can't
> find the draft/RFC right now (draft-ietf-dhc-agent-vpn-id ?), but I

Actually, it's any situation where the server and client can not send
packets directly between themselves, VPNs and MPLS may both fit that,
but neither is a strict requirement.

I think you're after RFC 5107 - the Server-Identifier Override Relay
Agent Information SubOption.

You're damned in either case here; if you reply via giaddr, it is
broken (relay will unicast to zeroed yiaddr), if you don't reply via
giaddr, it is still broken, as the direct unicast won't reach the
client.

So I think this is a flaw in RFC 5107 that sadly we didn't think of by
the time of its publication.

> Additionally, doesn't section 4.1 of RFC 2131 spell out that if there is
> a GIADDR, it's supposed to be used in preference to the CIADDR?

It's a good question!  One I hadn't even thought to consider before,
as I figured this section was a victim to DHCPv4's overloaded
messages.  There is some text in 4.1 that leads me to believe that
the author was presuming only those situations where the client
was broadcasting its queries (there is an implication that giaddr
can reliably be used to determine if the client is or isn't on the
same link as the server, which is not true in DHCPINFORM or
DHCPREQUEST direct unicasts to the server).

But we are talking about clarification, so either clarification should
be valid, it's just a matter of picking one.

But if the clarification is that DHCPINFORM should be sent to giaddr
identically to other messages, then I think BOOTP relays need
clarification for how to deal with zeroed yiaddrs, or we need to
specify that DHCP servers must copy ciaddr to yiaddr in the reply.

This seems like a violation of 'yiaddr' field semantics to me.

--=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

--wq9mPyueHGvFACwf
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmbAd0ACgkQcXeLeWu2vmqdkACgjMJhM9KgoCs05AUc8th6oAGi
5uMAoIyvAEiWDHg0yLYtdjHpwid9eFD5
=omIz
-----END PGP SIGNATURE-----

--wq9mPyueHGvFACwf--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 2B2D93A6862; Tue, 17 Feb 2009 15:00:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 17 Feb 2009 15:00:01 -0800 (PST)
Cc: [e-mail]
Subject: [dhcwg] I-D Action:draft-ietf-dhc-option-guidelines-04.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 17 Feb 2009 23:00:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.


	Title           : Guidelines for Creating New DHCP Options
	Author(s)       : D. Hankins
	Filename        : draft-ietf-dhc-option-guidelines-04.txt
	Pages           : 17
	Date            : 2009-02-17

This document seeks to provide guidance to prospective DHCP Option
authors, to help them in producing option formats that are easily
adoptable.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-dhc-option-guidelines-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AAB028C17E for <[e-mail]>; Tue, 17 Feb 2009 15:05:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.393
X-Spam-Level: 
X-Spam-Status: No, score=-5.393 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_00=-2.599, FAKE_REPLY_C=2.012, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zqi92MVXFnG8 for <[e-mail]>; Tue, 17 Feb 2009 15:05:22 -0800 (PST)
Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id 750C228C189 for <[e-mail]>; Tue, 17 Feb 2009 15:05:22 -0800 (PST)
Received: from hcf.isc.org (dhcp-186.sql1.isc.org [204.152.187.186]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id n1HN5Y33025305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 17 Feb 2009 15:05:34 -0800
Received: by hcf.isc.org (Postfix, from userid 10200) id 60B1F57354; Tue, 17 Feb 2009 15:07:32 -0800 (PST)
Date: Tue, 17 Feb 2009 15:07:32 -0800
From: "David W. Hankins" <[e-mail]>
To: DHC WG <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82evfD9Ogz2JrdWZ"
Content-Disposition: inline
User-Agent: Mutt/1.5.17 (2007-11-01)
Subject: Re: [dhcwg] draft-ietf-dhc-option-guidelines-04
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 17 Feb 2009 23:05:29 -0000

--82evfD9Ogz2JrdWZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Revision 4 of this draft is up.  The main change is the inclusion of a
new section "The Dangers of Sub Options" (queue dramatic music).  I've
also passed through the rest of the body for some simpler wording.

Review is welcome as always.

--=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

--82evfD9Ogz2JrdWZ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmbQzMACgkQcXeLeWu2vmrWegCguLj2EkF6xUF2evUMHosFxYcp
EykAniBKGCdAuJNDfy7kdnz6+z127Gz2
=5aTG
-----END PGP SIGNATURE-----

--82evfD9Ogz2JrdWZ--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BDDD28C1A1 for <[e-mail]>; Tue, 17 Feb 2009 23:20:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdkUd4LSBN-X for <[e-mail]>; Tue, 17 Feb 2009 23:20:18 -0800 (PST)
Received: from mail-gx0-f222.google.com (mail-gx0-f222.google.com [209.85.217.222]) by core3.amsl.com (Postfix) with ESMTP id 440D43A6980 for <[e-mail]>; Tue, 17 Feb 2009 23:20:18 -0800 (PST)
Received: by gxk22 with SMTP id 22so5069442gxk.13 for <[e-mail]>; Tue, 17 Feb 2009 23:20:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZBDBG4RZ0LTgts7vGPQGRzgbc4zwy+iWdN4tICHeWKE=; b=nOsqScqA2WAcwV4uAS8KFWk+jpGGfRrqbZmN3iRc8p59aiZjCMYUrc6NScWKss93Q8 queziEdBU8So7qGkYLOVmLEGJTkADkSN5kFxl/8a2qYrEWr8ECL+quc+fN+eP3dEAexq N60iItW9gcWSN0Q+7xcYXajg7uTQudQb2cjRk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oG7TN3HzAolWKycdGeaoxLDJLnRX8CY5XvmlnfGGSkgVGcnYHA2gNnA4xYUC7bdfB6 CyuucOFlMI66q6YdVPfGAmmON7MvlDCOfY6RAINlqAEAF8/Ruj1RcskbXKbCLkyC0woU o4JWih1ZgFqnYYzZP90z3mOmbwJezqN3Z3/aY=
MIME-Version: 1.0
Received: by 10.100.141.10 with SMTP id o10mr5561781and.145.1234941628163;  Tue, 17 Feb 2009 23:20:28 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Wed, 18 Feb 2009 15:20:28 +0800
Message-ID: <[e-mail]>
From: Peny Yang <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail], McCann Peter-A001034 <[e-mail]>
Subject: Re: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 18 Feb 2009 07:20:19 -0000

Hi, Gaurav:

Thanks for the clarification.
Ciaddr is the only choice for this case.

BRG
Peny

On Tue, Feb 17, 2009 at 10:26 PM, GAURAV HALWASIA
<[e-mail]> wrote:
> Hi Peny,
>
> There is a clarify draft on DHCPINFORM in ietf.
> http://ietfreport.isoc.org/all-ids/draft-dhankins-dhcpinform-clarify-00.txt
>
>
> The draft clearly indicates that DHCP server should send an unicast reply to
> the "ciaddr" if present. In "ciaddr" is 0, then the ACK should be unicasted
> to the "giaddr".
> <snip>
>  Next, the DHCPv4 server MUST determine the "reply IPv4 address and
>    port" according to the following priority list:
>
>    1.  The 'ciaddr' field and port 68 ('DHCP client'), if it is nonzero.
>
>    2.  The 'giaddr' field and port 67 ('DHCP server'), if it is nonzero.
>  </snip>
>
> Thanks,
> Gaurav
>
> --- On Tue, 17/2/09, Peny Yang <[e-mail]> wrote:
>
> From: Peny Yang <[e-mail]>
> Subject: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM
> To: [e-mail]
> Cc: "McCann Peter-A001034" <[e-mail]>
> Date: Tuesday, 17 February, 2009, 2:28 PM
>
> Hi, DHC Folks:
>
> I have a question on the DHCPv4 server behavior for DHCPINFORM.
> When the server receives DHCPINFORM with non-zero ciaddr and non-zero
> giaddr respectively, which address should server send DHCPACK to? To
> client (ciaddr)? Or to DHCP relay node (giaddr)?
>
> It seems current RFC2131 has somewhat conflicting statements:
>
> ===>in section 3.4, it was said
> The servers SHOULD unicast the DHCPACK reply to the address given in
> the 'ciaddr' field of the DHCPINFORM message.
>
> ===>in section 4.1, it was said:
> If the 'giaddr' field in a DHCP message from a client is non-zero, the
> server sends any return messages to the 'DHCP server' port on the
> BOOTP relay agent whose address appears in 'giaddr'
>
> And, I checked the dhcpd implementation, ciaddr is chosen in this case.
>
> I am a little confused on which way to follow. Your help is appreciated.
>
> Thanks
> BRG
> Peny
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
> ________________________________
> Get rid of Add-Ons in your email ID. Get [e-mail]. Sign up
> now!


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C01928C104 for <[e-mail]>; Wed, 18 Feb 2009 01:14:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_66=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOV0XO0Uke85 for <[e-mail]>; Wed, 18 Feb 2009 01:14:44 -0800 (PST)
Received: from mail-gx0-f222.google.com (mail-gx0-f222.google.com [209.85.217.222]) by core3.amsl.com (Postfix) with ESMTP id 6D6143A6358 for <[e-mail]>; Wed, 18 Feb 2009 01:14:44 -0800 (PST)
Received: by gxk22 with SMTP id 22so5112084gxk.13 for <[e-mail]>; Wed, 18 Feb 2009 01:14:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ABXTrxMl3pKZH3bTi5NPrkNWH3XdTAKaX10C1kMPhJs=; b=XpPSNlQSdsNyp4A5wy0tZQF8BGhxvHbJ+TCnedokDWxcuWbXxQ5W9Jir8b0lE904PO fbtbREDVN8baRFbRa7pfdiPZY4ps1KV+Kv6Rlt+Jtb1svouRmjOV1P6PNG3btzU8/aDE A1hON/P1FDxlY77Y749wjX2GXR0LxCIHVhP2A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kdbkxMA/X/cVJ36hOPNkLSA1vRSIQJykQtT4FyQZapV/qURu53X2qZ40tpLIBckBFP WT+bWKnm+Qyhx6YcqoAwuFXTfLc1uPGfqnW7337VUMzwMjbnbJvlSLKz0+arEYohICWA ZNBOdJhx4GNX7f3Jbcij92EOxMVqXd9tBSzus=
MIME-Version: 1.0
Received: by 10.100.93.17 with SMTP id q17mr9253287anb.93.1234948496049; Wed,  18 Feb 2009 01:14:56 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Wed, 18 Feb 2009 17:14:55 +0800
Message-ID: <[e-mail]>
From: Peny Yang <[e-mail]>
To: "David W. Hankins" <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: DHC WG <[e-mail]>
Subject: Re: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 18 Feb 2009 09:14:45 -0000

Hi, Hankins:

Thanks for your help. The situation is clear now.
By the way, IMHO, it's not a good idea to drop the DHCPINFORM with
zeroed ciaddr. Even though ciaddr is provided, sometimes the route is
not available back to client, such as client behind NAT. Or some other
cases?

BRG
Peny


On Wed, Feb 18, 2009 at 1:08 AM, David W. Hankins <[e-mail]> wrote:
> On Tue, Feb 17, 2009 at 04:58:45PM +0800, Peny Yang wrote:
>> I have a question on the DHCPv4 server behavior for DHCPINFORM.
>> When the server receives DHCPINFORM with non-zero ciaddr and non-zero
>> giaddr respectively, which address should server send DHCPACK to? To
>> client (ciaddr)? Or to DHCP relay node (giaddr)?
>
> Hi Peny,
>
> One of the things I noticed while writing the dhcpinform-clarify
> first draft (I really should get the WG item version in...) was that
> you can't unicast reply to clients via BOOTP relay agents (giaddr).
>
> The trouble is that BOOTP relay agents will forward the unicast on
> to the MAC:IP of chaddr:yiaddr field contents.  Even if chaddr is
> filled in by the client (and consquently echoed by the server),
> yiaddr must be zeroed in DHCPINFORM exchanges, as DHCPINFORM is not
> used to assign addresses.
>
> This asks the relay agent to unicast the reply to the all-zeroes IP
> address.
> So it is most preferable to unicast directly to ciaddr (as you
> pointed out, the only normative language on the subject of DHCPINFORM
> in RFC 2131!).  This is the only thing that I think the WG is sure
> about on the subject, or at least no one has disagreed with.  It is
> only if ciaddr is zero that you might "consider other methods," which
> I list by priority in my draft, but there has not been a great deal of
> agreement.  The opposing view is that any ciaddr-zeroed DHCPINFORM
> must be dropped.

> I hope this helps.
>
> --
> 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
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 3276A3A6931; Wed, 18 Feb 2009 16:45:00 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed, 18 Feb 2009 16:45:01 -0800 (PST)
Cc: [e-mail]
Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpinform-clarify-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2009 00:45:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.


	Title           : Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications
	Author(s)       : D. Hankins
	Filename        : draft-ietf-dhc-dhcpinform-clarify-00.txt
	Pages           : 10
	Date            : 2009-02-18

The DHCPINFORM message within the DHCPv4 protocol has in operation
diverged incompatibly from the previously defined standard, and some
questions about DHCPv4 server behaviour remain unclear.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpinform-clarify-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-dhc-dhcpinform-clarify-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D441A3A6B95 for <[e-mail]>; Thu, 19 Feb 2009 11:46:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.197
X-Spam-Level: 
X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.401,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBH22YkPjKD5 for <[e-mail]>; Thu, 19 Feb 2009 11:46:53 -0800 (PST)
Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id E157A3A68C5 for <[e-mail]>; Thu, 19 Feb 2009 11:46:53 -0800 (PST)
Received: from hcf.isc.org (dhcp-186.sql1.isc.org [204.152.187.186]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id n1JJl7ER024127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 19 Feb 2009 11:47:07 -0800
Received: by hcf.isc.org (Postfix, from userid 10200) id 83E0F57356; Thu, 19 Feb 2009 11:49:06 -0800 (PST)
Date: Thu, 19 Feb 2009 11:49:06 -0800
From: "David W. Hankins" <[e-mail]>
To: DHC WG <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi"
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.17 (2007-11-01)
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpinform-clarify-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2009 19:46:54 -0000

--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 18, 2009 at 04:45:01PM -0800, [e-mail] wrote:
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpinform-clarify-00.=
txt

I've gone ahead and included some changes pursuant to review by Ted,
as well as completing the document (I trailed off to an 'under
construction' disclaimer previously), so far as I am aware that it
needs completion.  The changes are significant, so it might be easier
to just read the document again rather than to try to follow my
changelog, but here it is anyway;

Of Insignificance;
- IETF Trust boilerplate.
- Typos and grammar fixes.
- Clarified some intents for clarification in Introduction.
- I've entered my own discussion of Section 4.1's relevance to the
  notes section.  I'm curious if any implementers treat DHCPINFORM
  replies identically to DHCPDISCOVER/DHCPREQUEST replies as this
  text may suggest, and if so, what problems they have (or haven't)
  had with relay agent traversal.

Of Significance;
- Completed the text where it trailed off 'Under Construction.'  This
  is the section describing how servers source MAC addresses to direct
  their replies.  In balance, I determined that because a server that
  actually uses chaddr is essentially performing an optimization, one
  that is redundant with well known ARP cache optimizations, there is
  no reason to direct a server to do so.  It is better to rely upon
  generic forwarding optimizations.

- Tightened wording on client behaviour for ciaddr/chaddr from dual
  SHOULDs to conflicting MUST's, describing an exceptional case.  I
  was concerned the previous SHOULD's still allow "magic vendor
  values" to conform to the protocol, something I think we should
  discourage.  The intent is to preserve the fields' meaning, in
  the event that some later extension can make use of them, and to
  encourage filling them, in the event some implementation requires
  it (the client has a better shot at compatibility).

- Added a security consideration for UDP amplification vectors.  The
  direction is that a server MUST NOT transmit replies that are
  directed to addresses they are not configured to cover.

- Found, I think, the right place to insert a clarification of RFC
  2131 non-normative text, permitting a server to inspect, but not
  modify, the DHCPINFORMing client's lease.  This new text permits a
  server to reply consistently between DHCPREQUEST and DHCPINFORM, in
  regards to non-lease-related configuration values, something that
  some clients expect (and become broken in its absence).


Conclusions from Ted's review and comments;
- Clients now MUST set the flags field to zero, replacing text I had
  copied and reworded from RFC 2131's table previously.  This states
  that a client MUST NOT set the 'BROADCAST' flag under any
  circumstance when sending a DHCPINFORM; it must always be capable
  of receiving a unicast reply in this case.

- FILE and SNAME fields may be used for option overloading, but
  MUST be zeroed otherwise.  Simply trying to be conservative here,
  let me know if there are other use cases for these fields in
  DHCPINFORM replies specifically.

- I believe the 'under construction' section finished in this rev is
  in line with Ted's comments on the subject of server MAC direction.

- I did not act on Ted's 'giaddr' directions, I think he has been
  corrected on the issue?

- For the time being, I have not adopted Ted's other objections to
  sourcing client information from anything other than 'ciaddr'.  I
  do not think he has a made a case that there is a significant enough
  issue at stake so as to intentionally break existing working
  deployments of at least two software implementations, and force out
  clients that cannot determine an address to provide in 'ciaddr', by
  issuing a retraction of RFC 2131's permissive SHOULD.  This is not a
  set-in-stone decision however, and I'm mainly waiting to hear more
  feedback.

--=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

--6c2NcOVqGQ03X4Wi
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmdt7EACgkQcXeLeWu2vmqGYQCfbA7mDa1K7limTkgU+YNvmhs1
xyoAoLfHLBxjj4bWaXk9wmOvwSMTMxBE
=17vm
-----END PGP SIGNATURE-----

--6c2NcOVqGQ03X4Wi--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 5A2723A6946; Fri, 20 Feb 2009 16:30:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri, 20 Feb 2009 16:30:01 -0800 (PST)
Cc: [e-mail]
Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-subnet-alloc-08.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 21 Feb 2009 00:30:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: Subnet Allocation Option
	Author(s)	: R. Johnson
	Filename	: draft-ietf-dhc-subnet-alloc-08.txt
	Pages		: 31
	Date		: 2009-2-19
	
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 [RFC3942], which declares that any pre-existing usages
   of option numbers in the range 128 - 223 should be documented and the
   working group will try to officially assign those numbers to those
   options.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-alloc-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-dhc-subnet-alloc-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C13028C283 for <[e-mail]>; Mon, 23 Feb 2009 18:37:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf55Eu73qbRR for <[e-mail]>; Mon, 23 Feb 2009 18:37:27 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id EA8C23A69FE for <[e-mail]>; Mon, 23 Feb 2009 18:37:26 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.38,256,1233532800"; d="scan'208";a="38164548"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Feb 2009 02:37:45 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1O2bjoT006364;  Mon, 23 Feb 2009 21:37:45 -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.13.8/8.13.8) with ESMTP id n1O2bjWT024863; Tue, 24 Feb 2009 02:37:45 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, 23 Feb 2009 21:37: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="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 23 Feb 2009 21:37:44 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] draft-hunt-dhcpv6-clarify-mrc-00
Thread-Index: AcmOPBLlP6tBAOldQaibOj/KTCuoKgH7G3Pw
References: <[e-mail]>
From: "Bernie Volz (volz)" <[e-mail]>
To: "Evan Hunt" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 24 Feb 2009 02:37:44.0973 (UTC) FILETIME=[DF8603D0:01C99628]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1995; t=1235443065; x=1236307065; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22Bernie=20Volz=20(volz)=22=20<[e-mail]> |Subject:=20RE=3A=20[dhcwg]=20draft-hunt-dhcpv6-clarify-mrc -00 |Sender:=20 |To:=20=22Evan=20Hunt=22=20<[e-mail]>,=20<dhcwg@ie tf.org>; bh=eu9Ye6TmbIfJ3xUs4EQWRvMx8188kE6+ejSdh/5nmHU=; b=oY5416IlDGMeuG5fDXbh/l40P0HhVi7e2snVQxxbj/rcbadPionZiVOCng 0Lt6/dz/l40irRzkegmsPdyXgvIuCeS/FdR6Puo5I0GejXdoq+eZPTdX25QI Na8l0k/A7f;
Authentication-Results: rtp-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); 
Subject: Re: [dhcwg] draft-hunt-dhcpv6-clarify-mrc-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2009 02:37:28 -0000

Evan:

It looks fine to me. You did well.

The only nit might be with the Security Section as the IESG (I think)
generally does not like "None." If you respin, you might just want to
use text along the lines of "see RFC 3315 ... No new or different
threats are introduced by clarifying the meaning of MRC."

- Bernie=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Evan Hunt
Sent: Friday, February 13, 2009 7:34 PM
To: [e-mail]
Subject: [dhcwg] draft-hunt-dhcpv6-clarify-mrc-00

Hello everyone,

About a year ago--I believe it was at the DHCPv6 Bakeoff held in
Vancouver
after IETF 70--Francis Dupont and David Hankins noted that some DHCPv6
implementations were failing the Tahi test suite due to a disagreement
over the precise meaning of the MRC variable in RFC 3315.

I've just submitted a short draft describing the problem and suggesting
a
resolution.  Feedback welcome.  It's my first I-D, so be gentle with me.


-- Forwarded message from IETF I-D Submission Tool
<[e-mail]> --
From: IETF I-D Submission Tool <[e-mail]>
Subject: New Version Notification for draft-hunt-dhcpv6-clarify-mrc-00=20
Date: Fri, 13 Feb 2009 16:27:27 -0800 (PST)


A new version of I-D, draft-hunt-dhcpv6-clarify-mrc-00.txt has been
successfuly submitted by Evan Hunt and posted to the IETF repository.

Filename:	 draft-hunt-dhcpv6-clarify-mrc
Revision:	 00
Title:		 DHCPv6 MRC Clarification
Creation_date:	 2009-02-13
WG ID:		 Independent Submission
Number_of_pages: 4

Abstract:
The definition of the Maximum Retransmission Count (MRC) variable
described in RFC 3315 is clarified to resolve an ambiguity.
=20



The IETF Secretariat.
-- End forwarded message --

--=20
Evan Hunt -- [e-mail]
Internet Systems Consortium, Inc.
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg