Subject: LLMNR Issue 93: Extensibility

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Jul 2005 09:34:53 -0700 (PDT)

Issue 93: Extensibility
Submitter: Markku Savela
Submitter email address: [email-masked]
Date first submitted: July 20, 2005
Reference:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00852.html
Document: LLMNR-41
Comment type: T
Priority: S
Section: 2.1.1, 6
Rationale/Explanation of issue:

LLMNR assigns meaning to two bits in DNS message.

Wasn't there a discussion about IANA and assigning bits in DNS message
a while back in namedroppers list? LLMNR is just reusing the format,
but will it be a problem if some future DNS (or already existing) uses
the same bits for something else, perhaps something that could also be
useful in LLMNR?

[Bernard Aboba]

The thread (referenced above) talks about parameter assignment.
IANA assignments are described here:

[1] http://www.iana.org/assignments/dns-header-flags
[2] http://www.iana.org/assignments/dns-parameters
[3] http://www.iana.org/assignments/dnskey-flags

Here is the DNS header format:
                               1  1  1  1  1  1
 0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ID                         |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|  Opcode   |AA|TC|RD|RA| Z|AD|CD|  RCODE    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                 QDCOUNT                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                 ANCOUNT                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                 NSCOUNT                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                 ARCOUNT                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Here is the LLMNR header format:

                               1  1  1  1  1  1
 0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ID                         |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|  Opcode   | C|TC| T| Z| Z| Z| Z|  RCODE    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                 QDCOUNT                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                 ANCOUNT                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                 NSCOUNT                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                 ARCOUNT                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Therefore the AA bit and RD bits are being reused.

LLMNR will never need the AA bit since responders only
answer queries for which they are authoritative.

Similarly, LLMNR will never need the "Recursion Desired"
bit, since there is no concept of recursion in LLMNR.

There is one "Reserved" bit left in DNS, which is also
"Reserved" in LLMNR. So assuming that this bit is
eventually used in DNS, it can also be used in LLMNR,
assuming that the usage would make sense.

Note that LLMNR also supports EDNS, which has additional reserved bits.

EDNS Header Flags (16 bits) per [RFC2671]
-----------------------------------------
Bit 0       DO   DNSSEC answer OK  	[RFC3225], [RFC4035]
Bit 1-15         Reserved

Here is what Section 6 (IANA considerations) says about allocation of
LLMNR header bits:

"This specification creates one new name space:  the reserved bits in
the LLMNR header.  These are allocated by IETF Consensus, in
accordance with BCP 26 [RFC2434]."

I don't think we necessarily want to automatically allocate LLMNR header
bits based on DNS header changes, so this seems like the best we can do.

--
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/>