[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Design decisions made at the interim SHIM6 WG meeting
On Thu, 27 Oct 2005, marcelo bagnulo braun wrote:
El 27/10/2005, a las 17:08, Iljitsch van Beijnum escribi�>> significant number of IPv6 applications doesn't either. I don't
see applications cycle through all source/dest pairs because
that's very hard to do right.
Indeed.
not really understand what is the part that you think it is hard....
It's not particularly easy to do in a portable manner at present, the
only semi-portable interface is the BSD IFCONF ioctl(), but it gives
you a lot of detail and you then have to understand the differences
in those details between those systems. Very easy to get it wrong.
It's even more fun if you want to stay abreast of changes to
configured addresses.
If you go down this road make sure to specify that an implementation
SHOULD provide a means for an application to retrieve a simple list
of candidate addresses (possibly sorted by preference determined by
whatever local policy).
So either we have three choices:
1. adopt the "second shim" to do this for the application
2. make it possible to repair the situation where there is no reachability
between the ULIDs from the start.
3. update RFC 3484 and wait for all applications to be updated
I believe 3. won't work in practice and if it did, it would be a huge
duplication of effort as all applications would have to implement the same
functionality. Remember that we chose to make the shim such that unmodified
applications can benefit from it.
Concur strongly.
I think we could have 3 approaches (which can be complementary i.e. does not
have to be one or the other)
- first approach is to let the app take care of everything
i.e. inform the app about all src and dst address and let
the app try all the possible combinations.
This seems contraversial - it's completely wrong for general case
IPv6 (no shim involved). Applications have no business interfering
with things normally determined by local routing policy, least not by
default.
At least, it'd be a fundamental change in existing practice.
- a second approach would be similar to the current case where the
app does not select the src address. In this case, the rfc3484bis
src address selection mechanism would need to use a different
src address each time the apps retries.
This really won't fly - it introduces state into source address
selection which just is not there, i.e. whether application is
retrying or not. (Never mind the previous point, which still applies
in this case).
Introducing such state would require quite fundamental changes to
existing application interfaces.
I think that the first two approaches make sense and that it would
be useful to incoporate information about incoming address pairs as
a hint to select outgoing address pairs that are working.
I don't think either approach makes sense :).
Is there any good reason why this retry/source-select state can not
be kept inside the shim6 layer? The remit of shim6 is after all to
handle this stuff transparently.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
I have the simplest tastes. I am always satisfied with the best.
-- Oscar Wilde