From ignatios at theory.cs.uni-bonn.de  Thu Dec  3 14:12:40 2015
From: ignatios at theory.cs.uni-bonn.de (Ignatios Souvatzis)
Date: Thu, 3 Dec 2015 14:12:40 +0100
Subject: wake on lan / wol with linux in IPv6-LAN (without IPv4)
In-Reply-To: <54188C76.4060009@ninjabadger.net>
References: <1758280.e4GZiBqmg0@eee-box> <9172206.KyyoHhs60Q@eee-box>
	<20140916075953.GA11261@cs.uni-bonn.de>
	<8738brrbga.fsf@nemi.mork.no> <54188C76.4060009@ninjabadger.net>
Message-ID: <20151203131240.GA18685@cs.uni-bonn.de>

On Tue, Sep 16, 2014 at 08:16:06PM +0100, Tom Hill wrote:
> On 16/09/14 13:34, Bj?rn Mork wrote:
> > This depends on all-stations multicast being forwarded to inactive
> > ports. If it works with your switches, then fine.  But I don't think you
> > can assume it works everywhere.
> 
> I'd be quite surprised if you find a switch that doesn't treat ff02::1
> in the same way as IPv4 broadcast, by default.
> 
> Saying that, I'd much prefer that IPv6 WoL had a known IPv6 multicast
> address, as opposed to using ff02::1.

But... that would mean you'd have to configure that. WoL wants to work
with minimal hardware action - it only checks for any ffffffffffff followed
by a couple of times its mac address anywhere in a packet, right?

	-is

From frnkblk at iname.com  Tue Dec  8 00:50:11 2015
From: frnkblk at iname.com (Frank Bulk)
Date: Mon, 7 Dec 2015 17:50:11 -0600
Subject: DNSSec and GoDaddy and IPv6 (cross-posted)
Message-ID: <006701d1314a$0460d1d0$0d227570$@iname.com>

Just for the record -- worked with GoDaddy over the last few weeks to find
out why I can't get DS keys added to a zone, onlyv6.com.  Their DS-adding
interface (selective and bulk) errors out.  

It culminated today with lots of back and forth with the front-line support
(that interfaces, via chat, with the Advanced Technical Support team).
After some red herrings about lack of connected to our nameservers (I had to
send screenshots that I could ping all three nameservers), a concern that a
nameserver didn't have a matching PTR record, and that not all nameservers
were at the same serial number (one was at a slightly older one), it came
down to that they require two working IPv4-enabled nameservers in order to
add a DS key.  Having an IPv6-only zone is apparently not acceptable.  Kudos
to the two front-line support reps that were professional and did their
level best (though one remarked he had never seen an IP address like that
before).

I suspect that GoDaddy's backend DS validation system has some kind of bug
that prevents contact with an IPv6-only zone.

Anyone know of a registrar that supports both IPv6 and DNSsec?

Frank


From drc at virtualized.org  Tue Dec  8 01:26:10 2015
From: drc at virtualized.org (David Conrad)
Date: Mon, 7 Dec 2015 16:26:10 -0800
Subject: DNSSec and GoDaddy and IPv6 (cross-posted)
In-Reply-To: <006701d1314a$0460d1d0$0d227570$@iname.com>
References: <006701d1314a$0460d1d0$0d227570$@iname.com>
Message-ID: <1CABB5C7-75E6-4447-B018-83ED091916A9@virtualized.org>

On Dec 7, 2015, at 3:50 PM, Frank Bulk <frnkblk at iname.com> wrote:
> Anyone know of a registrar that supports both IPv6 and DNSsec?

https://www.gkg.net

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20151207/3b7c8e87/attachment.bin 

From nicolas at ncartron.org  Tue Dec  8 08:53:27 2015
From: nicolas at ncartron.org (Nico CARTRON)
Date: Tue, 8 Dec 2015 08:53:27 +0100
Subject: [dns-operations] DNSSec and GoDaddy and IPv6 (cross-posted)
In-Reply-To: <1CABB5C7-75E6-4447-B018-83ED091916A9@virtualized.org>
References: <006701d1314a$0460d1d0$0d227570$@iname.com>
	<1CABB5C7-75E6-4447-B018-83ED091916A9@virtualized.org>
Message-ID: <BCC0EEC0-10A0-4AB4-B2A5-6587DB88A2AC@ncartron.org>

On 08 Dec 2015, at 01:26, David Conrad <drc at virtualized.org> wrote:
> 
>> On Dec 7, 2015, at 3:50 PM, Frank Bulk <frnkblk at iname.com> wrote:
>> Anyone know of a registrar that supports both IPv6 and DNSsec?
> 
> https://www.gkg.net

GANDI (http://www.gandi.net) also does. 

Cheers,

-- 
Nico

From p.mayers at imperial.ac.uk  Tue Dec  8 13:08:30 2015
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Tue, 8 Dec 2015 12:08:30 +0000
Subject: [dns-operations] DNSSec and GoDaddy and IPv6 (cross-posted)
In-Reply-To: <BCC0EEC0-10A0-4AB4-B2A5-6587DB88A2AC@ncartron.org>
References: <006701d1314a$0460d1d0$0d227570$@iname.com>
	<1CABB5C7-75E6-4447-B018-83ED091916A9@virtualized.org>
	<BCC0EEC0-10A0-4AB4-B2A5-6587DB88A2AC@ncartron.org>
Message-ID: <5666C83E.70106@imperial.ac.uk>

On 08/12/15 07:53, Nico CARTRON wrote:
> On 08 Dec 2015, at 01:26, David Conrad <drc at virtualized.org> wrote:
>>
>>> On Dec 7, 2015, at 3:50 PM, Frank Bulk <frnkblk at iname.com> wrote:
>>> Anyone know of a registrar that supports both IPv6 and DNSsec?
>>
>> https://www.gkg.net
>
> GANDI (http://www.gandi.net) also does.

+1 GANDI are excellent.

From marka at isc.org  Tue Dec  8 01:58:06 2015
From: marka at isc.org (Mark Andrews)
Date: Tue, 08 Dec 2015 11:58:06 +1100
Subject: [dns-operations] DNSSec and GoDaddy and IPv6 (cross-posted)
In-Reply-To: Your message of "Mon, 07 Dec 2015 17:50:11 -0600."
	<006701d1314a$0460d1d0$0d227570$@iname.com>
References: <006701d1314a$0460d1d0$0d227570$@iname.com>
Message-ID: <20151208005806.507EB3EDD7D1@rock.dv.isc.org>


In message <006701d1314a$0460d1d0$0d227570$@iname.com>, "Frank Bulk" writes:
> Just for the record -- worked with GoDaddy over the last few weeks to find
> out why I can't get DS keys added to a zone, onlyv6.com.  Their DS-adding
> interface (selective and bulk) errors out.  
> 
> It culminated today with lots of back and forth with the front-line support
> (that interfaces, via chat, with the Advanced Technical Support team).
> After some red herrings about lack of connected to our nameservers (I had to
> send screenshots that I could ping all three nameservers), a concern that a
> nameserver didn't have a matching PTR record, and that not all nameservers
> were at the same serial number (one was at a slightly older one), it came
> down to that they require two working IPv4-enabled nameservers in order to
> add a DS key.  Having an IPv6-only zone is apparently not acceptable.  Kudos
> to the two front-line support reps that were professional and did their
> level best (though one remarked he had never seen an IP address like that
> before).

RFC 3901 comes to mind here. 
 
> I suspect that GoDaddy's backend DS validation system has some kind of bug
> that prevents contact with an IPv6-only zone.

It's called not turning on IPv6. :-)
 
> Anyone know of a registrar that supports both IPv6 and DNSsec?
> 
> Frank
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

From paf at frobbit.se  Tue Dec  8 03:00:20 2015
From: paf at frobbit.se (Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=)
Date: Tue, 08 Dec 2015 03:00:20 +0100
Subject: [dns-operations] DNSSec and GoDaddy and IPv6 (cross-posted)
In-Reply-To: <006701d1314a$0460d1d0$0d227570$@iname.com>
References: <006701d1314a$0460d1d0$0d227570$@iname.com>
Message-ID: <C0E764EB-7956-4BBA-8F2B-C9A90EE76D23@frobbit.se>

On 8 Dec 2015, at 0:50, Frank Bulk wrote:

> Anyone know of a registrar that supports both IPv6 and DNSsec?

Self promotion: Frobbit :-)

   Patrik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20151208/ca010db8/attachment.bin 

From johannes at webernetz.net  Wed Dec 16 10:33:29 2015
From: johannes at webernetz.net (Johannes Weber)
Date: Wed, 16 Dec 2015 10:33:29 +0100
Subject: IPv6 Dynamic Prefix Problems
Message-ID: <b723a19318a867a97702fb4a817fa3c0@webernetz.net>

 

Hello ipv6-ops,

what are your experiences with dynamic IPv6 prefixes? Here in Germany,
several ISPs only offer dynamic /56 prefixes that change after a router
reboot. Of course, for "normal" end-users this is not a problem. But for
companies having several remote offices behind such ISP lines, this is a
problem. (And of course, for me as a network guy, too. ;))
I encounter several problems with this type of dynamic prefixes and
summarized them here:
http://blog.webernetz.net/2015/10/27/ipv6-dyn-prefix-problems/ 

1) Many DNS changes for services behind the dyn prefix (not all devices
are able to update DNS records)
2) Security policies with DynDNS ranges (how to allow a dyn IPv6-range
in other firewall policies?)
3) Routing inside IPv6 VPN tunnels (solved with OSPFv3, but maybe not
optimal?)

I am highly interested in others experience about dynamic prefixes. How
do you solve these problems, e.g., when a company has several remote
offices with dynamic prefixes?

Thanks,

Johannes 
-- 
Johannes Weber
 mail:    johannes at webernetz.net
 mobile:  +49 174 1880211

 blog:    http://blog.webernetz.net
 twitter: https://twitter.com/webernetz 

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20151216/1235038a/attachment.html 

From lists at quux.de  Wed Dec 16 10:40:49 2015
From: lists at quux.de (Jens Link)
Date: Wed, 16 Dec 2015 10:40:49 +0100
Subject: IPv6 Dynamic Prefix Problems
In-Reply-To: <b723a19318a867a97702fb4a817fa3c0@webernetz.net> (Johannes
	Weber's message of "Wed, 16 Dec 2015 10:33:29 +0100")
References: <b723a19318a867a97702fb4a817fa3c0@webernetz.net>
Message-ID: <871tam20ke.fsf@pc8.berlin.quux.de>

Johannes Weber <johannes at webernetz.net> writes:

> 1) Many DNS changes for services behind the dyn prefix (not all devices
> are able to update DNS records)
> 2) Security policies with DynDNS ranges (how to allow a dyn IPv6-range
> in other firewall policies?)
> 3) Routing inside IPv6 VPN tunnels (solved with OSPFv3, but maybe not
> optimal?)

4) Prefix Translation
5) Use a SIXXS / HE Tunnel 
6) Paying extra for static prefixes (if even possible) 

There are several theories about why they change the prefix:

a) customer demand (privacy)
b) we have always done it this way
c) as with v4 we can sell static addresses

Jens
-- 
----------------------------------------------------------------------------
| Foelderichstr. 40   | 13595 Berlin, Germany           | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink at quux.de        | ---------------  | 
----------------------------------------------------------------------------

From bjorn at mork.no  Wed Dec 16 11:06:58 2015
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Wed, 16 Dec 2015 11:06:58 +0100
Subject: IPv6 Dynamic Prefix Problems
In-Reply-To: <b723a19318a867a97702fb4a817fa3c0@webernetz.net> (Johannes
	Weber's message of "Wed, 16 Dec 2015 10:33:29 +0100")
References: <b723a19318a867a97702fb4a817fa3c0@webernetz.net>
Message-ID: <87r3imd7wd.fsf@nemi.mork.no>

Johannes Weber <johannes at webernetz.net> writes:

> what are your experiences with dynamic IPv6 prefixes? Here in Germany,
> several ISPs only offer dynamic /56 prefixes that change after a router
> reboot. Of course, for "normal" end-users this is not a problem. But for
> companies having several remote offices behind such ISP lines, this is a
> problem. (And of course, for me as a network guy, too. ;))
> I encounter several problems with this type of dynamic prefixes and
> summarized them here:
> http://blog.webernetz.net/2015/10/27/ipv6-dyn-prefix-problems/ 
>
> 1) Many DNS changes for services behind the dyn prefix (not all devices
> are able to update DNS records)
> 2) Security policies with DynDNS ranges (how to allow a dyn IPv6-range
> in other firewall policies?)
> 3) Routing inside IPv6 VPN tunnels (solved with OSPFv3, but maybe not
> optimal?)
>
> I am highly interested in others experience about dynamic prefixes. How
> do you solve these problems, e.g., when a company has several remote
> offices with dynamic prefixes?

Not really solving your problem, but these were the main reasons why we
chose to provide (semi-)static prefixes to all users. "business class"
users get fully static prefixes, while residential users get static
prefixes as long as they don't have to change access router (due to
changes in the layer2 access network).  Such events are rare, so most
users will never have to change their prefix.

This is implemented by pre-allocating prefixes for every user within
aggregation ranges allocated to the routers they connect to.  Rebooting,
or even replacing, the router will not affect the prefix.  Aggregating
per router avoids having too many prefixes in the table. For simplicity
we wanted to aggregate on nibble boundaries, and found that /36 was a
suitable tradeoff between number of routes and wasted addresses.  Each
access router will typically use more than one /36, but going up to a
/32 seemed excessive :)

(we give every user a /48, so there are only 4096 prefixes per /36).

Sorry for your problems, but I must admit I am happy to see such reports
indicating that our strategy makes sense.  To tell the truth, it wasn't
easy to sell the concept to an organization used to dynamic IPv4 pool
allocations.  Some of the counter arguments included "what about privacy
when the prefix is tied to a specific user?" and "will residential users
get business class service?"


But the only "real" problem so far is that some users might not like the
prefix they are assigned permanently.  Some of the reasons are actually
worth considering, like parts of the address looking like words with
specific negative meanings.




Bj?rn

From sthaug at nethelp.no  Wed Dec 16 11:13:43 2015
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Wed, 16 Dec 2015 11:13:43 +0100 (CET)
Subject: IPv6 Dynamic Prefix Problems
In-Reply-To: <871tam20ke.fsf@pc8.berlin.quux.de>
References: <b723a19318a867a97702fb4a817fa3c0@webernetz.net>
	<871tam20ke.fsf@pc8.berlin.quux.de>
Message-ID: <20151216.111343.74695574.sthaug@nethelp.no>

> > 1) Many DNS changes for services behind the dyn prefix (not all devices
> > are able to update DNS records)
> > 2) Security policies with DynDNS ranges (how to allow a dyn IPv6-range
> > in other firewall policies?)
> > 3) Routing inside IPv6 VPN tunnels (solved with OSPFv3, but maybe not
> > optimal?)
> 
> 4) Prefix Translation
> 5) Use a SIXXS / HE Tunnel 
> 6) Paying extra for static prefixes (if even possible) 
> 
> There are several theories about why they change the prefix:
> 
> a) customer demand (privacy)
> b) we have always done it this way
> c) as with v4 we can sell static addresses

We run dynamic IPv4 allocation for our residential customers (and any
business customer which wants it) - and we *don't* actively change the
allocated address. As long as the customer sends a DHCP request from the
same MAC address (or client identifier), the customer would normally get
the same IPv4 address.

We expect to use the same policy for IPv6 - i.e. there are no plans to
*actively* change IPv6 address / prefix.

Steinar Haug, AS 2116

From gert at space.net  Wed Dec 16 11:29:25 2015
From: gert at space.net (Gert Doering)
Date: Wed, 16 Dec 2015 11:29:25 +0100
Subject: IPv6 Dynamic Prefix Problems
In-Reply-To: <b723a19318a867a97702fb4a817fa3c0@webernetz.net>
References: <b723a19318a867a97702fb4a817fa3c0@webernetz.net>
Message-ID: <20151216102925.GX58491@Space.Net>

Hi,

On Wed, Dec 16, 2015 at 10:33:29AM +0100, Johannes Weber wrote:
> what are your experiences with dynamic IPv6 prefixes? Here in Germany,
> several ISPs only offer dynamic /56 prefixes that change after a router
> reboot. Of course, for "normal" end-users this is not a problem. But for
> companies having several remote offices behind such ISP lines, this is a
> problem. (And of course, for me as a network guy, too. ;))

I do feel your pain, but I wonder if this is not just assumptions that
need to go away - and if this is the right way to *make* them go away
(by breaking stuff that relies on "the IPv6 address of <box> will never
ever change!").

Yes, network people like to have SSH sessions that survive for weeks or
longer, but really, we're just 0.01% of the users - and typical users
have no idea what a "long-lived TCP session" might be...

OTOH, what you really want is multihoming with two different IPv6 access
ISPs, and that will have to work with "I get one prefix from each ISP
and my devices have to handle having multiple addresses, some of them
coming and going at unexpected times" - which inevitably leads to needing
new strategies for service discovery (= "dynDNS") and session failover
in case one of the addresses just stops working because the ISP line
broke.

[..]
> 1) Many DNS changes for services behind the dyn prefix (not all devices
> are able to update DNS records)

This indeed is tricky.  OTOH, AVM can do it for devices *behind* the
router, so we "just" need to ensure router vendors understand what
is needed...

> 2) Security policies with DynDNS ranges (how to allow a dyn IPv6-range
> in other firewall policies?)

Is "relying on source IP address" a good security strategy?

> 3) Routing inside IPv6 VPN tunnels (solved with OSPFv3, but maybe not
> optimal?)

The "multiple addresses" model lends itself to "the VPN will provide
yet another /64 for the LAN, and by choosing the appropriate *source*
address the client will decide whether it wants to go into the VPN or
not" (homenet source-address dependent routing).

> I am highly interested in others experience about dynamic prefixes. How
> do you solve these problems, e.g., when a company has several remote
> offices with dynamic prefixes?

Add a second prefix from the internal company range and put that into the
VPN (source address selection will nicely handle this today, unlike
all the potential pitfalls with proper source address *failover* in the
multihoming case).

Food for thought, not an "answer today".

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: 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

From liviu.pislaru at rcs-rds.ro  Wed Dec 16 12:03:42 2015
From: liviu.pislaru at rcs-rds.ro (Liviu Pislaru)
Date: Wed, 16 Dec 2015 13:03:42 +0200
Subject: IPv6 Dynamic Prefix Problems
In-Reply-To: <b723a19318a867a97702fb4a817fa3c0@webernetz.net>
References: <b723a19318a867a97702fb4a817fa3c0@webernetz.net>
Message-ID: <0b95c4e915529e287ea8d937ee83ac0f@rcs-rds.ro>

 

Johannes,

I've read your blog post and i fully agree that DNS changes (dynamic
DNS) and dynamic IPv6 allocation for LAN (DHCP-PD) is a big issue.
Couple of years ago i addressed this issue and came up with a personal
solution (you can test it and use it for free if you want).
https://www.duiadns.net/ipv6-for-lan-feature

regards,
--
Liviu P.

On 2015-12-16 11:33, Johannes Weber wrote: 

> Hello ipv6-ops,
> 
> what are your experiences with dynamic IPv6 prefixes? Here in Germany, several ISPs only offer dynamic /56 prefixes that change after a router reboot. Of course, for "normal" end-users this is not a problem. But for companies having several remote offices behind such ISP lines, this is a problem. (And of course, for me as a network guy, too. ;))
> I encounter several problems with this type of dynamic prefixes and summarized them here:
> http://blog.webernetz.net/2015/10/27/ipv6-dyn-prefix-problems/ [1] 
> 
> 1) Many DNS changes for services behind the dyn prefix (not all devices are able to update DNS records)
> 2) Security policies with DynDNS ranges (how to allow a dyn IPv6-range in other firewall policies?)
> 3) Routing inside IPv6 VPN tunnels (solved with OSPFv3, but maybe not optimal?)
> 
> I am highly interested in others experience about dynamic prefixes. How do you solve these problems, e.g., when a company has several remote offices with dynamic prefixes?
> 
> Thanks,
> 
> Johannes 
> -- 
> 
> Johannes Weber
> mail: johannes at webernetz.net
> mobile: +49 174 1880211
> 
> blog: http://blog.webernetz.net [2]
> twitter: https://twitter.com/webernetz [3]
 

Links:
------
[1] http://blog.webernetz.net/2015/10/27/ipv6-dyn-prefix-problems/
[2] http://blog.webernetz.net
[3] https://twitter.com/webernetz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20151216/e0596f59/attachment.html 

From jeroen at massar.ch  Wed Dec 16 13:01:19 2015
From: jeroen at massar.ch (Jeroen Massar)
Date: Wed, 16 Dec 2015 13:01:19 +0100
Subject: IPv6 Dynamic Prefix Problems
In-Reply-To: <871tam20ke.fsf@pc8.berlin.quux.de>
References: <b723a19318a867a97702fb4a817fa3c0@webernetz.net>
	<871tam20ke.fsf@pc8.berlin.quux.de>
Message-ID: <5671528F.4050907@massar.ch>

On 2015-12-16 10:40, Jens Link wrote:
> Johannes Weber <johannes at webernetz.net> writes:
[..]
> 5) Use a SIXXS / HE Tunnel 

Tunnel brokers (RFC3053) are transition technologies, they won't be here
forever. You likely wanted to point out commercial VPN solutions that
can provide these services just like the normal ISP who is apparently
providing insufficiently configured connectivity.

With IPv6 being 20 years old (RF1883) that transition has to end
somewhere...

Note that SixXS will be having a nice "Call your ISP for IPv6" action[1]
starting somewhere next week.

This hopefully will get people finally calling up to their ISPs and
asking for IPv6 instead of just easily bypassing IPv6 deployment with
easier means.

There is no reason anymore (missing CPE/PE device support, missing OS
support, missing software support) for 'testing IPv6', various locations
are running it natively, many are even forcing DS-Lite/CGN to make sure
they can keep the IPv4 addresses for 'business' customers. Hence, if an
ISP did not take care in the last say 10 years of getting ready for
IPv6, then they won't do that in the next few years either, thus better
to abandon hope and chose wisely with your money.


As for the dynamic issue, everybody seems to forget the great idea that
Microsoft provided: Direct Access[2] or using the 'IPv6 security
feature': IPSEC.

Sign your packets, and check that the signature is valid & known on the
receiving side, presto, does not matter what the prefix is anymore.

Indeed, that does not work like PI, but all/most-of the work on
alternative models have been abandoned, which is why there are so many
/48s PI prefix and sub-prefixes out of PA (Provider Aggregated, remember
that ;) in your routing tables....

Routing scaling research will be fun, but in the end, that is the only
real way to handle that situation.

Greets,
 Jeroen

[1] https://www.sixxs.net/news/2015/#happybirthdayipv6ipv6turns20ye-1201
[2] https://en.wikipedia.org/wiki/DirectAccess


From gert at space.net  Wed Dec 16 13:09:27 2015
From: gert at space.net (Gert Doering)
Date: Wed, 16 Dec 2015 13:09:27 +0100
Subject: IPv6 Dynamic Prefix Problems
In-Reply-To: <5671528F.4050907@massar.ch>
References: <b723a19318a867a97702fb4a817fa3c0@webernetz.net>
	<871tam20ke.fsf@pc8.berlin.quux.de> <5671528F.4050907@massar.ch>
Message-ID: <20151216120927.GB58491@Space.Net>

Hi,

On Wed, Dec 16, 2015 at 01:01:19PM +0100, Jeroen Massar wrote:
> Routing scaling research will be fun, but in the end, that is the only
> real way to handle that situation.

Dual-PA multihoming works, and has a number of extra benefits that you
cannot get with PI - like, applications can decide which ISP to use
("bittorrent on cable, ssh on LTE") by selecting the corresponding
source address.

It's not something that would work for an enterprise network, but as soon
as the "we need persistant addresses!" phase of denial is over, it's a great
solution for SoHo networks.  And yes, been there, tested OpenWRT HNCP
implementation, liked the result.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: 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

From jeroen at massar.ch  Wed Dec 16 13:16:41 2015
From: jeroen at massar.ch (Jeroen Massar)
Date: Wed, 16 Dec 2015 13:16:41 +0100
Subject: IPv6 Dynamic Prefix Problems
In-Reply-To: <20151216120927.GB58491@Space.Net>
References: <b723a19318a867a97702fb4a817fa3c0@webernetz.net>
	<871tam20ke.fsf@pc8.berlin.quux.de> <5671528F.4050907@massar.ch>
	<20151216120927.GB58491@Space.Net>
Message-ID: <56715629.6040608@massar.ch>

On 2015-12-16 13:09, Gert Doering wrote:
> Hi,
> 
> On Wed, Dec 16, 2015 at 01:01:19PM +0100, Jeroen Massar wrote:
>> Routing scaling research will be fun, but in the end, that is the only
>> real way to handle that situation.
> 
> Dual-PA multihoming works, and has a number of extra benefits that you
> cannot get with PI - like, applications can decide which ISP to use
> ("bittorrent on cable, ssh on LTE") by selecting the corresponding
> source address.

The hack for selecting which uplink to use is what some people think is
what they should use QoS for, forgetting that the other side and
intermediaries will have no idea about what the QoS fields mean.

> It's not something that would work for an enterprise network, but as soon
> as the "we need persistant addresses!" phase of denial is over, it's a great
> solution for SoHo networks.  And yes, been there, tested OpenWRT HNCP
> implementation, liked the result.

Homenet (for homes as it and you say) is a good start indeed though
primarily addresses outbound traffic.

DynDNS can 'solve' inbound connectivity but the world would be so much
better off if it actually used SRV so one could publish preferences that
way.

Greets,
 Jeroen


From gert at space.net  Wed Dec 16 13:23:31 2015
From: gert at space.net (Gert Doering)
Date: Wed, 16 Dec 2015 13:23:31 +0100
Subject: IPv6 Dynamic Prefix Problems
In-Reply-To: <56715629.6040608@massar.ch>
References: <b723a19318a867a97702fb4a817fa3c0@webernetz.net>
	<871tam20ke.fsf@pc8.berlin.quux.de> <5671528F.4050907@massar.ch>
	<20151216120927.GB58491@Space.Net> <56715629.6040608@massar.ch>
Message-ID: <20151216122331.GD58491@Space.Net>

Hi,

On Wed, Dec 16, 2015 at 01:16:41PM +0100, Jeroen Massar wrote:
> > It's not something that would work for an enterprise network, but as soon
> > as the "we need persistant addresses!" phase of denial is over, it's a great
> > solution for SoHo networks.  And yes, been there, tested OpenWRT HNCP
> > implementation, liked the result.
> 
> Homenet (for homes as it and you say) is a good start indeed though
> primarily addresses outbound traffic.
> 
> DynDNS can 'solve' inbound connectivity but the world would be so much
> better off if it actually used SRV so one could publish preferences that
> way.

Indeed, more work needs to be done.  I'm not claiming this is perfect 
- many little details need to be improved, like SRV for externally-visible
components (= software that can publish them, dyndns services that can
handle them, client software that will query for them).

gert
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20151216/e8a45f74/attachment.bin 

From Holger.Zuleger at hznet.de  Wed Dec 16 15:56:56 2015
From: Holger.Zuleger at hznet.de (Holger Zuleger)
Date: Wed, 16 Dec 2015 15:56:56 +0100
Subject: IPv6 Dynamic Prefix Problems
In-Reply-To: <b723a19318a867a97702fb4a817fa3c0@webernetz.net>
References: <b723a19318a867a97702fb4a817fa3c0@webernetz.net>
Message-ID: <56717BB8.9020303@hznet.de>


On 16.12.2015 10:33, Johannes Weber wrote:
> 1) Many DNS changes for services behind the dyn prefix (not all devices
> are able to update DNS records)
For those of you having its own authoritative DNS server (which is
recommended anyway if you want to use DNSSEC), the following tool can
help to manager your DNS entries in case of network prefix change:
http://www.hznet.de/tools.html#gen6dns

It generates forward and reverse RR for all prefixes given on the
command line.

> 2) Security policies with DynDNS ranges (how to allow a dyn IPv6-range
> in other firewall policies?)
> 3) Routing inside IPv6 VPN tunnels (solved with OSPFv3, but maybe not
> optimal?)

> I am highly interested in others experience about dynamic prefixes. How
> do you solve these problems, e.g., when a company has several remote
> offices with dynamic prefixes?
The best is to avoid dynamic prefixes if it is not a single LAN home
network environment.  Otherwise there are actually too many unresolved
issues.

So in your case ("company (with) several remote offices") I would
recommend have a look at LISP. It can help a lot to get a stable prefix.
The advantage against SixXS and the like is, that LISP can be used with
IPv6 transport too, and is able to send traffic to other LISP sites
directly, not via the LISP Proxy. LISP is an full mesh overlay network.

Holger

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4160 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20151216/b0c8372d/attachment-0001.bin 

From wolfgang.rupprecht at gmail.com  Sat Dec 19 20:33:11 2015
From: wolfgang.rupprecht at gmail.com (Wolfgang S. Rupprecht)
Date: Sat, 19 Dec 2015 11:33:11 -0800
Subject: IPv6 Dynamic Prefix Problems
References: <b723a19318a867a97702fb4a817fa3c0@webernetz.net>
Message-ID: <871taicjyg.fsf@capsicum.wsrcc.com>


Johannes Weber <johannes at webernetz.net> writes:
> what are your experiences with dynamic IPv6 prefixes?

I have native IPv6 via Comcast, a cable company in the US.  At first my
IPv6 address got lost every few days (4 days if I recall correctly).
After many frustrating rounds of hand edits to a dozen files in /etc and
DNS zone file directory every time the address changed, I started to
piece together what was going on.  Basically the router, a Netgear
3700v4, while claiming to implement IPv6, was really just running highly
buggy alpha quality firmware that was probably written by an outside
contractor and never updated by Netgear.

1) the dhcp ipv6 renewals never occurred because the firewall wasn't
   allowing packets to destination port 546/udp (the dhcp6 port)
   through.

Even after months of this being reported to Netgear they hadn't fixed
it.  Many other router manufacturers had the same problem.   If you are
losing ipv6 addresses and ipv6 simply stops even though the unit wasn't
rebooted this is most likely the cause.

2) whenever the unit was rebooted it would get a new ipv6 address.
Again this wasn't Comcast's fault.  The IPv6 spec for dhcp doesn't use
MAC address to identify the client.  It uses a newly created method
using what the RFC calls DUID.  This can be generated by several methods
one being a combination of the time the machine was *first* booted and
the one of the unit's MAC address.  The intention was to have only one
identifier for the client even if it had several different interfaces
(and hence multiple possible MAC addresses).  It was also intended to
prevent different units from sharing the same identifier in the case of
a network card being moved to a different machine.  The time of first
boot would change, hence the DUID would be different.  The intention was
that once generated on a machine, the DUID would be written to a file or
other store and used from then on.  Router manufacturers seemed to have
missed that fact because quite a few of them generate a brand new DUID
every time the router boots.  This is why the IPv6 address changes on
every boot when running a buggy router (which is unfortunately most of
the consumer routers running factory firmware.)

I finally solved my problem with both the buggy firewall rules and the
buggy DUID usage by installing aftermarket OpenWRT firmware on my unit.
I now have semi-static dhcp6 issued addresses that don't change for many
months at a time.

>From your description, it sounds like you might be seeing issue #2 from
above also.  You might ask your ISP if they are seeing your DUID change
or perhaps run a test where they compare the DUID before and after you
reboot your router.

As for the DNS changing perhaps once per year, I have a small shell
script that runs on the client that registers its IP address in a
dynamic DNS zone I created for this purpose.  I use nsupdate with PKI
security to secure the update.  This also covers the case of laptops
which might pop up on a different IP address several times a day.

-wolfgang
   


From kurt.buff at gmail.com  Sat Dec 19 22:37:58 2015
From: kurt.buff at gmail.com (Kurt Buff)
Date: Sat, 19 Dec 2015 13:37:58 -0800
Subject: Curious situation - not urgent, but I'd like to know more
Message-ID: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>

All,

I ran into an interesting situation some months ago which still
baffles me, and though I was able to work around it, I expect it will
happen again.

We implemented MSFT DirectAcess at our company quite some time ago
(using 2008R2 and Forefront 2010), and it works extremely well.

At least it worked well for everyone until one of the employees got
his Comcast connection upgraded, and then DirectAccess didn't work for
that employee any more.

We proved that if he tethered to his cell phone, that would work, and
if he used an SSL VPN client while on his Comcast connect that would
work, but DirectAccess would not work at home.

Finally, I discovered that his Comcast-installed router was handing
our IPv6 addresses on his home LAN. Turning that off enabled
DirectAccess to work again.

We do not have an assigned IPv6 block from our ISP, though of course
MSFT OSes use it, and auto-assign themselves addresses, but for now
we're ignoring it.

Has anyone run into this problem and solved it - not by turning off
iIPv6 address assignment for the home LAN, but really solved it? If
so, how did you do that?

Would getting and implementing an IPv6 assignment from our ISP cure
the problem, or make it worse?

I've found little guidance from MSFT about DirectAccess in an IPv6
environment, though I admit I haven't been terribly diligent in my
searches.

Kurt

From jjmb at jjmb.com  Sun Dec 20 03:49:05 2015
From: jjmb at jjmb.com (Brzozowski, John Jason)
Date: Sat, 19 Dec 2015 21:49:05 -0500
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
Message-ID: <CAFFn+aVHEa3NLV18q2rSC4DTAedm4Z2nCXDLLohL6KUygKBFKg@mail.gmail.com>

I run the IPv6 program for Comcast.  Let me know how I can help.

Adding my work email so I don't miss these emails.

John

On Saturday, December 19, 2015, Kurt Buff <kurt.buff at gmail.com> wrote:

> All,
>
> I ran into an interesting situation some months ago which still
> baffles me, and though I was able to work around it, I expect it will
> happen again.
>
> We implemented MSFT DirectAcess at our company quite some time ago
> (using 2008R2 and Forefront 2010), and it works extremely well.
>
> At least it worked well for everyone until one of the employees got
> his Comcast connection upgraded, and then DirectAccess didn't work for
> that employee any more.
>
> We proved that if he tethered to his cell phone, that would work, and
> if he used an SSL VPN client while on his Comcast connect that would
> work, but DirectAccess would not work at home.
>
> Finally, I discovered that his Comcast-installed router was handing
> our IPv6 addresses on his home LAN. Turning that off enabled
> DirectAccess to work again.
>
> We do not have an assigned IPv6 block from our ISP, though of course
> MSFT OSes use it, and auto-assign themselves addresses, but for now
> we're ignoring it.
>
> Has anyone run into this problem and solved it - not by turning off
> iIPv6 address assignment for the home LAN, but really solved it? If
> so, how did you do that?
>
> Would getting and implementing an IPv6 assignment from our ISP cure
> the problem, or make it worse?
>
> I've found little guidance from MSFT about DirectAccess in an IPv6
> environment, though I admit I haven't been terribly diligent in my
> searches.
>
> Kurt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20151219/291feb66/attachment.html 

From frnkblk at iname.com  Sun Dec 20 05:39:41 2015
From: frnkblk at iname.com (frnkblk at iname.com)
Date: Sat, 19 Dec 2015 22:39:41 -0600
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
Message-ID: <004101d13ae0$7280e430$5782ac90$@iname.com>

Have you tried running a Wireshark capture on that employee's computer to confirm if it's trying use DirectAccess over IPv6?  

Frank

-----Original Message-----
From: ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de [mailto:ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de] On Behalf Of Kurt Buff
Sent: Saturday, December 19, 2015 3:38 PM
To: ipv6-ops at lists.cluenet.de
Subject: Curious situation - not urgent, but I'd like to know more

All,

I ran into an interesting situation some months ago which still
baffles me, and though I was able to work around it, I expect it will
happen again.

We implemented MSFT DirectAcess at our company quite some time ago
(using 2008R2 and Forefront 2010), and it works extremely well.

At least it worked well for everyone until one of the employees got
his Comcast connection upgraded, and then DirectAccess didn't work for
that employee any more.

We proved that if he tethered to his cell phone, that would work, and
if he used an SSL VPN client while on his Comcast connect that would
work, but DirectAccess would not work at home.

Finally, I discovered that his Comcast-installed router was handing
our IPv6 addresses on his home LAN. Turning that off enabled
DirectAccess to work again.

We do not have an assigned IPv6 block from our ISP, though of course
MSFT OSes use it, and auto-assign themselves addresses, but for now
we're ignoring it.

Has anyone run into this problem and solved it - not by turning off
iIPv6 address assignment for the home LAN, but really solved it? If
so, how did you do that?

Would getting and implementing an IPv6 assignment from our ISP cure
the problem, or make it worse?

I've found little guidance from MSFT about DirectAccess in an IPv6
environment, though I admit I haven't been terribly diligent in my
searches.

Kurt



From evyncke at cisco.com  Sun Dec 20 10:10:34 2015
From: evyncke at cisco.com (Eric Vyncke (evyncke))
Date: Sun, 20 Dec 2015 09:10:34 +0000
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
Message-ID: <D29C2D07.62A97%evyncke@cisco.com>

Interesting situation indeed :-)

As we all known, Microsoft DirectAccess uses IPsec over IPv6 (and
potentially over Teredo or SSL-VPN if the host does not have native IPv6).
So, if your DirectAccess head-end is dual-stack, it now receives Ipsec
packets over IPv6 rather than HTTLS or Teredo over IPv4, so, firewall
settings must be tuned for that.

Now, I am really puzzled by your sentence "his Comcast-installed router
was handing our IPv6 addresses on his home LAN", is it a typo in 'our'
rather than 'out' ? It would be interesting to see the
addresses/prefixes/routes of the failing DirectAccess client as well as
which IPv6 address.prefix is used by DirectAccess for the
normally-functionning clients.

-?ric


On 19/12/15 22:37, "ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de on
behalf of Kurt Buff" <ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de
on behalf of kurt.buff at gmail.com> wrote:

>All,
>
>I ran into an interesting situation some months ago which still
>baffles me, and though I was able to work around it, I expect it will
>happen again.
>
>We implemented MSFT DirectAcess at our company quite some time ago
>(using 2008R2 and Forefront 2010), and it works extremely well.
>
>At least it worked well for everyone until one of the employees got
>his Comcast connection upgraded, and then DirectAccess didn't work for
>that employee any more.
>
>We proved that if he tethered to his cell phone, that would work, and
>if he used an SSL VPN client while on his Comcast connect that would
>work, but DirectAccess would not work at home.
>
>Finally, I discovered that his Comcast-installed router was handing
>our IPv6 addresses on his home LAN. Turning that off enabled
>DirectAccess to work again.
>
>We do not have an assigned IPv6 block from our ISP, though of course
>MSFT OSes use it, and auto-assign themselves addresses, but for now
>we're ignoring it.
>
>Has anyone run into this problem and solved it - not by turning off
>iIPv6 address assignment for the home LAN, but really solved it? If
>so, how did you do that?
>
>Would getting and implementing an IPv6 assignment from our ISP cure
>the problem, or make it worse?
>
>I've found little guidance from MSFT about DirectAccess in an IPv6
>environment, though I admit I haven't been terribly diligent in my
>searches.
>
>Kurt


From netztier.ch at gmail.com  Sun Dec 20 15:28:07 2015
From: netztier.ch at gmail.com (Marc Luethi)
Date: Sun, 20 Dec 2015 15:28:07 +0100
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
Message-ID: <CALTc+JMKJVFB9gxVESk5zKOgbvs+cURXvZgkUikWvJ=NCCFczg@mail.gmail.com>

Hi all

I suggest to investigate source address selection on the client side,
while closely following name resolution (assuming this is similar to
Windows 2012R2's DA implementation, DNS64 is supposed to be at work, here)
and keeping an eye on the IPv6 routing table.

In your situation, I would presume that the end system ends up with an RFC
4193 address (from the /48 that was initially chosen when DA was set up) on
its *IP-over-HTTPS* tunneling interface (courtesy of the DA implementation)
and a global unicast address  the (W)LAN interface, based on the CPE's RAs.

While things *should* be neat, my experience with Windows 7's way of
picking source addresses was so bad ("longest match" seemed entirely
unheard-of), I eventually gave up using RFC 4193 addresses for my internal
network altogether.

I repeateadely observed Win7 using its global unicast address(es) to access
internal ressources, while stubbornly sticking to te RFC4193 source address
when attempting to talk to addresses on the global IPv6 internet.

cheers
Marc




On 19 December 2015 at 22:37, Kurt Buff <kurt.buff at gmail.com> wrote:

> All,
>
> I ran into an interesting situation some months ago which still
> baffles me, and though I was able to work around it, I expect it will
> happen again.
>
> We implemented MSFT DirectAcess at our company quite some time ago
> (using 2008R2 and Forefront 2010), and it works extremely well.
>
> At least it worked well for everyone until one of the employees got
> his Comcast connection upgraded, and then DirectAccess didn't work for
> that employee any more.
>
> We proved that if he tethered to his cell phone, that would work, and
> if he used an SSL VPN client while on his Comcast connect that would
> work, but DirectAccess would not work at home.
>
> Finally, I discovered that his Comcast-installed router was handing
> our IPv6 addresses on his home LAN. Turning that off enabled
> DirectAccess to work again.
>
> We do not have an assigned IPv6 block from our ISP, though of course
> MSFT OSes use it, and auto-assign themselves addresses, but for now
> we're ignoring it.
>
> Has anyone run into this problem and solved it - not by turning off
> iIPv6 address assignment for the home LAN, but really solved it? If
> so, how did you do that?
>
> Would getting and implementing an IPv6 assignment from our ISP cure
> the problem, or make it worse?
>
> I've found little guidance from MSFT about DirectAccess in an IPv6
> environment, though I admit I haven't been terribly diligent in my
> searches.
>
> Kurt
>



-- 
'Multiple exclamation marks,' he went on, shaking his head, 'are a sure
sign of a diseased mind.'
(Terry Pratchett, in 'Eric').

netztier.ch at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20151220/38cf7147/attachment.html 

From kurt.buff at gmail.com  Sun Dec 20 19:43:39 2015
From: kurt.buff at gmail.com (Kurt Buff)
Date: Sun, 20 Dec 2015 10:43:39 -0800
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <CAFFn+aVHEa3NLV18q2rSC4DTAedm4Z2nCXDLLohL6KUygKBFKg@mail.gmail.com>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
	<CAFFn+aVHEa3NLV18q2rSC4DTAedm4Z2nCXDLLohL6KUygKBFKg@mail.gmail.com>
Message-ID: <CADy1Ce4J8nxbwFu-q8J8AqwTezFu2nQKfq3e1dRYmgqnMuoPvw@mail.gmail.com>

Thanks!


I'll go back to my notes tomorrow in the ticketing system, and see if I can
give more detail.

Failing that, I'm going to see if I can recruit someone to help recreate
the problem - I don't have Comcast myself.

Kurt

On Sat, Dec 19, 2015 at 6:49 PM, Brzozowski, John Jason <jjmb at jjmb.com>
wrote:

> I run the IPv6 program for Comcast.  Let me know how I can help.
>
> Adding my work email so I don't miss these emails.
>
> John
>
> On Saturday, December 19, 2015, Kurt Buff <kurt.buff at gmail.com> wrote:
>
>> All,
>>
>> I ran into an interesting situation some months ago which still
>> baffles me, and though I was able to work around it, I expect it will
>> happen again.
>>
>> We implemented MSFT DirectAcess at our company quite some time ago
>> (using 2008R2 and Forefront 2010), and it works extremely well.
>>
>> At least it worked well for everyone until one of the employees got
>> his Comcast connection upgraded, and then DirectAccess didn't work for
>> that employee any more.
>>
>> We proved that if he tethered to his cell phone, that would work, and
>> if he used an SSL VPN client while on his Comcast connect that would
>> work, but DirectAccess would not work at home.
>>
>> Finally, I discovered that his Comcast-installed router was handing
>> our IPv6 addresses on his home LAN. Turning that off enabled
>> DirectAccess to work again.
>>
>> We do not have an assigned IPv6 block from our ISP, though of course
>> MSFT OSes use it, and auto-assign themselves addresses, but for now
>> we're ignoring it.
>>
>> Has anyone run into this problem and solved it - not by turning off
>> iIPv6 address assignment for the home LAN, but really solved it? If
>> so, how did you do that?
>>
>> Would getting and implementing an IPv6 assignment from our ISP cure
>> the problem, or make it worse?
>>
>> I've found little guidance from MSFT about DirectAccess in an IPv6
>> environment, though I admit I haven't been terribly diligent in my
>> searches.
>>
>> Kurt
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20151220/0eda68ee/attachment.html 

From John_Brzozowski at Cable.Comcast.com  Sun Dec 20 19:47:03 2015
From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John)
Date: Sun, 20 Dec 2015 18:47:03 +0000
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <CADy1Ce4J8nxbwFu-q8J8AqwTezFu2nQKfq3e1dRYmgqnMuoPvw@mail.gmail.com>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
	<CAFFn+aVHEa3NLV18q2rSC4DTAedm4Z2nCXDLLohL6KUygKBFKg@mail.gmail.com>,
	<CADy1Ce4J8nxbwFu-q8J8AqwTezFu2nQKfq3e1dRYmgqnMuoPvw@mail.gmail.com>
Message-ID: <9B0BE61A-A5B9-4BF0-82E1-119FBCC32189@Cable.Comcast.com>

I can help.  Can you send details how to setup the scenario please?  Not only do I have access, I also have a long list of co-workers that are are capable and willing.

John
+1-484-962-0060

On Dec 20, 2015, at 13:43, Kurt Buff <kurt.buff at gmail.com<mailto:kurt.buff at gmail.com>> wrote:

Thanks!


I'll go back to my notes tomorrow in the ticketing system, and see if I can give more detail.

Failing that, I'm going to see if I can recruit someone to help recreate the problem - I don't have Comcast myself.

Kurt

On Sat, Dec 19, 2015 at 6:49 PM, Brzozowski, John Jason <jjmb at jjmb.com<mailto:jjmb at jjmb.com>> wrote:
I run the IPv6 program for Comcast.  Let me know how I can help.

Adding my work email so I don't miss these emails.

John

On Saturday, December 19, 2015, Kurt Buff <kurt.buff at gmail.com<mailto:kurt.buff at gmail.com>> wrote:
All,

I ran into an interesting situation some months ago which still
baffles me, and though I was able to work around it, I expect it will
happen again.

We implemented MSFT DirectAcess at our company quite some time ago
(using 2008R2 and Forefront 2010), and it works extremely well.

At least it worked well for everyone until one of the employees got
his Comcast connection upgraded, and then DirectAccess didn't work for
that employee any more.

We proved that if he tethered to his cell phone, that would work, and
if he used an SSL VPN client while on his Comcast connect that would
work, but DirectAccess would not work at home.

Finally, I discovered that his Comcast-installed router was handing
our IPv6 addresses on his home LAN. Turning that off enabled
DirectAccess to work again.

We do not have an assigned IPv6 block from our ISP, though of course
MSFT OSes use it, and auto-assign themselves addresses, but for now
we're ignoring it.

Has anyone run into this problem and solved it - not by turning off
iIPv6 address assignment for the home LAN, but really solved it? If
so, how did you do that?

Would getting and implementing an IPv6 assignment from our ISP cure
the problem, or make it worse?

I've found little guidance from MSFT about DirectAccess in an IPv6
environment, though I admit I haven't been terribly diligent in my
searches.

Kurt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20151220/471e8e27/attachment.html 

From kurt.buff at gmail.com  Sun Dec 20 19:48:00 2015
From: kurt.buff at gmail.com (Kurt Buff)
Date: Sun, 20 Dec 2015 10:48:00 -0800
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <D29C2D07.62A97%evyncke@cisco.com>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
	<D29C2D07.62A97%evyncke@cisco.com>
Message-ID: <CADy1Ce6c0LE1M57cx2PZLypricV_ML_bWoTYi13NO12sbhtP0Q@mail.gmail.com>

Yes - "our" should read "out" - they were not anything we would hand out,
and ISTR that they were listed on the NIC entries, separately from the
DirectAccess addresses listed in the other ipconfig entries.

Per my earlier statement, I'll either retrieve those settings from the
ticket, or try to recreate.

Kurt

On Sun, Dec 20, 2015 at 1:10 AM, Eric Vyncke (evyncke) <evyncke at cisco.com>
wrote:

> Interesting situation indeed :-)
>
> As we all known, Microsoft DirectAccess uses IPsec over IPv6 (and
> potentially over Teredo or SSL-VPN if the host does not have native IPv6).
> So, if your DirectAccess head-end is dual-stack, it now receives Ipsec
> packets over IPv6 rather than HTTLS or Teredo over IPv4, so, firewall
> settings must be tuned for that.
>
> Now, I am really puzzled by your sentence "his Comcast-installed router
> was handing our IPv6 addresses on his home LAN", is it a typo in 'our'
> rather than 'out' ? It would be interesting to see the
> addresses/prefixes/routes of the failing DirectAccess client as well as
> which IPv6 address.prefix is used by DirectAccess for the
> normally-functionning clients.
>
> -?ric
>
>
> On 19/12/15 22:37, "ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de on
> behalf of Kurt Buff" <ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de
> on behalf of kurt.buff at gmail.com> wrote:
>
> >All,
> >
> >I ran into an interesting situation some months ago which still
> >baffles me, and though I was able to work around it, I expect it will
> >happen again.
> >
> >We implemented MSFT DirectAcess at our company quite some time ago
> >(using 2008R2 and Forefront 2010), and it works extremely well.
> >
> >At least it worked well for everyone until one of the employees got
> >his Comcast connection upgraded, and then DirectAccess didn't work for
> >that employee any more.
> >
> >We proved that if he tethered to his cell phone, that would work, and
> >if he used an SSL VPN client while on his Comcast connect that would
> >work, but DirectAccess would not work at home.
> >
> >Finally, I discovered that his Comcast-installed router was handing
> >our IPv6 addresses on his home LAN. Turning that off enabled
> >DirectAccess to work again.
> >
> >We do not have an assigned IPv6 block from our ISP, though of course
> >MSFT OSes use it, and auto-assign themselves addresses, but for now
> >we're ignoring it.
> >
> >Has anyone run into this problem and solved it - not by turning off
> >iIPv6 address assignment for the home LAN, but really solved it? If
> >so, how did you do that?
> >
> >Would getting and implementing an IPv6 assignment from our ISP cure
> >the problem, or make it worse?
> >
> >I've found little guidance from MSFT about DirectAccess in an IPv6
> >environment, though I admit I haven't been terribly diligent in my
> >searches.
> >
> >Kurt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20151220/3c9eb827/attachment-0001.html 

From kurt.buff at gmail.com  Sun Dec 20 19:49:52 2015
From: kurt.buff at gmail.com (Kurt Buff)
Date: Sun, 20 Dec 2015 10:49:52 -0800
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <CALTc+JMKJVFB9gxVESk5zKOgbvs+cURXvZgkUikWvJ=NCCFczg@mail.gmail.com>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
	<CALTc+JMKJVFB9gxVESk5zKOgbvs+cURXvZgkUikWvJ=NCCFczg@mail.gmail.com>
Message-ID: <CADy1Ce5-rFfBWvL--kdRDKTQZH1bWWQYOEwQLrd9377sR73FeQ@mail.gmail.com>

You may well be onto something - I believe this was a Win7 machine. I'll
try to confirm tomorrow.

On Sun, Dec 20, 2015 at 6:28 AM, Marc Luethi <netztier.ch at gmail.com> wrote:

> Hi all
>
> I suggest to investigate source address selection on the client side,
> while closely following name resolution (assuming this is similar to
> Windows 2012R2's DA implementation, DNS64 is supposed to be at work, here)
> and keeping an eye on the IPv6 routing table.
>
> In your situation, I would presume that the end system ends up with an RFC
> 4193 address (from the /48 that was initially chosen when DA was set up) on
> its *IP-over-HTTPS* tunneling interface (courtesy of the DA
> implementation) and a global unicast address  the (W)LAN interface, based
> on the CPE's RAs.
>
> While things *should* be neat, my experience with Windows 7's way of
> picking source addresses was so bad ("longest match" seemed entirely
> unheard-of), I eventually gave up using RFC 4193 addresses for my internal
> network altogether.
>
> I repeateadely observed Win7 using its global unicast address(es) to
> access internal ressources, while stubbornly sticking to te RFC4193 source
> address when attempting to talk to addresses on the global IPv6 internet.
>
> cheers
> Marc
>
>
>
>
> On 19 December 2015 at 22:37, Kurt Buff <kurt.buff at gmail.com> wrote:
>
>> All,
>>
>> I ran into an interesting situation some months ago which still
>> baffles me, and though I was able to work around it, I expect it will
>> happen again.
>>
>> We implemented MSFT DirectAcess at our company quite some time ago
>> (using 2008R2 and Forefront 2010), and it works extremely well.
>>
>> At least it worked well for everyone until one of the employees got
>> his Comcast connection upgraded, and then DirectAccess didn't work for
>> that employee any more.
>>
>> We proved that if he tethered to his cell phone, that would work, and
>> if he used an SSL VPN client while on his Comcast connect that would
>> work, but DirectAccess would not work at home.
>>
>> Finally, I discovered that his Comcast-installed router was handing
>> our IPv6 addresses on his home LAN. Turning that off enabled
>> DirectAccess to work again.
>>
>> We do not have an assigned IPv6 block from our ISP, though of course
>> MSFT OSes use it, and auto-assign themselves addresses, but for now
>> we're ignoring it.
>>
>> Has anyone run into this problem and solved it - not by turning off
>> iIPv6 address assignment for the home LAN, but really solved it? If
>> so, how did you do that?
>>
>> Would getting and implementing an IPv6 assignment from our ISP cure
>> the problem, or make it worse?
>>
>> I've found little guidance from MSFT about DirectAccess in an IPv6
>> environment, though I admit I haven't been terribly diligent in my
>> searches.
>>
>> Kurt
>>
>
>
>
> --
> 'Multiple exclamation marks,' he went on, shaking his head, 'are a sure
> sign of a diseased mind.'
> (Terry Pratchett, in 'Eric').
>
> netztier.ch at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20151220/b43005ac/attachment.html 

From brian.e.carpenter at gmail.com  Sun Dec 20 19:57:21 2015
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Mon, 21 Dec 2015 07:57:21 +1300
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <CALTc+JMKJVFB9gxVESk5zKOgbvs+cURXvZgkUikWvJ=NCCFczg@mail.gmail.com>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
	<CALTc+JMKJVFB9gxVESk5zKOgbvs+cURXvZgkUikWvJ=NCCFczg@mail.gmail.com>
Message-ID: <5676FA11.4020507@gmail.com>

On 21/12/2015 03:28, Marc Luethi wrote:
> Hi all
> 
> I suggest to investigate source address selection on the client side,
> while closely following name resolution (assuming this is similar to
> Windows 2012R2's DA implementation, DNS64 is supposed to be at work, here)
> and keeping an eye on the IPv6 routing table.
> 
> In your situation, I would presume that the end system ends up with an RFC
> 4193 address (from the /48 that was initially chosen when DA was set up) on
> its *IP-over-HTTPS* tunneling interface (courtesy of the DA implementation)
> and a global unicast address  the (W)LAN interface, based on the CPE's RAs.
> 
> While things *should* be neat, my experience with Windows 7's way of
> picking source addresses was so bad ("longest match" seemed entirely
> unheard-of), I eventually gave up using RFC 4193 addresses for my internal
> network altogether.
> 
> I repeateadely observed Win7 using its global unicast address(es) to access
> internal ressources, while stubbornly sticking to te RFC4193 source address
> when attempting to talk to addresses on the global IPv6 internet.

Yes. Apparently Win8 is up to date in that respect (i.e. follows RFC6724 not
RFC3484). It would be possible to make Win8 misbehave by changing the default
preferences (https://tools.ietf.org/html/rfc6724#section-10.6).

Conversely, it's possible to make Win7 behave correctly by changing its default
policies to conform to RFC6724. I just found the following site that offers a
script (YMMV, I haven't checked it):
https://sites.google.com/site/jrey42/Home/ipv6/prefixpolicies

But if that is the cause of the original issue, maybe switching off the
ULA prefix would be easier, and nicer than switching off IPv6.

    Brian Carpenter


> 
> cheers
> Marc
> 
> 
> 
> 
> On 19 December 2015 at 22:37, Kurt Buff <kurt.buff at gmail.com> wrote:
> 
>> All,
>>
>> I ran into an interesting situation some months ago which still
>> baffles me, and though I was able to work around it, I expect it will
>> happen again.
>>
>> We implemented MSFT DirectAcess at our company quite some time ago
>> (using 2008R2 and Forefront 2010), and it works extremely well.
>>
>> At least it worked well for everyone until one of the employees got
>> his Comcast connection upgraded, and then DirectAccess didn't work for
>> that employee any more.
>>
>> We proved that if he tethered to his cell phone, that would work, and
>> if he used an SSL VPN client while on his Comcast connect that would
>> work, but DirectAccess would not work at home.
>>
>> Finally, I discovered that his Comcast-installed router was handing
>> our IPv6 addresses on his home LAN. Turning that off enabled
>> DirectAccess to work again.
>>
>> We do not have an assigned IPv6 block from our ISP, though of course
>> MSFT OSes use it, and auto-assign themselves addresses, but for now
>> we're ignoring it.
>>
>> Has anyone run into this problem and solved it - not by turning off
>> iIPv6 address assignment for the home LAN, but really solved it? If
>> so, how did you do that?
>>
>> Would getting and implementing an IPv6 assignment from our ISP cure
>> the problem, or make it worse?
>>
>> I've found little guidance from MSFT about DirectAccess in an IPv6
>> environment, though I admit I haven't been terribly diligent in my
>> searches.
>>
>> Kurt
>>
> 
> 
> 

From brian.e.carpenter at gmail.com  Sun Dec 20 20:23:14 2015
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Mon, 21 Dec 2015 08:23:14 +1300
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <5676FA11.4020507@gmail.com>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
	<CALTc+JMKJVFB9gxVESk5zKOgbvs+cURXvZgkUikWvJ=NCCFczg@mail.gmail.com>
	<5676FA11.4020507@gmail.com>
Message-ID: <56770022.1080502@gmail.com>

Just an update: I eyeballed the "PrefixPolicies-Vista78.cmd" script from
https://sites.google.com/site/jrey42/Home/ipv6/prefixpolicies, concluded
that it was safe, and ran it. It apparently works, but I don't have a
ULA setup to test it with.

jrey42 deserves kudos.

Regards
   Brian

On 21/12/2015 07:57, Brian E Carpenter wrote:
> On 21/12/2015 03:28, Marc Luethi wrote:
>> Hi all
>>
>> I suggest to investigate source address selection on the client side,
>> while closely following name resolution (assuming this is similar to
>> Windows 2012R2's DA implementation, DNS64 is supposed to be at work, here)
>> and keeping an eye on the IPv6 routing table.
>>
>> In your situation, I would presume that the end system ends up with an RFC
>> 4193 address (from the /48 that was initially chosen when DA was set up) on
>> its *IP-over-HTTPS* tunneling interface (courtesy of the DA implementation)
>> and a global unicast address  the (W)LAN interface, based on the CPE's RAs.
>>
>> While things *should* be neat, my experience with Windows 7's way of
>> picking source addresses was so bad ("longest match" seemed entirely
>> unheard-of), I eventually gave up using RFC 4193 addresses for my internal
>> network altogether.
>>
>> I repeateadely observed Win7 using its global unicast address(es) to access
>> internal ressources, while stubbornly sticking to te RFC4193 source address
>> when attempting to talk to addresses on the global IPv6 internet.
> 
> Yes. Apparently Win8 is up to date in that respect (i.e. follows RFC6724 not
> RFC3484). It would be possible to make Win8 misbehave by changing the default
> preferences (https://tools.ietf.org/html/rfc6724#section-10.6).
> 
> Conversely, it's possible to make Win7 behave correctly by changing its default
> policies to conform to RFC6724. I just found the following site that offers a
> script (YMMV, I haven't checked it):
> https://sites.google.com/site/jrey42/Home/ipv6/prefixpolicies
> 
> But if that is the cause of the original issue, maybe switching off the
> ULA prefix would be easier, and nicer than switching off IPv6.
> 
>     Brian Carpenter
> 
> 
>>
>> cheers
>> Marc
>>
>>
>>
>>
>> On 19 December 2015 at 22:37, Kurt Buff <kurt.buff at gmail.com> wrote:
>>
>>> All,
>>>
>>> I ran into an interesting situation some months ago which still
>>> baffles me, and though I was able to work around it, I expect it will
>>> happen again.
>>>
>>> We implemented MSFT DirectAcess at our company quite some time ago
>>> (using 2008R2 and Forefront 2010), and it works extremely well.
>>>
>>> At least it worked well for everyone until one of the employees got
>>> his Comcast connection upgraded, and then DirectAccess didn't work for
>>> that employee any more.
>>>
>>> We proved that if he tethered to his cell phone, that would work, and
>>> if he used an SSL VPN client while on his Comcast connect that would
>>> work, but DirectAccess would not work at home.
>>>
>>> Finally, I discovered that his Comcast-installed router was handing
>>> our IPv6 addresses on his home LAN. Turning that off enabled
>>> DirectAccess to work again.
>>>
>>> We do not have an assigned IPv6 block from our ISP, though of course
>>> MSFT OSes use it, and auto-assign themselves addresses, but for now
>>> we're ignoring it.
>>>
>>> Has anyone run into this problem and solved it - not by turning off
>>> iIPv6 address assignment for the home LAN, but really solved it? If
>>> so, how did you do that?
>>>
>>> Would getting and implementing an IPv6 assignment from our ISP cure
>>> the problem, or make it worse?
>>>
>>> I've found little guidance from MSFT about DirectAccess in an IPv6
>>> environment, though I admit I haven't been terribly diligent in my
>>> searches.
>>>
>>> Kurt
>>>
>>
>>
>>

From kurt.buff at gmail.com  Sun Dec 20 20:40:31 2015
From: kurt.buff at gmail.com (Kurt Buff)
Date: Sun, 20 Dec 2015 11:40:31 -0800
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <9B0BE61A-A5B9-4BF0-82E1-119FBCC32189@Cable.Comcast.com>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
	<CAFFn+aVHEa3NLV18q2rSC4DTAedm4Z2nCXDLLohL6KUygKBFKg@mail.gmail.com>
	<CADy1Ce4J8nxbwFu-q8J8AqwTezFu2nQKfq3e1dRYmgqnMuoPvw@mail.gmail.com>
	<9B0BE61A-A5B9-4BF0-82E1-119FBCC32189@Cable.Comcast.com>
Message-ID: <CADy1Ce5W0jTiDPOrSSUMVPk_ZEtj_2Z5casUsniiWDz1Gi4jjg@mail.gmail.com>

Sounds good. I'll see what I can dig up tomorrow.

Kurt

On Sun, Dec 20, 2015 at 10:47 AM, Brzozowski, John <
John_Brzozowski at cable.comcast.com> wrote:

> I can help.  Can you send details how to setup the scenario please?  Not
> only do I have access, I also have a long list of co-workers that are are
> capable and willing.
>
> John
> +1-484-962-0060
>
> On Dec 20, 2015, at 13:43, Kurt Buff <kurt.buff at gmail.com> wrote:
>
> Thanks!
>
>
> I'll go back to my notes tomorrow in the ticketing system, and see if I
> can give more detail.
>
> Failing that, I'm going to see if I can recruit someone to help recreate
> the problem - I don't have Comcast myself.
>
> Kurt
>
> On Sat, Dec 19, 2015 at 6:49 PM, Brzozowski, John Jason <jjmb at jjmb.com>
> wrote:
>
>> I run the IPv6 program for Comcast.  Let me know how I can help.
>>
>> Adding my work email so I don't miss these emails.
>>
>> John
>>
>> On Saturday, December 19, 2015, Kurt Buff <kurt.buff at gmail.com> wrote:
>>
>>> All,
>>>
>>> I ran into an interesting situation some months ago which still
>>> baffles me, and though I was able to work around it, I expect it will
>>> happen again.
>>>
>>> We implemented MSFT DirectAcess at our company quite some time ago
>>> (using 2008R2 and Forefront 2010), and it works extremely well.
>>>
>>> At least it worked well for everyone until one of the employees got
>>> his Comcast connection upgraded, and then DirectAccess didn't work for
>>> that employee any more.
>>>
>>> We proved that if he tethered to his cell phone, that would work, and
>>> if he used an SSL VPN client while on his Comcast connect that would
>>> work, but DirectAccess would not work at home.
>>>
>>> Finally, I discovered that his Comcast-installed router was handing
>>> our IPv6 addresses on his home LAN. Turning that off enabled
>>> DirectAccess to work again.
>>>
>>> We do not have an assigned IPv6 block from our ISP, though of course
>>> MSFT OSes use it, and auto-assign themselves addresses, but for now
>>> we're ignoring it.
>>>
>>> Has anyone run into this problem and solved it - not by turning off
>>> iIPv6 address assignment for the home LAN, but really solved it? If
>>> so, how did you do that?
>>>
>>> Would getting and implementing an IPv6 assignment from our ISP cure
>>> the problem, or make it worse?
>>>
>>> I've found little guidance from MSFT about DirectAccess in an IPv6
>>> environment, though I admit I haven't been terribly diligent in my
>>> searches.
>>>
>>> Kurt
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20151220/2e28be86/attachment-0001.html 

From tony at lavanauts.org  Sun Dec 20 21:06:35 2015
From: tony at lavanauts.org (Antonio Querubin)
Date: Sun, 20 Dec 2015 10:06:35 -1000 (HST)
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <5676FA11.4020507@gmail.com>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
	<CALTc+JMKJVFB9gxVESk5zKOgbvs+cURXvZgkUikWvJ=NCCFczg@mail.gmail.com>
	<5676FA11.4020507@gmail.com>
Message-ID: <alpine.DEB.2.10.1512200956500.9212@sol>

On Mon, 21 Dec 2015, Brian E Carpenter wrote:

> Yes. Apparently Win8 is up to date in that respect (i.e. follows RFC6724 not
> RFC3484). It would be possible to make Win8 misbehave by changing the default
> preferences (https://tools.ietf.org/html/rfc6724#section-10.6).
>
> Conversely, it's possible to make Win7 behave correctly by changing its default
> policies to conform to RFC6724. I just found the following site that offers a
> script (YMMV, I haven't checked it):
> https://sites.google.com/site/jrey42/Home/ipv6/prefixpolicies
>
> But if that is the cause of the original issue, maybe switching off the
> ULA prefix would be easier, and nicer than switching off IPv6.

Anybody from MS know whether there's a planned official patch for Win7? 
Turning on IPv6 on a network with many Win7 systems might result in IPv6 
being turned off with extreme prejudice :)

Antonio Querubin
e-mail:  tony at lavanauts.org
xmpp:  antonioquerubin at gmail.com

From joachim at tingvold.com  Mon Dec 21 00:27:32 2015
From: joachim at tingvold.com (Joachim Tingvold)
Date: Mon, 21 Dec 2015 00:27:32 +0100
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
Message-ID: <E35D46C4-8FD1-41C7-A34B-88B266839FFA@tingvold.com>

On 19 Dec 2015, at 22:37, Kurt Buff wrote:
> Has anyone run into this problem and solved it - not by turning off
> iIPv6 address assignment for the home LAN, but really solved it? If
> so, how did you do that?

Hi,

Disclaimer; my knowledge of DA's inner workings is almost non-existent.

I had this issue as a user some years back at the company I work for. I 
had "native" (tunneled) IPv6 at home, and DA would not work. If I 
disabled IPv6 (either on my machine, or on my router), DA started 
working immediately.

It turned out that the FQDN used as the DA-endpoint (the destination 
where the client tries to establish the tunnel) had ULA as it's 
AAAA-record. When I confronted our DA-guy with this, he told me that it 
used to be in the official documentation from Microsoft to use ULA. I 
never actually cared enough to try looking it up (so I cannot say if it 
was real or not, or if it was misconfiguration regarding split-DNS), but 
in any case removing the AAAA-record (from the external DNS) solved the 
issue.

You can find the FQDN by issuing "netsh int teredo show state" or "netsh 
int httpstunnel show interfaces" in cmd. Do a lookup on it, and if there 
is no AAAA-record, the prefix policies that's been discussed might be 
the issue.

-- 
Joachim

From kurt.buff at gmail.com  Tue Dec 22 02:25:54 2015
From: kurt.buff at gmail.com (Kurt Buff)
Date: Mon, 21 Dec 2015 17:25:54 -0800
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
Message-ID: <CADy1Ce5Wod0MDrg3u0Yz3Br8wj6fa5guY_eWhyvzhZtQJgdtyg@mail.gmail.com>

All,

Just a quick update - I sent some details of the client config to John
Brzozowski offlist just now.

Brian's info sounds reasonable, and I'm willing to bet that's what is the
root cause, but I'm going to wait for John to have his say, and we'll see
what comes of that.

Thanks for the feedback everyone, and I'll keep the list posted with any
results.

Kurt



On Sat, Dec 19, 2015 at 1:37 PM, Kurt Buff <kurt.buff at gmail.com> wrote:

> All,
>
> I ran into an interesting situation some months ago which still
> baffles me, and though I was able to work around it, I expect it will
> happen again.
>
> We implemented MSFT DirectAcess at our company quite some time ago
> (using 2008R2 and Forefront 2010), and it works extremely well.
>
> At least it worked well for everyone until one of the employees got
> his Comcast connection upgraded, and then DirectAccess didn't work for
> that employee any more.
>
> We proved that if he tethered to his cell phone, that would work, and
> if he used an SSL VPN client while on his Comcast connect that would
> work, but DirectAccess would not work at home.
>
> Finally, I discovered that his Comcast-installed router was handing
> our IPv6 addresses on his home LAN. Turning that off enabled
> DirectAccess to work again.
>
> We do not have an assigned IPv6 block from our ISP, though of course
> MSFT OSes use it, and auto-assign themselves addresses, but for now
> we're ignoring it.
>
> Has anyone run into this problem and solved it - not by turning off
> iIPv6 address assignment for the home LAN, but really solved it? If
> so, how did you do that?
>
> Would getting and implementing an IPv6 assignment from our ISP cure
> the problem, or make it worse?
>
> I've found little guidance from MSFT about DirectAccess in an IPv6
> environment, though I admit I haven't been terribly diligent in my
> searches.
>
> Kurt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20151221/1e0de275/attachment.html 

From seth.mos at dds.nl  Wed Dec 23 11:54:00 2015
From: seth.mos at dds.nl (Seth Mos)
Date: Wed, 23 Dec 2015 11:54:00 +0100
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
Message-ID: <567A7D48.80101@dds.nl>

Op 19-12-2015 om 22:37 schreef Kurt Buff:
> All,
> 
> I ran into an interesting situation some months ago which still
> baffles me, and though I was able to work around it, I expect it will
> happen again.
> 

> Has anyone run into this problem and solved it - not by turning off
> iIPv6 address assignment for the home LAN, but really solved it? If
> so, how did you do that?

We use OpenVPN on pfSense with Viscosity on the clients, or the Android
OpenVPN app. It is a complete Dual-Stack solution for both the servers
and the clients, and because we push more specific IPv6 routes it takes
precedence of the default route as intended. We've been using this for
almost 2 years now on a variation of Windows and MacOS as well as some
phones. It works well.

We use mostly UDP on 1194, unless it's a really crappy hotel wifi and
they use the TCP 443 to get around silly firewalls.

Kind regards,

Seth


From p.mayers at imperial.ac.uk  Wed Dec 23 12:13:01 2015
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Wed, 23 Dec 2015 11:13:01 +0000
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <567A7D48.80101@dds.nl>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
	<567A7D48.80101@dds.nl>
Message-ID: <567A81BD.5070002@imperial.ac.uk>

On 23/12/15 10:54, Seth Mos wrote:

> We use OpenVPN on pfSense with Viscosity on the clients, or the Android
> OpenVPN app. It is a complete Dual-Stack solution for both the servers
> and the clients, and because we push more specific IPv6 routes it takes

What happens if the client has no local, non-VPN IPv6 traffic? Doesn't 
it break things, because even though you're pushing more-specifics, the 
device now thinks it has a global IPv6 address and breaks address selection?

From seth.mos at dds.nl  Wed Dec 23 12:40:40 2015
From: seth.mos at dds.nl (Seth Mos)
Date: Wed, 23 Dec 2015 12:40:40 +0100
Subject: Curious situation - not urgent, but I'd like to know more
In-Reply-To: <567A81BD.5070002@imperial.ac.uk>
References: <CADy1Ce6E4ydpOvM1ukG0rvzwc5C7Z=V_M2sK7jC7q408evBALg@mail.gmail.com>
	<567A7D48.80101@dds.nl> <567A81BD.5070002@imperial.ac.uk>
Message-ID: <567A8838.5040101@dds.nl>

Op 23-12-2015 om 12:13 schreef Phil Mayers:
> On 23/12/15 10:54, Seth Mos wrote:
> 
>> We use OpenVPN on pfSense with Viscosity on the clients, or the Android
>> OpenVPN app. It is a complete Dual-Stack solution for both the servers
>> and the clients, and because we push more specific IPv6 routes it takes
> 
> What happens if the client has no local, non-VPN IPv6 traffic? Doesn't
> it break things, because even though you're pushing more-specifics, the
> device now thinks it has a global IPv6 address and breaks address
> selection?
> 

It doesn't have a IPv6 default route,because a no route to host is
immediate you are unlikely to see slow downs.

This is by no means a scientific method, but I've had no complaints either.

Regards,

Seth