Hi Tim,
I will shamelessly plagiarize this text in the next version of the draft!
Ron
>
> "While an IPv6 link MTU can be set to 1280 bytes, it is recommended
>that for IPv6 UDP in particular, which includes DNS operation,
Hi,
> On 21 Nov 2018, at 13:40, Ron Bonica wrote:
>
> Brian,
>
> Fair enough. I have worked the 1280 byte requirement into Section 7.4. New
> text is included below.
>
> Ron
>
> 7.4. For Network Operators
>
> As per RFC 4890, network
> To: Ron Bonica
> Cc: Brian E Carpenter ; Joe Touch
> ; int-area
> Subject: Re: [Int-area] Stateless devices and IP fragmentation
>
> On Fri, Nov 16, 2018 at 7:02 AM Ron Bonica wrote:
> >
> > Hi Brian,
> >
> > Fair enough. Does the following text w
Brian,
Fair enough. I have worked the 1280 byte requirement into Section 7.4. New text
is included below.
Ron
7.4. For Network Operators
As per RFC 4890, network operators MUST NOT filter ICMPv6 PTB
messages unless they are known
> On Nov 17, 2018, at 9:28 AM, Tom Herbert wrote:
>
> On Sat, Nov 17, 2018 at 9:09 AM Joe Touch wrote:
>>
>>
>>
>>> On Nov 17, 2018, at 9:00 AM, Tom Herbert wrote:
>>>
>>> On Fri, Nov 16, 2018 at 7:02 AM Ron Bonica wrote:
Hi Brian,
Fair enough. Does the following
> On Nov 17, 2018, at 9:00 AM, Tom Herbert wrote:
>
> On Fri, Nov 16, 2018 at 7:02 AM Ron Bonica wrote:
>>
>> Hi Brian,
>>
>> Fair enough. Does the following text work?
>>
>> Ron
>>
>> 7.3. For Middle Box Developers
>>
>> Middle boxes SHOULD process IP
telligent middle box deployment decisions.
I don't think this paragraph is needed with the suggested text above.
Tom
>
> > -Original Message-
> > From: Brian E Carpenter
> > Sent: Thursday, November 15, 2018 10:44 PM
> > To: Ron Bonica ; Tom
wrote:
>>> Tom, Joe, Brian,
>>>
>>> I haven't seen a response to this message. Can I assume that you are OK with
>> this text?
>>>
>>> Ron
>>>
>>>
Touch
> SENT: Thursday, November 15, 2018 5:24 PM
> TO: Ron Bonica
> CC: Tom Herbert ; Brian E Carpenter
> ; int-area
> SUBJECT: Re: [Int-area] Stateless devices and IP fragmentation
>
> On 2018-11-15 13:35, Ron Bonica wrote:
>
> Tom, Joe, Brian,
>
>
Ron
> >
> >
> >> -Original Message-----
> >> From: Ron Bonica
> >> Sent: Wednesday, November 14, 2018 4:35 PM
> >> To: Tom Herbert
> >> Cc: int-area ;
't seen a response to this message. Can I assume that you are OK with
> this text?
>
> Ron
>
>
>> -Original Message-
>> From: Ron Bonica
>> Sent: Wednesday, November 14, 2018 4:35 PM
>> To: Tom Herbert
>>
rea ; Joe Touch
> Subject: RE: [Int-area] Stateless devices and IP fragmentation
>
> Folks,
>
> We thrashing over the example. Can everybody agree to the following text?
>
>Ron
>
> 7.3. For Middle Box Developers
>
> Midd
; From: Tom Herbert
>>>>> Sent: Wednesday, November 14, 2018 3:02 PM
>>>>> To: Ron Bonica
>>>>> Cc: int-area ; Joe Touch
>>>>> Subject: Re: [Int-area] Stateless devices and IP fragmentation
>>>>>
>>>>>
a
> Cc: int-area ; Joe Touch
> Subject: Re: [Int-area] Stateless devices and IP fragmentation
>
> On Wed, Nov 14, 2018 at 11:35 AM, Ron Bonica
> wrote:
> > Folks,
> >
> > Since we seem to have reached consensus on Section 7.1, let's take another
> stab at Secti
gt; that we can reach consensus in this round.
>>>
>>> Ron
>>>
>>>
>>>> -Original Message-
>>>> From: Tom Herbert
>>>> Sent: Wednesday, November 14, 2018 3:02 PM
&g
November 14, 2018 3:29 PM
> TO: Ron Bonica
> CC: Tom Herbert ; int-area
> SUBJECT: Re: [Int-area] Stateless devices and IP fragmentation
>
> On 2018-11-14 11:35, Ron Bonica wrote:
>
>> Folks,
>>
>> Since we seem to have reached consensus on Section 7.1, let
On 2018-11-14 13:25, Brian E Carpenter wrote:
> ...
>
> Trying to use the traditional 5-tuple will not work well with
> fragments.
>
> It's more complicated at the server farm end.
> "Moreover, the transport-layer
> information such as the source port is not repeated in fragments,
> which
Folks,
We thrashing over the example. Can everybody agree to the following text?
Ron
7.3. For Middle Box Developers
Middle boxes SHOULD process IP fragments in a manner that is compliant with RFC
791 and RFC 8200. In many cases, middle boxes
Ron
>>
>>
>>> -Original Message-
>>> From: Tom Herbert
>>> Sent: Wednesday, November 14, 2018 3:02 PM
>>> To: Ron Bonica
>>> Cc: int-area ; Joe Touch
>>> Subject: Re: [Int-area] Stateless
Cc: Tom Herbert ; int-area
Subject: Re: [Int-area] Stateless devices and IP fragmentation
On 2018-11-14 11:35, Ron Bonica wrote:
Folks,
Since we seem to have reached consensus on Section 7.1, let's take another stab
at Section 7.3. I am looking particularly to Tom Herbert and Joe Touch
On 2018-11-14 12:35, Ole Troan wrote:
> Joe,
>
> For IPv4 part of the transport headers are now part of the network layer.
> Forwarding is done one address and port.
> I.e it's now part of 'normal' routing/forwarding. That's absolutely not the
> case. In IPv6 packets are delivered to hosts
sage-
>> From: Tom Herbert
>> Sent: Wednesday, November 14, 2018 3:02 PM
>> To: Ron Bonica
>> Cc: int-area ; Joe Touch
>> Subject: Re: [Int-area] Stateless devices and IP fragmentation
>>
>> On Wed, Nov 14, 2018 at 11:35 AM, Ron Bonica
>> wrote:
>&
>
>> Of course you can pass non TCP/UDP through limited domains, but you cannot
>> expect that to work across the Internet anymore.
>
> You mean the IPv4nternet, I hope ;-).
I hope so too. ;-)
Ole
___
Int-area mailing list
Int-area@ietf.org
On 2018-11-15 09:31, Ole Troan wrote:
> Tom,
>
>> I don't believe this can be true. Not all protocols even have port
>> numbers (e.g. ICMP, ESP) and yet we still expect them to be
>> deliverable. Maybe your referring to ECMP, which does route based on
>> flow (e.g. port information)? But, ECMP is
Joe,
>> For IPv4 part of the transport headers are now part of the network layer.
>> Forwarding is done one address and port.
>> I.e it's now part of 'normal' routing/forwarding. That's absolutely not the
>> case. In IPv6 packets are delivered to hosts based on longest match on
>> destination
Tom,
> I don't believe this can be true. Not all protocols even have port
> numbers (e.g. ICMP, ESP) and yet we still expect them to be
> deliverable. Maybe your referring to ECMP, which does route based on
> flow (e.g. port information)? But, ECMP is not required to make IP
> work either.
On 2018-11-14 11:35, Ron Bonica wrote:
> Folks,
>
> Since we seem to have reached consensus on Section 7.1, let's take another
> stab at Section 7.3. I am looking particularly to Tom Herbert and Joe Touch
> for feedback, since they objected to the previous formulation.
>
> Proposed text
On 2018-11-14 11:33, Ole Troan wrote:
> Joe,
>
> Again, this does nothing for middleboxes that can handle IPv6 fragments. Flow
> labels don't fix DPI or NAT devices.
> It wasn't meant to. If you read my post, I clearly stated the IPv4 Internet.
>
> There is much less justification to
On Wed, Nov 14, 2018 at 11:35 AM, Ron Bonica wrote:
> Folks,
>
> Since we seem to have reached consensus on Section 7.1, let's take another
> stab at Section 7.3. I am looking particularly to Tom Herbert and Joe Touch
> for feedback, since they objected to the previous formulation.
>
> Proposed
On Wed, Nov 14, 2018 at 11:33 AM, Ole Troan wrote:
> Joe,
>
Again, this does nothing for middleboxes that can handle IPv6 fragments.
Flow labels don’t fix DPI or NAT devices.
>>>
>>> It wasn’t meant to. If you read my post, I clearly stated the IPv4 Internet.
>>>
>>> There is much less
Folks,
Since we seem to have reached consensus on Section 7.1, let's take another stab
at Section 7.3. I am looking particularly to Tom Herbert and Joe Touch for
feedback, since they objected to the previous formulation.
Proposed text follows
Ron
Joe,
>>> Again, this does nothing for middleboxes that can handle IPv6 fragments.
>>> Flow labels don’t fix DPI or NAT devices.
>>
>> It wasn’t meant to. If you read my post, I clearly stated the IPv4 Internet.
>>
>> There is much less justification to “encourage deprecation” of IPv6
>>
> On Nov 14, 2018, at 7:01 AM, Ole Troan wrote:
>
> Joe,
>
>> Again, this does nothing for middleboxes that can handle IPv6 fragments.
>> Flow labels don’t fix DPI or NAT devices.
>
> It wasn’t meant to. If you read my post, I clearly stated the IPv4 Internet.
>
> There is much less
Again, this does nothing for middleboxes that can handle IPv6 fragments. Flow
labels don’t fix DPI or NAT devices.
Joe
On Nov 14, 2018, at 2:16 AM, Ole Troan wrote:
>>> RFC7596 specifies destination unreachable, host unreachable for this.
>> You have to be careful; that would cause the
>> RFC7596 specifies destination unreachable, host unreachable for this.
> You have to be careful; that would cause the origin to cease sending all
> traffic to that IP address - which works for that RFC (which is L3 oriented),
> when in fact it is only the lack of the L4 info that makes it
8 7:07 PM
To: Ron Bonica mailto:rbon...@juniper.net>>
Cc: Tom Herbert mailto:t...@herbertland.com>>; Ole Troan
mailto:otr...@employees.org>>; int-area
mailto:int-area@ietf.org>>
Subject: Re: [Int-area] Stateless devices and IP fragmentation
Notes below...
On Nov 12
, November 12, 2018 7:07 PM
To: Ron Bonica
Cc: Tom Herbert ; Ole Troan ;
int-area
Subject: Re: [Int-area] Stateless devices and IP fragmentation
Notes below...
On Nov 12, 2018, at 3:56 PM, Ron Bonica
mailto:rbon...@juniper.net>> wrote:
Tom,
OK. Let's see if the following text wor
On 2018-11-13 13:01, Ole Troan wrote:
> On 13 Nov 2018, at 21:39, Joe Touch wrote:
>
> On 2018-11-12 23:18, Ole Troan wrote:
> See my suggested text - I.e., if you can't handle the fragments they way you
> WANT, then you need to forward them.
> To where?
> When the forwarding decision is
gt; FROM: Joe Touch
> SENT: Monday, November 12, 2018 7:07 PM
> TO: Ron Bonica
> CC: Tom Herbert ; Ole Troan ;
> int-area
> SUBJECT: Re: [Int-area] Stateless devices and IP fragmentation
>
> Notes below...
>
>> On Nov 12, 2018, at 3:56 PM, Ron Bonica
> See my suggested text - I.e., if you can’t handle the fragments they way you
> WANT, then you need to forward them.
To where?
When the forwarding decision is based on L4 information, as it is inthe IPv4
Internet, the best we could do is to send an ICMP destination unreachable back.
>
> IMO,
> Sure, but then the device can no longer be called stateless. AFAICT
> using the flow label in the hash is the only way that a stateless L4
> load balancer could get a consistent hash between fragments and
> non-fragments.
>
> Tom
>
>>
>> Undesirable outcomes c
MUST document the behaviors that
> their devices exhibit.
>
>
>
>
>> -Original Message-----
>> From: Tom Herbert
>> Sent: Monday, November 12, 2018 4:25 PM
>> To: Ron Bonica
>> Cc: Joe Touch ; Ole Troan
>> ; int-area
>> Subject: Re: [I
encapsulation.
>>>>
>>>>> 2) Application-layer protocols that depend upon IPv6 fragmentation
>>>> SHOULD be updated to break that dependency.
>>>>
>>>> Same issue...
>>>>
>>>>> 3) Middle box
vember 12, 2018 4:25 PM
> To: Ron Bonica
> Cc: Joe Touch ; Ole Troan
> ; int-area
> Subject: Re: [Int-area] Stateless devices and IP fragmentation
>
> On Mon, Nov 12, 2018 at 1:08 PM, Ron Bonica wrote:
> > Joe, Tom,
> >
&
issue and propose work-arounds.
>
>> -Original Message-----
>> From: Joe Touch
>> Sent: Monday, November 12, 2018 2:02 PM
>> To: Ron Bonica
>> Cc: Ole Troan ; Tom Herbert
>> ; int-area
>> Subject: Re: [Int-area] Stateless devices and IP fragmentation
&
work-arounds.
> -Original Message-
> From: Joe Touch
> Sent: Monday, November 12, 2018 2:02 PM
> To: Ron Bonica
> Cc: Ole Troan ; Tom Herbert
> ; int-area
> Subject: Re: [Int-area] Stateless devices and IP fragmentation
>
> Ron
>
> As I noted, S
elopers heed these
>> recommendations, they will avoid some amount of pain. However, it is
>> understood that these recommendations will not be heeded by all. Hence the
>> word "SHOULD".
>>
>>
>> Ron
>>> -Orig
od that these recommendations will not be heeded by all. Hence the
> word "SHOULD".
>
>
> Ron
>> -Original Message-
>> From: Ole Troan
>> Sent: Monday, November 12, 2018 5:23 AM
>>
> Ron
>> -Original Message-
>> From: Ole Troan
>> Sent: Monday, November 12, 2018 5:23 AM
>> To: Joe Touch
>> Cc: Tom Herbert ; Ron Bonica
>> ; int-area
>> Subject: Re: [Int-area] Stateless devic
er 12, 2018 5:23 AM
> To: Joe Touch
> Cc: Tom Herbert ; Ron Bonica
> ; int-area
> Subject: Re: [Int-area] Stateless devices and IP fragmentation
>
>
>
> > On 12 Nov 2018, at 11:11, Joe Touch wrote:
> >
> >
> >
> > On Nov 12
> On 12 Nov 2018, at 11:11, Joe Touch wrote:
>
>
>
> On Nov 12, 2018, at 1:36 AM, Ole Troan wrote:
>
>>> And none of these update RFC1812.
>>>
>>> These things can be rolled out in any numbers you like - they are creating
>>> the problem that only they can clean up. Killing capability in
On Nov 12, 2018, at 1:36 AM, Ole Troan wrote:
>> And none of these update RFC1812.
>>
>> These things can be rolled out in any numbers you like - they are creating
>> the problem that only they can clean up. Killing capability in the rest of
>> the Internet to make these mechanisms work
> And none of these update RFC1812.
>
> These things can be rolled out in any numbers you like - they are creating
> the problem that only they can clean up. Killing capability in the rest of
> the Internet to make these mechanisms work isn’t a viable solution and never
> has been.
And if
And none of these update RFC1812.
These things can be rolled out in any numbers you like - they are creating the
problem that only they can clean up. Killing capability in the rest of the
Internet to make these mechanisms work isn’t a viable solution and never has
been.
Joe
> On Nov 8, 2018,
Joe,
> On 9 Nov 2018, at 00:55, Joe Touch wrote:
>
> Experimental. For a reason.
No. The protocol instances are standard documents. Rfc7596, 7597, 7599.
We have had this discussion before.
We are not going to agree, and there might not be any purpose disturbing the wg
with this.
But
> On Nov 8, 2018, at 9:27 AM, Tom Herbert wrote:
>
> I don't know what "edge devices" are in the context of IP protocols.
Simple. Anything that depends on information beyond the IP header. It’s what
they look at, not where they are (mis)located.
> I
> do know these devices are NOT hosts--
Experimental. For a reason.
> On Nov 8, 2018, at 9:13 AM, Ole Troan wrote:
>
>
>
>> On 9 Nov 2018, at 00:02, Joe Touch wrote:
>>
>> Please indicate the basis of your belief. Mine is RFC1812.
>
> CGNs, RFC6346 et al.
> Your belief system is unfortunately outdated.
> I don’t like it
On Thu, Nov 8, 2018 at 9:07 AM, Joe Touch wrote:
> Boxes that do DPI ***are*** edge devices, regardless of where they
> are(mid)placed.
>
I don't know what "edge devices" are in the context of IP protocols. I
do know these devices are NOT hosts-- the destination address of
packets is not their
> On 9 Nov 2018, at 00:02, Joe Touch wrote:
>
> Please indicate the basis of your belief. Mine is RFC1812.
CGNs, RFC6346 et al.
Your belief system is unfortunately outdated.
I don’t like it anymore than you do.
And no, you cannot pretend these don’t exist by declaring them extensions of
Boxes that do DPI ***are*** edge devices, regardless of where they
are(mid)placed.
That’s why they should be required to do the equivalent work.
Just because they ‘don’t want to’ doesn’t make it so.
Joe
> On Nov 8, 2018, at 8:48 AM, Tom Herbert wrote:
>
> Unlike intermediate devices,
Please indicate the basis of your belief. Mine is RFC1812.
> On Nov 8, 2018, at 8:43 AM, Ole Troan wrote:
>
>
>
>> On 8 Nov 2018, at 23:15, Joe Touch wrote:
>>
>>
>> It always can forward based on IP info alone. It is only the desire to alter
>> packets in transit or forward based on
On Thu, Nov 8, 2018 at 8:15 AM, Joe Touch wrote:
> Dropping those non initial fragments isn’t work conserving either.
>
> The point is that work conservation needs to consider the impact of the
> forwarded or dropped messages, not merely whether info is passed on an
> outgoing wire.
>
> And to
> On 8 Nov 2018, at 23:15, Joe Touch wrote:
>
>
> It always can forward based on IP info alone. It is only the desire to alter
> packets in transit or forward based on transport info that gets in the way.
Joe, I have told you many times over that this is wrong for IPv4. Repeating it
does
Dropping those non initial fragments isn’t work conserving either.
The point is that work conservation needs to consider the impact of the
forwarded or dropped messages, not merely whether info is passed on an outgoing
wire.
And to be clear, the only party that puts the onus of keeping state
On Wed, Nov 7, 2018 at 10:32 AM, Joe Touch wrote:
> Sorry - previous response got cut off. Let's try again...
>
>
>
>
> On 2018-11-07 10:08, Tom Herbert wrote:
>
> On Wed, Nov 7, 2018 at 9:24 AM, Joe Touch wrote:
>
> It conserves no work to pass fragments that will be dropped later.
>
>
>> We need compliance checks to fix this, or to find another way to put more
>> pain where the problem lies.
>
> I would like to hear from the vendors of the stateless devices whether
> they think this is feasible solution.
Implementations tend to live within the laws of physics, so demanding
Sorry - previous response got cut off. Let's try again...
On 2018-11-07 10:08, Tom Herbert wrote:
> On Wed, Nov 7, 2018 at 9:24 AM, Joe Touch wrote:
>
>> It conserves no work to pass fragments that will be dropped later.
>>
>> Customers want devices that work. This is a tragedy of the
On Wed, Nov 7, 2018 at 9:24 AM, Joe Touch wrote:
> It conserves no work to pass fragments that will be dropped later.
>
> Customers want devices that work. This is a tragedy of the commons issue.
> Nobody wants other people’s devices to drop their fragments. But nobody wants
> to pay to not
It conserves no work to pass fragments that will be dropped later.
Customers want devices that work. This is a tragedy of the commons issue.
Nobody wants other people’s devices to drop their fragments. But nobody wants
to pay to not drop fragments of others.
We need compliance checks to fix
On Wed, Nov 7, 2018 at 8:28 AM, Joe Touch wrote:
> The current “solution” of ignoring this need isn’t tenable either, though. It
> isn’t “work conserving” to simply drop traffic that is deemed too expensive
> to handle.
>
The device can choose to drop the first fragment, but allow non-first
The current “solution” of ignoring this need isn’t tenable either, though. It
isn’t “work conserving” to simply drop traffic that is deemed too expensive to
handle.
It’s always appealing - and profitable - for vendors to shortchange customers.
Joe
> On Nov 7, 2018, at 8:07 AM, Tom Herbert
71 matches
Mail list logo
