v6ops-nat64-pb-statement-req-00 comments

[Pekka Savola <pekkas@netcore.fi>]

My high-level comment on the draft is that we IMHO need to give a 
brief description of the translation scenarios that the solution(s) 
should address.  This gives much better context on the requirements 
and what's behind them.  And I don't mean something like the list in 
Section 3.1 or Figure 2; those are so simplistic that are useless in a 
document like this.

In Section 3.2:
          In addition, there
   is an architectural consideration, that we would be imposing v6-only
   nodes to support "NAT hacks" in order to enable communication with
   the v4 world, and that those modifications may stay forever, even
   when the need for communication with the v4-Internet is not so
   pressing.

I'm not sure if I see this as a very convincing argument.  If the "NAT 
hack" is not made on the v6-only host, it will be made in a translator 
in the network, which probably also may stay forever.  Which of these 
two options is worse from architectural point of view?  Putting it in 
a host gives the host a potential to have insight in how the hack 
works; in the network, this would likely be essentially a black box.

4. Requirements for new generation of v4-v6 translation mechanisms

   This list of requirements basically should contain all the aspects
   that should be considered when designing a new generation of
   translation mechanisms.

This begs the question, "can we describe the scenarios where these 
translation mechanisms would be deployed?".  And I'm not interested in 
a list like shown in Section 3.1.  What I would be very interested in 
seeing is a concrete example of deployment cases (e.g. about 1-2 
paragraphs of concise text per case).  This would ground this work in 
reality and given much better context to what problems we are actually 
trying to solve.  I think folks have been discussing about 2-4 
applicable scenarios that should be covered by this document.

Section 4.1 R5 "IPv6 routing should not be affected in any way". 
Some mandatory requirements use uppercases, some don't.  The practise 
should probably be made uniform one way or the other.

Section 4.1 R9 "MUST not result in a significantly vulnerable 
Internet" -- compared to what?  What we currently have?  Do we have 
that described or defined somewhere?  This will be prone to arguments 
later on if this is not clear enough now.

editorial
---------

Section 2.1.3 "translated forwarded" -- is something missing here?

Section 2.1.3 talks about embedding in "a "privacy address".  I have 
no idea what this means.  RFC4941 certainly doesn't consider any kind 
of embedding like this.

Section 2.2 says: "Some are turning off IPv4 immediately, at least as 
a customer service."  -- this seems like an overly broad statement, 
requiring at least a reference.  I haven't seen anyone mentioning 
which network/ISP/whatever would go this far, or even plan to do it?

Section 3.1: s/distcntion/distinction/

Section 3.2: s/f other/if other/, s/e modified/be modified/.

Section 3.4: s/NAT4/NAT46/ ?

Section 4.1 R3 s/wich/which/, R8 s/suport/support/.
Section 4.1 and 4.2 in general could use a proofreading and making 
sure each sentence ends to a dot :-).

Section 4.2 I1 is missing, is it intentional?

Section 4.2 I2 IMHO implies that the NAT box wouldn't even need to be 
on the (regular) forwarding path, is this interpretation correct?

Section 6: R10 on DNSSEC also strongly relates to security issues.




--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings