Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

From: Ole Trøan <[email-masked]>
Date: Sat, 1 Dec 2012 09:44:54 +0100

Qiong,

> [Qiong] and a sub-mode for "source IPv6 address determiniation", how to determine the encapsulated IPv6 source address.
> 1) algorithmic, LAN prefix + embedded IPv4 address/PSID in Interface Identifier (MAP) 
> 2) WAN IPv6 address (DS-Lite, LW46, Public 4over6)
>  
> Right ?

MAP could also create its tunnel endpoint address from the WAN prefix (not address).
so you'd have, for CPE tunnel end point address:

1) arbitrary IPv6 address (DS-lite)
2) WAN IPv6 address (DS-lite, LW46, Public 4over6)
3) Algorithmic End-user IPv6 prefix + Well known interface-id (MAP)

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Sat, 1 Dec 2012 09:47:48 +0100

Simon,

>>> Med: The rationale we adopted in this draft is as follows:
>>> 
>>> * there are three major flavors: full stateful, full stateless, and binding mode
>>> * all these modes can support assigning a full or a shared IPv4 address
>> 
>> now you got me thinking, are these really the right modes from a CPE perspective?
>> 
>> let me try to explain, with my CPE implementor hat on, what "modes" would make sense?
>> 
>> - NAT placement. do I need a NAT on the CPE or not?
>>   (no NAT && no IPv4 address == DS-lite)
>> - full IPv4 address assigned.
>>   I can assign the IPv4 address to the tunnel endpoint interface, and use that address for
>>   local applications, and as the outbound address of the NAT
>>   (mechanisms: MAP, Public 4over6)
>> - IPv4 prefix assigned:
>>   I need to disable the CPE NAT, and use the assigned IPv4 prefix as my LAN side DHCPv4 pool
>>   (mechanism: MAP)
>> - Shared IPv4 address.
>>   I must enable a local NAT, I cannot assign the IPv4 address on the "WAN" interface, but only use it
>>   for the outbound side of the NAT.
> 
> Interesting... But note that even just implementing MAP alone would generate three of these "implementation modes". I would still like to see this list added to an "implementation considerations" section. Stuff like "you can't assign a partial address to a tunnel interface" may not be obvious to implementers.
> 
>> then there might be a sub-modes for "tunnel endpoint determination" i.e. how to determine an IPv6 tunnel end point address given an IPv4 destination address and port.
>> 1) algorithmic (MAP)
>> 2) configured (Public 4over6, LW46, DS-lite)
>> 
>> and a sub-mode for IPv4 address configuration:
>> 1) As "native IPv4"
>>     (Public4over6, LW46)
>> 2) Embedded Address
>>     (MAP)
>> 3) None
>>    DS-lite
>> 
>> does this make sense?
> 
> Totally appropriate for an "implementation considerations" section IMHO.

I'm suggesting to replace the current drafts "state*, binding modes" with these modes.

cheers,
Ole

---

From: Qiong <[email-masked]>
Date: Sat, 1 Dec 2012 17:08:49 +0800

Ole,

On Sat, Dec 1, 2012 at 4:44 PM, Ole Trøan <[email-masked]> wrote:

> Qiong,
>
> > [Qiong] and a sub-mode for "source IPv6 address determiniation", how to
> determine the encapsulated IPv6 source address.
Thanks for clarification. But if MAP uses the WAN prefix as its tunnel
endpoint address, does BR need to keep all the records for CPEs (because
the CPE's WAN prefix might be arbitary) ? Or do you mean the CPE's WAN
prefix will be embedded with EA bits ? Would you please explain it a bit
more ?

> 1) arbitrary IPv6 address (DS-lite)
Why it is arbitary ? Is it the source address of the tunnel endpoint ?

Thanks
Qiong

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: Ole Trøan <[email-masked]>
Date: Sat, 1 Dec 2012 13:11:16 +0100

Qiong,

[...]

> Thanks for clarification. But if MAP uses the WAN prefix as its tunnel endpoint address, does BR need to keep all the records for CPEs (because the CPE's WAN prefix might be arbitary) ? Or do you mean the CPE's WAN prefix will be embedded with EA bits ? Would you please explain it a bit more ?  

from MAP's perspective it doesn't matter if it is a /64 on the WAN or a /56 delegated prefix.
any prefix can have EA bits.

> Why it is arbitary ? Is it the source address of the tunnel endpoint ?

in DS-lite the tunnel concentrator learns the tunnel endpoint address when the NAT bindings are created.
so the CPE is free to pick whatever IPv6 address it has. this is different from Public 4over6 and LW46 where the
address has to be configured on both ends.

cheers,
Ole

---

From: Qiong <[email-masked]>
Date: Sun, 2 Dec 2012 10:54:17 +0800

Hi Ole,

Please see inline ~~

> any prefix can have EA bits.
[Qiong] In theory, right. But I think it still have several issues here:
1) The /64 WAN prefix or a /56 delegated prefix does not have a flag saying
"hey, I'm the one with EA bits". Then, how can a CPE choose which prefix to
extract the EA bits ? Or do you need another configuration flag to indicate
which prefix to embed to EA bits?
2) Some operators have adpoted stateful DHCPv6 on the WAN interface. In
that case, multiple CPEs can be within the same /64 prefix in the WAN side
with different last 64 bits. However, if EA bits is embedded in the WAN
prefix, it will have extra impact on operators' addressing model, consuming
more address. And also it seems difficult to configure non-contiguous
addresses in DHCPv6 server for stateful dhcpv6 mode(configure a lot of
pools with different /64 prefix?).

And if I remember correctly, when dIVI-pd came out, it said clearly that it
was designed for delegated prefix. I thought it was the original intension
of current stateless solutions (please correct me if I'm wrong). And I do
suggest to simplify the implementation, rather than leaving too much
flexibility and increase the complexity.

> so the CPE is free to pick whatever IPv6 address it has. this is different
> from Public 4over6 and LW46

[Qiong] In theory, right. But still, I have a few comments on it:
1) In DS-Lite, the operator may apply source address filtering for security
consideration. Currently, we are applying the acl using WAN address. The
arbitrary IPv6 address may lead this address filtering fail.
2) Even in DS-Lite, operators may adopt bulk port allocation for each
subscriber (each subscriber will be reserved a port-set in AFTR when the
first packet creates the NAT binding). If the CPE arbitrary chooses
different IPv6 address, this port-set reservation can not work neither...
3) Current DS-Lite CPEs all choose the WAN address as the tunnel endpoint,
which is simple and easy to manage.

 where the
> address has to be configured on both ends.
[Qiong] Lw4o6 and public 4over6 can also use arbitary address if the lwAFTR
does not do source address filtering/validation . The upstream packet only
needs be decapsulated and the downstream packet can find the matching
tunnel endpoint address using public v4 address and port. But still, for
management and security reasons, I still suggest to use the WAN address as
the tunnel endpoint address.

Best wishes
Qiong

Open source code:

---

From: <[email-masked]>
Date: Sun, 2 Dec 2012 15:15:46 +0100

Hi Ole,

Whichever state is selected, NAT is certainly fundamental to how the state will operate and so we tried to weave it into the functional description. I'm not sure that provisioned NAT info enough to be able to use to unambiguously define with operating 'mode' (for want of a better word) to use.

One of the reasons for the use of state in the draft is try and define the operating modes with as little overlap as possible (it's not 100%, but there's only 1 exception at the moment for binding mode and MAP1:1). From this, then it is easier to align the specific solution names to the state characteristics.

But, with what you've suggested, there is more overlap, i.e. both 2&4 have NAT functions that are supported by two different mechanisms.

However, what you've said does raise the following point:

The way that state is described in the draft at the moment is actually taken from a concentrator perspective. This could be taken to be almost the inverse of the amount of state that is required from the CPEs perspective (i.e. if all of the state is in the providers network (DS-Lite), then the CPE doesn't need it. If the providers network has less state ('per-customer', 'stateless'), then the CPE needs to have more - i.e. dynamic state table for NAT, configuration for local IPv4/port set, MAPing rules etc.

Would describing the different states more from the CPE's perspective make this clearer?

Cheers,
Ian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Trøan
Sent: Samstag, 1. Dezember 2012 09:48
To: Simon Perreault
Cc: [email-masked]
Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

Simon,

cheers,
Ole

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

---

From: Ole Trøan <[email-masked]>
Date: Mon, 3 Dec 2012 10:03:42 +0100

Qiong,

> 1) The /64 WAN prefix or a /56 delegated prefix does not have a flag saying "hey, I'm the one with EA bits". Then, how can a CPE choose which prefix to extract the EA bits ? Or do you need another configuration flag to indicate which prefix to embed to EA bits?

from the draft:
   "A MAP node finds its Basic Mapping Rule by doing a longest match
   between the End-user IPv6 prefix and the Rule IPv6 prefix in the
   Mapping Rules table.  The rule is then used for IPv4 prefix, address
   or shared address assignment."

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Mon, 3 Dec 2012 10:06:28 +0100

Ian,

> One of the reasons for the use of state in the draft is try and define the operating modes with as little overlap as possible (it's not 100%, but there's only 1 exception at the moment for binding…

I don't think you should try to define modes such that the map (no pun intended) into the specific solution names.
shouldn't the purpose of a "unified CPE", be for the CPE not to have to care about the different "deployment modes" on the head end?

> Would describing the different states more from the CPE's perspective make this clearer?

that would certainly help. although I don't think "state" is the defining characteristic.

cheers,
Ole

---

From: <[email-masked]>
Date: Mon, 3 Dec 2012 10:55:28 +0100

Hi Ole,

As a background, the usual modes supported by a CPE are: IPv4-only, Dual-stack. A natural mode to be added to the list is IPv6-only ... but this mode is not sufficient to reflect whether IPv4 service continuity features are enabled in the CPE or not. This draft focuses on this service: i.e., IPv4 service continuity when only an IPv6 prefix is configured to the CPE. 

Now for the items you listed below, I do not see them as "modes" but as a set of actions to be enforced based on some trigger(s). The combination of the actions listed below will result in a "mode". 

The CPE will need some trigger(s) to decide which modules are to be mounted (e.g., NAT, port restriction, etc.) and how some configuration will be enforced (e.g., IPv6@ of the local IPv4-in-IPv6 tunnel, IPv4 address, etc.). Several cases are to be considered:

(1) a CPE is complied to support only one mode: no issue here.
(2) a CPE supports several modes but only one mode is explicitly configured: once a mode is enabled, the behaviour of the CPE is similar to (1)
(3) the CPE supports several modes but no mode is explicitly enabled: the CPE will need additional triggers to decide which mode to activate (e.g., If only a Remote IPv4-in-IPv6 Tunnel Endpoint is configured, this means the stateful mode must be enabled). A mode is defined as a set of actions (mount a module, configuration actions). 

The list of actions you provided needs to be captured somehow in the draft. I will double check the text and see whether any item is missing in -00.

Thanks. 

Cheers,
Med

>-----Message d'origine-----
>De : Ole Trøan [mailto:[email-masked]] 
>Envoyé : vendredi 30 novembre 2012 20:36
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : Simon Perreault; [email-masked]
>Objet : Re: [Softwires] Unified Softwire CPE: 
>draft-bfmk-softwire-unified-cpe
>
>Med, et al,
>
>then there might be a sub-modes for "tunnel endpoint 
>determination" i.e. how to determine an IPv6 tunnel end point 
>address given an IPv4 destination address and port.
>1) algorithmic (MAP)

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Mon, 3 Dec 2012 12:02:56 +0000

On 12/3/12 4:55 AM, "[email-masked]"
<[email-masked]> wrote:

>Hi Ole,
>
>As a background, the usual modes supported by a CPE are: IPv4-only,
>Dual-stack. A natural mode to be added to the list is IPv6-only ... but
>this mode is not sufficient to reflect whether IPv4 service continuity
>features are enabled in the CPE or not. This draft focuses on this
>service: i.e., IPv4 service continuity when only an IPv6 prefix is
>configured to the CPE.
>
>Now for the items you listed below, I do not see them as "modes" but as a
>set of actions to be enforced based on some trigger(s). The combination
>of the actions listed below will result in a "mode".
>
>The CPE will need some trigger(s) to decide which modules are to be
>mounted (e.g., NAT, port restriction, etc.) and how some configuration
>will be enforced (e.g., IPv6@ of the local IPv4-in-IPv6 tunnel, IPv4
>address, etc.). Several cases are to be considered:
>
>(2) a CPE supports several modes but only one mode is explicitly
>configured: once a mode is enabled, the behaviour of the CPE is similar
>to (1)
>(3) the CPE supports several modes but no mode is explicitly enabled: the
>CPE will need additional triggers to decide which mode to activate (e.g.,
>If only a Remote IPv4-in-IPv6 Tunnel Endpoint is configured, this means
>the stateful mode must be enabled). A mode is defined as a set of actions
>(mount a module, configuration actions).

To make this list complete,
#4 should be CPE supports several modes and several modes are configured.

Thanks
Senthil
>
>The list of actions you provided needs to be captured somehow in the
>draft. I will double check the text and see whether any item is missing
>in -00.
>
>Thanks. 
>
>Cheers,
>Med
> 
>

---

From: Qi Sun <[email-masked]>
Date: Mon, 3 Dec 2012 21:13:22 +0800

Ole,

> shouldn't the purpose of a "unified CPE", be for the CPE not to have to care about the different "deployment modes" on the head end?

[Qi] I think the modes are "functional modes" rather than "deployment modes". CPE has different functional characteristics under different modes and it has to know what behavior it should perform under different mode. 

> that would certainly help. although I don't think "state" is the defining characteristic.

[Qi] IMHO, using state as the defining characteristic, the CPE can determine which module to mount and which functionality to perform.

Best Regards,
Qi

---

From: <[email-masked]>
Date: Tue, 4 Dec 2012 18:53:03 +0100

Hi Ole,

Answers inline.

Cheers,
Ian

-----Original Message-----
From: Ole Trøan [mailto:[email-masked]] 
Sent: Montag, 3. Dezember 2012 10:06
To: Farrer, Ian
Cc: [email-masked]; [email-masked]
Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

Ian,

Ian: But a MAP CPE does have to care about what is on the tunnel head end as it could be another mesh client, or it could be the BR. It uses a different mapping rule type for each, so it is aware of the capabilities of the head end.

Ian: Is the problem with the what's being described (i.e. the content and functional differentiations) or the naming and terminology used to describe it?

cheers,
Ole

---

From: Tina TSOU <[email-masked]>
Date: Wed, 5 Dec 2012 18:34:23 +0000

Dear Med, Ian and Suresh,
Great job! Draft-bfmk is written very well to reach consensus.
Two small comments are below.

1.      I’m not sure whether it is appropriate to put DS-Lite case into the document, since in DS-Lite case the CPE is only the tunnel end point without NAT, which is basically different with lw4over6/MAP. But if the objective of this document is to define an unified CPE for all the 4over6 mechanisms, other mechanisms like public 4over6 should also be included in the document. My understanding may be wrong.

2.      The title says “unified softwire CPE”, but in softwire, there are many other transition technologies, e.g., 6rd. To be specific, maybe 4over6 CPE is more appropriate.

Thank you,
Tina

On Dec 4, 2012, at 9:53 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ole,

Answers inline.

Cheers,
Ian

-----Original Message-----
From: Ole Trøan [mailto:[email-masked]]
Sent: Montag, 3. Dezember 2012 10:06
To: Farrer, Ian
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

Ian,

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

---

From: <[email-masked]>
Date: Thu, 6 Dec 2012 07:35:33 +0100

Hi Tina,

Many thanks for the comments. Some clarifications below:

* DS-Lite is included in the scope for the reasons detailed in the draft (see Section 1.1):

   (2)  Simplify solution migration paths: Define a unified CPE behavior
        which allows for smooth migration between the different modes
and

   (4)  Re-usability: Maximize the re-use of existing functional blocks
        including Tunnel Endpoint, port restricted NAPT44, Forwarding
        behavior, etc.

* Public 4over6 is already included in the draft:

   (2)  Binding approach (e.g., Lightweight 4over6 (Lw4o6)
        [I-D.cui-softwire-b4-translated-ds-lite<http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00#ref-I-D.cui-softwire-b4-translated-ds-lite>],
        [I-D.ietf-softwire-public-4over6<http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00#ref-I-D.ietf-softwire-public-4over6>] or MAP 1:1
        [I-D.ietf-softwire-map<http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00#ref-I-D.ietf-softwire-map>] ): Requires a single per-subscriber
        state (or a few) to be maintained in the Service Provider's
        network.

* I agree with you the title should be updated to reflect the scope of the draft. The proposed scope is IPv4 service continuity over IPv6 mechanisms.

Cheers,
Med

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Tina TSOU
Envoyé : mercredi 5 décembre 2012 19:34
À : [email-masked]
Cc : [email-masked]
Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

1.      I'm not sure whether it is appropriate to put DS-Lite case into the document, since in DS-Lite case the CPE is only the tunnel end point without NAT, which is basically different with lw4over6/MAP. But if the objective of this document is to define an unified CPE for all the 4over6 mechanisms, other mechanisms like public 4over6 should also be included in the document. My understanding may be wrong.

2.      The title says "unified softwire CPE", but in softwire, there are many other transition technologies, e.g., 6rd. To be specific, maybe 4over6 CPE is more appropriate.

Thank you,
Tina

Hi Ole,

Answers inline.

Cheers,
Ian

-----Original Message-----
From: Ole Trøan [mailto:[email-masked]]
Sent: Montag, 3. Dezember 2012 10:06
To: Farrer, Ian
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

Ian,

cheers,
Ole

---

From: Qi Sun <[email-masked]>
Date: Fri, 14 Dec 2012 11:06:48 +0800

Dear authors,

Thank you for your hard work! I think we are trying to move forward. 

I have some comments on the provisioning method.

In the section 4.4 that there is a new sub-option OPTION_MAP_BIND. It is the sub-option of OPTION_MAP (OPTION_SW) used to convey an IPv4 address. Considering OPTION_MAP (OPTION_SW) is a DHCPv6 option, it is a little confusing that we are going to use DHCPv6 for IPv4 resources allocation. IMHO, this should be the decision of DHC WG, which hasn't published the outcome of this issue.

Is it possible that we make this part clearer?

Best Regards,
Qi

On 2012-12-6, at 下午2:35, <[email-masked]> <[email-masked]> wrote:

>         [I-D.cui-softwire-b4-translated-ds-lite],
>         [I-D.ietf-softwire-public-4over6] or MAP 1:1
>         [I-D.ietf-softwire-map] ): Requires a single per-subscriber
> On Dec 4, 2012, at 9:53 AM, "[email-masked]" <[email-masked]> wrote:
> 
>> Hi Ole,
>> 
>> Answers inline.
>> 
>> Cheers,
>> Ian
>>