Subject: Re: [Mip6] Deprecating Routing Header Type 0

From: Tim Enos <[email-masked]>
Date: Tue, 26 Jun 2007 18:24:19 -0500 (CDT)

Hi Vijay/all,

<snip>

>
>True. But there were other emails on the IPv6 mailing list which
>said block all, then enable for each application.

Good point, and IMO such an approach would be a bit draconian. Given the ability to do so, filtering on RH type should be what people do.

Even so, _my_ (main) focus is what the authors of the would-be spec are saying and writing. Given that, and what appears to be the majority viewpoint in the group, RH2 is safe.

> I would like "block RH0, allow all other", at least as far as IETF specification goes.

I am thinking that specifying firewall policy for the remaining RH types is probably beyond the scope of the draft.

To my knowledge, the purpose of the draft was merely to deprecate RH0 and say why.

That said, I'd not argue the point (here or elsewhere) and defer to group judgement.

FWIW, IMO "block RH0, allow all other" is reasonable. Given an ability to filter per RH type, that would be one of 251 (2^n - 5) remaining possibilities, where:

n=8 (number of bits in the Routing Type field), and the (-5) comes from adding:

(-1) for a deprecated RH0

(-1) for Nimrod which is RH1

(-1) for MIPv6 which is RH2

(-1) for RFC3692-style Experiment 1 which is RH253

(-1) for RFC3692-style Experiment 2 which is RH254

I got the above from http://www.iana.org/assignments/ipv6-parameters

> In practice, it could be different and not in our control.

I would expect that to be true as well.

There may well be some extant firewall implementations that lack the granularity to filter per RH type.

The question at each such site then becomes one of "Shall we permit all RH types, or deny all of them?"

Again, I don't think the answer to that question is best answered in the RH0 deprecation draft.

Best Regards,

Tim
Rom 8:28

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6