On Fri, May 17, 2019 at 1:59 PM Enno Rey <[email protected]> wrote: > > 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:aaaa:bbbb:cccc:dddd:eeee:ffff > > Temporary IPv6 Address. . . . . . : > > 2002:4332:aaaa:bbbb:cccc:dddd:eeee:ffff > > Temporary IPv6 Address. . . . . . : > > 2002:4332:aaaa:bbbb:cccc:dddd:eeee:ffff > > 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
So, network filters aren't going to gratuitously inspect IPv4 packets for IPv6 content. Seems reasonable to me. Thanks, Kurt > > > > Kurt > > > > On Fri, May 17, 2019 at 1:06 PM Brian E Carpenter > > <[email protected]> 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 > =======================================================
