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

[Rémi Després <[e-mail]>]

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