Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt

From: Erik Guttman <[email-masked]>
Date: Fri, 6 Dec 2002 17:03:05 +0100 (CET)

Harald,

You sent a comment that we should add examples.  I suggested a few and
got no response.  I am trying again, with specific text.  This could be
added in section 1 (introduction), say as a subsection to 1.2
Applicability, or in Section 7 on application considerations

X.Y  Examples: Applications Using Link-Local Addresses

   Several applications are particularly well suited for use in a
   link-local environment.  These applications have been enjoyed for
   years by users of AppleTalk and SMB protocols, but have not been
   available for use on networks using the Internet protocol suite
   alone due to the lack of automatic address configuration.

   The primary applications which users expect are file sharing and
   printer sharing.  File sharing could be achieved using FTP [RFC959], 
   and NFSv4 [RFC3010] clients and servers.  Print sharing can be done
   by using LPD [RFC1179] or IPP [RFC2910] protocols.

   These protocols will behave as expected if

    a) neither the client nor the server is forced to change its
       link-local address after a protocol connection has been
       established

    b) neither the client nor the server are multihomed hosts using
       link-local on more than one interface

    c) both client and server have a v4LL address

   Existing clients can cope with (a) by reestablishing a connection.
   Connection failures are common enough that clients typically are
   able to easily restart a session. Clients may and servers likely
   will need to be changed so as to always use their *current* address
   for communication, instead of the address they had at the time the
   program started.

   It would be best if vendors avoided support for (b) unless they
   offer new interfaces and mechanisms to resolve potential problems
   with address ambiguity, as discussed in Section 3.

   c) concerns hosts which forward messages including link-local
   addresses off of the local link.  Protocols listed above can 
   contain addresses (FTP, NFSv4, IPP).  Section 2 specifies that a 
   datagram with a link-local source or destination address MUST not be
   sent to a router for forwarding.  There are only a limited number of
   ways in which a datagram with a link-local identifier can then be
   forwarded off the local link.

      1. A host not compliant with this specification may send a
         message to a link-local destination address to a router for
         forwarding.  The router, if it is not compliant with this
         specification, will forward the message.

         Result 1.1.  A host which receives this message will not be
         able to respond, as hosts which comply with this specification
         do not forward from a link-local source address.

         Response to 1.1.  Configure routers not to forward to
         link-local destinations.

         Result 1.2.  A host which forwards a message to a link-local
         destination instead of using ARP to resolve the address locally 
         will not be able to communicat with hosts configured with 
         link-local addresses, on their local link.

         Response to 1.2:  Configure routers not to forward to
         link-local address destinations.  Upgrade hosts to support this
         specification if one wants to effectively communicate with
         hosts using link-local addresses.

      2. If a host sends a datagram to a global multicast address from
         a link-local source address, a router may forward the message.

         Result 2.1:  Messages will leave a local link which have a
         source address to which it is impossible to send a reply.  Or
         if one does send a reply and it happens to reach the sender,
         the sender will not be able to reply (see Result 1.1).

         Response to 2.1:  Configure routers not to forward messages
         with link-local source addresses.

      3. A host with a global address could act as a proxy for a device
         with a link-local address.   The proxy could forward a request
         for a client with only a link-local address off the link.  The
         proxy could also forward a reqest from off the link to a server
         with only a link-local address.

         Result 3.1:  Link-local addresses in NFSv4, IPP and FTP
         (passive mode) will not result in the receiver of these locators 
         being able to respond to their senders.  This has the same
         properties as network address translation (NAT). [RFC2663]

         Response to 3.1:  For communication off the local link, the
         best thing to do is configure the client or server with a 
         global address.  If that is not possible, see [RFC2663] for
         how to proxy and gateway applications across an address
         scope boundary.

How does this look?

Erik

On Wed, 27 Nov 2002, Erik Guttman wrote:
> On Fri, 4 Oct 2002, Thomas Narten wrote:
> > The IESG discussed this document recently, and has the following
> > comments.
> > 
> > DISCUSS:
> > ========
> > Harald:
> > 
> > Three objections, based on a quick scan:
> > 
> > 1)
> > 
> > The document gives no (zero) examples of applications that can 
> > successfully and safely be used with link-local addresses. I think a 
> > list of applications would serve two purposes:
> > 
> > - document the motivation for this feature
> > - serve as target for people arguing that this application has 
> > serious failure modes when used with link-local addresses
> 
> Application examples:
> 
>   Tha classic peer to peer applications are
>     'File sharing' - NFS and ONC RPC based protocols, SMB
>     'Local printing' - LPD
> 
>   Let's add
>     'Local web browsing' - FTP, HTTP
>     'Local administration' - telnet
> 
> Caveats:
> 
> General -
>   This does not describe how a link-local address is configured with the
>   application.  This could be done using LLMNR, SLP, etc.  This implies
>   that 'link-local locators' (names and addresses that have only link-
>   local significance) can obtained service queries (SLP), or name
>   lookups (LLMNR), etc.
> 
>   Since link local addresses may change over time (unlikely, but
>   possible), it is best to obtain them dynamically (using SLP or LLMNR,
>   etc.)
> 
>   Link-local local locators which are forwarded off-link are worthless.
>   Therefore, some protocols, such as conferencing or those which build
>   session based directories to forward locators would fail.
> 
>   An example of how a protocol which supports forwarding of locators can
>   be made to work in a scoped address environment is in RFC 3111, SLP
>   modifications for IPv6.  The only trick is to keep information which
>   is received using a scoped address separate, and to only forward it
>   to others in the same scope as it was received.
> 
>   The following comments apply equally to any use of these protocols
>   in scoped or private address spaces.
> 
>   HTTP - 
>     Redirects [RFC 2616, Section 10.3] and the Content-Location header 
>     in general [RFC 2616, Section 14.14] will have to be link-local
>     locators in order for a client configured with a link-local
>     address to make use of it.
>   
>   HTML - 
>     URIs refered to in anchors, etc. must be link-local locators in
>     order for a a client configured with a link-local address to make 
>     use of it.
> 

> > The following set of protocols:
> > 
> > - FTP
> > - DNS
> > - NFS
> > - IPSEC using IPv4 as an identifier
> > - BGP
> > - OSPF
> > - RTP/RTCP
> >  <<<the list is far longer, I think>>>
> > 
> > will fail if applications use a link-local address instead of a 
> > globally unique address when sending the address of its interface in 
> > a protocol packet.
> 
> In the case of IPSEC using IPv4 as an id, BGP, OSPF: OK.
> 
> Why is this the case with FTP, DNS, NFS, RTP/RTCP?
> If the sender and receiver are both on the same link these protocols
> should work fine, I believe.