Subject: RE: Revision to resolution of Issue 28

From: <[email-masked]>
Date: Wed, 16 Apr 2003 12:16:53 +0300

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi Aidan,

[Mailing from work now]

> Mika Liljeberg wrote:
> > The change was made because there is no easy way for an 
> application (=
> > LLMNR resolver) to check whether a particular address is 
> on-link. Not on
> > any operating system I know, anyway. There's no difference 
> between IPv4
> > and IPv6 in this respect.
> > 
> 
> Yes, I gathered that from reading the stuff on the issues web page
> and the mailing list.  I didn't really buy the check the routing
> table thing..

Why?

> The proposed solution seems like a bit of a fudge, (as in it doesn't
> address the fundamental issue of not being able to tell what is
> on-link) but because it is only a "preference" it probably won't
> hurt that much.

Yes, it could be clearer. But a clear requirement won't help if there is no clear way to implement it. It just means that different implementations will get it wrong in different ways.

It occurs to me that it would be a whole lot simpler to do the PTR queries using unicast. The LLMNR resolver could use a TTL=1 when sending the query. This way it would either get an immediate no-route response from the local TCPIP stack, a direct response from the holder of the address, or an ICMP time exceeded reply from the default router. Either way, the resolver wouldn't have to do any checking on the address. This approach has several benefits:

1) Immediate error response if there is no route for the address
2) Error response from default router if the address is off-link
3) LLMNR resolver does not need to do any checking on the address
4) Unicast is easier on the network

Note that conflict resolution for addresses is taken care by DAD, so using unicast for PTR shouldn't make any difference there. Another assumption is that the PTR query is already vulnerable to spoofing on the local link, so, as long as we use TTL=1 for the query there should be no perceivable additional risk.

> > [On-link determination would become trivial, by the way, if we only
> > allowed LLMNR to only advertise link-local addresses].
> 
> True..  but it appears people want to use it for more than that,
> at least in the IPv6 case.

Yes, IPv4 keeps muddying the water. LL's are always available with IPv6, so there should be no reason to advertise anything else.

	MikaL

--
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: Aidan Williams <[email-masked]>
Date: Thu, 17 Apr 2003 10:32:38 +1000

>>and the mailing list.  I didn't really buy the check the routing

Mainly because the suggested approach of using a UDP connect as a test
will succeed when there is a default route, or a route of more than
one hop.  Perhaps we really mean that we should prefer addresses we
can ARP/ND directly for.

"Reachable" (or unreachable) in RFC3484 is deliberately vague, and
explicitly says that determining unreachability is implementation
dependent.

 > Yes, it could be clearer. But a clear requirement won't help if
 > there is no clear way to implement it.

I understand that the resolver doesn't have a guaranteed way of
discovering whether a particular address is directly reachable on the
link..  My concern was more about the proposed text for Issue 28.

The -17 text doesn't define "reachable" anywhere, but it does define
"on link".  Right at the point where it seems like it is going to use
the "on link" definition for something, it starts talking about
"reachable".

The text used elsewhere ("must be reachable through the link over
which LLMNR is used") seems self-contained enough to me -- hence the
suggestion I made.  "Prefer addresses that can be directly ARPed/NDed
for" would work for me too.

 > It just means that
 > different implementations will get it wrong in different ways.

Quite.. ;-)

 > It occurs to me that it would be a whole lot simpler to do the PTR
 > queries using unicast. The LLMNR resolver could use a TTL=1 when
 > sending the query. This way it would either get an immediate
 > no-route response from the local TCPIP stack, a direct response from
 > the holder of the address, or an ICMP time exceeded reply from the
 > default router. Either way, the resolver wouldn't have to do any
 > checking on the address. This approach has several benefits:
 >

I think that is a good idea.  This is what the Node Information Query
reverse lookup does.

When asked to reverse lookup a multicast address what then?  Offhand I
can't think of a good reason not to just multicast the PTR query to
the address you are looking up.

- aidan

---

From: Mika Liljeberg <[email-masked]>
Date: 17 Apr 2003 20:33:13 +0300

> one hop.  Perhaps we really mean that we should prefer addresses we

Well, I gave the UDP connect as an example of what an application could
try in order to satisfy the requirement. To force the stack to do ARP/ND
the application would actually have to send a packet (which I think is
unfeasible in practise).

> the "on link" definition for something, it starts talking about

Hmm. I don't see any problem with the text, because the "on-link"
definition is used for constrain the source and destination addresses
used by LLMN. Which RRs to prefer is a separate issue and the text on
that is correct (and consistent with RFC3484), I think. Maybe we just
need a definition for "reachable"?

> for" would work for me too.

Does that mean you require the resolver to ARP/ND every address to find
out whether it can be done, before returning the address to the
application? I should hope not.

	MikaL

---

From: Mika Liljeberg <[email-masked]>
Date: 17 Apr 2003 20:45:21 +0300

> the address you are looking up.

I think we have to be careful here. Even though setting TTL=1 would
limit the propagation, I wouldn't want to send a PTR query to the subnet
broadcast address.

The first question is, is it useful to support PTR queries for multicast
and broadcast addresses at all? If yes, we have to define the behaviour
both ways. Does a responder also include its subscribed multicast
addresses to A and AAAA responses? Multicast addresses would also have
to be treated as non-UNIQUE RRs to avoid problems with conflict
resolution.

I would say just return an error to PTR queries for multicast/broadcast
addresses.

	MikaL