Hi patte, Thanks for the continuing discussion:
>> I can't think why an IPv4 application which has been made to work >> from behind NAT, I guess with specific messy protocols and external >> servers to trick the NAT box into allowing various things to happen, >> would be easier to modify for IPv6 operation. As far as I know, >> making an application able to operate from behind NAT isn't some >> special generalised independence from how each host is connected or >> where, which would somehow ease rewriting the code for IPv6. >> >> This is pretty generalised discussion. Can you think of some >> examples? > > One example is HTTP and the usage of cookies. If you have a lot of > clients (thousands) behind a forwarding proxy then how to do server > load-balancing in front your servers? You can't use the source address > to identify a unique client, every client behind the proxy is having > the same source address in their connections to the server. So the ADC > in front of your server usually identifies the clients by the help of > cookies, and direct the client always to the correct "real server". So > when the connection lands at the real server the source address has > been changed by the forwarding proxy and the destination address has > been changed by the ADC (if the ADC operates in L3 mode) - NAT > everywhere and far from easy to troubleshoot > http://en.wikipedia.org/wiki/HTTP_cookie OK - this is just a client-server application, and since the client can communicate perfectly well with the server, as long as it opens the session from behind NAT, then NAT makes no difference. Since the whole thing happens at the HTTP level, IPv4 or IPv6 is not an issue either. But applications which attempt to do things which would be easy and natural without NAT, such as sending video, audio or whatever from one host to another, are difficult or impossible with hosts behind one or more layers of NAT. > And you can try it yourself, take a session to a web site, shut down > your interface and use another interface to continue on the same site. > Most likely the site will continue to serve you from where you left > off. > > A cookie is an identifier that is decoupled from the address space and > network layer, the more these kind of applications there is deployed > the easier it would be to change the network and address architecture. Yes, but this is just client-server applications. > I think that the SCTP verification tag and MP-TCP token has similar > characteristics, and they are more of general nature and not so much > tied to a certain application. Both the verification tag and token are > 32-bit, if these transport protocols becomes more used the middleboxes > could start to track sessions with the help of the 32-bit "session > identifier". MP-TCP is for TCP only, UDP should be abandoned and SCTP > shuold be used instead - but SCTP is plagued by the evil NAT and thus > there is a catch-22 situation. > > This is an architectural discussion/speculation and there is a lot of > hurdles to get us there, maybe impossible to achieve... I think SCTP is an interesting and promising protocol, but I don't know much about it. I will probably steer well clear of the multipath TCP debates. I understand it requires changes to some or all DFZ routers. If we can change all DFZ routers, then there's a lot more I would be doing than MP-TCP! - Robin _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
