Subject: RE: Some IPv6LL operational experience

From: "Bound, Jim" <[email-masked]>
Date: Sat, 23 Aug 2003 01:03:44 -0400

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-masked]
--------------------------------------------------------------------

---

From: Joshua Graessley <[email-masked]>
Date: Sat, 23 Aug 2003 21:50:10 -0700

> 10 out of 30 on two links.  Your mdns will not work with the other 

We are trying to push for a wider adoption of mDNS. We were trying to 
work with the IETF to establish it as a standard, but the working group 
ran it in to the ground as LLMNR to such a state that we can not use 
it. We continue working on mDNS since LLMNR is in such a useless state. 
Our implementation of mDNS can be built on many platforms. We feel that 
mDNS combined with IPv6LL addresses make for a very powerful solution 
to the problems of local communication on both configured and 
unconfigured networks.

> How does the user know to specify applicationname FE80::1%ethernet0,

On our implementation, if the scope is not specified the transmit 
fails. I think it results in a no route to host error. This means that 
the scope id must be specified for a link-local address. In the case of 
mDNS, this is automatic. In the case of manually typing an address, the 
user must append the scope id to the IPv6LL address (i.e. 
fe80::123%en0). Some browsers choke on this, treating the % as an 
escape character. Most browsers handle this correctly when the IPv6 
address is correctly bracketed by '[' and ']'.

> thought should go into their use by what I call mission critical

Suggesting that applications should avoid IPv6LLs at all cost is silly. 
IPv6LLs will work transparently with the vast majority of existing 
applications. Applications that have special requirements (those 
transmitting an address in a packet) will need to filter out such 
addresses for any destination that may potentially be off link. Those 
applications may also need to remember the interface packets were 
received on in the case of an IPv6LL being forwarded to another node on 
the same link, just as our mDNSResponder and resolver libraries do. 
This is not a difficult concept to grasp nor is the code very 
complicated. I'm surprised it has sparked such a heated debate.

-josh

---

From: Keith Moore <[email-masked]>
Date: Sun, 24 Aug 2003 01:15:00 -0400

> Suggesting that applications should avoid IPv6LLs at all cost is silly. 

suggesting that apps in general can use IPv6LLs is also silly.

OTOH, promoting the use of mDNS and LLs for IPv6 is criminally irresponsible.