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

[<[e-mail]>]

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:[e-mail]] 
>Envoyé : vendredi 30 novembre 2012 20:36
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : Simon Perreault; [e-mail]
>Objet : Re: [Softwires] Unified Softwire CPE: 
>draft-bfmk-softwire-unified-cpe
>
>Med, et al,
>
>> 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.
>
>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?
>
>cheers,
>Ole
>
>
>