Hi,
let me summarize the discussion we had about address selection,
and move on to the next-step.
The discussion was about a try-and-error based mechanism proposed
by Fred Baker, and the address selection design team's proposal,
which is based on policy distribution.
* Fred's proposal.
- A host tries each pair of src and dst addresses to establish
a connection in a short time period.
- A host can make use of ICMP error messages indicating that the
src address should be this, or the src address is simply wrong.
- A host can have cache for the reachability status, which stores
which src and dst pair should be used to reach a certain dst.
** Pro
- A connection can be established as far as one working pair exists.
- Routing status can be reflected to address selection directly,
which means no need for intermediate agent and information conversion.
** Con
- Impact for host protocol stack implementation.
- Not a small change for the existing protocol stack and possibly
applications.
- We do not have established caching algorithm.
- Caching does good for static environment, and can harm for
dynamically changing environment.
- Network outage invokes cache reconstruction.
- Conformance with network policy, user experience.
- A connection success does not mean conformance with site network
policy, nor user experience, such as delay and bandwidth.
- A site may have demands for preference control on address selection,
such as IPv6 and IPv4 prioritization, in order to decrease network
provisioning cost or to enhance user experience.
- Extra load for network and host.
- routers have to send error messages.
- servers are loaded by unused sessions.
- extra CO2 emission ;)
- Non-connected transport protocol complexity
- Only applications know the connection success/failure if they use
non-connected transport protocol like UDP.
- Spoils DNS round-robin based load balancing
- Network side(routers) cannot have effects on dst address selection.
Only can have effects on src address selection.
* Design Team proposal.
- Network side distributes address selection policy to hosts.
** Pro
- No impact on protocol stack, as far as it implements RFC 3484.
- At least, network policy can be implemented.
This does not always lead to user experience enhancement.
- Network side can have effects on dst address selection also.
** Con
- Hosts have to have functionalito for receiving and processing policy
information.
- To make use of routing information, routing information has to be
converted to address selection policy at intermediate nodes, and
frequently updatable policy distribution mechanism is necessary,
such as DHCP reconfigure.
* Considerations towards next-step
Design team proposal and Fred proposal have different applicability
domains, and one does not include the other.
Fred proposal works more nicely if combined with Design team'smechanism.
Design team proposal can work by itself, but if combined with
Fred proposal, the applicability will be broader.
So, my suggestion is to have both mechanisms, while keeping one mechianism
work without the other protocol.
--
Arifumi Matsumoto
Secure Communication Project
NTT Information Sharing Platform Laboratories
E-mail: arif...@nttv6.net
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
