So, I choose MAP. > the alternatives we have are perfectly fine: > - Shared IPv4 address over IPv4 transport -> NAT444 / CGN > - Shared IPv4 address over IPv6 transport -> 464XLAT / DS-lite > - Full IPv4 address over IPv6 transport -> DS-lite with Public IPv4 address
Otherwise, I'm tempted to do the above, if the wg decide to choose 4rd-u. As an operator, the 4rd-u scares us too much since no experience of 4rd-u's new unified tunneling in our circumstance at this time. Sorry, Remi-san. I really respect you, but I can't decide to do 4rd-u in our real production network. cheers, --satoru On 2012/04/02, at 19:33, Ole Trøan wrote: >> If this is to say that until a BOF is started, you will keep your >> objection(s) unknown, I continue to take it as a lack of identified >> objections. > > the objections I'm aware of are: > - people are uncomfortable with only a double translation solution > * injection of IPv4 routes into IPv6 > * transparency > * hard to identify IPv4 traffic in the "core" > * higher risk of leakage. i.e single translation / packets outside the > domain > (all these apply equally to MAP-T btw) > - redefining the modified EUI-64 format (V-octet) and the consequences > standardization wise of that > - overloading information in the fragment header > > (please don't respond to these, FYI only. I'm on Easter holiday.) > > if it wasn't for my general "uncomfortableness" with double-translation I'd > could be convinced that a single solution was possible. > > the status quo; with no path forward just means that we'll effectively kill > A+P. > I would certainly not recommend my product managers to implement either of > this given the risk. > is there consensus to abandon these efforts (which is basically what we do by > publishing them as experimental anyway)? > > the alternatives we have are perfectly fine: > - Shared IPv4 address over IPv4 transport -> NAT444 / CGN > - Shared IPv4 address over IPv6 transport -> 464XLAT / DS-lite > - Full IPv4 address over IPv6 transport -> DS-lite with Public IPv4 address > > problem solved. ;-) > > cheers, > Ole > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
