Brian, > I'm not arguing that general-purpose apps should do anything > special to support link-local addresses. For the most part, > I doubt they'll ever see them, since link-local addresses > won't be in the DNS.
Exactly my point in last mail to Itojun. > > But then again, I don't think that most apps need to do > anything to discourage their use with link-local addresses. I agree. I am not worried about that if they are not in DNS. I am worried about the case below. > A standard server listening on some TCP port, accepting > connections, and just chatting with the peer over that > stream, doesn't need to care whether the client is using a > global or a link-local address. TCP will remember the > scope-id internally as part of the endpoint. The app never > even sees it. And if the app does extract the address via > getpeername or whatever, it'll get the scope-id as part of > the sockaddr_in6. If it subsequently opens another > connection to the peer using that sockaddr_in6, it'll connect > to correct peer. So I think the existence of link-local > addresses is a non-issue for most of the world's application writers. Yep. This should work I agree. But how did this happen in the first place is the question? The answer is in your next paragraph I would argue and my concern. > > The only potential concern I see here is with apps that are > specifically designed to be ad-hoc apps. There is that nasty term again ad hoc :--). We can make this simpler any app that can be started with a command line argument and an address ok. I am saying in most cases that should be discouraged as not baked in IPv6. So we don't have to bring ad hoc into this at all. > How does the > initiating node get the link-local address of its peer in the > first place, since link-local addresses are not in the DNS? > Others have pointed to LLMNR as being designed for this > purpose, or maybe some other type of discovery mechanism will be used. Uh. People are deploying IPv6 today. Without this they should not be using them and if they do they need to understand the risks. > > Regardless of that issue, I think proper link-local support > is a major selling point for IPv6. The ad-hoc scenario using > link-local addresses is another place where IPv6 has a much > better story than IPv4. In the IPv4 world, multiple OS > vendors are today shipping a solution where if the machine > doesn't hear a DHCP server it goes into an "ad-hoc" mode > where it creates an address in the 169.254/16 space. With > only 16 bits of numbering space for nodes, the possibility of > collisions is much greater than for IPv6. And the lack of a > scope-id field in the sockaddr_in means that if nodes on two > links do collide, another IPv4 node on both of those links > has no way to disambiguate the two. IPv6 handily solves this > problem today. But it is not baked in IPv6 yet technically for to many uses cases I did already document for you and others. /jim > > --Brian > > > -----Original Message----- > > From: Bound, Jim [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, 20 August, 2003 07:27 > > To: Brian Zill; [EMAIL PROTECTED] > > Subject: RE: IPv6 Link-Local Use Issue for Applications > > > > > > Brian, > > > > Aware of how it could be done and we had to put link-id in > > our first R&D stack back in 1995 when we saw this then. My > > contention is for multiple links the state to be maintained > > to send a packet to the right link with no probe from network > > peer (telling node what link it is speaking to the initiator > > on) is far to cumbersome to ask Oracle, SAP, or Peoplesoft to > > be aware of to port to IPv6. > > > > Glad you agree on not putting these in the DNS too. > > > > thanks > > /jim > > > > > -----Original Message----- > > > From: Brian Zill [mailto:[EMAIL PROTECTED] > > > Sent: Monday, August 18, 2003 11:00 PM > > > To: Bound, Jim; [EMAIL PROTECTED] > > > Subject: RE: IPv6 Link-Local Use Issue for Applications > > > > > > > > > Jim, as long as the application is link-local aware, and > treats the > > > scope-id properly, this is not a problem. Most stacks > I'm aware of > > > handle this situation correctly. But this means getting > the address > > > directly off something on the link, and not through some external > > > lookup mechanism like the global DNS. Link-local addresses are > > > ambiguous off link, and therefore should not (or rather, > MUST NOT) > > > appear in the global DNS. For the most part, this limits > the use of > > > link-local addresses to applications that are aware of the link. > > > > > > --Brian > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Bound, Jim > > > > Sent: Monday, 18 August, 2003 18:01 > > > > To: [EMAIL PROTECTED] > > > > Cc: Bound, Jim > > > > Subject: IPv6 Link-Local Use Issue for Applications > > > > > > > > > > > > Folks, > > > > > > > > Below is a picture of two links: Link 1 and Link 2. Link 1 has > > > > Host-L1-B and Host-L1-C. Link 2 has Host-L2-E and Host-L2-F. > > > > A multihomed Host-LX-D0 is connected to both Link 1 and > Link 2. > > > > All hosts have both a Link-Local address FE80::XXXX and > a Global > > > > Address 3FFE:YY::XXXX. Note that Host-L1-B and > Host-L2-E have the > > > > same Link-Local address as FE80::MAC1. This is > > permitted in IPv6 > > > > for separate links. > > > > > > > > > > > > Host-L1-B Host-L1-C > > > > 3FFE:AB::MAC1 3FFE:AC::MAC2 > > > > FE80::MAC1 FE80::MAC2 > > > > Link 1 ___|_____________|___________ 3FFE:AD::MAC3 > > > > | FE80::MAC3 > > > > > > > > |--- Host-LX-D0 > > > > > > > > | FE80::MAC6 > > > > > > > > Link 2______________________________| 3FFE:A0::MAC6 > > > > | | > > > > FE80::MAC1 FE80::MAC5 > > > > 3FFE:AE::MAC1 3FFE:AF::MAC5 > > > > Host-L2-E Host-L2-F > > > > > > > > If Host-LX-D0 user wants to ftp or telnet to Host-L2-E using > > > > FE80::MAC1 as an address 'ftp FE80::MAC1' being a > multihomed host > > > > the routing or interface redirection (depending on how > > you wanted to > > > > implement) really does not know if it is for Link 1 or Link 2 as > > > > both will be in the destination cache potentially and > duplicated, > > > > and this would be compliant to the IPv6 standard. > > > > > > > > But if Host-LX-D0 used Host-L2-E's global address 3FFE:AE::MAC1 > > > > there would be no problem, as IPv6 does not permit duplicate > > > > prefixes across links. > > > > > > > > What some implementations have done is require the user > > to specify > > > > the interface in addition to the address for link local > > (Linux did > > > > this as a note) 'ftp FE80::MAC1%Ethernet0' and other > > implementations > > > > perform a round robin to find the correct link-local > > address. The > > > > '%' is an artifact of the getaddrinfo() API as parameter. > > > > > > > > But this does not really solve the problem completely. > > How does the > > > > user know which Link to use for the link-local address? What if > > > > the user sent the message to the wrong link, especially in a > > > > mission critical situation (e.g. Patient in Hospital, > > > > Telecommunications Grid, Soldiers Device in Combat). > This is not > > > > good and also has security issues that can be resolved > > with IPsec, > > > > but an encrypted packet to the wrong link is still not good as > > > > there is a chance in the diagram above that all Hosts > are in fact > > > > using same PKI and IPsec encrypt and decrypt, and the packet > > > > could be accepted. > > > > > > > > IPv6 efforts in the IETF will not solve the future scoping > > > > capabilities within the IPv6 architecture any time soon, > > > and it will > > > > be even longer to get scoping widely implemented in the > market and > > > > tested well through interoperability events. The industry > > > > requires a solution today, and I would argue there is > no solution. > > > > > > > > The solution that will work for now is make a statement > > in the IETF > > > > and in industry IPv6 implementation documentation that > link-local > > > > addresses SHOULD not be used as an IPv6 address type by > > > > applications. That link-local addresses SHOULD not be > > included in > > > > the DNS. That link-local adddresses SHOULD be > restricted to IETF > > > > protocols on Hosts to perform Neighbor Discovery, > > Stateless Address > > > > Configuration, DHCPv6, or other operation protocols to > > bring a Host > > > > up on a network. The bottom line is link-local address are not > > > > usable for applications. > > > > > > > > Would like to hear what my colleagues in IETF IPv6 WG > think about > > > > this issue? > > > > > > > > This mail will also be sent to the IPv6 Forum deployment > > effort and > > > > to several users I know of that are deploying IPv6 currently, to > > > > hear from the operational and implementation community too. > > > > > > > > Thanks > > > > /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] > > > > > > -------------------------------------------------------------------- > > > > > > > > > > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
