[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Resolving my DISCUSS on ipv4 linklocal



See below. I have indicated to Erik Guttman that I think the warnings are sufficiently draconian to allow the document to be published.

It doesn't make the technology harmless, of course, but it allows us to say "I told you so" when the problems occur....

comments?

Harald

---------- Forwarded Message ----------
Date: mandag, mai 05, 2003 11:07:34 +0200
From: Erik Guttman <Erik.Guttman@Sun.COM>
To: zeroconf@merit.edu
Cc: Harald Alvestrand <chair@ietf.org>
Subject: New text for [LL4] No Examples of Applications



Description of Issue No examples of applications
Submitter Name Harald Alvestrand
Submitter Email Address chair@ietf.org
Date first submitted 6 Feb 2003
Reference
http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00041.html

http://www.merit.edu/mail.archives/zeroconf/2002-10/msg00000.html
Comment Type ['T'echnical | 'E'ditorial] T
Priority ['S' Must fix | '1' Should fix | '2' May fix ] 1
Section A new introduction section?
Rationale/Explanation
of issue: There was a request for a list of example applications which
can safely be used with link-local addresses.
Lengthy description of problem: I supplied the following list: File
sharing (NFS, SMB),
Print sharing (LPD, IPP), Local file sharing & web browsing
(FTP, HTTP), Remote login (TELNET)

This raised questions which I have not had the time, and lack enough
expertise to answer:

o Doesn't NFSv3 include addresses? Will that cause NFSv3
to fail?
o Doesn't NFSv4 and IPP carry domain names? DNS will not
have LL entries, most likely. Won't this cause NFSv4
and IPP to fail?

==============================================

Before coming up with text for this, I think that we need to have
agreement on the characteristics of applications that will cause them to
fail when used with LLv4 addresses.

I do not believe that just because an application uses LLv4 addresses
that it will fail. The problem is not use by itself -- it is use of
linklocal addresses IPv4 addresses in the wrong context.

If an application uses its LLv4 address in communicating with a host
off the link, it will break. However, if it uses that address in
communicating with a host on-link then that should not happen.

In looking at this, I believe the problem is "leakage". Including an LLv4
address in an off-link application exchange is an example of leakage --
and I believe that this MUST NOT be done at any layer.

Similarly, I do not believe that including domain names in an application
is by itself a problem -- unless it involves leakage. Examples of
leakage include using LLv4 addresses in DNS. Including a name in an
application where DNS is not configured among the conversants is not a
problem -- assuming LLMNR is available to resolve the name.

If the above makes sense, then I do not think it is necessarily
appropriate to come up with "lists of applications" that will
automatically fail. Rather we should focus on what applications need to do
in order to be successful. Here is some proposed text:


Requested Change:

"Use of linklocal IPv4 addresses in off-link communication is likely to
cause application failures. This can occur within any application that
includes embedded addresses, if an LLv4 addresses is embedded when
communicating with a host that is not on the link. Examples of
applications that include embedded addresses are found in [RFC3027]. This
includes IPsec, Kerberos 4/5, X-Windows/Xterm/Telnet, FTP, RSVP, SMTP,
SIP, Real Audio, H.323, and SNMP.

In order to prevent use of LLv4 addresses in off-link communication, the
following cautionary measures are advised:

a. Routable addresses should be used within applications whenever they are
available.
b. Names that are globally resolvable to routable addresses should be
used within applications whenever they are available. Names that are
resolvable only on the local link (such as through use of protocols such
as LLMNR) MUST NOT be used in off-link communication. This can be
prevented by using LLv4 addresses or names resolvable on the
local link when an LLv4 address is used as the source address in the
packet.
c. LLv4 addresses MUST NOT be configured in the DNS."






---------- End Forwarded Message ----------