Thanks for the comment I picked up the first, which is an obvious typo. Your suggested text changes the last sentence of 5.1 and adds "it's a trade-off". I understand you to be trying to say "NPTv6 is likely to prevent you from running certain applications." I'll point out that the use of NAPT has not prevented folks from running applications; it has made it a lot harder, and they have had to work around the NAPT, but it has meant that they move the applications to zones in their network designed to handle them. NPTv6 allows them to do the same within the privately-addressed parts of their network, which seems like a benefit, and in general if they have both the internal and external addresses of peers and are using "Happy Eyeballs" technology (so that they in fact use whatever address works), the user experience will be the same as a network without translation. So I don't agree that it's as much of a barrier as you seem to think it is.
On Mar 1, 2011, at 11:28 PM, S.P.Zeidler wrote: > Hi, > > chapter 5, dot 5, >>to "outside" the of it,<< surplus the > > in section 5.1 I would not say that the -benefits- are consistent > with the app requirements; the -drawbacks- need to be acceptable for > app requirements instead. How about: > > --- snip --- > In light of the above, network planners considering the use of NPTv6 > translation should carefully consider the kinds of applications that > they will need to run in the future, and determine whether the limitation > on the types of applications that is imposed by using NPTv6 is acceptable, > and will be outweighed by the address stability and provider independence > benefits. It's a trade-off. > --- snip --- > > regards, > spz > -- > [email protected] (S.P.Zeidler) _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
