Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-01.txt

From: [email-masked]
Date: Tue, 14 Oct 2008 07:45:01 -0700 (PDT)

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, J. Freimann
	Filename        : draft-ietf-dhc-dhcpv6-opt-netboot-01.txt
	Pages           : 11
	Date            : 2008-10-14

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a
framework for passing configuration information to nodes on a
network.  This document describes a new option for DHCPv6 to convey
information, required for network booting, to the nodes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-netboot-01.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.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Matthew Ryan <[email-masked]>
Date: Tue, 14 Oct 2008 23:59:23 -0700

The bootfile-url sub-option is defined as a list of NUL-terminated 
ASCII strings.  I believe defining it as a list of length-prefixed
(2 octet lengths) ASCII strings that omit the NUL would be a better 
encoding.

   Doing so would make parsing the option more efficient, since you 
wouldn't have to check each octet to see if it's NUL.  It might also 
allow implementers to reuse existing code from other items which are 
lists of length-prefixed things, such as the user-class options.

   Also, including the NUL would be a departure from the usual practice 
of omitting it when encoding ASCII data in DHCP and DHCPv6 options 
(though in this case it is being used as the separator).

   For the netboot-vendor sub-option, it might be useful for consistency 
to have the vendor-class-data section be formatted in the same way as 
the vendor-class option defined in RFC3315 22.16.  That is, a list of 
instances where each is 2 octets length followed by that many octets 
opaque data.

  - Matt

---

From: Thomas Huth <[email-masked]>
Date: Wed, 15 Oct 2008 11:07:51 +0200

[email-masked] wrote on 14.10.2008 16:45:01:

> This draft is a work item of the Dynamic Host Configuration Working Group

> of the IETF.

New in this version:

- The draft now contains a suboption for vendor class extensions.

- Some remarks about iSCSI network boot strapping have been added, too.

There are some topics concerning our draft that we'd like to discuss here:

1) Is anybody here experienced with iSCSI network booting who could
cross-check our remarks about iSCSI in chapter 7 ?

2) We recently discovered
http://www.ietf.org/proceedings/08jul/slides/dhc-12.pdf which contains a
list with iSCSI and PXE boot needs for IPv6. We think that our drafts
covers most required options already...
Just equivalents for DHCPv4/PXE options 93, 94 and 97 are still not defined
yet. But are they really required?
"Client system architecture type" (Option 93) and "Client network interface
identifier" (Option 94) seem already to be provided in the PXE Vendor class
identifier string (Option 60 for DHCPv4, option 16 for DHCPv6), so a new
option sounds like redundant information. What do you think?>
And what is Option 97 ("Universally unique ID") exactly good for? It sounds
similar to the DUIDs from RFC 3315... so could the DUIDs be used instead of
the unique IDs from DHCPv4 option 97 ?

Mit freundlichen Grüßen / Kind regards,
   Thomas Huth
                                                                           
    IBM Deutschland                 Vorsitzender des Aufsichtsrats:        
    Research & Development GmbH     Martin Jetter                          
    Schönaicher Str. 220            Geschäftsführung: Erich Baier          
    71032 Böblingen                 Sitz der Gesellschaft: Böblingen       
    Tel.: +49-7031-16-2183          Registergericht: Amtsgericht           
                                    Stuttgart, HRB 243294

---

From: Thomas Huth <[email-masked]>
Date: Fri, 17 Oct 2008 10:14:23 +0200

Thanks for your feedback, Matthew!

> (though in this case it is being used as the separator).

Ok, that sounds reasonable. On the other side, one could argue that some
of these strings (the kernel parameters) are finally passed as parameters
to the OS kernel on the client machine - and these parameters are normally
null terminated. So the strings would require conversion on the client
side.

I don't have a very strong opinion on this... has anybody else any
comments.
on this issue?

> instances where each is 2 octets length followed by that many octets

OK, agreed.

Another question to everybody: Is ASCII still a sane encoding for URLs like
the strings in our
SUBOPT_BOOTFILE_URL suboption? I mean, according to RFC2396, chapter 2.1,
ASCII
should be fine and special characters should be encoded with "%" + hex
number for example...
or should we rather directly use something like UTF-8 to encode the URL in
this suboption?..

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 17 Oct 2008 08:52:24 -0700

> > lists of length-prefixed things, such as the user-class options.

There is a DHCPv4 option that is similarly encoded as well.

> null terminated. So the strings would require conversion on the client

This really hasn't been an issue.

> I don't have a very strong opinion on this... has anybody else any

I think we have to have a concrete decision, which means strong
opinions are mandatory.  The opinions on null termination of ascii
strings were weak when drafting RFC2131 and RFC2132, I presume, and as
a consequence the language is inconsistent and permissible of NULL
termination.

The consequence was interoperability problems.  There were machines
that would literally crash if the values weren't terminated.

If you examine draft-ietf-dhc-option-guidelines, one of the points it
tries to make is not to invent option format definitions when
defining new option formats, if it is at all possible to avoid.

This may be one of those cases (I have not yet looked at the netboot
draft).  The existing option "atoms" used by DHCP software everywhere
are not NULL terminated.  Length-terminated chains of string type
formats exist elsewhere.  If you're after rapid deployment, the best
idea is to format the option identically to others (so that config
syntax, and not software updates, can enable it).

> or should we rather directly use something like UTF-8 to encode the URL in

I would specify NVT-ASCII and suggest %-escapes, again synching with
existing DHCP software implementations.  It will make deployment
easier (and not require software updates).

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Oct 2008 13:09:56 -0700

On Oct 17, 2008, at 8:52 AM, David W. Hankins wrote:
> opinions are mandatory.

Yup.

>  The opinions on null termination of ascii

The interchangeable use of NUL termination and length prefixes in  
DHCPv4 was a disaster, and the rubble from that disaster is strewn  
throughout every DHCPv4 implementation in the form of unnecessary  
conditionals to check to see if the client is broken.   Based on that  
experience, upon which David has expounded at length, in my opinion we  
must never use NUL-terminated strings in a DHCPv6 spec.   We already  
have one way of representing strings; we don't need two.