Marcelo, On 2007-11-25 08:12, marcelo bagnulo braun wrote:
El 22/11/2007, a las 3:46, Brian E Carpenter escribió:I guess we're going to discuss this draft on only one list? This one?1. Introduction RFC 4966 published on July 2007 deprecates the NAT-PT tool, the mechanism defined by the IETF to enable communications between IPv4 only nodes with IPv6 only nodes, letting the dual-stack approach as the preferred mechanism to enable nodes to be able to communicate with v6 and v4 nodes. However, there are several reasons why the dual stack approach may not be adequate for a number of scenarios. For once, the dual-stack approach imposes the management of two networks in a site, the v6 one and the v4 one, increasing the costs of using IPv6.I think that's a very weak argument in the next few years. The vast majority of deployments will be dual stack routing - can you seriously imagine doing anything else? If you want to make this argument, it should surely be made only as a long term consideration.but if you hav to do v4, why would you even bother doing v6 at all? It is merely an additional cost
When an ISP can no longer assign IPv4 addresses to new customers, it will undoubtedly run v4 and v6 in coexistence to service old and new customers respectively. At that point it will certainly be running major services like email, http (proxy) and VoIP in dual stack mode - the question is how to deal with services that aren't naturally dual stacked.
but current nat traversal mechanisms enable some of these forms of communication even through nats, right?In addition, as IPv4 public address space is depleted, it will no longer possible to access to IPv4 public addresses, making dual stack nodes even less attractive.Well, if I was implementing a new service, I would work very hard to get a public IPv4 address for it, so I don't think this argument works for servers and services for many years to come. It clearly will apply to client systems much sooner. So I'd rather see the problem expressed as: New populations of clients (and p2p hosts) that have no public IPv4 address, but do have plentiful public IPv6 addresses, which need to contact legacy servers (and p2p hosts) that have a public IPv4 address (possibly NATted) but no IPv6 capability. I don't think that changes the technical scenario.3. Supported application behavior The general purpose of NAT64 type of mechanisms is to enable communication between a v4-only node and a v6-only node. However, there is wide range of type of communication, when considering how they handle the IP addresses.That's true. But are we really aiming to solve all the scenarios you describe? It seems to me that we probably can't, because in any case the only safe assumption is that the legacy IPv4 system is sitting behind a NAPT. And in any case, if we have a translator with one IPv4 address fronting for 1000 IPv6 hosts, we automatically inherit *all* the issues of NAPT, including dynamic port mapping and the need for application level gateways for any address-dependent applications.maybe the requirement should be that we support all the application behavours that are currently supported by v4 nat traversal techniques, (as oposed to just support the application behaviours supported by v4 nats)
Yes. It's another "first do no harm" requirement.
Brian
Therefore, is there any point in having any goals that go beyond "doing no more damage to connectivity than NAPT44 does today"? In any case I am sure that we will end up with NAPT64, not NAT64. Port mapping is inevitable. Brian