Subject: draft-ietf-6man-ext-transmit-01

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Jun 2013 11:09:09 +1200

If you're following the current discussion on v6ops, it
seems that we need to decide whether to proceed with the
subject draft, so that there is at least a marker for what
forwarding nodes are supposed to do about extension headers.

So, are there any more comments on the draft?

   Brian

> Hi,
> 
> This version is intended to respond to Ray Hunter's comments.
> There are two important changes:
> 
> 1. The MUST NOT that Ray mentioned is now SHOULD NOT. Really
> this is a matter of internal consistency in the document, since
> the exceptions to the SHOULD NOT are specified, so the MUST NOT
> was inappropriate.
> 
> 2. It is now made explicit that only standards-track extension
> headers are covered. That knocks out HIP, which is Experimental.
> 
> There are a few other changes of editorial nature.
> 
>    Brian + Sheng
> 
> -------- Original Message --------
> Subject: I-D Action: draft-ietf-6man-ext-transmit-01.txt
> Date: Wed, 29 May 2013 13:21:08 -0700
> From: internet-drafts at ietf.org
> To: i-d-announce at ietf.org
> CC: ipv6 at ietf.org
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
> 
> 	Title           : Transmission of IPv6 Extension Headers
> 	Author(s)       : Brian Carpenter
>                           Sheng Jiang
> 	Filename        : draft-ietf-6man-ext-transmit-01.txt
> 	Pages           : 9
> 	Date            : 2013-05-29
> 
> Abstract:
>    Various IPv6 extension headers have been standardised since the IPv6
>    standard was first published.  This document updates RFC 2460 to
>    clarify how intermediate nodes should deal with such extension
>    headers and with any that are defined in future.  It also specifies
>    how extension headers should be registered by IANA, with a
>    corresponding minor update to RFC 2780.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-ext-transmit
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-01
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ext-transmit-01
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

---

From: Nalini Elkins <[email-masked]>
Date: Wed, 5 Jun 2013 21:23:58 -0700 (PDT)

Brian,

Two questions:

First:

>> Some tricky and potentially malicious cases will be avoided by forbidding

>> very long chains of extension headers that need to be fragmented [I-D.ietf-6man-oversized-header-chain]. 

I wonder if this is the place to define "very long"?

Second:

Are there other RFCs which have rules for what "middle boxes" will do?   I am not referring to translation techniques such as SIIT, etc. which is implemented in some load balancers.
I guess I am wondering more about if there is a precedent for regulating what packets firewalls will and will not forward.

BTW, thanks so much for doing this!

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Jun 2013 16:47:34 +1200

On 06/06/2013 16:23, Nalini Elkins wrote:
>>> very long chains of extension headers that need to be
>>> fragmented [I-D.ietf-6man-oversized-header-chain].
> 

I guess those two words can be deleted - the issue is only that
the header chain gets fragmented at all. The full discussion is
in the cited draft, of course.

> 
> Second:
> 
> Are there other RFCs which have rules for what "middle boxes"
> will do?   I am not referring to translation techniques such
> as SIIT, etc. which is implemented in some load balancers. I
> guess I am wondering more about if there is a precedent for
> regulating what packets firewalls will and will not forward.

The IETF hasn't done much about firewalls at all. This search
produces far more expired drafts than anything else:
https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=

   Brian

> Nalini Elkins Inside Products, Inc. (831) 659-8360 
> www.insidethestack.com

---

From: Nalini Elkins <[email-masked]>
Date: Thu, 6 Jun 2013 07:24:32 -0700 (PDT)

>>> Some tricky and potentially malicious cases will be avoided by forbidding very long chains of extension headers that need to be

>> I guess those two words can be deleted - the issue is only that the header chain gets fragmented at all. The full discussion is in the cited draft, of course.

I know the draft that you have cited and they do not define "long" either.  There has been quite a bit of discussion about what "long" means and IMHO somewhere, someone needs to take some kind of reasonable stand. 

>>The IETF hasn't done much about firewalls at all. This search produces far more expired drafts than anything else:

The reason I asked is because I think defining RFCs or rules for firewalls is a really good thing to do but if the vendors are not in the habit of having to be compliant, then why would they pay attention to this draft that we are discussing?  I actually think maybe an RFC which explicitly talks about firewalls is probably a good thing to do.  Now, getting vendors to comply...
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Brian E Carpenter <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: 6man <[email-masked]> 
Sent: Wednesday, June 5, 2013 9:47 PM
Subject: Re: draft-ietf-6man-ext-transmit-01

   Brian

---

From: Ray Hunter <[email-masked]>
Date: Thu, 06 Jun 2013 17:32:50 +0200

I can confirm that the 01 version does address all of my comments, and I
now support.

Thanks,
RayH