On Oct 25, 2010, at 9:32 AM, Keith Moore wrote: > > On Oct 25, 2010, at 12:19 PM, Fred Baker wrote: > >> >> On Oct 25, 2010, at 8:42 AM, Chris Engel wrote: >> >>> Regardless, nothing the authors are doing with this flavor of NAT (unless >>> I'm mistaken about it) should break end to end connectivity between devices >>> running IPv6 since it's a 1:1 stateless mapping. A FW with statefull >>> inspection and packet filtering rules would...but in that case the person >>> deploying the FW WANTS that connectivity broken. If you're trying to argue >>> that people should not be allowed to deploy FW's.... well then, good luck >>> with that. >> >> Agreed. Not that there are not issues with prefix translation; there are >> applications and application deployments that make the (for the past 15 >> years indefensible) assumption that an address carried as a literal in an >> application will be meaningful to its peer, and those applications will have >> the same RFC 2993 problems that IPv4 NAT imposes. > > Fred, it's not an indefensible assumption. It's how the Internet was > designed to work. it's the behavior specified by the core Internet protocol > standards.
It also is definitely *not* the way the Internet has been deployed for the past fifteen years. Anyone that puts IPv4 literals into HTTP or SIP/SDP headers *has* to use a global address, or anyone across a NAT can't communicate with them. What I am pointing out, in case you missed it, is that there is also a problem in the transition/coexistence phase with the assumption that just because I speak IPv[46] that you can speak IPv[46] and that there is a reliable route using IPv[46] between us. Putting an IPv[46] literal into an application header is not only stupid because of the coupling implied - that your address space and mine overlap - but because of the coexistence coupling. > Applications need to have a predictable, well-documented environment in which > to operate. Why in the world you think that networks should be able to > violate the standards and that somehow it's the application developers' > responsibility to adapt to whatever random brain damage the network operators > decide to impose is beyond me. But it makes no sense from an engineering > perspective. Perhaps. It is, however, reality. > If there really is a need for NATs in the network (which has not been > established) then it's incumbent for IETF to standardize them in such a way > that applications still have a predictable environment which lets them do > what they need to do (modulo policy). So far, IETF has not done that. What > it has mostly done is fail to provide clear direction. Well, it actually has been established. That's the point the people you are so actively not listening to are trying to make. The need for address translation has nothing to do with topology obfuscation, although that point is frequently brought up; if I can read your SMTP envelopes I can figure out your topology well enough for any nefarious purposes I might have. And it has nothing to do with address amplification, which I suspect is what you're responding to as "unproven". It has to do with the sizes of route tables in the core and the politics of attachment at the edge. If we use the existing prefix allocation policy assumptions, which are built around enumerating the objects at the edge, we wind up with as many routes in the route table as we have objects at the edge. Aggregation of routes, which is what we use to make routing scale in the Internet, simply doesn't exist. Current estimates I see talk about 10^7 routes within 15 years, and in a world of 10^10 people I suspect it's a lot more than that over time. If you want to pay for the silicon, heat, and power, I'll happily sell you the routers, but it turns out that you're talking about a lot of silicon, a lot of heat, and a lot of power, which is to say a lot of money. Transit providers are looking for solutions there. At the edge, there is a huge push for PI addressing. You can say that shim6-or-etc enables the edge networks to be independent of their providers by having a prefix from each of them; the edge networks are voting with their feet in that regard and saying it's not a network they're willing to operate. They want address independence, and they don't want to have to do anything when they change providers. They see PI addressing as the solution. And I will argue that ILNP (which requires every host in the world to be upgraded and therefore is IMHO a non-starter, although as a solution I prefer it) or NAT66 as proposed in this document (which reduces the problem to one of updating CPEs by updating the checksum) handles both issues. The transit networks get to view their route tables as entirely PA, and therefore as having been advertised by O(10^4) ISPs or large corporate networks, and the edge networks get the address independence they desire. That may be "broken" from your perspective, but from the guy-paying-the-money's perspective that is not broken. It is exactly what they are looking for. This is the last note that I will post to this thread. I'm really not interested in further rehashing this. I have a life. _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
