Re: I-D Action:draft-ietf-6man-exthdr-01.txt

On 2011-01-16 11:59, Hing-Kam (Kam) Lam wrote: >> But it is a very open question whether any middlebox will bother to >> do this. >> >>> So the one thing this proposal will *not* do is allow new extension headers >>> to cross the Internet transparently. All it might do is cause the firewalls >>> to

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

> > But it is a very open question whether any middlebox will bother to > do this. > >> So the one thing this proposal will *not* do is allow new extension headers >> to cross the Internet transparently. All it might do is cause the firewalls >> to dig one layer deeper before discarding the packet.

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

> If we take the view that a firewall will block anything it does not know, > without question or limit, then > 1) We have no way to extend our basic protocols that will pass through > firewalls (we have to tunnel / encapsulate) I agree. > 2) you are correct that this document does not help. Dis

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

Fernando, >> >> That is, help middleboxes to violate e2e transparency and, furthermore, >> allow unknown headers to cross those middleboxes. > > I don't think this I-D will make a difference. > > From the POV of a firewall, unless it really wants a packet to > pass-through, it will block it. > > S

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

On Thu, Jan 6, 2011 at 6:56 PM, Rémi Després wrote: > > Le 5 janv. 2011 à 21:15, Brian E Carpenter a écrit : >> On 2011-01-06 02:15, RJ Atkinson wrote: >> ... >>> Prohibiting new IPv6 Extension Headers outright, >>> ... >> My reaction is that this is going too far, > > +1 I agree with this. I don

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

On Jan 3, 2011, at 13:43, Fernando Gont wrote: > > From the POV of a firewall, unless it really wants a packet to pass-through, > it will block it. That's an unwarranted assumption. Consider the "firewall" described in I-D.ietf-v6ops-cpe-simple-security, which is intended to block only unsolic

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

Le 5 janv. 2011 à 21:15, Brian E Carpenter a écrit : > On 2011-01-06 02:15, RJ Atkinson wrote: > ... >> Prohibiting new IPv6 Extension Headers outright, >> ... > My reaction is that this is going too far, +1 > ... > So I am more inclined to a SHOULD NOT approach; I think I'm agreeing > with a s

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

Le 5 janv. 2011 à 13:44, Joel M. Halpern a écrit : > ... > I consider (a), specifying the format at least to the level of requiring TLV > encoding, to be a good idea. +1 IETF IPv6 working group mailing list ipv6@ietf.org Adm

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

On 05 Jan 2011, at 15:15 , Brian E Carpenter wrote: > On 2011-01-06 02:15, RJ Atkinson wrote: > ... >> A) Prohibiting new IPv6 Extension Headers outright, >> as Joel has repeatedly suggested. This removes the >> narrow case where RFC-2460 allows Extension Headers, >> so the I-D would be a

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

On 2011-01-06 02:15, RJ Atkinson wrote: ... > A) Prohibiting new IPv6 Extension Headers outright, >as Joel has repeatedly suggested. This removes the >narrow case where RFC-2460 allows Extension Headers, >so the I-D would be an Update to RFC-2460. My reaction is that this is going to

RE: I-D Action:draft-ietf-6man-exthdr-01.txt

Earlier, Manav wrote: > Assume you are the end host that wants to prioritize certain packets > or wants to implement Access control lists (ACLs). In the absence > of this extension a router cannot apply ACLs as it will never know how > to parse the packet in case it comes across an unknown exten

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

On 05 Jan 2011, at 05:12 , Suresh Krishnan wrote: > I'm up for it :-). In fact I already suggested the meat in > > http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html > > "RFC2460 allows the use of both extension headers and destination options in > order to encode optional destina

RE: I-D Action:draft-ietf-6man-exthdr-01.txt

ont > Sent: Tuesday, January 04, 2011 3.13 AM > To: Brian E Carpenter > Cc: Thomas Narten; ipv6@ietf.org; Suresh Krishnan > Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt > > On 03/01/2011 06:25 p.m., Brian E Carpenter wrote: > > > The basic motivation for th

RE: I-D Action:draft-ietf-6man-exthdr-01.txt

> > For clarity, in terms of the pieces of your original note: > > I consider (a), specifying the format at least to the level > of requiring > TLV encoding, to be a good idea. I agree to this. I think there is value in specifying a format that all subsequent extension headers MUST use. C

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

For clarity, in terms of the pieces of your original note: I consider (a), specifying the format at least to the level of requiring TLV encoding, to be a good idea. I do not see any particular advantage in (b), allocating a code point, but I can live with it if the WG wants it. And (c), cha

RE: I-D Action:draft-ietf-6man-exthdr-01.txt

Hi Joel, > -Original Message- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On > Behalf Of Joel M. Halpern > Sent: Tuesday, January 04, 2011 12:26 PM > To: Fernando Gont > Cc: ipv6@ietf.org > Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt >

RE: I-D Action:draft-ietf-6man-exthdr-01.txt

Hi Ran, > I believe there would be broad support within the IPv6 WG to > have a small clarification to RFC-2460 that required the use > of Destination Options in all cases where they can be made to > work (in essence, this is Joel's I and II above). > > However, that could be done in a 1-page

RE: I-D Action:draft-ietf-6man-exthdr-01.txt

Hi Steve, > -Original Message- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On > Behalf Of Steven Blake > Sent: Tuesday, January 04, 2011 10:21 AM > To: ipv6@ietf.org > Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt > > On Tue, 2011-01-0

RE: I-D Action:draft-ietf-6man-exthdr-01.txt

sh Krishnan > Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt > > On 03/01/2011 06:25 p.m., Brian E Carpenter wrote: > > > The basic motivation for the present draft is clear: > > > >>However, > >>some intermediate nodes such as firewalls, m

RE: I-D Action:draft-ietf-6man-exthdr-01.txt

Hi Brian, Please see response inline. > -Original Message- > From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] > Sent: Monday, January 03, 2011 4:25 PM > To: Thomas Narten > Cc: Suresh Krishnan; ipv6@ietf.org > Subject: Re: I-D Action:draft-ietf-6man-exth

RE: I-D Action:draft-ietf-6man-exthdr-01.txt

Hi Thomas, Please see responses inline. > -Original Message- > From: Thomas Narten [mailto:nar...@us.ibm.com] > Sent: Monday, January 03, 2011 3:40 PM > To: Suresh Krishnan > Cc: Tony Li; ipv6@ietf.org > Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt > &g

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

Earlier, Remi Depres wrote: > 1. let's assume a new routing extension is found useful. >Without a skippable extension format, it won't ever be deployable: > - All FWs will have no option but rejecting all packets having it. In reality, such an extension would use the existing IPv6 Routin

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

Le 4 janv. 2011 à 16:20, Steven Blake a écrit : > On Tue, 2011-01-04 at 09:20 -0500, Thomas Narten wrote: >> >> If the firewall will just dig one layer deeper and then discard >> anyway, what is the point? > > +1 > > I still don't understand what this draft solves that couldn't be solved > mor

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

Then what about if we forget firewalls for the moment? A lot of routers look for the TCP/UDP Port numbers for LAG/ECMP computation. Many of them can cope with having a destination options extension, and therefore that is clearly the better way to handle such information. And anything we do shou

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

Hi, Thomas, On 04/01/2011 11:29 a.m., Thomas Narten wrote: >> From the POV of a firewall, unless it really wants a packet to >> pass-through, it will block it. > > I think this is the crux of the problem. firewalls, by default, > discard stuff. They don't like the idea of allowing unknown or > "u

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

On Tue, 2011-01-04 at 09:20 -0500, Thomas Narten wrote: > This is at best poorly phrased. :-) > > If the firewall will just dig one layer deeper and then discard > anyway, what is the point? +1 I still don't understand what this draft solves that couldn't be solved more easily by just encoding

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

All, I have very strong sympathy with the thoughts expressed by Thomas Narten in this note, especially: (A) the root question (not yet clearly answered, although it has been asked more than once) of what problem this

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

Fernando Gont writes: > On 03/01/2011 06:25 p.m., Brian E Carpenter wrote: > > The basic motivation for the present draft is clear: > > > >>However, > >>some intermediate nodes such as firewalls, may need to look at the > >>transport layer header fields in order to make a decision t

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

Brian E Carpenter writes: > > 2) The routing header is essentially deprecated, and we probably won't > > define any more. > The proposal for RH4, i.e. draft-ietf-6man-rpl-routing-header, > is active. Oh, right. But I view that as (essentially) an L2 usage. It will be used within one RPL domain,

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

Hi, Joel, On 03/01/2011 06:53 p.m., Joel M. Halpern wrote: > If we take the view that a firewall will block anything it does not > know, without question or limit, then > 1) We have no way to extend our basic protocols that will pass through > firewalls (we have to tunnel / encapsulate) > 2) you a

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

Generally I support the draft, but I also agree with comments about firewalls. To make this idea work, I would suggest changing word "must" to word "SHOULD" in definition of Hdr Options parameters. Designers of these additional headers have to acknowledge the fact that there is no guarantee of del

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

If we take the view that a firewall will block anything it does not know, without question or limit, then 1) We have no way to extend our basic protocols that will pass through firewalls (we have to tunnel / encapsulate) 2) you are correct that this document does not help. Also, if we assume th

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

On 03/01/2011 06:25 p.m., Brian E Carpenter wrote: > The basic motivation for the present draft is clear: > >>However, >>some intermediate nodes such as firewalls, may need to look at the >>transport layer header fields in order to make a decision to allow or >>deny the packet.

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

> 2) The routing header is essentially deprecated, and we probably won't > define any more. The proposal for RH4, i.e. draft-ietf-6man-rpl-routing-header, is active. However, isn't the real question whether we want to change the implied intention that adding a new extension header should be hard?

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

FWIW, I'm sympathetic to Tony's basic sense that it is unclear that we need to do this work/document. I'm still not clear on exactly what *real* problem it solves. Suresh Krishnan writes: > Since RFC2460 came out, four new extension headers have been defined. > 135 - Mobility header > 139 - HI

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

On Dec 21, 2010, at 9:32 PM, Suresh Krishnan wrote: > We will come back with a proposal to resolve the issues that you, Ran and > Fernando raised. Thank you, we look forward to it. Tony IETF IPv6 working group mailing list

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

Hi Tony, On 10-12-21 06:30 PM, Tony Li wrote: Hi Suresh, It does seem helpful and useful to propose that future new extension headers be TLV encoded. While it seems obvious from 2460 that this was the intent, I cannot find that explicitly stated anywhere. I would support this draft simply sta

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

Hi Suresh, >> It does seem helpful and useful to propose that future new extension headers >> be TLV encoded. While it seems obvious from 2460 that this was the intent, >> I cannot find that explicitly stated anywhere. I would support this draft >> simply stating that and no more. This shou

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

Hi Tony, Thanks for your comments. Please see responses inline. On 10-12-21 01:10 PM, Tony Li wrote: On Dec 20, 2010, at 5:48 PM, Tony Li wrote: I do not support this work. It seems ill conceived and unnecessary. If there are needs for new extension headers, they should be presented. If t

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

On Dec 20, 2010, at 5:48 PM, Tony Li wrote: > > I do not support this work. It seems ill conceived and unnecessary. > > If there are needs for new extension headers, they should be presented. If > the data must be carried as an extension header, then specific new extension > headers should

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

I do not support this work. It seems ill conceived and unnecessary. If there are needs for new extension headers, they should be presented. If the data must be carried as an extension header, then specific new extension headers should be defined for those code points. Tony On Dec 20, 2010,

Re: I-D Action:draft-ietf-6man-exthdr-01.txt

I support this work and would like to see this progressed. Kam On Sat, Dec 18, 2010 at 5:15 AM, wrote: > 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