RE: Last Call: draft-ietf-v6ops-natpt-to-historic (Reasons to Move NAT-PT to Historic Status) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: Steven M. Bellovin [mailto:smb@xxxxxxxxxxxxxxx] 

> More precisely, any protocol that uses secondary connections, 
> the parameters of which are carried in-band in a secured 
> connection, can't easily be NATted.  The most obvious example 
> is FTP.  4217 notes that it only works through NAT if the 
> client is aware of the NAT's existence, and that there are 
> serious security issues even so.

This is a design choice in the protocol, one that I would see as a layering violation. Application layer protocols should not be talking about IP addresses.

In IPSEC the issue is rather more architectural and it is not really possible to do a work around without fundamentally changing the principles behind the protocol.

IPSEC is a Network layer protocol so dealling in the IP addresses is not a layer violation.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]