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

[Brian E Carpenter <[e-mail]>]

Fernando,

Thanks for the careful review. Most of your comments lead to fairly obvious
fixes, which we'll apply in the next version. Just a few points below which
may need discussion:

On 14/08/2013 09:28, Fernando Gont wrote:
...
> * Section 1:
>> Unfortunately, experience has showed that as a result,
>>    the network is not transparent to IPv6 extension headers.
> 
> I'd probably rephrase this sentence. A firewall's goal is, for instance,
> to police packets. So that lack of "transparency" is actually a goal
> they have (whether we like it or not).

True, but it's unfortunate from the point of view of the design of IPv6.
Speaking for myself only, I think the sentence is accurate - see the
next point.

...
> * 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. 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.

> 
> OTOH, the rest of the document is perfectly fine in this respect -- it
> acknowledges that some devices will look at the extension headers, and
> provides advice on what to do (e.g., "you should have an explicit policy
> regarding what to do with extension headers").
> 
> I guess I could live with a SHOULD (at least, it's not a "MUST") --
> however, in the light of reality, I'd probably relax this requirement.

...

> * 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. 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!)

    Brian