Jordan’s distinction about tunneling vs translation is key here given the
considerations for the normative language.
Mike’s suggestion is not that BR should calculate checksum, rather that BR
should forward packets with UDP checksum being 0. Is that right, Mike? If so,
then it is reasonable.
I agree and sometimes flexibility becomes an unwanted necessity (as is the case
here with option (a)).
IMO, option (b) length based check for NH should be preferred, since it works
for all AFI/SAFIs with an assumption that NH could be one IPv4 or IPv6 prefix.
Very reasonable option.
Option
Thanks, Eric & Dave.
--
Cheers,
Rajiv
From: Eric Vyncke
Date: Tuesday, May 28, 2019 at 3:07 AM
To: David Black , "tsv-...@ietf.org"
Cc: Softwires-wg list , IETF Discussion ,
"draft-ietf-softwire-iftunnel@ietf.org"
Subject: Re: Tsvart last call review of draft-ietf-softwire-iftunnel-04
Hi David,
Thanks for your review and comments. QQ -
>My fundamental concern with this draft is that the MIB-2 tunnel type
>registry is seriously incomplete and out of date, as there are a large
>number of tunnel types that aren't included in that registry, e.g., IPsec
>tunnel-mode AMT tunneling.
1. Not aware
2. Not aware.
Cheers,
Rajiv Asati
Distinguished Engineer, CX CTO Office
> On Jan 28, 2019, at 9:43 AM, "ian.far...@telekom.de"
> wrote:
>
> Hi Yong,
>
> Please see inline below.
>
> Thanks,
> Ian
>
> On 26.01.19, 13:08, "Softwires on behalf of Yong Cui"
> wrote:
>
>
Support (as a co-author).
--
Cheers,
Rajiv
From: Softwires on behalf of "ianfar...@gmx.com"
Date: Tuesday, January 8, 2019 at 11:48 AM
To: Yong Cui
Cc: Softwires-wg list
Subject: Re: [Softwires] WGLC for draft-ietf-softwire-iftunnel-01
HI Yong,
Sorry for the late response. I’m still
cially, this part:
Some Service Providers have a requirement to use only existing
logging systems and to avoid introducing new ones (mainly because of
Capital Expenditure (CAPEX) considerations). This requirement is
easily met with stateless solutions.
Cheers,
Med
De : Softwires [m
e-encapsulation of IPv6. Rajiv, pls
check if we can do this on ASR9k as BNG.
Regds
Ramesh
From: Lee, Yiu [mailto:yiu_...@comcast.com]
Sent: 09 May 2018 08:35
To: Rajiv Asati (rajiva); Ramesh R Chandra
Cc: ianfar...@gmx.com; softwires@ietf.org; int-a...@ietf.org
Subject: Re: [EXTERN
brainer and all this is available in NAT44. MAP being stateless, no
such data available from MAP-BR. We are exploring alternate option on BR to
create this data in MAP.
Pls advise.
Regds
ramesh
-Original Message-----
From: ianfar...@gmx.com<mailto:ianfar...@gmx.com> [mailto:ianfar...@
quired to do so for administrative reasons.
Cheers,
Med
De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Rajiv Asati
(rajiva)
Envoyé : jeudi 3 mai 2018 23:50
À : Softwires-wg list; int-a...@ietf.org
Cc : ramesh.r.chan...@ril.com
Objet : [Softwires] ISP CGN logging inc. Destination ??
Is t
ing.
daveor
On 3 May 2018, at 22:50, Rajiv Asati (rajiva)
<raj...@cisco.com<mailto:raj...@cisco.com>> wrote:
Is there an RFC (besides 6269) that encourages / discourages CGN logging of
destination IP+Port if source IP+port is already logged?
RFC6269 does mention the below, as com
Ian,
Thanks for sharing the URL. While not explicit, “all metadata” would include
both source and destination A+P. Is that the right interpretation?
If an ISP were to use “binding” mode on the BR, then without using net
flow/IPFIX, How could the compliance be achieved ?
Cheers,
Rajiv Asati
Is there an RFC (besides 6269) that encourages / discourages CGN logging of
destination IP+Port if source IP+port is already logged?
RFC6269 does mention the below, as compared to the server side logging of
source IP+port -
// logging the destination address on the NAT is inferior
to
Chongfeng,
Happy to hear wide IPv6 deployment in CT production network.
Could you please help us understand how is this draft related to the above ?
Perhaps, moving from v4-only/dual-stack to IPv6-only (between CPE and BNG
through ASBR) and deploying MAP function on CPE. Is that it ? If yes,
Ted,
I would therefore like the working group to consider changing the proposed
status of MAP-T to Proposed Standard.
That's quite reasonable. And I agree, especially given that few operators have
already deployed and asked for the same.
If the working group agrees, we would go through a
It might be worth understanding why this problem is even worth
addressing/mentioning.
Is the possibility of 2 or more host devices (behind 2 or more MAP CE
routers) sharing the same IPv4 address would be generating the fragmented
packets towards the same destination around the same time, not
UmmŠthat doesn¹t cut it either, since softwire node will always have to
formulate the 32-bit IPv4 address even if /32 is conveyed. Also,
Software interface is not defined anywhere in this document.
How about the following -
--
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco
be used.
There is naturally the non-address-shared mode of MAP to consider (i.e.
when PSID length =0). Here each MAP user has a full IPv4 address and of
course also the corresponding full port range.
Cheers,
Wojciech
On 13 November 2013 19:12, Rajiv Asati (rajiva)
raj...@cisco.com wrote:
Hi
Hi Kristian,
Yes, that's correct.
--
Cheers,
Rajiv
-Original Message-
From: Poscic, Kristian Poscic kristian.pos...@alcatel-lucent.com
Date: Tuesday, November 12, 2013 6:31 PM
To: Softwires-wg list softwires@ietf.org
Subject: [Softwires] port-forwards in MAP
Just wanted to
Hi Edwin,
This document has been quite useful to few of upcoming MAP-T deployments.
I would be supportive of its adoption in this WG, if/when prompted by the
chairs.
--
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco
-Original Message-
From: Edwin Cordeiro ecorde...@nic.br
Date:
Typically, an IP address pertains to a CPE. So, a common BCP is to employ
uRPF to detect/mitigate the source-address spoofing.
In A+P environment (such as that of MAP), an IPv4 address + port-range
pertain to a CPE. So, it is tempting to think that the port-range aware
uRPF is needed to avoid
I really don't see the need for having to specify more than one BR
prefixes (of whatever length) inside a single MAP domain. Let alone FQDN
or list of IP addresses.
The reason is that having multiple BR prefixes in the same domain would at
best allow the upstream traffic to go to different BR.
attribution and spoofing
Le 2013-04-26 16:50, Rajiv Asati (rajiva) a écrit :
Thankfully, in MAP, both CE and BR employ the so called port-range aware
uRPF, as Ole well clarified. So, the possibility of any device causing
any
grief to any other device (in the network - CE or outside the network -
via BR
based attribution and spoofing
On Fri, Apr 26, 2013 at 7:50 AM, Rajiv Asati (rajiva) raj...@cisco.com
wrote:
Typically, an IP address pertains to a CPE. So, a common BCP is to
employ
uRPF to detect/mitigate the source-address spoofing.
In A+P environment (such as that of MAP), an IPv4 address
I agree with Med. In reality, it is highly unlikely that each and every Dhcpv4
option would be needed for an ipv6 only host.
And the ones that are really needed, would better move to dhcvpv6 sooner than
later. It would be prudent for us to do find the delta instead of carrying over
the legacy
Ole, Tom,
I would suggest fixing port offset to 6 rather than 4, since 0-1023 are
the system/reserved ports that should be avoided by default. This also
allows increasing the IP address sharing efficiency, suffice to say, as
Tom already noted.
Pls see RFC6335.
Of course, the default
I thought we had closed this optic after the extensive discussion on the
mailing list few months back.
Cheers,
Rajiv
-Original Message-
From: Ole Troan o...@cisco.com
Date: Wednesday, February 13, 2013 6:17 PM
To: Tom Taylor tom.taylor.s...@gmail.com
Cc: Softwires-wg list
I support (a).
Not allowing the usage of the reserved port range 0-1023 is one less thing
for an operator to worry about.
0-1023 range is good enough to be blocked.
Cheers,
Rajiv
-Original Message-
From: Ole Troan o...@cisco.com
Date: Tuesday, February 5, 2013 8:38 AM
To:
+1 in keeping both.
-Original Message-
From: wang.c...@zte.com.cn wang.c...@zte.com.cn
Date: Monday, January 28, 2013 9:38 PM
To: Wojciech Dec wdec.i...@gmail.com
Cc: Softwires-wg list softwires@ietf.org, remi.desp...@free.fr
remi.desp...@free.fr, softwires-boun...@ietf.org
is whether to import these algorithm parameters EXPLICITLY into IPv6
address or not.
Lw4o6 does not import anything into IPv6 address.
Nor does MAP in a typical deployment. IOW, MAP doesn't require IPv6 prefix
assignment (or addressing policy) to be different from what it would be
without MAP.
Let's not leave anything in the drafts as loose-ends for the readers (e.g.
Implementors, designers, architects) to (mis)interpret.
We better provide recommendations, if/as needed in case of ambiguity or
disagreement.
IMO, /64 (or less) usage for end-user prefix is better off as a MAP (-E)
I just noticed an opportunity for the technical fix-up in section 5.1.
The current text suggests reserving the first IPv6 prefix in an End-user
IPv6 prefix for MAP. Well, we should't be reserving the entire prefix. We
just need an address.
Please consider updating the text.
OLD:
zero) of
looks a
stateful solution to me.
On 11/10/12 1:34 AM, Rajiv Asati (rajiva) raj...@cisco.com wrote:
One can define a MAP-domain consisting of 1 CE or N CEs. This is more of
a
deployment choice.
Cheers,
Rajiv
-Original Message-
From: Lee, Yiu Lee yiu_...@cable.comcast.com
Date: Friday
One can define a MAP-domain consisting of 1 CE or N CEs. This is more of a
deployment choice.
Cheers,
Rajiv
-Original Message-
From: Lee, Yiu Lee yiu_...@cable.comcast.com
Date: Friday, November 9, 2012 2:43 PM
To: Softwires-wg list softwires@ietf.org
Subject: [Softwires] MAP-E 1:1 for
Let's not get into debating the local behavior e.g. Implementation
specifics (since one can argue that the router vendors can provide
comparable optimization for host routes as well as non-host routes).
If I as a vendor were really bothered about host vs. non-host
control-plane data-plane, then
Favor of both.
When will the opportunity be to change from experimental to standards? and
what will it take ?
Thanks.
Cheers,
Rajiv
Sent from my Phone
On Sep 25, 2012, at 12:45 AM, Suresh Krishnan suresh.krish...@ericsson.com
wrote:
Hi all,
During the softwire WG meeting at IETF84
+1
I also support MAP-E and MAP-T, as Maglione pointed out. We need to be
respectful of the design team that produced MAP based on consideration and
requirements. Not to forget that MAP-T (unlike others) has already been
deployed.
Cheers,
Rajiv
Sent from my Phone
On Aug 8, 2012, at 5:35 AM,
Support.
Cheers,
Rajiv
-Original Message-
From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On
Behalf Of Satoru Matsushima
Sent: Friday, July 20, 2012 6:12 AM
To: Suresh Krishnan
Cc: Softwires WG; Yong Cui
Subject: Re: [Softwires] Call for adoption of
This is a moot argument, as we have seen many protocols (take MPLS for
example) that were proposed to do just X, evolved to do X, Y, Z and
more.
Who would have thought that BGP would be advertising MAC addresses when
BGP was first introduced?
Let's focus on the operational problems solved (or
I am not fond of the proposed change.
After all, most of the other documents refer to stateful without taking a
side (e.g. carrier-side), and so this document should state stateless in the
same regard.
Of course, where it makes sense to clarify, it must be clarified that stateless
is in the
1. Rajiv Asati, Cisco: Yes
2. Rajiv Asati, Cisco: MAP
Cheers,
Rajiv
-Original Message-
From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org]
On
Behalf Of Alain Durand
Sent: Wednesday, April 04, 2012 5:14 PM
To: softwires@ietf.org WG
Cc: int-...@tools.ietf.org;
I am well aware of this, but this doesn't explain why 4rd mapping rules
similar
to those of CERNET2 wouldn't have, like MAP-T, IPv4 to IPv6 communication
(single translation) supported.
As said in RFC6219, CERNET hosts have their IPv6 addresses configured via
manual configuration or
I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls
GMA
(still trivial to implement and to use but harder to trace).
I agree. GMA is defined here, btw -
http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-0
2#section-4.1
Cheers,
Rajiv
-Original
+1
Cheers,
Rajiv
Sent from my Phone
On Feb 11, 2012, at 3:30 AM, Francis Dupont francis.dup...@fdupont.fr wrote:
In your previous mail you wrote:
(1) Either issue a WG LC, or
+1
francis.dup...@fdupont.fr
___
Softwires mailing list
I would shy away from drawing that conclusion, given the implementation
specifics.
Cheers,
Rajiv
-Original Message-
From: Rémi Després [mailto:despres.r...@laposte.net]
Sent: Tuesday, February 07, 2012 8:28 AM
To: Rajiv Asati (rajiva)
Cc: Satoru Matsushima; Softwires WG; Wojciech
ability instead of the more general five-tuple based IPv4
classification ability should be reserved, when deliver IPv4 over
IPv6?
How would one get 5-tuple based classification when delivering IPv4 over
IPv6, if the v4 packet is not translated into v6?
The fact of the matter is that 5-tuple
Hi Xie,
China Telecom have placed the prototype of DIVI in its product
network
and gave a systematic test , and we haven't found any reachibility
problem due
to option processing in tranlation box. Moreover, during Tinghua 100th
Thanks for sharing your deployment experience. This
every IP-only app work now on
n900?
Cheers,
Rajiv
-Original Message-
From: Cameron Byrne [mailto:cb.li...@gmail.com]
Sent: Wednesday, September 28, 2011 3:14 PM
To: Rajiv Asati (rajiva)
Cc: Mark Townsley; Hui Deng; Softwires-wg list; Behave WG; IETF Discussion;
Dan Wing (dwing
Hi Cameron,
Very interesting ( clever indeed).
How does this clever code ensure that all but a few (pesky apps)
continue to use IPv6 interface instead of the NAT46 interface?
Cheers,
Rajiv
-Original Message-
From: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] On
Behalf
tunneling). It may be that the recommendation is specifically against
*stateful* double translation
That may be reasonable. And the document may reflect that.
IETF recommends using dual-stack or tunneling based solutions
for
IPv6 transition and specifically recommends against
that the interim meeting agenda would end up allowing more
than one WGs work on 4v6 transition options. Not the best intent in
favor of larger internet community.
Cheers,
Rajiv
-Original Message-
From: Rajiv Asati (rajiva)
Sent: Friday, August 19, 2011 11:04 AM
To: 'Alain Durand'
Cc
Yes for 5 and 4.
On 20 August 2011 16:21, Yong Cui cuiy...@tsinghua.edu.cn wrote:
Hi folks,
Following our rough concensus during Quebec City meeting and
according to our charter/milestones, the chairs would like to
ask the mailing list for the confirmation to
Yong,
Why is dIVI not included In the discussion ?
Could you please clarify?
Cheers,
Rajiv
Sent from Phone
On Aug 19, 2011, at 8:10 AM, Yong Cui cuiy...@tsinghua.edu.cn wrote:
Hi folks,
We, softwire wg chairs, in agreement with our ADs, are announcing
an interim meeting in Beijing
+1.
The RFP angle is an important one, Simon.
Cheers,
Rajiv
Sent from Phone
On Aug 19, 2011, at 8:57 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
On 2011-08-19 05:19, Tetsuya Murakami wrote:
draft-murakami-softwire-4rd
draft-murakami-softiwire-4v6-translation
I think it
, not
just a particular solution.
Cheers,
Rajiv
-Original Message-
From: Alain Durand [mailto:adur...@juniper.net]
Sent: Friday, August 19, 2011 9:44 AM
To: Rajiv Asati (rajiva)
Cc: Yong Cui; softwires@ietf.org; liziye; iesg-secret...@ietf.org;
Ralph Droms
(rdroms)
Subject: Re
Nejc,
Good table indeed.
If you could add few more service related impact due to other features such as
UPNP inside home, DPI in the network, L4 QoS in the network, L4-aware routing
etc., then it would be quite insightful. I may also help you with that.
Cheers,
Rajiv
-Original
: xiaohong.d...@orange-ftgroup.com [mailto:xiaohong.deng@orange-
ftgroup.com]
Sent: Wednesday, August 10, 2011 5:35 AM
To: despres.r...@laposte.net; Rajiv Asati (rajiva)
Cc: softwires@ietf.org
Subject: RE: [Softwires] Clarification of the stateles/stateful discussion
|-Original
Satoru-san,
This is an important point that most of us forget that restricting to
n ports doesn't equate to just n NAT sessions rather many more than
n sessions. We must add that to the 4v6 motivation draft as well as to
the 4v6 comparison draft.
port. There may be multiple session to
Hi Cameron,
Please see inline,
I believe the mapped mode has some similar challenges in mobile as
DS-lite. It is an IP in IP tunnel. It is really a non-starter in
3GPP networks as the draft amply notes.
Thanks for sharing your opinion about the 4v6 encap mode as well as
other tunneling
doesn't really solve the problem, considering the
evolving operational practices.
Cheers,
Rajiv
-Original Message-
From: Jan Zorz @ go6.si [mailto:j...@go6.si]
Sent: Monday, August 01, 2011 10:32 AM
To: Rémi Després
Cc: Rajiv Asati (rajiva); softwires@ietf.org
Subject: Re: [Softwires
Indeed.
And we keep forgetting an important point that most of us have been
*just* fine with only 1000 (or 2000) ports since that's what most
CPE/home routers in our homes had with NAT44, by default.
Cheers,
Rajiv
-Original Message-
From: softwires-boun...@ietf.org
Jan,
The better solution would be to allocate more ports to the user,
depending on ISP policy.
The CPE/home router can log the exhaustion of the binding and this could
be notified by SNMP (at least in the managed CPE case).
Cheers,
Rajiv
-Original Message-
From:
Cameron,
... there are not enough public
address to give these users (growth through 2015) each 2000 ports.
Agreed. Please note that 2000 ports per subscriber is just one allocation
point. It could be as low as 16 ports per subscriber.
In wireline deployments, 256 or 512 or 1000 ports
We agree that different operators (whether in 3GPP/mobile space or Wireline
(DSL/Cable/Fiber) space) would embrace stateful or stateless NAT based
solution, per their short-term long-term plans and associated constraints.
Perhaps, it could be phrased a bit better in the draft, but that's not
I think definitely we should define the first case, isn't reduce
redundant
delivery the original spirit of multicast? Deliver multicast over an
IPv6
multicast disabled network doesn't seem quite persuading, except the
legacy
case.
And AMT has been devised to address that very space. :)
We
Remi,
Note also that, in 3GPP where power consumption is important, the IPv4v6
bearer option completely avoids the IPv6 header overhead (no need for 4V6).
Don't follow this. Could you please expand?
Cheers,
Rajiv
-Original Message-
From: softwires-boun...@ietf.org
Cameron,
Since i have seen 3G/LTE on a few of these related threads, i will
state that it is unlikely that mobile wireless providers and the
3GPP/GSMA will adopt yet another tunneling protocol or user equipment
modification.
Thanks for sharing your opinion, as most of us may not be caring
Support.
Cheers,
Rajiv
-Original Message-
From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com]
Sent: Friday, June 17, 2011 2:32 AM
To: mohamed.boucad...@orange-ftgroup.com
Cc: Satoru Matsushima; Softwires-wg; 'Softwire Chairs'; Lee, Yiu;
olaf.bonn...@telekom.de;
68 matches
Mail list logo
