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

From: "Bound, Jim" <[email-masked]>
Date: Thu, 21 Aug 2003 22:57:27 -0400

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

--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Thu, 21 Aug 2003 23:40:02 -0400

> worried about the case below.

What about apps that need to pass their hosts' addresses to their peers? 
Where do they get those addresses in the first place?  For a variety of
reasons, DNS isn't a reliable way to find your own addresses. So you get them
from the interfaces.  Right now the obvious thing to do is to skip over any LL
addresses that are assigned to your interfaces, in order to avoid giving LL
addresses to your peers, but this only works if all participating hosts have
routable addresses.  If we start expecing apps to use LL addresses, all bets
are off, and we are back to a NAT-like situtation where multiparty apps have
to implement their own proxies, routing, and perhaps even addressing in order
to function.

And what happens when vendors start shipping support for LLMNR?  Will
getaddrinfo() (or other API used for DNS lookup) suddenly start doing LLMNR
queries if it thinks that DNS is unreachable?  Will apps that were formerly
using getaddrinfo to do DNS queries then get exposed to LL addresses even
though they don't work properly with those apps?

Personally I have strong doubts that LLMNR is fixable.  But if it's going to
be deployed, LLMNR needs to stay entirely separate from DNS even to the point
of having separate APIs.  My fear is that the misguided temptation to try to
make LLMNR transparent to apps by overloading existing interfaces will be too
great.
--------------------------------------------------------------------
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: Julien Laganier <[email-masked]>
Date: Mon, 25 Aug 2003 17:25:45 +0200

On Friday 22 August 2003 05:40, Keith Moore wrote:
> reasons, DNS isn't a reliable way to find your own addresses. So you get
> them from the interfaces.  Right now the obvious thing to do is to skip
> over any LL addresses that are assigned to your interfaces, in order to
> avoid giving LL addresses to your peers, but this only works if all
> participating hosts have routable addresses.  If we start expecing apps to
> use LL addresses, all bets are off, and we are back to a NAT-like
> situtation where multiparty apps have to implement their own proxies,
> routing, and perhaps even addressing in order to function.
>

One solution may be to have a configurable switch for the behavior of existing 
APIs (getaddrinfo...), like the existing nsswitch.conf ?

--julien

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Aug 2003 12:11:26 -0400

> > And what happens when vendors start shipping support for LLMNR? 
> > Will getaddrinfo() (or other API used for DNS lookup) suddenly start
> > doing LLMNR queries if it thinks that DNS is unreachable?  Will apps
> > that were formerly using getaddrinfo to do DNS queries then get
> > exposed to LL addresses even though they don't work properly with
> > those apps?
> 
> One solution may be to have a configurable switch for the behavior of
> existing APIs (getaddrinfo...), like the existing nsswitch.conf ?

Aarrgh!  please, no.  The last thing apps need to deal with is more
variation in behavior from one platform to another. 

If LLMNR is going to handle queries for DNS names, it needs to produce
consistent results with DNS.  Full stop.  If it doesn't guarantee this,
it has no business returning queries for DNS names, and we need to
forbid getaddrinfo() APIs from using LLMNR.  Part of behaving
consistently with DNS means NO LL addresses in LLMNR for any DNS name
which could also be queried from DNS.

We really, really don't want apps using LL addresses anyway - not even
on an isolated network.  First because this requires apps to treat LL
addresses differently depending on whether they are being run on an
isolated network or not.  Second because all the hosts in the app may
not have a consistent view of the network - some hosts in an app may see
themselves as being on an isolated network while other hosts see
themselves as connected.  Third because isolated newtorks can become
connected and connected networks can become isolated - and you
want to avoid having to change addresses across those transitions - this
essentially amounts to a renumbering procedure done under severe time
constraints.

A lot of these problems are solved if instead of using LL, isolated
networks elect a probabistically unique PI prefix (PUPI).  I think it
would be acceptable to advertise a PUPI in DNS or LLMNR as long as there
were no PA addresses available (or maybe as long as any PA addresses
were also advertised).  And PUPIs are routable by private agreement
between managed networks, or within a self-configuring network, so you
don't have the same severely constrained use you have with LL.

Ketih

---

From: Hans Kruse <[email-masked]>
Date: Mon, 25 Aug 2003 14:59:14 -0400

Yes, I think that is the right way to go.

I think the following "rules" should go with this approach:

- Assume DNS returns both PA and PUPI, then
  if my node only has PUPI, I select the advertised PUPI,
  if my node has a PA, I select the PA being advertised.

- Obviously, if DNS only returns PUPI and I have both, I use PUPI,
  and use PA if DNS only returns PA and I have both.

- If there is no match (I have only PUPI and DNS returns PA, or vice 
versa), I would suggest to fail the connection by default (even though it 
might work), but I am not sure.

- Referring addresses should only ever be done within type, i.e. never 
refer a PA over a connection using PUPIs, or vice versa.

Incidentally, this would address quite a few of the scenarios in 
hain/templin as well as the ones suggested for the ad-hoc cases.

Can the WG move on the Hinden draft, maybe with a set of rules like the 
ones above (and all the safeguard statements discussed before)?

> don't have the same severely constrained use you have with LL.

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax
--------------------------------------------------------------------
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: "Chirayu Patel" <[email-masked]>
Date: Tue, 26 Aug 2003 09:50:03 +0530

> might work), but I am not sure.

.....maybe not. Failing connections is too drastic. You never know if the site
operator has set up an internal route from the PA to the PUPI.

CP