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

"Bernie Volz (volz)" <volz@cisco.com> Mon, 05 November 2018 15:24 UTC

From: "Bernie Volz (volz)" <volz@cisco.com>
To: "ianfarrer@gmx.com" <ianfarrer@gmx.com>, dhcwg <dhcwg@ietf.org>
CC: "draft-ietf-dhc-dhcp4o6-saddr-opt@ietf.org" <draft-ietf-dhc-dhcp4o6-saddr-opt@ietf.org>, "dhc-chairs@ietf.org" <dhc-chairs@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, Eric Rescorla <ekr@rtfm.com>
Thread-Topic: New Version Notification for draft-ietf-dhc-dhcp4o6-saddr-opt-07.txt
Thread-Index: AQHUdAdzBW8Chuc5HEStiPnEWf9kk6VBTDiw
Date: Mon, 05 Nov 2018 15:23:59 +0000
Message-ID: <24d257b09bc74dd1b30c977e62400dfd@XCH-ALN-003.cisco.com>
References: <799BD1D2-A40B-401B-8D46-EFABFA187FEF@gmx.com>
In-Reply-To: <799BD1D2-A40B-401B-8D46-EFABFA187FEF@gmx.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/jpp3s8TG2V-GXEb9QDcfWb3SAEg>
Subject: Re: [dhcwg] New Version Notification for draft-ietf-dhc-dhcp4o6-saddr-opt-07.txt
Precedence: list

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: ianfarrer@gmx.com <ianfarrer@gmx.com> 
Sent: Sunday, November 4, 2018 1:27 AM
To: dhcwg <dhcwg@ietf.org>
Cc: draft-ietf-dhc-dhcp4o6-saddr-opt@ietf.org; dhc-chairs@ietf.org; iesg@ietf.org; Eric Rescorla <ekr@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

Re: [dhcwg] New Version Notification for draft-ie… ianfarrer
Re: [dhcwg] New Version Notification for draft-ie… Bernie Volz (volz)
Re: [dhcwg] New Version Notification for draft-ie… ianfarrer
Re: [dhcwg] New Version Notification for draft-ie… Bernie Volz (volz)