Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcp4o6-saddr-opt-01.txt

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 17 Jan 2018 23:15:16 +0000

Hi:

I reviewed the updated draft and have a bunch of comments/issues.

Section 5 (figure and steps):

- Why is "/128 IPv6 software source address" used? Can the /128 be dropped? Isn't IPv6 address sufficient to denote what it is? Does the /128 care any significance above and beyond what "IPv6 address" would infer? (This is also used in other places in the document if I recall.)

- What happens if a DHCPNAK is sent by the server (perhaps the DHCPOFFERed address is no longer available)? This would also impact section 7.1 to add some discussion about DHCPNAK.

Section 6.1:

- "The field is padded on the right with zero bits up to the nearest octet boundary". Wouldn't "next octet boundary" be more correct? I guess you can't pad to less bits, so perhaps it "nearest" is OK? (i.e., if length is 41 the nearest is 40 if padded is ignored; 48 is what you'd want and so next would be cleaner?)

Section 6.2

- Option field definition ... "that the client has bound". If I understand correctly, this is sent in the DHCPREQUEST / (and DHCPACK). But until the client receives the DHCPACK, it probably hasn't bound to this yet. So, is "will bind" more appropriate than "has bound"? (Of course, in the renewal case the "has bound" is more correct.)

- I think in last paragraph, "DHCP-RESPONSE" should be "DHCPV4-RESPONSE"? There are 2 places that need to be fixed in the document.

Section 7

- "... client has already obtained a suitable IPv6 prefix to use for its local softwire endpoint using DHCPv6, SLAAC or another mechanism."

When SLAAC is referenced here it is a bit odd as SLAAC is for stateless addresses, not prefixes? But of course, there is the RFC 8273 (Unique IPv6 Prefix per Host) and draft-pioxfolks-6man-pio-exclusive-bit work. I would think you'd need the draft-pioxfolks-6man-pio-exclusive-bit draft to use this for this document so perhaps a reference to it? Or perhaps remove SLAAC if it really is a prefix that is needed?

Section 7.1

- As mentioned earlier, consider DHCPNAK implications?

Section 7.2.1

- Again, DHCPNAK could be returned by a server?

Section 7.4

- "The receiver MUST only use bits the bind-ipv6-prefix". I think from is missing "bits from the"?

Section 10

- Please improve the IANA considerations to specify the URL for the pages to update. This has been more recent practice to avoid any possible confusion. See https://tools.ietf.org/html/draft-ietf-dhc-access-network-identifier-13 as an example. Something like:

   IANA is requested to assign the OPTION_DHCP4O6_S46_SADDR option code from the
  "BOOTP Vendor Extensions and DHCP Options"  registry,
   <http://www.iana.org/assignments/bootp-dhcp-parameters>.

   IANA is requested to assign the OPTION_S46_BIND_IPV6_PREFIX option code from the
   DHCPv6 "Option Codes" registry,
   <http://www.iana.org/assignments/dhcpv6-parameters>.

Otherwise, the document looks pretty good (though I am not a softwires expert by any means!).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, December 12, 2017 8:39 AM
To: [email-masked]
Cc: [email-masked]
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcp4o6-saddr-opt-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration WG of the IETF.

        Title           : DHCPv4 over DHCPv6 Source Address Option
        Authors         : Ian Farrer
                          Qi Sun
                          Yong Cui
                          Linhui Sun
	Filename        : draft-ietf-dhc-dhcp4o6-saddr-opt-01.txt
	Pages           : 12
	Date            : 2017-12-12

Abstract:
   DHCPv4 over DHCPv6 is a mechanism for dynamically configuring IPv4
   over an IPv6-only network.  For DHCPv4 over DHCPv6 to function with
   some IPv4-over-IPv6 softwire mechanisms and deployment scenarios, the
   operator needs to know the /128 IPv6 address that the client will use
   as the source of IPv4-in-IPv6 softwire tunnel.  This address, in
   conjunction with the clients IPv4 address and (in some deployments),
   the Port Set ID are used to create a binding table entry in the
   operator's softwire tunnel concentrator.  This memo defines a DHCPv6
   option to convey IPv6 parameters for establishing the softwire tunnel
   and a DHCPv4 option (to be used only with DHCP 4o6) to communicate
   the source tunnel IPv6 address between the DHCP 4o6 client and
   server.  It is designed to work in conjunction with the IPv4 address
   allocation process.  This document updates "DHCPv6 Options for
   Configuration of Softwire Address and Port-Mapped Clients" to allow
   the DHCPv6 option OPTION_S46_BR(90) to appear outside of DHCPv6
   softwire container options.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp4o6-saddr-opt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dhc-dhcp4o6-saddr-opt-01
https://datatracker.ietf.org/doc/html/draft-ietf-dhc-dhcp4o6-saddr-opt-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcp4o6-saddr-opt-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg