[v6ops] draft-link-v6ops-6mops-00

["[e-mail]" <[e-mail]>]

Hi Jen,

Tks for the document! Some inputs.

0. Abstract
typo: a deployment

Are we targeting to an enterprise (or even home) network, right? I will assume that in some of the inputs below. May be it needs to be made clear in the abstract.

1. Intro

A reader can say keeping IPv4 private addresses is not a trouble … So may be that need to be stressed in the document.

For example replace
	IPv6 adoption: IPv4 address exhaustion.
with 
	IPv6 adoption: IPv4 address exhaustion, even for private IPv4 addresses in some cases.

Then add some text regarding the “added cost and complexity” of unnecessarily keeping dual-stack. It means extra opex, energy, human resources, monitoring tools, more possible security issues, etc.

I will not use migration, instead transition, across all the document (see my previous email today with inputs for draft-link-v6ops-claton-03.txt).

Same with public WiFi, instead Wi-Fi hotspot.

Definitively, in the intro it should be clear that allowing devices to opt-out from IPv4 helps to move faster to a read IPv6-only world, and it has no negative impact on networks, instead it is positive, because as more and more devices stop using IPv4, you have less worries.

4. Solution Overview

Dual-Stack Endpoint (Not IPv6-Only Capable). I’ve seen enterprise networks that still prefer to manually configure IPv4. Obviously I will not recommend that, but to have a more complete description of this case, I will change:

	Additionally, it obtains an IPv4 address via DHCPv4

with
	Additionally, it obtains an IPv4 address via DHCPv4 or manually configured.
or
	Additionally, it obtains an IPv4 address via DHCPv4 or configured by any other means. (in the future we may want to configure IPv4 using DHCPv6 …)


4.2. IPv6-Only and IPv4-enabled Endpoints Coexistence

	Certain devices, such as resource-constrained embedded systems, may
	operate in IPv6-only mode without CLAT if their communication is
	limited to IPv6-enabled destinations

If those devices are limited to IPv6-enabled destinations, then probably it could be emphasised with:

	operate in IPv6-only mode without CLAT (and not using the PLAT) if their communication is

4.3.1. NAT64
I’m not convinced about this:
	then NAT64
	might need to be performed closer to the clients. If IPv4-only
	internal destinations are using [RFC1918] address space, then the
	operator MUST NOT use the well-known prefix 64:ff9b::/96 for NAT64
	(see section 3.1 of [RFC6052]).

I will say otherwise, unless I’m missundersting the point.

I will recommend to have the NAT64 closer to the network border/connections to Internet … I tend also to prefer in deployments to exclude some prefixes in the DNS64 config to avoid translating RFC1918.


4.3.2. 464XLAT

CLAT MUST be enabled ?

I find difficult to have this case as possible:
   * Option 108 Without CLAT MAY be enabled if the administrator is
willing to identify and fixIPv4-only systems/applications, or if
all applications are confirmed to work in IPv6-only mode.

Only a CLI or GUI doing ping to literals will bypass it. I can understand that if we are talking about headless devices (IoT, etc.), but probably those are already in a specific VLAN, SSID or network segment …


4.3.3. Signalling NAT64 Prefix to Hosts
maybe will be better to define PREF64 in the terminology section?

I think
	In the absense of PREF64 information in
	Router Advertisements such systems would not be able to run clat,

is only true if there is no other way to discover the NAT64 prefix, but there are other alternatives, as described in RFC8585.

(also clat should be CLAT across all the document, not sure if only this occurrence or there are more)

Further to that

	As such device wouldn't be able to
	use the network-provided DNS64, access to IPv4-only destination would

even if DNS64 is not used, there is no impact on the IPv4-only destinations, what actually happens is that everything is double-translated (CLAT and NAT64). See 4.1.1., 4.3. and 4.4. at RFC8683.


4.3.4. DNS vs DNS64

I think this section needs a lot of extra thinking/work. Some points raised here.

	DNSSEC Incompatibility: DNS64 responses fail DNSSEC validation.
Actually not (and in general, based in actual deployment experience), resolvers running DNS64 allow “don’t break DNSSEC”. See 4.1.2. to 4.1.6. in RFC8683.


	Additional requirements for application: to benefit from DNS64,
	applications need to be IPv6-enabled, use DNS (do not use IPv4
	literals). Many applications do not satisfy those requirements
	and therefore fail if the endpoint does not have an IPv4 address/
	native IPv4 connectivity.

I don’t think this is correct. Apps using literals, not using DNS, or using only IPv4, will just get the double translation. I will not clarify this as a drawback, is "on purpose feature” with 464XLAT, it works even if DNS64 is not being used, compared with NAT64 alone, which will never work without DNS64.

	If the network provides PREF64 in RAs (Section 4.3.3) and all
	endpoints are guaranteed to have CLAT enabled, DNS64 is unnecessary
	and SHOULD NOT be enabled.

I think this needs to be reworded. Maybe:

	If the network provides PREF64 in RAs (Section 4.3.3) and all
	endpoints are guaranteed to have CLAT enabled, DNS64 is not indispensable
	and MAY NOT be enabled. However, it has some performance and power consumption impact as there will be a double translation (NAT46 at the CLAT and NAT64 at the PLAT) for any IPv4-only destination flows.


5.1. Benefits Compared to Dual-Stack
Repeating here my input from the intro:
Add some text regarding the “added cost and complexity” of unnecessarily keeping dual-stack. It means extra opex, energy, human resources, monitoring tools, more possible security issues, etc.


7.3.2. Network Extension
typo: However thios approach (this)


A general comment:
My actual experience is that the low level of DNSSEC deployment (and validation), increased IPv6 deployment in content providers, the ability to enable (example Bind, “break DNSSEC no") and the host OSs doing AAAA synthesis just works and I don't find in deployments real cases of broken DNSSEC. This has been reported already in RFC8683. So I'm not convinced at all about suggesting not using DNS64. Unless all the OSs already support AAAA self-synteshis - that should be probably our goal with OS vendors. May be an alternative is to suggest not using DNS64 if the OS supports self-synthesis?



Regards,
Jordi

@jordipalet



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.