On Jan 27, 2009, at 10:11 PM, Tony Hain wrote:
It looks like the only cure for this nat66 nonsense is to mandate AH everywhere...

In which case we will once again find out just exactly how much power a statement by the IETF requiring network administrators to do something has. All point to point interfaces default to PPP, right?

Every implementation where the network presumes omniscient knowledge about what the end user intended is inherently broken. GSE is not only doing that, it is saying that 'it doesn't matter what the end user wanted, the network admin for the router currently holding the packet gets to do whatever they want to the header'. There will be no way to diagnose what is going on, because every packet could take a very different path as each hop along the way distorts reality with its own nat66 policy, which might include load-balancing.

I understand your viewpoint. That is in fact part of why I specified the BUPT prototyping effort the way I did - to force a worst case oscillation in addressing and drive the test crazy.

    ftp://ftpeng.cisco.com/fred/gse/nat66-gse.html

That said, I rather strongly suspect that your view of the end user doesn't work in the Internet even without NATs. Let's imagine that one has two addresses and a target system/service has one addresses, and both ends are using shim6. Let's further assume that the two systems are respectively in Singapore and Canberra, and that the two ISPs in Singapore have different contracts with the ISP in Canberra; one routing traffic directly, and the other via an intermediate Tier 1. Yes, I'm referring to the little routing test Geoff conducted and reported to the IAB perhaps ten years ago. By choice of address pair, one had the opportunity of using an 80 ms RTT or one that was over 600 ms. And let's note that since these are three different ISPs with three different prefixes, no static rule on source or destination address choice can be guaranteed to work.

What is the user's intention? I will give strong odds that it is to "access the peer machine for some particular transaction in the manner that completes the transaction in the least wall clock time". It might be to download a picture or html file, send an email, or etc. And the only way that it will make the right choice is by either (a) monkeying with DNS to only present the address that has a relatively short RTT or (b) monkey with routing to send the datagram on the short delay path. But standard routing is not about delay (I was at the time arguing that expected path delay should be available in routing to enable such decisions), it is about contracts.

Now, if I am allowed to, I can force such things to work right in routing, and in so doing GSE would select the corresponding address pair. shim6 lacks the information, apart from some form of history or reputation mechanism.

So in that case, GSE has a hope of serving the user's intent, and shim6 gets it right some percentage of the time.



Believe it or not, I am also a strong supporter of the end to end principle. What I believe, that you apparently don't, is that there is value in the network helping the user achieve his intended goals. I also believe that there is a fair bit of state and intelligence in routing that the user's administration uses to meet its goals, which is valid and relevant and may be at odds with the actual user - if the "user" is a virus, we usually prefer that the user loses that particular battle.

So please don't be knee-jerk here. The NAT66 proposal (and the one like it but without the checksum offset mechanism that GSE originally proposed) don't have the same effect as NAT44; they don't prevent access. What they do is create a situation in which a host that thinks it has one address on a given interface in fact has several, which a peer should choose among and might change its mind concerning as it interacts with routing. But the user's intent rarely has anything to do with the value of the address - let me ask, when you ask google where to find content and you click on a link, do you even know what the address was, and if you did would it affect you in any way? The user's intent has far more to do with the behavior of the application he has chosen. So I will argue that a technology that enables the routing system to have a number of prefixes comparable to the number of transit networks in the world and enables any system to address a peer anywhere else achieves the user's probable intent regardless of whether the technology in question rewrites the locator. _______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66

Reply via email to