.
Then create net routes for both:
* 2607:5300:60:62ac::/64
* 2607:5300:60:62FF::/64
on the same interface. i.e., both networks are on-link, and things will
work.
Thanks,
--
Fernando Gont
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
ess of the network shouldn't depend on prefixes being stable.
More specifically, hosts should be able to do better. That's the goal of
https://tools.ietf.org/html/draft-gont-6man-slaac-renum-08
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint:
On 15/10/20 08:02, Christian Weisgerber wrote:
On 2020-10-14, Fernando Gont wrote:
Set the VL to 30', and the PL to 15'. You could even set the VL to 15',
and the PL to 7.5', if necessary.
How does this influence the lifetime of privacy addresses?
It should affect i
Hello,
On 15/10/20 07:27, Henrik Friedrichsen wrote:
Hey,
On Wed, Oct 14, 2020 at 02:30:04PM -0300, Fernando Gont wrote:
And you may also look at this other one, which has recommendations for CPEs,
which in your case accounts for your DHCPv6-PD and RA daemons:
https://tools.ietf.org/html
and the CPE router crashes and reboots. The
local hosts will not see the "link down" event (since the switch has
been "up"), but if your ISP does dynamic prefixes, your CPE is likely to
get a new prefix without the CPE router even noticing.
Thanks,
--
Fernando Gont
e-mail: fer
t the protocol level.
- ignore the ISP's pseudo-IPv6 setup and get your v6 connectivity via
tunnel to HE, as long as you don't need to reach hosts single-homed
behind Cogent,
Depending on where you are and the availability of POPs, you may get a
horrible RTT (and geo-location).
ke router is rather irrelevant, as
long as it's not in use. So something along the lines of
fe80::0123:4567:890a:bcde will probably work fine).
(and appologies for the timing :-) )
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
one encountered this as well and/or has hints on
how to solve this?
Thank you very much for your time.
Best regards,
Alex
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
hing running.
Your default route is wrong. Namely:
defaultff02::2%vio0 UGS01 - 8
vio0
If your provider says that the default router is on fe80::1, then the
default route should be:
defaultfe80::1%vio0 UGS 0 1 -
at employ IPv6 Extension Headers (such as the IPsec EHs).
See https://tools.ietf.org/html/rfc7872 for details. Note: while for
some reason I didn't include the corresponding measurements in RFC7872,
IPsec EHs *are* also dropped by many ASes.
You may want to tunnel IPsec over, say, UDP, or emplo
age first.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
r to what extent we'll be able to rely on IPv6 for
DNS transport.
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
th6 from the linux box to the openbsd one reports:
> Resume: pmtu 1500 hops 2 back 2
This doesn't really matter. PMTU can be assymetric. So you should use
tracepath6 from OpenBSD ot Linux, since that's the direction in which
traffic is being fragmented.
Thanks,
--
Fernando Gont
e-m
ess so it should work.
... as long as IPv6 addresses are not embedded in the app protocol.
FWIW, I wouldn't go this way. ULAs (fd00::/8) erver a different purpose:
e.g., still be able to communicate within your network if global
connectivity/addressing fails.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
tisers or whomever to track individuals' behaviour. Not
> everyone likes that.
Please see this:
*
<https://www.ietf.org/internet-drafts/draft-ietf-6man-ipv6-address-generation-privacy-08.txt>
* RFC7217
* <https://tools.ietf.org/html/draft-ietf-6man-default-iids-08>
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
nov's netkill attack, which aims at exhausting
memory by tying it to both PCBs and socket send buffers.
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
uot;. They could simply ACK any SYN/ACK they receive, and that's it.
The attack is not new, and they are not proposing any counter-measures.
It doesn't mean does this does not need attention... but they are not
making any new contribution to the issue.
Kind regards,
--
Fernando Gont
not what they try to
do. And even then, brute force attacks against SYN cookies have
already been discussed in the past. (although I agree that it usually
requires hard googling to spot the right documentation)
Kind regards,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fin
a lot of TCP connections with
minimal own resources...
Yes. This is in an unnecessarily-expensive naphta attack.
Kind regards,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
. 6-8, 2002, Marseille, France.
Kind regards,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
on to demultiplex the messages accordingly.
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
21 matches
Mail list logo
