Folks,
Any thoughts?
On 2/4/20 22:55, Fernando Gont wrote:
Folks/Hiroki,
I've implemented the upcoming revision of RFC4941
(https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis-08) for FreeBSD.
The main changes are this:
* Reduce the Valid Lifetime from 1 week to 2 days.
utes.
But yes: use normal IPv6 send mechanisms. And also probably motivate
that nodes use the address of the sending interface (strong-end system
model, per RFC1122).
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945
cribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
freebsd-net@freebsd.org mailing list
ID.
@@ -2289,7 +2330,6 @@ in6_tmpifadd(const struct in6_ifaddr *ia0, int
forcegen, int delay)
* there may be a time lag between generation of the ID and generation
* of the address. So, we'll do one more sanity check.
*/
lt6_tmp.ia6t_vltime = new->ndpr_vltime;
lt6_tmp.ia6t_pltime = new->ndpr_pltime;
in6_init_address_ltimes(pr, <6_tmp);
cut here
Thanks!
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprin
d be specified for interface em0."
since the config for em0 does specify rtltime -- unless I'm missing
something.
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
___
-vltime.txt
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To
html/draft-gont-v6ops-slaac-renum-02
Question:
Would you guys be interested in an implementation of the proposed
mitigations?
P.S.: If you have any thoughts or comments on the proposed mitigations,
that would be appreciated, too.
Thanks!
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.co
...@ietf.org
To: Fernando Gont , Suresh Krishnan
, Richard Draves ,
Thomas Narten
A new version of I-D, draft-ietf-6man-rfc4941bis-03.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.
Name: draft-ietf-6man-rfc4941bis
Revision: 03
Title: Pri
tf.org/html/draft-gont-6man-slaac-renum ?
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
___
freebsd-net@freebsd.org mailing list
https://lists.fre
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...
ned with sizeof(long) and 2)
> IFACE_LENGTH should be IFNAMSIZ.
Thanks so much! -- I'll incorporate these into the ipv6toolkit (that's
the reason for which I was playing with this in the first place).
Thanks again!
Best regards,
--
Fernando Gont
e-mail: ferna...@g
Hi, Hiroki,
On 08/07/2014 06:24 AM, Hiroki Sato wrote:
>
> Fernando Gont wrote
> in <53e2b586.3080...@gont.com.ar>:
>
> fe> However, whenever I lookup an entry for fc00:1::1 with routing sockets,
> fe> the only entry I obtain is fc00:1::/64 (a network route) r
ia routing sockets. And that I shouldn't be implementing this
"is the dst address my own address?" hack.
Any thoughts?
P.S.: I can provide a code snippet if that'd be of any help.
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fi
link-local by default). But I understand YMMV.
While node information message can be interesting at times, since they
are only supported in BSDs and can only be used when on-link, it's not a
debugging mechanism you can rely on. As a result of that, my 2cents
would be "disable them by default
ecial distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
The RFC Editor Team
Association Management Solutions, LLC
--
Fernando
Management Solutions, LLC
IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
----
--
Fernando Gont
e-m
nnection entering FIN_WAIT_1 at the same time and
> sending FIN/ACKs repeatedly (though our connections are a bizarre case
> of this where both ends of the connection are actually the same
> connection).
Last time I checked, FreeBSD was handlind this case properly... so this
is probably th
On 06/16/2013 01:51 AM, Bruce A. Mah wrote:
> If memory serves me right, Fernando Gont wrote:
>
>> What would be the appropriate command to show the IPv6 multicast
>> groups joined by all/each interface?
>
> Try ifmcstat(8).
That's exactly what I wanted.
Thanks
Folks,
What would be the appropriate command to show the IPv6 multicast groups
joined by all/each interface?
Thanks in advance!
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
@SI6Networks.
Thanks!
Best regards,
- --
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJRI38CAAoJEJbuqe/Qdv/xvB4IANcso
ed, it seems those bytes are being rewritten).
Is this a known issue with gogoc? Am I missing something else?
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 9
Folks,
FYI:
* <http://tools.ietf.org/id/draft-ietf-6man-oversized-header-chain-02.txt>
* <http://tools.ietf.org/id/draft-ietf-6man-nd-extension-headers-01.txt>
P.S.: These two I-Ds have already been adopted by the 6man wg, and are
close to publication as RFCs.
Cheers,
--
Fernando
Please take a look at the discussion on how to "steal" incomming
connections in Section 3.1 of RFC 6056.
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
__
r for road warriors sends a IPv6 prefix to be used on
> OpenVPN as well as a IPv4 address. It works well.
The questions is: what happens when under attack? (please see above)
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7
e they have some patches for some of
these issues...
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
freebsd-net@freebsd.org mailing list
http://l
ommend that range. In RFC 6056 we recommend
implementations to use the largest possible port range -- ideally
1024-65536.
> Is there any particular reason
> why net.inet.ip.portrange.first defaults to 1?
Please see above.
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg
anced
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:
This document specifies a method for gener
since it contains a number of fixes.
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
___
freebsd-net@freebsd.org mailing list
http://lists.fr
be employed to
play with IPv6 address resolution, SLAAC, etc.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
freebsd-net@freebsd.org mailing list
enerates a lot of traffic.
> The retransmits are roughly ~300-500 byte packets.
Can you post a packet trace (tcpdump's packet decode output), or send me
the trace or pcap files to me off-list, so that I can take a look and
comment?
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@
behavior
>> intentional? (If so, what's the rationale?)
>
> It's kern/152791, isn't it?
Yep, it seems it is. -- The fix would be that when an ICMPv6 Redirect is
received with RD Target == RD Destination, not only is an entry created
in the Neighbor Cache, but a host-route
Redirect Destination.
Should I report this as a bug, or is this (non-rfc-compliant) behavior
intentional? (If so, what's the rationale?)
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076
is there any reason not to make it 4?
Not at all. Algorithm 4 (double-hash) is the best option, IMO.
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_
ed than I to comment on the style of the
> patch, but it applies cleanly, and seems to run fine on both v4 and v6.
Has this been commited to the tree, already? -- If so, what's the
default algorithm?
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP
stablished at a high rate).
As a datapoint, Linux ships with Algorithm #4 enabled by default.
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Hi, Paul,
> I was wondering if someon knew if FreeBSD supports the creation of
> anycast addresses and groups.
Anycast is a routing artifact. There's nothing (syntactically) special
about anycast when compared to unicast addresses.
Thanks!
Kind regards,
--
Fernando Gont
e-
iginal SYN was accepted, the connection is established. The second
> * SYN is inflight, and if it arrives with an ISN that falls within the
> * receive window, the connection is killed.
What do you mean by "recreated", specifically?
Thanks!
Kind regards,
--
Fernando Gont
e-mail:
ised to see that thread posted here ...
>
> -- Qing
>
>
>> -Original Message-
>> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
>> n...@freebsd.org] On Behalf Of Fernando Gont
>> Sent: Thursday, March 04, 2010 7:08 PM
>> To: freebsd-net@freebsd.o
, if you prefer.
Thanks!
Kind regards,
- --
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
iQEcBAEBCAAGBQJLkHWNAAoJEJbuqe/Qdv/x8RkH/2BMUvD
uot;be liberal in
> what you accept", but, as you probably know, it shouldn't cause any
> interoperability trouble in practice.
Agreed.
Thanks again!
Kind regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96E
local,
> or is this a manually configured link-local situation ?
I'm just playing with a RouterAdvertisement forging tool I just built.
I've checked the on-the-wire packets, and they seem to be correct. :-(
Thanks,
--
Fernando Gont
e-mail: fe
ts of the IPv6 Source address must be fe80:, or else the
message is dropped (at least, no changes are made to the destination
cache or the neighbor cache).
Can anybody confirm this one, or correct me if I am wrong?
Thanks!
Kind regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@ac
eb-09-security-assessment-TCP.aspx
Additionally, I have posted a copy of the document on my personal web
site: http://www.gont.com.ar
Any comments will be more than welcome.
Kind regards,
- --
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9
sh time would be nice to remove if you're investigating the
related issues.
Ok.
One thing you may or may not have noticed is that FreeBSD keeps
TIME_WAIT sockets in a seperate zone which has a limit size, so you
will not have to worry too much about them clogging up all ephemeral
fixed this in the patch itself, but then undid that change
when I changed the first ephemeral port from 1024 to 1.
This one should be fine. :-)
Kind regards,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
utgoing connections
to about (ephemeral_ports/TIME_WAIT). Any objections against changing
this? At least for outgoing connections (i.e., non-listening
sockets), this shouldn't be the case. I'd be interested in working on
this issue...
Kind regards,
--
Fernand
ng that I can't apply it. I think all the whitespace got
stomped, either by your mail program or my mail program. Can you
please resent this as an attachment?
Sure. Please let me know if this one is okay.
Kind regards,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fi
eral ports.
So unless you're tweaking the configuration of each of the systems
you have behind the NAT, I'm afraid you won't be able to implement
such a policy. FWIW, Windows used the range 1024-4999 or something...
at least W95 and XP. Vista probably still does the same thing.
Kin
if (*lastport < first || *lastport > last)
+ *lastport = first;
+ lport = htons(*lastport);
+ } while (in_pcblookup_local(pcbinfo, laddr, lport,
+ wild));
}
if (prison_ip(cred, 0, &laddr.s_addr))
retur
ection
algorithm described in the draft (this is, IMHO, the right approach
to ephemeral port randomization)
Kind regards,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_
addr.s_addr))
return (EINVAL);
Kind regards,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
freebsd-net@freebsd.org mailing list
http://lists.f
*lastport = first;
+ lport = htons(*lastport);
+ } while (in_pcblookup_local(pcbinfo, laddr, lport,
+ wild));
}
if (prison_ip(cred, 0, &laddr.s_addr))
return (EINVAL);
--
Fernando Gont
e
roposed changes (extending the port
range and possibly implementing the RFC1948-like scheme for ephemeral
port selection).
Any comments will be more than welcome.
Thanks,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE
CCR) in which they
show errors that, IIRC, were not caught by the CRC, but *were* caught
by the checksum.
Kindest regards,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
__
ction-establishment timer should be set to a
larger value, or else fewer retransmissions and fewer ICMP errors should be
required to abort a connection.
If you have a copy of Stevens' TCPv2 at hand, there's a diagram on page 828
that shows this. The 75-second timer w
educed to such a value that, in that case, this code would
kick in before the 75-seconds tconnection-establishment timer?
Thanks!
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
used to stop emitting
>packets by filling their SYN queue; I'm not sure when that stopped applying.
Well, that's the point of my question: is there any reason for the stacks
to behave like that?
Kind regards,
Fernando Gont
e-mail: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
for a new connection.
But, why doesn't it reply a SYN/ACK with a RST, if it DOES KNOW that
that segment doesn't correspond to any current connection?
Kind regards,
Fernando Gont
e-mail: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
59 matches
Mail list logo