Subject: Re: draft-ietf-6man-exthdr-02.txt

From: RJ Atkinson <[email-masked]>
Date: Sun, 17 Apr 2011 16:54:28 -0400

Earlier, Hing-Kam Lam wrote:
> I thought we were very close to the WG LC last time and 
> the new version is addressing all the points raised. 

Unfortunately, the new version unfortunately does not address 
my comments, or those of others with similar concerns about the 
operational impacts of ANY new IPv6 headers on existing IPv6 
deployments with routers containing silicon (e.g. ASIC, FPGA) 
forwarding engines that parse/parse-past the currently defined 
set of IPv6 headers and extensions.

As someone else noted recently on the IPv6 Ops list, 
in the IETF words such as "SHOULD" or "SHOULD NOT" are 
entirely ignorable.  So those don't address my concerns.

As I've said before, I do think that with some specific edits 
to tighten up the wording (e.g. using words such as "MUST NOT" 
and requiring more specific justification & documentation
than in a normal standards-action if one proposes defining
any new IPv6 header), the draft could be edited into
a form where it would be widely agreeable.

I provided specific suggestions in the past on this,
which I don't see reflected in the latest text.  Perhaps
I've overlooked something.  I am on travel, which means 
that I am both short of time and have VERY limited Internet 
access.  

I will try to propose some specific edits to this draft,
but I doubt I will be able to post a note to this list
with those proposed edits until end of week (at earliest).

Cheers,

Ran

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 19 Apr 2011 16:44:38 -0400

Hi Ran,

> a form where it would be widely agreeable.

    The base IPv6 standard [RFC2460] allows the use of both extension
    headers and destination options in order to encode optional
    destination information in an IPv6 packet.  The use of destination
    options to encode this information, provides more flexible handling
    characteristics and better backward compatibility than using
    extension headers.  Because of this, implementations SHOULD use
    destination options as the preferred mechanism for encoding optional
    destination information, and use a new extension header only if
    destination options do not satisfy their needs.  The request for
    creation of a new IPv6 extension header MUST be accompanied by an
    specific explanation of why destination options could not be used to
    convey this information.

This was the text I have added in version -02 in response to your 
comments. This text discourages creation of new extension headers and 
recommends using an existing extension header (dest opts). What do you 
think is missing here?

> with those proposed edits until end of week (at earliest).

OK. I will look forward to your proposal.

Thanks
Suresh