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:otr...@employees.org] >Envoyé : vendredi 30 novembre 2012 20:36 >À : BOUCADAIR Mohamed OLNC/OLN >Cc : Simon Perreault; softwires@ietf.org >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 > > > _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
