Subject: Benjamin Kaduk's No Objection on draft-ietf-6man-ra-pref64-08: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 16 Dec 2019 09:19:27 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6man-ra-pref64-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-ra-pref64/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this well-written document!  I just have some fairly minor
comments; the most significant one is a request to expound a bit more in
the security considerations section.

Section 1

   NAT64 [RFC6146] with DNS64 [RFC6147] is a widely-deployed mechanism
   to provide IPv4 access on IPv6-only networks.  In various scenarios,
   the host must be aware of the NAT64 prefix in use by the network.

RFC 6147 sayas that no changes are required to the IPv6 node "for the
class of applications that work through NATs".  Is it only applications
that do not work through NATs that comprise the "various scenarios"
mentioned here?  (Interestingly, neither of the examples in Section 2
seem to fall nicely into that bucket.)

Section 2

      *  Local DNSSEC validation (DNS64 in stub-resolver mode).  As
         discussed in [RFC6147] section 2, the stub resolver in the host
         "will try to obtain (real) AAAA RRs, and in case they are not
         available, the DNS64 function will synthesize AAAA RRs for
         internal usage."  This is required in order to use DNSSEC on a
         NAT64 network.

nit: I think the "this" that is required is "the stub doing the DNS64",
not the AAAA synthesis mentioned in the quoted text.

      *  Networks with no DNS64 server.  Hosts that support AAAA
         synthesis and that are aware of the NAT64 prefix in use do not
         need the network to perform the DNS64 function at all.

side note: I'm curious how common it is for a NAT64 network to not
provide a DNS64 server, though that probably has no bearing on the
contents of this document.

Section 3

   host.  Only one packet (a Router Advertisement) is required to
   complete the network configuration.  This speeds up the process of
   connecting to a network that supports NAT64/DNS64, and simplifies
   host implementation by removing the possibility that the host can
   have an incomplete layer 3 configuration (e.g., IPv6 addresses and
   prefixes, but no NAT64 prefix).

This discussion seems slightly at odds with the premise/assumption in
6146/6147 that hosts will not need to know the NAT64 prefix in order to
function (for applications that work through NAT, at least).  I don't
have any proposed alternative text, though (would just predicating the
discussion on having a host that needs/wants the NAT64 prefix suffice?).

Section 5

   Scaled   13-bit unsigned integer. The maximum time in units of 8
   Lifetime seconds over which this NAT64 prefix MAY be used. The value
            [...]
            lifetime values which are not divisible by 8. In such cases
            the router SHOULD round the provided value up to the lesser
            of nearest integer divisible by 8, or 65528 and divide the
            result by 8 (or just perform a logical right-shift by 3) and
            set the Scaled Lifetime field to the resulting value. If

nit: I think the lone comma before "or 65528" is misplaced and suggest
NEW:

%           lifetime values which are not divisible by 8. In such cases
%           the router SHOULD round the provided value up to the lesser
%           of the nearest integer divisible by 8 and 65528, and divide the
%           result by 8 (or just perform a logical right-shift by 3) and
%           set the Scaled Lifetime field to the resulting value. If

            such a non-zero lifetime value to be divided by 8 (to be
            subjected to a logical right-shift by 3) is less than 8 then
            the Scaled Lifetime field SHOULD by default be set to 1.

I suggest to s/SHOULD by default/SHOULD/

   Highest  96-bit unsigned integer. Contains bits 0 - 95 of the NAT64
   96 bits  prefix.
   of the
   prefix

Am I supposed to zero-fill when the prefix length is less than 96 bits?

Section 6

   When multiple PREF64 were discovered via RA PREF64 Option (the Option
   presents more than once in a single RA or multiple RAs were
   received), host behaviour with regards to synthesizing IPv6 addresses
   from IPv4 addresses SHOULD follow the recommendations given in
   Section 3 of [RFC7050], limited to the NAT64 prefixes that have non-
   zero lifetime.

This seems to have high overlap with a recommendation from Section 4;
could/should the texts be consolidated?

Section 7

   Section 6.2.7 of [RFC4861] recommends that routers inspect RAs sent
   by other routers to ensure that all routers onlink advertise the
   consistent information.  Routers SHOULD inspect valid PREF64 options

nit: I think s/the consistent information/consistent information/

Section 9

I appreciate the discussion that RAs already need to be protected for
normal opration, and that NAT64 prefix delivery, when bundled as an RA
option, can take advantage of those mechanisms.  Nonetheless, I think
it would still be appropriate to mention (either inline or by reference)
the scope of risk/breakage possible when an incorrect NAT64 prefix
(or length) is used.

---

From: Jen Linkova <[email-masked]>
Date: Tue, 17 Dec 2019 11:20:43 +1100

Hi Benjamin,

Thanks for your comments!

> seem to fall nicely into that bucket.)

So RFC6147 says that 'DNS64 is used with an IPv6/IPv4 translator to
enable client-server
communication between an IPv6-only client and an IPv4-only server,
   without requiring any changes to either the IPv6 or the IPv4 node,
   for the class of applications that work through NATs.'.

Maybe I'm wrong but I read ' the class of applications that work
through NATs.' part as applications which are *using* DNS64 and NAT,
not performing DNS and NAT functions. At the same time the examples in
Section 2 fall into two buckets:
1) performing the DNS64 function
2) performing the NAT64 function

Do you think any text is needed here?

> not the AAAA synthesis mentioned in the quoted text.

Would it be better if we say:
"Local DNSSEC validation (DNS64 in stub-resolver mode). As discussed
in <xref target="RFC6147"/> section 2, the stub resolver in the host
"will try to obtain (real) AAAA RRs, and in case they are not
available, the DNS64 function will synthesize AAAA RRs for internal
usage." Therefore to perform the DNS64 function the stub resolver
needs to know the NAT64 prefix. This is required in order to use
DNSSEC on a NAT64 network"
?

> contents of this document.

Partially it's a chicken and egg problem: if I deploy a NAT64 network
I need to provide DNS64 as well because mosts hosts currently have no
knowledge of the NAT64 prefix and can not perform DNS64 functions
themselves. If hosts can receive the prefix information, I might
eventually deprecate DNS64 in my network.
Also that paragraph is following the one about hosts using the trusted
3rd-party DNS servers and those two scenarios are closely related: if
the host can use 3rd-party DNS servers and still work on NAT64
network, then we might get rid of DNS64 function on the network
completely.

> function (for applications that work through NAT, at least).

Well, our intention was not to rely on 6146/6147 assumption (actually
even RFC6147 discusses scenarios when DNS64 might break things) but
instead
first to explain why hosts might need to know the NAT64 prefix (the
section 2 of the draft) and then describe why the RA option and not
RFC7050 for example.

> I don't

How about this: we'll start the section 2 with smth like:
'While RFC6147 assumes that a NAT64/DNS64 environment does not require
any changes on hosts for applications that work through NATs, there
are some cases when  it is useful for hosts to know the NAT64 prefix
..."
?

> %           set the Scaled Lifetime field to the resulting value. If

Oh, that's interesting. The comma was actually suggested by one of the reviewer.
English is not my native language so I probably shouldn't have any
opinions here but
I read 'the router SHOULD round the provided value up to the lesser of
the nearest integer divisible by 8 and 65528'
as 'that integer needs to be divisible by 8 AND 65528'. It's not
really clear that 'and 65528' is for 'the lesser of'.
Also after looking at some language-related forums it looks to me that
a question of 'the lesser of A or B' vs 'the lesser of A and B' is
a rather controversial one..
Also, does your comment apply to the sentence 'The value of the Scaled
Lifetime field SHOULD by default be set to the lesser of 3 x
MaxRtrAdvInterval divided by 8, or 8191' (earlier in the same
paragraph)?

> I suggest to s/SHOULD by default/SHOULD/

It does make sense, I'll fix it in -09.

> Am I supposed to zero-fill when the prefix length is less than 96 bits?

Do you mean the case when, for example, some bits in the positions 64
- 95 are set  to non-zero, while the prefix length is 64?
I believe it's covered in RFC6050 so I do not think we shall specify
it here as we already have documents defining how to use the provided
prefix, while this document
just describe a mechanism to deliver the prefix to the application.

> could/should the texts be consolidated?

Good point. I think we shall consolidate "handing multiple prefixes"
and "prefix consistency" sections under "Usage Guidelines".
Will be done in -09.

> nit: I think s/the consistent information/consistent information/

Will be fixed in -09, thanks!

> the scope of risk/breakage possible when an incorrect NAT64 prefix

Would it address your concern if  we add smth like:

"If a host is provided with an incorrect NAT64 prefix the IPv6-only
host might not be able to communicate with IPv4-only destinations.
Connectivity to destinations reachable over IPv6 would not be impacted
just by providing a host with an incorrect prefix (however if
attackers are capable of sending
rogue RAs they can perform denial-of-service or man-in-the-middle
attacks, as described in RFC6104)."

-- 
SY, Jen Linkova aka Furry

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 16 Dec 2019 17:36:24 -0800

Hi Jen!

> through NATs.' part as applications which are *using* DNS64 and NAT,

I am reading it the same way...

> 2) performing the NAT64 function

... and can only assume that 6147 was assuming that "applications" do not
include the DNS-resolution and NAT functions, presumably for being a "lower
layer" than the application.

> Do you think any text is needed here?

There's no strict need for change, no.  I just always wonder when "various
scenarios" comes up whether more specificity is possible and/or desired.
Answers to that are quite mixed!

> DNSSEC on a NAT64 network"

That would be better, yes.  I think there probably exists a variant that
does not need to add a new sentence, but it may not be worth the effort to
wordsmith further.

> network, then we might get rid of DNS64 function on the network

Okay.

> section 2 of the draft) and then describe why the RA option and not

I think that's a good approach to take.  What stuck out at me here is that
we imply that knowing the NAT64 prefix is somehow a required part of host
configuration for all hosts ("host can have an incomplete layer 3
configuration", "to complete the network configuration").  I don't think
that's strictly-speaking true, since we have some machines running fine for
some users just using the preexisting mechanisms.  But in some sense those
machines have reduced functionality, and they only run fine for those users
because the users in question don't require the missing functionality.
Reality may be a bit mushy in terms of what is "required" for a "complete"
configuration, and it's hard for me to make definitive/universal
statements.

> are some cases when  it is useful for hosts to know the NAT64 prefix

I think that would assuage my concerns; thanks!

> really clear that 'and 65528' is for 'the lesser of'.

Indeed, English is messy.  To make things even more fun, I'm given to
understand that comma usage differs between British English and American
English (though I don't know if that's true for this specific case)!
To me, it's clear that "lesser of" requires at least two operands (and some
might argue it requires exactly two), but the comma is trying to act as a
separator between clauses, which would leave a lonely-and-incomplete clause
"to the lesser of the nearest integer divisible by 8" in the current text.

> a rather controversial one..

I can definitely believe that.

Perhaps it's best to just leave this one to the RPC style editors.

> MaxRtrAdvInterval divided by 8, or 8191' (earlier in the same

I think it would; this one stuck out at me more because there is an
additional operation specified at the end ("and divide the result by 8")
that increases the potential confusion about grouping and
order-of-operations.

> - 95 are set  to non-zero, while the prefix length is 64?

Yes.

> just describe a mechanism to deliver the prefix to the application.

Sure, that seems fine.

> attacks, as described in RFC6104)."

That sounds wonderful; thank you!

-Ben

---

From: Jen Linkova <[email-masked]>
Date: Tue, 17 Dec 2019 14:02:11 +1100

On Tue, Dec 17, 2019 at 12:36 PM Benjamin Kaduk <[email-masked]> wrote:
> What stuck out at me here is that

Well, I think there are two contributing factors here:
1) Internet is changing while RFCs are static. New use cases (such as
464XLAT, DNSSEC, DoT/DoH to 3rd-party servers) have arisen since
RFC6147 was published back in 2011. So now we do have cases when it
would beneficial (or even required) for a host to know the NAT64
prefix.
2) I do not think the draft is saying that *all* hosts must know the
prefix. If it does we might need to change the wording.
As you've said, different hosts have different functionality.
If a host performs DNSSEC validation or 464XLAT or ignores the network
provided resolvers then it needs to know the prefix, so prefix
information arriving after a delay means the host can have incomplete
configuration (== "network configuration which does not allow it to
have the full Internet access").
However some hosts might not need it at all - they are not doing
DNSSEC validation, they do not perform 464XLAT, they only use the
network provided resolvers etc.

> I think that would assuage my concerns; thanks!

Cool, -09 will have that text.

> Perhaps it's best to just leave this one to the RPC style editors.

Yeah, I think it's a good idea.
I'll keep the text unchanged for now.

> That sounds wonderful; thank you!

Sweet, stay tuned for -09 then - will submit before Dec 19th.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 19 Dec 2019 15:30:34 +1100

Hi Benjamin,

> I think that would assuage my concerns; thanks!

Sorry for bringing this topic back but the authors have discussed the
proposed changes and we believe it would be better to avoid mentioning
that assumption the RFC6147 made..
First of all that assumption is not true nowadays anyway - there are a
lot of applications which work just fine on NAT44 networks but fail on
NAT64 ones.
If it was not the case, we would not have clat on mobile phones.
Just mentioning that assumption w/o detailed discussion might be even
more confusing for a reader and 'm not sure that this draft is the
right place to discuss RFC6147 assumptions in details..
The draft enumerates the use cases when - whatever RFC6147 is saying -
the host might need to know the prefix and hopefully it should be
clear for a reader why we are doing this..

It's not like I feel very strongly about it but I'd definitely prefer
to keep the text as it is...
What do you think?

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 20 Dec 2019 15:26:07 -0800

> to keep the text as it is...

I also don't feel strongly about it (and it was only a COMMENT-level note
to begin with).  I was just noting that if a reader came in with context
from RFC 6147 and started reading this text, they might make a false
assumption.  Your argument that this is not the right place to get into a
comprehensive discussion, and that a superficial discussion would not be
helpful, is pretty compelling, though.  So it seems that leaving as-is is
the best path forward.

Thanks,

Ben