On Tue, Apr 10, 2012 at 10:29 PM, Maoke <[email protected]> wrote: > hi Yiu, > > sorry but i just found i missed a technical issue you left in this message. > > 2012/4/9 Lee, Yiu <[email protected]> > >> >> on the other hand, 4rd-u makes a tight coupling between the address >> format >> and its own header mapping mechanism. this makes an operator unable to >> have >> different choices of transition mechanism as long as it chooses 4rd-u. >> if >> you concern the choice of IPv6 transition mechanism, i do recommend >> MAP, as >> either encapsulation or translation is operatable with MAP >> address/port >> mapping without difficulty. >> >> [YL] Sorry for my lack of knowledge. Please explain how MAP isn't coupling >> address format and header mapping? > > > tight coupling here, i mean, that 4rd-u header mapping mechanism sometimes > depends on features of the address format, like the CNP and the V-octet. for > example, it removes the L4 checksum adjustment, this makes the whole system > MUST following the addressing with CNP. > > for the MAP, things are different. boxes are implemented with existing > header processing modules but only need to add MAP address mapping module > into them. once the operator deploys MAP following its addressing plan > paradigm (we are still working on a better guidance for this in the MAP > deployment draft), the operator can choose either MAP-T or MAP-E for the > header mapping without the need of changing their addressing plan. if the > operator find translation is suitable for this part after a certain period > of practice on encapsulation, it can switch the mode by informing the CE to > change the mode of working (surely sometimes such an action of informing is > not easy in practice for, e.g., the home CE subscribers but it is feasible > for enterprise networking). another example of de-coupling is translation > approach: RFC6052 defines a stateless address mapping while RFC6145 defines > the header processing which is usable for both stateless and stateful > solutions, both 1:1 case for non-renumbering transition and residual > deployment of MAP. > > implementation does also benefit from the de-coupling. the RFC6145 > translation module can directly work with address mapping module of MAP or > RFC6052. the MAP address module can work with header processing module of > RFC2473 (for MAP-E) or translation module of RFC6145 (for MAP-T). > > it doesn't mean the tight coupling doesn't work. like the Burton snowboard, > it works fantastically with its own system of bindings, not interchangable > for other brands ;-) however, in most of time, we really think > interchangability, supported by loose coupling, is preferred. >
I fail to understand why there is so much hype around these standards, 6145 is the good old SIIT 6052 defines NAT64 prefixes. Behcet _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
