On 2013-06-13 14:02, Joe Touch wrote:
[..]
>> peeking at
>> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml
>> 'act' and noting there are a few protocols that have act != 00 that
>> might be affected by this.
>
> Agreed.
>
> I'm not sure why the table includes HBH and DO in th
On 6/13/2013 1:54 PM, Jeroen Massar wrote:
On 2013-06-13 13:17, Joe Touch wrote:
[..]
And, for some
options, if the option in question is not supported, the packet should
be dropped -- i.e., you cannot just "ignore the hbh header" (at east in
theory).
Why not? Is there any HBH header that is
On 2013-06-13 13:17, Joe Touch wrote:
[..]
>>> And, for some
>>> options, if the option in question is not supported, the packet should
>>> be dropped -- i.e., you cannot just "ignore the hbh header" (at east in
>>> theory).
>>
>> Why not? Is there any HBH header that is crucial for operation of IP
On 06/13/2013 01:17 AM, Randy Bush wrote:
FWIW, I don't think anyone has proposed "if the chain is larger than X,
then drop".
i am saying that i am telling my neighbor that, if the header length is
larger than X, it is likely that their packet will not propagate. it's
an ops bcp statement, not
On 6/13/2013 12:02 AM, Jeroen Massar wrote:
On 2013-06-12 14:58, Fernando Gont wrote:
Jeroen,
On 06/12/2013 11:44 PM, Jeroen Massar wrote:
with the exception of the HBH header, correct. I got tired of writing that each
time I was repeating myself.
the HBH is an issue to itself. expect those
On Jun 13, 2013 1:18 AM, "Randy Bush" wrote:
>
> > FWIW, I don't think anyone has proposed "if the chain is larger than X,
> > then drop".
>
> i am saying that i am telling my neighbor that, if the header length is
> larger than X, it is likely that their packet will not propagate. it's
> an ops
> FWIW, I don't think anyone has proposed "if the chain is larger than X,
> then drop".
i am saying that i am telling my neighbor that, if the header length is
larger than X, it is likely that their packet will not propagate. it's
an ops bcp statement, not a statement of ipv6 protocol definition.
On 2013-06-12 14:58, Fernando Gont wrote:
> Jeroen,
>
> On 06/12/2013 11:44 PM, Jeroen Massar wrote:
>>> with the exception of the HBH header, correct. I got tired of writing that
>>> each time I was repeating myself.
>>> the HBH is an issue to itself. expect those packets to be severely rate
>>
On 13/06/2013 10:06, Joe Touch wrote:
>
>
> On 6/12/2013 2:44 PM, Jeroen Massar wrote:
>> Unless the router in question knows what that HBH header will do (read:
>> it was implemented when the definition of that header was defined) or
>> what it should do with it, it won't be able to do anything
Agreed.
Let's ask some "running code" people some input about the practical
constraints.
/as
On 6/12/13 6:21 PM, Ray Hunter wrote:
>>> So a limit of 128 would currently probably be ok, but I personally would
>>> prefer the limit to be a bit higher just to have some extra margi
On 06/13/2013 01:59 AM, Joe Touch wrote:
> FWIW, I added INTAREA, because I don't consider potentially killing off
> IPv6 header extensions as merely maintenance (6man) or operational (v6ops).
We're trying to do exactly the opposite: try to define under which
constraints we can expect them to work
FWIW, I added INTAREA, because I don't consider potentially killing off
IPv6 header extensions as merely maintenance (6man) or operational (v6ops).
Joe
On 6/12/2013 3:45 PM, Warren Kumari wrote:
BTW: Who added every basically single IETF list to this thread?
--
On Jun 12, 2013, at 6:07 PM, sth...@nethelp.no wrote:
>>> However, anything that says "if the chain is >X, then drop" is broken,
>>> period.
>>
>> FWIW, I don't think anyone has proposed "if the chain is larger than X,
>> then drop".
>
> On the other hand - I, as an operator, may well decide to
On 06/13/2013 12:25 AM, Joe Touch wrote:
>> I want to recommend hosts not to send such packets. Hence it looks like
>> std track.
>
> Telling them they SHOULD NOT is BCP. It's a configuration, and it's
> compliant with the existing standard AFAICT, so since it's not a change
> per se it wouldn't b
On 6/12/2013 3:19 PM, Fernando Gont wrote:
On 06/13/2013 12:07 AM, Joe Touch wrote:
On 6/12/2013 2:44 PM, Fernando Gont wrote:
just to be clear I'm not against the IETF documenting e.g. in a BCP,
what the longest expected header chain should be.
Well, that seems more std track than bcp to
On Jun 12, 2013, at 2:44 PM, Robert Elz wrote:
> Date:Wed, 12 Jun 2013 19:49:08 +0200
> From:Gert Doering
> Message-ID: <20130612174908.gt2...@space.net>
>
> | Loop back to about 50 messages earlier in this thread,
>
> I don't generally read this list (any more) - just
On 06/13/2013 12:07 AM, Joe Touch wrote:
>
> On 6/12/2013 2:44 PM, Fernando Gont wrote:
>>> just to be clear I'm not against the IETF documenting e.g. in a BCP,
>>> what the longest expected header chain should be.
>>
>> Well, that seems more std track than bcp to me.
>
> If it's an operational r
On 06/13/2013 12:07 AM, sth...@nethelp.no wrote:
>>> However, anything that says "if the chain is >X, then drop" is broken,
>>> period.
>>
>> FWIW, I don't think anyone has proposed "if the chain is larger than X,
>> then drop".
>
> On the other hand - I, as an operator, may well decide to drop su
Joe,
an IPv6 router compliant with RFC2460 does not inspect the header chain.
>>>
>>> That cannot be true; there are headers after IPv6 but before fragmentation
>>> that are hop-by-hop.
>>
>> with the exception of the HBH header, correct. I got tired of writing that
>> each time I was rep
Hi, Ole,
On 06/12/2013 11:53 PM, Ole Troan wrote:
>> IIRC, someone reported that Cisco ASA drop v6 packets with extension
>> headers by default.
>
> I think you'll find that the Cisco ASA isn't marketed as a router either, it
> is a firewall.
Agreed.
>>> just to be clear I'm not against t
On 6/12/2013 2:44 PM, Fernando Gont wrote:
just to be clear I'm not against the IETF documenting e.g. in a BCP, what the
longest expected header chain should be.
>
Well, that seems more std track than bcp to me.
If it's an operational recommendation (SHOULD because that's all that
routers
> > However, anything that says "if the chain is >X, then drop" is broken,
> > period.
>
> FWIW, I don't think anyone has proposed "if the chain is larger than X,
> then drop".
On the other hand - I, as an operator, may well decide to drop such
packets.
Steinar Haug, AS 2116
On 6/12/2013 2:44 PM, Jeroen Massar wrote:
Unless the router in question knows what that HBH header will do (read:
it was implemented when the definition of that header was defined) or
what it should do with it, it won't be able to do anything with it
anyway. Thus just ignoring/skipping it, hec
On 6/12/2013 2:36 PM, Ole Troan wrote:
Joe,
an IPv6 router compliant with RFC2460 does not inspect the header chain.
That cannot be true; there are headers after IPv6 but before fragmentation that
are hop-by-hop.
with the exception of the HBH header, correct. I got tired of writing that
Jeroen,
On 06/12/2013 11:44 PM, Jeroen Massar wrote:
>> with the exception of the HBH header, correct. I got tired of writing that
>> each time I was repeating myself.
>> the HBH is an issue to itself. expect those packets to be severely rate
>> limited.
>
> I am wondering why if your box c
Fernando,
>>> However, anything that says "if the chain is >X, then drop" is broken,
>>> period. At some point, if you want to play "IPv6 router", you need to earn
>>> the title.
>>
>> an IPv6 router compliant with RFC2460 does not inspect the header chain.
>>
>> I'm not aware of any router th
On 06/12/2013 11:25 PM, Ole Troan wrote:
>> However, anything that says "if the chain is >X, then drop" is broken,
>> period. At some point, if you want to play "IPv6 router", you need to earn
>> the title.
>
> an IPv6 router compliant with RFC2460 does not inspect the header chain.
>
> I'm not
On 2013-06-12 14:36, Ole Troan wrote:
> Joe,
>
>>> an IPv6 router compliant with RFC2460 does not inspect the header chain.
>>
>> That cannot be true; there are headers after IPv6 but before fragmentation
>> that are hop-by-hop.
>
> with the exception of the HBH header, correct. I got tired of w
Joe,
>> an IPv6 router compliant with RFC2460 does not inspect the header chain.
>
> That cannot be true; there are headers after IPv6 but before fragmentation
> that are hop-by-hop.
with the exception of the HBH header, correct. I got tired of writing that each
time I was repeating myself.
th
On 6/12/2013 2:25 PM, Ole Troan wrote:
Joe,
FWIW, I wouldn't mind:
- IPv6 *should* limit its header chains to (some reasonable limit)
What I expect when that's not the case:
- SOME packets get through, perhaps more slowly
- when the router can't keep up, it can drop the ove
Joe,
> FWIW, I wouldn't mind:
>
> - IPv6 *should* limit its header chains to (some reasonable limit)
>
> What I expect when that's not the case:
>
> - SOME packets get through, perhaps more slowly
> - when the router can't keep up, it can drop the overload
>
> This isn't any differ
On 06/12/2013 10:49 PM, Joe Touch wrote:
> FWIW, I wouldn't mind:
>
> - IPv6 *should* limit its header chains to (some reasonable limit)
>
> What I expect when that's not the case:
>
> - SOME packets get through, perhaps more slowly
> - when the router can't keep up, it can drop the over
FWIW, I wouldn't mind:
- IPv6 *should* limit its header chains to (some reasonable limit)
What I expect when that's not the case:
- SOME packets get through, perhaps more slowly
- when the router can't keep up, it can drop the overload
This isn't any different from many other t
Hi,
On Wed, Jun 12, 2013 at 12:54:59PM -0700, Joe Touch wrote:
> So let me get this straight:
>
> - operationally, it's appropriate to drop all fragments because they
> interfere with a router being efficient
>
> - operationally, it's appropriate to block ICMPs because they could
> interfere w
On 06/12/2013 08:44 PM, Robert Elz wrote:
> | We're not talking ivory tower theoretical routers. We're talking about
> | devices that can stand the heat out there, like "be able to apply
> different
> | rate limiting classes to incoming BGP SYNs from trusted networks, and to
> | ICMP pack
So let me get this straight:
- operationally, it's appropriate to drop all fragments because they
interfere with a router being efficient
- operationally, it's appropriate to block ICMPs because they could
interfere with network operation
Sounds a lot like the Internet and its users are get
On Wed, Jun 12, 2013 at 2:44 PM, Robert Elz wrote:
> everyone knows that if one sends fragmented packets
> performance goes out the window. Perfectly acceptable result, and no
> changes at all to v6 specs are needed to get to that.
edns0 + dnsssec == +1pkt responses
Date:Wed, 12 Jun 2013 19:49:08 +0200
From:Gert Doering
Message-ID: <20130612174908.gt2...@space.net>
| Loop back to about 50 messages earlier in this thread,
I don't generally read this list (any more) - just happened to see the
past hour's worth of messages, so I
On 6/12/2013 10:49 AM, Gert Doering wrote:
Hi,
On Wed, Jun 12, 2013 at 10:06:47AM -0700, Joe Touch wrote:
EVERYTHING that IP *needs* to examine is before the frag header; that's
already in 2460.
And *this* is why IETF is still producing documents that vendors can not
implement. Loop back t
On 6/12/2013 10:36 AM, Fernando Gont wrote:
On 06/12/2013 07:06 PM, Joe Touch wrote:
Cc'd to INTAREA, where I believe fundamental changes to IP should be
discussed:
I disagree. This is nto a fundamental change, but rather a deployment
issue, well within the charter. See:
It can't be just a
Hi,
On Wed, Jun 12, 2013 at 10:58:33AM -0700, Joe Touch wrote:
> > We're talking about
> > devices that can stand the heat out there
>
> Sounds like you're living in a tower much more fragile than ivory.
>
> If you want to stand the heat, build heat-proof stuff.
I'm not a vendor, so I can't bu
Hi,
On Wed, Jun 12, 2013 at 10:06:47AM -0700, Joe Touch wrote:
> EVERYTHING that IP *needs* to examine is before the frag header; that's
> already in 2460.
And *this* is why IETF is still producing documents that vendors can not
implement. Loop back to about 50 messages earlier in this thread,
On 06/12/2013 07:44 PM, Joe Touch wrote:
>>
>> I disagree. This is nto a fundamental change, but rather a deployment
>> issue, well within the charter. See:
>
> It can't be just a deployment issue if it updates 2460 to change how
> fragmentation works.
It doesn't change how fragmentation works. I
On 06/12/2013 07:06 PM, Joe Touch wrote:
> Cc'd to INTAREA, where I believe fundamental changes to IP should be
> discussed:
I disagree. This is nto a fundamental change, but rather a deployment
issue, well within the charter. See:
The 6man working group is responsible for the maintenance, upkeep
Cc'd to INTAREA, where I believe fundamental changes to IP should be
discussed:
On 6/12/2013 5:21 AM, Fernando Gont wrote:
On 06/12/2013 02:37 AM, Mark Andrews wrote:
The obvious limit is no re-assembly required to find the L4 header.
That's already in draft-ietf-6man-oersized-header-chain
On Jun 11, 2013, at 5:50 AM, Jared Mauch wrote:
>
> On Jun 11, 2013, at 12:23 AM, cb.list6 wrote:
>
>> I believe Warren's data hints at the idea that the packets will vanish if
>> they don't fit a very specific profile.
Yup.
>
> Very likely…
>
> Anything beyond the ability of my devic
> it takes a while for equipment to get upgraded everywhere.
>>it's pretty quick, no more than a decade or two
HAHAHAHA. Same in enterprises. Some of our folks are rushing madly from 1980
to 1981.
randy
IETF IPv6 working g
> it takes a while for equipment to get upgraded everywhere.
it's pretty quick, no more than a decade or two
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo
> 2008? RH0?
> Dudes, have we not moved beyond this?
>>Jun 10 15:03:54 psg kernel: IPFW2: IPV6 - Unknown Extension Header(64),
>>ext_hd=0
>>welcome to the operational internet
>>randy
Sure, guys. I was only showing frustration. I suppose at vendors still
supporting headers deprecated
On Jun 11, 2013, at 11:17 AM, Randy Bush wrote:
>> 2008? RH0?
>> Dudes, have we not moved beyond this?
>
Nope, and we never will. It is really easy to send an RH0 packet -- if you were
an attacker, why wouldn't you at least try it?!
> Jun 10 15:03:54 psg kernel: IPFW2: IPV6 - Unknown Ex
> 2008? RH0?
> Dudes, have we not moved beyond this?
Jun 10 15:03:54 psg kernel: IPFW2: IPV6 - Unknown Extension Header(64), ext_hd=0
welcome to the operational internet
randy
IETF IPv6 working group mailing list
ipv6@ietf
On Jun 11, 2013, at 12:23 AM, cb.list6 wrote:
> I believe Warren's data hints at the idea that the packets will vanish if
> they don't fit a very specific profile.
>Very likely…
>Anything beyond the ability of my device to filter poses a security risk.
>Example from 2008 of operators tu
On 06/11/2013 05:56 AM, Brian E Carpenter wrote:
>> Simply saying that there can be arbitrary chaining of x bytes long does not
>> benefit anyone in a practical way, afaik.
>
> IMHO it does; for a start it makes it clear that (say) 257 bytes of
> headers have a vanishingly small chance of getting
On 06/11/2013 11:50 AM, Jared Mauch wrote:
>
> On Jun 11, 2013, at 12:23 AM, cb.list6 wrote:
>
>> I believe Warren's data hints at the idea that the packets will vanish if
>> they don't fit a very specific profile.
>
> Very likely…
>
> Anything beyond the ability of my device to filter pose
On Jun 11, 2013, at 12:23 AM, cb.list6 wrote:
> I believe Warren's data hints at the idea that the packets will vanish if
> they don't fit a very specific profile.
Very likely…
Anything beyond the ability of my device to filter poses a security risk.
Example from 2008 of operators turnin
55 matches
Mail list logo
