Jim, 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.
But then again, I don't think that most apps need to do anything to discourage their use with link-local addresses. 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. The only potential concern I see here is with apps that are specifically designed to be ad-hoc apps. 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. 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. --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] --------------------------------------------------------------------
