how to proceed

[Iljitsch van Beijnum <iljitsch@muada.com>]

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.