Subject: [dhcwg] Ben Campbell's No Objection on draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Oct 2018 14:59:51 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-dhc-dhcp4o6-saddr-opt-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp4o6-saddr-opt/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Alissa's comment privacy comment.

Please consider using the new normative keyword boilerplate from RFC 8174.

---

From: <[email-masked]>
Date: Fri, 12 Oct 2018 07:19:25 +0000

Hi Ben,

Thanks for the comments. Please see inline below.

Regards,
Ian

On 11.10.18, 00:00, "dhcwg on behalf of Ben Campbell" <[email-masked] on behalf of [email-masked]> wrote:

    

[if - (Duplicated from my response to Alissa), proposed new text for Security Considerations
Section:

9.1.  Client Privacy Considerations

   [RFC7844] describes anonymity profiles for DHCP clients.  These
   considerations and recommendations are also applicable to clients
   implementing the mechanism described in this document.  As DHCP4o6
   only uses DHCPv6 as a stateless transport for DHCPv4 messages, the
   "Anonymity Profile for DHCPv4" described in Section 3 is most
   relevant here.

   In addition to the considerations given in [RFC7844], the mechanism
   that the client uses for constructing the interface identifier for
   its IPv6 softwire source address (see Section 7.1), could result in
   the device being trackable across different networks and sessions,
   e.g., if the client's softwire IID is immutable.

   This can be mitigated by constructing the softwire source IPv6
   address as per Section 6 of [RFC7597].  Here, the address' IID
   contains only the allocated IPv4 address (and port set identifier if
   [RFC7618] is being used).  This means no additional client
   information is exposed to the DHCP4o6 server, and will also mean that
   the IID will change as the leased IPv4 address changes (e.g., between
   sessions when Section 3.5 of [RFC7844] is implemented).
]

[if - Updated with the new boilerplate]

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