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: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
