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

i***@gmx.com

2018-03-19 09:36:37 UTC

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.

I reviewed the updated draft and have a bunch of comments/issues.
- 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.
]

- "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
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]

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
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.
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp4o6-saddr-opt/
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
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
dhcwg mailing list
https://www.ietf.org/mailman/listinfo/dhcwg