RE: ocean: do not boil

["Hesham Soliman (EAB)" <hesham.soliman@era.ericsson.se>]

  > 
  > Please note that both solutions require IPv4 service at the 
  > translation
  > point, including at least one globally routable IPv4 address.
  > 
  > Once the network has been set-up, these two choices 
  > _should_ work the
  > same for IPv4 traffic sent outside the site.  However, there are a
  > few of key differences:
  > 
  >          - The IPv4 NAT solution supports the use of IPv4-only
  >                  services within the site, whereas NAT-PT only
  >                  supports IPv4 communication with the outside (there
  >                  is no internal IPv4 routing).
  > 
  >          - The NAT-PT solution does not require running a 
  > DHCP server
  >                  or assigning private IPv4 prefixes to 
  > internal networks.
  > 
  >          - The NAT-PT solution involves changes to DNS (either to
  >                  resolver on each host, or to the server), 
  > and the IPv4
  >                  NAT solution does not.
  > 
  > Are there some other technical advantages to the NAT-PT 
  > solution that I
  > am missing?
  > 

=> Are nodes inside the network capable of communicating
with each other using IPv4? I don't think that would
be possible.
Also, and if the different private address clouds are
not physically separated then we end up with
having overlapping IPv4 address spaces. This will mean
that operators need to use BGP-based MPLS vpns (eek), virtual
routers ...etc. which is definitely a disadvantage to
the v4 NAT solution.
This situation could happen if the operator starts 
with a large network or when they expand an existing 
network. Could be very messy.

The only way to go around that would be to assume that
_all_ hosts inside the network will have v6 enabled and 
can communicate using v6. I.e. no v4 only devices in the 
network. This is probably unrealistic, especially in a public
access network. 

  > How will hosts know that they are running in a NAT-PT environment,
  > and that they shouldn't send IPv4 traffic?  

=> This is part of the NAT-PT solution, whether you
use DNS ALG in the network or modify the client's
resolver this would work fine. It doesn't need 
to be a mapped address. If the DNS ALG is in the
network then it can be any IPv6 unicast prefix.
If the client's resolver is changed it can also be 
any prefix, but in this case it has to be a "well known"
prefix. A mapped prefix would work fine.

  > Who has explored this in detail, and what did you find?

=> Alain's draft addresses this. I've also explored 
an alternative that I presented in the DT. This involved
having a DNS ALG in the network. 
The advantage of Alain's altrnative is that it allows 
DNSSEC in the client's resolver (as opposed to being 
verfied in the operator's DNS). The advantage of having
the DNS ALG in the network is that we don't have to change
(or guarantee changing) resolvers in all clients. 

There are other pros and cons related to how equally
a load can be distributed between the translators but 
the DNSSEC was the most significant difference. 

I don't know if v4 NATs can be distributed for load 
sharing and I haven't looked into that, I'd be interested
in a pointer though if someone else studied it.

Hesham