Re: IPv6 Dynamic Prefix Problems

[Gert Doering]

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 AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279


pgpXPKkzPNj8T.pgp
Description: PGP signature

Re: IPv6 Dynamic Prefix Problems

[Holger Zuleger]

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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: IPv6 Dynamic Prefix Problems

[Jeroen Massar]

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

Re: IPv6 Dynamic Prefix Problems

[Gert Doering]

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 AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

Re: IPv6 Dynamic Prefix Problems

[Jens Link]

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

Re: IPv6 Dynamic Prefix Problems

[Bjørn Mork]

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

Re: IPv6 Dynamic Prefix Problems

[sthaug]

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

Re: IPv6 Dynamic Prefix Problems

[Gert Doering]

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  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 AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279