Hi all, during the great discussion about identifiers back in July participants pointed out interesting solutions/proposals around the topic - such as ILNP, how Apple is solving the mobility challenge, Multipath TCP, Nimrod, etc - and now when I have studied and absorbed the material I felt a need to update the hierarchical IPv4 framework. I think the discussion was very useful for me - I learned a lot so thanks to all participants who took part in the discussion (unfortunately I started my vacation at the time and wish I have had more time to be in the discussion). In a nutshell what has been changed at http://www.ietf.org/id/draft-frejborg-hipv4-03.txt
1. Backwards compatibility MPTCP is doing a very nice job with backwards compatibility, "hiding" the new features in the TCP option field. Inspired by this I stumbled over RFC 1385 "The Extended Internet Protocol" and moved the ALOC&ELOC field away from the IP header into the IP option field. No longer a need to have new protocol ID assigned - greater backwards compatibility should be achieved by using the IP option field. 2. IPsec AH ILNP is taking care of the IPsec AH challenge. In the hIPV4 framework IPsec AH is no-go, due to that the LSR is a middlebox swapping the IP source and destination header. We could get around this and make IPsec AH work also in the hIPv4 framework by first assembling a legacy IPv4 packet, then copying the pseudoheader checksum to the IP option field (there is now a 16 bit padding field where the checksum would fit in) and then insert the ALOC information to the header, recalculate the pseudoheader checksum and send the packet to the other endpoint. When LSR is swapping the packet the padding field remains intact and when the remote endpoints receives the packet the original pseudoheader checksum can be retrieved from the padding field. But I think this would be an awful kludge, because it would - break the IPsec AH specs - not solve the NAT traversal issue, and the IPv4 world is full of NAT middleboxes Also, I haven't seen many IPsec AH implementations lately - most IPsec installations are LAN-to-LAN solutions using ESP and remote access system are becoming more and more deployed upon SSL/TLS based RAS So I let darwinism take care of IPsec AH - it is not well suited for the IPv4 world and SSL/TLS has been able to adapt better to the NAT traversal challenge. 3. The identifier Host or session identifier? After studying the MPTCP drafts I found potential in the sender token, it might be used as session identifier to solve site and endpoint mobility issues. But the sender token can not be used to improve NAT traversal, here you would prefer to have HIP in place. On the other hand, if you prefer to do NAT you should not expect to have all features available as when not using NAT - and should we encourage the use of NAT? So I think the the sender token is good enough to create a semi-session layer protocol (as AppleTalk had) that could be used to achieve better mobility - MPTCP looks promising at the moment. If a host really needs to be identified - well, I would use a PKI solution for that purpose. 4. Traffic Engineering MPTCP might create subflows for a connection, how to route the subflows on different links in the backbone - especially if both endpoints have just one IP-address at each host? IGP tuning will not be useful, MPLS TE might be used but it gets tricky since both subflows uses the same protocol. What if you could apply Valiant Load-Balancing on the subflows and separate the subflows that way over different links in the backbone?? Suggestions, questions, feedback and/or criticism is highly appreciated. -- patte _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
