RE: OMNI Interface - formal issues

["Templin (US), Fred L" <[e-mail]>]

Zdenek, thank you for submitting these comments - all of which are important
points for further discussion. See below:

> -----Original Message-----
> From: Jaron, Zdenek [mailto:[e-mail]]
> Sent: Monday, June 01, 2020 12:18 AM
> To: 6man WG <[e-mail]>; Templin (US), Fred L <[e-mail]>
> Subject: OMNI Interface - formal issues
> 
> 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.

Yes, that is correct; in the next draft version I will include the docs in the update
header text.

> Also, I believe that introduction of new message code for PTB requires
> an IANA action, which is not mentioned in IANA considerations section.

Also correct, and I will fix in the next draft version.

> 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.)

What we would like to have happen when a node receives an advisory PTB
is to reduce its estimate of the path MTU to the destination the same as for
an ordinary PTB message. So, it is OK if COTS devices do not recognize the
new codepoint. However, there is no guidance in RFC8201 as to whether a
node should retransmit data at a smaller packet size if it receives a PTB
because it is possible that the data may have reached the final destination
even though the node received a PTB. In other words, there is no normative
guidance that asserts that receipt of a legacy PTB must be regarded as a loss
indication.

The purpose of defining an "advisory" codepoint is therefore to unambiguously
assert that this PTB need not be regarded as a loss indication. This would indicate
to nodes that regard a legacy PTB as a loss indication that the advisory PT need
not be regarded in that way. In the final analysis, however, if a node decides to
retransmit on receipt of a PTB no harm is done in any case. The advisory PTB
simply provides a useful clue to nodes that recognize it that this PTB does
not represent a loss event.

> 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].

The OMNI spec is an "IPv6-over-foo" document which specifies the operation
of IPv6 over specific link layers. That includes the formation and use of IPv6
link-local addresses. So, since only nodes that implement the OMNI spec
will ever see these link-local addresses it should be OK to define the link
local addresses as being relative to fe80::/10 as permitted by RFC4291 while
overriding the default zero settings of the 54 intermediate bits. So, since this
is wholly contained within the OMNI spec I don't think we need to formally
update 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].

Good point, Zdenek - I honestly never dug deeply into RFC4193 and thought
that all of fc::/7 was our own playground for free expression. However, I
notice that RFC4193 says that bit 7 is "Set to 1 if the prefix is locally assigned
and Set to 0 may be defined in the future". The behavior you are describing
above is therefore with respect to "fd::/8", so what if we were to change
the OMNI spec to define "fc::/8" as permitted by RFC4193? That way, we
would be free to define the setting of fc80::/10 in the way we currently
do in the OMNI spec. However, I think you are correct we would still need
to say "updates RFC4193. What do you think?

Thanks - Fred

> 
> 
> Best regards
> Zdenek Jaron