RFC 4282, "The Network Access Identifier", December 2005

Note: This RFC has been obsoleted by RFC 7542

Errata ID: 816
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-18
Held for Document Update by: Dan Romascanu

Unfortunately, the text of that RFC does not fully reflect the
established state of the IETF standards, by referring to obsolete
documents (e.g., ex STD 10, RFC 821) and ignoring effective updates,
e.g., STD 3, RFC 1123, and RFC 2821.

In particular, the text of RFC 4282 repeatedly (e.g. in Section
2.6.) emphasizes making a deviation from established standards
for host / domain names.

This is not true!
The pretended deviation in fact reflects the current standards.

The modification to RFC 952, RFC 821, et al. has already been
introduced into the IETF Standards by STD 3, RFC 1123 (Host
Requirements, Part II), published 16 years ago, in October 1989.
Section 2.1 of that RFC, on page 13, says:

    "One aspect of host name syntax is hereby changed: the
     restriction on the first character is relaxed to allow
     either a letter or a digit. Host software MUST support
     this more liberal syntax."

and continues saying:

    "Host software MUST handle host names of up to 63 characters
     and SHOULD handle host names of up to 255 characters."

Therefore, it would have been strongly advisable to point out
on page 6 of RFC 4282, in Section 2.2, first bullet, that the
named rules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!

Note: IMHO, it is a fundamental design flaw of RADIUS and certain
other protocols using TLVs, AVPs, -- or however similar protocol
objects are named -- to specify that the 'length' information
(being stored in a single octet) is to comprise the cumulative
size of the Type, Length and Value fields, instead of just giving
the size of the Value (payload) field; the latter solution would
always allow to fully exhaust the total range of an 8-bit unsigned
Length and thereby allow payload octet strings of size 0..255 !


Similarly, RFC 4282 ignores the standardization state of the
proprietary historic tunnelling protocols that have served as
'precursors with major deficiencies to learn from' for the
development of L2TP, the only comparable protocol named in 
RFC 4282 that is on the IETF Standards Track.

  o   L2F [RFC2341] has been published for information only
      as a Historic RFC 'ab initio'.

  o   PPTP [RFC2637] has purposely been rejected by the IETF --
      because of its well known significant security flaws, among
      other issues, and the Informational RFC 2637 has been
      published with a very clear IESG Note to this end.

I am surprised that a new Standards Track RFC is getting published
that repeatedly refers to obsolete protocols equally as to official
protocols, in a manner that does not make clear the distinction.
The continued unreflected use of PPTP, in particular, is seen by
major security consultants as 'one of the most widespread trojan
horses' in the current Internet.  We should do everything to
communicate and emphasize the 1998/1999 decisions of the IETF and
IESG and the reasons behind it, and push the evolved standards!

It should say:

[see above]

Notes:

from pending

Report New Errata