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

From: [email-masked]
Date: Sat, 17 Mar 2018 23:54:30 -0700

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-02.txt
	Pages           : 14
	Date            : 2018-03-17

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 IPv6 address that the client will use as
   the source of IPv4-in-IPv6 softwire tunnel.  This address, in
   conjunction with the client's 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.

   This document updates RFC7598, allowing OPTION_S46_BR (90) to be
   enumerated in the DHCPv6 client's ORO request and appear directly
   within subsequent messages sent by the DHCPv6 server.

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-02
https://datatracker.ietf.org/doc/html/draft-ietf-dhc-dhcp4o6-saddr-opt-02

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

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/

---

From: [email-masked]
Date: Mon, 19 Mar 2018 09:36:37 +0000

Hi,

This update addresses a few comments received since the last update:

1, Bernies review from the 18th Jan (thanks Bernie) - detail on the changes given below.
2, Added a pointer in the abstract that this draft updates RFC7598 (flagged by I-D Nits).
3, A new paragraph has been added based on a possible exploit raised by a developer working on a server implementation:

The server MAY implement a policy enforcing a minimum time
 interval between a clients updating its softwire source
IPv6 address. If a client attempts to update the softwire
source IPv6 address before the minimum time has expired,
the server can either silently drop the client's 
message or send back a DHCPACK message containing the
exisiting IPv6 address binding in
OPTION_DHCP4O6_S46_SADDR. 

As ever, any comments, reviews etc. welcome.

Thanks,
Ian

Bernie’s comments from 18th Jan.

> 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.)

[if - Removed /128 throughout]

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

[if - Changed the intro text to section 5 to read:
The following diagram shows the relevant extensions to the successful DHCP 4o6 IPv4 allocation client/server message flow for
       the softwire source address function. The full process, including  error handling is described in Section 7.
]

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

[if - Changed to ‘next’]

> 
> 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.)

[if - Changed the description to:

softwire-ipv6-src-address: 16 bytes long; The IPv6  address that is associated (either being requested for binding or currently bound) with the client's IPv4
       configuration.
]

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

[if - Changed throughout]

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

[if - Changed to:

It is also a prerequisite that the client has already learned a suitable IPv6 prefix to use for its local softwire endpoint
      using DHCPv6, RA/PIO or another mechanism.
]

> 
> Section 7.1
> 
> - As mentioned earlier, consider DHCPNAK implications?

[if - Added the following para:

If the client receives a DHCPv4 DHCPNACK message from the server,
  then the configuration process has been unsuccessful.  The client
  then restarts the process from Step 1 of Figure 1.
]

> 
> Section 7.2.1
> 
> - Again, DHCPNAK could be returned by a server?

[if - Added the following para:

  If the client receives a DHCPv4 DHCPNACK message in repsonse from the
  server, then the renew/rebind process has been unsuccessful.  In this
  case, the client MUST stop using the configured IPv4 address.  The
  client then restarts the process from Step 1 of Figure 1.

]

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

[if - Fixed]

> 
> 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 <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 <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 <http://www.iana.org/assignments/dhcpv6-parameters>>.

[if - Updated]

> On 18. Mar 2018, at 07:54, [email-masked] wrote:
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg