Subject: Re: LLMNR authorized range

From: Joshua Graessley <[email-masked]>
Date: Wed, 17 Mar 2004 14:13:00 -0800

My friends has a problem with his cable modem provider. He has paid 
extra to get extra addresses. The addresses are handed out using DHCP. 
The addresses are not always on the same subnet. I see no reason why 
LLMNR shouldn't work for him.

I may soon have a similar situation at home. I've got sDSL for a small 
server I run. I'm thinking about getting a cable modem connection so I 
can get stuff quicker. When I have that setup at home, I'll have two or 
more subnets running on the local network. All of the devices can 
communicate using their IPv4 addresses (albeit inefficiently). LLMNR 
should work in this situation but due to the TTL stuff it may not work.

I think there is a simple solution for IPv6. Always use the IPv6 
link-local addresses. The only solution that would work 100% of the 
time for IPv4 would be to use the same link-local multicast to send the 
response.

-josh

On Mar 17, 2004, at 1:22 PM, Paul Vixie wrote:

>>> ...  If there are two subnets overlaid on a local network and the
>>> hosts are unaware of the opposite subnet, LLMNR will make it
>>> impossible to resolve names of some devices on the same link just
>>> because they exist on a different subnet.
>
> that sounds like the right thing, since if they're on different subnets
> then they will not be able to communicate even though those subnets are
> in the same broadcast domain.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Mar 2004 17:02:06 -0600

[ Moderators note: Post by non-subscriber.  With the massive amount of
   spam, it is easy to miss and therefore delete relevant posts 
   by non-subsrcibers. Please fix your subscription addresses. ]

> LLMNR shouldn't work for him.

It shouldn't work for him because his network is misconfigured.    It's 
not the job of the IETF to arrange for it to be the case that any 
random configuration error still results in desired behavior, for any 
arbitrary value of "desired."

If you want this to work, you need to go check out the IPv4ll protocol 
and make sure that it does the right thing in this case.   And your 
friend needs to use IPv4ll.  Rendezvous works correctly in this case, 
doesn't it?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Andras Salamon <[email-masked]>
Date: Thu, 18 Mar 2004 16:54:57 +0200

> arbitrary value of "desired."

Exactly how is overlaying two IP network ranges onto one L2 infrastructure
misconfigured?

-- Andras Salamon                   [email-masked]

---

From: Andras Salamon <[email-masked]>
Date: Thu, 18 Mar 2004 17:32:58 +0200

> LLMNR shouldn't work for him.

This hits at the crux of what "Link-Local" means in the acronym LLMNR.

The above scenario (if indeed regarded as acceptable practice) will be
regarded by most people as "local".  During the original drafting of
the document, did the authors have a specific definition of "link-local"
in mind?  As I recall, the original spec came out of Stuart Cheshire's
work on replacing AppleTalk's naming service; this became Rendezvous and
branched off into LLMNR.  If this is the case, then the "local" definition
was pretty broad, and would probably cover the overlaid network scenario.

Also, in the above scenario, forcing TTL=1 will cause the router to
drop the packet before it is forwarded back onto the "other" part of
the local network.  Making TTL=5 (or any other number greater than 1
but less than the worst-case diameter of the Internet) seems to be an
ugly solution, and also gets away from the "link-local" part of LLMNR --
why not just call it "restricted scope MNR" then?  Or why not just drop
the TTL restriction altogether and just allow general MNR?

I repeat -- TTL checks are a kludge, and do not capture the idea of
"local" networks.  There are local networks for which TTL must be
greater than 1 to capture locality (eg. multiple IP ranges overlaid on
the same L2 medium as above), and there are distinctly non-local networks
(eg. LANs bridged through long thin pipes) for which any multicast can
cause great harm -- even with TTL=1.

In a message to this forum from Bernard Aboba in October 2003:

    As a result, the ZEROCONF WG has had to spend the last year
    rewriting the IPv4 Link-Local specification so as to "do no harm".
    The current specification no longer mandates a test for a TTL value,
    and prefers a routable address when available.  It is perhaps not as
    "useful" as the early versions -- but it also does not break the
    basic interoperability of TCP/IP.

I've probably taken the above slightly out of context, but perhaps we
should go back to the original multicast slant of LLMNR and drop UDP
unicast, as suggested by Bernard in another message.  For multicast,
the TTL is irrelevant unless we are trying to compensate for potential
router bugs.  On the other hand, for TCP queries, the TTL should not be
restricted.  Then, interoperability with an existing protocol seems to
be a worthwhile goal, as long as it is not bought at a terrible price.
(Why was UDP unicast functionality introduced, anyway?)

At the end of the day, I just want to see some finality with LLMNR,
whatever it is!  Either it is going to be useless and Rendezvous will
win out in the marketplace, or it will be useful and over time it may
grow to take over from Rendezvous.  But right now LLMNR is by definition
useless, since it hasn't been finalised.

---

From: bill <[email-masked]>
Date: Thu, 18 Mar 2004 08:50:54 -0800 (PST)

> This hits at the crux of what "Link-Local" means in the acronym LLMNR.

	link-local is an unfortunate terminological choice.
	it might be useful to consider "single broadcast domain",
	which pretty much eliminates the overlay scenario. 

>  As I recall, the original spec came out of Stuart Cheshire's

	Hum... there were a series of efforts that hit confluence and
	then diverged...  the TBDS research, what became Rendezvous and 
	what might become LLMNR... all are varients that use DNS or DNSlike 
	stuff.

> -- Andras Salamon                   [email-masked]

--bill

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Mar 2004 12:36:42 -0600

> Exactly how is overlaying two IP network ranges onto one L2 

It is misconfigured in the sense that it does not do what the customer 
expects.   The customer expects that the two devices he or she has 
connected to the network will be able to communicate with each other 
without relying on the service provider.   This is unfortunately not 
true - they will not be able to communicate other than over the service 
provider's link, unless they implement Rendezvous (I do not believe 
that the current IPv4ll draft, for example, will allow them to 
communicate independent of the ISP).

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Mar 2004 12:47:39 -0600

On Mar 18, 2004, at 9:32 AM, Andras Salamon wrote:
> During the original drafting of
> in mind?

Yes.   However, the current document bears only a passing resemblance 
to what the authors had in mind.   The original intention was that the 
two devices we're discussing would both have IPv4ll addresses, and that 
MDNS, as it was then called, would uses these addresses, not the 
globally-routable addresses.   Both the IPv4ll spec and the MDNS spec 
have been changed dramatically since then.   IPv4ll no longer works the 
way it did, and LLMNR doesn't either.

At this point, I have to say that it is my sincere hope that neither 
IPv4ll nor LLMNR make it to standard as they are currently constituted. 
  But if they do make it to standard, my next hope is that they do not 
fail to interoperate with Rendezvous.   If they do not interoperate 
reliably with Rendezvous, then the only purpose they will serve is to 
make sure that no reliable mechanism exists whereby two arbitrary hosts 
can automatically communicate with each other on the local link in the 
event that the DHCP server is not configured to enable this 
communication - by having two incompatible mechanisms that do roughly 
the same thing, we eliminate the possibility of dependable 
interoperability.

I sympathize deeply with your motivation to make LLMNR work correctly 
in the scenario we're talking about in the absence of any competing 
protocol, but that is not the domain in which we are operating.

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 17 Mar 2004 14:13:00 -0800

-josh

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Mar 2004 17:02:06 -0600

---

From: Andras Salamon <[email-masked]>
Date: Thu, 18 Mar 2004 16:54:57 +0200

---

From: Andras Salamon <[email-masked]>
Date: Thu, 18 Mar 2004 17:32:58 +0200

---

From: bill <[email-masked]>
Date: Thu, 18 Mar 2004 08:50:54 -0800 (PST)

--bill

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Mar 2004 12:36:42 -0600

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Mar 2004 12:47:39 -0600