[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Thanks for the feedback, see comments in-line

Brian E Carpenter wrote:

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.
I can't recall who it was, recently I heard a songwriter say "I always been described as 'ahead of my time' but unfortunately, there is no line at the bank with that label..." It seems like there is rough consensus that coexistence is the right term. 
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.
Fair enough, no need to over-analyze the motivation since it is already agreed that this work needs to be done. The "settled opinion" is more folkloric than historic. 
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).
agree. either we justify the statement by citing authoritative source (apparently non-existent) or remove it. 
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.
perhaps a v4/v4 NAT that includes v6 pass-through, if you mean dual-stack end-nodes with private v4 address space. What I meant by "dual stack solves only the simplest part of the problem" is that it permits coexistence of IPv4 and IPv6 nodes and simultaneous native IPv4 and IPv6 interactions, but it leaves the knottiest problems - how to facilitate interaction of IPv4-only nodes with IPv6-only nodes or applications. While the former do and will dominate for some time, the latter are theoretical. That is a bigger problem than just address mapping that a v4/v4 NAT could solve. There is no one size fits all approach. Dual stack and tunneling should cover the preponderance, address mapping much of the rest, leaving the residual to translation as a last resort. 
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.
Translators definitely exist and I have had discussions with developers about that kind of deployment scenario - it has been considered but not implemented (that I know of) to add the intelligence to the translator to pair up like this. Good point, it is effectively like tunneling with substitution of header rather than wrapping. I can't see reflexive NAT having any advantage over tunneling, so it is more of an academic discussion.
as I said, some of my comments were half-baked: reflexive NAT is not truly reversible, but could effectively be within a v4v6v4 scenario that carries the v4 address as part of the v6 mapping. 
   Brian



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