Subject: [dhcwg] Valid values for DHCPv6 option 18 (Interface ID)

From: Andre Kostur <[email-masked]>
Date: Tue, 11 Mar 2014 17:10:42 -0700

Has there been any changes as to how option 18 has been defined by us?
 I'm running into certain programs (Wireshark, in particular) and
devices that appear to be doing both:
- Assuming it's printable
- Interpreting the content

Both appear to be strongly discouraged by 3315:

   The Interface-ID SHOULD be considered an opaque value, with policies
   based on exact match only; that is, the Interface-ID SHOULD NOT be
   internally parsed by the server.

According to my interpretation, that says that one should neither be
attempting to interpret the contents, nor try to display it as a
string.

Thoughts?

-- 
Andre Kostur

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 12 Mar 2014 01:28:42 +0000

No change.

I think this was an error - we display it as hex byte string (01:02:03:...).

- Bernie (from iPad)

> On Mar 11, 2014, at 8:11 PM, "Andre Kostur" <[email-masked]> wrote:
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Simon Hobson <[email-masked]>
Date: Wed, 12 Mar 2014 10:50:45 +0000

> attempting to interpret the contents, nor try to display it as a

I don't think the two are mutually exclusive.
The text you quote is about how the value is used for processing - ie you should not be looking into the value and using a subset of it for (eg) selecting address allocation policies.

Wireshark is a diagnostic tool, it make complete sense to display the content of packets/fields - that is the purpose of the tool. Just because we aren't allowed to delve into a field for processing purposes doesn't make the showing of the contents of that field invalid for diagnostic purposes.
It shouldn't be assuming a printable string though, and should take care to only use display safe methods (eg hex encode non-printable octets).