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

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

Brian E Carpenter  - Le 7/19/08 5:26 AM :


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.


Brian,

 The role of dual stack during the coexistence period might IMHO be
somewhat clarified, and also simplified, as follows:

- Host capabilities
 o DS (ASAP)
 o IPv6-only (eventually, but slow start)

- Router capabilities
  o DS (ASAP)
  o IPv6-only (eventually, but slow start)

- Interworking functions (at least before global IPv4 shortage)
  . Dual-stack lite carrier grade NATs (DSL-CGNs)
  . Dual-stack lite Public address servers (DSL-PASs)

 The former are those of draft-durand-dual-stack-lite-00. (In ISP
infrastructures, they involve carrier grade NAT44s. In IPv4/IPv6 tunnels
between customer sites and these NATs, packets contain private IPv4
addresses of customer sites.)

 The latter are those of draft-despres-v6ops-apbp-01, renamed here to
clarify their relationship with DSP-CGNs. (In ISP infrastructures, they
involve Public Address Servers, to which public IPv4 addresses can be
borrowed together with some limited ranges of ports. In IPv4/IPv6
tunnels between customer sites and these servers, packets contain public
IPv4 addresses that have been borrowed. If the CPE is a router, it
includes its NAT44; if it is a host, there is no NAT in the path.)
IMHO, if CGNs are deployed, NAT64 and NAT46 are no longer necessary, but I understand that this is a subject for debate. 


 This view is submitted as an exploratory contribution.



Regards.

Rémi