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

Hagen Paul Pfeifer <hagen@jauu.net> Sat, 24 October 2015 12:48 UTC

Return-Path: <hagen@jauu.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB131B3530; Sat, 24 Oct 2015 05:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zea-NIXvd9bC; Sat, 24 Oct 2015 05:48:09 -0700 (PDT)
Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1F61B352D; Sat, 24 Oct 2015 05:48:08 -0700 (PDT)
Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 0B28642511; Sat, 24 Oct 2015 14:48:06 +0200 (CEST)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp1.mailbox.org ([80.241.60.240]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id PIqbsEk1BTpy; Sat, 24 Oct 2015 14:48:04 +0200 (CEST)
Date: Sat, 24 Oct 2015 14:48:03 +0200
From: Hagen Paul Pfeifer <hagen@jauu.net>
To: Bob Hinden <bob.hinden@gmail.com>
Subject: Re: Comments on <draft-gont-6man-rfc6564bis-01>
Message-ID: <20151024124803.GA4053@virgo.local>
References: <5ABE9F3B-FD35-4288-B7AE-A154A4DF384C@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <5ABE9F3B-FD35-4288-B7AE-A154A4DF384C@gmail.com>
X-Key-Id: 98350C22
X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22
X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/VO4HiUaBgTD0d6n_R38abg-aA1o>
Cc: IPv6 List <ipv6@ietf.org>, draft-gont-6man-rfc6564bis@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Oct 2015 12:48:11 -0000

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

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.

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

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