Re: [Bier] Possible conflict between nibble value in RFC 8296 and IANA registry of IP version number

[" 徐小虎(义先) " <[e-mail]>]

Hi Greg,
Thanks for raising this issue.
As had been said in (https://tools.ietf.org/html/draft-xu-mpls-sr-over-ip-00#page-9) as follows:
"   The MPLS label stack has no explicit protocol identifier field to
   indicate the protocol type of the MPLS payload.  This document
   proposes a mechanism for containing a protocol identifier field
   within the MPLS packet, which is useful for any new encapsulation
   header which may need to be encapsulated with an MPLS header.  With
   this explicit protocol identifier field, there is no need any more
   for each new encapsulation header to deal with the notorious first
   nibble issue associated with MPLS individually.  More specifically,
   there is no need to intentionally avoid the first nibble of each new
   encapsulation header from being 0100 (IPv4) or 0110 (IPv6) and even
   worsely misuse the first nibble of each new encapsulation header as
   an MPLS payload type field (e.g., MPLS-BIER
   [I-D.ietf-bier-mpls-encapsulation]).  The tacit permission of
   misusing the first nibble of each new encapsulation header as an MPLS
   payload type field would exhause the valuable nibble space quickly."I strongly believe the MPLS community should start to consider how to deal with the nibble issue caused by the lack of a protocol field in the MPLS architecture, rather than leaving this issue to each new encapsulation.
Best regards,Xiaohu------------------------------------------------------------------Greg Mirsky <[e-mail]>2018年3月23日(星期五) 20:11BIER WG <[e-mail]>; Loa Andersson <[e-mail]>[Bier] Possible conflict between nibble value in RFC 8296 and IANA registry of IP version number
Dear All,RFC 8296 explains the nibble field on BIER header as:   Nibble:
      This field is set to the binary value 0101; this ensures that the      MPLS ECMP logic will not confuse the remainder of the BIER header      with an IP header or with the header of a pseudowire packet.  In      an MPLS network, if a BFR receives a BIER packet with any other      value in the first nibble after the label stack, it SHOULD discard      the packet and log an error.
But IANA registry for IP version numbers reflects allocation of 5 for ST RFC 1819 (thanks to Loa for pointing me to the registry):
Decimal 	Keyword 	Version 	Reference 0-1		Reserved	[Jon_Postel][RFC4928]2-3		Unassigned	[Jon_Postel]4	IP	Internet Protocol	[RFC791][Jon_Postel]5	ST	ST Datagram Mode	[RFC1819][Jim_Forgie]6	IPv6	Internet Protocol version 6	[RFC8200]7	TP/IX	TP/IX: The Next Internet	[RFC6814]8	PIP	The P Internet Protocol	[RFC1621]9	TUBA	TUBA	[RFC1347]10-14		Unassigned	[Jon_Postel]15		Reserved	[Jon_Postel]
Perhaps ST Datagram never saw the light of deployment but, as it looks, we may have formal conflict at hand. The way to remedy the situation may be to re-assign value 5 to BIER or, at the minimum, make it reserved.What do you think?
Regards,Greg