Re: Comments on <draft-gont-6man-rfc6564bis-01>

[Bob Hinden <[e-mail]>]

Hagan,

> On Oct 24, 2015, at 5:48 AM, Hagen Paul Pfeifer <[e-mail]> wrote:
> 
> * Bob Hinden | 2015-10-23 15:52:21 [-0700]:
> 
> Hey Bob!
> 
>> I have read this draft a few times, and I guess I don’t really see how this
>> draft changes anything from RFC6554.
> 
> The difference from 6554 - An IPv6 Routing Header for Source Routes with the
> Routing Protocol for Low-Power and Lossy Networks - is enormously! ;-) Just
> kidding.

Sorry about that :-)

> 
> Let me explain the difference from a user (kernel, software) point of view.
> With 6564 the kernel do *not* know how to interpret a unknown/upcoming
> extension header or protocol. Say Next Header is 666 how to interpret this? As
> a 6564 uniform extension header? As a legacy extension header? As a protocol?
> Right, the kernel has no information about the type and the required
> treatment. What the kernel normally do is a treatment as a protocol and
> looking for the registered proto handler.  If 666 is not a registered
> transport protocol the kernel will drop the packet, generate icmp, whatever.
> Simple defining a shiny uniform extension header is only half of the coin.

OK, so the other change is the allocation of a protocol value.  The document says this in the start of Section 5, but there isn’t an allocation request is the IANA considerations section.  I think that is why I missed it.

I still don’t see how this changes the core problem of knowing how to process new unknown extension headers.  Even with what is proposed in this draft, if an implementation sees a subtype value it don’t know about, it will still won’t know how to process it.  It may or may not decide to drop it.  If it’s trying to do some sort of security validation, I suspect it will default to dropping.  I see this draft as just pushing the problem down a level to the subtype, from the next header.  The core problem remains.

I wish there was some solution to introducing new headers (extension and transport) to the Internet.  It’s an unfortunate problem not limited to IPv6 extension headers, but I don’t think the approach in this draft will make any material difference.  New headers and IANA registries IMHO won’t change anything.

> 
> The only way to solve this issue is to provide the kernel a *guaranteed
> promise* that a extension header is formated in the uniform extension format.
> This can only be done by providing a unique next-header value. The kernel now
> must *not* know the particular new encapsulated extension header and their
> meaning.  The most important characteristic is that the kernel is now in the
> ability to ignore unknown extension header and jump over their because the
> kernel know that the Universal Extension Header implement a TLV like encoding
> (hdr_ext_len).
> 
> It is all about *knowing* in advanced if a particular header is encoded as a
> Universal Extension Header or not.
> 
> Pseudo Code (only some known ext header supported to point to the problem):

Nice pseudo code :-)

Bob

> 
> func process_header() {
> 	while (more_ext_header) {
> 		switch (next_header) {
> 			case EXT_HOP_HOP:
> 					hdr_size = process_ext_hop_hop();
> 					break;
> 			case EXT_ROUTING:
> 					hdr_size = process_ext_routing();
> 					break;
> 			case EXT_FRAGMENT:
> 					hdr_size = process_ext_fragment();
> 					break;
> 			case EXT_UNIVERSAL_HEADER():
> 					hdr_size = process_ext_universal();
> 					break;
> 			default:
> 					// hdr processing ends here
> 					return treat_as_transport_protocol();
> 		}
> 
> 		packet_ptr += size_of_known_ext_hdr;
> 	}
> }
> 
> func process_ext_universal() {
> 		switch (subtype) {
> 				case EXT_NEW_BACK_TO_FUTURE:
> 						process_ext_back_to_future();
> 					  break;
> 				default:
> 						// unknown extension header
> 						// do nothing, simple ignore it
> 						// great!
> 					  break;
> 		}
> 
> 		// We know the extact len of the
> 		// ext hdr, for known AND unknown (upcoming)
> 		// universal extension header, because they are
> 		// always encoded in hdr_ext_len - really great!
> 		return hdr->hdr_ext_len;
> }
> 
> func process_ext_hop_hop() {
> 		// do hop-by-hop processing here
> 		//
> 		// We return the exact length of this header, we must
> 		// known the length and format in advance.
> 		return EXT_HEADER_KNOWN_LENGTH
> }
> 
> 
> I hope the text/pseudo-code was understandable! ;)
> 
> 
> Cheers and a nice weekend,
> 
> Hagen