Francis,

On Mon 26 Sep '05 at 12:51 Francis Dupont <[EMAIL PROTECTED]> wrote:
> 
>  In your previous mail you wrote:
>
>    > => IMHO you'd like to have a more concrete operational recommendation.
>    
>    Yes, but I'd meant as opposed to a mandate that "routers SHOULD NOT
>    forward"...
>    
>    I'd think that most routers currently only know about link-local, 
> multicast,
>    unspecified and loop-back addresses in the forwarding path.
>    
>    RFC3849 doesn't mention routers, i.e. it's perfectly valid for a router to
>    forward a packet with a src/dst within the prefix. The onus is on
>    the operator to filter the prefix.
>    
> => RFC 3849 is different because it wants to limit the scope of the
> doc prefix. In KHI we simply don't want to see the prefix in IP headers
> so the requirement (don't route) is stronger than filtering.

RFC 3849 seems to be very similar imho, as it suggests using packet filters to
stop forwarding, as well as filtering the prefix from routing.

You shouldn't see the documentation prefix in the src or dst of any packet.

,----[RFC 3849]----
| 3.  Operational Implications
| 
|    This assignment implies that IPv6 network operators should add this
|    address prefix to the list of non-routeable IPv6 address space, and
|    if packet filters are deployed, then this address prefix should be
|    added to packet filters.
`----

If you filter traffic and routes at the edge of the DFZ, I think you'd get the
desired behaviour.

Placing a requirement directly on routers is a lot tougher than placing a
requirement on the operators. To support the current wording, every router
vendor would have to update their code, and then every customer would have to
upgrade every single router. This of course, would then have to be possibly
undone come January 1st 2009.

I think it is better to say that routers must be configurable with a wide
range of options, which allow the operators to accomplish these tasks.

Furthermore, it's nicer to keep the core forwarding simple, and put the
intelligence towards the edge of the network.


A.

-- 
Alun Evans
IOS Software Engineer, cisco Systems.
http://www.cisco.com/go/ipv6/

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to