Softwire Provisioning Using DHCPv4 over DHCPv6
draft-ietf-dhc-dhcp4o6-saddr-opt-08

Thanks to everyone involved for the work they did on this document.

I agree with Alissa's request for the addition of privacy considerations.

---------------------------------------------------------------------------

§7.2.1:

>  the client's IPv6 will change.  E.g., if there is an IPv6 re-

Nit: "...the client's IPv6 address will change."

---------------------------------------------------------------------------

§9:

>  For such an attack to be effective, the attacker would need to know
>  both the client identifier and active IPv4 address lease currently in
>  use by another client.  The risk of this can be reduced by using a
>  client identifier format which is not easily guessable, e.g., by
>  including a time component for when the client identifier was
>  generated (see [I-D.ietf-dhc-rfc3315bis] Section 11.2).

I might be missing something here, but my understanding is that DHCP isn't
confidential, and so attackers on the same segment might be able to observe
another client's identifier and IPv4 address in the DHCP traffic itself
(depending on the nature of the networking equipment). Even if
this cannot be easily mitigated, I think it's worth mentioning.

---------------------------------------------------------------------------

§10:

>  IANA is requested to update the entry for DHCPv6 Option S46_BR (90)
>  in the Option Codes table at https://www.iana.org/assignments/
>  dhcpv6-parameters as follows:
>
>  Old entry:
>
>  |    90 | S46_BR                  | No                  | No        |
>
>  New entry:
>
>  |    90 | S46_BR                  | Yes                 | No        |

This is a somewhat unconventional way to represent IANA actions. This format
does not make sense in a vacuum; and, more importantly, and will lose meaning
in the case that the corresponding registry table is ever expanded. I also
note that the name is incorrect (S46_BR instead of OPTION_S46_BR), and that
the Reference column is omitted (which is relevant, as I believe the intenion
is to instruct IANA to add this document to the list of references).  Please
consider reformatting as:

  Old Entry:

    Value:             90
    Description:       OPTION_S46_BR
    Client ORO:        No
    Singleton Option:  No
    Reference:         [RFC7598]

  New Entry:

    Value:             90
    Description:       OPTION_S46_BR
    Client ORO:        Yes
    Singleton Option:  No
    Reference:         [RFC7598] [RFCxxxx]


>  IANA is also requested to make a new entry for
>  OPTION_S46_BIND_IPV6_PREFIX (TBD1) in the Option Codes table at
>  https://www.iana.org/assignments/dhcpv6-parameters:
>
>  |  TBD1 |OPTION_S46_BIND_IPV6_PREFIX| Yes               | Yes       |

Similarly:

    Value:             TBD1
    Description:       OPTION_S64_BIND_IPV6_PREFIX
    Client ORO:        Yes
    Singleton Option:  Yes
    Reference:         [RFCxxxx]

I think this document could benefit from some discussion of the privacy considerations associated with the new options specified in the document. E.g., if one were to apply the analysis in RFC 7844, what would the guidance be to clients that want to limit the disclosure of information about themselves? (It might be "don't use DHCP4o6," but even that is worth saying if that's the best advice available.)

I agree with Alissa's comment privacy comment.

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

Section 7

   It is also a prerequisite that the client has already learned a
   suitable IPv6 prefix to use for its local softwire endpoint using
   DHCPv6, RA/PIO or another mechanism.

I think I'm confused.  Is the OPTION_S46_BIND_IPV6_PREFIX option a way to
obtain the "suitable IPv6 prefix" above?  If so, then "prerequisite" may
not be the best word to use here.

Section 7.2.1

   Across the lifetime of the leased IPv4 address, it is possible that
   the client's IPv6 will change.  E.g., if there is an IPv6 re-
   numbering event.

nit: The last sentence is a sentence fragment.

Section 9

With address-binding mechanisms such as these we also try to consider the
possibility of binding an unexpected address to an unsuspecting recipient,
e.g., to direct a large flow of traffic to a victim unable to process it
all.  I did not see an immediate way for an attacker to do this, since it
would seem like it would either require DHCPv4 to assign the same address
twice or allow a duplicate v6/v4 softwire binding, but I am not sure I have
the full picture in my head yet.  It would be good to include some text on
this class of attacks, even if it is just "redirecting existing flows to an
unsuspecting victim is not possible because <reason>".

Thank you for addressing my DISCUSS