Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 1 Apr 2011 07:15:21 +0000

Hi Mark,

Absolutely. L2TP tunnels are widely use in many areas including 4over6.
The motivation of this draft is to extend dslite to re-use the same
framework to provision a public IP to the B4 element and the AFTR not to
NAT. I agree RFC5571 can achieve the same objective, but this will make
the deployment easier to do two functions on the AFTR. Does this make
sense to you?

Thanks,
Yiu  

On 4/1/11 1:17 AM, "Mark Townsley" <[email-masked]> wrote:

>L2TP tunnels are absolutely in use today.
>
>- Mark

---

From: Ole Troan <[email-masked]>
Date: Fri, 1 Apr 2011 12:05:31 +0200

> the deployment easier to do two functions on the AFTR. Does this make

Yiu explained this to me during PCP, and I think I get it now.

this is for the case where one has already deployed DS-lite to a customer.
for whatever reason DS-lite fails for this end user (e.g. some application doesn't work through the CGN).

4over6 provides a solution for provisioning a non NATed non port restricted public IPv4 address to this end user.

seems to me a very valid use case and something we should measure all of the 4 over 6 mechanisms (ds-lite, 4rd, divi...) against. 

cheers,
Ole

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 1 Apr 2011 20:41:17 +0000

Ole,

Thanks for explain the use case to the list. This is exactly what we have
in mind for this draft.

/Yiu

On 4/1/11 6:05 AM, "Ole Troan" <[email-masked]> wrote:

>for whatever reason DS-lite fails for this end user (e.g. some
>application doesn't work through the CGN).
>
>4over6 provides a solution for provisioning a non NATed non port
>restricted public IPv4 address to this end user.
>
>seems to me a very valid use case and something we should measure all of
>the 4 over 6 mechanisms (ds-lite, 4rd, divi...) against.
>
>cheers,
>Ole
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 1 Apr 2011 22:04:31 +0000

Hi Ole,

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?

Thanks,
Yiu

---

From: Yong Cui <[email-masked]>
Date: Sat, 02 Apr 2011 11:45:55 +0800

Thanks Ole for your explanation.
So the public 4over6 is just a slight revision to DS-Lite:
We need to remove NAT in DS-Lite and make the client get public IPv4
address.

Yong

-----Original Message-----
From: Ole Troan <[email-masked]>
Date: Fri, 1 Apr 2011 12:05:31 +0200
To: "Lee, Yiu" <[email-masked]>
Cc: Mark Townsley <[email-masked]>, Yong Cui
<[email-masked]>, "[email-masked] list"
<[email-masked]>
Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6

---

From: Ole Troan <[email-masked]>
Date: Mon, 4 Apr 2011 10:39:16 +0200

Yiu,

> So case 2 is equal to 4over6. Is my understanding right?

yes, the 'service' provided should be the same.
I presume 4over6 also could do 1?

the main differences between 4over6 and 4rd for case 2, would be how it is provisioned and that 4over6 wouldn't have any dependency between the tunnel endpoint addresses and the payload addresses.
obviously 4rd could be made less dependent of that too, by assigning specific IPv6 addresses for the mapping, independent of the delegated IPv6 prefix used within the end user site. doing that you really keep mapping state in the RIB. but that's definitely one deployment model of 4rd.

cheers,
Ole

---

From: Yong Cui <[email-masked]>
Date: Mon, 04 Apr 2011 20:15:13 +0800

>I presume 4over6 also could do 1?
Currently, we only focus on 2 without 1. Because if we use DHCPv4 over
IPv6 tunnel, DHCPv4 doesnot support prefix assignment, right?
>
>the main differences between 4over6 and 4rd for case 2, would be how it
>is provisioned and that 4over6 wouldn't have any dependency between the
>tunnel endpoint addresses and the payload addresses.
>obviously 4rd could be made less dependent of that too, by assigning
>specific IPv6 addresses for the mapping, independent of the delegated
>IPv6 prefix used within the end user site. doing that you really keep
>mapping state in the RIB. but that's definitely one deployment model of
>4rd.
Even for 2, the use cases are different between 4over6 and 4rd because of
the independency of IPv4/IPv6 addresses. For example, 4over6 can assign
the public IPv4 addresses to a few high-priority hosts distributed in a
large-scale network withOUT changing the local network devices or the
current policy of IPv6 address assignment. So we don't need the
cooperation with the local IPv6 address assignment.
That's quite important for our CERNET2.

Yong

---

From: Mark Townsley <[email-masked]>
Date: Mon, 4 Apr 2011 05:31:42 -0700

> That's quite important for our CERNET2.

Classic stateful vs. stateless deployment alternative. I hear the same for people who end up deploying L2TP for IPv6 over IPv4 instead of 6rd. It all depends on how much control you need over the two addressing families and their interaction. 

- Mark

---

From: Yong Cui <[email-masked]>
Date: Mon, 04 Apr 2011 20:38:35 +0800

>Classic stateful vs. stateless deployment alternative. I hear the same
>for people who end up deploying L2TP for IPv6 over IPv4 instead of 6rd.
>It all depends on how much control you need over the two addressing
>families and their interaction.

You are right, Mark. So in order to encourage the deployment of IPv6 and
make the deployment as simple as possible, we are looking forword to the
4over6 solution in CERNET2.

Yong

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 5 Apr 2011 16:54:36 +0000

100% agreed.

---

From: Rémi Després <[email-masked]>
Date: Wed, 6 Apr 2011 14:57:17 +0200

Le 4 avr. 2011 à 14:38, Yong Cui a écrit :
...
>>> For example, 4over6 can assign
>>> current policy of IPv6 address assignment.

This is a requirement for a customizable service.

>>> So we don't need the

>> families and their interaction.

Same view.
It can also be viewed as a tradeoff between customizable services and the triple [ease of operation, scalability, investment cost].

> 4over6 solution in CERNET2.

With the customizable service you want, this is clearly a solution.

But this of course doesn't prohibit others providers to prefer more standardized services (for residual IPv4 connectivity across IPv6-only) to privilege ease of operation, scalability, and investment costs.

The tradeoff could then be summarized as:
 +----------------------------+--------------------+-----------------+
 |                            |  Stateful (4over6) | Stateless (4rd) |
 +----------------------------+--------------------+-----------------+
 |    Customizable services   |          +         |        -        |
 | -------------------------- | ------------------ | --------------- |
 |      Ease of operation     |          -         |        +        |
 | -------------------------- | ------------------ | --------------- |
 |         Scalability        |          -         |        +        |
 | -------------------------- | ------------------ | --------------- |
 |       Invetment cost       |          -         |        +        |
 |        minimization        |                    |                 |
 +----------------------------+--------------------+-----------------+
Does this make sense to you?

Regards,
RD

---

From: "Peng Wu" <[email-masked]>
Date: Wed, 6 Apr 2011 21:27:20 +0800

Hi Remi,
please see inlines

------------------				 
Peng Wu
PhD candidate
Department of Computer Science & Technology
Tsinghua University, Beijing, China

-------------------------------------------------------------
From：R閙i_Despr閟
Date：2011-04-06 20:57:34
To：Yong Cui
CC：[email-masked] list; Lee,Yiu
Subject：Re: [Softwires] Questions on: draft-cui-softwire-host-4over6

>But this of course doesn't prohibit others providers to prefer more standardized services (for residual IPv4 connectivity across IPv6-only) to privilege ease of operation, scalability, and investmen…
Depends on what kind of services a provider really wants. The other day at v6ops session this presenter from China Telecom said that the want their IPv4 & IPv6 addressing & routing be separated when provider this kind of IPv4-over-IPv6 service. So, it's still a tradeoff thing rather than standardized/not standardized...
>The tradeoff could then be summarized as:
Well, if we talk about these kinds of pros & cons, keep in mind that 4over6 is an extension of Dual-stack lite, they can be naturally coupled(shared devices & services). So I think the "-" items doesnt't match.

IMHO, theoretically the relationship is like this: 
if don't like address & routing coupling, then stateful(on AFTR). Under this direction, if dedicated v4 address, then 4over6; if stateful address sharing, then DS-lite; if stateless sharing, then some sort of A+P thing;
if can accept address & routing coupling, then stateless. if dedicated v4 address, then 4rd; if address sharing, then 4rd with address multiplexing

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 6 Apr 2011 13:42:33 +0000

Remi,

>The tradeoff could then be summarized as:

This choice of stateful or stateless are not so clear-cut. I guess we all
agree that there are pros and cons in both camps. For example: stateful
would yield better utilization of IPv4 addresses. It also decouples the
IPv4 address from IPv6 address which makes the IPv4 address design a
little easier. Your table is very much favor to stateless, I think this
doesn't capture all the points.

Regards,
Yiu

---

From: Rémi Després <[email-masked]>
Date: Wed, 6 Apr 2011 16:04:14 +0200

Le 6 avr. 2011 à 15:42, Lee, Yiu a écrit :

> would yield better utilization of IPv4 addresses.

Agreed
An additional line showing a + for stateful can cover the point.

> It also decouples the
> little easier.

Partially agreed.
- If all IPv6 customers are given the same number of IPv4 ports, 4rd doesn't imply anything on Pv6 routing.,
- If there are several 4over6 concentrators, there are constraints on the IPv6 routing to ensure satisfactory load sharing between them with stable routes.
- Furthermore, if these concentrators are far from one another, they imply that the IPv4 backbone ensures symmetric routing so that all return traffic from a concentrator comes back to it.

> Your table is very much favor to stateless, I think this

Agreed, at least concerning the first point above.
I view it as a convenient discussion tool.

Regards,
RD

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 6 Apr 2011 19:06:36 +0000

Hi Remi,

On 4/6/11 10:04 AM, "Rémi Després" <[email-masked]> wrote:

>- If there are several 4over6 concentrators, there are constraints on the
>IPv6 routing to ensure satisfactory load sharing between them with stable
>routes.
>- Furthermore, if these concentrators are far from one another, they
>imply that the IPv4 backbone ensures symmetric routing so that all return
>traffic from a concentrator comes back to it.

I think we are on the same page. What I meant is in the case of stateful
6to4, IPv6 address won't contain any IPv4 address in the prefix. That
won't require coupling between the IPv4 and IPv6 prefixes. It may or may
not be a problem for some operators.

LB is a different issue. It doesn't relate to address coupling. That said,
it isn't so straight forward for stateless approach because it depends on
the placement of the BR and the v6 routing to the anycast address.

For stateful 4to6, the outgoing and incoming v4 traffic are symmetric
because all v4 traffic must traverse the concentrator. I don¹t see why the
backbone has to do something special for it.

/Yiu

---

From: Rémi Després <[email-masked]>
Date: Wed, 6 Apr 2011 23:19:44 +0200

Yiu,

I am not sure we completely understand each other here.
Please tell me if what I write is insufficiently clear.

> not be a problem for some operators.

IPv6 prefixes of 6rd don't contain IPv4 embedded addresses (they differ in this respect from the stateless A+P described in the aplusp draft).
With 4rd, if all CE's get IPv6 prefixes having the same length, and are assigned the same number of IPv4 ports, the IPv6 routing is taken as is.
It is only after that that one or a few mapping rules, whose parameters can be advertised in stateless DHCPv6, define how each CE derives its shared IPv4 address and port set from its IPv6 prefix.

> the placement of the BR and the v6 routing to the anycast address.

Routing of the IPv6 network can be reconfigured at any time without breaking connections.
Load balancing can be performed without any concern for packets of each connection having to go to the same BR, which makes it simpler. 

> backbone has to do something special for it.

If there is only one concentrator, no problem.
But if there are several widely separated concentrators, and they are reachable at the same PI prefix at the border between the IPv6-only network and the IPv4 backbone, then there is a return path problem. 

RD

PS: I may be able to continue tomorrow, but then will be unreachable until April 25.

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 6 Apr 2011 22:20:58 +0000

Hi Remi,

I think I mis-read Figure 1 in your draft. As I read this, I think the
current design will completely rely on dhcp to manage the v4 prefix. Yes,
this decouples the v4 and v6 addresses, but this will add additional
operation effort on dhcp. Also, if an ISP has many small IPv4 prefixes
they want to use in 4rd, it will require to provision all of them to the
BR. This may be ok for some operators, but not all operators.

In term of single or multiple 4over6 concentrators, I don't see people
will advertise the same PI from two far away concentrators. So the return
packet will also go back to the same (or close) concentrator. That said, I
agree that stateless is always easier for HA. I have no disagreement on
this.

In the end, they have pros and cons. Based on the ISP's requirements, it
is just a matter of choice.

Cheers,
/Yiu

On 4/6/11 5:19 PM, "Rémi Després" <[email-masked]> wrote:

>IPv6 prefixes of 6rd don't contain IPv4 embedded addresses (they differ
>in this respect from the stateless A+P described in the aplusp draft).
>With 4rd, if all CE's get IPv6 prefixes having the same length, and are
>assigned the same number of IPv4 ports, the IPv6 routing is taken as is.
>It is only after that that one or a few mapping rules, whose parameters
>can be advertised in stateless DHCPv6, define how each CE derives its
>shared IPv4 address and port set from its IPv6 prefix.
>
>Load balancing can be performed without any concern for packets of each
>connection having to go to the same BR, which makes it simpler.
>
>
>But if there are several widely separated concentrators, and they are
>reachable at the same PI prefix at the border between the IPv6-only
>network and the IPv4 backbone, then there is a return path problem.
>
>RD
>

---

From: Rémi Després <[email-masked]>
Date: Thu, 7 Apr 2011 07:18:30 +0200

> is just a matter of choice.

We agree.
Thanks.
RD