On 12/3/12 4:55 AM, "[email protected]" <[email protected]> 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: > >(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). 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 > > >>-----Message d'origine----- >>De : Ole Trøan [mailto:[email protected]] >>Envoyé : vendredi 30 novembre 2012 20:36 >>À : BOUCADAIR Mohamed OLNC/OLN >>Cc : Simon Perreault; [email protected] >>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 >[email protected] >https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
