Re: hop-by-hop and router alert options [Re: Question about use of RSVP in Production Networks]

Florian Weimer <fw@deneb.enyo.de> Wed, 11 August 2004 19:07 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28688; Wed, 11 Aug 2004 15:07:57 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuyWu-0005gd-2n; Wed, 11 Aug 2004 15:12:57 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuyNh-0000yE-9j; Wed, 11 Aug 2004 15:03:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuyCV-0001hp-Uo for ietf@megatron.ietf.org; Wed, 11 Aug 2004 14:51:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26811 for <ietf@ietf.org>; Wed, 11 Aug 2004 14:51:50 -0400 (EDT)
Received: from mail.enyo.de ([212.9.189.167]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuyHI-0005FV-Oy for ietf@ietf.org; Wed, 11 Aug 2004 14:56:50 -0400
Received: (debugging) helo=deneb.enyo.de ip=212.9.189.171 name=deneb.enyo.de
Received: from deneb.enyo.de ([212.9.189.171]) by mail.enyo.de with esmtp id 1BuyCR-00081D-HC; Wed, 11 Aug 2004 20:51:47 +0200
Received: from fw by deneb.enyo.de with local (Exim 4.34) id 1BuyCP-0003Nh-K6; Wed, 11 Aug 2004 20:51:45 +0200
To: Pekka Savola <pekkas@netcore.fi>
References: <Pine.LNX.4.44.0408111448190.24098-100000@netcore.fi>
From: Florian Weimer <fw@deneb.enyo.de>
Date: Wed, 11 Aug 2004 20:51:45 +0200
In-Reply-To: <Pine.LNX.4.44.0408111448190.24098-100000@netcore.fi> (Pekka Savola's message of "Wed, 11 Aug 2004 14:58:29 +0300 (EEST)")
Message-ID: <87657pwlry.fsf@deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: ietf@ietf.org
Subject: Re: hop-by-hop and router alert options [Re: Question about use of RSVP in Production Networks]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f

* Pekka Savola:

> The justification is simple: any "magic" packets which all routers on
> the path must somehow examine and process seems a very dubious concept
> when we want to avoid DoS attacks etc.

Any packet with IP options is more or less in that category right now,
so it's a very long way to go.[1]  IPv6 seems to make things even
worse. 8-(

1. Some platforms support dropping IPv4 packets with options.  As
   discussed before, existing contractual obligations with respect to
   source routing may prevent you from enabling such a feature.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf