Subject: Interest in IPv6 Hop by Hop options

From: Alan Davy <[email-masked]>
Date: Wed, 04 Nov 2009 16:40:26 +0000

Hi All,

We are currently specifying an IPv6 hop by hop option which will be used 
to carry node related information along a path within a network domain. 
There has been previous proposals submitted to the IETF within this 
area, such as IPv6 Route Record [1] and Connection/Link Status 
Investigation[2]. We are aware of the reasons these proposals have been 
rejected previously, being mainly related to the problems of the hop by 
hop option and the operators unwillingness to share private data.

As such a technique has a variety of useful applications to management 
and monitoring, we believe that a standard method of managing data entry 
within an IPv6 hop by hop option along with standard data format 
templates can be of great benefit to the future development of in-line 
based network management and monitoring protocols. We would like to see 
if there is much interest in specifying such a draft and whether anyone 
would like to assist in the specification of such an Internet Draft. We 
wish to constrain this solution to intra domain (such as DiffServ).

Looking forward to some discussion on this issue.

[1] http://tools.ietf.org/html/draft-kitamura-ipv6-record-route-00
[2] http://tools.ietf.org/html/draft-ietf-ipngwg-hbh-ext-csi-02

Best Regards,
-- 

Alan Davy

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 4 Nov 2009 18:52:33 +0200

> hop option and the operators unwillingness to share private data.

Every router and middlebox on the path needs to parse HBH, which causes severe 
challenge with some hardware and/or software architecture. Hence, I believe 
many, if not all, network gears vendors hate HBH.

With HBH, you can in principle extend IPv6 routing to do really anything. But 
then you need to upgrade all the routers. And that's simply not going to 
happen. So basically, HBH is only useful in the mythical "walled garden" 
networks.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Alan Davy <[email-masked]>
Date: Thu, 12 Nov 2009 11:25:59 +0100

Hi Rémi,

> happen. So basically, HBH is only useful in the mythical "walled garden" 
The point of our proposed solution is to specify a common set of rules 
or guidelines for managing the entry of data into the hop by hop option 
header data field. The hop by hop option can be ignored by routers that 
do not support it or blocked by edge routers that do not like/recognise 
it. However by setting in place a standard interface, operators can use 
this feature to build future in-line network management and monitoring 
protocols.

Alan

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 12 Nov 2009 13:52:09 +0100

On Thu, 12 Nov 2009 11:25:59 +0100, Alan Davy <[email-masked]> wrote:
> it.

I wonder how that is possible. Middleboxes want to find the transport
header, and often don't like in-band data that they don't understand (think
of NATs and firewalls). Also hardware is often optimized for the case that
there is no hop-by-hop header. If there is, I understand in many cases,
packet processing will go through "slow path".

It's irrelevant whether your extension can be safely ignored - it will
still incur some processing overhead in any case. And *I* am only answering
your question why many people do not like HbH. I am not a network gear
vendor or operator myself.

-- 
Rémi Denis-Courmont

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 12 Nov 2009 11:29:12 -0500

> packet processing will go through "slow path".

(rja will beat me for this, but..)

if you can't predict what's at byte-offset X ... you have to punt to
'slow-path' (out of asic-land and into cpu/software land) to make a
decision, of skip processing that packet. 'skip processing' could mean
'drop on the floor' or 'pass on through'.

hop-by-hop options are a nasty can of worms. (variable length headers really)

> vendor or operator myself.

operations folk don't like things they can't control (easily) stealing
resources from their gear, and/or non-deterministic behaviour

"oops, 1kpps of hop-by-hop causes the cpu to hog out, which causes
isis to drop which causes bgp nexthops to disappear, which causes..."

sure, some of this could be ameliorated with better scheduling or
other bits, but... just not doing this is 'safer' for the gear. I
suspect HbH options will just get skipped (by config option) in gear
so an operator can decide to process these (on a less constrained
platform/network) or ignore them believing that whatever the HbH
option is it's not relevant to transit traffic.

-Chris