OMNI Interface - formal issues

["Jaron, Zdenek" <[e-mail]>]

Dear Fred, 6man
After reading the draft https://tools.ietf.org/html/draft-templin-6man-omni-interface-22 I have found three formal discrepancies and I suggest considering the following updates:


Section 5 introduces new code for Packet too big ICMPv6 error called
"Advisory PTB" and thus formally updates [RFC4443] and [RFC8201]. According
to guidelines in [RFC7322], Section 4.1.4., updated RFCs should be mentioned
in the document header.
Also, I believe that introduction of new message code for PTB requires
an IANA action, which is not mentioned in IANA considerations section.
As a side note, the mechanics of processing received Advisory PTB is not
explained in much detail in the document. What is the update of [RFC8201]?
(note: COTS IPv6 implementation observing [RFC4443] will treat an incoming
Advisory PTB as normal PTB.)


The section 7 proposes embedding some (generally nonzero) data in last 112
bits of a link local address. This violates the current wording of [RFC4291],
Section 2.5.6., which explicitly states that the 54 bits following the
FE80::/10 prefix are zero. If the OMNI specification is not able to use
link-local addresses from FE80::/64, it has to formally update the [RFC4291].


In section 8, the document describes usage of "OMNI ULA" addresses from
FD80::/10. Bits 8 and 9 are assigned a fixed value of "10", bits 10-15 encode
OMNI instance ID and following bits are taken from the MNP.
This violates the [RFC4193], which mandates that bits 8-47 are allocated by
a pseudo-random algorithm and "MUST NOT be assigned sequentially or
with well-known numbers". I believe that the usage proposed in OMNI spec
would require a formal update to [RFC4193].


Best regards
Zdenek Jaron