My preference is A, then B, then C.
I also think we should keep the former site-local prefix IANA-reserved.
BTW Patrik - does this mean you're not a fan of the source/destination address selection mechanism for IPv6?
To be honest, I have concentrated on looking at the problem which Brian touched on. Say you have some application which is to send an email to [EMAIL PROTECTED] Today, one look up MX for ecs.soton.ac.uk and sort them. Then A RR is looked up, and for each result set you try the IP addresses in order.
Now when having IPv6 as well, one have to look for A and AAAA RR. This makes things even more complicated, and the same problem exists for every protocol which have such indirection (NS, MX, SRV,... record types) which will over time be _all_ protocols. Simply because we need the indirection.
Now, if we on top of this have scoped addresses of any kind in IPv6, which forces the _application_ (on top of transport layer) to select "the best address"... That I definitely do NOT like.
What is acceptable for me is some algorithm which still make it possible for an application to do:
data = gethostbyname(hostname,service); socket = bind(data); fd = open(socket);
Well, in principle, and the calls doesn't have to be named exactly that. BUT, my point is that I don't care what the gethostbyname or bind or open call do. That should be invisible for the application. What I have heard IPv6 people asking me as an application developer is to suddenly change this pretty simple algorithm to do something more complicated. And, when I talk with people like Itojun which implements these black boxes (I only write the gethostbyname equivalent above) he strongly as you all saw argues as well for [A] because doing scoped addresses of any kind in what I call "black boxes" is not possible.
That is evidence enough for me.
Don't know if I answer your question though ;-)
paf
Tim
On Tue, Aug 05, 2003 at 05:47:20AM +0200, Patrik Fältström wrote:From an Application (above TCP) perspective, A, definitely A. Itojun
summarizes well the issues. Mandating a host to know topology is just a
really bad thing. Really really bad.
paf
On tisdag, aug 5, 2003, at 03:09 Europe/Stockholm, Jun-ichiro itojun Hagino wrote:
I would like to hear from the working group on how we should proceed.
I
think the choices are:
A) Deprecate Site-Local addresses independently from having an alternative solution available. This would mean that the working group should treat the deprecation, and requirements and solution documents outlined above independently from each other. If there was no consensus on an alternative a replacement would not happen.
my choice is (A). as we have discussed at SF (and probably prior meetings) site-local address has a lot of issues with it, for instance, - ambiguous address - can't be used referrals across site zones, and there's no way to determine if a site-local address is from out-of-site or not (because of ambiguity) - mandates hosts to know the topology, which we should not allow/mandate - site-border router issues, and (lack of) routing protocol functionality to handle it therefore sooner deprecation is better.
itojun PS: each of the items are summary of discussions we had before, to my ears, don't try to comment on each items please. the point of the email is the very first sentence, and that's all. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
-------------------------------------------------------------------- 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] ---------------------------------------------------------------------------------------------------------------------------------------- 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] --------------------------------------------------------------------
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
