On 14/08/2013 19:59, Fernando Gont wrote:
> Hi, Brian,
>
> On 08/14/2013 01:29 AM, Brian E Carpenter wrote:
>> ...
>>> * Section 2.1:
>>>> Any forwarding node along an IPv6 packet's path, which forwards the
>>>> packet for any reason, SHOULD do so regardless of any extension
>>>> headers that are present, as required by RFC 2460.
>>> I find this particular requirement a bit troublesome. Truth is that many
>>> devices violate this requirement, and will always will.
>> Yes, but the IPv6 design really does require this.
>
> That's my point: is that a sensible requirement? For instance, for the
> time being (Flow Label not used), there's no other way to identify flows
> than to break this reuirement.
Which is indeed why I worked hard to get RFC 6437 written. But changing
this aspect of IPv6 design would be a *really* big discussion.
>
>
>> I think the
>> SHOULD is right, because RFC 2119 says that it means "there
>> may exist valid reasons in particular circumstances to ignore a
>> particular item, but the full implications must be understood and
>> carefully weighed before choosing a different course." That is
>> a perfectly reasonable choice for the person managing a firewall
>> to make, but it doesn't change the IPv6 design assumption.
>
> I have no issues with this. -- Although I'd note that this text gives
> the idea that processing the extesion header chain is more an exception
> than a rule.
>
>
>
>>> * Section 4:
>>>> This list excludes both type 59, No Next Header, [RFC2460], which is
>>>> not an extension header as such, and type 139, HIP, [RFC5201], which
>>>> is experimental.
>>> If RFC5201 specifies an extension header, why shouldn't it be listed in
>>> the registry? (Disclaimer: I haven't even looked at RFC5201... so I
>>> might be missing something).
>> This is a bit tricky. If HIP was a standards-track protocol it would
>> be easy, but since it's experimental, it really doesn't seem realistic
>> to hint that firewalls should allow it by default.
>
> So the question here is:
> 1) Are we creating an IANA registry for Ext Headers or,
> 2) Are we creating a registry for ext headers that, by default, should
> be passed?
>
> If the former, HIP should be in. If the latter, it shouldn't.
>
> Besides, if we imply that HIP should be filtered but they use some
> specific "Next Header" value (as opposed to 253 or 254), then whatever
> value is currently used for the HIP ext header will be unusable on the
> public Internet even if the the document eventually becomes a Proposed
> Standard.
>
>
>
>> Maybe we should
>> change the IANA registry to include the experimental ones, but with
>> a special tag? (Extension headers 253 and 254 are also tricky, because
>> they are experimental values defined by a standards track RFC. Go figure!)
>
> I think we might be able to do both "1)" and "2)" above by adding a tag
> along the lines of "not expected in the public Internet"? (with the
> implication that "it's okay to filter").
Something like that, yes. We'll try some words in the next version.
Brian
>
>
> Cheers,
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
