Patrick,
your msg broke the long silence of this mailing list!
I've yet to read your new draft and comment (just finished my 3 week-
long back-2-back trips), but will try to do so in coming days, as part
of my efforts to get ready for Hiroshima.
Talking about Hiroshima: according to the RRG plan, the Hiroshima RRG
meeting will be focusing on the discussions of RRG recommendation to
IETF on scalable routing solutions. There is precisely two weeks
before Hiroshima now, lets get the discussion started on the list
first. I'm going through all the exchanges since Stockholm by subject
groups, in an attempt to make a summary.
Lixia
On Oct 20, 2009, at 7:55 AM, Patrick Frejborg wrote:
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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
