[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
how to proceed
We are once again discussing all kinds of details, which is of course
very useful, but I want to take a few moments to look at the big
picture, and the relationship between the smaller issues that make up
said big picture. This should give us some guidance about how to
proceed, as some issues are fundamental and must be resolved in order
to arrive at a workable solution, while others (hopefully most) can be
pushed back and resolved later as optional mechanisms.
All of this is assuming a multiaddress solution.
1. Basic operation and negotiation
I think we're beginning to get a pretty good handle on this part. We
reached the conclusion that actual identifier/locator separation isn't
needed here. There are some details to be worked out, such as when the
negotiation happens: always at the beginning, after sessions have been
established or both/any.
2. Security association setup
As we're not chartered to build a world wide PKI, we must make our
mechanisms as secure as possible in the absense of strong
authentication. There are some proposals for this (not necessarily in
this wg). However, we don't really know yet what we want to do if there
IS strong authentication present at some other layer (IPsec, TLS),
which should be common enough to make it useful to reuse.
3. Have identifiers anyway
Identifiers aren't required, but that doesn't mean they aren't desired.
It seems there are at least some people within the IETF who would like
to see a real locator/identifier separation. Are we prepared to add
identifiers to the mix? And if so, in what way? There are proposals for
disjoint identifier/locator spaces, but also for "hiding" identifiers
inside locators. The cryptographic nature of some identifiers may be
useful in securing negotiations. Do we want to allow identifiers that
don't look like IPv6 addresses?
Ephemeral locators aren't very suitable for referential purposes. Do we
need to make this issue part of the multi6 solution or is it better to
create a new protocol for this that is orthogonal to our other efforts?
5. Ingress filtering (and address selection)
Need I say more?
6. Address rewriting by routers
This can be useful, but what is the right way to handle this? It seems
unlikely that this capability will be universally available anytime
soon, if ever. On the other hand it would be a shame to have to use
complex mechanisms to get around ingress filtering when the rewriting
capability is available.
7. Traffic engineering and policy (and address selection)
Current proposals are lacking with regard to traffic engineering. We
could reuse DNS SRV records for this. There are few provisions for
policy enforcement in current proposals, except in NAROS which hasn't
been heard from in a while.
Still too much handwaving.
9. Interfaces to other layers
It is likely higher layers will want to influence certain aspects of
multihoming operation. Interfaces between layers and APIs are needed
That's it for now. I suggest that we keep this list up to date (feel
free to add stuff) and go over it to see how we want to handle the
issues at some point.