• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

RFC 5952 - IPv6 address hex digits MUST now be lower case! WTF?

Started by snarked, December 03, 2010, 12:32:56 PM

Previous topic - Next topic

snarked

Stop the stupidity of RFC 5952, Section 4.3, where it states that ONLY lower case alphabetics are valid for hexadecimal digits in IPv6 addresses.  Upper-case or capital letters are now forbidden!

This RFC flies in the face of 50+ years of computer industry, science, and computational theory history, where the alphabetic digits for radix bases greater than 10 are traditionally upper case, with lower case reserved for use in base 37 numbers and higher.  If any change is to be made, then it should be from upper-case only to allowing both cases, or even mixed-case from digit to digit.  Disallowing upper-case digits as forbidden is a real bonehead move in my opinion.

The discussion on the issue is based the IETF errata section for the RFC (Errata #2656), and is taking place on the IPv6 mailing list:  http://www.ietf.org/mail-archive/web/ipv6/current/maillist.html - Topic "[Technical Errata Reported] RFC5952 (2656)."  Please [also] make your comments there.

rwg

RFC 5952 simply specifies a set of rules for generating the preferred textual representation of an IPv6 address.

The third sentence of RFC 5952's section 4 reads:

The recommendation in this section SHOULD be followed by systems when generating an address to be represented as text, but all implementations MUST accept and be able to handle any legitimate RFC4291 format.

If you feed a program the address FE80:000:00:0::00:000:0001, the program MUST accept it and parse it correctly since that's an acceptable format under RFC 4291.  When that program wants to output the address (to the console, to a log file, whatever), the program SHOULD use the form fe80::1.  This is in the spirit of Postel's Law: "be conservative in what you do, be liberal in what you accept from others."

I can't get as worked up as you have over whether or not lowercase 'a' - 'f' was the right choice.  It's convenient to pick one or the other for consistency and to make sorting slightly easier.  The RFC 5952 authors picked lowercase.  Them's the breaks.  If it really bothers you, feel free to write IPv6 addresses using uppercase 'A' - 'F' -- humans probably won't care, and programs should be able to read those addresses as long as they're valid representations according to RFC 4291.

snarked

OK, but if one reads down to 4.3, it does not say lower case "for output only."  That subsection makes it clear - upper case is not acceptable at all, due to the use of "MUST."  Such leaves no discretion for user input as your reply post here implies.  4.3 is in direct contradiction with 4, which says that one must remain in "full compliance" with prior RFCs, and the prior RFC directly cited, 4291, has upper-case digits.

rwg

Section 4.3 doesn't contradict section 4 in any way.  Section 4 just lays out the rules for constructing the preferred canonical textual representation of an IPv6 address and says you SHOULD use these rules.  These rules are the subsections of section 4: sections 4.1, 4.2 (which includes sections 4.2.1, 4.2.2, and 4.3.3), and 4.3.

All textual representations of IPv6 addresses that were valid under RFC 4291 are still valid under RFC 5952.  But if the textual representation of an IPv6 address contains uppercase characters, then that representation is not the preferred canonical textual representation of the address under RFC 5952.

snarked

That is NOT how I read section 4.3.  Since is says "MUST be lower case", I read such as meaning that upper case is clearly forbidden (on input as well).  The plain language on this is clear.

rwg

I don't know how to convince you that you're reading more into this RFC than there is.  Section 4.3 is not a standalone rule that all textual representations of IPv6 addresses must conform to in order to be valid.  It is one of five rules (along with sections 4.1, 4.2.1, 4.2.2, and 4.2.3) that a given representation must conform to in order to be the canonical textual representation of an IPv6 address.

snarked

I can't agree with your interpretation.  When they write "MUST be [in such a form]", that disallows ALL other possibilities.  This is a clear change as the prior RFC clearly had UPPER case alpha hex digits.  However, if they're going to be fully compliant and "handle all RFC 4291 formats", then LOWER case must be disallowed.  The contradiction is the very problem of RFC 5952.  In order for all of section 4 to be valid, some subsection must be jettisoned from acceptance.