[Softwires] ALG section in draft-ietf-softwire-dual-stack-lite-06
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 Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] DS-Lite I-D progress (was RE: dual-stack-lite-06 - Too biased against static port sharing)
Dear Alain, Yiu, Is there any plan to update the DS-Lite draft to take into account the comments received so far and to make this document progress? Cheers, Med -Message d'origine- De : francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr] Envoyé : mercredi 18 août 2010 21:48 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : Rémi Després; Softwires; Ralph Droms Objet : Re: [Softwires] dual-stack-lite-06 - Too biased against static port sharing In your previous mail you wrote: We have raised this point during the last call which has been issued on version 03 of the draft and suggested to remove this section from the draft since it is not normative and also because this depends on the taste of each SP and their deployment context. A reference to http://tools.ietf.org/html/ draft-ietf-intarea-shared-addressing-issues-01#page-22 would be sufficient IMHO. Dynamic vs. Static and Port set vs. Individual ports discussion can be elaborated further in draft-intarea-shared-addressing-issues if required. = IMHO it is the best option (and to make the draft smaller is a good goal :-). Thanks francis.dup...@fdupont.fr IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] ALG section in draft-ietf-softwire-dual-stack-lite-06
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 Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] ALG section in draft-ietf-softwire-dual-stack-lite-06
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 towns...@cisco.com 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 Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
