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

From: Ole Troan <[email-masked]>
Date: Wed, 30 Mar 2011 18:55:31 +0200

reading drafts during the plenary post working group session.

1) what does this solution offer that isn't in RFC5571? different encapsulation?
2) host initiated. does this propose to support hosts behind a CPE? how would they then be
   provisioned?

cheers,
Ole

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 30 Mar 2011 21:12:55 +0000

See inline:

>1) what does this solution offer that isn't in RFC5571? different

Similar but there is a major difference. RFC5571 is 6over4 using l2tpv2 to
punch through the NAT. This doesn't need this requirement, so l2tpv2 isn't
needed. 

>2) host initiated. does this propose to support hosts behind a CPE? how

The idea is the CPE will be the dhcp relay agent which will relay the dhcp
requests from the hosts behind the CPE to the dhcp server. That said,
there are details we need to sort out such as the CPE must be also
provisioned an ipv4 address from the same subnet to support hair-pinning.
Also the servers behind the CPE are normal servers, we need to detail
how/when to create the binding in the NAT table so that it won't require
the servers to send keepalive to the TC.

Regards,
Yiu

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Mar 2011 20:12:45 +1300

Terminology alert:

> Similar but there is a major difference. RFC5571 is 6over4 using l2tpv2 to

No, RFC 2529 defines "6over4". Please don't create confusion by using
"6over4" to mean anything except RFC 2529.

    Brian

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 31 Mar 2011 07:16:47 +0000

Thanks Brain for the alert. RFC5571 is a hub-and-spoke architecture using
6over4overl2tpv2 where 4over6 doesn't need the l2tpv2 encap.

/Yiu

---

From: Ole Troan <[email-masked]>
Date: Thu, 31 Mar 2011 09:29:00 +0200

Yiu,

> punch through the NAT. This doesn't need this requirement, so l2tpv2 isn't

RFC5571 specifies both IPv4 over IPv6 and IPv6 over IPv4.
so the difference with this draft is that you rather want RFC2473 encapsulation rather than PPP/UDP?

the main argument for choosing L2TP in the first place, was that all the infrastructure was available, including LNSes, LAC implementations and backend AAA infrastructure.

doesn't this argument still hold for the hub and spoke case?

the main short-coming of the RFC5571 as I see it is the lack of provisioning... if we fixed that would 5571 be more palatable as a solution?

> the servers to send keepalive to the TC.

the Basic IPv6 CE draft (to be RFC6204) only suggest to pass across some well known options from the WAN side DHCP client to the LAN side DHCP server. perhaps you would suggest new text to the Advanced CE draft suggesting that all unknown stateless DHCP option should be passed across?

cheers,
Ole

---

From: Yong Cui <[email-masked]>
Date: Thu, 31 Mar 2011 15:42:12 +0800

Ole,

-----Original Message-----
>the main argument for choosing L2TP in the first place, was that all the
>infrastructure was available, including LNSes, LAC implementations and
>backend AAA infrastructure.
>
>the main short-coming of the RFC5571 as I see it is the lack of
>provisioning... if we fixed that would 5571 be more palatable as a
>solution?

At least from the thousands of campus networks, we don't use L2TP.
So we need IPv4 over native IPv6 in this case.

Yong

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 31 Mar 2011 07:48:36 +0000

Hi Ole,

But there is no NAT hole punching is involved, why use l2tp instead of
stateless IPv4-in-IPv6?

/Yiu

On 3/31/11 3:29 AM, "Ole Troan" <[email-masked]> wrote:

>the Basic IPv6 CE draft (to be RFC6204) only suggest to pass across some
>well known options from the WAN side DHCP client to the LAN side DHCP
>server. perhaps you would suggest new text to the Advanced CE draft
>suggesting that all unknown stateless DHCP option should be passed across?
>
>cheers,
>Ole
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 31 Mar 2011 10:11:32 +0200

Lee,

> But there is no NAT hole punching is involved, why use l2tp instead of

well, only because it is there, implemented and deployable.

I missed that 4over6 is stateless, I thought it was the equivalent of a configured IPv4 over IPv6 tunnel?

cheers,
Ole

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 31 Mar 2011 08:23:16 +0000

Ole,

The way to set up the tunnel is similar to ds-lite. The CPE will learn the
TC's v6 address, then encap v4 packets into v6 to the TC. To create the
v4-v6 mapping in the TC's routing table. This could be done by the TC to
look at the dhcp message or by keepalive packets from the cpe. We haven't
decided which way is preferred. But the tunnel itself is stateless.

Cheers,
/Y

On 3/31/11 4:11 AM, "Ole Troan" <[email-masked]> wrote:

>>>> Similar but there is a major difference. RFC5571 is 6over4 using
>>>>l2tpv2
>>>> to
>>>>> 2) host initiated. does this propose to support hosts behind a CPE?
>>>>>how
>>>>> would they then be
>>>>> provisioned?
>>>>

---

From: Ole Troan <[email-masked]>
Date: Thu, 31 Mar 2011 10:37:39 +0200

Yiu,

> decided which way is preferred. But the tunnel itself is stateless.

since we have tended to classify mechanisms into 'stateless' and 'stateful'. I think we need a common understanding of what mean by these terms.

simply stated, if the mechanism scales by the number of subscribers/tunnels then it is stateful. if it scales by the amount of packets/traffic then it is stateless.

if you agree with that definition I would think 4over6 is stateful, since it suggests to integrate the tunnel state into the RIB. i.e. you allocate a piece of memory per subscriber and you have to snoop on DHCP messages to refresh this state.

cheers,
Ole

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 31 Mar 2011 08:41:08 +0000

Ok. I agree with your definition. How about I rephrase it that dslite and
4over6 don't require control channel. RFC5571 requires control channel.
Can we agree that control channel requires extra overhead?

Cheers,
/Yiu

On 3/31/11 4:37 AM, "Ole Troan" <[email-masked]> wrote:

>since we have tended to classify mechanisms into 'stateless' and
>'stateful'. I think we need a common understanding of what mean by these
>terms.
>
>simply stated, if the mechanism scales by the number of
>subscribers/tunnels then it is stateful. if it scales by the amount of
>packets/traffic then it is stateless.
>
>if you agree with that definition I would think 4over6 is stateful, since
>it suggests to integrate the tunnel state into the RIB. i.e. you allocate
>a piece of memory per subscriber and you have to snoop on DHCP messages
>to refresh this state.
>
>cheers,
>Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 31 Mar 2011 10:44:36 +0200

Yiu,

> Can we agree that control channel requires extra overhead?

absolutely. both encapsulation and signalling overhead.

that does come with some benefits though, e.g. you can do authentication and so on.

cheers,
Ole

---

From: "Peng Wu" <[email-masked]>
Date: Thu, 31 Mar 2011 16:57:35 +0800

jump in here:)
So I think we can agree they have different use cases/application scenarios.
Refer to Yong's example again, in CERNET user access(IPv4 & IPv6) is based on Ethernet, pure-IP. Authentication is done through other way. We do want to keep that. 
------------------				 
Peng Wu
PhD candidate
Department of Computer Science & Technology
Tsinghua University, Beijing, China

-------------------------------------------------------------
From：Ole Troan
Date：2011-03-31 16:46:06
To：Lee, Yiu
CC：[email-masked] list
Subject：Re: [Softwires] Questions on: draft-cui-softwire-host-4over6

Yiu,

cheers,
Ole

---

From: Yong Cui <[email-masked]>
Date: Fri, 01 Apr 2011 05:55:31 +0800

Ole, 

The IPv4/IPv6 address mapping is stateful, which is the almost same as
DS-Lite does on address/port mapping, but simpler (i.e. Without port
mapping). 

Although L3TP is an important tunneling method, do you think IP-IP tunnels
are still widely used, including softwire mesh, DS-Lite, 6RD...? In order
to keep the simplicity, we really hope to use IP-IP tunnels in the
networks.

Yong

---

From: Mark Townsley <[email-masked]>
Date: Fri, 1 Apr 2011 07:17:04 +0200

> to keep the simplicity, we really hope to use IP-IP tunnels in the

L2TP tunnels are absolutely in use today. 

- Mark