Subject: Do reserved label types clash with 1034/5 ?

From: Roy Arends <[email-masked]>
Date: Thu, 28 Feb 2002 18:23:45 +0100 (CET)

There is a potential problem due to a clash between rfc2671 (EDNS0) and
1034/5.

This has to do with with section 3.2 of rfc2671 where it reads:

3.2. The "1 1 1 1 1 1" extended label type will be reserved for future
     expansion of the extended label type code space.

and at section 7 (IANA Considerations) of rfc2671 it reads:

     This document assigns extended label type 0bxx111111 as "Reserved
     for future extended label types."  We request that IANA record this
     assignment.

This last section has logically the following effect:

(1) An ASCII label has a maximum size of 62 instead of 63, due to the
    fact that labeltype/length 0b00111111 matches reserved labeltype
    0bxx111111.

This is bad, since it is not backw. compatible.

(2) An offset in a Compressed label (or pointer label) has a maximum of
    16127 due to offset>16127 matches reserved labeltype 0bxx111111.

This is less bad, since you'd probably use EDNS when using large offsets.

Was my interpretation right ? Or are the IANA Considerations of rfc2671
unclear ?

(been reading through archives, no mentionings of this, and no registry
at IANA has been opened for EDNS extended label types)

Please enlighten me :-)

Roy Arends
Nominum

--
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: Bob Halley <[email-masked]>
Date: 28 Feb 2002 10:45:34 -0800

[ post by non-subscriber ]

> There is a potential problem due to a clash between rfc2671 (EDNS0) and

I don't think there is any clash, though the RFC 2671 text is a little
confusing.

>     fact that labeltype/length 0b00111111 matches reserved labeltype

No.  3.2 says 'The "1 1 1 1 1 1" *extended label type*' [my emphasis].
To be an 'extended label type', the label type (upper two bits) must
be '0 1' as described in 3.1.  There is thus no conflict with ordinary
labels, which always have '0 0' in the upper two bits.

Section 7 requests IANA to create an ENDS Extended Label Types
registry.  The document is differentiating between the normal DNS
label type codes which are used in the upper two bits, and the
extended type codes which are used in the lower 6 bits of extended
labels.  Section 7 could have perhaps been clearer, but it says
"assigns *extended* label type 0bxx111111" [my emphasis].  The
document presumably has "xx" in the upper bit postions not because
they may take on any value, but because they are not part of the
"extended type" code registry space.

> Was my interpretation right ? Or are the IANA Considerations of rfc2671

I think your interpretation is incorrect, and that there is no
conflict between RFC 1035 and RFC 2671.

/Bob

---

From: Roy Arends <[email-masked]>
Date: Thu, 28 Feb 2002 20:47:52 +0100 (CET)

On 28 Feb 2002, Bob Halley wrote:

> Section 7 could have perhaps been clearer, but it says "assigns
> *extended* label type 0bxx111111" [my emphasis].  The document
> presumably has "xx" in the upper bit postions not because they may
> take on any value, but because they are not part of the "extended
> type" code registry space.

That was my initial interpretation too, but thinking more about this,
another interpretation could be that since EDNS0, 0bxx111111 is now known
as extended label type, reserved for future extensions. i.e. ASCII labels
can have extensions by this (aka have extended label types), pointer
labels can have extensions by this......

I know this might be a far fetched hair split, but it was a
possibility, and the "xx" part was where the ambiguity came from, plus the
fact the doc states "types" instead of "type codes".

(Why not simply state 'assigns EDNS extended label type code "0b111111" ')

Anyway, I needed to have this clarified for the dnssec revision docs.
I'll go with your presumption, until consensus states otherwise ;-)

Thanks for the quick response,

Regards,

Roy