Transmission and Processing of IPv6 Extension Headers
RFC 7045

Note: This ballot was opened for revision 04 and is now closed.

(Brian Haberman) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

Comment (2013-10-08 for -04)
No email
send info
Could you provide any citations on the middle box behaviors, e.g., lack of support for all of 2460?

10 points to the INT area for the cite to Heller :)

"... Not just a failure to recognize such a header".  
Isn't this another Catch-22?  If a node doesn't recognize a header, how does it know if it's standard or not?  This also seems in contradiction to later guidance that unrecognized extensions may be dropped by default.

A flow chart or pseudo code might be useful in Section 2.1, like "if (known && standard) { /* policy */ }"

(Stewart Bryant) No Objection

Comment (2013-10-09 for -04)
No email
send info

In section 2.1, I think that it would be helpful to the reader to use the 
option name, as well as the number.

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

Comment (2013-10-07 for -04)
No email
send info
Thanks for the work on this document. I have no objection to its publication and just two minor observations.


Section 1.1

A couple of points about the following paragraph:

   In this document "standard" IPv6 extension headers are those
   specified in detail by IETF standards actions.  "Experimental"
   extension headers are those defined by any Experimental RFC, and the
   experimental extension header values 253 and 254 defined by [RFC3692]
   and [RFC4727].  "Defined" extension headers are the "standard"
   extension headers plus the "experimental" ones.

My reading of the IANA registry (
protocol-numbers/protocol-numbers.xhtml) is that allocations can be made
by IESG Approval or Standards Action. I think both of those are covered
by what you call "standard".

I am not convinced that an experiment that uses an experimental code 
point needs to be documented in an Experimental RFC. 

Are 253 and 254 intended solely for experimental extension headers? 
Couldn't the experiment be an experimental payload protocol?


I find myself in I-wouldn't-have-done-it-this-way land, so this is, of
course, just a Comment for you to chew on and accept or reject according
to how it strikes you...

It seems to me unwise to create a new registry that duplicates
information held in another registry. By adding a column to the
"Assigned Internet Protocol Numbers" registry you are making it 
completely clear which are the IPv6 Extension Headers. Rather than risk 
having this registry out of step with your new "IPv6 Extension Header
Types registry", I would have had the existing, empty "IPv6 Next Header
Types" registry redirect users to the "Assigned Internet Protocol
Numbers" registry and mention the existence of the specific column that
identifies extension headers.

(Stephen Farrell) No Objection

Comment (2013-10-08 for -04)
No email
send info
- 2.1 says nodes SHOULD forward rfc4727 experimental
headers, but earlier said that its ok (nodes MAY) default
to not forwarding packets with experimental headers. I
think you need to add an "unless otherwise stated here"
to the statement about defaults for experimental headers.

- section 4: Is it wise to ask IANA to "redirect" users
from one (empty) registry to another? That could be the
start of a slippery slope turning IANA registries into a
miasma of hypertext;-) Maybe it'd be better to ask that
IANA mark that registry as having being replaced by this
new one. Also - what if someone else asks IANA to add an
entry to the currently empty registry but not the new one
- is it clear what should happen in that case?

(Joel Jaeggli) (was Discuss) No Objection

Comment (2013-10-10 for -04)
No email
send info
Converting the discuss to a comment on the assumption the proposed text will make it into the document under brian's watch.

If you need to find the transport header due to configured policy and you can't due to being unable to parse the extensions chain your configured action will be to drop. That perhaps weasels it's way through section 2.1 requirements but it's still quite ugly.

former discuss

This is a dicuss because I'd like to see if I'm in the rough in this.

Devices generally considered to be IP routers in fact are able to or find it necessary to forward on the basis of headers other than the IP header e.g. the transport header. By the definition applied in the problem statement all ipv6 capable routers in the internet that  I'm aware are or are capable of being middleboxes. 

I would welcome the existence proof of an ipv6 capable router which is not capable of being a middlebox by the definition applied in the problem statement.

I'm not sure that's a glaring flaw in the document but it certainly is with our vocabulary around taxonomy if true.

Barry Leiba No Objection

Comment (2013-10-04 for -04)
No email
send info
As "Catch 22" is one of my favourite books ( ), it pleases me to know that there'll be an RFC with a reference to it.

-- Section 4 --

   Additionally, IANA is requested to make the existing empty IPv6 Next
   Header Types registry redirect users to a new IPv6 Extension Header
   Types registry.  It will contain only those protocol numbers which
   are also marked as IPv6 Extension Header types in the Assigned
   Internet Protocol Numbers registry.

Two small points here:

1. "It" in the second sentence is ambiguous: it could refer to either of the registries mentioned in the first sentence.  I suggest making it "The IPv6 Extension Header Types registry will contain...".

2. Is it your intent that the (empty) IPv6 Next Header Types registry also be closed to new registrations?  Whether or not, it would be best to make that clear.

(Ted Lemon) No Objection

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection