Skip to main content

Transmission and Processing of IPv6 Extension Headers
draft-ietf-6man-ext-transmit-05

Yes

(Brian Haberman)

No Objection

(Benoît Claise)
(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Pete Resnick)
(Sean Turner)
(Spencer Dawkins)
(Ted Lemon)

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

Brian Haberman Former IESG member
Yes
Yes (for -04) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2013-10-07 for -04) Unknown
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 (http://www.iana.org/assignments/
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.
Barry Leiba Former IESG member
No Objection
No Objection (2013-10-04 for -04) Unknown
As "Catch 22" is one of my favourite books ( http://staringatemptypages.blogspot.com/2007/10/you-must-read-this.html ), 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.
Benoît Claise Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Joel Jaeggli Former IESG member
(was Discuss) No Objection
No Objection (2013-10-10 for -04) Unknown
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.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (2013-10-08 for -04) Unknown
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 */ }"
Sean Turner Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2013-10-08 for -04) Unknown
- 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?
Stewart Bryant Former IESG member
No Objection
No Objection (2013-10-09 for -04) Unknown
Comment:

In section 2.1, I think that it would be helpful to the reader to use the 
option name, as well as the number.
Ted Lemon Former IESG member
No Objection
No Objection (for -04) Unknown