RE: WG Review: IPv6 Maintenance (6man)

Hi, Dear all > -Original Message- > From: Brian E Carpenter ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] > On Behalf Of > I think there's a missing goal, something like > > - Define relationship and boundary between DHCPv6-based and > RA/ND-based host configuration mechanisms. (

RE: draft-chakrabarti-nordmark-6man-efficient-nd - Proposing new use case "Set-and-forget off-line network"

Hi Anders, Thanks for your detail comments -- those are quite useful! Please see in-line. -Original Message- From: Anders Brandt [mailto:anders_bra...@sigmadesigns.com] Sent: Monday, September 02, 2013 2:44 AM To: ipv6@ietf.org; Pascal Thubert (pthubert); Samita Chakrabarti; Erik Nordma

Re: WG Review: IPv6 Maintenance (6man)

On 12/10/2013 05:38, The IESG wrote: > Mar 2014 - Develop approach for IPv6 Fragmentation Possibly ambitious, but it is the logical next step beyond draft-ietf-6man-oversized-header-chain. > Mar 2014 - Develop approaches for IPv6 Extension Headers (Hop-by-Hop > and Destination) Shouldn't th

RE: draft-chakrabarti-nordmark-6man-efficient-nd review

-Original Message- From: Andrew Yourtchenko [mailto:ayour...@cisco.com] Sent: Wednesday, August 21, 2013 2:36 AM To: Suresh Krishnan Cc: Samita Chakrabarti; nordm...@cisco.com; pthub...@cisco.com; m...@lilacglade.org; ipv6@ietf.org Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd review Hi

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

L >> Cc: Fernando Gont; 6man Mailing List; i...@ietf.org; Ray Hunter >> Subject: RE: Last Call: >> (Implications of Oversized IPv6 Header Chains) to Proposed Standard >> >> +1 >> >> Is there a way to decouple this discussion from draft-ietf-6man- >> o

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: Monday, October 14, 2013 12:34 PM > To: Templin, Fred L > Cc: Fernando Gont; Ray Hunter; 6man Mailing List; i...@ietf.org > Subject: Re: Last Call: > (Implicati

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

Fred, On 15/10/2013 06:38, Templin, Fred L wrote: ... >> We could have that discussion in 6man, sure, but I don't believe that >> it's >> relevant to the question of whether draft-ietf-6man-oversized-header- >> chain >> is ready. > > If it messes up tunnels, then it's not ready. That doesn't fol

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

Hi Ron, > -Original Message- > From: Ronald Bonica [mailto:rbon...@juniper.net] > Sent: Saturday, October 12, 2013 7:07 PM > To: Brian E Carpenter; Templin, Fred L > Cc: Fernando Gont; 6man Mailing List; i...@ietf.org; Ray Hunter > Subject: RE: Last Call: > (Impl

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 3:42 PM > To: Templin, Fred L > Cc: Fernando Gont; Ray Hunter; 6man Mailing List; i...@ietf.org > Subject: Re: Last Call: > (Implicati

Re: WG Review: IPv6 Maintenance (6man)

Would you expand a bit on this? Jul 2014 - Advance IPv6 core specifications to Internet standard And after the discussions in Berlin about fragmentation, the dates of the milestones look a bit ambitious to me. Regards, as On 10/11/13 2:38 PM, The IESG wrote: > The IPv6

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

+1 Is there a way to decouple this discussion from draft-ietf-6man-oversized-header-chain? I would be glad to discuss it in the context of a separate draft. Ron > > > > So, it wasn't necessarily the case that 1280 was a product of >

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

er; 6man Mailing List; i...@ietf.org >> Subject: 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 ch

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: > (Implicati

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: > (Impl

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 I

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

ail.com >> Cc: i...@ietf.org; 6man Mailing List >> Subject: Re: RE: Last Call: > 08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed >> Standard >> >> Templin, Fred L wrote: >>> Hi Brian, >>> >>> Responding in a slightly re-

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)

org; ipv6@ietf.org > Subject: Re: Adrian Farrel's No Objection on draft-ietf-6man-ext- > transmit-04: (with COMMENT) > > Fred, > > On 09/10/2013 04:28, Templin, Fred L wrote: > ... > > When Wireshark encounters a header type 253 or 254, it assumes it is > > an unkn

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: > (Impl

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

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

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 i

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

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 add an "unless otherwise stated here" > to the statement ab

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

Fred, On 09/10/2013 04:28, Templin, Fred L wrote: ... > When Wireshark encounters a header type 253 or 254, it assumes it is > an unknown extension header of length 8 bytes, then skips ahead and > attempts to parse anything that follows as additional headers. They must have just made that up; the

Re: Richard Barnes' No Objection on draft-ietf-6man-ext-transmit-04: (with COMMENT)

On 09/10/2013 04:44, Richard Barnes wrote: ... > Could you provide any citations on the middle box behaviors, e.g., lack > of support for all of 2460? The documentation of pretty much any firewall would do it, but that gets a bit like name-calling. The whole problem came to my attention when a stu

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

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 fragment. Yes, but ch

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

Fred, See below... On 10/10/2013 06:42, Templin, Fred L wrote: > Hi Ole, > >> -Original Message- >> From: Ole Troan [mailto:otr...@employees.org] >> Sent: Wednesday, October 09, 2013 10:31 AM >> To: Templin, Fred L >> Cc: Ronald Bonica; ipv6@ietf.org

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

Hi Ole, > -Original Message- > From: Ole Troan [mailto:otr...@employees.org] > Sent: Wednesday, October 09, 2013 10:31 AM > To: Templin, Fred L > Cc: Ronald Bonica; ipv6@ietf.org; i...@ietf.org > Subject: Re: Last Call: > (Implications of Oversized IPv6 Heade

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

Fred, >>>> -Original Message- >>>> From: Ronald Bonica [mailto:rbon...@juniper.net] >>>> Sent: Tuesday, October 08, 2013 5:46 PM >>>> To: Ole Troan; Templin, Fred L >>>> Cc: ipv6@ietf.org; i...@ietf.org >>>> Subje

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

Hi Ole, > -Original Message- > From: Ole Troan [mailto:otr...@employees.org] > Sent: Wednesday, October 09, 2013 9:54 AM > To: Templin, Fred L > Cc: Ronald Bonica; ipv6@ietf.org; i...@ietf.org > Subject: Re: Last Call: > (Implications of Oversized IPv6 Header Chains)

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

Fred, >> -Original Message- >> From: Ronald Bonica [mailto:rbon...@juniper.net] >> Sent: Tuesday, October 08, 2013 5:46 PM >> To: Ole Troan; Templin, Fred L >> Cc: ipv6@ietf.org; i...@ietf.org >> Subject: RE: Last Call: >> (Implications of

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

> -Original Message- > From: Ronald Bonica [mailto:rbon...@juniper.net] > Sent: Tuesday, October 08, 2013 5:46 PM > To: Ole Troan; Templin, Fred L > Cc: ipv6@ietf.org; i...@ietf.org > Subject: RE: Last Call: > (Implications of Oversized IPv6 Header Chains) to Pro

Re: Joel Jaeggli's Discuss on draft-ietf-6man-ext-transmit-04: (with DISCUSS and COMMENT)

Hi Brian, On 09.10.2013 01:10, Brian E Carpenter wrote: > I don't care about NAT66 but if you mean NPTv6, I suppose it's true. > Inserting "may" or perhaps "might" is OK by me. You are right, I meant NPTv6 - sorry didn't use the correct term. Regards, Roland ---

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

I agree with Ole. Ron > -Original Message- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Ole Troan > Sent: Tuesday, October 08, 2013 12:17 PM > To: Templin, Fred L > Cc: ipv6@ietf.org; i...@ietf.org; IETF-Announce > S

Re: Joel Jaeggli's Discuss on draft-ietf-6man-ext-transmit-04: (with DISCUSS and COMMENT)

On 09/10/2013 10:08, Roland Bless wrote: > Hi Brian, > > On 08.10.2013 21:45, Brian E Carpenter wrote: >> NEW >>Today, IPv6 packets are often forwarded not only on the basis of their >>first 40 bytes by straightforward IP routing. Some routers, and a >>variety of intermediate nodes oft

Re: Joel Jaeggli's Discuss on draft-ietf-6man-ext-transmit-04: (with DISCUSS and COMMENT)

On Oct 8, 2013, at 3:11 PM, Benoit Claise wrote: > FYI, there is a middlebox definition at > http://tools.ietf.org/html/rfc3303#section-2.1 > yes I'm aware of it… As with discussion that dwells on the question of what was an ip router of the future expected to be like in 1994 and although it

Re: Joel Jaeggli's Discuss on draft-ietf-6man-ext-transmit-04: (with DISCUSS and COMMENT)

FYI, there is a middlebox definition at http://tools.ietf.org/html/rfc3303#section-2.1 Regards, Benoit On Oct 8, 2013, at 12:45 PM, Brian E Carpenter wrote: Joel, Would this help? OLD Today, packets are often forwarded not only by straightforward IP routers, but also by a variety of

Re: Joel Jaeggli's Discuss on draft-ietf-6man-ext-transmit-04: (with DISCUSS and COMMENT)

Hi Brian, On 08.10.2013 21:45, Brian E Carpenter wrote: > NEW >Today, IPv6 packets are often forwarded not only on the basis of their >first 40 bytes by straightforward IP routing. Some routers, and a >variety of intermediate nodes often referred to as middleboxes, such >as firewal

Re: Joel Jaeggli's Discuss on draft-ietf-6man-ext-transmit-04: (with DISCUSS and COMMENT)

On Oct 8, 2013, at 12:45 PM, Brian E Carpenter wrote: > Joel, > > Would this help? > > OLD > Today, packets are often forwarded not only by straightforward IP > routers, but also by a variety of intermediate nodes, often referred > to as middleboxes, such as firewalls, load balancers, o

Re: Joel Jaeggli's Discuss on draft-ietf-6man-ext-transmit-04: (with DISCUSS and COMMENT)

Joel, Would this help? OLD Today, packets are often forwarded not only by straightforward IP routers, but also by a variety of intermediate nodes, often referred to as middleboxes, such as firewalls, load balancers, or packet classifiers. NEW Today, IPv6 packets are often forwarde

Re: Joel Jaeggli's Discuss on draft-ietf-6man-ext-transmit-04: (with DISCUSS and COMMENT)

On Oct 8, 2013, at 12:06 PM, Brian E Carpenter wrote: > On 08/10/2013 20:19, Joel Jaeggli wrote: > ... >> -- >> DISCUSS: >> -- >> >> This is a dicuss because

Re: Joel Jaeggli's Discuss on draft-ietf-6man-ext-transmit-04: (with DISCUSS and COMMENT)

On 08/10/2013 20:19, Joel Jaeggli wrote: ... > -- > DISCUSS: > -- > > This is a dicuss because I'd like to see if I'm in the rough in this. > > Devices generally

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

Hi, Fred, Thanks so much for your feedback! -- Please find my comments in-line... On 10/08/2013 03:33 PM, Templin, Fred L wrote: >> I would claim that additional encapsulation headers are already >> considered in the 1280 minimum MTU. >> as in: 1500 - 1280. > > It is kind of like that, but what

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

Hi Ole, > -Original Message- > From: Ole Troan [mailto:otr...@employees.org] > Sent: Tuesday, October 08, 2013 9:17 AM > To: Templin, Fred L > Cc: i...@ietf.org; IETF-Announce; ipv6@ietf.org > Subject: Re: Last Call: > (Implications of Oversized IPv6 Header Chains)

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

Fred, > Hi, I would like to make a small amendment to what I said in my > previous message as follows: > > 4) Section 5, change the final paragraph to: > > "As a result of the above mentioned requirements, a packet's header > chain length MUST fit within the Path MTU associated with its >

Re: [homenet] draft-lepape-6man-prefix-metadata-00

Hi Michael, Thanks for the review, please find comments inline @SB On 9/25/13 6:28 PM, "Michael Richardson" wrote: > >I think that this draft is useful land should be adopted. > >I think that application writers will be much happier asking for prefix >colours than properties, if there is a clea

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

tf.org; ipv6@ietf.org; The IESG > Subject: Re: Adrian Farrel's No Objection on draft-ietf-6man-ext- > transmit-04: (with COMMENT) > > On 08/10/2013 10:28, C. M. Heard wrote: > ... > > > Maybe I'm making too much of this. Certainly a reasonable action > > for

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

On 08/10/2013 10:28, C. M. Heard wrote: ... > Maybe I'm making too much of this. Certainly a reasonable action > for a middlebox that's told to pass packets with extension header > types 253 and 254 is to stop parsing when it encounters those next > header types and forward the packet in quest

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

On Tue, 8 Oct 2013, Brian E Carpenter wrote: > Yes, and for a moment there you had me worried, but if the security > concern is that the unknown header may contain bad stuff and/or cause > a buffer overflow bug, then it really doesn't matter whether it is > an extension header or a payload header.

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

On 08/10/2013 05:53, C. M. Heard wrote: > On Mon, 7 Oct 2013, Adrian Farrel wrote: >> 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" >>

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

On 08/10/2013 03:43, Adrian Farrel wrote: ... > 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

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

y, October 04, 2013 1:42 PM > To: i...@ietf.org; IETF-Announce > Cc: ipv6@ietf.org > Subject: RE: Last Call: > (Implications of Oversized IPv6 Header Chains) to Proposed Standard > > Hi, I have a concern about this document. In the definition of "IPv6 > Header Chain"

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

On Mon, 7 Oct 2013, Adrian Farrel wrote: > 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 Expe

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

Hi, I have a concern about this document. In the definition of "IPv6 Header Chain", it says: "However, if a second IPv6 header appears in the header chain, as is the case when IPv6 is tunneled over IPv6, the second IPv6 header is considered to be an upper-layer header and terminates the

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

Hi Barry, On 05/10/2013 07:29, Barry Leiba wrote: ... > -- 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 >

Re: AD Evaluation: draft-ietf-6man-oversized-header-chain

On 10/02/2013 08:50 PM, Tom Taylor wrote: > Just a trivial change: "including" -> "subject to" Agreed. But I can fix it this after IETF LC or even durng AUTH48. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25

Re: a frag measurement of interest

On Thu, 3 Oct 2013, Randy Bush wrote: https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters I've commented on the article that it would be interesting for them to test smaller packets with IPv6 fragmentation header as well. It's been discussed before that several platforms

Re: AD Evaluation: draft-ietf-6man-oversized-header-chain

Just a trivial change: "including" -> "subject to" On 02/10/2013 1:14 PM, Ronald Bonica wrote: Brian, This works for me. So, the complete list of changes follows. Do these work for you? Ron CHANGES === ... OLD> A host that receives a first-fragme

Re: Detailed review of Significance of IPv6 Interface Identifiers

On 02/10/2013 20:32, Ray Hunter wrote: >> Brian E Carpenter >> 1 October 2013 23:48 >> I know that a couple of people wanted the extra details suggested by Ray >> below. However, the explanation that I got from the 802.1 liaison >> (see my previous message) seem

RE: AD Evaluation: draft-ietf-6man-oversized-header-chain

header-chain@tools.ietf.org > Cc: 6man WG > Subject: Re: AD Evaluation: draft-ietf-6man-oversized-header-chain > > Ron, > > On 10/2/13 1:14 PM, Ronald Bonica wrote: > > Brian, > > > > This works for me. So, the complete list of changes follows. Do these &

Re: AD Evaluation: draft-ietf-6man-oversized-header-chain

Ron, On 10/2/13 1:14 PM, Ronald Bonica wrote: > Brian, > > This works for me. So, the complete list of changes follows. Do these work > for you? > Works for me! Brian signature.asc Description: OpenPGP digital signature I

RE: AD Evaluation: draft-ietf-6man-oversized-header-chain

f-6man-oversized-header-chain@tools.ietf.org > Cc: 6man WG > Subject: Re: AD Evaluation: draft-ietf-6man-oversized-header-chain > > Hi Ron, > > On 10/2/13 12:23 PM, Ronald Bonica wrote: > > Hi Brian, > > > > So, merging in you last set of comments, th

Re: AD Evaluation: draft-ietf-6man-oversized-header-chain

Hi Ron, On 10/2/13 12:23 PM, Ronald Bonica wrote: > Hi Brian, > > So, merging in you last set of comments, the next draft version will include > the changes listed below. Please tell me if these work for you. > > Ron > > OLD> >For example, assume that a

RE: AD Evaluation: draft-ietf-6man-oversized-header-chain

[RFC 2460]. -Original Message- > From: Brian Haberman [mailto:br...@innovationslab.net] > Sent: Wednesday, October 02, 2013 11:23 AM > To: draft-ietf-6man-oversized-header-chain@tools.ietf.org > Cc: 6man WG > Subject: Re: AD Evaluation: draft-ietf-6man-oversized-header-chain &

Re: AD Evaluation: draft-ietf-6man-oversized-header-chain

Hi Ron, On 10/2/13 10:55 AM, Ronald Bonica wrote: > Brian, > > Thanks for the review. Please see responses, inline. > >> -Original Message- >> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of >> Brian Haberman >> Sent: Tuesday, October 01, 2013 3:16 PM >> To: d

RE: AD Evaluation: draft-ietf-6man-oversized-header-chain

Brian, Thanks for the review. Please see responses, inline. > -Original Message- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Brian Haberman > Sent: Tuesday, October 01, 2013 3:16 PM > To: draft-ietf-6man-oversized-header-chain@tools.ietf.org; 6man W

Re: AD Evaluation: draft-ietf-6man-oversized-header-chain

On 10/2/13 1:57 AM, Fernando Gont wrote: > Hi, Brian, > > On 10/01/2013 04:16 PM, Brian Haberman wrote: >> 1. The 2nd paragraph of Section 4 (Motivation) could be made more >> clear. For example, you could indicate if the example first >> fragment does or does not match the stateless firewall ru

Re: Detailed review of Significance of IPv6 Interface Identifiers

> Brian E Carpenter > 1 October 2013 23:48 > I know that a couple of people wanted the extra details suggested by Ray > below. However, the explanation that I got from the 802.1 liaison > (see my previous message) seems to me to make the details unimportant. > >

Re: AD Evaluation: draft-ietf-6man-oversized-header-chain

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Brian, On 10/01/2013 04:16 PM, Brian Haberman wrote: > 1. The 2nd paragraph of Section 4 (Motivation) could be made more > clear. For example, you could indicate if the example first > fragment does or does not match the stateless firewall rule.

Re: Detailed review of Significance of IPv6 Interface Identifiers

ship, but that's what the draft fixes.) > Agreed >> Brian >> > Original text: > > /However, this has not so far proved to be the case. Also, there is >evidence from the field that despite the IEEE standard [IEEE802], MAC >addresses with universal sco

Re: I-D Action: draft-ietf-6man-ug-04.txt

Dear 6man, This version has two main changes: 1. Updated the discussion of IEEE 802.1 slightly, following review by Eric Gray, the IETF's liaison to 802.1. The wording in 802.1 is quite subtle, but quoting Eric, '"universal scope" means that a MAC address MUST be globally unique within the scope

Re: UDP+Fragmentation (was: "Deprecate")

On 09/24/2013 10:51 PM, C. M. Heard wrote: >> If you care about fragmentation-based attacks, you really don't want to >> use TCP. There are a bunch of attacks that can be (by far) more >> devastating than the fragmentation-based ones (see >>

Re: [6MAN] UDP+Fragmentation

On 09/26/2013 02:02 PM, Warren Kumari wrote: >>> There has also been discussion that for things like routers you >>> can just do X to protect the device control plane / only care >>> about traffic directed to the device itself. >> >> Agreed. But, isn't that orthogonal to the discussion regarding >

Re: [6MAN] UDP+Fragmentation (was: "Deprecate")

On Sep 25, 2013, at 3:38 PM, Fernando Gont wrote: > On 09/25/2013 02:32 PM, Warren Kumari wrote: >>> >>> Unless you have a very sloppy IPv6 implementation (that does not >>> enforce limits on the maximum number of queued fragments), an >>> attacker will only be able to DoS communication instanc

Re: [6MAN] UDP+Fragmentation (was: "Deprecate")

On 09/25/2013 02:32 PM, Warren Kumari wrote: >> >> Unless you have a very sloppy IPv6 implementation (that does not >> enforce limits on the maximum number of queued fragments), an >> attacker will only be able to DoS communication instances (e.g. TCP >> connections) that employ fragmentation. Suc

Re: [6MAN] UDP+Fragmentation (was: "Deprecate")

On Sep 23, 2013, at 1:15 PM, Fernando Gont wrote: > On 09/23/2013 12:57 AM, C. M. Heard wrote: >> >> There are two issues that Warren's comments brought to the fore: >> >> 1.) One of the reasons why operators block fragments is that if >>fragments are allowed into one's network, it is rel

Re: UDP+Fragmentation (was: "Deprecate")

On Mon, 23 Sep 2013, Fernando Gont wrote: > On 09/23/2013 12:57 AM, C. M. Heard wrote: > > > > There are two issues that Warren's comments brought to the fore: > > > > 1.) One of the reasons why operators block fragments is that if > > fragments are allowed into one's network, it is relative

RE: UDP+Fragmentation (was: "Deprecate")

Hi, I have done some looking around on linux and found two more sources of IPv6 fragmentation. First, unless explicitly told not to, 'ping6' will use IPv6 fragmentation to ensure that ICMPv6 echo request packets larger than the path MTU are delivered to the final destination. The destination then

Re: 6MAN Adoption call on

After reviewing the adoption call comments, the chairs have decided not to adopt draft-gont-ipv6-smurf-amplifier. - We have not seen strong working group support for working on the draft. - We are not convinced that the problem the draft sets out to resolve is worth fixing given that multicast R

Re: UDP+Fragmentation (was: "Deprecate")

On 09/23/2013 12:57 AM, C. M. Heard wrote: > > There are two issues that Warren's comments brought to the fore: > > 1.) One of the reasons why operators block fragments is that if > fragments are allowed into one's network, it is relatively easy > for an attacker to make a DOS attack on

Re: UDP+Fragmentation (was: "Deprecate")

In message , "C. M. Heard " writes: > On Mon, 26 Aug 2013, C. M. Heard wrote: > > Upon reflection, I have come to the conclusion that the proposal > > in draft-andrews-6man-fragopt (or a variant thereof) is a much > > better solution to the problems with IPv6 fragmentation than the > > UDP segm

Re: UDP+Fragmentation (was: "Deprecate")

On Mon, 26 Aug 2013, C. M. Heard wrote: > Upon reflection, I have come to the conclusion that the proposal > in draft-andrews-6man-fragopt (or a variant thereof) is a much > better solution to the problems with IPv6 fragmentation than the > UDP segmentation scheme I proposed. > > The huge advan

Re: ICMPv6 Destination at Sleep

On 12 Sep 2013, at 11:33, wrote: > > This information would assist the sending device to better choose its next > course of action (e.g. ask user to go and kick the device). I may poke > homenet as well, but I have been in understanding that homenet is focused on > routing and related problema

RE: ICMPv6 Destination at Sleep

] Sent: 11. syyskuuta 2013 21.48 To: Savolainen Teemu (Nokia-NRC/Tampere); ipv6@ietf.org Subject: RE: ICMPv6 Destination at Sleep Hi Teemu, I read your proposal and have been thinking about it. I'd like to share some of my thoughts as feedback for you. My thoughts are a bit random and not

RE: ICMPv6 Destination at Sleep

ep modes. But the duration is usually ~200ms and the IP messages are buffered, so this ICMPv6 mechanism wouldn't be needed in this case. - Interfaces that do longer sleep modes often take down their IP stack. They re-acquire IP addresses when re-awakening. If the IP address of inter

RE: I-D Action: draft-baker-ipv6-ospf-dst-flowlabel-routing-03.txt

I have first hand knowledge that a McAfee Sidewinder firewall sets/rewrites the flow label. Sent from my Verizon Wireless 4G LTE smartphone Original message From: Brian E Carpenter Date: 09/02/2013 20:17 (GMT-05:00) To: 6man Cc: Fred Baker Subject: Re: I-D Action: draft

Re: DHCPv6 address selection option and stateless DHCPv6?

Hi Lorenzo, The current text describes the meaning of "stale" as follows in 3.2. The received information can be considered stale in several cases, e.g., when the interface goes down, the DHCP server does not respond for a certain amount of time, and the Information Refresh Time is ex

Re: Detailedl review of draft-ietf-6man-oversized-header-chain-06

It's normal practice in other WGs I've worked with (e.g, AVT, MMUSIC). If you name the registry exactly as shown on the IANA page, implementors can always search for it. A URL is transitory, as the text vs. XML discussion shows. On 06/09/2013 8:01 PM, Fernando Gont wrote: On 09/06/2013 05:13

Re: Detailed review of draft-ietf-6man-stable-privacy-addresses-13 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)

Hi, Ray, Please find my responses in-line... On 09/07/2013 03:26 AM, Ray Hunter wrote: >>> 3. I think there should be some words on the quality requirements of >>> the PRF F(), and also any security impact of this being weak/ >>> predictable. >> >> mm.. should we really say more than "it is cr

Re: Detailed review of draft-ietf-6man-stable-privacy-addresses-13 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)

inline > Fernando Gont > 7 September 2013 02:58 > Hi, Ray, > > Thanks so much for the review! -- Please find my comments in-line... > > On 09/06/2013 04:56 AM, Ray Hunter wrote: >> Summary Recommendations === >> >> 1. Proceed with the document and

Re: Detailedl review of draft-ietf-6man-oversized-header-chain-06

On 07/09/2013 12:01, Fernando Gont wrote: > On 09/06/2013 05:13 PM, Brian E Carpenter wrote: >>> This puzzles me. If the URL is removed prior to publication, I guess one >>> has to navigate IANA's site, or Google for he registry?? >> Yes. In the ext-transmit draft, we just put the names of the >> r

Re: Detailed review of draft-ietf-6man-stable-privacy-addresses-13 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)

Hi, Ray, Thanks so much for the review! -- Please find my comments in-line... On 09/06/2013 04:56 AM, Ray Hunter wrote: > Summary Recommendations === > > 1. Proceed with the document and the proposed solution. > > 2. Given the likely ubiquitous deployment of this standard, I

Re: Detailedl review of draft-ietf-6man-oversized-header-chain-06

On 09/06/2013 05:13 PM, Brian E Carpenter wrote: >> This puzzles me. If the URL is removed prior to publication, I guess one >> has to navigate IANA's site, or Google for he registry?? > > Yes. In the ext-transmit draft, we just put the names of the > registries. Doesn't that make things ("slight

Re: Detailedl review of draft-ietf-6man-oversized-header-chain-06

On 07/09/2013 00:28, Fernando Gont wrote: > On 09/06/2013 08:42 AM, t.petch wrote: >> They are not saying:-( >> >> In >> draft-leiba-cotton-iana-5226bis-03 >> the nearest they come to saying, as far as I can see, how a document >> should reference a registry is >> >> " Providing a URL to prec

RE: Detailedl review of draft-ietf-6man-oversized-header-chain-06

[mailto:ie...@btconnect.com] > Sent: Friday, September 06, 2013 7:42 AM > To: Brian E Carpenter; Ronald Bonica > Cc: 6man > Subject: Re: Detailedl review of draft-ietf-6man-oversized-header- > chain-06 > > Original Message - > From: "Brian E Carpenter" > To:

Re: AD Evaluation: draft-ietf-6man-ext-transmit-03

One additional administrative point on this draft... I have added the 6man mailing list to the notification list for this draft. What this means is that all IESG ballot messages generated will be sent to the list. This will facilitate the WG seeing all points raised by other ADs, hopefully s

Re: DHCPv6 address selection option and stateless DHCPv6?

On Fri, Sep 6, 2013 at 9:23 PM, Tim Chown wrote: > > If #2, then perhaps this option needs a lifetime value? Unless the plan > is that a) who/whatever solves the problem statement in RFC 4076 will solve > this too, or b) that everyone needing this option will use stateful DHCPv6. > > What about u

  1   2   3   4   5   6   7   8   9   10   >