Subject: [Softwires] comments on draft-carpenter-softwire-sample-00

From: WashamFan <[email-masked]>
Date: Mon, 27 Sep 2010 16:05:15 +0800

Hi,

It says,

   The SAMPLE server will act as an IPv6 router.  In the simplest case,
   it will forward all IPv6 packets to a default route, except those
   whose destination address lies within the PSAMPLE prefix, which will
   be encapsulated and sent towards the host (CPE) and port indicated by
   the V4ADDR and PN values.

I think it is not appropriate to assume NAT traversal without
relay can be always successful. Hairpinning might be always used
for simplicity.

I'd like to know the status of the draft, is the WG pursuing this
work?

Thanks,
washam

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Sep 2010 09:16:58 +1300

Hi,

On 2010-09-27 21:05, WashamFan wrote:
> relay can be always successful. 

I don't understand your comment. If you have a NAT that you cannot
traverse with UDP, you have many other problems, not just a lack
of IPv6 connectivity.

> Hairpinning might be always used
> for simplicity.

Yes, that is the SAMPLE model. And it's a discussion for the
community whether or not this is acceptable.

> I'd like to know the status of the draft, is the WG pursuing this

There are three drafts aiming at the same problem, SAMPLE,
draft-lee-softwire-6rd-udp, and draft-despres-softwire-6rdplus.
Please hold your breath, there's hope of a joint proposal
from several authors within a few days.

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Sep 2010 16:06:42 -0700

Hi Brian, 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Monday, September 27, 2010 1:17 PM
> To: WashamFan
> Cc: [email-masked]
> Subject: Re: [Softwires] comments on 
> draft-carpenter-softwire-sample-00
> 
> Hi,
> 

And then there is IRON, which already incorporates the
SAMPLE approach as a solid story for NAT traversal to
compliment its many other desireable attributes.

Thanks - Fred
[email-masked]

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: WashamFan <[email-masked]>
Date: Tue, 28 Sep 2010 09:49:39 +0800

Hi,

Please see inline.

----- Original Message -----
From: Brian E Carpenter <[email-masked]>
Date: Tuesday, September 28, 2010 4:17 am
Subject: Re: [Softwires] comments on draft-carpenter-softwire-sample-00
To: WashamFan <[email-masked]>
Cc: [email-masked]

>  traverse with UDP, you have many other problems, not just a lack

I misunderstood. I thought the text implies direct tunnels established
instead of hairpinning via SAMPLE server when SAMPLE client to 
SAMPLE client communication occurs . 

>  from several authors within a few days.

Is it possible to combine all these efforts? I see 2 major 
difference between  draft-carpenter-softwire-sample-00
and draft-lee-softwire-6rd-udp-02 at least:

1. According to the IPv6 address assignment, SAMPLE
is  to connect isolated IPv6 hosts but 6rd-udp is to connect
both isolated IPv6 hosts and LANs.

2. They are different in terms of IPv6 address assignment
procedure. SAMPLE uses ND but 6rd-udp might use RADIUS,
let's say.

Personally, I think it is meaningful to work on tunneling
IPv6 traversing NAT, but I think we should justify the work
by clarifying how bad Teredo did the job before we reinvent
the wheel.

THanks,
washam

---

From: "Yiu L. Lee" <[email-masked]>
Date: Mon, 27 Sep 2010 22:09:23 -0400

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.

Regards,
Yiu

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Sep 2010 15:28:41 +1300

> So far, we don't hear much response to support this work in the operator's

One reason is that the smaller, more agile ISPs with problems
in this area are simply figuring out how to deal with Teredo,
e.g. with Tui boxes, http://www.braintrust.co.nz/tui/

IMNSHO, cumbersome solutions like L2TPv2 will only appeal to telco-like
operators.

   Brian

---

From: Rémi Després <[email-masked]>
Date: Tue, 28 Sep 2010 19:03:38 +0200

Hi Washam,

As Brian suggested, it might be best to wait for the new proposal (we work together on it).
It is intended to combine, improve, and complete, draft-carpenter-6man-sample and draft-despres-softwire-6rdplus. 

Traffic between two NAT44 sites is, as you suggested, always based on hairpinning (simpler and, even more important IMHO, resistant to all odd NAT behaviors).

Its other distinctive property is that hosts behind the same NAT44 communicate directly within their site using their IPv6 addresses.

Your comments will be most welcome when the draft is available.

Regards,
RD

---

From: Mark Townsley <[email-masked]>
Date: Tue, 28 Sep 2010 21:38:15 +0200

> So far, we don't hear much response to support this work in the operator's

I know of more than one L2TPv2 based softwire deployments active today.
A new one is getting ready to go online soon as well (sorry, not my
place to spill the beans on who).

Given existing deployment of L2TP and TSP, I still find it hard to see
why another stateful point-to-point tunnel is really necessary at this
stage of the game.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Tue, 28 Sep 2010 21:57:43 +0200

> e.g. with Tui boxes, http://www.braintrust.co.nz/tui/

Oh yeah, that one too.

> IMNSHO, cumbersome solutions like L2TPv2 will only appeal to telco-like

L2TP is often the NNI which allows a challenger ISP to setup service to
subscribers where the "telco-like" incumbent owns the physical layer (in
particular for remote locations where co-location might not be a
reasonable option). So, it ends up in a lot of different types of ISPs,
even those that do not have PPP anywhere else. The one place where it
almost never ends up is at a DOCSIS cable operator, which is where I
hear most of the resistance to its introduction.

L2TP would and should lose a beauty contest with a brand new protocol
created today (surely we would have learned something in 15 years!).
However, on the concentrator side, virtually every SP vendor has an LNS
offering, alongside open source options if you want to go that route. On
the client side, it is in a number of RGs, pretty much every host OS,
not to mention your iPhone, iPad, Android... It's everywhere. Why not
just use it? PPP isn't *that* hard.

- Mark

---

From: WashamFan <[email-masked]>
Date: Wed, 29 Sep 2010 13:30:07 +0800

Hi Remi,

Personally, I think it is very meaningful to address tunneling
IPv6 over IPv4 with NAT traversal issue, especially in China.
We have less IPv4 address space assigned at the first place,
compared to the huge population, the address per person
ratio is very low, I suspect some ISPs have already deployed
some kind of NATs somewhere in their network. (As myself,
I got 10/8 from my provider). In the other hand, we bought
CPE outselves, the ISP can not control the CPES most of
time, I am afraid. That is very different from that in Europe
or America, I guess. My impression is, from my experience
surfing the Internet, I would go thru one layer NAT (deployed
by my provider in my residential building) and a 192.168
network (somewhere in the SP network) before I hit the 
Internet finally. 

When my ISP is going to provide IPv6 to me, let's say,
6rd as the first step, the existing complex network arch would
hinder the classic 6rd deployed.

I am looking forward to the new combined proposal.

Thanks,
washam

----- Original Message -----
From: Rémi Després <[email-masked]>
Date: Wednesday, September 29, 2010 1:03 am
Subject: Re: [Softwires] comments on draft-carpenter-softwire-sample-00
To: WashamFan <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>, [email-masked]

>  It is intended to combine, improve, and complete, 
> draft-carpenter-6man-sample and draft-despres-softwire-6rdplus. 
>  
>  Traffic between two NAT44 sites is, as you suggested, always based on 
> hairpinning (simpler and, even more important IMHO, resistant to all 
> odd NAT behaviors).
>  
>  Its other distinctive property is that hosts behind the same NAT44 
> communicate directly within their site using their IPv6 addresses.
>  
>  >>>   whose destination address lies within the PSAMPLE prefix, which 
> 
>  >> will

---

From: Mark Townsley <[email-masked]>
Date: Wed, 29 Sep 2010 09:53:43 +0200

On 9/29/10 7:30 AM, WashamFan wrote:
> time, I am afraid. 

There are still plenty of providers in the US and EU that sell service
without control of the CPE. For newer "3-play" DSL and FTTH service it
is trending more towards an SP-provided CPE, but there is still plenty
of consumer-purchased CPE out there.

I think in 2011 you are going to see more and more 6rd with the DHCP
option on products that you can buy from your local electronics stores.
If the SP sets up a BR and offers the DHCP option, 6rd should work
reasonably well even with consumer purchased CPE.

> That is very different from that in Europe

If you add your own NAT in your apartment, that's at least 3 levels of
NAT...

> hinder the classic 6rd deployed.

...That many levels of NAT is a hindrance for the SP to deploy just
about anything.

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.

- Mark

---

From: WashamFan <[email-masked]>
Date: Wed, 29 Sep 2010 16:19:20 +0800

>  sounds to me like more of the latter.

Tunnels start at one point and terminate at the other. Can
you really setup IPv6 service independent of your provider?
IPv6 service should always be delivered by your provider, but
in the situation I described above, it seems to me it is hard
for those providers delivering IPv6 service over existing
complex IPv4 networks.

Thanks,
washam

---

From: Mark Townsley <[email-masked]>
Date: Wed, 29 Sep 2010 12:13:59 +0200

> you really setup IPv6 service independent of your provider?

Teredo does precisely that. But, it relies on relays that may or may not
work for you.

I'm not sure which is the best for where you are located in China, but
here's a list of services that will terminate the other end of the
Tunnel for you beyond your SP:

http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers

6fei seems to be one in China, and uses TSP which is designed to
discover the presence of NATs and bore through them appropriately.

- Mark

---

From: "Yiu L. Lee" <[email-masked]>
Date: Wed, 29 Sep 2010 10:13:35 -0400

Hi Washam,

If I were the SP running multiple NAT layers, I would have more worry of
breaking IPv4 services than finding a way to give IPv6 to users.

Cheers,
Yiu

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 29 Sep 2010 15:02:20 -0700

Mark, 

> [mailto:[email-masked]] On Behalf Of Mark Townsley
> Sent: Tuesday, September 28, 2010 12:58 PM
> To: [email-masked]

Actually, I had my first cursory look at L2TP only a
few days ago. Without doing a deep dive into the spec,
I am truly perplexed as to how you could have chastised
my SEAL proposal as being "complex".

Some of the things I have seen so far in L2TP are
variable-length headers prepared piecemeal instead
of as a single unit, control messages spliced together
from bits and pieces, cursory treatment of MTU issues,
complicated connection control, tunnel "sessions" (?),
ppp overlays (??), and I'm sure much more.

Most of this extra "stuff" looks to me like it was
thrown in to compensate for the fact that L2TP does
not seem to recognize the tunnel as a point-to-
(multi)point interface with route configurations,
neighbors and the like the same as for any interface.
You should really have another look at SEAL.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 29 Sep 2010 15:14:09 -0700

Here is a first-pass attempt at capturing a feature by
feature comparison of popular tunneling mechanisms. If
there are mechanisms I have missed, please let me know
and send Y/N values for the various features. If you
see features missing that should be included in the
comparison, let me know. If you see feature descriptions
you do not agree with, please provide some of your own.

Upshot is that nothing I know of comes close to IRON
in terms of desirable features.

Thanks - Fred

---

From: Mark Townsley <[email-masked]>
Date: Thu, 30 Sep 2010 03:14:24 +0200

> You should really have another look at SEAL.

I already admitted L2TP wouldn't win any beauty contests.

The point is running, interoperable, available, code. Particularly for a
transition mechanism that is targeted at being temporary.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Thu, 30 Sep 2010 10:51:34 +0200

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, neither
constitute dynamic state.

- Mark

PS. IRON does have an impressive feature list here!

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 30 Sep 2010 14:58:45 -0700

Folks,

I am receiving useful feedback on this, and will make
appropriate updates. Based on the feedback, it is too
early to make conclusive statements such as appeared
in my original message, so please keep the feedback
coming and we will see where it takes us.

Thanks - Fred

> [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Wednesday, September 29, 2010 3:14 PM
> To: [email-masked]
> Subject: [Softwires] Tunneling mechanism feature comparison
>