Re: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

Fred, On 12/10/2013 08:56, Templin, Fred L wrote: > Hi Brian, > >> -Original Message- >> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] >> Sent: Friday, October 11, 2013 12:50 PM >> To: Fernando Gont >> Cc: Templin, Fred L; Ray Hunter; 6man Mailing List; i...@ietf.org >> Sub

RE: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

Hi Brian, > -Original Message- > From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] > Sent: Friday, October 11, 2013 12:50 PM > To: Fernando Gont > Cc: Templin, Fred L; Ray Hunter; 6man Mailing List; i...@ietf.org > Subject: Re: Last Call: > (Implications of Oversized IPv6 Heade

Re: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

On 12/10/2013 06:04, Fernando Gont wrote: ... > P.S.: Reegarding enforcing a limit on the length of the header chain, I > must say I symphatize with that (for instance, check the last individual > version of this I-D, and you'll find exactly that). But the wg didn't > want that in -- and I did rais

RE: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

Hi Fernando, > -Original Message- > From: Fernando Gont [mailto:fg...@si6networks.com] > Sent: Friday, October 11, 2013 10:04 AM > To: Templin, Fred L; Ray Hunter; brian.e.carpen...@gmail.com > Cc: 6man Mailing List; i...@ietf.org > Subject: Re: Last Call: > (Implications of Oversized IPv

RE: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

Hi Ray, > -Original Message- > From: Ray Hunter [mailto:v6...@globis.net] > Sent: Friday, October 11, 2013 9:59 AM > To: Templin, Fred L > Cc: brian.e.carpen...@gmail.com; i...@ietf.org; 6man Mailing List > Subject: Re: Last Call: > (Implications of Oversized IPv6 Header Chains) to Propos

Re: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

On 10/11/2013 12:36 PM, Templin, Fred L wrote: >> FWIW, my idea of the I-D is that it says "look, if you don't put all >> this info into the first fragment, it's extremely likely that your >> packets will be dropped". That doesn't mean that a middle-box may want >> to look further. But looking furt

Re: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

> Templin, Fred L > 11 October 2013 17:33 > Hi Ray, > >> -Original Message- >> From: Ray Hunter [mailto:v6...@globis.net] >> Sent: Friday, October 11, 2013 12:49 AM >> To: Templin, Fred L; brian.e.carpen...@gmail.com >> Cc: i...@ietf.org; 6man Mailing List

WG Review: IPv6 Maintenance (6man)

The IPv6 Maintenance (6man) working group in the Internet Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at

RE: Adrian Farrel's No Objection on draft-ietf-6man-ext-transmit-04: (with COMMENT)

Sorry Brian; here is the correct explanation: > > They must have just made that up; there's no justification for it. > > It could be an unknown extension header of unknown length, or it > > could be an unknown payload of unknown length. In real life > > I'd expect firewalls to default-drop such pa

RE: Adrian Farrel's No Objection on draft-ietf-6man-ext-transmit-04: (with COMMENT)

Hi Brian, > -Original Message- > From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] > Sent: Thursday, October 10, 2013 9:15 PM > To: Templin, Fred L > Cc: C. M. Heard; 6man-cha...@tools.ietf.org; Adrian Farrel; draft-ietf- > 6man-ext-trans...@tools.ietf.org; ipv6@ietf.org > Subje

RE: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

Hi Fernando, > -Original Message- > From: Fernando Gont [mailto:fg...@si6networks.com] > Sent: Friday, October 11, 2013 1:36 AM > To: Ray Hunter; Templin, Fred L; brian.e.carpen...@gmail.com > Cc: 6man Mailing List; i...@ietf.org > Subject: Re: Last Call: > (Implications of Oversized IPv6

RE: RE: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

Hi Ray, > -Original Message- > From: Ray Hunter [mailto:v6...@globis.net] > Sent: Friday, October 11, 2013 12:49 AM > To: Templin, Fred L; brian.e.carpen...@gmail.com > Cc: i...@ietf.org; 6man Mailing List > Subject: Re: RE: Last Call: 08.txt> (Implications of Oversized IPv6 Header Chains

6man IETF 88 Call for agenda items

We have asked for a two and a half hour slot in Vancouver for the 6MAN working group. The preliminary agenda has given us the 0900-1130 Monday morning slot. If you have a draft you would like to discuss, please send your request for agenda time to the 6man chairs. Please include in the request,

Re: Stephen Farrell's No Objection on draft-ietf-6man-ext-transmit-04: (with COMMENT)

On 10/11/2013 05:24 AM, Brian E Carpenter wrote: > On 08/10/2013 23:31, Stephen Farrell wrote: > ... >> - 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

I-D Action: draft-ietf-6man-stable-privacy-addresses-14.txt

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 : A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration

Re: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

On 10/11/2013 04:48 AM, Ray Hunter wrote: > > I think the draft does what it can in a pragmatic manner, but might > benefit from some acknowledgement that this security approach of > applying parsing at a single perimeter can never ever catch all variants > of transporting FOO over BAR. FWIW, my

Re: RE: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

Templin, Fred L wrote: > Hi Brian, > > Responding in a slightly re-arranged order: > >> The problem is that you are asserting that middleboxes that a tunnel >> passes through are expected to examine the complete header chain of >> the encapsulated packet even if the encapsulated packet is a fragmen