IPv6 ingress filtering

Kurt Buff - GSEC, GCIH kurt.buff at gmail.com
Fri May 17 23:07:52 CEST 2019


On Fri, May 17, 2019 at 1:59 PM Enno Rey <erey at ernw.de> 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
> > <brian.e.carpenter at gmail.com> 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
> =======================================================


More information about the ipv6-ops mailing list