Re: Detailed review of draft-ietf-6man-ext-transmit-02

[Fernando Gont <[e-mail]>]

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.


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


Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492