Subject: Re: Character set for Line ID

From: RJ Atkinson <[email-masked]>
Date: Tue, 6 Dec 2011 14:35:39 -0500

Bob,

  My read of the relevant RFCs is that the 
DHCP Line-ID option specifies the use of the "NVT"
character set.  

The character set specification is implicit, applying 
to all DHCP options, rather than having been written
explicitly for this single DHCP option.  One has 
to really study the full set of DHCP RFCs 
(i.e. the full daisy-chain of RFC citations from
the References backwards) to see this, but it is
consistent with every DHCP implementation that 
I can identify.

  I can't find ANY DHCP implementations that permit 
"arbitrary bytes" to be entered into the Line-ID option 
field. I can't think of any DHCP implementation that
permits, for example, LINEFEED or CARRIAGE-RETURN
to be entered into ANY DHCP-related field.  Many
have problems with inputs other than printable
characters from ISO-8859, for example.  

  The word "opaque" in the DHCP Line-ID option
specification refers to the packet processing
for the DHCP packet, not to the contents of
the field or how that field is entered 
(presumably via a CLI or perhaps web page someplace) 
or how that field is to be displayed to humans.

The DHCP Line-ID option does not use the word 
"opaque" to indicate absence of a character set.
That is a mis-reading of the DHCP RFC set.

As a former ISP person, I can assure that the
Line-ID values absolutely DO get displayed
to operators and others in network operations.
It is important to be able to configure the
Line-ID values and to view them in order to
troubleshoot real networks (e.g. a DSL deployment).

So the assumption that the DHCP Line-ID option
does not have any specified character set is
not actually correct.

Now, if one's goal is *strict* compatibility with
the DHCP Line-ID option, then the NVT character
set (originally specified in very early RFCs)
ought to be specified.  

I think, however, it would be reasonable to choose 
some alternative such as US-ASCII, ISO-8859-1, 
or (maybe -- possibly more risky given existing
DHCP implementations -- but more globally suitable)
UTF-8.

Yours,

Ran

---

From: Bob Hinden <[email-masked]>
Date: Tue, 6 Dec 2011 16:46:52 -0800

Ran,

Thanks.  I was reaching a conclusion based on what someone said at the last 6man session.  Given that opaque is not what I thought, your suggestion makes sense to me.

Bob

On Dec 6, 2011, at 11:35 AM, RJ Atkinson wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 8 Dec 2011 00:37:38 -0500

Hi Ran,
  Thanks for the explanation. It was very useful.

On 12/06/2011 02:35 PM, RJ Atkinson wrote:
> ...

This is not a goal but is certainly a limiting factor. I have checked
with a few BBF operators and they believe that the printable subset of
7-bit ASCII should be sufficient to hold the line ids. From my reading
of RFC854 (is there a more specific reference?) it seems that NVT should
be able to hold all possible line-ids.

Thanks
Suresh