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

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Ed,

On 2008-07-19 07:22, Ed Jankiewicz wrote:
> 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.

Yes. As some of us having been saying for *many* years, in my case, since
RFC 1671.

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

I deny that. I personally have always expected many years of coexistence,
and I don't know where this "settled opinion" was to be found.

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

That doesn't belong in that document. You're possibly correct that no
IETF document formally states the strong preference for dual stack as
the coexistence mechanism, but it's the implicit assumption throughout
pretty much everything NGTRANS and V6OPS have done. I don't think we
should rewrite history, and dual stack is still the best way we know
(for reasons stated in RFC 1671, which of course has absolutely no
authority whatever).

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

Correct, but that argues for more v4/v4 NAT, not against dual stack.

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

Bingo. I'm sure ISPs will still be routing IPv4 for 15 years; not so
clear about 50.

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

If you mean by "reflexive" that the NAT mapping is reversed before delivery,
sure, that's invisible to the upper layer and is isomorphic with a tunnel.
But do such devices exist?

The IETF definitely recommends avoiding irreversible NAT when possible,
and therefore the statement that tunnels are preferred is definitely true.

   Brian