Subject: [dhcwg] SLAAC and DDNS

From: <[email-masked]>
Date: Fri, 27 Feb 2009 10:01:34 -0600

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

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 27 Feb 2009 09:41:54 -0800

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

The IPv6 source address of an Info-Request message is more likely a
link-local address, and using this field presumes the client has only
one address.  So you would have to specify that the client MUST select
a source address specifically not in keeping with the usual guidelines
for source address selection.  This isn't impossible, a client can
bind the socket.

You'd also have to specify the client MUST include a client identifier
option so that the server can manufacture a DHCID.  RFC 3315 states
this is a SHOULD for information-request, only a MUST if
authentication is in use.

But, this method raises a security concern.

The client does not have a TSIG key, but by using only the source
IPv6 address field and an FQDN option, it can ask a DHCPv6 server to
perform an update on its behalf.  This mechanism simply extends DHCP
to tunnel through DNS security, to bypass it.  Anyone can send that
packet, and they can ask the DHCP server to update the zone with
whatever contents they might have updated themselves - just limited
to AAAA and DHCID RRs.  This is not very different form simply leaving
the DNS zone wide open, or erecting access control on the DNS zone to
limit RR types.  There is for example a BIND 9 ACL command that
permits systems to update their own PTR records.

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 27 Feb 2009 13:37:56 -0500

Why not have the client do DHCPv6 but have the DHCPv6 server assign the
client the SLAAC address (for what it is worth, CNR's DHCPv6 server
supports this capability). No protocol or client changes (provided the
client already supports DHCPv6 based address assignment - if it doesn't
having it do the Information-Request requires new code anyway). No new
draft to write.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David W. Hankins
Sent: Friday, February 27, 2009 12:42 PM
To: DHC WG
Subject: Re: [dhcwg] SLAAC and DDNS

On Fri, Feb 27, 2009 at 10:01:34AM -0600, [email-masked] wrote:
> 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.

---

From: <[email-masked]>
Date: Fri, 27 Feb 2009 13:15:22 -0600

Bernie,
> No protocol or client changes (provided the

I was more concerned about the case where the client and server support the "lightweight", stateless DHCPv6 protocol only.

David,

> The IPv6 source address of an Info-Request message is more likely a link-local address, and using this field presumes the client has only one address.  So you would have to specify that the client MUST select a source address specifically not in keeping with the usual guidelines for source address selection.  This isn't impossible, a client can bind the socket.

I suppose that's true, so the client would have to include an option telling the server about its IP address(es) in the Info-Request message.

> You'd also have to specify the client MUST include a client identifier option so that the server can manufacture a DHCID.  RFC 3315 states this is a SHOULD for information-request, only a MUST if authentication is in use.

Yes, I agree that it would need to be MUST to include client id.

> The client does not have a TSIG key, but by using only the source
IPv6 address field and an FQDN option, it can ask a DHCPv6 server to perform an update on its behalf.  This mechanism simply extends DHCP to tunnel through DNS security, to bypass it.  Anyone can send that packet, and they can ask the DHCP server to update the zone with whatever contents they might have updated themselves - just limited to AAAA and DHCID RRs.

If the client-id is required, then the risk would be the same as with stateful DHCPv6 and the FQDN option, right?
 
Greg

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 27 Feb 2009 12:49:54 -0800

> If the client-id is required, then the risk would be the same as with stateful DHCPv6 and the FQDN option, right?

No, in that case the server is selecting both the addresses and the
hostname, and assigning them.  You're proposing that the client supply
the addresses, which is not very different from simply updating DNS
directly, unless you provide the server with some way of validating
that the DUID, FQDN, and addresses are consistent.  This is usually
done through configuration, or dynamic configuration, where the
DUID and FQDN is consistent, to provide assigned address(es) which
the elements of the network can then enforce.

Thinking further...

You also need to work in the mechanism where the client and server
negotiate through several trials to a domain name, which means you
have to solicit offers, and make a request from the server you've
selected, in order to arrive at a single domain name (rather than
having 10 servers update 10 names at the same time).

And you have to work out the lease time you're now going to be
applying to these domain names.  They have to be removed from DNS
at some point, and clients can probably not be trusted to reliably
solicit for their removal.

---

From: <[email-masked]>
Date: Fri, 27 Feb 2009 15:43:08 -0600

> No, in that case the server is selecting both the addresses and the hostname, and assigning them.  You're proposing that the client supply the addresses, which is not very different from simply updating DNS directly, 

Except that if you choose TSIG for dynamic update security, then you still need keys on all your clients.

> unless you provide the server with some way of validating that the DUID, FQDN, and addresses are consistent.

Why?  For RFC 4703/4704 behavior, a client provides the DUID and FQDN.  For a stateful DHCPv6, the server determines the address, for stateless DHCPv6, the client provides the address in the Info-Request.  In either case, if some malicious hacker were able to fabricate the proper DUID, he could cause pretty much the same havoc in both environments.
 
> You also need to work in the mechanism where the client and server negotiate through several trials to a domain name, which means you have to solicit offers, and make a request from the server you've selected, in order to arrive at a single domain name (rather than having 10 servers update 10 names at the same time).

I'm having trouble understanding the need for this.  If this were true, wouldn't a stateful server which supports 4703/4704 need to do this also?

> And you have to work out the lease time you're now going to be applying to these domain names.  They have to be removed from DNS at some point, and clients can probably not be trusted to reliably solicit for their removal.

Yes, I believe I had identified this problem in my initial post.  So far, I have only thought of some sort of "scavenger" that cleans up stale resource records.  But I'll be honest, that this may be a show-stopper.

Greg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 27 Feb 2009 17:19:52 -0500

Greg, perhaps you can give some motivation behind all this? If you're
going to require a new 'client' that does this special
Information-Request handling that you're proposing, why not just develop
a stateful DHCPv6 client?

>Why?  For RFC 4703/4704 behavior, a client provides the DUID and FQDN.
For a stateful DHCPv6, the server determines the address, for stateless
DHCPv6, the client provides the address in the Info-Request.  In either
case, if some malicious hacker were able to fabricate the proper DUID,
he could cause pretty much the same havoc in both environments.

While I think at the surface there may not be much difference, I think
if you dig a bit deeper there is. An Information-Request is far easier
to fabricate than a complete DHCPv6 exchange (assuming Rapid Commit
isn't used) and the DHCP server is able to control the addresses it
gives out and to whom. Those are not possible in stateless. Yes, the
DHCP server has the opportunity to refuse to do updates for
Information-Request only clients, but it is only a request/reply
exchange and not a 4-way exchange.

And, the lease (lifetime) issue is also a key piece of this in terms of
the server knowing when to remove data.

Also, if I recall, the Information-Request only piece is harder to
secure if DHCPv6 AUTH ever takes off.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, February 27, 2009 4:43 PM
To: [email-masked]
Subject: Re: [dhcwg] SLAAC and DDNS

directly, 

Except that if you choose TSIG for dynamic update security, then you
still need keys on all your clients.

> unless you provide the server with some way of validating that the
DUID, FQDN, and addresses are consistent.

Why?  For RFC 4703/4704 behavior, a client provides the DUID and FQDN.
For a stateful DHCPv6, the server determines the address, for stateless
DHCPv6, the client provides the address in the Info-Request.  In either
case, if some malicious hacker were able to fabricate the proper DUID,
he could cause pretty much the same havoc in both environments.
 
> You also need to work in the mechanism where the client and server
negotiate through several trials to a domain name, which means you have
to solicit offers, and make a request from the server you've selected,
in order to arrive at a single domain name (rather than having 10
servers update 10 names at the same time).

I'm having trouble understanding the need for this.  If this were true,
wouldn't a stateful server which supports 4703/4704 need to do this
also?

> And you have to work out the lease time you're now going to be
applying to these domain names.  They have to be removed from DNS at
some point, and clients can probably not be trusted to reliably solicit
for their removal.

Yes, I believe I had identified this problem in my initial post.  So
far, I have only thought of some sort of "scavenger" that cleans up
stale resource records.  But I'll be honest, that this may be a
show-stopper.

Greg
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 27 Feb 2009 14:27:15 -0800

> Except that if you choose TSIG for dynamic update security, then you still need keys on all your clients.

You still have not explained why DHCP is required to tunnel the update
to the DNS servers.  You may as well operate the DNS servers with
limited contextual filters, such as only allowing updates for AAAA's
matching source addresses over TCP.  It is not clear what service the
DHCP servers are providing except to copy and paste option contents on
the client's behalf.

DHCP is not a firewalling or filtering service.

> Why?  For RFC 4703/4704 behavior, a client provides the DUID and FQDN.  For a stateful DHCPv6, the server determines the address, for stateless DHCPv6, the client provides the address in the Info-R…

In no event with stateful DHCPv6 servers performing DDNS could a
client insert a foreign AAAA into DNS.  It will only insert records
for addresses it governs.

Spoofing a DUID is measurably harder when authentication is in use,
which Information-Request can also use.  But as I said before, you
have proposed no model by which a server can validate the supplied
addresses against an Information-Requesting client's DUID.

> I'm having trouble understanding the need for this.  If this were true, wouldn't a stateful server which supports 4703/4704 need to do this also?

It does this.  Modulo rapid commit, Solicit yields multiple
Advertisements, of which the client selects one to Request, resulting
in one Reply.

---

From: <[email-masked]>
Date: Fri, 27 Feb 2009 16:46:34 -0600

Hi Bernie,

The motivation is for environments that are not using stateful clients and servers, because this is often deemed too "heavyweight".  Certainly the implementation of the clients and servers which support stateful DHCPv6 would be much more complicated than those that just do stateless (RFC 3736).  Stateful DHCPv6 also suffers from potential performance issues when there are large numbers of clients (re)booting at the same time.  With IPv6, one would expect these numbers to be VERY large, at least in some cases.

Since a stateless client doesn't have a lease/lifetime, it seems the only viable solution would be a scavenger of some sort.

Greg

---

From: Ralph Droms <[email-masked]>
Date: Sat, 28 Feb 2009 06:07:22 -0500

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, <[email-masked]> <[email-masked] 
 > 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  
> 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
>

From: [email-masked]
To: [email-masked]
Date: Wed,  4 Feb 2009 02:30:01 -0800 (PST)
Cc: [email-masked]
Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-03.txt

--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: <[email-masked]>

--NextPart--

To: [email-masked]
From: Thomas Huth <[email-masked]>
Date: Wed, 4 Feb 2009 11:53:36 +0100
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-03.txt

[email-masked] 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=

From: Bud Millwood <[email-masked]>
Organization: Weird Solutions, Inc.
To: [email-masked]
Date: Wed, 4 Feb 2009 14:17:40 +0100
Cc: Thomas Huth <[email-masked]>
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-03.txt
Reply-To: Bud Millwood <[email-masked]>

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
>

=2D-=20
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687

From: [email-masked]
To: [email-masked]
Date: Wed,  4 Feb 2009 12:45:01 -0800 (PST)
Cc: [email-masked]
Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-srsn-option-02.txt

--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: <[email-masked]>

--NextPart--

Date: Thu, 05 Feb 2009 16:24:18 +0800
From: Sean Shen <[email-masked]>
To: 'Damien Neil' <[email-masked]>, 'DHC-WG WG' <[email-masked]>, [email-masked]
Subject: Re: [dhcwg] [CGA-EXT] "Secure DHCPv6 Using	CGAs"draft-jiang-dhc-secure-dhcpv6-01

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 

Content-class: urn:content-classes:message
Date: Thu, 5 Feb 2009 17:01:32 -0600
From: "Thomson, Martin" <[email-masked]>
To: <[email-masked]>
Subject: [dhcwg] draft-ietf-geopriv-lis-discovery updated based on DHC comments

From: Bud Millwood <[email-masked]>
Organization: Weird Solutions, Inc.
To: [email-masked]
Date: Fri, 6 Feb 2009 09:22:41 +0100
Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated based on DHC comments
Reply-To: Bud Millwood <[email-masked]>

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

-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687

From: "Glen Zorn" <[email-masked]>
To: "'Bud Millwood'" <[email-masked]>
Date: Fri, 6 Feb 2009 15:44:06 +0700
Organization: Network Zen
Cc: [email-masked]
Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated based on DHC	comments

Bud Millwood [mailto:[email-masked]] 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.

...

From: Bud Millwood <[email-masked]>
Organization: Weird Solutions, Inc.
To: [email-masked]
Date: Fri, 6 Feb 2009 13:32:01 +0100
Cc: Thomas Huth <[email-masked]>
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-03.txt
Reply-To: Bud Millwood <[email-masked]>

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

From: [email-masked]
To: [email-masked]
Date: Fri,  6 Feb 2009 18:15:01 -0800 (PST)
Cc: [email-masked]
Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-agentopt-delegate-03.txt

--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: <[email-masked]>

--NextPart--

Date: Sat, 07 Feb 2009 14:21:53 -0500
From: Danny Mayer <[email-masked]>
To: Bud Millwood <[email-masked]>
X-kostecke.net-MailScanner: Found to be clean
X-kostecke.net-MailScanner-From: [email-masked]
Cc: [email-masked], Thomas Huth <[email-masked]>
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-03.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:[email-masked]?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

Content-class: urn:content-classes:message
Date: Sun, 8 Feb 2009 16:26:08 -0600
From: "Thomson, Martin" <[email-masked]>
To: "Glen Zorn" <[email-masked]>, "Bud Millwood" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated based onDHC	comments

Content-class: urn:content-classes:message
Date: Sun, 8 Feb 2009 22:37:26 -0600
From: "Thomson, Martin" <[email-masked]>
To: "Thomson, Martin" <[email-masked]>, "Glen Zorn" <[email-masked]>, "Bud Millwood" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated basedonDHC	comments

To: [email-masked]
From: Thomas Huth <[email-masked]>
Date: Mon, 9 Feb 2009 11:25:53 +0100
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-03.txt

[email-masked] 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

From: Bud Millwood <[email-masked]>
Organization: Weird Solutions, Inc.
To: Danny Mayer <[email-masked]>
Date: Tue, 10 Feb 2009 14:52:09 +0100
Cc: [email-masked], Thomas Huth <[email-masked]>
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-03.txt
Reply-To: Bud Millwood <[email-masked]>

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

From: Bud Millwood <[email-masked]>
Organization: Weird Solutions, Inc.
To: [email-masked]
Date: Tue, 10 Feb 2009 15:41:47 +0100
Cc: "Thomson, Martin" <[email-masked]>
Subject: Re: [dhcwg] =?iso-8859-1?q?draft-ietf-geopriv-lis-discovery_updated_b?= =?iso-8859-1?q?asedonDHC=09comments?=
Reply-To: Bud Millwood <[email-masked]>

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
> > Of Thomson, Martin
> > Sent: Monday, 9 February 2009 9:26 AM
> > To: Glen Zorn; Bud Millwood
> > Cc: [email-masked]
> > 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
> >
> > > From: [email-masked] [mailto:[email-masked]] On
> >
> > Behalf
> >
> > > Of Glen Zorn
> > > Sent: Friday, 6 February 2009 7:44 PM
> > > To: 'Bud Millwood'
> > > Cc: [email-masked]
> > > Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated based
> > > onDHC comments
> > >
> > > Bud Millwood [mailto:[email-masked]] 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.
> > >
> > > ...
> > >
> > -----------------------------------------------------------------------
> > -------------------------
> > 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]
> ---------------------------------------------------------------------------
>--------------------- 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]

-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687

Content-class: urn:content-classes:message
Date: Tue, 10 Feb 2009 18:17:39 -0600
From: "Thomson, Martin" <[email-masked]>
To: "Bud Millwood" <[email-masked]>, <[email-masked]>
Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated basedonDHC	comments

From: Bud Millwood <[email-masked]>
Organization: Weird Solutions, Inc.
To: [email-masked]
Date: Wed, 11 Feb 2009 10:27:23 +0100
Cc: "Thomson, Martin" <[email-masked]>
Subject: Re: [dhcwg] =?iso-8859-1?q?draft-ietf-geopriv-lis-discovery_updated_b?= =?iso-8859-1?q?asedonDHC=09comments?=
Reply-To: Bud Millwood <[email-masked]>

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
> > From: Bud Millwood [mailto:[email-masked]]
> > Sent: Wednesday, 11 February 2009 1:42 AM
> > To: [email-masked]
> > 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
> > >
> > > > From: [email-masked] [mailto:[email-masked]] On
> >
> > Behalf
> >
> > > > Of Thomson, Martin
> > > > Sent: Monday, 9 February 2009 9:26 AM
> > > > To: Glen Zorn; Bud Millwood
> > > > Cc: [email-masked]
> > > > 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
> > > >
> > > > > From: [email-masked] [mailto:[email-masked]] On
> > > >
> > > > Behalf
> > > >
> > > > > Of Glen Zorn
> > > > > Sent: Friday, 6 February 2009 7:44 PM
> > > > > To: 'Bud Millwood'
> > > > > Cc: [email-masked]
> > > > > Subject: Re: [dhcwg] draft-ietf-geopriv-lis-discovery updated
> >
> > based
> >
> > > > > onDHC comments
> > > > >
> > > > > Bud Millwood [mailto:[email-masked]] 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.
> > > > >
> > > > > ...
> > > > >
> > > > -------------------------------------------------------------------
> >
> > ----
> >
> > > > -------------------------
> > > > 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]
> > > ---------------------------------------------------------------------
> >
> > ------
> >
> > >--------------------- 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]
> > Bud Millwood
> > Weird Solutions, Inc.
> > http://www.weird-solutions.com
> > tel: +46 8 758 3700
> > fax: +46 8 758 3687
>
> ---------------------------------------------------------------------------
>--------------------- 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]

-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687

Date: Thu, 12 Feb 2009 00:12:36 -0800 (PST)
From: Sri Gundavelli <[email-masked]>
To: Ralph Droms <[email-masked]>
Cc: Dhcwg WG <[email-masked]>, [email-masked], Ryuji Wakikawa <[email-masked]>
Subject: Re: [dhcwg] Review of draft-ietf-netlmm-pmip6-ipv4-support

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 <[email-masked]>
>> > To: Dhcwg WG <[email-masked]>
>> > 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

Date: Sat, 14 Feb 2009 00:34:15 +0000
From: Evan Hunt <[email-masked]>
To: [email-masked]
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 <[email-masked]> --
From: IETF I-D Submission Tool <[email-masked]>
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 -- [email-masked]
Internet Systems Consortium, Inc.

From: [email-masked]
To: [email-masked]
Date: Fri, 13 Feb 2009 17:00:02 -0800 (PST)
Cc: [email-masked]
Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv4-bulk-leasequery-00.txt

--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: <[email-masked]>

--NextPart--

Date: Sun, 15 Feb 2009 13:52:34 -0500
From: John Jason Brzozowski <[email-masked]>
To: dhc WG <[email-masked]>
Cc: dhc Chairs <[email-masked]>
Subject: [dhcwg] Request for Agenda Items

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

Thanks,

Ralph and John

Date: Tue, 17 Feb 2009 16:58:45 +0800
From: Peny Yang <[email-masked]>
To: [email-masked]
Cc: McCann Peter-A001034 <[email-masked]>
Subject: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM

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

Date: Tue, 17 Feb 2009 19:56:34 +0530 (IST)
From: GAURAV HALWASIA <[email-masked]>
To: [email-masked], Peny Yang <[email-masked]>
Cc: McCann Peter-A001034 <[email-masked]>
Subject: Re: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM
Reply-To: [email-masked]

--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 <[email-masked]> wrote:

From: Peny Yang <[email-masked]>
Subject: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM
To: [email-masked]
Cc: "McCann Peter-A001034" <[email-masked]>
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
[email-masked]
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;[email-masked]&gt;<BR>Su=
bject: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM<BR>To: dhc=
[email-masked]<BR>Cc: "McCann Peter-A001034" &lt;[email-masked]&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
[email-masked]
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 [email-masked]. <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--

Date: Tue, 17 Feb 2009 09:08:47 -0800
From: "David W. Hankins" <[email-masked]>
To: Peny Yang <[email-masked]>
Cc: DHC WG <[email-masked]>
Subject: Re: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM

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

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

--bp/iNruPH9dso1Pn--

Date: Tue, 17 Feb 2009 10:28:48 -0800
From: "David W. Hankins" <[email-masked]>
To: DHC WG <[email-masked]>
Subject: Re: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM

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

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

--wq9mPyueHGvFACwf--

From: [email-masked]
To: [email-masked]
Date: Tue, 17 Feb 2009 15:00:01 -0800 (PST)
Cc: [email-masked]
Subject: [dhcwg] I-D Action:draft-ietf-dhc-option-guidelines-04.txt

--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: <[email-masked]>

--NextPart--

Date: Tue, 17 Feb 2009 15:07:32 -0800
From: "David W. Hankins" <[email-masked]>
To: DHC WG <[email-masked]>
Subject: Re: [dhcwg] draft-ietf-dhc-option-guidelines-04

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

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

--82evfD9Ogz2JrdWZ--

Date: Wed, 18 Feb 2009 15:20:28 +0800
From: Peny Yang <[email-masked]>
To: [email-masked]
Cc: [email-masked], McCann Peter-A001034 <[email-masked]>
Subject: Re: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM

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
<[email-masked]> 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 <[email-masked]> wrote:
>
> From: Peny Yang <[email-masked]>
> Subject: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM
> To: [email-masked]
> Cc: "McCann Peter-A001034" <[email-masked]>
> 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
> ________________________________
> Get rid of Add-Ons in your email ID. Get [email-masked]. Sign up
> now!

Date: Wed, 18 Feb 2009 17:14:55 +0800
From: Peny Yang <[email-masked]>
To: "David W. Hankins" <[email-masked]>
Cc: DHC WG <[email-masked]>
Subject: Re: [dhcwg] Question on DHCPv4 server behavior for DHCPINFORM

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 <[email-masked]> 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.

From: [email-masked]
To: [email-masked]
Date: Wed, 18 Feb 2009 16:45:01 -0800 (PST)
Cc: [email-masked]
Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpinform-clarify-00.txt

--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: <[email-masked]>

--NextPart--

Date: Thu, 19 Feb 2009 11:49:06 -0800
From: "David W. Hankins" <[email-masked]>
To: DHC WG <[email-masked]>
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpinform-clarify-00.txt

--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, [email-masked] 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

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

--6c2NcOVqGQ03X4Wi--

From: [email-masked]
To: [email-masked]
Date: Fri, 20 Feb 2009 16:30:01 -0800 (PST)
Cc: [email-masked]
Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-subnet-alloc-08.txt

--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: <[email-masked]>

--NextPart--

Content-class: urn:content-classes:message
Date: Mon, 23 Feb 2009 21:37:44 -0500
From: "Bernie Volz (volz)" <[email-masked]>
To: "Evan Hunt" <[email-masked]>, <[email-masked]>
Subject: Re: [dhcwg] draft-hunt-dhcpv6-clarify-mrc-00

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Evan Hunt
Sent: Friday, February 13, 2009 7:34 PM
To: [email-masked]
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
<[email-masked]> --
From: IETF I-D Submission Tool <[email-masked]>
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 -- [email-masked]
Internet Systems Consortium, Inc.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg