Mailing List Archive

Johannes Weber <johannes@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@quux.de | --------------- |
----------------------------------------------------------------------------

Johannes Weber <johannes@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

> > 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

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

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@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

On 2015-12-16 10:40, Jens Link wrote:
> Johannes Weber <johannes@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

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

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

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

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

Johannes Weber <johannes@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