-----Original Message-----
From: Rémi Després [mailto:remi(_dot_)despres(_at_)free(_dot_)fr]
Sent: Thursday, September 29, 2011 3:13 AM
To: Dan Wing
Cc: 'Softwires-wg'; 'Behave WG'; 'IETF discussion list'; 'Teemu
Savolainen'
Subject: Re: [BEHAVE] ... Dual Stack Hosts Using "Bump-in-the-Host"
(BIH))
Le 29 sept. 2011 à 23:50, Dan Wing a écrit :
-----Original Message-----
From: Rémi Després [mailto:remi(_dot_)despres(_at_)free(_dot_)fr]
Sent: Thursday, September 29, 2011 5:14 AM
To: Softwires-wg
Cc: Dan Wing; Teemu Savolainen; Satoru Matsushima; IETF discussion
list; Behave WG
Subject: Re: [BEHAVE] ... Dual Stack Hosts Using "Bump-in-the-Host"
(BIH))
Hi all,
Le 27 sept. 2011 à 21:10, Dan Wing a écrit :
-----Original Message-----
From: teemu(_dot_)savolainen(_at_)nokia(_dot_)com
[mailto:teemu(_dot_)savolainen(_at_)nokia(_dot_)com]
...
I mean does existing
applications work better if double translation is done in
deterministic
manner?
Yes, it allows the CPE to implement an ALG -- if an application
needs
an ALG (e.g., active-mode FTP).
+1
As Softwire is concerned, it is worth noting here that, with
encapsulation rather than double translation, NO ALG is ever needed.
(Neither in ISP Border Relay nodes, nor in CPEs, nor in BIH hosts).
Do a message flow for active mode FTP with 4rd.
Two cases (which I din't differentiate, sorry for that).
a) The hosts handles 4rd
b) The host is behind a NAT44 (
In case b), an ALG is needed as usual, as the CPE-NAT44 does its usual
job for that.
Case a) was assumed to apply to this discussion, considering a host
that is directly the 4rd CE.
I did one, and
it needs an ALG in the 4rd NAPT44 function.
In case a), the host can assign to an FTP application a pair of ports
of its assigned range.
Thus no translation is needed (e2e transparency).
OK?
If BIH worked that way, BIH would fail when the host has multiple
interfaces running, and those interfaces have different port
ranges.
-d
RD
-d
It is sometimes argued that double translation could be as simple
than
encapsulation.
AFAIK, this discussion clearly indicates the contrary.
(No ALGs eliminates any variants about where to put them.)
RD
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf