Re: existing proposals

[Jun-ichiro itojun Hagino <itojun@iijlab.net>]

>> 	Here are documents currently alive (there can be others):
>> 	draft-ietf-ipngwg-ipv6-2260-00.txt
>> 	draft-ietf-ipngwg-ipv6multihome-with-aggr-01.txt
>> 	draft-bragg-ipv6-multihoming-00.txt (not discussed in 1999 interim)
>> 	draft-ietf-ipngwg-default-addr-select-02.txt
>All of them violate the end to end principle and does not work.
>It is wrong to add intelligence to already too intelligent
>routing system.

	In what sense it violates "end to end principle"?  what led you to the
	conclusion?
	None of them modify routing protocols.  The first 3 items are just
	routing configuration/opertional hints.

>As for source address selection, as Internet routes are heavily
>assymmetric, it is wrong to assume that an end system can make a
>good guess on routing environment of its peer, which means a
>source can not make proper selection of its source address to
>be used at its peer.
>End to end principle means that decision should be made based
>only on  host's local, which does not mean local to peer of
>the host, information.

	so, i guess you are saying that
	- if we rely on source address selection rule on the sender side,
	  we are violating end to end principle.

	The goal of source address selection draft is clearly stated in
	section 1.  From multihoming perspective, the goal for the source
	address selection is to use *seemingly better* source address for the
	peer to reply.
	The only guy who can pick the correct source address to use is,
	a guy knows about every states in all intermediate routes, nobody else,
	so it is impossible.

	I don't agree with your wording: "violates end to end principle".
	There's no NAT involved, there's no header-rewriting 8+8 router
	involved.  Please use appropriate term like "uses source address
	selection".

	I agree (i took a glance into your draft):
	- session layer/modified TCP, which lets us endpoint address (unlike
	  TCP), will make some part of problems go away.
	- socket API changes may help, but you may not be able to convince
	  vendors out there.
	- drastic changes like 8+8, may help.
	However, we already are deploying IPv6 nodes, there are IPv6-enabeld
	TCP applications.  If we think about real deployment, things we can do
	is very limited.  IT IS TOO LATE FOR MAJOR CHANGE!  If you are
	interested in toy protocol implementation just for inside your
	playground, go ahead make any changes.

	BTW, only the last one (among 4 drafts) talks heavily about source
	address selection.  I wonder how you concluded like below.

>All of them violate the end to end principle and does not work.

itojun