Subject: Re: IPv6 Link-Local Use Issue for Applications

From: Keith Moore <[email-masked]>
Date: Wed, 20 Aug 2003 22:19:16 -0400

> 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. 

really?  what is a "standard" server, anyway?  a SIP server certainly
does care.  an HTTP server that returns redirects might care.  lots
of servers log IP addresses, and they care at least to the extent
that they might want to log the scope_id or interface name of an LL
address in addition to the address itself.  and it would make perfect
sense for some apps - in particular those that do referrals - to refuse to
talk to LL addresses at all. 

Sure enough, you can get away with using LL addresses for some apps.
but it's a big stretch to say that LL addresses are good enough for 
most apps.  There are too many cases where they fail.

LL addresses are simply not suitable for general-purpose use, not even
on ad hoc networks. 

Keith

--------------------------------------------------------------------
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: "Brian Zill" <[email-masked]>
Date: Wed, 20 Aug 2003 17:11:48 -0700

Jim,

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-masked]] 
> Sent: Wednesday, 20 August, 2003 07:27
> To: Brian Zill; [email-masked]
> 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-masked]]
> > Sent: Monday, August 18, 2003 11:00 PM
> > To: Bound, Jim; [email-masked]
> > 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-masked] 
> > > [mailto:[email-masked]] On Behalf Of Bound, Jim
> > > Sent: Monday, 18 August, 2003 18:01
> > > To: [email-masked]
> > > 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
> > > 
> > >