<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">All,</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);"> <a href="https://tools.ietf.org/html/rfc5963">https://tools.ietf.org/html/rfc5963</a></span></div><div><span style="background-color: rgba(255, 255, 255, 0);"> <span style="font-weight: bold;">IPv6 Deployment in Internet Exchange Points (IXPs)</span></span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Martin</span></div></div><div><br>On Jan 15, 2018, at 3:52 AM, Nick Hilliard <<a href="mailto:nick@inex.ie">nick@inex.ie</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Nishal Goburdhan wrote:</span><br><blockquote type="cite"><span>ie, when you apply for your next block of IPv4 addresses for your</span><br></blockquote><blockquote type="cite"><span>peering lan, at afrinic, you won’t be getting addresses assigned from</span><br></blockquote><blockquote type="cite"><span>196.223.x, but from 196.60.y. so the “consistency” that you are aiming</span><br></blockquote><blockquote type="cite"><span>for, would be unrealised in the future. unless, of course, you plan to</span><br></blockquote><blockquote type="cite"><span>change your IPv6 addresses at the same time - and that’s a totally</span><br></blockquote><blockquote type="cite"><span>unnecessary pain.</span><br></blockquote><span></span><br><span>Agreed that explicitly tying the IPv6 address to the exact ipv4 address</span><br><span>is something that will bite in future years. We had several iterations</span><br><span>of IPv6 addressing at INEX before we realised that there was no</span><br><span>compelling argument to encode information of any form in ipv6 addresses,</span><br><span>and that doing so would invariable cause problems down the line where</span><br><span>the terms for encoding the information changed, but there wasn't a</span><br><span>compelling reason to renumber the ipv6 address.</span><br><span></span><br><span>In other words, the for anything other than simplest: start off at</span><br><span>address number 0 and increment. We eventually decided to make the</span><br><span>decimal representation of the last ipv4 octet the same as the hex</span><br><span>representation of the last octet in ipv6, i.e.</span><br><span></span><br><span>186.6.36.6 - 2001:7f8:18::6</span><br><span>186.6.36.150 - 2001:7f8:18::150</span><br><span></span><br><span>We considered plenty of other schemas along the way (e.g. ipv4 address</span><br><span>mapping, ASN encoding, and curiously a scheme which guaranteed that each</span><br><span>IPv6 address would end up in a different multicast group for ND</span><br><span>announcements (long story, but there were some nasty bugs in the early</span><br><span>days of Cisco 6500 kit, ouch)).</span><br><span></span><br><span>Obviously, each IXP is different, and you can do whatever you want from</span><br><span>the UI in 4.7.0.</span><br><span></span><br><span>The only encoding that INEX uses in either IPv4 or IPv6 is to reserve</span><br><span>all single-digit addresses for IXP use only (and we didn't even succeed</span><br><span>at this, oops).</span><br><span></span><br><span>Nick</span><br><span>_______________________________________________</span><br><span>INEX IXP Manager mailing list</span><br><span><a href="mailto:ixpmanager@inex.ie">ixpmanager@inex.ie</a></span><br><span><a href="https://www.inex.ie/mailman/listinfo/ixpmanager">https://www.inex.ie/mailman/listinfo/ixpmanager</a></span><br></div></blockquote></body></html>