Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
Hi, On Tue, Mar 31, 2020 at 02:30:46AM +0200, Roger Wiklund wrote: > Hi > > I played around with IPv6 on my Mac today (Mac OS Catalina) and I noticed > that besides the IP from DHCPv6 (dynamic) it's also generating two other > addresses. > > When I read DHCPv6 vs SLAAC it often boils down to "control" but I don't > see the need to allocate a dynamic address if the autogenerated are used. > For client's you dont really have any inbound connections unless it's a > support case. > > What's your view on this? > > Thanks! I for one think that, very broadly speaking, DHCPv6 should & can be avoided in many environments. See also 'Does One Need DHCP(v6)?' https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/ cheers Enno -- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator
Re: IPv6 ingress filtering
Hi, On Fri, May 17, 2019 at 01:45:56PM -0700, Kurt Buff - GSEC, GCIH wrote: > Forgive the intrusion, as I seek a bit of clarity. > > MSFT DirectAccess seems to use the address range in question: > > Tunnel adapter iphttpsinterface: > >Connection-specific DNS Suffix . : >IPv6 Address. . . . . . . . . . . : 2002:4332:::::: >Temporary IPv6 Address. . . . . . : 2002:4332:::::: >Temporary IPv6 Address. . . . . . : 2002:4332:::::: >Link-local IPv6 Address . . . . . : fe80::75e4:c4b3:fae6:237c%2 >Default Gateway . . . . . . . . . : > > It seems to me that filtering this range might hurt a bit, unless I'm > mistaking what some are proposing. not being an MS DirectAccess expert I'd say that - given DA is a VPN technology, using IP-HTTPS as a (somewhat proprietary) tunnel tech - these addresses shouldn't be visible too much "in the [public] IPv6 Internet" so the proposed filtering (of this thread) shouldn't come into play. cheers Enno > > Kurt > > On Fri, May 17, 2019 at 1:06 PM Brian E Carpenter > wrote: > > > > On 18-May-19 06:12, Gert Doering wrote: > > > Hi, > > > > > > On Fri, May 17, 2019 at 12:55:33PM -0500, David Farmer wrote: > > >> A few questions; > > >> > > >> Are you generating ICMPv6 toward non-2002::/16 sources for traffic > > >> destined > > >> to 2002::/16? > > >> Are you generating ICMPv6 toward 2002::/16 source for traffic destined to > > >> non-2002::/16? > > >> For the later, where are you getting the route for 2002::/16 from? > > > > > > Indeed, as you said, filtering correctly (= ICMP unreachable, so clients > > > can fail over quickly [if HE is not in use]) is hard. > > > > > > We still run our own relay, so do not filter today. Mostly because I > > > know it works and (since it's our relay) I can rely on it to not break > > > things for people - and haven't had time to change that to "filter". > > > > And surely the question is "What would produce the most help desk calls?". > > Filtering something that is presumably working for its remaining users > > might not be a good idea from that point of view. > > > > Brian -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Florian Grunow, Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ===
Re: A=1 L=0 PIO
Hi, On Tue, Aug 16, 2016 at 11:49:33AM +0200, Mikael Abrahamsson wrote: > On Tue, 16 Aug 2016, Sander Steffann wrote: > > > Hi Mikael, > > > >> I'm trying to figure out what a "normal" currently deployed in the field > >> IPv6 host would do if it receives an RA with PIO /64 where L=0 and A=1. > > > > On an implementation level what I have seen on Linux is that the L flag > > determines whether the route 2001:db8::/64 -> eth0 is installed or not. > > Ok, thanks everybody. So it'll still do A=1 style addressing (EUI64, > privacy extension addressing etc)? Will it perform DAD? from my memory: yes to all of those, for common desktop OS (Win, Linux, Max OS-X). When we did the lab testing for this one (https://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DHCPv6_Conflicting_Parameters.pdf) we played a bit with the L-flag as well, so the L=0 + A=1 scenario occurred. I don't remember any case where the things you mention did not happen. We still have that lab infrastructure so we can repeat (some of) the tests with L=1 (and without DHCPv6). Let me know if you (or the group) is interested; we can assign a student to the task. (I'm on family holiday myself until end of Aug). best Enno > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ===
Re: Win 2012 R2 and NTP over IPv6
Hi, did you play with the "w32tm" command? It has a debug option and you can manually resync etc. HTH, Enno On Wed, Jul 29, 2015 at 10:33:36AM +0200, Gert Doering wrote: > Hi, > > one of my colleagues just brought up a windows / ipv6 issue that I cannot > answer (and google just returns "disable ipv6!" as the top#1 link...) - > specifically, his server 2012 r2 is unable to sync to an IPv6-enabled > NTP server. > > I can see queries and responses: > > 10:26:22.401681 IP6 2001:608:x:xx::zz.123 > 2001:608:0:c::123.123: NTPv3, > Client, length 48 > 10:26:22.402150 IP6 2001:608:0:c::123.123 > 2001:608:x:xx::zz.123: NTPv3, > Server, length 48 > > IPv6 connectivity is working fine - when pinging ntp.space.net, the server > will happily acknowledge receipt of the echo replies. > > Windows firewall is disabled (box is behind ACLs and the ACLs permit NTP), > so it really should be able to synchronize fine - but it doesn't. > > So, before entering lenghty debug sessions, I'm hoping to hear from someone > that this is a known issue, and all you need to do is "X" (or "it is known > to not-work")... > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AGVorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ===
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4)
Hi, On Wed, Sep 17, 2014 at 12:07:23PM +0200, Ignatios Souvatzis wrote: > On Wed, Sep 17, 2014 at 11:59:55AM +0200, Ignatios Souvatzis wrote: > > Hi, > > > > On Wed, Sep 17, 2014 at 10:14:31AM +0200, Mikael Abrahamsson wrote: > > > > > So, one interpretation would be that if the device hasn't subscribed to > > > the > > > "all IPv6 nodes" multicast group, it's not an IPv6 node, and shouldn't > > > receive the traffic. RFC 2710, sect. 5, states that no REPORT or DONE messages are to be sent for link-scope all-nodes (ff:02::1), so one can't potentially "subscribe" to that address in a setting with MLD snooping. > > RFC 4541 "Considerations for Internet Group Management Protocol (IGMP) > and Multicast Listener Discovery (MLD) Snooping Switches" says: > > "3. IPv6 Considerations > [...] > >In IPv6, the data forwarding rules are more straight forward because >MLD is mandated for addresses with scope 2 (link-scope) or greater. >The only exception is the address FF02::1 which is the all hosts >link-scope address for which MLD messages are never sent. Packets >with the all hosts link-scope address should be forwarded on all >ports." > > -is it should be noted that RFC 4541 is an "Informational" one and I don't think any normative value for a kind-of vendor-proprietary thing called "MLD snooping" might be attached to it ;-) best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ===
Re: Something with filters
Eric, guys, On Thu, Aug 28, 2014 at 02:28:53PM +, Eric Vyncke (evyncke) wrote: > The mapped IPv4 address is probably coming out of a 6PE (or 6VPE) MPLS router > where the HopLimit field is copied into the MPLS header and when the poor P > router in charge of sending the ICMPv6 has no IPv6 address at all? This is > per RFC and perhaps an explanation why uRPF is not activated? > > No explanation about the :: address though? > > As a security person, I would love to have uRPF enabled where possible but I > am afraid that even in IPv4 it is not deployed everywhere :-( to be honest, as another security person, I'm not really sure about the benefit of uRPF in the IPv6 world, in some scenarios. imagine a single infected smartphone on LTE, generating connections with potentially 2^64 different source addresses from its assigned /64. How would you counter that with uRPF? not to speak about a home device sitting behind a CPE (and mimicing connections from different /64s being part of the /56 the CPE "got")... thoughts? best Enno > > -?ric > > PS: indeed, ask your vendors for features, customers have much more power > than you guess :-) > > From: Lorenzo Colitti mailto:lore...@google.com>> > Date: jeudi 28 ao?t 2014 07:46 > To: Jeroen Massar mailto:jer...@massar.ch>> > Cc: IPv6 Ops list > mailto:ipv6-ops@lists.cluenet.de>> > Subject: Re: Something with filters > > On Wed, Aug 27, 2014 at 9:01 AM, Jeroen Massar > mailto:jer...@massar.ch>> wrote: > 9 2001:5a0:a00::2e (2001:5a0:a00::2e) 79.018 ms 79.910 ms 79.960 ms > 10 :: (::) 101.893 ms 102.004 ms 103.574 ms > 11 rar3.chicago-il.us.xo.net<http://rar3.chicago-il.us.xo.net> > (:::65.106.1.155) 104.732 ms > > Yeah baby, we can use the unspecified address in ICMP replies! > > The mapped IPv4 address in there is pretty cool, too... -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ===
Re: Poll on SMTP over IPv6 Usage
Postfix 2.9.5 on FreeBSD best Enno On Thu, Feb 13, 2014 at 03:23:21PM -0500, James Small wrote: > Interested in what you're using to send/receive SMTP over IPv6: > > A) Using (product) from __ (vendor) > > B) Using (service provider or "cloud solution") > > C) Elected not to implement SMTP over IPv6 at this time because > ___ (reason) > > > > All responses greatly appreciated, > > --Jim > > > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ===
Neighbor Cache Exhaustion, was Re: Question about IPAM tools for v6
Hi Guillaume, willing to share your lab setup / results? We did some testing ourselves in a Cisco-only setting and couldn't cause any problems. [for details see here: http://www.insinuator.net/2013/03/ipv6-neighbor-cache-exhaustion-attacks-risk-assessment-mitigation-strategies-part-1/] After that I asked for other practical experience on the ipv6-hackers mailing list, but got no responses besides some "I heard this is a problem in $SOME_SETTING" and references to Jeff Wheeler's paper (which works on the - wrong - assumption that an "incomplete" entry can stay in the cache for a long time, which is not true for stacks implementing ND in conformance with RFC 4861). So your statement is actually the first first-hand proof of NCE being a real-world problem I ever hear of. thanks in advance for any additional detail. best Enno On Fri, Jan 31, 2014 at 02:59:24PM +0100, Aur??lien wrote: > On Fri, Jan 31, 2014 at 2:07 PM, Ole Troan wrote: > > > >> Consensus around here is that we support DHCPv6 for non-/64 subnets > > >> (particularly in the context of Prefix Delegation), but the immediate > > >> next question is "Why would you need that?" > > > > > > /64 netmask opens up nd cache exhaustion as a DoS vector. > > > > FUD. > > > > > Hi Ole, > > I personnally verified that this type of attack works with at least one > major firewall vendor, provided you know/guess reasonably well the network > behind it. (I'm not implying that this is a widespread attack type). > > I also found this paper: http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf > > I'm looking for other information sources, do you know other papers dealing > with this problem ? Why do you think this is FUD ? > > Thanks, > -- > Aur??lien Guillaume -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ===
Re: Best practice - dual stack DNS?
Hi, On Mon, Oct 21, 2013 at 02:42:02PM +0200, Gert Doering wrote: > Hi, > > On Mon, Oct 21, 2013 at 02:24:27PM +0200, Roger Wiklund wrote: > > So currently I only have IPv4 DNS and what works just fine. What's the best > > practice for dual stack DNS? Should I bother with setting up DHCPv6 relay > > etc? > > Well, how do you handle clients that do not want to use IPv4? So yes, > DHCPv6 and RDNSS is it :-) which both are (still) not supported by Android, to the best of my knowledge. Not sure about the environment of the OP but at least for Android clients his exact setup is probably the way to go [besides manually configuring DNS resolvers in some Android-based phones GUI]. best Enno > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AGVorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey Troopers 2013 Videos online: http://www.youtube.com/user/TROOPERScon?feature=watch === Blog: www.insinuator.net || Conference: www.troopers.de ===
Re: "Your IP address is coming across to us in an invalid format."
was discussed on the RIPE67 mailing list as well. turned out there was some (automated?) follow-up from Cisco's side recommending sth along the lines of "contact your sysadmin and ask her to enable IPv4" ;-) best Enno On Wed, Oct 16, 2013 at 07:01:58PM +, Eric Vyncke (evyncke) wrote: > Forwarded internally, hopefully to be fixed quickly > > > -Original Message- > > From: Bill Owens [mailto:ow...@nysernet.org] > > Sent: mercredi 16 octobre 2013 12:00 > > To: Eric Vyncke (evyncke) > > Cc: 'ipv6-ops@lists.cluenet.de' > > Subject: Re: "Your IP address is coming across to us in an invalid > > format." > > > > On Wed, Oct 16, 2013 at 06:52:04PM +, Eric Vyncke (evyncke) wrote: > > > Can you tell us this faulty URL? > > > > Log in as usual to cisco.com (which appears to work fine), select > > "Account" from the top bar, then "Profile Manager", which is > > https://tools.cisco.com/RPF/profile/profile_management.do and up comes the > > message. There is an error code and an email to contact, which I haven't > > personally done, but one of the engineers here has gone through that > > process and was told that it was because he was using IPv6. He briefly > > disabled v6 on his PC and tried again, and the link worked normally, so > > there's at least circumstantial evidence that v6 is the culprit. . . > > > > Bill. -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey Troopers 2013 Videos online: http://www.youtube.com/user/TROOPERScon?feature=watch === Blog: www.insinuator.net || Conference: www.troopers.de ===
Re: teredo.ipv6.microsoft.com off?
Hi, thanks for that link. big questions is: what means "disabling IPv6" in those contexts? unchecking IPv6 in GUI based interface properties? setting "DisabledComponents" to 0xfff? using some netsh-based approach? from what I hear: "as long as you can successfully ping ::1, IPv6 is considered enabled and MS regards this as a 'supported configuration'". best Enno On Wed, Jul 17, 2013 at 04:45:58PM +0200, Jens Link wrote: > Enno Rey writes: > > Hi, > > > There's quite some debate which approach to use due to operational > > practices and MS telling people "not to 'fully' disable IPv6 as you > > might lose support for $SYSTEM". > > I'm still looking for a source too. Rumors have it that the Windows 7 > roll out here (large enterprise customer) will be with IPv6 disabled. I > guess that why they hired me to do the IPv6 planing (on the network > side). > > Disabling IPv6 will lead to some problems: > > http://support.microsoft.com/kb/2549656 > > (DNS Server service randomly cannot resolve external names and returns a > "Server Failure" error if IPv6 is disabled in Windows Server 2008 and > Windows Server 2008 R2) > > This is an actual problem for a customer where I helped implementing > IPv6 last year. They dont use Windows but they are running a large dual > stacked website. > > Jens > -- > - > | Foelderichstr. 40 | 13595 Berlin, Germany| +49-151-18721264 | > | http://blog.quux.de | jabber: jensl...@guug.de | --- | > - -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 174 3082474 PGP FP 055F B3F3 FE9D 71DD C0D5 444E C611 033E 3296 1CC1 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey Troopers 2013 Videos online: http://www.youtube.com/user/TROOPERScon?feature=watch === Blog: www.insinuator.net || Conference: www.troopers.de ===
Re: teredo.ipv6.microsoft.com off?
Ron, > >>> I am too. I would really like to see 6to4 and teredo be default off > >>> everywhere, and people who want it can manually turn it on. If > >>> teredo went away completely, that would also be a good thing. > >> > >> Strongly concur here as well. One less thing I have to disable on > >> all my systems in enterprise nets. > > > > Windows boxes that are in an Active Domain (which should match your > > 'enterprise net') have Teredo and 6to4 disabled per default. > > Next to that one can enforce that of course through AD policies. > > A number of my enterprise nets support many OSs and are not AD-centric. > That's why I qualified my enterprise nets as "heterogeneous". But yes, if > you are homogeneous on Windows and everything is in AD, you can disable those > things through GPO. For me, we have to tell each of our users to disable > teredo, disable 6to4, disable privacy/temporary addresses, etc., and in many > cases beg them to upgrade to OSs that support DHCPv6. > what if they use Android based systems? is there support for DHCPv6 in the interim? best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 174 3082474 PGP FP 055F B3F3 FE9D 71DD C0D5 444E C611 033E 3296 1CC1 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey Troopers 2013 Videos online: http://www.youtube.com/user/TROOPERScon?feature=watch === Blog: www.insinuator.net || Conference: www.troopers.de ===
Re: teredo.ipv6.microsoft.com off?
Hi,
off the top of my head it's roughly as follows:
a) 6to4
Win7/Server 2008 generation and before: "if IPv4 address = Non-RFC 1918
address, automatically enable 6to4 and try to resolve 6to4.ipv6.microsoft.com
to get 'nearest relay'".
no idea as for Win8/Server 2012.
b) Teredo
Vista: enable by default.
Win7/Server 2008: perform the following decision logic:
1) if $SYSTEM member of AD domain, assume that $SYSTEM is "well managed" => no
need for SOHO tech called Teredo, hence disable it.
2) if $SYSTEM does _not_ have local firewall enabled, assume that $SYSTEM in
poor security state and it might be too risky to use Teredo, hence disable it.
3) if both above conditions _not_ met (read: not member of AD domain, but local
firewall enabled), then put Teredo into 'dormant' state and try to reach
teredo.ipv6.microsoft.com every 30 seconds to check if Teredo usable if needed.
once $APPLICATION asks for that, move from 'dormant' into 'qualified' state and
thereby 'enable' Teredo.
again, no idea as for Win8/Server 2012.
I can't support the above statements by any links, right now.
Maybe Chris Palmer can help with that...
Furthermore there's different ways of getting rid of Teredo (and the other
tunnel techs):
- there's a registry parameter 'DisabledComponents' that allows disabling
(native|tunnel|all) IPv6, based on a certain bit mask. see KB929852.
- (presumably) this parameter can be controlled by GPOs.
- the tunnel interfaces can be disabled individually by "netsh int $TUNNEL_INT
set state disabled" on individual systems (persistently, so setting stays after
reboot).
There's quite some debate which approach to use due to operational practices
and MS telling people "not to 'fully' disable IPv6 as you might lose support
for $SYSTEM". I've never been able to find any 'official source' for the latter
statement but heard it in pretty much all enterprise environments ("our Windows
people tell us we can't do that as the MS engineers tell them they will lose
support then").
best
Enno
On Wed, Jul 17, 2013 at 03:36:00PM +0200, Jens Link wrote:
> Jeroen Massar writes:
>
> > Windows boxes that are in an Active Domain (which should match your
> > 'enterprise net') have Teredo and 6to4 disabled per default.
>
> Sure about that? IIRC this depends on the Windows version. And I think I
> have seen Win 2008R2 Servers within an AD, with at least 6to4
> enable. Right now I'm not sure about Teredo.
>
> > Next to that one can enforce that of course through AD policies.
>
> Okay, not a group policies, but for reference:
>
> http://lists.cluenet.de/pipermail/ipv6-ops/2010-March/003267.html
>
> Where are the Windows people on this list? ;-)
>
> Jens
> --
> -----
> | Foelderichstr. 40 | 13595 Berlin, Germany| +49-151-18721264 |
> | http://blog.quux.de | jabber: jensl...@guug.de | --- |
> -
--
Enno Rey
ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 174 3082474
PGP FP 055F B3F3 FE9D 71DD C0D5 444E C611 033E 3296 1CC1
Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey
Troopers 2013 Videos online:
http://www.youtube.com/user/TROOPERScon?feature=watch
===
Blog: www.insinuator.net || Conference: www.troopers.de
===
Re: Windows 2008R2 MTU reverts to default
Hi, On Tue, Jun 11, 2013 at 12:48:37PM +0200, Daniel Roesen wrote: > On Tue, Jun 11, 2013 at 07:29:43AM +0200, Enno Rey wrote: > > b) (much better): have the router advertise the lower MTU you want to use > > in the RAs by just setting a lower MTU on the (router) interfaces in > > question. > > See also: > > http://blog.ioshints.info/2013/01/mtu-issues-and-tcp-mss-clamping-in.html > > Guys... don't mess arbitrarily with link MTUs (RA) when you have > problems with path MTU. well, a number of people/organizations I know solve (_other_ parties') path MTU problems by using "conservative" link MTU settings (e.g. 1400) in _their own_ networks... not sure about the intent of the OP though best Enno > > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 174 3082474 PGP FP 055F B3F3 FE9D 71DD C0D5 444E C611 033E 3296 1CC1 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de ===
Re: Windows 2008R2 MTU reverts to default
Hi, On Mon, Jun 10, 2013 at 10:59:21PM +0200, Dick Visser wrote: > On 10 June 2013 22:48, Phil Pennock wrote: > > On 2013-06-10 at 14:57 +0200, Dick Visser wrote: > >> This works for a while, but after a minute or so it changes back to the > >> default: > > > >> Any ideas what might be causing this? > > > > A thought, so only qualifies as "might", I don't know Windows to speak > > definitively, but ... IPv6 NDP Route Advertisement with the MTU option? > > > > Windows then updating the manually-configured 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? two things come to mind: a) as already stated by Christopher: by deactivating the processing of RAs on the Windows systems in question. It should be noted that this is a severe "deviation from default" (see https://www.troopers.de/wp-content/uploads/2013/01/TROOPERS13-Design+Configuration_of_IPv6_Segments_with_High_Security_Requirements-Enno_Rey.pdf for the term) and hence in general we don't like or recommend that approach. b) (much better): have the router advertise the lower MTU you want to use in the RAs by just setting a lower MTU on the (router) interfaces in question. See also: http://blog.ioshints.info/2013/01/mtu-issues-and-tcp-mss-clamping-in.html best Enno > > > -- > Dick Visser > System & Networking Engineer > TERENA Secretariat > Singel 468 D, 1017 AW Amsterdam > The Netherlands -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 174 3082474 PGP FP 055F B3F3 FE9D 71DD C0D5 444E C611 033E 3296 1CC1 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de ===
Re: RA Guard support...
Hi, one of our students quickly put together a list for different vendors, based on publicly available information. It can be found at http://www.insinuator.net. best Enno On Thu, May 02, 2013 at 09:19:07AM -0700, Mark Boolootian wrote: > Nick Buraglio put together an IPv6 feature matrix some time back. > Don't know how current it is: > > > http://www.forwardingplane.net/2011/03/ipv6-features-matrix-for-network-hardware/ -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 174 3082474 PGP FP 055F B3F3 FE9D 71DD C0D5 444E C611 033E 3296 1CC1 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de ===
