Subject: comments on draft-baker-6man-hbh-header-handling

From: "C. M. Heard" <[email-masked]>
Date: Tue, 10 Nov 2015 20:06:47 -0800

Regarding Section 2.3, Adding headers or options in transit:

   Use cases under current consideration take this a step further: a
   router or middleware process MAY add an extension header, MAY add an
   option to the header, which may extend the length of the Hop-by-Hop
   Extension Header, or MAY process such an option in a manner that
   extends both the length of the option and the Extension Header
   containing it.

This seems to me to be a violation of the basic architectural assumptions of
RFC 2460, and I don’t think that the 6man WG should go in that direction.  I
would prefer to see this section of the draft removed and for RFC 2460bis to
state that processing at forwarding nodes MUST NOT alter the length of an
IPv6 option or of the extension header in which it resides.

Mike Heard

---

From: [email-masked]
Date: Wed, 11 Nov 2015 08:48:36 +0100

> IPv6 option or of the extension header in which it resides.

Yes, header injection would be a major change to the protocol and I believe fundamentally incompatible with taking RFC2460 to Internet standard.

I would be perfectly fine with the work on header injection continuing outside of the context of RFC2460bis.

Best regards,
Ole

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 11 Nov 2015 17:52:44 -0800

> outside of the context of RFC2460bis.

If that means having 6man endorse standards-track (or even
experimental) documents that permit the length of an IPv6
packet to be changed by an intermediate system without
adding another IPv6 header, then I'm afraid I don't agree.

Rather than repeat previous discussion let me just point to
this message by Brian Carpenter:

http://www.ietf.org/mail-archive/web/ipv6/current/msg22830.html

Note that the objections to header injection apply equally to
options whose length can change in transit.  I'd like to see
the 6man WG weigh in against both.

//cmh