Client Link-Layer Address Option in DHCPv6
draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-05

[Ballot discuss]
I have one point to clarify:
Section 4., paragraph 1:

>    DHCPv6 Relay agents which receive messages originating from clients
>    (for example Solicit and Request, but not, for example, Relay-Forward
>    or Advertise) MAY include the link-layer source address of the
>    received DHCPv6 message in Client Link-layer Address option in
>    relayed DHCPv6 Relay-Forward messages.  The DHCPv6 Relay agent
>    behavior can depend on configuration that decides whether the Client
>    Link-layer Address option needs to be included.

  What happens if the client has already included such an option on its
  own? Are clients allowed or not allowed to add such an option? This
  isn't specified explicitly.

[Ballot comment]

- Section 2 says that "...it can be used along with other
identifiers to associate DHCPv4 and DHCPv6 messages from a
dual stack client." Why would this be needed? (Saying "lawful
intercept" is not a good answer here.) I think it'd be useful
to provide a non-LI reason for why this is useful.

- Section 7 could usefully note that if IPsec is not used then
anyone who can see packets sent between the relay agent and
server with this option, or anyone who can see a log that
contains this options's value, can probably track the client
in a new way. That'd be a privacy issue so yet again motivates
use of IPsec but also motivates not logging this option value,
or at least considering security and privacy when doing that.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04. 
Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We understand that, upon approval of this document, there is a single IANA action which needs to be completed.

In the DHCP Option Codes subregistry of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry located at:

http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml

a single new DHCP Option Code is to be registered as follows:

Value: [ TBD-at-time-of-registration ]
Description: OPTION_CLIENT_LINKLAYER_ADDR
reference: [ RFc-to-be ]


Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: EXTENDED Last Call:  (Client Link-layer Address Option in DHCPv6) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Client Link-layer Address Option in DHCPv6'
as Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-02-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Note that this is an extension of the IETF last call that was
originally announced on 2013-02-04. The IETF last call has been
extended because of IPR disclosure 1710, which was published in
reference to draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt.
Because draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt is a
predecessor to draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04.txt,
IPR disclosure 1710 should be considered in this IETF last call.

Abstract


This document specifies the format and mechanism that is to be used
for encoding client link-layer address in DHCPv6 Relay-Forward
messages by defining a new DHCPv6 Client Link-layer Address option.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/ballot/


IPR disclosure 1710 may be relevant to this document.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Client Link-layer Address Option in DHCPv6) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Client Link-layer Address Option in DHCPv6'
  as Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-02-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies the format and mechanism that is to be used
  for encoding client link-layer address in DHCPv6 Relay-Forward
  messages by defining a new DHCPv6 Client Link-layer Address option.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
    is this the proper type of RFC? Is this type of RFC indicated in
    the title page header?

Proposed Standard.  This documents an extension to the DHCPv6
protocol, so it only really makes sense as a PS.  The intended type is
indicated in the header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement
    Write-Up. Recent examples can be found in the "Action"
    announcements for approved documents. The approval announcement
    contains the following sections:

Technical Summary:

This document specifies the format and mechanism that is to be used
for encoding client link-layer address in DHCPv6 Relay-Forward
messages by defining a new DHCPv6 Client Link-layer Address option.

Working Group Summary:

This document was proposed in the working group about a year ago as an
extension for DHCPv6 clients.  There was concern that it would turn
into something that would replace DUID and create interoperability
problems, so the working group developed a rough consensus that we
should implement this as a relay option instead, since this would
prevent it being misused to replace DUID.

Those who disagreed with the consensus, because they would have
preferred a DHCP client option, went along with this because this
solution satisfied their actual use case.  They were encouraged to try
pursuing the client option in the future if they felt it was still
needed.  This was seen as an acceptable compromise by all the
dissenters.

Document Quality:

I'm not aware of any existing implementations.  This is something that
a number of enterprise folks have requested, and we expect to see
implementation in relay agents targeted to those markets.  I think
everyone who's reviewed the document is mentioned in the
acknowledgements section.


Personnel:

Ted Lemon is the document shepherd.  Ralph Droms is the responsible AD.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not
    ready for publication, please explain why the document is being
    forwarded to the IESG.

I read the document thoroughly, and submitted quite a few editorial
suggestions to the authors, which they implemented.  The differences
between the -03 and -04 versions of the document reflect this review.

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

No, the document has had a great deal of review.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the
    review that took place.

This is strictly a DHCP doc, and has had plenty of review from DHCP experts.

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area Director
    and/or the IESG should be aware of? For example, perhaps he or she
    is uncomfortable with certain parts of the document, or has
    concerns whether there really is a need for it. In any event, if
    the WG has discussed those issues and has indicated that it still
    wishes to advance the document, detail those concerns here.

I think the document is good as written, and serves a useful purpose.
It will need some editing by the RFC editor for readability, but these
edits should be very minor--mainly adding in articles where they were
left out due to language differences.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed. If not, explain why?

Guarav Halawasia, Shwetha Bhandari and Woj Dec have indicated that
they are not aware of any IPR other than the Cisco IPR.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.

Cisco filed an IPR on the original non-wg version of this draft, which
for some reason was not carried over to the wg version of the draft,
but is still applicable.  The disclosure in question is IPR disclosure
#1710.  This should be linked back to the working group draft; I would
have done it, but couldn't figure out how.

There was brief discussion on the mailing list, but this is a case
where we're basically screwed.  Cisco was the first to claim to have
invented this blindingly obvious feature.  There's no other way to do
it that wouldn't be covered by the Cisco patent.  So we basically just
have to put up with Cisco's abuse of the patent system, and hope for
the best.  According to the IPR disclosure, if the IETF adopts this as
a standard they won't sue anyone for infringement who doesn't sue them
first for some infringement.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with it?

There is a strong consensus behind this document.  Some working group
participants would have liked it if the document had had wider
applicability, but even those participants agree that the use cases to
which the document is now applicable are the most important ones, so
they were willing to participate in the consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

No, what dissent there was was amicable, and nobody's indicated that
they are upset at the outcome.

(11) Identify any ID nits the Document Shepherd has found in this
    document. (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist). Boilerplate checks are not enough;
    this check needs to be thorough.

The document passes idnits with no errors and one warning about
spacing which can be trivially addressed during the editing process.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type
    reviews.

The document contains nothing like this.

(13) Have all references within this document been identified as
    either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
    for advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their
    completion?

No, all the normative references are to RFCs.

(15) Are there downward normative references references (see RFC
    3967)? If so, list these downward references to support the Area
    Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any
    existing RFCs? Are those RFCs listed on the title page header,
    listed in the abstract, and discussed in the introduction? If the
    RFCs are not listed in the Abstract and Introduction, explain
    why, and point to the part of the document where the relationship
    of this document to the other RFCs is discussed. If this
    information is not in the document, explain why the WG considers
    it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA
    considerations section, especially with regard to its consistency
    with the body of the document. Confirm that all protocol
    extensions that the document makes are associated with the
    appropriate reservations in IANA registries. Confirm that any
    referenced IANA registries have been clearly identified. Confirm
    that newly created IANA registries include a detailed
    specification of the initial contents for the registry, that
    allocations procedures for future registrations are defined, and
    a reasonable name for the new registry has been suggested (see
    RFC 5226).

I had to ask the authors to make a minor change to the IANA
considerations document, which they made; I think it's fine now.

(18) List any new IANA registries that require Expert Review for
    future allocations. Provide any public guidance that the IESG
    would find useful in selecting the IANA Experts for these new
    registries.

None.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

There are no such parts to the document.