Ayyasamy, Senthilkumar (UMKC-Student);
To summarise, read:
http://www.ietf.org/internet-drafts/draft-ohta-multi6-8plus8-00.txt
which describes a end2end scalable 8+8 id/loc proposal, a lot different
from Mike O'dell's version of 8+8.
Also, since the transport is maintaining per path information, it is in
the best decision to decide which path to use.
*nod*.
Correctly speaking, the transport or the application layer
is the only place to decide which pasth to use, since the
IP layer can not maintain timeout.
Attempt to imitate it by IP layer results in NAT, where connection
will be terminated if there is no packets flow for a timeout period
incorrectly guessed by the IP layer. At the upper layers, it is
often perfectly leagal if there is no traffic for 1 hour over
a live connection. But, NAT behaves badly for such connections.
It is the main reason why multi addressing is the only
architectural possibility to do a scalable MH. The problem with
the remaining solutions (at shim/new identity/network layer) is
that they hide the redundancy factor (multiple address -MA) from
the users. Given the current state (failures, misconfigurations
and rate limitations,) e2e check (by measurements) is the only
option to check path availability. The MA feature gives user a
chance to make a choice based on e2e reachability checks.
Right.
I dont know why people get suprised by explicit announcement of
MA. we have been doing this kind of explicit announcement both
in DNS ( multiple NX records) and SMTP ( multiple MX records.)
So, in a way SMTP reliability is due to explicit announcement of
multiple MX records.
That is an argument I made several years ago.
id/loc split proposals are cool. But, without modifying the routing
architecture, they can never provide a e2e reliability or explicit
user control feature.
Wrong.
8+8 addressing (ID locator separation) works just fine to support
multiple addresses of a host. Note that Mike O'dell made a poor
proposal of an 8+8 variant does not mean others does not work.
With 8+8 addressing, IP layer needs no modification and routing
architecture works as is.
With 8+8 addressing, all the addresses are passed to the upper
layers and controlled there.
Because IPv6 addressing space was designed to leave a group bit
of 8 byte MAC for 8+8 addressing, transport layers, including TCP,
can check the bit to see whethere a host support end to end
multihoming.
That is, API of TCP with 8+8 addressing needs no modificaiton
and the existing code, including Mozilla, works as is without
even a line of modificaiton.
OTOH, I don't forsee any routing change at
*architectural* level in the near future.
It is time to think
on why id/loc split proposals without routing architecture change
kill the e2e control/reliability options and are architecturally
incomplete.
There has been a lot of 8+8 id/loc split proposal, most of
which does not change routing architecture.
It is granted that Mike O'dell's GSE was a poor id/loc proposal.
But, it is a problem of GSE, not 8+8 nor id/loc separation.
So, it is clear that a combination/subset of host-centric MH,
transport MA and BGP MH (if there exists a solution which
doesn't bloat routing table) is the ONLY possibility to do a
scalable MHv6.
Read:
http://www.ietf.org/internet-drafts/draft-ohta-multi6-8plus8-00.txt
though it does not use BGP in a way you might be thinking, which
is why it does not bloat the routing table.
Masataka Ohta