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

["Bernie Volz (volz)" <[e-mail]>]

Hi:

I thought I had sent something but I guess I didn’t …

Anyway, I checked the -08 when it was published and looks ready to me!

Thanks much!

Hopefully it can move to RFC-Editor queue soon!!

- Bernie

On 11/6/18, 6:43 AM, "[e-mail]" <[e-mail]> wrote:

    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