Subject: RE: myth of the great transition (was US Defense Department forma lly adopts IPv6)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Jun 2003 19:33:24 -0700

> On Tuesday, June 17, 2003, at 11:51  AM, Hallam-Baker, Phillip wrote:
> 
> > The key in my view is to work on the NAT vendors, instead 
> of viewing 
> > NAT
> > boxes as an obstacle they should be seen for what they 
> really are, an
> > essential and important part of the internet infrastructure.
> 
> you obviously don't write applications.

No, because I design and use applications I really wish that the IETF
had designed a decent NAT box spec rather than adopting the ostrich
position.

		Phill

---

From: [email-masked]
Date: Wed, 18 Jun 2003 00:45:44 -0400

> had designed a decent NAT box spec rather than adopting the ostrich

If my un-NAT'ed box does a LISTEN on some TCP port, that generates no
outbound traffic.  However, if a SYN packet arrives at my upstream router
for my IP address and that port, the router still knows how to deliver it.

If my same box running the same software does a LISTEN on a TCP port while
behind a NAT, it also generates no outbound traffic.  However, if a SYN
packet shows up at the NAT box with the NAT box's IP address and that port
number on it, the NAT box HAS NO CLUE who to deliver it to.

It's pretty easy to show that there is no *transparent* way to make both
cases work.  If you handwave some magical-pixie-dust packet that is sent
out that says "Hey NAT box, I'm doing a LISTEN on port NNNN", then you have
to deal with (a) scaling when lots of clients do this, (b) information leakage
security issues, and (c) what happens when the application is started in
a NON-NAT environment.  If you don't sprinkle pixie dust, then the NAT doesn't
know what to do without manual configuration...

All the while noting that it could very well be 3-4 hops or more across a
large enterprise network before you reach a NAT... or your large enterprise
network might be acquisition-legacy hell and a packet can traverse 5 NAT
boxes without leaving the corporate network.  And deciding what the proper
behavior of the corporate NAT to the Internet in Chicago should be when
an application in the San Fran and Zurich offices both open port 31337 is
left as an exercise for the reader.

More "gotchas" can be found in RFC3027.

Now, what were you saying about ostriches?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 18 Jun 2003 07:55:34 +0200

> had designed a decent NAT box spec rather than adopting the ostrich

Phil,

at the risk of feeding into a long-burning flamewar:
when you say "a decent NAT box spec", what do you think of?

As far as I can tell, a NAT box contains, over and above what it does 
because it's a router, a firewall or any other thing it might do:

- Address translation
- Application layer gatewaying
- Remote control of the NAT functionality (already being worked on in 
MIDCOM)

So what did you want a "decent NAT box spec" to say?

                Harald, genuinely curious

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 18 Jun 2003 09:11:46 +0200

On woensdag, jun 18, 2003, at 04:33 Europe/Amsterdam, Hallam-Baker, 
Phillip wrote:

> I really wish that the IETF had designed a decent NAT box spec rather 
> than adopting the ostrich position.

http://www.ietf.org/html.charters/nat-charter.html

---

From: Keith Moore <[email-masked]>
Date: Wed, 18 Jun 2003 12:42:53 -0400

> I really wish that the IETF
> had designed a decent NAT box spec

that's an oxymoron.  the basic premis of NAT is fundamnetally broken.

---

From: james woodyatt <[email-masked]>
Date: Wed, 18 Jun 2003 10:44:05 -0700

On Tuesday, Jun 17, 2003, at 22:55 US/Pacific, Harald Tveit Alvestrand 
> when you say "a decent NAT box spec", what do you think of?

Now, you've done it.

>                Harald, genuinely curious

I maintain the NAT code (among other things) in the firmware of a 
consumer Wi-Fi/router product.  I'm not sure I can think of anything 
the IETF needs to do here beyond what it has already done-- or is in 
the process of finishing up.

I think the spec that Mr. Hallam-Baker would like to see is likely to 
emerge from outside the IETF.  In fact, I predict that several 
competing de facto standards will emerge in the market, and eventually 
one of them may win out-- but I'm pessimistic about that.

When customers of retail Internet service start demanding a NAT 
standard, then that's when the IETF might want to think about 
documenting the standard that the market seems to want.  Not before, I 
think.

I see no evidence that such demand exists now, or that it's very likely 
to exist in the foreseeable future.  Piteous whines from applications 
developers complaining about the weird menagerie of NAT implementations 
do *NOT* constitute an indication of real demand from retail Internet 
service customers.

The IETF has already decided how to proceed with addressing the 
limitations in IPv4 that make the deployment of NAT devices an optimal 
strategy in some cases.  We've seen how successful the IETF has been in 
persuading users that a new protocol is superior because it comes 
stamped with the magick 'Draft Standard' label.  I doubt that providing 
such a magick stamp for NAT devices would be worth the effort if the 
market isn't interested in products that claim to be compliant with it.

-- 
j h woodyatt <[email-masked]>

---

From: Keith Moore <[email-masked]>
Date: Wed, 18 Jun 2003 15:51:48 -0400

> documenting the standard that the market seems to want.  

here's the only thing that a NAT standard should say:

an intermediary MUST NOT alter the source or destination field in an IP
header.

an intermediary MUST NOT route an IP packet to other than its intended
destination.

an intermediary MUST NOT alter the payload of an IP packet.

---

From: james woodyatt <[email-masked]>
Date: Thu, 19 Jun 2003 22:00:00 -0700

On Wednesday, Jun 18, 2003, at 12:51 US/Pacific, Keith Moore wrote:
> [I wrote:]

I don't dispute this.  However, I will observe that customers of retail 
Internet service seem to rarely have much interest in whether their 
network intermediaries comply with this proposition.

And, your list is incomplete.  The NAT code I maintain does all of the 
things above that your proposal would explicitly forbid-- but it does a 
few other nasty things as well.  For example, 1) it *should* be 
rewriting IP datagram identifiers (but I haven't coded it yet), and 2) 
it hides path-MTU discovery black-holes by rewriting TCP MSS fields.

Basically, once you've committed to rewriting the forwarding 
information in an IP datagram, then it's open season on all manner of 
horrible opportunities for intermediaries to engage in Internet abuse.

You want to know what made my blood run cold in the latest release of 
the product's firmware?  I had to change it so that it would propose an 
impossible MRU in a PPPoE LCP negotiation.  Apparently, a lot of PPPoE 
implementations are happily proposing an MRU of 1500 octets, because 
there are a lot of PPPoE servers out there that will refuse to 
negotiate down to the more realistic value of 1492.  Consequently, when 
the product doesn't connect to a buggy PPPoE server, and every other 
product people try seems to work fine (as long as you don't stress test 
it), the customer blames the firmware that actually complies with the 
actual standard for refusing to work the way everyone else's 
non-compliant system works.

So yeah-- I'm very excited about the prospects of the IETF proposing 
standards.  I'm even more excited when they're standards that customers 
regard as actually valuable parts of their lifestyles.  I have yet to 
see a proposal for a NAT box spec that would seem like a valuable 
addition to the RFC library.  Including yours, Keith... no disrespect 
intended, honest.

-- 
j h woodyatt <[email-masked]>
stop me before i rewrite your IP header again.