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

[Jen Linkova <[e-mail]>]

Hi Jordi,

On Sun, May 26, 2024 at 12:39 AM [e-mail]
<jordi.palet=[e-mail]> wrote:
> 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.

This is explained in the Introduction:
"This document explores the requirements, recommendations, and
challenges associated with deploying IPv6-mostly networks in
enterprise and public Wi-Fi environments. While the principles
discussed may be applicable to other network types, this document's
focus remains on these specific use cases."

I think we shall not be too restrictive - the same principle can be
applied to other networks, not just public WiFi or enterprise, so I
intentionally kept the abstract generic.

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

Don't you think it would be repeating Section 5 (Solution Benefits) then?

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

OK, will fix in -01

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

Ack, will add to -01

> 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

The key thing here is that we can call such device 'v6-only capable'
while it doesn't support CLAT! (I'm not sure if it's clear enough from
the doc or not, but currently the rule of thumb is 'you SHOULDN'T call
a device 'v6-only capable if it doesn't have CLAT - there are
exceptions etc, but in general - no'.
So it doesn't matter if the device uses PLAT or not, what's important
is that you can still disable IPv4 for them.
I'll think about how to clarify that..

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

Please note that the full sentence is:
"if not all internal services are IPv6-enabled, then NAT64 might need
to be performed closer to the clients."

Here is an example scenario (extremely simplified, indeed, just to
illustrate my point):
Let's say you have a router which serves two network segments:
workstations (IPv6-mostly) and printers, and also has an uplink to the
Internet edge.
If you only need NAT64 to reach IPv4-only Internet destinations, then
you can safely deploy NAT64 somewhere at the Internet edge and send
all NAT64 from your v6-only workstations upstream.
But if your printers are IPv4-only, how would you let your IPv6-only
workstations talk to those printers? By sending traffic upstream to
NAT64 and then back? ACL config would be fun too..
Doing translations close to the source might be beneficial in this case.

>I tend also to prefer in deployments to exclude some prefixes in the DNS64 config to avoid translating RFC1918.

If you are using the WKP it should happen automatically, right?

> 4.3.2. 464XLAT
>
> CLAT MUST be enabled ?

I do not think we shall make such a strong statement. It's up to the
administrators - if they control the devices and know they work w/o
CLAT - how can we say 'MUST'?

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

I have a lot of endpoints which are (or were) IPv6-only w/o CLAT. Most
of them just run a very limited set of applications and all those
applications are doing the right thing (no v4 literals etc), so they
work fine.

This document is trying to provide some general recommendations ("if
you do not know your fleet, you might want to do this") but still
allow people to do smth differently, if they have reasons.

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

Ack, will do.

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

Do you mean PCP or smth else?

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

Ack.

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

Nope, the previous sentence reads: " such systems would not be able to
run clat,"

The scenario we are talking about here is systems which use RFC7050 to
find the NAT64 prefix (and do not implement RFC8880 - the next
revision will make it explicit).
So if such system doesn't use the network DNS64 (because the system is
configured to use 3rd-party DNS - such as a corporate DNS over
HTTPS/TLS) - it can not detect NAT64 prefix and can not run clat.

> 4.3.4. DNS vs DNS64
>
> I think this section needs a lot of extra thinking/work. Some points raised here.

[skip]

Thanks, -01 will have that section rephrased.

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

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

I have had non-zero tickets opened because of DNSSEC being broken.
So yes, the numbers are low but non-zero.


--
Cheers, Jen Linkova