I like it. Nice and clean diagram. I believe NAT64 & 'provision of additional IP address and port ranges' should be 'yes'. NAT64 uses a IPv4 NAT pool much like NAT444 and needs to support all the bells and whistles...APP, EIM, HP, PB, etc
Same goes for " Requirements for provision of additional IPv4 addresses and port ranges" and "NAT64". I believe it should be 'none' since it is automatic. Thanks, Reinaldo On 8/11/11 1:00 PM, "Nejc Škoberne" <[email protected]> wrote: > Hello all, > > I am working on a trade-off analysis of IPv4 address sharing mechanisms. I am > replying to Remi's e-mail (sent before I subscribed to the list): > >> I therefore worked out a way to present the range of solutions to be >> compared, >> with the following taken in consideration: >> - The stateless/stateful IPv4 across IPv6 comparison isn't limited to IPv4 >> shared addresses (applies also to exclusive IPv4 customer addresses). >> - If there is, in BR/AFBR's, no Customer state (i.e. no states referring to >> individual IPv6 prefixes), there can't be per-transport-connection state >> either. >> - CE-CE direct paths are possible only if IPv4/IPv6 mappings of BR/AFBR's >> don't >> depend on Customer state. >> >> The proposed document structure is as follows, with pros and cons for each >> section: >> a) Stateful per transport connection (and also stateful per customer IPv6 >> prefix) >> e.g. DS-lite with CGN >> b) Stateful per customer IPv6 prefix (but Stateless per transport connection) >> e.g. draft-cui-softwire-host-4over6-06 >> c) Stateless per customer IPv6 prefix (and also stateless per transport >> connection) >> - Hub-an-spoke >> TBD >> - Direct CE-CE paths (mesh) >> . Encapsulation based >> e.g. draft-murakami-softwire-4rd-00 alias >> . Translation based >> e.g. draft-murakami-softwire-4v6-translation-00 > > I think we really need such a comparison document. As a newcomer I spent a lot > of time digging up all the scattered documents here and it wasn't easy grasp > the > "big picture" of what has been proposed. I think we also need a trade-off > analysis > document, which I am writing at the moment. > > Anyway, I am not sure I agree with the structure suggested. I think we should > try > to be even more general and try to abstract all packet manipulations. I have > prepared > a table which tries to document all so-far implemented combinations (IPv4 > address sharing > mechanisms + 4via6 mechanisms, the intersection includes all but NAT444, which > is > only IPv4 address sharing mechanism and Public 4over6 which is only a 4via6 > mechanism). > It would be useful to know if any of the missing combinations might be useful > in > practice as well, I hope this table will help in determining that. > > I will be very happy to hear any comments on the comparison. It's only a > 1-page table. > > The PDF document: http://nejc.skoberne.net/transfer/mechanisms.pdf > > Thanks, > Nejc > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
