of an earlier
non-ATOMIC packet
S/ATOMIC/atomic/ ?
RFC 1122 also suggests that fragments can overlap [RFC1122]. Such
overlap can occur if successive retransmissions use different
packetizing but the same reassembly Id.
s/Id/ID/
Thanks!
Kind regards,
--
Fernando Gont
e-mail: ferna
not necessary.
Well, you have argued many times in favor of accepting error messages
(ICMP hard errors) that could be stale, be generated by corrupted
datagrams (e.g., by firewalls), etc. So what?
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9
* in 5 years or so with
something else, I'd argue Why not?. There are estimates of 15-20 more
years of living with IPv4, so
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
-to-end transparency in the sense that every node will be reachable
from every node? -- IMHO, forget about it (see slide 13 of:
http://www.gont.com.ar/talks/lacnog2010/fgont-lacnog2010-ipv6-security.pdf)
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809
are important when a cluster of devices is intended to act
as a single device on the Internet, and a NAT can be an effective way to
implement that front-end.
... and don't forget about renumbering.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5
Hi, Lars,
On 06/12/2012 04:36 AM, Eggert, Lars wrote:
Hi,
shouldn't we at the same time also be making the RFCs that originally
registered these option numbers Historic?
You're absolutely right. The next rev will do this.
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg
to develop major changes or
additions to the IPv6 specifications.
IPv6 already puts all the per-hop information before the fragmentation
header. Requiring the entire header chain to be inside the first
fragment is, IMO, a major change.
I guess we must agree to disagree.
Thanks,
--
Fernando Gont
just aiming at limiting the header chain length, *not* encouraging
router to drop when the header chain exceeds that length.
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
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 recommendation
,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
.
If we continue on the current path (do nothing), they will be
effectively killed. (see Brian et al's I-D, Warren et al's I-D, etc.).
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
to be in disagreement. If anything, anything that I don't want
is not an attack, but rather an unnecessary attack surface. But again,
please read the I-D... because it really doesn't follow that reasoning.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2
houghts?
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
these protocols are referred to as "firewall
> friendly".
>
> [Rick] The scenario makes no sense other than a mismanaged company
> frankly. You are essentially encouraging something against BCP. Even
> beyond security you will make it difficult to troubleshoot if everything
-01.txt
Date: Tue, 13 Oct 2015 06:45:30 -0700
From: internet-dra...@ietf.org
To: Fred Baker <f...@cisco.com>, Fernando Gont <fg...@si6networks.com>
A new version of I-D, draft-gont-opsawg-firewalls-analysis-01.txt
has been successfully submitted by Fernando Gont and posted to the
IET
If you mean TLS, it prevents DPI, but still allows for filtering based
on port numbers...
> - recommendation for NOT BLOCKING traffic over the Internet (except to
> each ISP own infrastructure)?
not blocking which sort of traffic?
> - logging / au
ch is more of a "fingers crossed" thing (if anything).
I'm not saying that I'm happy with the outcome, but rather that I think
that from an engenering point of view, it all looks like this ship has
sailed, and we should probably figure out how to deal with those cases
where fragmentation is actua
On 07/27/2018 05:15 PM, Tom Herbert wrote:
> On Fri, Jul 27, 2018 at 5:38 AM, Fernando Gont wrote:
>> Hi, Joe,
>>
>> On 07/26/2018 04:14 AM, Joe Touch wrote:
>>> Hi, all,
[]
>>
>> Side coments:
>>
>> It would all seem that there are tw
is EHs
is dropped to some extent (while not included in the RFC, I also mesured
IPsec, and you get similar numbers). So besides the issues that are
specific to fragmentation, anything that is EHs gets dropped here an
there. -- and ding ECMP with the FL will not change that.
(Again: not that I'm happy
over UDP to be able to survive NATs
and firewalls
Yes, and one hand is not nice to have to account for all types of
brokenness and filtering. OTOH, it would make any sense to enigneer a
protocol that only works on paper.
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@
ch assumption. Where you can't, you
may have to do stateful firewalling.
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
). Use of the fragment header with IPv4 is
> compelling because it could address deficencies in IPv4 fragmentation
> like the small ID field. It might also free up IPID to be used as an
> IPv4 flow label (RFC6864 states IPID can be arbitrarily set for atomic
> datagrams).
Isn't the general co
nality should be removed.
+ fwiw, i don't care that much about the outcome, as long as there's
some level of convergence among specs, devices, and deployed
reality
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:
ol development and application
>>>> development?
>>>
>>> I’m specifically wondering about application protocols (as distinct from
>>> other protocols) developed in the IETF (as distinct from developed
>>> elsewhere). Sometimes we use BCPs to guide future w
r IPv6 the only guarantee is 1280. Therefore, in order to robustly support
> the minimum IPv6 MTU tunnels MUST employ fragmentation.
Isn't that an oxymoron? If fragmentation is fragile, if you need
something robust, you need to rely on something else
--
Fernando Gont
SI6 Networks
e-mail: fg...@
On 3/9/19 18:39, Tom Herbert wrote:
>
>
> On Tue, Sep 3, 2019, 8:31 AM Fernando Gont <mailto:fg...@si6networks.com>> wrote:
>
> On 3/9/19 17:33, Templin (US), Fred L wrote:
> > Why was this section taken out:
> &
On 4/9/19 00:34, Tom Herbert wrote:
> On Tue, Sep 3, 2019 at 1:49 PM Fernando Gont wrote:
>>
>> On 3/9/19 23:33, Tom Herbert wrote:
>>> Bob,
>>>
[]
>> "fragile" means that it fails in an uncceptably large number of cases.
>> ~30 failur
widespread famine, and others.
I don't think that logic has solved any real problems in the real world.
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
On 4/9/19 00:02, Templin (US), Fred L wrote:
> Fernando,
>
>> -Original Message-----
>> From: Fernando Gont [mailto:fg...@si6networks.com]
>> Sent: Tuesday, September 03, 2019 1:49 PM
>> To: Tom Herbert ; Bob Hinden
>> Cc: Templin (US), Fred L ; int-ar
On 5/9/19 17:31, Tom Herbert wrote:
> On Wed, Sep 4, 2019 at 5:34 PM Fernando Gont wrote:
>>
>> On 4/9/19 18:26, Templin (US), Fred L wrote:
>>> Hi Ole,
>>>
>>>> -Original Message-
>>>> From: Ole Troan [mailto:otr...@employ
ear. That seems pretty good to me. Which shows that implementers
> have taken IP fragmentation seriously and put in the hard work necessary to
> optimize the performance.
Have you ever checked the number of CVEs related to fragmentation?
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networ
On 4/9/19 16:46, Templin (US), Fred L wrote:
> Hi Fernando,
>
>> -Original Message-----
>> From: Fernando Gont [mailto:fg...@si6networks.com]
>> Sent: Tuesday, September 03, 2019 2:45 PM
>> To: Templin (US), Fred L ; Tom Herbert
>> ; Bob Hinden
>&
e no idea that some set of layers
> inflates the headers (e.g., with signatures or key exchanges) beyond the MTU
> somewhere.
This would seem to be incorrect. IP has a minimum MTU of 68 bytes, and
IPv6 has a minimum MTU of 1280. Hence if you send packets smaller than
or equal to the minimum MTU, th
claim this is hand-waving.
FWIW, I don't remember seeing anything like this at the network layer.
(One might guess that in theory you *could* get feedback from upper
layers, but...)
This kind of thing is easier at *higher* layers -- such as trying to do
the 3WHS with the ECN bits set, and if you don't h
Tom,
On 7/8/19 04:50, Tom Herbert wrote:
> On Tue, Aug 6, 2019 at 6:17 PM Fernando Gont wrote:
>>
>> Hello, Alissa,
>>
>> Thanks for your comments! Inline...
>>
>> On 6/8/19 23:
On 7/8/19 17:07, Joe Touch wrote:
>
>
>> On Aug 7, 2019, at 7:01 AM, Fernando Gont > <mailto:ferna...@gont.com.ar>> wrote:
>>
>> On 7/8/19 16:30, Joe Touch wrote:
>>> Things that don’t work aren’t always either deprecated or secur
ating stuff that is
not possible to implement in a meaningful way, vendors for claiming they
support something when they do it in a very poorly way, or ops folks for
solving their problems with what they have at hand (instead of e.g. to
applying pain to vendors or SDOs, if at all possible)). :-)
essentially IPv6 EHs, as per RFC7872).
That is: can you reliably use them? --Not at all... expect when you run
the network yourself.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9
ted. The message here is "unless you really know what you are
doing and you're in e.g. a controlled environment where fragmentation is
known to be supported, you shouldn't rely on fragmentation".
I wouldn't mind myself stronger advice, but this is what the wg settled on.
Thanks,
--
Fernan
loy RFC2119
language to quote requirements from other RFCs, while in this specific
case we use caps to stress that this is the advice we are giving out.
FWIW, the advice hopefully triggers work for any protocols expected to
work across the Internet, and that currently rely on fragmentation.
--
Fernando Gont
ding
on whether you want to make sure that packets cannot be injected, or
that packets cannot leak out.
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
In
On 29/2/20 23:19, Joseph Touch wrote:
On Feb 29, 2020, at 5:46 PM, Fernando Gont <mailto:ferna...@gont.com.ar>> wrote:
I did look at the protocols involved here; the ingress does add
headers but doesn’t appear to handle fragmentation.
That’s a non-starter if you want you
keep trying to push
similar ideas in other documents.
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf
low the insertion/removal of
extension header while the packets are en-route to the final destination.
I wished this conversation could go back to a honest one.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7
document.
I'm glad that there are more eyes now looking at what's going on.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
ples that we're developing
specs within?
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
On 27/2/20 23:18, Phillip Hallam-Baker wrote:
On Thu, Feb 27, 2020 at 8:52 PM Fernando Gont <mailto:fg...@si6networks.com>> wrote:
On 27/2/20 20:58, Robert Raszuk wrote:
>
[...]
>
> We need to ask ourselves what is more important ... quality of
use one
document says one thing, and another says another thing.
There's a reason for which we have the "Update" and "Obsolete" tags in
RFCs...
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
g that won't have a single bit of
coherence, virtually impossible to digest by anybody else other by than
a limited group of people that just happens to know how everyone
violates each others specs.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484
n there's stuff at
stake, only big vendors get to play, with their own rules".
I'll refer to Jinmei's email, which esentially conveys the same message
<https://mailarchive.ietf.org/arch/msg/spring/hmmgQygE0qIhOrt4Ii_1ANDQgHM/>
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6ne
have an explanation of how PMTUD and error
reporting works. And it doesn't have one.
In that light, I'm curious how folks can state that eh insertion/removal
is allowed.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9
ly rubber-stamping any hacks a vendor with big pockets may
bring up.
Otherwise, I don't see the point of all this big structure.
For instance, we have an "Internet Architecture Board", which I guess
have a say on things that affect architecture?
Thanks,
--
Fernando Gont
e-mail: ferna..
ated at will *within the same organization that
published the specs*.
As noted by Jinmei here
<https://mailarchive.ietf.org/arch/msg/spring/XZ_D_cfPNNzXpi4_ZbuTidMTo4k/>
, I believe not only are we just rubber-stamping stuff, but also I
believe that our processes are being circumvented.
they
actually sent.
EH removal breaks that.
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman
are en-route to their intended destination, etc.
Thanks,
Fernando
On 27/2/20 20:21, Joe Touch wrote:
EH isn't a HBH option or extension.
Joe
On 2020-02-27 15:06, Fernando Gont wrote:
On 27/2/20 19:52, Joe Touch wrote:
FWIW - there are separable issues here:
- whether an IP header
r procedural aspects will be
appreciated.
Thanks!
Cheers,
Fernando
Forwarded Message
Subject: Errata #5933 for RFC8200
Date: Thu, 27 Feb 2020 17:07:36 -0300
From: Fernando Gont
To: Suresh Krishnan
CC: 6...@ietf.org <6...@ietf.org>
Suresh,
Two months ago I filled an errata on RFC8200
instance I proposed a direction to
try for an engineering compromise in draft-herbert-6man-eh-attrib-00,
but saw little discussion on that.
Tom
On Thu, Feb 27, 2020 at 1:43 PM Fernando Gont wrote:
Folks,
If you haven't been following recent developments in the Spring WG, you
may be surprised
1M
customers) DNS resolver in Germany in July. More than 2/3 of all DNS
traffic from that resolver to the Internet was over IPv6, less than 1/3
over IPv4.
At least for DNS, IPv6 is doing pretty good.
Modulo fragmentation? ;-)
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar ||
-considerations)
Date: Fri, 12 Feb 2021 18:50:48 -0300
From: Fernando Gont
To: IPv6 Operations
Folks,
In the aforementioned document
(https://tools.ietf.org/html/draft-gont-v6ops-ipv6-addressing-considerations),
we have tried to do at least three things:
1) Look at what we have and try to discuss
60 matches
Mail list logo
