/comment on the 6man wg mailing list
(https://www.ietf.org/mailman/listinfo/ipv6), that´d be fabulous.
But we'll appreciate your feedback off-line, on this list, etc. (that'd
still be great ;-) )
Thanks in advance!
Regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
P
IPv6 Operations WG of the IETF.
Title : Operational Implications of IPv6 Packets with
Extension Headers
Authors : Fernando Gont
Nick Hilliard
Gert Doering
Warren Kumari
Subject: IPv6 addressing: Gaps?
(draft-gont-v6ops-ipv6-addressing-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
,
Fernando
Forwarded Message
Subject: New Version Notification for
draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
Date: Sat, 25 Jul 2020 22:28:50 -0700
From: internet-dra...@ietf.org
To: Fernando Gont , Gert Doering
, Geoff Huston , Warren Kumari
, Nick Hilliard
A new version of
On 2/4/20 03:19, Gert Doering wrote:
Hi,
On Thu, Apr 02, 2020 at 12:09:34AM -0300, Fernando Gont wrote:
On 1/4/20 14:16, Gert Doering wrote:
[...]
Even IETF discontinued recommending DHCPv6-PD for "inside a home network",
because it doesn't work.
Would you mind elaborat
On 1/4/20 14:16, Gert Doering wrote:
Hi,
[...]
Even IETF discontinued recommending DHCPv6-PD for "inside a home network",
because it doesn't work.
Would you mind elaborating on this one?
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint:
,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
On 31/3/20 16:03, Gert Doering wrote:
Hi,
On Tue, Mar 31, 2020 at 03:10:50PM -0300, Fernando Gont wrote:
So, managed networks tend to like DHCPv6 (DNS!), and wonder how they
should cope with Android.
Probably they don't.
I'm working with one enterprise right now, and one of the
't.
FWIW, it's quite interesting to see the same folks ditching DHCPv6 to
then complain if SLAAC-based hosts use more addresses than they would like.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
ut
every attempt has been shot down.
Yes. That has been very unfortunate.
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
and will *never* be used.
Fixing the ambiguity about what hosts should do about this has often been
discussed in the IETF but there's never really been evidence that it's worth
doing.
FWIW, me, even if it was just for the sake "clarity", that would be
worth doing.
On 26/10/19 11:06, Bjørn Mork wrote:
> Fernando Gont writes:
>
>> They can't do stable addresses, and they are facing this problem.
>
> This is a constructed problem. The solution is to remove the
> construction.
>
> I realize that the "can't do st
nd they are facing this problem.
Not sure how many more 100's of messages are needed before we get to do
something about it...
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
rate the ULA prefix once and store it in stable storage; that should be a
> feature of your CE. Then you never change the ULA prefix.
"MAY be a feature..." ;-) many (most?) will not even know about ULAs. :-(
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6network
reason.
As noted in the draft, the renumbered home network is one of many
possible scenarios where the renumbering event occurs. While we can
certainly recommend stable prefixes, I do think that the network should
be robust in the presence of such events.
Thoughts?
Thanks!
Cheers
Date: Wed, 23 Oct 2019 03:51:32 -0500
From: Fernando Gont
To: IPv6 Operations
Folks,
Earlier this year there was a lot of discussion about slaac renumbering
problems. Our original I-D covered everything from the problem statement
to proposed protocol updates and operational workarounds.
Base
Operations
CC: Fernando Gont , Jan Zorz ,
Richard Patterson
As usual, Ron and I are looking for supportive public commentary if
people want it on the IETF 105 agenda, and if people would like to see
it adopted as a working group draft.
> On Jul 6, 2019, at 9:03 AM, Fernando Gont wrote:
>
eventually be revised.
P.S.: We also published "IPv6 Security Frequently Asked Questions (FAQ)"
at: https://www.internetsociety.org/deploy360/ipv6/security/faq/
Thanks!
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945
e.g. the CPE crashes and reboots,
nodes on the local network continue using outdated prefixes which
result in connectivity problems. This document analyzes this problem
scenario, and proposes workarounds.
Any comments will be welcome.
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e
On Mon, Dec 11, 2017 at 6:18 PM, Pete Mundy wrote:
>
> I'm not so worried about secure IoT devices. The insecure ones will get
> hacked, and the secure ones will do their job.
>
> I just want direct uninhibited and unmodified end to end connectivity
> across the IPv6 internet.
>
That train has
e firewall.
>
> Isn't it better to forego the boarder firewall completely and make
> implementing that service the responsibility of each host for itself?
>
> Pete
>
>
> > On 12/12/2017, at 10:00 AM, Fernando Gont wrote:
> >
> > The crap doesn't get fixed
have to deal with the many problems that so called
> stateful firewalls bring along with them. Now that IPv6 is set to do away
> with (P/N)AT, we’re halfway there.
>
>
> --
> *From:* fernando.gont.netbook@gmail.com gmail.com> on behalf of Fernando
of the terms set out at www.rogers.com/web/content/emailnotice
>
>
>
> Ce message est confidentiel. Notre transmission et réception de courriels
> se fait strictement suivant les modalités énoncées dans l’avis publié à
> www.rogers.com/aviscourriel
>
> --
>
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
On 12/11/2017 08:54 AM, Tom Hill wrote:
> On 11/12/17 05:21, Fernando Gont wrote:
>> one would want to be able to whitelist all ports
>> for a given IP address
>
> What? No!
>
> "Dear Gateway, I am definitely not a compromised host, please open all
> ports tow
, local port, remote ip, remote port),
which kind of sucks -- one would want to be able to whitelist all ports
for a given IP address, or at least (local ip, local port)
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4
On 03/15/2017 05:27 AM, Bjørn Mork wrote:
> Fernando Gont writes:
>
>> * "IPv6 Address Usage Recommendations" <https://goo.gl/UJYdyY>
>> * "Recommendation on Temporary IPv6 Interface Identifiers"
>> <https://goo.gl/541H8V>
>
> Follo
Folks,
FYI:
* "IPv6 Address Usage Recommendations" <https://goo.gl/UJYdyY>
* "Recommendation on Temporary IPv6 Interface Identifiers"
<https://goo.gl/541H8V>
Comments welcome!
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprin
Hopefully all this SeND machinery is not being pushed in as a
heavyweight RFC7217. You don't need all the certs-related stuff for
getting a non-predictable stable-per-network IID.
Thanks!
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
ave a Mac
> anyway, thus what info am I losing there?
>
>> The problem is *not* that this IID is changing. It is a stable one. And
>> yes, I vote not against temporary addresses.
>
> Actually, it is not a stable address as some have found out (read:
> anecdotal), they also change at re-install and there are a couple of
> other possibilities from what I recall.
One might argue that a reinstall results in a conceptualy different
system. The fact that the underlying hardware is tha same is anecdotical.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
eND, does it?
Can anyone verify that:
1) As you disconnect and subsequently reconnect to the same network, the
address is formed with the same IID?
2) When multiple prefixes ad advertised on the same network, each
resulting address (for each different prefix) employs a different IID?
3) If multiple interfaces (NICs) are connected to the same subnet, each
obtains a different address, plus "1)" and "2)" above are true?
Thanks!
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
h to turn if off would be amazing.
>> The above trick kinda does that though and it mostly seem to work.
> My info is, to set
> sysctl -w net.inet6.send.opstate=0
> to go back to mac address based eui64, but didn't checked it.
Please don't resort to eui64. That's a bad idea. See RFC7721 and RFC707
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
ge within the same network
-- for instance, RFC7217 was/is known in 6man circles as "stable-privacy
addresses").
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
distribution.
The RFC Editor Team
Association Management Solutions, LLC
___
v6ops mailing list
v6...@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5
:
and CC
.
P.S.: You can find a number of pointers to articles and other related
work on this topic here:
<http://blog.si6networks.com/2015/12/the-controversial-ipv6-extension-headers.html>
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP
hat without at
least some "roadmap"/brief discussion, folks might need to dig deep into
many documents in order to grasp "what this is ll about".
FWIW, 8just me thinking out loud), I guess that one of the possible
outcomes could be to have (some reduced version of) Section 3 be a
subsection of Section 4?
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
re anything missing?
Or, if you like the document and agree with its content, that's also
interesting feedback to have.
P.S.: If possible, please CC and
when sending
feedback.
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 780
FYI -- could be of Interest for folks currently in Prague for the IETF
meeting...
Forwarded Message
Subject: IPv6 hackers #2 (Prague 2015) tomorrow! (July 21, 4 PM @ CZ.NIC)
Date: Mon, 20 Jul 2015 18:24:04 -0300
From: Fernando Gont
To: IPv6 Hackers Mailing List
Folks
or avoiding the use of IPv6 EHs where possible.
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Folks,
FYI:
<http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt>.
Comments welcome.
Thanks!
Fernando
Forwarded Message
Subject: New I-D: IPv6 Extension Headers in the Real World
Date: Fri, 08 Aug 2014 00:04:37 -0400
From: Fernando Go
;s top-1m sites... that's a
bit more than "selected content providers"
> advice with regards to HBH headers. assuming there isn't any feature
> enabled that uses HBH. on a platform that supports forwarding of
> packets with HBH without punting, forward. fo
current state of affairs on the public IPv6 Internet:
<http://www.iepg.org/2014-07-20-ietf90/iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0.pdf>
Thanks!
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
On 07/01/2014 01:58 PM, Dan Lüdtke wrote:
>
> I have no access to a IPv6 enabled system for testing, so I am asking
> instead of trying. Sorry!
>
> On 01.07.2014 17:52, Fernando Gont wrote:
>> 3) Looks-up M in PATH. The dropping node is M+1.
>
> Would the tool be
s I was expecting to be
dropping the packets.
Obviously, I don't care about this specific case... but probably is one
on which we might have more insights than others.
Thoughts?
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484
l free to
discuss this document on this list (ipv6-ops) while CC'ing
.
P.S.: Regardless of what we end up doing with this I-D, etc., I think
the brainstorming would be fruitful. :-)
Thanks!
Best regards,
Fernando
Original Message
From: internet-dra...@ietf.org
To
any intent/mechanism for them to
be as "stable" as possible? Or is it usual for hosts to get a new
address for each lease?
P.S.: I understand this is likely to vary from one implementation to
another... so please describe which implementation/version you're
referring to.
Thanks!
Best reg
es represent address waste?
>>
>> "Unused address space". In the same way that the Earth's surface is not
>> currently accommodating as many many as it could. But that doesn't meant
>> that it should, or that you'd like it to.
>
> Hmm, intrigu
it, will not another attacker
> understand it too, and attack it?
Play both sides. And attack yourself. scan6
(http://www.si6networks.com/tools/ipv6toolkit) exploit current
addressing techniques. draft-ietf-6man-stable-privacy-addresses is meant
to defeat it.
Maybe one problem is t
ponses are legitimate or not (TCP timestamps, IP IDs,
etc. are usually your friends here).
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
e.
And it's not just limits. e.g., how many *security* tools need superuser
privileges, but will never give up such superuser privileges once they
are not needed anymore?
"Know thyself" (http://en.wikipedia.org/wiki/Know_thyself). I know my
code is not going to be as good as it sh
ths are
selected based on the value of a number of variables.
Configuration file is dynamically generated, with the right path
to the oui.txt file.
= CHANGELOG =
- --
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25
ths are
selected based on the value of a number of variables.
Configuration file is dynamically generated, with the right path
to the oui.txt file.
= CHANGELOG =
- --
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25
h link? I doubt so.
Scan Google's IPv6 address space, and you'll find one. (scan6 of
<http://www.si6networks.com/tools/ipv6toolkit> is your friend :-) )
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
rate is lower than the rate at
which you "produce" them, it's still a problem.
Too bad -- we do have plenty of experience with this.. e.g., managing
the IP reassembly queue.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
"Why would you need that?"
>>
>> /64 netmask opens up nd cache exhaustion as a DoS vector.
>
> ND cache size Should be limited by HW/SW vendors - limiting number
> entries ND cache entries per MAC adresss, limiting number of outstanding
> ND requests etc.
+1
Don
s.com/tools/ipv6toolkit>. On the same page, you'll
also find a PDF that discusses ND attacks, and that tells you how to
reproduce the attack with the toolkit.
Besides, each manual page of the toolkit (ra6(1), na6(1), etc.) has an
EXAMPLES section that provides popular ways to r
ile doing DAD, such NS will cause DAD to
fail, and the tentative address should not be used. -- This scenario
would happen if both devices are trying t configure the same (tentative)
address at roughly the same time, and hence their respective DAD probes
"cross" on the network.
T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
FYI
- Original Message
Date: Sat, 13 Jul 2013 20:30:54 +0200
From: Fernando Gont
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623
Thunderbird/17.0.7
MIME-Version: 1.0
To: IPv6 Hackers Mailing List
Subject
value based upon learnt
>> values on the wire?
>
> Yup, this was the case. I watched it continuously, and when an RA came
> in, it overwrote the manually configured MTU.
> Next question: how do I prevent that from happening?
Is there any reason for which the router is including an MTU
ould attend, whether they would have stuff to
present, etc. So I've set up a very short on-line survey to help us
plan for the meeting.
If you're interested, please take 5 minutes to complete the survey at:
<https://www.surveymonkey.com/s/FFL386K>
Thanks!
Best regards,
- --
Fernando
sed? That the interface must be
put nto promiscuous mode? Something else?
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
used one of the various open-source or commercial offerings (e.g
> NAV, Slaacer, and the like).
At the risk of sounding our own horn:
<http://www.si6networks.com/tools/ipv6mon> (runs on *BSD and Linux, and
is GPL'ed).
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si
On 03/31/2013 07:56 PM, Daniel Roesen wrote:
> On Sun, Mar 31, 2013 at 02:57:20AM -0300, Fernando Gont wrote:
>>> Totally random crazy idea: could there be firewalls on some of these
>>> machines that are causing multicast RAs to be filtered but unicast RAs
>>> are fi
MLD snoping and hence do not forward multicasted packets?
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
63 matches
Mail list logo
