On Sun, Aug 26, 2018 at 08:19:41PM -0700, Tom Herbert wrote:
> Toerless,
>
> I'm not sure what "outsourced into a common network component" means.
> I've done a lot of app and OS development and have NEVER once
> "outsourced" security to the network.
And i worked in a company where for a good
On Sun, Aug 26, 2018 at 7:35 PM, Toerless Eckert wrote:
> On Sun, Aug 26, 2018 at 05:10:00PM -0700, Joe Touch wrote:
>> Agreed, but reassembly is clearly possible (hosts do it). The issue is cost.
>>
>> We are not in the business of defending a vendor's idea of profit margin
>> WHEN it gets in
> On Aug 26, 2018, at 7:35 PM, Toerless Eckert wrote:
>
> On Sun, Aug 26, 2018 at 05:10:00PM -0700, Joe Touch wrote:
>> Agreed, but reassembly is clearly possible (hosts do it). The issue is cost.
>>
>> We are not in the business of defending a vendor's idea of profit margin
>> WHEN it gets
On Sun, Aug 26, 2018 at 05:10:00PM -0700, Joe Touch wrote:
> Agreed, but reassembly is clearly possible (hosts do it). The issue is cost.
>
> We are not in the business of defending a vendor's idea of profit margin
> WHEN it gets in the way of a required mechanism. I've described why it's
>
On 8/26/2018 4:16 PM, Tom Herbert wrote:
> On Sun, Aug 26, 2018 at 2:55 PM, Toerless Eckert wrote:
>> On Sun, Aug 26, 2018 at 11:38:57AM -0700, Joe Touch wrote:
>>> NATs already have what they need to do the proper job - they need to
>>> reassemble and defragment using unique IDs (or cache
On 8/26/2018 4:33 PM, Toerless Eckert wrote:
> On Sun, Aug 26, 2018 at 03:50:18PM -0700, Joe Touch wrote:
>>> Reassmbly/refragment and MTU discovery puts NAT out of the realm of many
>>> cost effective HW acceleration methods. Simple address rewrite does not.
>> And crumple zones and airbags get
On Sun, Aug 26, 2018 at 04:16:39PM -0700, Tom Herbert wrote:
> When the host stack pundits are asking network device stack builders
> to conform to the standard protocols then I believe that is
> reasonable. If firewalls were standard and ubiquitous, and standards
> were adhered to, then host
On Sun, Aug 26, 2018 at 03:50:18PM -0700, Joe Touch wrote:
> > Reassmbly/refragment and MTU discovery puts NAT out of the realm of many
> > cost effective HW acceleration methods. Simple address rewrite does not.
>
> And crumple zones and airbags get in the way of cars running fast and being
>
On Sun, Aug 26, 2018 at 2:55 PM, Toerless Eckert wrote:
> On Sun, Aug 26, 2018 at 11:38:57AM -0700, Joe Touch wrote:
>> NATs already have what they need to do the proper job - they need to
>> reassemble and defragment using unique IDs (or cache the first fragment when
>> it arrives and use it
On Sun, Aug 26, 2018 at 2:12 PM, Joe Touch wrote:
>
>
> On Aug 26, 2018, at 12:58 PM, Tom Herbert wrote:
>
> On Sun, Aug 26, 2018 at 11:38 AM, Joe Touch wrote:
>
>
>
> On Aug 26, 2018, at 10:31 AM, Christian Huitema wrote:
>
> It seems that the biggest obstacle to fragmentation are NAT and
> On Aug 26, 2018, at 3:03 PM, Toerless Eckert wrote:
>
> On Sun, Aug 26, 2018 at 11:26:47PM +0200, Ole Troan wrote:
>>
>>
>>> On 26 Aug 2018, at 23:12, Joe Touch wrote:
>>>
>>> As I???ve mentioned, there are rules under which a NAT is a valid Internet
>>> device, but it is simply not
> On Aug 26, 2018, at 2:55 PM, Toerless Eckert wrote:
>
> On Sun, Aug 26, 2018 at 11:38:57AM -0700, Joe Touch wrote:
>> NATs already have what they need to do the proper job - they need to
>> reassemble and defragment using unique IDs (or cache the first fragment when
>> it arrives and use
> On Aug 26, 2018, at 2:31 PM, Toerless Eckert wrote:
>
> On Sun, Aug 26, 2018 at 09:09:54AM -0700, Joe Touch wrote:
>>
>>
>>> On Aug 24, 2018, at 8:24 PM, Toerless Eckert wrote:
>>>
>>> Of course. Will take a decade to get ubiquitously deployed, but
>>> neither IPv4 nor IPv6 will go away,
> On Aug 26, 2018, at 2:27 PM, Toerless Eckert wrote:
>
> Took us decades to figure out that in-network
> fragmentation (as mandaory in IPv4) is not a good thing, and
> we eliminated it for IPv6. Why do we hang on to fragmentation
> from the host when tranport layers would be better doing it
> On Aug 26, 2018, at 2:26 PM, Ole Troan wrote:
>
>
>
>> On 26 Aug 2018, at 23:12, Joe Touch wrote:
>>
>> As I’ve mentioned, there are rules under which a NAT is a valid Internet
>> device, but it is simply not just a router.
>
> If there really was, can you point to where those rules
On Sun, Aug 26, 2018 at 11:26:47PM +0200, Ole Troan wrote:
>
>
> > On 26 Aug 2018, at 23:12, Joe Touch wrote:
> >
> > As I???ve mentioned, there are rules under which a NAT is a valid Internet
> > device, but it is simply not just a router.
>
> If there really was, can you point to where
On Sun, Aug 26, 2018 at 11:38:57AM -0700, Joe Touch wrote:
> NATs already have what they need to do the proper job - they need to
> reassemble and defragment using unique IDs (or cache the first fragment when
> it arrives and use it as context for later - or earlier cached - fragments).
>
On Sun, Aug 26, 2018 at 09:09:54AM -0700, Joe Touch wrote:
>
>
> > On Aug 24, 2018, at 8:24 PM, Toerless Eckert wrote:
> >
> > Of course. Will take a decade to get ubiquitously deployed, but
> > neither IPv4 nor IPv6 will go away, only the problems with fragmentation
> > will become worse and
On Sat, Aug 25, 2018 at 01:46:47PM -0700, Joel Jaeggli wrote:
> It's actually not that useful if it's an icmp message. because it's
> going to fail in many cases where it has to be hashed to a destination.
> just like non-initial fragements do...
>
> 4821 gets you there with tcp.
Its meant to
On Sat, Aug 25, 2018 at 08:32:41AM +0200, Mikael Abrahamsson wrote:
> > IMHO, we (network layer) should accept defeat on network layer
> > fragmentation and agree that we should make it easier for the
> > transport layer to resolve the problem.
>
> I want to keep the fragmentation requirement for
> On 26 Aug 2018, at 23:12, Joe Touch wrote:
>
> As I’ve mentioned, there are rules under which a NAT is a valid Internet
> device, but it is simply not just a router.
If there really was, can you point to where those rules are? Describing the
behavior of the host stack and applications?
> On Aug 26, 2018, at 12:58 PM, Tom Herbert wrote:
>
> On Sun, Aug 26, 2018 at 11:38 AM, Joe Touch wrote:
>>
>>
>>> On Aug 26, 2018, at 10:31 AM, Christian Huitema wrote:
>>>
>>> It seems that the biggest obstacle to fragmentation are NAT and Firewall.
>>> They need the port numbers in
On Sun, Aug 26, 2018 at 11:38 AM, Joe Touch wrote:
>
>
>> On Aug 26, 2018, at 10:31 AM, Christian Huitema wrote:
>>
>> It seems that the biggest obstacle to fragmentation are NAT and Firewall.
>> They need the port numbers in order to find and enforce context. NAT might
>> be going away with
> On Aug 26, 2018, at 10:31 AM, Christian Huitema wrote:
>
> It seems that the biggest obstacle to fragmentation are NAT and Firewall.
> They need the port numbers in order to find and enforce context. NAT might be
> going away with IPv6, maybe, but firewalls are not.
>
> Have considered
On Sun, Aug 26, 2018 at 10:31 AM, Christian Huitema wrote:
> It seems that the biggest obstacle to fragmentation are NAT and Firewall.
> They need the port numbers in order to find and enforce context. NAT might be
> going away with IPv6, maybe, but firewalls are not.
>
> Have considered
It seems that the biggest obstacle to fragmentation are NAT and Firewall. They
need the port numbers in order to find and enforce context. NAT might be going
away with IPv6, maybe, but firewalls are not.
Have considered strategies that move the port number inside the IP header? For
example,
On Fri, Aug 24, 2018 at 8:24 PM, Toerless Eckert wrote:
> On Fri, Aug 03, 2018 at 09:48:25AM +0200, Mikael Abrahamsson wrote:
>> I've kept saying "Networks must support ip fragmentation properly.
>
> Why ? Wheren't you also saying that you've got (like probably many
> else on this thread) all the
> On Aug 24, 2018, at 8:24 PM, Toerless Eckert wrote:
>
> Of course. Will take a decade to get ubiquitously deployed, but
> neither IPv4 nor IPv6 will go away, only the problems with fragmentation
> will become worse and work if we do not have an exit strategy like this.
>
> If we don't try
28 matches
Mail list logo
