Subject: [dhcwg] rfc3679bis, or: about allocation of DHCPv4 options (was [IANA #1172829] Request for Early Allocation of DHCPv4 option (draft-ietf-dhc-v6only)

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Jun 2020 13:38:15 -0400

I hate that ML are not consistently named for the WG. resending with correct
WG ML list name.

...

Bernie, is some of the desire to pick <127 a result of the experience with
CAPPORT's use of 160?

Unfortunately, while I participated in the thread that Jen linked to justify
why ietf-dhc-v6only should have 108, I can't seem to find much discussion
about 108 itself.
(Much of it is not about why 108, and rather about the protocol as a whole)

So, aside from Tomek's original message there isn't much discussion about why
we are going against IANA's normal process here.

Given this recommendation and the experience with CAPPORT, should we be
changing advice to IANA in general?

Is there an need to repeat the delouse effort that resulted in RFC3679?
RFC3679 already says:

   IANA is requested to reassign these option codes after the list of
   option codes that have never been assigned or have previously been
   returned has been exhausted.

Maybe this is not well understood.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 23 Jun 2020 17:51:48 +0000

I'm really not sure why this is generating so much discussion?

Including Jen as dhc wg is included, so just to make sure she see it.

I do believe some had a bad experience with option 160, however, it was related to Polycom usage. See https://tools.ietf.org/html/draft-ietf-capport-rfc7710bis-07 - it will ask to use option 114. We had a reference for that one and contacted Dieter at Apple to confirm it was not still in use and whether he thought it would create any conflict and the result was that there would be no issues as it never made it into the wild.

And, when we did the work to determine what was in use (~2004 if I recall), no one ever reported that 160 had been used for anything so there was no reason for IANA to hold off on allocating it (as we did recommend with some others that were in use). The general guidelines was indeed to avoid their use, but given the experience with 160 even that approach failed. So the bottom line is that any value has a small risk as people violated the rules; this was more obvious in the original private use space as vendors thought they could use a value.

For 108, while we have some information it was used for Swap Path, we sadly have no information about who was potentially using it to contact them. Also, a (perhaps now dated DHCP fingerprint file I have based on PRL values) has no one using 108 in the PRL.

So, can we be 100% certain there will not be an issues ... no. But that applies to any value IANA may pick. And, we've probably now done more to notify people of the use of 108 and so anyone that knows of a concern would hopefully have stepped forward? Or perhaps may in the next few days?

Note also that there have been other options allocated which have not run into problems as far as I am aware.

I don't think I would change the IANA recommendation, but I also see no reason to disallow folks from recommending values if they have some reason to do so.

- Bernie

-----Original Message-----
From: dhcwg <[email-masked]> On Behalf Of Michael Richardson
Sent: Tuesday, June 23, 2020 1:38 PM
To: [email-masked]; Bernie Volz (volz) <[email-masked]>
Subject: [dhcwg] rfc3679bis, or: about allocation of DHCPv4 options (was [IANA #1172829] Request for Early Allocation of DHCPv4 option (draft-ietf-dhc-v6only)

I hate that ML are not consistently named for the WG. resending with correct WG ML list name.

....

Bernie, is some of the desire to pick <127 a result of the experience with CAPPORT's use of 160?

Unfortunately, while I participated in the thread that Jen linked to justify why ietf-dhc-v6only should have 108, I can't seem to find much discussion about 108 itself.
(Much of it is not about why 108, and rather about the protocol as a whole)

So, aside from Tomek's original message there isn't much discussion about why we are going against IANA's normal process here.

Given this recommendation and the experience with CAPPORT, should we be changing advice to IANA in general?

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Jun 2020 17:05:58 -0400

> I'm really not sure why this is generating so much discussion?

I think because many are surprised with the IANA interaction.

    > I do believe some had a bad experience with option 160, however, it was
    > related to Polycom usage. See

Yes, the question is whether there might be other submarine uses out there :-)

    > And, when we did the work to determine what was in use (~2004 if I
    > recall), no one ever reported that 160 had been used for anything so

Yes, I wasn't criticizing the work: it seems pretty clear to me.
I am just wondering if the results have just not sunk in enough.

    > So, can we be 100% certain there will not be an issues ... no. But that
    > applies to any value IANA may pick. And, we've probably now done more
    > to notify people of the use of 108 and so anyone that knows of a
    > concern would hopefully have stepped forward? Or perhaps may in the
    > next few days?

I doubt it: I think that if there was any use of 108 it's in places that
can't spell IETF.

    > run into problems as far as I am aware.

Understood.

    > I don't think I would change the IANA recommendation, but I also see no
    > reason to disallow folks from recommending values if they have some
    > reason to do so.

As I read the RFC3679 recommendations, it seems that IANA was not actually
following them.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 23 Jun 2020 22:09:03 +0000

Hi:

> As I read the RFC3679 recommendations, it seems that IANA was not actually following them.

>From RFC3678:

6. IANA Considerations

   IANA has returned the DHCP option codes listed in Section 2 to the
   list of available option codes.  These option codes may be reassigned
   to new DHCP options, according to the procedures in RFC 2939 [6].
   IANA is requested to reassign these option codes after the list of
   option codes that have never been assigned or have previously been
   returned has been exhausted.

I think they are trying to follow the last sentence. But this is just a request; it is on part of an IETF document requesting a specific value [provided that value is not actively assigned at the time IANA does the assignment].

And, 108 (section 2.10) falls into section 2 which is:

2. Unused DHCP Option Codes to be Reassigned to Future DHCP Options

   The option codes listed in this section are to be returned to IANA
   for reassignment to new options.  Responses from associated contact
   persons are noted where they have been received.

BTW: I did a google search for "dhcp option 108" and while it uncovered DHCPv6 option 108, there was no DHCPv4 option (things it found said this was undefined) - of course it also found RFC3678. While not authoritative, it does support the belief that this option is not in use as to use it would require some documentation to specify what it is and how to set it. I'm not sure how it was discovered back when Ralph worked on RFC3678 that is was "swap path". Include "swap path" in the google search turns up different hits, where some have defined it to be swap path. One interesting one is:

https://archive.org/stream/sg245280/sg245280_Beyond_DHCP_Work_Your_TCPIP_Internetwork_with_Dynamic_IP_djvu.txt (goes from START---- to ----END, pasted as it came):

START----

D.4 Unofficial DHCP options 

Several additional options, while not yet part of the official RFC 2132 
standard, have achieved some degree of popularity and are in common use. 
If you are interested in the latest inventory of unofficially assigned DHCP 
options, the list is available on the Internet at: 

ftp : //ftp . isi . edu/ in-notes/ iana/ assignments 

Appendix D. DHCP options (RFC 2132) 481 

Option 

Description 

62 

NetWare/I P Domain Name 

63 

NetWare/I P Suboptions 

77 

User Class 

78 

Directory Agent Information 

79 

Service Location Agent Scope 

80 

Naming Authority 

81 

Client Fully Qualified Domain Name 

82 

Agent Circuit ID 

83 

Agent Remote ID 

84 

Agent Subnet Mask 

85 

Novell Directory Services Servers 

86 

Novell Directory Services Tree Name 

87 

Novell Directory Services Context 

88 

IEEE 1003.1 POSIX Timezone 

89 

Fully Qualified Domain Name 

90 

Authentication 

91 

Banyan Vines TCP/IP Server 

92 

Server Selection 

93 

Client System Architecture 

94 

Client Network Device Interface 

95 

Lightweight Directory Access Protocol (LDAP) 

96 

IPv6 Transitions 

97 

UUID/GUID-based Client Identifier 

100 

Printer Name 

101 

Multicast Scope 

102 

Start Time 

103 

Multicast Time-to-Live 

104 

Multicast Block Size 

105 

Client Port 

106 

Cookie 

107 

Multicast Scope List 

108 

Swap Path 

109 

Autonomous System Number (ASN) 

110 

IPX Compatibility 

111 

Served IP Range 

112 

Netlnfo Parent Server Address 

113 

Netlnfo Parent Server Tag 

114 

Universal Resource Locator (URL) 

115 

DHCP Failover Protocol 

126 

Extension 

127 

Extension 

482 Beyond DHCP - Work Your TCP/IP Internetwork with Dynamic IP 

By convention, OS/2 Warp (and likely other IBM products) may use additional 
DHCP options in the 200 to 208 range. You may wish to use these same 
option numbers for the same purposes, even on non-IBM platforms. 

200 Default LPR Printer 

201 Default Gopher Server 

202 Default WWW Home Page 

203 Default WWW Proxy Gateway 

204 Default WWW News Server 

205 Default SOCKS Server 

206 NFS Mount Points 

207 Default X Font Servers 

208 X Display Manager Servers

----END

Which is a bit scary as we didn't have all of these.

But ... I think we are OK ... as:
1) They MAY be "reassigned" to new options.
2) IANA SHOULD reassigned only after "truly" unused option codes have been assigned. (Though of course, that is only as good as the information provided as to what an truly unused code is.)
3) But there's no harm in letting IETF documents request values that "MAY" be reassigned (see 1) .

- Bernie

-----Original Message-----
From: dhcwg <[email-masked]> On Behalf Of Michael Richardson
Sent: Tuesday, June 23, 2020 5:06 PM
To: Bernie Volz (volz) <[email-masked]>; [email-masked]
Subject: Re: [dhcwg] rfc3679bis, or: about allocation of DHCPv4 options (was [IANA #1172829] Request for Early Allocation of DHCPv4 option (draft-ietf-dhc-v6only)

    > concern would hopefully have stepped forward? Or perhaps may in the

I doubt it: I think that if there was any use of 108 it's in places that can't spell IETF.

Understood.

    > reason to disallow folks from recommending values if they have some

As I read the RFC3679 recommendations, it seems that IANA was not actually following them.