RE: List of IPv6 multihoming drafts

["marcelo bagnulo" <marcelo@it.uc3m.es>]

Hi Ole,

> Iljitsch,
>
> >> > - Extension Header for Site-Multi-homing support
> >> >   Problem for router vendors to add new header in hardware.
> >
> >> There is no need that the proposed extension header is supported in ALL
> >> routers.
> >
> > Essentially, the hardware guys say they need to specifically support a
> > header in hardware to be able to forward packets having this header in
> > it in the fast path. See the message I just posted to ipv6mh:
>
> that is not strictly true. for forwarding a packet there is no need to
> look at the extension header chain, apart from the hop-by-hop option
> case (hop by hop is typically done in software so don't expect much
> performance). for packet filtering the extension headers will have to
> be supported if parsing the subsequent headers are required. unknown
> extension headers should be expected by all implementations, not too
> dissimilar to an encrypted packet.
>
> so a solution which:
>  - don't use hop-by-hop
>  - don't use routing headers
>  - don't require insertion of extension headers
>
> should be all right to process for routers.
>
> I have only browsed the abovementioned draft. if it is expected that a
> typical case is that no route for the destination exists and that the
> alternative prefix option is there, that would require hardware
> changes.

It is expected that the header is there but it is not expected that the
header need to be processed fequently. I mean, extension header processing
will only be needed when an outage occurs, which it is not expected to be
very frequent.

I think that it would not be too much problem that packets that need to have
the newly defined extension header processed are coursed through the slow
path, since these are not expected to be the common case, only when a path
outage occurs.

My main concern is how packets that carry the newly defined extension header
but do not need header processing are processed by the routers, slow path or
fast path?

Thanks, marcelo

> e.g an implementation today could send the ICMP error message
> from software, and the hardware could rate-limit the punting of these
> packets, so software wouldn't even see them all.
>
> /ot
>