RE: hop-by-hop and router alert options [Re: Question about use o f RSVP in Production Networks]
Tschofenig Hannes <hannes.tschofenig@siemens.com> Wed, 11 August 2004 13:01 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 JAA01431; Wed, 11 Aug 2004 09:01:41 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BusoP-0006zH-Fg; Wed, 11 Aug 2004 09:06:37 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Busgo-00031G-5c; Wed, 11 Aug 2004 08:58:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BusZS-0001dg-0v for ietf@megatron.ietf.org; Wed, 11 Aug 2004 08:51:10 -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 IAA00895 for <ietf@ietf.org>; Wed, 11 Aug 2004 08:51:08 -0400 (EDT)
Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuseB-0006oH-Ec for ietf@ietf.org; Wed, 11 Aug 2004 08:56:04 -0400
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i7BCp40T009185; Wed, 11 Aug 2004 14:51:04 +0200
Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i7BCogNW027337; Wed, 11 Aug 2004 14:50:52 +0200
Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <P8C2SD7C>; Wed, 11 Aug 2004 14:50:42 +0200
Message-ID: <2A8DB02E3018D411901B009027FD3A3F046864BA@mchp905a.mch.sbs.de>
From: Tschofenig Hannes <hannes.tschofenig@siemens.com>
To: 'Pekka Savola' <pekkas@netcore.fi>, ietf@ietf.org
Date: Wed, 11 Aug 2004 14:50:08 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Subject: RE: hop-by-hop and router alert options [Re: Question about use o f 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: 92df29fa99cf13e554b84c8374345c17
hi pekka, if you want to discover nodes somewhere along the path (between a particular source and a destination address) then you have a limited number of choices. the router alert option is one option and certainly not better or worse than other options. do you have a suggestion how to accomplish the same functionality (as required by rsvp or similar protocols) in a better fashion? ciao hannes > On Tue, 10 Aug 2004, Fleischman, Eric wrote: > > I am aware of some use of RSVP in labs but I am not aware > of any use > > of RSVP in production networks (i.e., real life networks people > > connect to the Internet with). Simultaneously, I am > encountering I-Ds > > and other work planning to use RSVP. This possible > disconnect concerns > > me. Therefore, I would appreciate being educated by anybody > using RSVP > > in production settings. Would you please let me know how > many devices, > > what applications, and how successful these deployments (if > any) are? > > Thank you. > > I'd be interested about this as well, but also in more general. > > I'd be in favor of deprecating the IP router alert option > completely. > Effectively this affects RSVP and MLD *). I'd want to > similarly do away with the IPv6 Hop-by-Hop options. At the > very least, I'd like to prevent further standardization of > these options. > > 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. > on the core equipment which must run on hardware: effectively > this means that either these are ignored in any case > (nullifying the use of such options), or put on a "slow path" > (causing a potential for DoS). IMHO, it seems just simply > bad protocol design to require such behaviour. > > I'm interested what others think about this.. :) > > *) MLD should be relatively straight-forward to re-design > (just send the MLD reports to a link-local address which the > router is listening), or just keep it as is for now. RSVP > can probably thrown away without many tears. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- RE: hop-by-hop and router alert options [Re: Ques… Tschofenig Hannes