Support
This interactive radius support for MAP is useful when it comes to
real deployment. ISPs are likely use radius to authorize and manage
MAP subscribers.
BRs
Gang
2013/5/24, Suresh Krishnan suresh.krish...@ericsson.com:
Hi all,
This call is being initiated to determine whether there
Dear Authors,
I read the document. Very interested idea to apply BFD.
It would be good you could discuss some specific needs from Softwires
technologies to BFD.
Otherwise, it seems BFD is orthogonal to Softwire solution.
Many thanks
Gang
2013/2/2, Tina TSOU tina.tsou.zout...@huawei.com:
Dear
Hello Woj and all,
Before you submit the MAP-T, I have a question whether we need it
given MAP-E is staying on standard track.
If I understood correctly, the motivation doing MAP-T is mainly driven
by ACL requirements. I don't see there are any needs from an operator
side on this point.
Hello Chairs,
I support the outcome from Vancouver meeting to choose MAP-E as the
basis. It's a fair decision after half-year of discussions. Many
thanks for the guidance of the chairs and ADs.
BRs
Gang
2012/8/8, Suresh Krishnan suresh.krish...@ericsson.com:
Hi all,
During the softwire WG
Hello all,
A new draft have been posted to address the case, where there was no
DHCP-PD available to parameter provisioning in carrier-side stateless
solution.
Your comments are appreciated
Many thanks
Gang
-- Forwarded message --
From: internet-dra...@ietf.org
Date: Mon, 09
Hello Dapeng and all,
I agreed Med explained three different cases and also understood
Dapeng's desire.
Trying to clarify cases and converge the discussion, I suggest following words.
Hopefully, that could eliminate your concerns.
States should be maintained on other equipments, e.g. customer
2. doing much more != doing better correct. a) the useful feature of
showing number of traverse nodes has been offered by MAP-suite through
translation mode. is it really an add-on to the encapsulation? i don't
think so. sometimes provider would like to open the tunnel details to the
users
2012/5/23, Maoke fib...@gmail.com:
2012/5/23 GangChen phdg...@gmail.com
2. doing much more != doing better correct. a) the useful feature of
showing number of traverse nodes has been offered by MAP-suite through
translation mode. is it really an add-on to the encapsulation? i don't
think
=
Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP
(as a whole) on the standard track,
the other being published as experimental or informational.
Answering YES to this question means you agree we cannot publish
2012/4/5, Alain Durand adur...@juniper.net:
Dear Softwire wg members:
At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a
whole) and
4rd-U. We got very strong feedback that we needed to select one
solution to cover that full stateless case, not two, and that we
2012/4/3, Wojciech Dec wdec.i...@gmail.com:
On 2 April 2012 19:10, Rémi Després despres.r...@laposte.net wrote:
Woj Well, in terms of facts we have
1. 4rd-U does not supporting single translation mode,
Not claimed to.
It's good to get clarity now that previous 4rd-U claims 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
the IPv6 fragment header in order to keep transparency?
See above draft to get more information on comparision. BTW,
fragmentation header is in common for MAP-T and 4rd-U.
BRs
Gang
From: GangChen
Date: 2012-03-27 15:53
To: Kevin Y
CC: Softwires WG
Subject: Re: [Softwires]Path to move forward
Hello Guanghui,
2012/3/23, Guanghui Yu yu.guang...@gmail.com:
Hi all
To define the transtion extension has the same problem, it still
is a new packet for existing devices.
4rd-U cannot replace MAP-T, since it cannot support single
translation.
I guess the concern of single
,
Med
-Message d'origine-
De : GangChen [mailto:phdg...@gmail.com]
Envoyé : jeudi 22 mars 2012 08:33
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Washam Fan; Softwires
Objet : Re: [Softwires] Fragmentation in sdnat-02
2012/3/21, mohamed.boucad...@orange.com mohamed.boucad...@orange.com:
Dear
2012/3/14, Francis Dupont francis.dup...@fdupont.fr:
In your previous mail you wrote:
(*) Question 1: It is not clear in text if there is a second NAT
in the AFTR or not. Could you please confirm/infirm a second NAT
is present?
= there is one but:
- it translates
Hello Cameron,
2012/3/6, Cameron Byrne cb.li...@gmail.com:
Thanks for submitting this help draft. I have a few questions.
Is it the case that MAP deployments require DHCPv6 and therefore for
mobile the solution is scoped only for 3GPP release 10 and beyond
networks?
I guess R10 and beyond
Dear Chairs,
Could you also kindly consider to assign a time slot for
draft-murakami-softwire-4v6-translation?
Many thanks
Gang
2011/11/12, Shishio Tsuchiya shtsu...@cisco.com:
Alain
I already had sent mail to you on 2 Nov,but our draft is not listed.
2011/11/11, Ole Troan otr...@employees.org:
Gang,
Can I reserve a time slot for 4v6 translation (i.e.
draft-murakami-softwire-4v6-translation-00 and
could the authors of dIVI-pd, 4rd-T (and possibly 4rd-U) see if they could
agree on one solution?
or give arguments for _why_ 3 are needed?
Hello, Alain and Yong,
Can I reserve a time slot for 4v6 translation (i.e.
draft-murakami-softwire-4v6-translation-00 and
draft-chen-softwire-4v6-add-format-00)?
The 10 minutes for the presentation.
Many thanks
Gang
2011/11/4, Alain Durand adur...@juniper.net:
If you want to present during
2011/11/7, Rémi Després despres.r...@laposte.net:
Ole,
1. Checksum neutrality being an open question, it is relevant here.
2. It is useful AFAIK to distinguish CE addresses from BR addresses.
The best proposal I know so far is as follows (with CNP = Checksum
neutrality preserver)
CE
Dear all,
For 4v6 unified address design, people have actually discussed that
for quite long time on the mailing list.
We would like to wrap some thoughts up to contribute some ideas from
practical deployment point of view. Below is the proposed draft. Hope
that could help the discussion.
Hello Maoke,
Thanks for the discussion.
Please my reply inline.
2011/10/9, Maoke fib...@gmail.com:
hi Gang,
thanks for the reply.
2011/10/9 GangChen phdg...@gmail.com
Yes, in padding case.
what do you mean with the yes? do you mean having a short-enough
Rule-IPv6
Hello Remi,
2011/10/6, Rémi Després despres.r...@laposte.net:
Le 6 oct. 2011 à 06:01, GangChen a écrit :
I understand such encoded information helps deriving a shared IPv4
address. However, I guess it's not necessary to dig up such
information if we only take traffic contronl on IPv6 data
Hello Remi,
Thanks for the answers.
Please see my reply inline.
2011/10/5, Rémi Després despres.r...@laposte.net:
There are no necessary to put IPv4 and Port-set ID information in last
64 bits.
The CE Pv6 prefix included in the /64 Subnet prefix isn't self delimited, so
that the length of
Hello Congxiao,
Thanks for the discussion.
Please see my reply inline.
2011/10/5, Congxiao Bao cx.cer...@gmail.com:
There are no necessary to put IPv4 and Port-set ID information in last
64 bits.
The CE Pv6 prefix included in the /64 Subnet prefix isn't self delimited,
so that the length
Hello Remi,
I'm trying to put some comments for such unified address mapping.
Regarding the deterministic benefit for double translation, I guess we
only could use V bits to achieve.
There are no necessary to put IPv4 and Port-set ID information in last
64 bits.
If I understand correctly, the
Hello Dan,
Can you run an FTP server on the BIH host, and have it do active mode
transfers and passive mode transfers?
Could you elaborate the scenario? You assume BIH host taking FTP sever.
I'm not sure whether following scenarios are correct
There are two possibilities
Option 1:
Dear Med,
The logic we adopted for guessing complexity of a valid port and for the
whole range is as mentioned in
http://tools.ietf.org/html/draft-bsd-softwire-stateless-port-index-analysis-00#section-2:
In each analyzed port derivation algorithm, an attacker may implement
a redirection
2011/9/7, Simon Perreault simon.perrea...@viagenie.ca:
mohamed.boucad...@orange-ftgroup.com wrote, on 09/07/2011 03:28 AM:
What I have done is I clarified the text as follows:
o Complexity: Reflects the complexity level of understanding the
algorithm and the expected complexity to
Hello Authors,
I think the draft did really good analysis on several mapping
algorithm, especially properties evaluation part.
One question for clarification:
I saw several properties are COMPLEXITY related.
Just wondering to know what kind of criteria you adopt to judge
different levels(i.e.
Dear Chairs,
We would like to reserve a time slot for the presentation of
draft-murakami-softwire-4v6-translation in the interim meeting.
Many thanks for your helps
Best Regards
Gang
2011/8/22, Alain Durand adur...@juniper.net:
As we mentioned earlier, the softwire interim meeting will focus
Dear Chairs,
I suggest including draft-murakami-softwire-4v6-translation-00 into
the agenda as well.
We already had a presentation in last softwire meeting. It's
reasonable to continue the discussion in the interim meeting
Many thanks
Gang
2011/8/19, Yong Cui cuiy...@tsinghua.edu.cn:
Hi
2011/8/18, Nejc Škoberne n...@skoberne.net:
Dear Behcet,
Of course. But you could support various scenarios in the scope of your
draft,
not only the common CPE one.
No.
a+p does not require a NAT44 to be used. This is the case here (my guess)
because NAT44 is commonly used in the
Sure. I can imagine a Linux implementation of 4via6 translation
support. If enabled, the TCP/IP stack would only bind to specific ports
(from the range). If you check the section III./C of the following paper:
http://zhuyc.info/globecom08mivi.pdf
the authors propose a modification to the
2011/8/18, Simon Perreault simon.perrea...@viagenie.ca:
On 2011-08-18 09:59, GangChen wrote:
NAT44 is one of three
fundamental functions in A+P architecture. Otherwise, it can’t connect
to legacy end-hosts.
What if in my deployment scenario there are no legacy end hosts? What
if all hosts
2011/8/18, Nejc Škoberne n...@skoberne.net:
Dear Gang,
That is not practicable. You can't do such modification on innumerable
hosts.
Who says only innumerable hosts will want to have this? My view on this
is,
that these proposals are not meant to solve only a specific
problem for a
Dear Nejc,
as far as I can understand your draft, you make NAPT44 in the CE obligatory.
[Gang] Yes. This is to avoid the problem where there are applications
that attempt
to bind to specific ports that are not part of the allowed port range.
However, this is not the case for 4rd, dIVI,
Gang
2011/7/19, GangChen phdg...@gmail.com:
Dear Chairs,
The presentation 4via6 Stateless Translation(i.e. topic 19) is
highly related to topic 8 and 9.
May I suggest to move topic 19 together with 8 and 9?
That would be helpful for the discussion
Many thanks
Gang
2011/7/18, Alain
Hello Remi,
I guess 4V6 CE need to recognize whether received IPv6 prefix is CE
IPv6 prefix, which is used to generate a shared IPv4 address. Then, it
should be no problem to distinguish native IPv6 or an IPv6 address CE
should translated.
Gang
2011/7/19, Rémi Després despres.r...@laposte.net:
Dear all,
We have submitted a draft regarding 4via6 stateless translation.
http://tools.ietf.org/id/draft-murakami-softwire-4v6-translation-00.txt
comments are welcome.
A new version of I-D, draft-murakami-softwire-4v6-translation-00.txt
has been successfully submitted by Tetsuya Murakami and
+1
2011/7/6, Lee, Yiu yiu_...@cable.comcast.com:
+1
On 7/6/11 10:33 AM, Rajiv Asati (rajiva) raj...@cisco.com wrote:
Support.
Cheers,
Rajiv
-Original Message-
From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com]
Sent: Friday, June 17, 2011 2:32 AM
To:
Dear all,
Last IETF meeting, ADs required volunteers to draft the motivation for
stateless 4via6 mechanism.
We have updated a draft to state the motivation mostly from
operational perspectives.
We believe the concrete solution shall be decided by business
requirements, so it is essential to
43 matches
Mail list logo
