Re: IPv6 Dynamic Prefix Problems
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
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
On 2015-12-16 10:40, Jens Link wrote: > Johannes Weberwrites: [..] > 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
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
Johannes Weberwrites: > 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
Johannes Weberwrites: > 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
> > 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
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