Subject: Proposed (partial) resolution to LLMNR Issue #2

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Mar 2003 09:38:16 -0800 (PST)

Issue 2: TTL=255 on Send, Check on Receive?
Submitter: Christian Huitema
Submitter email address: [email-masked]
Date first submitted: March 7, 2003
Reference:
Document: LLMNR-13
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

Why is it necessary to set TTL=255 on Sending an LLMNR Response, and
then to check this on receipt? All you really care about is that the
responder is on the same link. So check that the Request is sent to the
LLMNR multicast address, rather than to a unicast address. That is enough.

[BA] -- There are cases when LLMNR requests need to be
sent via unicast so this cannot be prohibited. With
respect to the TTL=255 check, the question is how to
limit LLMNR responses to hosts on the local link. Do
you have a suggestion?

Here is a proposed changes to clarify the use of
unicast queries as well as use of IP and DNS TTL:

"2.3. Unicast queries

A sender MUST NOT send a unicast LLMNR query except when:

a. A sender repeats a query after it received a response
to the previous LLMNR query with the TC bit set, or

b. The sender's LLMNR cache contains an NS resource record that
enables the sender to send a query directly to the hosts
authoritative for the name in the query.

If a TC (truncation) bit is set in the response, then the sender MAY use
the response if it contains all necessary information, or the sender MAY
discard the response and resend the query over TCP or using EDNS0 with
larger window using the unicast address of the responder. The RA
(Recursion Available) bit in the header of the response MUST NOT be set.
If the RA bit is set in the response header, the sender MUST ignore it.

2.4. Addressing

For IPv4 LINKLOCAL addressing, section 2.4 of "Dynamic Configuration of
IPv4 Link-Local Addresses" [IPV4Link] lays out the rules with respect to
source address selection, TTL settings, and acceptable
source/destination address combinations. IPv6 is described in [RFC2460];
IPv6 LINKLOCAL addressing is described in [RFC2373]. LLMNR queries and
responses MUST obey the rules laid out in these documents.

In composing an LLMNR response, the responder MUST set the Hop Limit
field in the IPv6 header and the TTL field in IPv4 header of the LLMNR
response to 255. The sender MUST verify that the Hop Limit field in IPv6
header and TTL field in IPv4 header of each response to the LLMNR query
is set to 255. If it is not, then sender MUST ignore the response.

Implementation note:

In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket
options are used to set the TTL of outgoing unicast and multicast
packets. The IP_RECVTTL socket option is available on some platforms
to retrieve the IPv4 TTL of received packets with recvmsg().
[RFC2292] specifies similar options for setting and retrieving the
IPv6 Hop Limit.

2.5. DNS TTL

The responder should use a pre-configured TTL value in the records
returned in the LLMNR query response. Due to the TTL minimalization
necessary when caching an RRset, all TTLs in an RRset MUST be set to the
same value. In the additional and authority section of the response the
responder includes the same records as a DNS server would insert in the
response to the unicast DNS query."

--
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: Alain Durand <[email-masked]>
Date: Tue, 18 Mar 2003 10:41:35 -0800

I would like to post on the list the comment I made this morning
on this issue (TTL=255 on send)

IMHO, LLMNR should be SLMNR (Subnet Local and not Link local)
as there is some ongoing work in IPv6 to define multi-link subnets
and I believe *LMNR should work in that environment.

In Multi-link subnets, the aTTL will be decremented by the routers
and a check that the received TTL=255 will fail.

	- Alain.