[153969] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

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

daemon@ATHENA.MIT.EDU (valdis.kletnieks@vt.edu)
Tue Jun 19 22:23:14 2012

To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: Your message of "Tue, 19 Jun 2012 22:21:11 +0900."
 <4FE07CC7.5040401@necom830.hpcl.titech.ac.jp>
From: valdis.kletnieks@vt.edu
Date: Tue, 19 Jun 2012 22:22:02 -0400
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

--==_Exmh_1340158922_1955P
Content-Type: text/plain; charset=us-ascii

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?

--==_Exmh_1340158922_1955P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iQIVAwUBT+EzyQdmEQWDXROgAQJffA//fXCyuNxJqUfQ5TCH9GiOi0HmkyRaUMoQ
ZobrXHhIh1X1zJO461wpP7HXKunNgBDCkc0eWoIuWrDv2Q0UaycAeNwVIFtJaXbQ
5NXGQL+rcRF7sLqq/YlTDGjxNg5oe1Fr61IVASURTqwM79vmgGRLsUHDedlDMaLc
NvKm5bDXD2/rmuigRTJfTkBVS/zAAVvR8YCqWRPOIP/QvzeqLEflxw3Ba0qBip0L
BK1+6VE/PGGKIl22UR/SA7WxL+vqwgV1IchHhAjnjzS5JD/obMpisJxSGfnC1Xtz
RzBVStjnxeVUNhD+T6ereB+AC+dsX4azTufTBIYXNJqU4OwMLa44l8voxzpeXQWw
0kHBuPhJdu8J6noFfjU8tvdnqsFREjYHdtpKH7Sl4p6zAh6n1SkMTAA5DV23TbDS
WdWjlz1k9U4+bSx07to1ZftwsADVhO3BRsEMvFjAW9fe/Efoj3/OsohrftlD75db
Gswugw0Gygx7ofhbrbAUpmuEkz/unUSmhzK3DzcFBDD3MmRBg+Eb/mIO+zeoXb/T
jC8XVoP7kO1ZBHWIQnKwlPdD171TYPxkSF2BdvNIuHpU/UGenD0+CAnSPLCAnKO6
RbrnZaFrTjc+O8o9xxfpVvLBw7IozbDPRqGRF2EG0wNI+MSgoOpZfOgC83nDuW8U
jcMBUGbwa2M=
=uYtj
-----END PGP SIGNATURE-----

--==_Exmh_1340158922_1955P--



home help back first fref pref prev next nref lref last post