<div id="compose" contenteditable="true" style="padding-left: 20px; padding-right: 20px; padding-bottom: 8px;">Very succulent description. It still doesn't explain why host behind CPE gets two different default gateways as Andrew is reporting. </div><div id="compose" contenteditable="true" style="padding-left: 20px; padding-right: 20px; padding-bottom: 8px;">Unless in reality, between provisioning the various LAN-side /64s (or some other yet to be identified event), the link local address of the LAN interface changes. </div><div id="compose" contenteditable="true" style="padding-left: 20px; padding-right: 20px; padding-bottom: 8px;"><br></div><div id="compose" contenteditable="true" style="padding-left: 20px; padding-right: 20px; padding-bottom: 8px;">Static Prefix will fix the problem of reachability due to an no-longer valid prefix. The different default gateways issue will still be present. Right?</div><div id="compose" contenteditable="true" style="padding-left: 20px; padding-right: 20px; padding-bottom: 8px;"><br></div><div id="compose" contenteditable="true" style="padding-left: 20px; padding-right: 20px; padding-bottom: 8px;"><br></div><div id="compose" contenteditable="true" style="padding-left: 20px; padding-right: 20px; padding-bottom: 8px;"><br></div><div id="compose" contenteditable="true" style="padding-left: 20px; padding-right: 20px; padding-bottom: 8px;"><br></div>
                <div class="gmail_quote">_____________________________<br>From: Jan Zorz <<a dir="ltr" href="mailto:zorz@isoc.org" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="0">zorz@isoc.org</a>><br>Sent: Monday, August 15, 2016 8:35 AM<br>Subject: Re: [afnog] A heads up on a nasty IPv6 bug<br>To: Andrew Alston <<a dir="ltr" href="mailto:andrew.alston@liquidtelecom.com" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="1">andrew.alston@liquidtelecom.com</a>>, Mukom Akong T. <<a dir="ltr" href="mailto:mukom.tamon@gmail.com" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="2">mukom.tamon@gmail.com</a>><br>Cc:  <<a dir="ltr" href="mailto:afnog@afnog.org" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="3">afnog@afnog.org</a>><br><br><br>Hey,<br><br>Yes, this dynamic way of assigning IPv6 PDs is causing much trouble to<br>operators around the world until they decide to swallow the initial pain<br>and change to static PD assignments... ;)<br><br>Please see my comments inline...<br><br>On 14/08/16 16:40, Andrew Alston wrote:<br>> If you are automatically allocating usernames for PPPoE authentication<br>> its relatively simple to tie that username provisioning to static<br>> assignments.<br>> <br>> As an example, if your username ends in a numeric on your auto<br>> provisioning system its relatively simple to use some basic maths and<br>> hex conversion to produce a static subnet that’s tied.<br><br>Yes, usually some math formula is created to tie the PD and username and<br>then the script populates additional field in your radius database and<br>after that - the user always gets the same IPv6 PD "for life".<br><br>If you have multiple aggregation or termination points then some<br>observation is needed prior to this so you can group users on same<br>termination points to have PD from same aggregated prefix, but this is<br>trivial.<br><br>> With regards to the subnet issue on the RA, I’ll respond to that later,<br>> though perhaps Jan would also like to make some comments on this, since<br>> his understanding of it is admittedly better than mine until I do more<br>> testing and labbing<br><br>Ok, let's un-dust the old saying:<br><br>"In theory there is no difference between theory and practice. In<br>practice there is."<br><br>For sake of simplicity, let's say we have only 3 components:<br><br>+--------+       wan +---------+ lan        +-----------+<br>|  ISP   |-----------|   CPE   |------------|   host    |<br>+--------+           +---------+            +-----------+<br><br>ISP can be any access equipment you are using, for example BRAS or<br>anything else.<br><br>CPE has for simplicity just WAN access and LAN segment behind the CPE<br>for home network.<br><br>host is any device that we use on our home network - it can be computer,<br>laptop, tablet, mobile phone, printer - anything that connects to our<br>network and can autoconfigure IPv6.<br><br>Theory:<br>- CPE connects to ISP and gets the Prefix Delegation (PD) from ISP.<br>- ISP installs a route for that PD segment towards the CPE wan interface<br>- CPE provisions /64 out of PD to LAN interface and starts sending out<br>RA (Router Advertisements) packets with prefix information to LAN<br>- host connects to LAN network and sends out na RS (Router Solicitation)<br>packet that is responded by RA packet containing prefix information.<br>- host accepts the packet, generates IPv6 address(es), does the DAD<br>process and if all good - sets up the IPv6 addresses and sets the<br>default route to source IPv6 address of RA message - that is a<br>link-local address of a CPE LAN interface.<br>- now IPv6 traffic can start flowing.<br>- ISP decides that PD must change, or something is wrong with wan link<br>and the PD assignment process restarts (for example pppoe client restarts)<br>- in this event CPE gets a different PD from ISP and need to delete the<br>old IPv6 address from LAN port that is no longer in assigned PD.<br>- ISP installs a route for that PD segment towards the CPE wan interface<br>and removes the route for old PD towards that CPE<br>- CPE adds a new IPv6 address from new /64 from new PD to LAN, deletes<br>the old IPv6 address and sends to LAN link the RA packet with old prefix<br>information with lifetime 0<br>- ISP removes the route<br>- all hosts that receives RA packet with lifetime 0 must remove the old<br>IPv6 address and stop using it.<br>- now we have CPE with new IPv6 PD and all hosts on LAN link with just<br>IPv6 addresses from new PD and world is beautiful and nice and a safe place.<br><br>This was the theory, now let's see some practice and real world - what<br>can go (and will) go wrong?<br><br>We have 2 failure modes here:<br>- host never receives RA packet with lifetime 0 and ends up with IPv6<br>addresses from old and new IPv6 PD<br>- host receives RA packet with lifetime 0, but doesn't care much because<br>it's implemented wrong (and this is happening, given the wide variety of<br>end user devices that are in use on this earth)<br><br>In both cases we end up with a device that has the option of using the<br>wrong IPv6 address as a source address for sent packet.<br><br>Source address selection mechanism is broken in this case and there is<br>an ongoing discussion at IETF how to fix that, but there will be some<br>time before any fix becomes standard and even more time before it's<br>implemented.<br><br>Currently hosts selects the source IPv6 address for packets in quite<br>variety of ways - some randomly, some "address that was last allocated",<br>some of them "first one until it's valid", and all other possible ways,<br>depending on OS and vendor.<br><br>Problem is, that after changing the PD - ISP removed the route back to<br>CPE for that old PD and some of those ISPs that went the "less optimal"<br>path down the IPv6 road and started with dynamic PD assignments did a<br>quick fix to put the old PD in "quarantene" and keep the old route back<br>to CPE for additional 24 hours so all old IPv6 addresses in LAN segment<br>behind the CPE expires and vanishes. This is a quick hack so you get a<br>quazi functional access network and can dedicate your time to start<br>planing a process to make PD assignments properly static (also over BRAS<br>reboots).<br><br>So, this is a pain that many of operators went through and the solution<br>is quite obvious: go with static IPv6 PD assignments. Your help desk<br>will appreciate you.<br><br>Again: "In theory there is no difference between theory and practice. In<br>practice there is."<br><br>I hope I shed some light on the issue with the above explanation.<br><br>See you all in Mauritius for Afrinic-25 where we can discuss IPv6<br>deployment challenges at length ;)<br><br>Cheers and thnx, Jan Zorz<br><br>-- <br>Jan Zorz<br>Internet Society<br>mailto:<<a dir="ltr" href="mailto:zorz@isoc.org" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="5">zorz@isoc.org</a>><br><a dir="ltr" href="http://www.internetsociety.org/deploy360/" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="6">http://www.internetsociety.org/deploy360/</a><br>--<br>"Engineering is always positive in results..." N. Tesla<br><br><br></div>