[dhcwg] New Version Notification for draft-ietf-dhc-dhcp4o6-saddr-opt-07.txt

[i***@gmx.com]

Hi,

I’ve just submitted -07 of draft-ietf-dhc-dhcp4o6-saddr-opt, updated to address comments received from the IESG ballot.

Thanks,
Ian

[Bernie Volz (volz)]

Ian:

Thanks.

For the following new text:

8.2. Handling Conflicts Between Client's Bound IPv6 Source Addresses

In order for traffic to be forwarded correctly, each CE's softwire
IPv6 source addresses must be unique. To ensure this, on receipt of
every client DHCPREQUEST message containing OPTION_DHCP4O6_S46_SADDR,
the DHCP 4o6 server MUST check the received IPv6 address against all
existing CE source addresses stored for active client IPv4 leases.
If there is a match, then the client's source address MUST NOT be
stored or updated.

Wouldn't the last sentence here cause renewals (DHCPREQUEST) to fail? Shouldn't this say something like "If there is a match not belonging to the DHCPREQUEST's client, then ..."?

For new section 9 text:

1. One customer learning the active IPv4 address lease and client
identifier of another customer via snooping the DHCP4o6 message
flow between the client and server. The mechanism described in
this document is intended for use in a typical ISP network
topology with a dedicated layer-2 access network per-client,
meaning that snooping of another client's traffic is not
possible. If the access network is a shared medium then it
provisioning softwire clients using dynamic DHCP4o6 as described
here is NOT RECOMMENDED.

In the last sentence, the "then it" seems broken? Should the "it" be dropped?

And, in the new section 9.1, the term "IID" is introduced. And, oddly, RFC7844 and RFC7597 (the two references in that text) never use this. Perhaps the first use should be "if the client's software interface identifier (IID) is immutable."?


Perhaps others will have additional comments (so you may not want to publish the -08 just yet).

- Bernie

-----Original Message-----
From: ***@gmx.com <***@gmx.com>
Sent: Sunday, November 4, 2018 1:27 AM
To: dhcwg <***@ietf.org>
Cc: draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org; dhc-***@ietf.org; ***@ietf.org; Eric Rescorla <***@rtfm.com>
Subject: Re: New Version Notification for draft-ietf-dhc-dhcp4o6-saddr-opt-07.txt

Hi,

I’ve just submitted -07 of draft-ietf-dhc-dhcp4o6-saddr-opt, updated to address comments received from the IESG ballot.

Thanks,
Ian

[i***@gmx.com]

Hi Bernie,

Thanks for the comments, please see inline. I’ve prepared -08 with the changes below, your comments for the IANA section from 19th Oct and also Amanda’s comments. I’ll hang on for a day or two before I post in case there’s any further comments.

Thanks,
Ian

Post by Bernie Volz (volz)
Thanks.
8.2. Handling Conflicts Between Client's Bound IPv6 Source Addresses
In order for traffic to be forwarded correctly, each CE's softwire
IPv6 source addresses must be unique. To ensure this, on receipt of
every client DHCPREQUEST message containing OPTION_DHCP4O6_S46_SADDR,
the DHCP 4o6 server MUST check the received IPv6 address against all
existing CE source addresses stored for active client IPv4 leases.
If there is a match, then the client's source address MUST NOT be
stored or updated.
Wouldn't the last sentence here cause renewals (DHCPREQUEST) to fail? Shouldn't this say something like "If there is a match not belonging to the DHCPREQUEST's client, then …"?

[if - Good point. Let’s not throw the baby out with the bath water! I’ve changed it to:

In order for traffic to be forwarded correctly,
each CE's softwire IPv6 source addresses must be unique.
To ensure this, on receipt of every client DHCPREQUEST
message containing OPTION_DHCP4O6_S46_SADDR, the
DHCP 4o6 server MUST check the received IPv6 address
against all existing CE source addresses stored for
active client IPv4 leases. If there is a match for
any active lease other than the lease belonging to
the client sending the DHCPREQUEST, then the
client's IPv6 source address MUST NOT be stored or
updated.
]

Post by Bernie Volz (volz)
1. One customer learning the active IPv4 address lease and client
identifier of another customer via snooping the DHCP4o6 message
flow between the client and server. The mechanism described in
this document is intended for use in a typical ISP network
topology with a dedicated layer-2 access network per-client,
meaning that snooping of another client's traffic is not
possible. If the access network is a shared medium then it
provisioning softwire clients using dynamic DHCP4o6 as described
here is NOT RECOMMENDED.
In the last sentence, the "then it" seems broken? Should the "it" be dropped?

[if - done]

Post by Bernie Volz (volz)
And, in the new section 9.1, the term "IID" is introduced. And, oddly, RFC7844 and RFC7597 (the two references in that text) never use this. Perhaps the first use should be "if the client's software interface identifier (IID) is immutable.”?

[if - done]

Post by Bernie Volz (volz)
Perhaps others will have additional comments (so you may not want to publish the -08 just yet).
- Bernie
-----Original Message-----
Sent: Sunday, November 4, 2018 1:27 AM
Subject: Re: New Version Notification for draft-ietf-dhc-dhcp4o6-saddr-opt-07.txt
Hi,
I’ve just submitted -07 of draft-ietf-dhc-dhcp4o6-saddr-opt, updated to address comments received from the IESG ballot.
Thanks,
Ian