John,
Here is a link to the cluster of documents that I believe you are looking
to have RFC numbers for:
http://www.rfc-editor.org/cluster_info.php?cid=C247
IIRC, at least back when I was AD, it was possible to request RFC numbers
in advance as long as they were in the Editor's queue (past all
On Nov 13, 2013, at 5:05 PM, Ted Lemon wrote:
On Nov 13, 2013, at 10:49 AM, Ole Troan otr...@employees.org wrote:
is there a problem here, or should we just accept that sometimes the IETF
will generate ten sets of publications solving more or less the same problem?
If I'd been area
On Apr 26, 2013, at 5:22 PM, Simon Perreault wrote:
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
:
a. map PSID into the EA bits of the delegated end-user IPv6 prefix;
b. length of EA bits = 0, which might mean no mapping at all;
Best Regards,
Leaf
-Original Message-
From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On
Behalf Of Mark Townsley
Sent
On Sep 25, 2012, at 6:45 AM, Suresh Krishnan wrote:
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 MAP-E as the basis for the proposed
standard stateless
Arthur's MAP Calculator tool is now published on the iTunes and Android store:
http://itunes.apple.com/ca/app/cisco-map-calculator/id561121079?mt=8ign-mpt=uo%3D2
https://play.google.com/store/apps/details?id=map.calculatorhl=en
Just search for Cisco Map Calculator and you should find it. They
On Aug 24, 2012, at 5:50 PM, Simon Perreault wrote:
Le 2012-08-24 11:39, Wojciech Dec a écrit :
Here's an idea: a restricted profile of MAP-E that would only
allow hub-and-spoke, described in a separate RFC, would look exactly
like LW4o6, right? And it could be implemented
In favor.
- Mark
On Aug 7, 2012, at 5:02 PM, Suresh Krishnan wrote:
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 MAP-E as the basis for the proposed
Arthur, I just demoed your MAP Simulation tool for the group. Sounds like they
really liked it! (you got applause)
Here's the link, for those who missed it:
http://6lab.cisco.com/map/MAP.php
Search for Map Calculator on Google Play for the android version. iPhone
version coming soon as well.
A map domain that supports a single customer is no more heavy than a LW46
mapping table entry that supports a single customer. You are comparing 1000
of this vs. 1000 of that, where this and that are effectively equal in
terms of resources necessary for support.
There are a lot of
If we can find a way to collapse H and T such that we are back to one
encap/decap and one entrans/detrans version, I think this would be
significant progress. 3 options here just seems ridiculous though.
- Mark
On Jun 25, 2012, at 8:24, Tetsuya Murakami tetsuya.murak...@ipinfusion.com
A video showing the tool in action:
http://www.youtube.com/watch?v=CqHBjO-QbSQ
- Mark
On Jun 19, 2012, at 4:25 PM, Mark Townsley wrote:
Good day all,
I asked a student of mine from Ecole Polytechnique that Cisco hired as an
intern for the summer to create a tool to help
Because of the history of MAP and 4rd-U, we will designate independent teams
of volunteer reviewers to advise the working group about the state of the
document sets. Each set will be reviewed by an independent team who are not
authors of the MAP and 4rd-U documents. Each review team will
On Feb 2, 2012, at 10:30 AM, Rémi Després wrote:
Le 2012-02-01 à 03:04, Maoke a écrit :
...
i have investigated, technically, what if we had updated RFC6145 with
carrying ICMPv4 messages in IPv6 directly instead of translating to ICMPv6,
specially for double translation,
As I watch
While I appreciate the functional modularity in understanding the solution
space, I do wish that DT had come up with a way to make this one document to
present to the world rather than four. I fear organ rejection when tossing a
list of RFCs for one function to the CPE industry.
In current
On Nov 29, 2011, at 6:33 PM, Alain Durand wrote:
Remi,
Thank you for starting this discussion on the mailing list.
Let me clarify my chair perspective on 4rd-u
You brought this to the Taipei meeting as an attempt to 'unify' encapsulation
and translation.
I have always been of the
Alexandre and I just finished up a -00 that describes two methods for moving a
6rd deployment to native IPv6. Apologies for not getting this out before the
meeting.
http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt
Abstract
This document provides guidelines for
While it is interesting to explore the various design spaces, we do not need
more ways to munge an IPv4 packet into an IPv6 packet and back to an IPv4
packet. Any alternative beyond the simple and obvious encap/decap that routers
have used for decades is already too much IMHO, we certainly
(resending as this was bounced from softwires due to the message being too long
- I removed the thread cc'd at the end)
Begin forwarded message:
From: Mark Townsley m...@townsley.net
Date: October 18, 2011 11:07:34 AM GMT+02:00
To: Rémi Després despres.r...@laposte.net
Cc: sarik...@ieee.org
On Oct 18, 2011, at 2:31 PM, Rémi Després wrote:
Thanks, Mark, for the quick and detailed response.
More below.
Le 18 oct. 2011 à 11:07, Mark Townsley a écrit :
On Oct 18, 2011, at 10:38 AM, Rémi Després wrote:
Le 18 oct. 2011 à 10:21, Mark Townsley a écrit :
While
On Oct 18, 2011, at 10:38 AM, Rémi Després wrote:
Le 18 oct. 2011 à 10:21, Mark Townsley a écrit :
While it is interesting to explore the various design spaces, we do not need
more ways to munge an IPv4 packet into an IPv6 packet and back to an IPv4
packet. Any alternative beyond
On Oct 18, 2011, at 4:31 PM, Rémi Després wrote:
Le 18 oct. 2011 à 15:35, Mark Townsley a écrit :
On Oct 18, 2011, at 2:31 PM, Rémi Després wrote:
...
I do understand the inconvenience of having to adapt running codes based on
encapsulation to a header mapping such as that of 4rd-U
+1 ... since the alternative is that apps that require ipv4 sockets and
pass ipv4 literals are stranded on ipv6 only networks.
Running code on the n900 shows that nat464 provides real user and
network benefit
Frankly, I preferred it when you were running IPv6-only without BIH on your
On Sep 28, 2011, at 8:12 PM, Cameron Byrne wrote:
On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley m...@townsley.net wrote:
+1 ... since the alternative is that apps that require ipv4 sockets and
pass ipv4 literals are stranded on ipv6 only networks.
Running code on the n900 shows
On Aug 20, 2011, at 9:04 AM, Rémi Després wrote:
Le 20 août 2011 à 11:46, Mark Townsley a écrit :
On Aug 20, 2011, at 3:20 AM, Rémi Després wrote:
Le 20 août 2011 à 03:55, Mark Townsley a écrit :
...
we're already confused:
http://tools.ietf.org/html/draft-boucadair-softwire-cgn
On Aug 20, 2011, at 3:20 AM, Rémi Després wrote:
Le 20 août 2011 à 03:55, Mark Townsley a écrit :
On Aug 19, 2011, at 8:04 PM, Nejc Škoberne wrote:
Because of what RFC6333 says, suggesting NOW that solutions that don't
need NATs are variants of DS-lite is a sure way to confuse
Particularly when targeting the consumer appliance space, fewer documents are
better than many. Softwires should be working to converge on a single concise
and clear RFC for the stateless ds-lite mode of operation.
- Mark
On Aug 18, 2011, at 9:08 PM, Satoru Matsushima wrote:
Hello
When the RFP is coming from Best Buy for a consumer device, you want fewer
alternatives.
- Mark
On Aug 19, 2011, at 9:25 AM, Rajiv Asati (rajiva) wrote:
+1.
The RFP angle is an important one, Simon.
Cheers,
Rajiv
Sent from Phone
On Aug 19, 2011, at 8:57 AM, Simon Perreault
On Aug 19, 2011, at 8:04 PM, Nejc Škoberne wrote:
Because of what RFC6333 says, suggesting NOW that solutions that don't need
NATs are variants of DS-lite is a sure way to confuse people.
Then we're already confused:
http://tools.ietf.org/html/draft-boucadair-softwire-cgn-bypass-03
- Mark
On Aug 19, 2011, at 1:08 PM, Rémi Després wrote:
Le 19 août 2011 à 17:11, Mark Townsley a écrit :
On Aug 19, 2011, at 5:17 AM, Rémi Després wrote:
Also, one of his slides has 4rd aka Stateless DS-lite. He knows, as you
know, that I had expressed strong opposition to this badly
On Aug 5, 2011, at 2:38 PM, Alain Durand wrote:
Following-up on the Quebec meeting, we would like to organize an interim
meeting end of September.
We will focus on so-called stateless solutions and other remaining business
in the wg (multicast. mibs,...)
that require more time than we
On Jul 26, 2011, at 4:30 PM, Rajiv Asati (rajiva) wrote:
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?
I read that statement as in
that it could have a
header-size smaller than PPTP. And of course ROHC. As link-speeds increased,
these progressively fell by the wayside in terms of wide support and usage.
There are good reasons for that.
- Mark
Cheers,
Rajiv
-Original Message-
From: Mark Townsley [mailto:m
On Jul 19, 2011, at 5:18 PM, Behcet Sarikaya wrote:
The schedule is obviously rather busy. Here's a suggestion: Softwires has 30
minutes of Multicast transition presentation, while we have an entire BoF
devoted to the subject earlier in the week. Do we really need to schedule
On Jul 5, 2011, at 8:44 AM, lizhenqi...@chinamobile.com wrote:
Two Points here.
1, For stateless 6rd, using anycast does provide BR redundancy, but not
loadbalancing. Generally loadbalancing can not be achieved by anycast, see
RFC4786 Operation of Anycast Services for more information.
On May 26, 2011, at 10:36 AM, Ole Troan wrote:
I like the draft and I think it covers the motivational points well.
as a general comment, I do think the document is too wordy. could the authors
make the next revision terser or do you want me to propose text changes?
I would also suggest
On Apr 19, 2011, at 4:06 PM, Alain Durand wrote:
On Apr 12, 2011, at 4:03 PM, Mark Townsley wrote:
Hello Dmitry,
My view is that 4rd is most easily understood if and only if it connects to
a CE function that is performing NAPT. The CE function may be in what is
traditionally
On Apr 19, 2011, at 4:36 PM, IESG Secretary wrote:
A modified charter has been submitted for the Softwires (softwire) working
group in the Internet Area of the IETF. The IESG has not made any
determination as yet. The modified charter is provided below for
informational purposes only.
it as such to guide implementers.
Then at least you and I agree. If 4rd becomes a WG item, this is the kind of
change we should be able to affect in the draft with WG consensus.
- Mark
Thank you,
Dmitry
-Original Message-
From: Mark Townsley [mailto:m...@townsley.net]
Sent: Tuesday, April
On Apr 4, 2011, at 5:15 AM, Yong Cui wrote:
I read your 4rd draft. As far as I know, the current 4rd draft supports 3
models:
1. An IPv4 prefix
2. Full IPv4 address (No port sharing)
3. IPv4 address and a range of ports
So case 2 is equal to 4over6. Is my understanding right?
No time for charter discussion? or the updated 4rd draft?
http://www.ietf.org/proceedings/80/agenda/softwire.htm
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
On Mar 23, 2011, at 4:31 PM, Bruno STEVANT wrote:
To Softwire chairs,
Softwire HS Phase 2 (IPv6 over L2TPv3) is not mentioned in this new charter.
Does the group consider it as a low-priority work to be delayed until next
charter ? I won't be in Prague, but if discussion on the charter is
I'd like to see all softwire documents be as silent as possible on specifics of
NAT. The essential delta in ds-lite vs. a NAT44 CGN is that the tunnel is
embedded within the NAT binding. I think the softwire documents should explain
this, then point to behave for anything else that has to do
On 11/9/10 9:08 AM, Templin, Fred L wrote:
After the 6, 7 or 8 figure range in terms of number of sites
6rd is enabling, the advantages vs. stateful methods
become quite apparent.
I'm not sure that is exactly true. If there is concern for
scaling, simply add more routers/servers the same
) have more to gain than those that do not.
- Mark
On 11/9/10 10:18 AM, Templin, Fred L wrote:
Mark,
-Original Message-
From: Mark Townsley [mailto:towns...@cisco.com]
Sent: Monday, November 08, 2010 5:57 PM
To: Templin, Fred L
Cc: softwires@ietf.org
Subject: Re: [Softwires
Get ready for softwire draft speed dating! :-)
In the future, it might be a good idea to cover items by topic rather
than individual drafts. For example, there are at least 8 drafts that
deal with ds-lite or 4/6 tunneling. The next big subset is related to 6rd.
Each topic could be presented
You are marking 6rd as not stateless due to:
[4] ISATAP and 6rd may require a list of router addresses and/or
per-neighbor state to avoid tunnel looping attacks.
The list of BR addresses for the CE as well as the BR ACL config to
counteract the looping attack are static configuration items,
On 9/29/10 10:19 AM, WashamFan wrote:
I have one important question here: Are you looking for a solution that
you can convince your provider to deploy and support, or something that
you can setup independent of your provider? Given the situation, it
sounds to me like more of the latter.
On 9/28/10 4:09 AM, Yiu L. Lee wrote:
Hi Washam,
Don't forget there are also Softwire Hub-and-Spoke (L2TPv2 based) and 6rd+.
So far, we don't hear much response to support this work in the operator's
community.
I know of more than one L2TPv2 based softwire deployments active today.
A new
On 9/28/10 4:28 AM, Brian E Carpenter wrote:
On 2010-09-28 15:09, Yiu L. Lee wrote:
Hi Washam,
Don't forget there are also Softwire Hub-and-Spoke (L2TPv2 based) and 6rd+.
So far, we don't hear much response to support this work in the operator's
community.
One reason is that the smaller,
the 6rd tunnel.
Yes, that may be a problem with 1280. In general.
- Mrak
Thanks - Fred
fred.l.temp...@boeing.com
-Original Message-
From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On
Behalf Of Mark Townsley
Sent: Thursday, May 06, 2010 1:39 AM
To: softwires
On 3/1/10 8:44 AM, Gabi Nakibly wrote:
Hi all,
I would like to comment on the loop avoidance issue addressed in the
Security Considerations section.
First, I agree that the the best mitigation measure here for loops via
external relays is to simply drop at the border of the 6rd domain
packets
Hi Martin, great news on the interoperability. Thanks for sharing this.
A good IPv4 ECMP load-balancing algorithm will take into account the
source and destination IPv4 address pair and try to keep associated
flows along the same path if possible. However, the fewer the IP
addresses, the
On 1/11/10 12:25 PM, Ole Troan wrote:
Washam,
thanks for all your comments!
Yes, Thanks.
Ole, just a couple of comments on the proposed minor bug fixes...
10. CE IPv4 address definition in sec3:
CE IPv4 address The IPv4 address given to the CE as part of
On 1/12/10 3:43 AM, WashamFan wrote:
In 9.2, after
Additionally, a CE MUST allow packets sourced by the configured BR
IPv4 Address,
I suggest to add, for anti spoofing,
, provided their IPv6 source address doesn't start with the 6rd prefix.
We've had operators interested in
On 1/12/10 4:04 AM, WashamFan wrote:
7. It is still hard for me to get to looping issues described in
section 12, it would help if an example was there.
yes, me too. ;-)
check out:
http://www.townsley.net/ietf76/townsley-ietf76-softwires-6rd-update.pdf
and Nakibly and Arov's
Softwires,
Happy New Year all. I hope none of you are fixing Jan 1, 2010 bugs in
your code these days ;-)
You may have seen a -02 followed quickly by a -03
draft-ietf-softwire-ipv6-6rd. The reason for the quick rev was a math
bug in one of the recommended bounds checks that we let get into
57 matches
Mail list logo
