On 1 mrt 2008, at 11:14, Geoff Huston wrote:
6. Next Steps Work Items Iljitsch van Beijnum
A discussion on what's missing from the base specification of Shim6 to consider what new work the WG should take on.
Here are some preliminary thoughts on part of this. Please let me know what you think so I can grow or shrink this part for next week as required...
One of the important things that's still open is the ingress filtering situation. The topic of address rewriting in routers in some way also resurfaces regularly.
After a discussion with Christian Vogt and some back and forth on the IETF list about draft-rosenberg-internet-waist-hourglass-00.txt, I've been thinking about NAT in IPv6. The problem with NAT as it's used in IPv4 is mainly the port overloading: this breaks incoming traffic. Another big problem is the fact that ports and the checksum must be rewritten, which means that the NAT must be aware of transport protocols. If we get rid of these two issues, NAT almost becomes harmless. I'm still not convinced that NAT in IPv6 is a good idea, but I AM convinced that if we can limit NAT to strict address translation without port overloading that is much, much less harmful than a port overloading NAT.
Now combine this with the shim6 proxy, address rewriting and ingress filtering stuff and you may end up with something like this:
When an IPv6 host uses unique site locals as source addresses and the packets are about to be forwarded to an ISP, the router rewrites the top 64 bits of the source address with a prefix that comes from the ISP in question. The new top 64 bits of the address are checksum- equivalent to the old top 64 bits. (As long as it's /48 prefixes this is fairly trivial to do.) This means that ingress filtering is no longer an issue. Because the checksums for TCP, UDP, ICMP and DCCP remain the same, these protocols don't break. RTP doesn't use a checksum (although it's generally used on top of UDP so see UDP) and unless I'm mistaken. SCTP doesn't include the addresses in its checksum , which is a good thing, because it uses a CRC-32 which I don't think is incrementally updatable like the normal checksum.
When packets return, routers don't rewrite the destination address. Then, two things can happen: the packets end up at the host itself, which recognizes the rewriting and from then on, sources packets with the source address that was written in the first packet by the router. Or hosts on the subnet are legacy and won't recognize the rewriting, so a middlebox rewrites the destination address to the unique site local prefix. The host or middlebox can now start shim6 so that if there is a path failure, the session/context can move to a different address.
For packets that aren't the first in a session and that also aren't part of a context for which there is shim6 state, the host (or middlebox) would fill in the "real" (external) address as a source address, which isn't rewritten by routers. Once shim state is negotiated, hosts may return to using the unique site local source address which can then be rewritten.
This would be a relatively clean type of NAT, the only thing that it breaks is referrals. In IPv4 this is often solved by asking a remote host to echo back the external address that it sees, but this would be problematic if the site is multihomed so the translation would be to different addresses based on which ISP is used to reach a particular destination...
In the case of a proxy, it would be nice if the proxy could select the full 128 bits of the address so it can create an HBA/CGA address, but it probably won't be easy to make this checksum-clean.