citation.
- maoke
2013/8/13 mohamed.boucad...@orange.com
Hi Satoru,
** **
Provisioning-related discussion should be included in the unified CPE not
in each individual document. This is true for MAP, lw4o6, etc.
Ensuring a coherency among ongoing specification documents
stand on itself rather than
depending upon any specific implementation.
if the citation is DEFINITELY needed for any non-technical reason, the
above explanation on the understanding must also be included in order to
avoid any misleading or restrictions on extensive usage.
cheers,
- maoke
2013/8
dear Tom,
thanks a lot for the comments. sorry for the delay though.
now maoke is replying in line regarding the section 5.
2013/5/16 Tom Taylor tom.taylor.s...@gmail.com
I have a number of trivial editorial comments, which I will share
privately with the authors. However, I also have a few
on the
understanding.
cheers,
maoke
2013/2/25 internet-dra...@ietf.org
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Softwires Working Group of the IETF.
Title : Mapping of Address and Port (MAP) - Deployment
to deploy such an MAP
overlay but the MAP supporting 1:1 mode is anyway a needed building block.
- maoke
Cheers,
Rajiv
-Original Message-
From: mohamed.boucad...@orange.com mohamed.boucad...@orange.com
Date: Thursday, February 14, 2013 5:55 AM
To: Ole Troan o...@cisco.com
Cc: Softwires
hi Ian,
2013/2/8 ian.far...@telekom.de
HI Maoke,
Comments in line.
Cheers,
Ian
Deutsche Telekom AG
Group Technology
Ian Farrer
IP Engineering
Landgrabenweg 151, 53227 Bonn, Germany
+49 228 93638046 (Phone)
+49 170 4557418 (Mobile)
E-Mail: ian.far...@telekom.dewww.telekom.com
2013/2/5 ian.far...@telekom.de
Hi Maoke,
Thanks for your response. Comments inline.
Cheers,
Ian
From: Maoke fib...@gmail.com
Date: Tuesday, 5 February 2013 06:54
To: Suresh Krishnan suresh.krish...@ericsson.com
Cc: Softwires WG softwires@ietf.org, Yong Cui cuiy...@tsinghua.edu.cn
.
- maoke
do we know that end users only need ports 0-1023 or 0-4095?
or are the ports the require to be opened inbound across the range?
I'm leaning towards a.
cheers,
Ole
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman
2013/1/29 Qi Sun sunqi.csnet@gmail.com
Woj ,
the IPv4 and PSID in the IID are particularly useful in cases of address
independence (ie 1:1).
Now that IPv4 and PSID is put in the IPv6 address, why is it a case of
address independence?
IPv4-address independent MAP rule .. ;-) - maoke
2013/1/29 Maoke fib...@gmail.com
2013/1/29 Qi Sun sunqi.csnet@gmail.com
Woj ,
the IPv4 and PSID in the IID are particularly useful in cases of address
independence (ie 1:1).
Now that IPv4 and PSID is put in the IPv6 address, why is it a case of
address independence?
IPv4
Prefixes cannot be overlapped among BMRs. this is necessary and
sufficient.
if i made mistakes, please point out without hesitation. thanks a lot!
- maoke
[Senthil] No, atleast in our implementation we have checks to make sure
the prefixes don’t overlap.
Thanks
Senthil
dear Med,
thanks for the response. please see inline.
2012/11/30 mohamed.boucad...@orange.com
**
Dear Maoke,
Thank you for the review and comments.
Please see inline.
Cheers,
Med
--
*De :* Maoke [mailto:fib...@gmail.com]
*Envoyé :* vendredi 30 novembre
-specific?
3. related to 2, how can we keep the CPE/BR CPE/AFTR consistency?
4. fragmentation issue is common to all modes and it is also needed to be
clarified/unified for the unified CPE.
only my 2 cents, identifying the problems that i expect this draft to
cover.
- maoke
2012/11/29 Suresh
dear chairs,
i confirm i am in favour of both.
- maoke
2012/9/25 Suresh Krishnan suresh.krish...@ericsson.com
Hi all,
During the softwire WG meeting at IETF84 a series of questions* to
determine the preferred solution in the meeting room indicated that the
sense of the room was in favor
of the WG. but
if you would like to discuss about the significance, motivation, and use
cases of translation/double-translation, you are welcome to mail me
offline. thanks!
- maoke
What's your unique network architecture compared with others, can you
show us your concrete network architecture
i share the same view with Remi. and ACL is not the only reason that MAP-T
is needed. - maoke
2012/9/7 Rémi Després despres.r...@laposte.net
Gang,
I think you are on a wrong track here.
1. In Vancouver it was decided that MAP-E would be standard track, and
both MAP-T and 4rd experimental
an operator
side on this point. Therefore, I don't see any needs publishing MAP-T
as a WG draft.
unfortunately, however, your understanding, IMHO, is not fairly correct. on
the other hand, my company has had a very concrete use-case where MAP-T is
needed. - maoke
In order to not disturb
. there is no need to limit MAP's scope with
focusing on mesh.
in a service architecture that i am designing for one of my company's
product, i have had the very concrete requirement on both mesh and
hubspokes.
- maoke
Best Regards,
Leaf
-Original Message-
From: softwires-boun...@ietf.org
the same MAP
algorithm for both MAP-E and MAP-T, and making them inter-operable.
- maoke
2012/8/8 Suresh Krishnan suresh.krish...@ericsson.com
Hi all,
During the softwire WG meeting at IETF84 a series of questions* to
determine the preferred solution in the meeting room indicated that the
sense
been already sketched in Figure 7 of RFC6346
(see http://tools.ietf.org/html/rfc6346#section-3.3.4).
yes. i share this point. thanks, Med, for the clear explanation on the big
picture. - maoke
Having standalone specifications for each of these flavours helps
operators to better target
hi Woj,
let me truncate the old text that makes this message too long. focusing on
the recent replies.
2012/7/19 Wojciech Dec wdec.i...@gmail.com
Hello Maoke,
okay, if your MAP algorithm refers to the GMA, it is fine to state GMA
is usable to address/port-set assignment and/or stateless
the result would
be, i don't see any problem of dealing that in the framework of a WG
document.
hope you may consider over this again. thanks!
- maoke
As such, I find it premature to move it to WG-draft status.
If 4rd is chosen for standardization, adapting this deployment draft to it
looks
in this version, if we don't receive objections on the above
changes, we plan to re-submit this -02 version as the WG draft,
draft-ietf-softwire-map-deployment-00, by July 1st.
thanks and regards,
maoke
-- Forwarded message --
From: internet-dra...@ietf.org
Date: 2012/6/29
Subject
2012/6/28 Leaf yeh leaf.y@huawei.com
Maoke - i fully agree with you as zero-lengthed EA-bits is a naturally
possible case of MAP. however, to my understanding, even in this case the
Figure 7 of MAP addressing architecture is still appliable and therefore it
implies PSID length also equals
hi Woj,
thanks a lot for the clarification.
2012/6/27 Wojciech Dec wdec.i...@gmail.com
Hi Maoke,
inline...
On 27 June 2012 05:28, Maoke fib...@gmail.com wrote:
hi dear authors,
as the map-00 draft contains the normative 1:1 mode statement that is new
in comparison to the previous
hi Woj,
thanks but it looks you didn't answer my questions somewhere maybe because
my questions were not clearly expressed. ;-) inline..
2012/6/27 Wojciech Dec wdec.i...@gmail.com
Hello Maoke,
inline...
On 27 June 2012 12:55, Maoke fib...@gmail.com wrote:
hi Woj,
thanks a lot
of
stateless, WITHOUT the exclusiveness against other solutions, more
specifically suitable for a certain use case.
cheers,
maoke
cheers,
--satoru
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
the current draft as working group
result. i also hope the MAP spec authors kindly understand with so many
uncertainty modifying MAP deployment draft to fit the MAP spec is a
mission-impossible for the time being.
thanks and regards,
maoke
___
Softwires mailing
. and updating the draft with referring to the
specs is definitely the most important task but the first-priority task of
us is clarifying the semantics and impacts of the specs itself.
thanks and regards,
maoke
Regards,
Woj.
On 26 June 2012 08:24, Maoke fib...@gmail.com wrote:
hi all,
we have
within a monolithic implementation. we
support the lightweight 4over6 as an independent standard.
thanks and regards,
maoke
2012/6/25 Satoru Matsushima satoru.matsush...@gmail.com
Hi Qiong,
Thanks you to carefully express your thought. I understand that.
First point, let me answer
2012/6/4 Rémi Després despres.r...@laposte.net
Maoke,
Please see comments inline.
2012-06-04 04:35, Maoke:
sorry for the late reply.
2012/5/23 Simon Perreault simon.perrea...@viagenie.ca
(Did you intend to send this to the WG?)
thanks for reminding :) i did reply but not reply-all
sorry for the late reply.
2012/5/23 Simon Perreault simon.perrea...@viagenie.ca
(Did you intend to send this to the WG?)
thanks for reminding :) i did reply but not reply-all.
On 2012-05-22 21:38, Maoke wrote:
My understanding: 4rd is a compromise.
What you gain: only one
2012/5/23 Maoke fib...@gmail.com
eBGP multihop applies non-1 non-255 values for the hop-limited security of
the sessions. both Cisco and Juniper has this well-known functionality.
iptables can be set with ttl module to restrict only packets with ttl
higher than or less than or equal
+1 xxx ms xxx ms xxx ms C (IPv6-domain hops are counted)
don't you think it is strange? the above behavior is neither
encapsulation nor translation, then can we call it as a unification?
thanks a lot for your attention,
- maoke
2012/5/21 internet-dra...@ietf.org
A New Internet-Draft
!= they are not
mature at *same* level.
3. call for reviewer, just like the previously call for poll, sounds to
me another political trick of the chair. logically, independent vs. we
will designate are contradictory. if the majority poll failed to indicate
consensus, how the minority reviews can?
- maoke
2012
hi Remi,
this acknowledges the part not belonging to technical issues.
2012/4/11 Rémi Després despres.r...@laposte.net
Maoke,
Good to see that at least one who has read the 4rd-u draft still considers
that technical considerations are worth working on.
sorry if you mean the at least one
. how could CNP protect these?
thanks for mentioning CNP here. i need to modify the concern for address
integrity to the concern for integrity of addresses, packet length and
payload protocol type.
- maoke
___
Softwires mailing list
Softwires@ietf.org
2012/4/12 Rémi Després despres.r...@laposte.net
Le 2012-04-11 à 15:44, Maoke a écrit :
postpone other parts, but focus on the checksum issue.
2012/4/11 Rémi Després despres.r...@laposte.net
5.4 Impact c. - it is true that, in the IPv6 packet of a tunneled ICMPv4
message, the ICMPv4
2012/4/12 Behcet Sarikaya sarikaya2...@gmail.com
On Tue, Apr 10, 2012 at 11:28 PM, Maoke fib...@gmail.com wrote:
hi Behcet,
2012/4/10 Tina TSOU tina.tsou.zout...@huawei.com
Sent from my iPad
On Apr 10, 2012, at 10:12 AM, Behcet Sarikaya sarikaya2...@gmail.com
wrote:
Hi
2012/4/12 Behcet Sarikaya sarikaya2...@gmail.com
On Tue, Apr 10, 2012 at 10:29 PM, Maoke fib...@gmail.com wrote:
hi Yiu,
sorry but i just found i missed a technical issue you left in this
message.
2012/4/9 Lee, Yiu yiu_...@cable.comcast.com
on the other hand, 4rd-u makes
refer to 4rd-u
only. i respect this way of calling but avoid to make any confusion by
myself.
hope it clarifies.
- maoke
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
hi all,
i made an internet-draft discussing the semantics issue of 4rd-U. comments,
recommendations, technical discussions are welcome.
http://tools.ietf.org/html/draft-chen-softwire-4rd-u-comment-00
thanks and regards,
maoke
-- Forwarded message --
From: internet-dra
2012/4/9 Rémi Després despres.r...@laposte.net
2012-04-09 11:52, Maoke:
2012/4/9 Sheng Jiang jiangsh...@huawei.com
Without any objection to MAP, we just start to coding 4rd-u and help to
improve it.
fine. we'd love to see it out with good amount of data and good amount of
feedback
of bindings, not interchangable
for other brands ;-) however, in most of time, we really think
interchangability, supported by loose coupling, is preferred.
cheers,
maoke
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo
hi Behcet,
2012/4/10 Tina TSOU tina.tsou.zout...@huawei.com
Sent from my iPad
On Apr 10, 2012, at 10:12 AM, Behcet Sarikaya sarikaya2...@gmail.com
wrote:
Hi Maoke,
Thank you for your efforts in technical details of one specific
proposal on the table.
However, I for one think
designers are so confident, why
not do the real coding work first and then propose it as a replacement of
MAP suite? i don't see any unfairness here. - maoke
Best regards,
Sheng
*From:* Maoke [mailto:fib...@gmail.com]
*Sent:* Monday, April 09, 2012 3:24 PM
*To:* Sheng Jiang
*Cc:* Lee
of standardization
of MAP, because the result of 4rd-u is still unsure. - maoke
I’d love to see operators find proper mechanisms respectively according to
their own situations, rather than some mechanisms **out**.
joke. operators haven't know what the 4rd-u is. operators never make
selection
and/or protocol
improvement.
sincerely,
maoke
2012/4/9 Alain Durand adur...@juniper.net
Makoe,
The usage of disparaging language does not benefit the clarity of the
discussion.
I understand that english may or may not be your primary language, nor is
it for the majority of the wg members
publish both as
standard track.
Answering NO to this question means you want to see both advance on the
standard track.
Maoke CHEN, FreeBit, choice: YES
considered as IETF
contribution.
do you think your statement on no identified flaws left, ignoring the
fact that competent contributors keep arguing, is not an attempt at biasing
people's understanding in the venue?
- maoke
Thanks,
RD
___
Softwires
shows there is no rough
consensus. but logically i do agree with Ralph, that it was hard to
conclude the rough consensus through the numbers. voting is surely never an
unbiased estimation method for the consensus. ;-)
regards,
maoke
2012/4/4 Tom Taylor tom.taylor.s...@gmail.com
I have been advised
playing the
vote but without the game rule for the vote.
vote is a way of reaching a certain result. if we don't like to make
endless voting circles, let's follow the rule of voting: majority wins.
cheers,
maoke
Cheers, Jan
___
Softwires mailing list
2012/4/4 Rémi Després despres.r...@laposte.net
Le 2012-04-04 à 08:04, Maoke a écrit :
dear Remi,
2012/4/2 Rémi Després despres.r...@laposte.net
Hi, Congxiao,
During the Softwire meeting, you came to the mike to assert that the
4rd-U specification was known to have flaws.
Yet, you do
not enough to provide an
informational guideline for people who would like to deploy it.
thanks,
maoke
2012/4/3 Reinaldo Penno repe...@cisco.com
Hello,
I was not part of the design team and maybe my question was already
answered in some design team ML.
Is there a document describing where
. otherwise, the market would see IETF more
of a group of doc-makers rather than technology-explorers.
- maoke
- we reject kings, presidents, and voting...
- Rex redivit. vive le Roi.
2012/4/3 Marc Blanchet marc.blanc...@viagenie.ca
well, let's see the other way around: what is the problem
) the chair's questions, esp. Q2,
with I don't think it is correct now to insert 4rd-u into a sort of
exclusive decision of choice.
regards,
maoke
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
2012/4/2 Rémi Després despres.r...@laposte.net
it is flawed in both architecture and technical aspects,
Which ones?
please refer to discussion mails and also my real-time comments on 4rd-u
presentation in the jabber room as a brief summary focusing on major
points. - maoke
of identified
objections.
Fair enough?
i din't say what if the BoF is not started but only said about what if the
BoF would started. ;-)
best,
maoke
Cheers,
RD
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
2012/4/2 Rémi Després despres.r...@laposte.net
2012-04-02 11:45, Maoke:
...
i am still in review on the version -06, but i have found something not
qualified (inconsistent semantics).
Asserting there are flaws implies ability to describe them.
What you have already found will be looked
done, before
talking on any doc-track issue with the community. this is the way of being
responsible.
thanks,
maoke
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
CHANGES the semantics of IPv6's HopLimit!
regards,
maoke
If I missed something, please don't get crossed, your additional
explanations will be welcome.
Regards,
RD
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo
conservative. - M
--
*From:* softwires-boun...@ietf.org javascript:_e({}, 'cvml',
'softwires-boun...@ietf.org'); [softwires-boun...@ietf.orgjavascript:_e({},
'cvml', 'softwires-boun...@ietf.org');]
on behalf of Maoke [fib...@gmail.com javascript:_e({}, 'cvml',
'fib
2012/3/28 Maoke fib...@gmail.com
*1. consider a case where 2 CEs, 1 hop apart in IPv6 domain, establish
EBGP session over IPv6 with their 4rd addresses as the loopback addresses
and ttl-security is set to, e.g., 254, in order to protect the peer from
receiving attack messages sending
take some time to get to understand the ICMPv6/iCMPv4 translation
semantics. they are different for -E and -T.
thanks,
maoke
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
Després wrote:
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
protocols, and you still can't handle future protocols that people might
develop.
misunderstanding on ICMP.
1. ICMP is not transport protocol.
2. ICMP cannot benefit from CNP at all because ICMPv4 checksum doesn't
cover the pseudo-header while ICMPv6 does.
just FYI.
- maoke
Checksum
as better as we can.
requiring others offering anything into our standard is really an easy
life. but it is, a sort of, selfish.
thanks,
maoke
Simon
--
DTN made easy, lean, and smart -- http://postellation.viagenie.ca
NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca
STUN/TURN
2012/3/28 Maoke fib...@gmail.com
2012/3/28 Simon Perreault simon.perrea...@viagenie.ca
On 03/28/12 10:48, Satoru Matsushima wrote:
On the contrary, there is a big difference. The difference is that you
are only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc,
etc, etc
2012/3/28 Rémi Després despres.r...@laposte.net
Le 2012-03-28 à 11:30, Maoke a écrit :
2012/3/28 Rémi Després despres.r...@laposte.net
Le 2012-03-28 à 06:10, Satoru Matsushima a écrit :
FYI, section 5 of RFC5082 (
http://tools.ietf.org/html/rfc5082#section-5.2) generalize a technique
2012/3/28 Simon Perreault simon.perrea...@viagenie.ca
On 03/28/12 12:50, Maoke wrote:
Yup. RFC 6052 section 4.
do you mean the following paragraph:
No. See my response to Ole.
1. as a stateless address mapping, RFC6052 doesn't assumes any stateful
NAT64 is also required to use
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
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
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
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
dear Remi,
i know you are very busy in Paris, but please respond to this thread.
again, if i made anything wrong, please don't hesitate to point out.
thanks!
best,
maoke
2012/3/26 Maoke fib...@gmail.com
dear Remi,
i think you won't be against if i change the subject of this specific
i wonder if remote participation (skype, jabber room, etc.) is available or
not. - maoke
2012/3/26 Rémi Després despres.r...@laposte.net
Hi, all,
With some co-authors of the 4rd-U proposal, we will hold an informal
meeting about it.
- subject: Clarification on what 4rd-U is designed to do
of the new features in the address format, and the
approval of the reversible header mapping tightly coupled with the address
format.
- maoke
Note that several co-authors of the U proposal have been MAP contributors.
- For this, community acceptance to listen to explanations, would
2012/3/20 Rémi Després despres.r...@laposte.net
Le 2012-03-19 à 16:12, Maoke a écrit :
2012/3/20 Rémi Després despres.r...@laposte.net
Le 2012-03-19 à 15:30, Maoke a écrit :
2012/3/19 Rémi Després despres.r...@laposte.net
Le 2012-03-19 à 11:38, Maoke a écrit :
...
let me draw
dear Remi,
2012/3/24 Rémi Després despres.r...@laposte.net
Le 2012-03-22 à 15:40, Maoke a écrit :
dear Alain, Yong, Ralph and all,
in program, the effort of the MAP team should be respected. The formation
of the MAP team was also the consensus of our meeting in beijing and we
have seen
2012/3/16 Rémi Després despres.r...@laposte.net
Maoke,
Let me try a more complete picture than before:
A1 -.
RFC6145-host| .-- 4rd BR --.
| ||
A2 -:--(v6net)--::--(v4 Internet)--- B
4rd-CE
2012/3/19 Rémi Després despres.r...@laposte.net
Le 2012-03-19 à 09:16, Maoke a écrit :
2012/3/16 Rémi Després despres.r...@laposte.net
Maoke,
Let me try a more complete picture than before:
A1 -.
RFC6145-host| .-- 4rd BR
2012/3/19 Rémi Després despres.r...@laposte.net
Le 2012-03-19 à 06:19, Maoke a écrit :
Remi,
please see inline.
2012/3/16 Rémi Després despres.r...@laposte.net
Maoke,
First:
- My apologies for having not answered this email before receiving a
reminder (it was by mistake lost
2012/3/19 Rémi Després despres.r...@laposte.net
Le 2012-03-19 à 10:21, Maoke a écrit :
2012/3/19 Rémi Després despres.r...@laposte.net
Le 2012-03-19 à 09:16, Maoke a écrit :
2012/3/16 Rémi Després despres.r...@laposte.net
Maoke,
Let me try a more complete picture than before
2012/3/19 Rémi Després despres.r...@laposte.net
Le 2012-03-19 à 11:38, Maoke a écrit :
...
let me draw an example for that:
A --- CE (IPv6 domain; router R1 here) BR (IPv4 Internet;
router R2 here)--- B
...
4rd-u isn't concerned with what happens between A and CE
2012/3/20 Rémi Després despres.r...@laposte.net
Le 2012-03-19 à 15:30, Maoke a écrit :
2012/3/19 Rémi Després despres.r...@laposte.net
Le 2012-03-19 à 11:38, Maoke a écrit :
...
let me draw an example for that:
A --- CE (IPv6 domain; router R1 here) BR (IPv4 Internet
2012/3/20 Rémi Després despres.r...@laposte.net
Le 2012-03-19 à 15:30, Maoke a écrit :
2012/3/19 Rémi Després despres.r...@laposte.net
Le 2012-03-19 à 11:38, Maoke a écrit :
...
let me draw an example for that:
A --- CE (IPv6 domain; router R1 here) BR (IPv4 Internet
Remi,
please see inline.
2012/3/16 Rémi Després despres.r...@laposte.net
Maoke,
First:
- My apologies for having not answered this email before receiving a
reminder (it was by mistake lost in a stack of non-urgent things to do).
- Thanks for the clear and detailed analysis.
More
2012/3/16 Rémi Després despres.r...@laposte.net
Maoke,
In a forthcoming answer to another of you emails, on thread 4rd-u tunnels
and stateful NAT64s, I will try to describe more completely what the
latest 4rd brings in the stateful NAT64 context.
Le 2012-03-16 à 01:27, Maoke a écrit
2012/3/15 Rémi Després despres.r...@laposte.net
Le 2012-03-15 à 10:22, Maoke a écrit :
2012/3/15 Rémi Després despres.r...@laposte.net
Le 2012-03-15 à 10:02, Maoke a écrit :
2012/3/15 Rémi Després remi.desp...@free.fr
Maoke,
Let's try, once more, to understand each other.
If we
2012/3/15 Rémi Després despres.r...@laposte.net
Le 2012-03-15 à 11:45, Maoke a écrit :
i understand NAT64 makes translation between arbitrary IPv6 address to
arbitrary IPv4 address. i don't understand how you make CNP in any IPv6
address.
in other words, we cannot limit NAT64 stateful
2012/3/15 Rémi Després despres.r...@laposte.net
Le 2012-03-15 à 11:40, Maoke a écrit :
2012/3/15 Rémi Després despres.r...@laposte.net
Le 2012-03-15 à 10:29, Maoke a écrit :
2012/3/15 Maoke fib...@gmail.com
2012/3/15 Rémi Després despres.r...@laposte.net
Le 2012-03-15 à 10:02
2012/3/15 Rémi Després despres.r...@laposte.net
Le 2012-03-15 à 14:47, Maoke a écrit :
2012/3/15 Rémi Després despres.r...@laposte.net
Le 2012-03-15 à 11:45, Maoke a écrit :
i understand NAT64 makes translation between arbitrary IPv6 address to
arbitrary IPv4 address. i don't
on the other hand, may i suggest not to term 4rd tunnel anymore? it
confuses. i emphasized it is NOT a TUNNEL to the common understanding at
all (but it seems you never?seldom respond to this point, nor to the ICMP
issue details. ) - maoke
___
Softwires
2012/3/14 Rémi Després despres.r...@laposte.net
Le 2012-03-14 à 06:51, Maoke a écrit :
2012/3/13 Rémi Després despres.r...@laposte.net
2012-03-13 12:02, Maoke :
2012/3/13 Rémi Després despres.r...@laposte.net
...
The 4rd mechanism is for protocols that have ports at their usual
2012/3/14 Rémi Després despres.r...@laposte.net
Le 2012-03-14 à 10:00, Maoke a écrit :
2012/3/14 Rémi Després despres.r...@laposte.net
Le 2012-03-14 à 06:51, Maoke a écrit :
2012/3/13 Rémi Després despres.r...@laposte.net
2012-03-13 12:02, Maoke :
2012/3/13 Rémi Després despres.r
2012/3/14 Rémi Després despres.r...@laposte.net
Le 2012-03-14 à 10:46, Maoke a écrit :
2012/3/14 Rémi Després despres.r...@laposte.net
Le 2012-03-14 à 10:00, Maoke a écrit :
2012/3/14 Rémi Després despres.r...@laposte.net
Le 2012-03-14 à 06:51, Maoke a écrit :
2012/3/13 Rémi
it has been done.)
cheers,
maoke
2012/3/12 Rémi Després despres.r...@laposte.net
Hello, all,
An updated version of draft-despres-softwire-4rd-u is now available at
http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05
Differences with -04 include:
- DHCPv6 options are now specified
2012/3/13 Rémi Després despres.r...@laposte.net
Le 2012-03-13 à 03:18, Maoke a écrit :
2012/3/12 Rémi Després despres.r...@laposte.net
Le 2012-03-12 à 10:21, Maoke a écrit :
hi Remi,
2012/3/12 Rémi Després despres.r...@laposte.net
2012-03-12 04:09, Maoke:
...
btw, BR also depends
2012/3/13 Rémi Després despres.r...@laposte.net
2012-03-13 12:02, Maoke :
2012/3/13 Rémi Després despres.r...@laposte.net
...
The 4rd mechanism is for protocols that have ports at their usual place
(all existing protocols that have ports have them at the same place, even
if using another
hi Remi,
2012/3/12 Rémi Després despres.r...@laposte.net
2012-03-12 04:09, Maoke:
...
btw, BR also depends upon NAT44 to deal with the unknown protocol,
right? if so, may i say your statement BR will support them without
needing an update is a proposition actually not existing? because
1 - 100 of 139 matches
Mail list logo
