Re: List of IPv6 multihoming drafts

[Ole Troan <ot@cisco.com>]

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. 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