Re: Question: Hop-by-Hop Header and Router Alert

Suresh Krishnan <suresh.krishnan@ericsson.com> Mon, 26 May 2008 21:14 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3843E28C1EE; Mon, 26 May 2008 14:14:29 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 465C93A6BFC for <ipv6@core3.amsl.com>; Mon, 26 May 2008 14:14:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPh6iGSPM5G7 for <ipv6@core3.amsl.com>; Mon, 26 May 2008 14:14:26 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id C1AB528C1E1 for <ipv6@ietf.org>; Mon, 26 May 2008 14:14:25 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m4QLEQtX028103; Mon, 26 May 2008 16:14:26 -0500
Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 May 2008 16:14:26 -0500
Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 May 2008 16:14:25 -0500
Message-ID: <483B27A1.7040705@ericsson.com>
Date: Mon, 26 May 2008 17:12:01 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: SpawnRR@gmx.de
Subject: Re: Question: Hop-by-Hop Header and Router Alert
References: <20080526133239.311900@gmx.net>
In-Reply-To: <20080526133239.311900@gmx.net>
X-OriginalArrivalTime: 26 May 2008 21:14:25.0990 (UTC) FILETIME=[7A0E5E60:01C8BF75]
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Hi Bernd,

SpawnRR@gmx.de wrote:
> Hi all, 
> 
> I’m contacting you as I’ve a question regarding the Hop-by-Hop header 
> option ‘Router Alert’ and its exact use. I hope I don't disturb you...

I am generally against any new proposal that uses hop by hop options 
(including router alerts) since they could increase the processing loads 
on intermediate routers and could be used as a DoS vector,

> 
> Currently I’m playing with some new ideas regarding mobile IP.
> These ideas include new messages and so on. The new messages are
> included within IPv6 packages and send toward a certain destination.
> While sending these messages toward the final destination it is
> necessary for them to be examined by routers on the paths. Hence,
> the Hop-by-Hop header with the ‘Router Alert’ option SHOULD be used
> indicating that the contents of the datagram may be interesting to
> the router. To give the router a hint about the datagram contents
> the router alert’s value field SHOULD be used therefore and inform
> the router about the contents of the payload or about the following
> IPv6 header, e. g. ICMPv6 message.
> 
> First question: 
> 
> Would it be okay to use the router alert option and its value field
> to indicate the router that it should not only process the hop-by-hop
> header before forwarding the message to the next hop,  but also to
> process the next header within the IPv6 packet, e.g. a ICMPv6
> message?

The router alert option does not have any processing rules associated 
with it. It just says "hey router, you need to take a closer look at the 
packet". This usually results (at least in our implementation) to take 
out the packet from the forwarding plane (fast path) and send it off to 
the control plane (slow path) for further processing. Here it will be 
examined in detail based on the applications that have registered to 
receive such packets (RSVP,MLD etc.). So your application will receive a 
copy of this packet and after that it can do whatever it wants to do.

> 
> Second question:
> 
> What will happen if a router doesn’t recognize the value in the
> router alert’s value field? Will it continue parsing the datagram
> and then forward the packet to the next hop (two MSB in the 
> Hop-by-Hop option type field set to ‘00’), or will it immediately
> stop parsing and forward the received IPv6 packet to the next 
> hop (two MSB in the Hop-by-Hop option type field set to ‘00’)?

The router code will not see this as an error. It will forward the 
packet through as if nothing happened. This is required for incremental 
deployment(e.g. non RSVP routers among RSVP routers)

Cheers
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------