2012/3/27 Rémi Després despres.r...@laposte.net
Dear Maoke,
Thanks for clarifying what you meant.
I now understand that you were referring to applications that might
require IPv4 dialogue between one link apart nodes.
btw, conceptually i don't suggest to call them applications. actually
In your previous mail you wrote:
Here are some questions about the demo and SD-NAT.
1. As I see, the bindings of v6 and v4+ports are deterministic and
pre-configured on the AFTR. Will it be of great cost if they are installed
using NETCONF which is mentioned in one of
Hello Kevin and all,
I actually see current multiple solution proposal from different
angle. Regarding the changes you mentioned, MAP-T/E is also doing
that, e.g. added fragmentation header to survive DF bit; change ICMP
ID filed to carry the port information.
4rd-U doesn't beat MAP-series. I
In your previous mail you wrote:
This is an issue common to all stateless solutions, including deterministic
NAT with (anaycast) IPv4 address pool.
= +1!
In fact, it is an issue common to all solutions implying mandatory
filtering on transport fields (aka layer 4) including ports.
Regards
In your previous mail you wrote:
In this context, the important consideration is AFAIK that it is
completely acceptable to lose fragmented packets that, with bad
luck, happen to be routed via distinct BRs when there is a route
change. Frequent route changes would have many more severe
Le 2012-03-27 à 08:41, Maoke a écrit :
dear Remi,
sorry but i forgot the time difference this morning. thanks for the quick
response!
2012/3/27 Rémi Després despres.r...@laposte.net
Dear Maoke,
Thanks for clarifying what you meant.
I now understand that you were referring to
2012/3/27 Rémi Després despres.r...@laposte.net
Le 2012-03-27 à 08:41, Maoke a écrit :
dear Remi,
sorry but i forgot the time difference this morning. thanks for the quick
response!
2012/3/27 Rémi Després despres.r...@laposte.net
Dear Maoke,
Thanks for clarifying what you meant.
I
In your previous mail you wrote:
What was the use case for non-contigous port sets?
= cf draft-tsou-softwire-port-set-algorithms-analysis-01.txt
A good port set definition algorithm must be reversible, easy to
implement, and should be able to define non-continuous or random port
On 3/27/12 4:02 AM, Francis Dupont francis.dup...@fdupont.fr wrote:
In your previous mail you wrote:
What was the use case for non-contigous port sets?
= cf draft-tsou-softwire-port-set-algorithms-analysis-01.txt
A good port set definition algorithm must be reversible, easy to
2012/3/27 Rémi Després despres.r...@laposte.net
Le 2012-03-27 à 12:15, Maoke a écrit :
2012/3/27 Rémi Després despres.r...@laposte.net
Le 2012-03-27 à 08:41, Maoke a écrit :
dear Remi,
sorry but i forgot the time difference this morning. thanks for the quick
response!
2012/3/27
Le 2012-03-27 à 13:12, Maoke a écrit :
2012/3/27 Rémi Després despres.r...@laposte.net
With TTL transparency added, I don't see what would be missing, even with all
requirements you expressed.
well, it is still uncertain how 4rd-u will do this. it is uncertain if the
new ad hoc
Hi Francis,
A quick question: why is there a SD-CGN? Do you mean the second NAT at
AFTR used to reshape the out-of-range source port into the restricted port
range?
If so, IMHO it is stateful, not using an algorithm. And I think it
still doesn't solve the security issue.
Please
In your previous mail you wrote:
A quick question: why is there a SD-CGN? Do you mean the second NAT at
AFTR used to reshape the out-of-range source port into the restricted port
range?
= there must be a SD-CGN which:
- filter from SD-CPE to the Internet packets checking the SD-CPE
2012/3/27, Jiang Dong jiangdong...@gmail.com:
Hi Gang and all,
I think there are some points need to be considered between MAP series and
4rd-U.
4rd-U saids IPv4 headers can be reversibly mapped into IPv6 headers so that
4rd tunnel packets can be designed to be valid IPv6 packets in Section
On 3/26/12 8:54 PM, Satoru Matsushima satoru.matsush...@gmail.com
wrote:
As a member of the MAT DT, I am naturally biased in favor of what Xing,
Maoke and Ole said.
I also think that the chair's questions are not adequate. I don't think
that the questions should be which of document the wg
Hi Remi,
Thank you for having the informational meeting of 4rd-u. I can understand 4rd-u
very much.
As you mentioned during the informational meeting, 4rd-u defines the new type
of the translation between IPv4 and IPv6 instead of MAP-E/MAP-T. Also, this new
type of the translation has no
I do agree with Tetsuya-san's comments. On the other hand, I couldn't
understand the reason of why the CNP is needed. Since 4rd-u focus on support to
communicate between ipv4 hosts, L4 checksum consistency could be agnostic from
any kind of 4rd-u nodes. So then I suggest that remove checksum
2012/3/27 Rémi Després despres.r...@laposte.net
Le 2012-03-27 à 13:12, Maoke a écrit :
2012/3/27 Rémi Després despres.r...@laposte.net
With TTL transparency added, I don't see what would be missing, even with
all requirements you expressed.
well, it is still uncertain how 4rd-u will do
FYI, section 5 of RFC5082 (http://tools.ietf.org/html/rfc5082#section-5.2)
generalize a technique that TTL is used to help tunnel packets security.
Anyway,
On 2012/03/27, at 14:02, Rémi Després wrote:
Le 2012-03-27 à 13:12, Maoke a écrit :
2012/3/27 Rémi Després despres.r...@laposte.net
19 matches
Mail list logo
