Subject: [BEHAVE] comments on draft-mrw-behave-nat66-01.txt

From: Keith Moore <[email-masked]>
Date: Mon, 17 Nov 2008 22:04:22 -0600

First off the bat, I absolutely think it's worth trying to document what
optimal behavior of a NAT66 device would look like, and documenting the
advantages and disadvantages of such a device.  In my mind, the main
benefits of such a document would be that (a) it would facilitate
discussion of just how good (or bad) a NAT66 could be and (b) it would
provide a common reference model for discussions of NAT66, so that
people could compare proposals or implementations by stating where those
  proposals or implementations deviated from the reference model.

However I don't think a good case has yet been made for standardizing
NAT66, nor does this document purport to be a description of existing
practice.  For that reason, it bugs me a bit that this document reads
like a prescriptive protocol specification in places.  To my mind this
dilutes the potential value of the document, rather than enhancing it.
I think it would be better for the document to talk about design choices
and the implications of those choices, than for the document to dictate
choices.

The document seems to indicate two primary benefits of NAT66 - topology
hiding and prefix independence.  I agree that there is a benefit (at
least a small one) in topology hiding.  But as for prefix independence,
I don't see how NAT66 actually improves the situation, and I think NAT66
actually makes things worse for applications.  ULAs already exist
(indeed NAT66 uses them) and any network is free to advertise ULA
prefixes to its hosts.  The difference between a network advertising
ULAs with no NAT66, and one that advertises ULAs with NAT66, is that the
latter network can try advertising only its ULA prefix within its
network.  The problem is that this breaks applications that need to do
referrals to peers that are elsewhere in the network.

What we've seen in the NATted IPv4 world is that apps need to be able to
know their external (global) addresses, and they also need to be able to
use those external (global) addresses even from within the local
network.  That way, the app can use the external (global) address for
referrals without worrying about whether the peers using the referral
addresses are also in the local addressing realm.  The same would be
true for applications in a NATted IPv6 world.

It appears that there's a fundamental choice to be made in IPv6 if you
want to use ULAs.  Either you NAT at the border and break apps that do
referrals, or you advertise both ULA and global prefixes to your local
apps and force apps to choose which prefix to use in which
circumstances.   Neither seems particularly attractive.  The latter is
more flexible but also more configuration intensive/sensitive. For
instance, if an app needs to do a referral, should it use the
(presumably less stable) global address, or the (presumably more stable)
ULA which (probably) won't work for an outside host?  The right answer
depends on the scope in which the app will be used in that instance, and
usually the app doesn't have any way of knowing whether it will be
expected to operate outside the portion of the network in which the ULA
is routable.

So as far as I can tell, the benefit of NAT66 is limited to topology
hiding, and that benefit appears to me to be marginal.  But I'm also
sure that there are corner cases - nets that support a very specific set
of applications, where topology hiding is deemed useful and yet there is
no need to do referrals to peers to which the ULAs aren't routeable.

So perhaps a case could eventually be made for NAT66 but with limited
applicability.  And I think a useful outcome of this discussion could be
to determine the applicability of NAT66.

One more thing:

I've become convinced that one of the biggest problems with NATs in
general stem from original assumptions that applications didn't need to
be aware of them or to control their bindings, and that somehow ALGs
could magically compensate for the apps not knowing their endpoint
addresses.  What we've seen is that apps do need to (be able to) be
aware of them, and to explicitly control them, and to use their external
addresses - which is why there are now various mechanisms (and hacks)
defined for doing these things in the v4 world.

Granted that NAT66 doesn't have all of the problems of NAT44 - not
having to deal with anonymous addressing realms with overlapping space
helps a lot.  But the need to be aware of bindings, to establish
bindings and maintain them, to be aware of external addresses and use
them from within the "local" side of the NAT - all of these are equally
present in v6.  So any actual NAT66 proposal (as opposed to just a
reference model) ought to make explicit provision for these, and avoid
the need for hacks and heuristics and external servers that we've seen
in IPv4.

Keith

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Nov 2008 09:23:11 +1300

Keith,

> hiding, and that benefit appears to me to be marginal.

That is marginal (indeed as a security-by-obscurity benefit, it seems
bogus to me, but there are apparently people who believe in it).

However, sad to say there is another benefit: scaleable BGP4-based
multihoming. (Slide 15 in http://www.cs.auckland.ac.nz/~brian/RRG0508.pdf
yet again.) This pains me...

   Brian

---

From: james woodyatt <[email-masked]>
Date: Thu, 20 Nov 2008 14:51:14 -0600

On Nov 18, 2008, at 14:23, Brian E Carpenter wrote:
> [Keith Moore writes:]

There are also people who think the physical shape of the ubiquitous  
banana cultivar is proof of the action of an intelligent designer in  
the origins of life and the descent of humanity, but I'm still waiting  
for *them*, too, to produce any actual science to back their claims.

> yet again.) This pains me...

I take exception to the unqualified description of this as a  
"benefit," when "trade" is probably the more appropriate word to use.   
When viewed as a trade-off between end-to-end addressability and  
default-free-zone scalability, I have little trouble making the choice  
in favor of the former instead of the latter.

As your own presentation above notes: we already have a plan for  
achieving DFZ scalability without sacrificing E2E addressability, and  
it's a plan that has No Obvious Technical Defects.  It seems to me  
that, if we're going to pitch this plan out the window for one that  
*does* have obvious technical defects, and which nevertheless seems  
less likely to meet with operational resistance (though, that's not at  
all clear either), then we ought to make sure we have *explicit* IAB  
approval to do that.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering