Re: how to proceed

[Brian E Carpenter <brc@zurich.ibm.com>]

Iljitsch,

We are expecting an architectural draft from Geoff as follow
up to his presentation in Seoul, and that should be our record
of the big issues. You have provided input for Geoff... thanks.

   Brian

Iljitsch van Beijnum wrote:
> 
> 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?
> 
> 4. Reference
> 
> 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.
> 
> 8. Failover
> 
> 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
> for this.
> 
> 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.