Alain Durand wrote:
> I'm affraid you're overlooking the impact on address selection here.

Back to the flat earth concept ... 
Insisting on a single address per interface is the only way to avoid address
selection. Until we have a globally routed PI space we know there will be
multiple PA addresses to deal with, and in any case we know there will be
routing filters. Therefore there will be address selection with all the
potential for delays, so app developers simply have to get over it.
Complaining about address selection will not make routing filters go away,
because filtering is not something the IETF gets to decide.

There is a requirement for local application stability no matter what is
happening with the set of ISP interconnects. Unless applications have an
affinity for a limited range prefix, they will be susceptible to disruption
from external events. These external events would normally have absolutely
nothing to do with the operation of the local app, but if the external
interconnect is the only source of the address prefix these internal-only
apps will fail. This failure mode from prefix instability is absolutely
unnecessary and unacceptable. 

There is also a requirement to provide mechanisms that are simple for the
non-technical consumer to understand and deploy. This is the only way to
replace existing consumer friendly technologies like NAT. Telling the
consumer 'replacing the NAT is easy, all you have to do is configure the
filter for the port number ...' will ensure they continue using the
automated tool. Building automated tools requires simple deterministic
mechanisms that just work out of the box. This includes working in the case
where there is no external Internet connection, but may be a connection to
another out of the box network.

This whole discussion is about multihoming, which points out the failure of
the approach to move the multihoming discussion into a separate WG. Multi6
should be closed NOW, and that work should be folded back into the IPv6 WG
so there can be a comprehensive approach to the issues (this is independent
of the fact that the thread in an Ops WG is really about rearchitecting the
Internet). As we stand now, all discussions about multihoming are assumed to
be taking place over there, so we don't recognize the address selection
discussion as being the same thing. 

Tony





--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to