Make sense. The authors will discuss this and send the response back to the working group.
On 2/23/11 11:29 AM, "Mark Townsley" <[email protected]> wrote: > >I'd like to see all softwire documents be as silent as possible on >specifics of NAT. The essential delta in ds-lite vs. a NAT44 CGN is that >the tunnel is embedded within the NAT binding. I think the softwire >documents should explain this, then point to behave for anything else >that has to do with operating a CGN. We are the tunneling folks here, the >translation folks are down the corridor. > >- Mark > > >On Feb 23, 2011, at 5:19 PM, Dan Wing wrote: > >> http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-06 says: >> >> 8.3. Application Level Gateways (ALG) >> >> The AFTR should only perform a minimum number of ALG for the classic >> applications such as FTP, RTSP/RTP, IPsec and PPTP VPN pass-through >> and enable the users to use their own ALG on statically or >> dynamically reserved ports instead. >> >> Comments: >> >> * To my knowledge, this would be the first time IETF suggests using an >>ALG >> in a NAT44 in a standards-track document. >> >> * Both IPsec and PPTP are protocols, not applications. IPsec is 50 >> (assuming you mean IPsec ESP, which I'm sure is what was intended) and >>PPTP >> uses protocol 47 (GRE). Thus, these do not belong in the Application >>Level >> Gateway section. Rather, IPsec and PPTP should be moved to the previous >> section (NAT Conformance) which already mentions other protocols like >>TCP >> and ICMP. >> >> * There aren't specifications describing an ALG for FTP, RTSP, RTP, >>IPsec, >> or PPTP VPN. >> >> * What is "RTSP/RTP"? Is this trying to say "RTSP, when it is using >>RTP", >> or is it trying to say "RTSP and other uses of RTP". Text needs to be >> clarified. >> >> * IPsec Passthru is pretty common on residential NATs. However, in a >>CGN, >> IPsec Passthru is difficult when multiple users connect to the same VPN >> concentrator. When that concentrator re-keys a session, the incoming >>IPsec >> SPI changes and there is no simple way to determine which user should >> receive that packet. There are several workarounds to this problem, >> including just ignoring it. >> >> -d >> >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > >_______________________________________________ >Softwires mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
