Hi Ole, In your previous Email you wrote, > in MAP you do all of that with one single DHCPv6 option...
IMHO, that's because the one DHCPv6 option contains so many KINDS of information (e.g. PSID, BR's prefix or address, see draft of map-dhcp-option ). And with separate provisoning processes , it's easier to detect problems if the whole process fails. Best Regards! Qi Sun On 6/8/12, Ole Trøan <[email protected]> wrote: > Peng, > >> Now there are actually 3 directions for IPv4-over-IPv6 mechanisms, >> they have respective application scenarios, pros and cons. >> 1)stateless, 4rd, MAP >> 2)per-flow stateful: DS-Lite >> 3)per-user stateful: public 4over6, lightweight 4over6 >> As Ole said, the problem is that, do we want serveral simple >> mechanisms, or one super-compatible mechanism with different modes. >> >> Now Given that a) the WG has accomplished DS-lite; b)MAP follows the >> stateless motivation all along the way; c)The signifcant changes to >> make MAP super-compatible, I vote for we define the third type, >> per-user stateful mechanisms independently. > > actually there are no significant changes to the MAP specification, the > per-user stateful mechanism is just intrinsically supported by MAP. it is a > corner case, and it would be more work in the specification to "ban" this > operational mode, than to support it. > > btw, one thing that appears most complicated is provisioning; currently it > looks like L4over6 suggests using 2 DHCP sessions and 3 DHCP options to get > provisioned. firstly a RFC6334 exchange to get the DS-lite tunnel up, then a > DHCPv6 option for the DHCPv4 server address, and then a DHCPv4 exchange to > get the IPv4 address, and then a new DHCPv4 option to get the port set. that > seems to me to be quite a few moving parts, and quiet a few corner cases to > be specified when one or more of the above fails. in MAP you do all of that > with one single DHCPv6 option... > > 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
