3) While TE has been discussed at length already, but it is something
which is absolutely required for a content provider to deploy
shim6. There
has been quite a bit of talk about what TE is used for, but it
seems that
few people recognize it as a way of expressing "business/financial
policies". For example, in the v4 world, the (multi-homed) end-user
maybe
visible via both a *paid* Transit path (say UUNET), and a *free*
peering
link (say Cogent), and I would wager that most content providers would
choose the free link (even if performance on that link is (not hugely)
worse). That capability all but disappears in the v6 world if the
Client
ID was sourced from their UUnet ip address (since that's who they
chose
to use for outbound traffic), and the (web) server does not know that
that locator also corresponds to a Cogent IP (which they can reach for
free). This change alone would add millions to the bw bills of said
content providers, and well, reduce the likelyhood of adoption of the
protocol by them. Now, if the shim6 init takes place in the 3way
handshake process, then the servers "somewhat" know what all possible
paths to reach that locator are, but then would need some sort of a
policy server telling them who to talk to on what ip, and that's
something
which will not simply scale for 100K+ machines.
4) As has also been discussed before, the initial connect time has
to be
*very* low. Anything that takes longer then 4-5 seconds the end-
users have
a funny way of clicking "stop" in their browser, deeming that "X is
down,
let me try Y", which is usually not a very acceptable scenario :-) So,
whatever methodology we use to do the initial set-up has to account
for
that, and be able to get a connection that is actually starting to do
something in under 2 seconds, along with figuring out which
sourceIP and
destIP pairs actually can talk to each other.