Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option

[<[e-mail]>]

Hi Lorenzo,

Please see inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:[e-mail]]
Envoyé : jeudi 5 décembre 2019 15:19
À : BOUCADAIR Mohamed TGI/OLN
Cc : Jen Linkova; Bjørn Mork; [e-mail]; V6 Ops List; [e-mail]
Objet : Re: [dhcwg] IPv6-Only Preferred DHCPv4 option

On Thu, Dec 5, 2019 at 10:24 PM <[e-mail]<mailto:[e-mail]>> wrote:
Hosts do not do this today, and I don't think they will start doing so. The reason is that they cannot tell whether another protocol will start working. If they wait xxx ms to make sure the other protocol comes up, they are slowing down all connections to single-stack networks by xxx ms, making their users unhappy.

[Med] Do you mean that clients that receive the signal to release IPv4 configuration will make the users unhappy anyway because they will need to wait for the pref64 to properly work?

Well, that's the intent of the pref64 RA option. That allows the pref64 to be communicated in the same packet as the rest of the configuration parameters.
[Med] If there is no delay then, the signals (pref64 presence, v6-only presence) are redundant. No?

Note that IPv6 has built-in delays in the protocol itself (DAD for the link-local address; various randomized delays) that make it very difficult to get anything done before at least 1-2 seconds have passed. Hosts that know that 70% of networks are IPv4-only will not want to wait 1-2 seconds to connect to those networks.

[Med] In that case, what is the benefit for the host to indicate its ipv6-only mode support?

The option improves the situation by allowing the host to wait for IPv6 only if it is expected to exist.
[Med] The host can “wait” without requiring the option. The key point is that an administrator sets “ipv6-mode” supported.

Hosts that implement the option allow networks to provide better service and create an incentive for networks to support IPv6
[Med] I’m not sure about this benefit for the NAT64 case as many features depends on the discovery of the prefix64.

That’s said, I do see a possible value for the network side but for other IPv6-only deployments:


·         CPE in DS-Lite mode

·         CPE in A+P mode

If ds-lite (or a+p) mode is explicitly enabled (managed CPE), DHCPv4 won’t be issued. In addition, if the CPE is ds-lite and a+p compliant, then RFC8026 will be used. No need for additional signal.

Now, if the CPE is ds-lite/a+p capable (non-managed CPE) but does not know if the network is ds-lite/a+p capable, the CPE will issue both DHCPv4 and DHCPv6 requests. If no “checks” are implemented at the DHCPv4 server side, the CPE may be assigned an IPv4 address in addition to receiving OPTION_AFTR_NAME. The CPE will need to release the IPv4 address.

With your option, the situation will be much more simple and the server will be returning an address in 192.0.0.0/29 (RFC6333, Section 5.7).

Cheers,
Med