regular case, it's only of use for
MLD-snooping switches.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar
PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01
This revised patch adresses a minor issue pointed out by Florian (avoid
floating-point math). At this point this is unnecessary, since the
IPv6 temporary address lifetimes are not configurable.
P.S.: Patch also available at:
https://www.gont.com.ar/files/fgont-patch-rfc8981-v0.3.diff
Thanks,
Fern
Folks,
Attached you'll find a patch for slaacd(8) that implements RFC 8981 (a
revision of RFC 4941, IPv6 Temporary Address Extensions), just published.
slacd(8) had most of it already. The remaining bit was to have each
temporary address employ a randomized Preferred Lifetime.
I've also found
.
Thoughts from people who are actually running this?
Oh, and we need to update the manpage.
p.s.: And I see that tab vs. space is still messed up in the defines
even after I tried to fix it :/ Maybe I should just let that part go
I can try clean that up and update the manpage if that help
DNS_LIFETIME 600 * 1.5
-
+#defineDFLT_VLTIME_MULT48
+#defineDEFAULT_PIO_PLTIME 1800
+#defineDEFAULT_PIO_VLTIME 1800 * DFLT_VLTIME_MULT
#define IMSG_DATA_SIZE(imsg) ((imsg).hdr.len - IMSG_HEADER_SIZE)
enum {
cut here
dy accepted the problem statement I-D:
https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-01
The problem can even happen accidentally if you e.g. configure rad(8),
realize that made a typo, kill the daemon, change the config, and
restart the daemon. -- the old prefix would live there for a lng t
/* 2 days */ > +#define
ND6_PRIV_PREFERRED_LIFETIME 86400 /* 1 day */
Maybe these should be in engine.h as opposed to engine.c? -- although I
see there are other #define's in engine.c
Thanks!
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F
ine ND6_PRIV_PREFERRED_LIFETIME86400 /* 1 day */
#ifdef _KERNEL
cut here
P.S.: Patch also available at:
https://www.gont.com.ar/code/patch-fgont-tempaddr-vltime.txt
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D
sg).hdr.len - IMSG_HEADER_SIZE)
+#define DFLT_VLTIME_MULT 48
+
static const char * const log_procnames[] = {
"main",
"engine",
cut here
Also available at:
https://www.gont.com.ar/code/patch-fgont-slaacd-max-lifetimes.txt
Thanks,
--
Fernando Go
efineMIN_RTR_ADV_INTERVAL200
#defineMAX_SEARCH 1025 /* same as MAXDNAME in arpa/nameser.h */
#defineDEFAULT_RDNS_LIFETIME 600 * 1.5
-
+#defineDEFAULT_PIO_PLTIME 1800
+#defineDEFAULT_PIO_VLTIME 1800 * 48
#define IMSG_DATA_SIZE(imsg) ((imsg).hdr.len - IMSG_HEADER_SIZE)
enum {
cut here
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Hello, Florian,
Apologies for the delay in my response. I was mostly off-line for the
last ten days or so. Inn-line
On 10/1/20 03:56, Florian Obser wrote:
Hi Fernando,
On Thu, Jan 09, 2020 at 08:49:15AM -0300, Fernando Gont wrote:
Hi, Pamela,
[]
Just happened to see this (sorry
dresses being
removed. Otherwise, you might break e.g. existing TCP connections upon
transient network problems.
Since we are at it: heads-up:
https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4941bis-05.txt
Thanks!
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6network
that contain a Destination Options Header")
* Filtering packets base on the EH size
* Filtering packets based on the number of EHs they contain (e.g., drop
the packet if it employs more than 5 EHs)
etc.
Thoughts?
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...
6 sysctls not documented...
>>
>> which ipv6 sysctls are you referring to ?
>>
>
> net.inet6.ip6.neighborgcthresh
> net.inet6.ip6.maxifprefixes
> net.inet6.ip6.maxifdefrouters
> net.inet6.ip6.maxdynroutes
> net.inet6.ip6.dad_pending
> net.inet6.ip6.mtudisctimeout
>
> any ip6 bods reading, feel free to help with a sentence or two.
Do you still need help with this?
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
It net.inet6.ip6.maxifdefrouters Ta integer Ta yes
> .It net.inet6.ip6.mforwarding Ta integer Ta yes
> .It net.inet6.ip6.multipath Ta integer Ta yes
> .It net.inet6.ip6.multicast_mtudisc Ta integer Ta yes
> +.It net.inet6.ip6.neighborgcthresh Ta integer Ta yes
> .It net.inet6.icmp6.rediraccept Ta integer Ta yes
> .It net.inet6.icmp6.redirtimeout Ta integer Ta yes
> .It net.inet6.icmp6.nd6_prune Ta integer Ta yes
>
>
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
) Internet-Draft before it is adopted as a working group item.
If you have a few minutes, please take a look, and post your
comments/review to (and make sure to CC me). This will
be of much help, and having feedback from the implementers' community
would be really valuable.
Thanks!
Best regards,
Folks,
What would be the appropriate command to show the IPv6 multicast groups
joined by all/each interface?
(FWIW, I'm looking for something similar to FreeBSD's "ifmcstat(8)" or
Linux's "ip -6 maddr show").
Thanks in advance!
--
Fernando Gont
our local
system.
The toolkit runs on (at least) the latest versions of Linux, FreeBSD,
NetBSD, OpenBSD, and Mac OS X.
Please send any bug reports and/or feature requests to
. And you can stay tunned for updates on our
Twitter: @SI6Networks.
Thanks!
Best regards,
- --
Fernan
e
> suggestion to disable all IPv6 traffic if we have an IPv4-only tunnel.
> iked(8) could use a pf anchor to load a block rule, disable
> net.inet6.ip6.forwarding, or we could add a knob net.inet6.enable=0
> that doesn't alter the configured routes and addresses and simply
>
On 11/23/2012 08:44 AM, Henning Brauer wrote:
> * Fernando Gont [2012-11-23 12:09]:
>> FYI. This is might affect OpenBSD users employing e.g. OpenVPN:
>> <http://tools.ietf.org/html/draft-gont-opsec-vpn-leakages>.
>
> we're way less affected than other OSes, sinc
h that e.g. all v6 traffic is filtered (yes, this is
certainly not the most desirable fix, but still probably better than
having your supposedly-secured traffic being sent in the clear).
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322
omeone can help a bit, i can dig further :-)
Where does the above code check whether the entire IPv6 header chain is
present in the first fragment?
Cheers,
--
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://tools.ietf.org/id/draft-ietf-6man-oversized-header-chain-01.txt>
* <http://tools.ietf.org/id/draft-ietf-6man-nd-extension-headers-00.txt>
P.S.: These two have already been adopted by the 6man wg, and are close
to publication as RFCs.
Cheers,
--
Fernando
od for Generating Stable Privacy-Enhanced
Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)
Author(s) : Fernando Gont
Filename: draft-ietf-6man-stable-privacy-addresses-01.txt
Pages : 17
Date: 2012-10-07
Abstract:
implementations (such as
predictability of Fragment ID values), etc. It can also be employed to
play with IPv6 address resolution, SLAAC, etc.
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
se for TCCLASS,
> I had fixed the TOS for ipv4 and I had an untested diff for ipv6. The
> thing is
No. The IPv6 traffic class is similar ot the IPv4 *ToS*.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
generation function (as you need to
remember the FL you used for the SYN/ACK, since the FL is supposed to
remain constant during the life of the connection).
Might be able to produce a patch in a couple of weeks, but mentioned it
in the event anyone else finds some cycles before I do.
Thanks,
--
Fernando
On 01/13/2012 12:11 PM, Alexander Bluhm wrote:
> On Fri, Jan 13, 2012 at 11:01:43AM -0300, Fernando Gont wrote:
>> On 01/12/2012 04:04 PM, Alexander Bluhm wrote:
>>> I have reconsidered it and drop the fragments immediately. The
>>> packet to be reassembled wi
r that packet.
If there were more fragment coming, they will be kept in the fragment
reassembly queue until a reassembly timeout.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
fragment fields while there.
> - If the fr_queue is empty, we had overlapping fragments, don't add
> new ones.
Not sure what this means.
P.S.: Will try your patch this weekend.
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Finger
On 01/11/2012 12:16 AM, Alexander Bluhm wrote:
> On Tue, Jan 10, 2012 at 07:51:03PM -0300, Fernando Gont wrote:
>> On 01/10/2012 01:20 PM, Alexander Bluhm wrote:
>>> Implement RFC 5722 and drop all IPv6 fragments that belong to a
>>> packet with overlapping fragme
receive them.
Since there's no legitimate reason of overlapping fragments, get rid of
them asap. And if there were more fragments (for the same packet)
coming, they will be dropped as a result of the reassembly timeout.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
p_inject() packets...
Thoughts?
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
On 01/10/2012 01:20 PM, Alexander Bluhm wrote:
> Implement RFC 5722 and drop all IPv6 fragments that belong to a
> packet with overlapping fragments.
FWIW, you may be interested in this one, too:
http://tools.ietf.org/id/draft-gont-6man-ipv6-atomic-fragments-00.txt
Thanks,
--
Fernando
34 matches
Mail list logo
