comments on draft-ipv6-v6ops-nat64-pb-statement-req-00

[Ed Jankiewicz <edward.jankiewicz@sri.com>]

in addition to some editorial comments I sent to Marcelo, I have a few 
substantive comments (some admittedly half-baked) and discussion points 
to raise on the draft.  I'm assuming there will be discussion at IETF 72?
1.  transition versus coexistence:  recognizing that the period of 
coexistence is likely to be longer, I would rather see consistent use of 
the term coexistence rather than transition throughout the document, 
e.g. coexistence scenarios, coexistence tools, etc.
2.  add a sentence in front of the Problem Statement to explicitly state 
this motivation, e.g.  "Settled opinion on the transition from an 
IPv4-dominant network to an IPv6-dominant network was that the period of 
coexistence would be brief, and could be accommodated by dual-stack and 
tunneling.  Operationally, we now expect..."
3.  Deemphasize dual stack.  In para 2.1.1 the statement "the IETF 
strongly prefers and recommends [dual stack] as the operational matters 
are simplest" begs for a citation.  RFC 4213 says dual stack is the most 
straightforward but does not include language recommending or preferring 
this solution.  Also the impetus of this draft is that dual stack solves 
only the simplest part of the problem, and becomes very problematic when 
IPv4 addresses really get scarce (approaching rather than reaching 
exhaustion).   Some have already stated (Alain Durand I recall saying 
something like) "a plan that requires all new end-nodes to be dual-stack 
and to have global IPv4 addresses is a non-starter."  Also an emphasis 
on dual stack creates a "must carry" situation where the core network 
continues to route IPv4 indefinitely.  While we say in para 2.2 that 
turning off IPv4 will be a business decision, the ISP can't make that 
choice without alienating customers that rely on dual stack.  I can 
still plug in a 50 year old rotary dial phone and expect the local telco 
(in the USA at least) to make it work, even though DTMF has been the 
dominant method for nearly that long.
4.  tunnel versus dual NAT:  in para 2.1.2 the statement that IETF 
recommends tunnels rather than dual NAT - that also would need a 
citation, unless this document is making the statement for the first 
time.  Also, I believe if the two NATs know they are in a reflexive 
relationship, they can avoid at least some of the general NAT problems - 
i.e. they should not attempt to translate addresses in application data.
5.  translation network architecture:  this may be beyond scope, but it 
seems to me that in para 2.1.3 there could be several sub-scenarios 
depending on the location of the translator
   a.  translator coupled to IPv6 end-nodes (IPv6 on the LAN side, IPv4 
on the WAN side)
   b.  translator coupled to IPv4 end-nodes (IPv4 on the LAN side, IPv6 
on the WAN side)
   c.  in-network translation gateway (most like NAT-PT)
There are some commercial products in development that fit these 
sub-scenarios, and each has its own strengths and weaknesses.  Pulling 
the translator into an IPv6-only or IPv4-only edge network (a or b) 
avoids some issues and those developers made the choice to restrict 
deployment architecture to simplify their job.  The different deployment 
architectures also have impact on the addressing concerns (para 3.3) and 
namespace (para 3.4).
6.  para 3.5 on market timing seems out of place as an 
implementation/deployment statement in a requirements draft
7.  Requirement R3 would be better stated in the negative:  Translation 
mechanism MUST NOT interfere with native connectivity...depending where 
the NAT64 is in the network it may be a pass-through, or it may not be 
involved at all in the native flow and thus do nothing but non-interference.
8.  Requirement R4 is very broad.  the essence of translating DNS in 
support of NAT64 is to map a query on one side to the equivalent query 
on the other, and do the same with the response.  Of course that mapping 
of names and addresses is non-trivial.  It might help to illustrate this 
mapping process as well as some of the bad behavior that must be avoided.
9.  Requirement R5 seems to forbid any routing table update, but don't 
the addresses that the NAT64 is mapping have to be routable?
10.  Requirement R6 lists a few protocols, but I'm sure others might be 
seen as highly desirable too.  Are we avoiding ALG issues by not 
mentioning higher level protocols like FTP?
11.  where does the interpretation in Requirement R7 that sees the IPv6 
side being like the private side of an IPv4 NAT come from?   the 
opposite could be reasonable too - i.e. if there is no NAT between the 
NAT64 and the v4-only nodes the v4-only nodes might be using private 
addresses, and the IPv6 side of the NAT64 is the public side.  The way 
it is described in R7, the IPv6 addresses are like IPv4 private 
addresses, mapped to the global addresses on the public side.
12.  Requirement R9 is a noble statement but hardly a "testable" 
requirement; at least we should cite RFC 4942 as guidance, and analyze 
some of the security issues that arise in the different scenarios and 
architectures discussed in the draft.



--
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  ed.jankiewicz@sri.com