Re: IPv6 /64 links (was Re: ipv6 book recommendations?)

[valdis.kletnieks () vt edu]

On Tue, 19 Jun 2012 22:21:11 +0900, Masataka Ohta said:

>    Or, a NAT gateway may receive packets to certain ports and behave as
>    an application gateway to end hosts, if request messages to the
>    server contains information, such as domain names, which is the case
>    with DNS, SMTP and HTTP, to demultiplex the request messages to end

For SMTP, you'll have already consumed the 3 packet handshake and the EHLO,
MAIL FROM, and at least one RCPT TO before you know which end host to
demultiplex to (and even then, you may not unless the end hosts are running a
DNS that advertises MX's with the NAT'ed IP in them).  At that point, you have
little choice but to then start up a conversation with the end host and relay
the EHLO/MAIL FROM/RCPT TO and hope to heck that the end host doesn't reply
differently to you than you did to the other end (in particular, you had to
respond to the EHLO with a list of extensions supported - if you said you
supported an extension that the end system doesn't actually have, you get to do
fixups on the fly as you continue the MITM).

And some things, like ssh or anything that uses OpenSSL, you'll have
a very hard time because you need to respond with the right certificate or
key, which you don't have.

>    hosts.  However, for an ISP operating the NAT gateway, it may be
>    easier to operate independent servers at default port for DNS, SMTP,
>    HTTP and other applications for their customers than operating
>    application relays.

So you're admitting that the NAT breaks things badly enough at the ISP
level that running a forwarding ALG is easier than actually making the
NAT work.

> > (HInt - we haven't solved that problem for NAT yet, it's one of the big
> > reasons that NAT breaks stuff)
>
> As you can see, there is no such problem.

You haven't actually *deployed* your solution in a production environment,
have you?

Attachment: _bin
Description: