Subject: [dhcwg] Updated draft-ietf-dhc-dhcpv6-remoteid-01.txt

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sun, 5 Mar 2006 17:42:31 -0500

Hello:

I have just submitted
ftp://ftpeng.cisco.com/volz/draft-ietf-dhc-dhcpv6-remoteid-01.txt to
hopefully address the IESG discuss items
(https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot
&ballot_id=1835&filename=draft-ietf-dhc-dhcpv6-remoteid).

The differences of significance from the -00 draft are below.

- Bernie

 3.  The Relay Agent Remote-ID Option
 
    This option MAY be added by DHCPv6 relay agents which terminate
    switched or permanent circuits and have mechanisms to identify the
-   remote host end of the circuit.  The remote-id field MAY be used to
-   encode, for instance:
+   remote host end of the circuit.
 
-   o  a "caller ID" telephone number for dial-up connection
-   o  a "user name" prompted for by a Remote Access Server
-   o  a remote caller ATM address
-   o  a "modem ID" of a cable data modem
-   o  the remote IP address of a point-to-point link
-   o  a remote X.25 address for X.25 connections
-   o  an interface identity, which might be the switch's DUID [1]
-      suffixed by the interface-id from the DHCPv6 Interface-Id option.
 
-   The remote ID MUST be globally unique.
 
---

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |       OPTION_REMOTE_ID        |         option-len
|
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                       enterprise-number
|
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        .
.
        .                           remote-id
.
        .
.
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
-         option-code      OPTION_REMOTE_ID (TBD)
+       option-code        OPTION_REMOTE_ID (TBD)
+
+       option-len         4 + the length, in octets, of the remote-id
+                          field. The minimum option-len is 5 octets.
+
+       enterprise-number  The vendor's registered Enterprise Number as
+                          registered with IANA [5].
 
-         option-len       length, in octets, of the remote-id field.
-                          The minimum length is 1 octet.
+       remote-id          The opaque value for the remote-id.
+
+   The definition of the remote-id carried in this option is vendor
+   specific.  The vendor is indicated in the enterprise-number field.
+   The remote-id field MAY be used to encode, for instance:
+
+   o  a "caller ID" telephone number for dial-up connection
+   o  a "user name" prompted for by a Remote Access Server
+   o  a remote caller ATM address
+   o  a "modem ID" of a cable data modem
+   o  the remote IP address of a point-to-point link
+   o  a remote X.25 address for X.25 connections
+   o  an interface or port identifier
 
-         remote-id        The opaque value for the globally unique
-                          remote-id.
+   Each vendor MUST assure that the remote-id is unique for their
+   enterprise-number, as the octet sequence of enterprise-number
+   followed by remote-id MUST be globally unique.  One way to achieve
+   uniqueness might be to include the relay agent's DUID [1] in the
+   remote-id.

--- 

    use this information to select parameters specific to particular
-   users, hosts, or subscriber modems.  The remote-id SHOULD be
-   considered an opaque value, with policies based on exact string
match
-   only; that is, the option SHOULD NOT be internally parsed by the
-   server.
+   users, hosts, or subscriber modems.  The combined enterprise-number
+   and remote-id SHOULD be considered an opaque value, with policies
+   based on exact string match only; that is, the remote-id field
SHOULD
+   NOT be internally parsed by the server.
 
    There is no requirement that a server return this option and its
data
    in a RELAY-REPLY message.
 
---

+   Note that even if the DHCP server trusts the relay agent not to
+   modify information provided in this option, the confidence in that
+   information is no higher than the confidence that the relay agent
has
+   in the information it puts in the option.  For example, in some
+   protocols it may be possible for a DHCP client to spoof or otherwise
+   choose port identifiers, caller ID information, or other information
+   carried in this option.  Sites should consider such possible
spoofing
+   and how likely it is in their environment when deciding what uses of
+   this option are appropriate.

---
 
+   [5]  "IANA. Private Enterprise Numbers.",
+        <http://www.iana.org/assignments/enterprise-numbers.html>.
+

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

---

From: Sam Hartman <[email-masked]>
Date: Sun, 05 Mar 2006 19:28:18 -0500

That text clears my discuss.  I don't have good enough network to go
update my ballot now, but will do so Monday.

---

From: Robert Elz <[email-masked]>
Date: Mon, 06 Mar 2006 15:57:44 +0700

Date:        Sun, 5 Mar 2006 17:42:31 -0500
    From:        "Bernie Volz \(volz\)" <[email-masked]>
    Message-ID:  <[email-masked]>

  | +   Each vendor MUST assure that the remote-id is unique for their
  | +   enterprise-number,

I know this message is unlikely to do any good, as it never has before,
but you really shouldn't be using MUST to attempt to tell people what
they're required to do.   The 2119 type "magic words" are intended to
make statements about implementation conformance to the protocol,
they allow an implementation to say that "Yes, I conform to rfcWXYZ",
or "I conditionally conform to rfcWXYZ".   That makes no sense for
this particular statement, my DHCP server (or relay agent, or client)
cannot be conforming or non conforming based upon what values some
vendor happens to have mistakenly assigned in duplicate.

  |                          as the octet sequence of enterprise-number
  | +   followed by remote-id MUST be globally unique.

That one is even less appropriately used, and should just be "must"
as it isn't any kind of admonition as to what an implementation (or
even person in this case) is required to do in order to conform, it
is simply a statement of a fact required by the protocol.

Just as a contrast, the uses of SHOULD and SHOULD NOT in regards to
treating these values as opaque data are entirely appropriate - I am
not saying that SHOULD is right rather than MUST, I don't know enough
about this draft to have that kind of opinion - just that the use of
a 2119 term in those places is the right thing to do, as there it is
a requirement on an implementation of this particular DHCP option,
and how a server (etc) should behave when the option is encountered.
That is the kind of thing a server can conform to (or in the case of
a SHOULD, can decide not to conform to, and explain why not, or in
what circumstances it is ignored.)

kre