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

[[e-mail]]

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

> On 5. Nov 2018, at 22:23, Bernie Volz (volz) <[e-mail]> wrote:
> 
> 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 …"?


[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.
]


> 
> 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?

[if - done]
> 
> 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]

> 
> 
> Perhaps others will have additional comments (so you may not want to publish the -08 just yet).
> 
> - Bernie
> 
> -----Original Message-----
> From: [e-mail] <[e-mail]> 
> Sent: Sunday, November 4, 2018 1:27 AM
> To: dhcwg <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; Eric Rescorla <[e-mail]>
> 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