Joshua, > Is it invalid to base assumptions on what can be observed? IPv6 has > been deployed for a while now. There are applications that support > IPv6. This applications work well with IPv6. This > applications have to > deal with IPv6LL addresses because IPv6LLs have existed for > as long as > most stable implementations have existed. I'm not sure why you are so > concerned about the negative impact of IPv6LL addresses when almost > every shipping implementation of IPv6 has implemented IPv6LLs and no > one has had serious problems with them.
IPv6LLs are very valuable to IPv6 for node discovery and first phase of autoconfiguration and that was their purpose and reason for creation. Your correct IPv6LLs have been around for a long time and they don't cause a problem on a single link. I have built the code to use them for IPv6, and been at bake-offs etc and have not seen a duplicate link-local on multiple links either. If a node communicates to another node with an IPv6LL and the receiving node sets the sin6_scope_ID the node can respond if sin6_scope_ID was implemented yes. All of this is axiomatic and proven. What is new is when the initial application wants to initiate communications with another node on a network and there is no DNS entry for the node and the only way is to have the application select the node destination is from the command line. On a single link that will work for a non-multihomed node. That is axiomatic. But if the node is multihomed with two links as in the diagram I sent and there is a duplicate link-local on one of the multihomed links, then how does the user know the packet is going to the correct node? That is the bottom line question for me. All the rest of this mail has nothing to do with my question. mdns or LLMNR are not widely implemented and if you bring your implementation to one of the many test events for IPv6 where your node must interoperate on the deployed implementations testing network most nodes will not respond to mdns. I am sure you can interoperate with your own nodes. But think about a network where your nodes are only say 10 out of 30 on two links. Your mdns will not work with the other nodes for IPv6LLs. My postulate is that major pain can be caused by sending to the wrong IPv6LL in a multilink scenario if the packet goes to the wrong link. How does the user know to specify applicationname FE80::1%ethernet0, ethernnet1, etc.? Because of this potential conflict today it needs to be documented publicly. That does not mean in worst case scenarios of no router and no assigned prefix for ad hoc network IPv6LLs cannot be used but rather some serious thought should go into their use by what I call mission critical applications. > If you try to remove IPv6LL you will get push back from the industry. in I am 100% against removal of IPv6LLs nor did I ever say that in any mail. > If you try to deprecate APIs, such as removing the scope id, > when there > is no clear reason why, you will get push back. I am 100% against deprecating scope id from the Base API that would be stupid. > This working > group may > do these things to satisfy the loud and obnoxious people on the list. This will not happen in this working group and I did not hear one person on this list state either of these statements, so if you can show me the mail where someone said this I will know I have missed that as I did not read any such mail on this thread to my knowledge? I am not going to participate here in the discussion regarding address use nor was it what my mail was about, but Keith's points are all correct in my opinion regarding tomorrows use of IPv6, and the downsides of not using global adddresses for general applications. I am quite familiar with ad hoc networks in depth and I have seen IPv6LLs used in specific cases some have pointed out here. That is why I know a fatal error can happen if boundaries are not understood for IPv6LLs and their use cases. Those boundaries and use cases will be recorded publicly but not from here in the IETF and now I am convinced of that from this mail thread. When and if mdns or LLMNR become widely implemented then that may solve some of the issues. All protocols have warts and some more than others that does not mean we don't use them, but we must document those warts. /jim -------------------------------------------------------------------- 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] --------------------------------------------------------------------
