Re: RV: (ipv6mh) hardware support for extension headers

[Pekka Savola <pekkas@netcore.fi>]

On Mon, 27 Oct 2003, marcelo bagnulo wrote:
> This is a message where Tony Hain explained why it is difficult to support
> new extension headers in all packets,
> This message was sent to ipv6mh list a while ago...
> Hope this helps to explain Jordi's concerns.

Please check out draft-savola-v6ops-firewalling-02.txt.  This should cover 
this case as well.  As identified in the draft, there are a few possible 
ways forward:

 - never do any new extension headers
 - specify that new extension headers must be done in TLV format, making 
them more easily extensible (AND skippable!)
 - specify new things as destination or hop-by-hop options instead.

HTH

> > -----Mensaje original-----
> > De: Tony Hain [mailto:alh-ietf@tndh.net]
> > Enviado el: miércoles, 27 de noviembre de 2002 1:59
> > Para: 'marcelo bagnulo'; 'Michel Py'; 'Ole Troan'
> > CC: 'Jordi Palet Martinez'; 'ipv6mh'; 'Vladimir Ksinant'; 'Yoshifumi
> > Atarashi'; 'Suzuki Shinsuke'; 'Kazuaki Tsuchiya'; 'Elwyn Daview'
> > Asunto: RE: (ipv6mh) hardware support for extension headers
> >
> >
> > Marcelo,
> >
> > The basic problem is that network operators have been told that the
> > proper thing to do is filter on the L4 port. This means that all
> > hardware implementations that are expected to be deployed on a network
> > boundary have to be able to parse the L4 port. Since everyone has a
> > different definition of what router class is needed at a boundary, this
> > effectively means all routers have to support finding the L4 port in
> > hardware. This is required even though most of the deployed routers
> > never look at the extension headers or the L4 port. The result is that
> > any new extension header that will be carried along with the current
> > common set, will cause packets to drop off the fast path. Yes, border
> > specific routers could be developed, but the market for them would be so
> > small, and the extra hardware necessary would be so much greater that
> > the result would be so expensive that nobody would ever buy them.
> >
> > Tony
> >
> >
> > > -----Original Message-----
> > > From: marcelo bagnulo [mailto:marcelo@it.uc3m.es]
> > > Sent: Monday, November 25, 2002 1:04 PM
> > > To: Michel Py; Ole Troan
> > > Cc: Jordi Palet Martinez; ipv6mh; Vladimir Ksinant; Yoshifumi
> > > Atarashi; Suzuki Shinsuke; Kazuaki Tsuchiya; Elwyn Daview
> > > Subject: RE: (ipv6mh) hardware support for extension headers
> > >
> > >
> > > Michel,
> > >
> > > if you don´t mind, i would split the question in two:
> > >
> > > - How would you rate the changes needed in routers in order
> > > to forward packets carrying the extesnion header WITHOUT
> > > PORCESSING it?
> > >
> > > - How would you rate the changes needed in routers in order
> > > to forward packets carrying the extesnion header and also
> > > process the extension header?
> > >
> > > Note that most routers will only forward packets containing
> > > the extesnion header without processing it.
> > >
> > > Thanks, marcelo
> > >
> > > > -----Mensaje original-----
> > > > De: Michel Py [mailto:michel@arneill-py.sacramento.ca.us]
> > > > Enviado el: domingo, 24 de noviembre de 2002 23:48
> > > > Para: Ole Troan
> > > > CC: Marcelo Bagnulo; Jordi Palet Martinez; ipv6mh; Vladimir
> > > Ksinant;
> > > > Yoshifumi Atarashi; Suzuki Shinsuke; Kazuaki Tsuchiya; Elwyn Daview
> > > > Asunto: RE: (ipv6mh) hardware support for extension headers
> > > >
> > > >
> > > > > Ole Troan wrote:
> > > > > the more serious issue with Marcelo's draft is that
> > > todays routers
> > > > > aren't built to send ICMP errors (or forward the packet
> > > in Marcelo's
> > > > > case), for every packet to an unknown destination.
> > > >
> > > > Dumb question for all router vendors:
> > > > Assuming that all political hurdles have been cleared, if
> > > you had to
> > > > implement (in silicon, for those of who that have hardware-assisted
> > > > routers) what Marcelo's draft requires, how would you rate
> > > the work it
> > > > would take?
> > > >
> > > > a) Piece of cake, just needs to be decided and would be in the next
> > > > version of the chips.
> > > > b) About the same as any other extension header.
> > > > c) Much more difficult than other extension headers you
> > > already have
> > > > implemented.
> > > >
> > > > Thanks
> > > > Michel.
> > > >
> > > >
> > >
> >
> 
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings