Hi James,<br><br><div class="gmail_quote">On Fri, Jun 15, 2012 at 10:10 AM, James A. T. Rice <span dir="ltr"><<a href="mailto:admins@jump.net.uk" target="_blank">admins@jump.net.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cloudfare are the ones with the badly engineered v6, not the rest of the world. You can take steps to make your v6 work correctly, indeed simply aggregating to a /36 or /40 level will likely make your problems go away. Otherwise announcing a /32 covering route will definitely make your problems go away. If necessary, renumbering into PI space might be the long term solution.<br>
</blockquote><div><br></div><div>the /36 or /40 will still be filtered per AS559's policies, so its pointless.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

A "Either accept the routes or carry a default." stance gets us nowhere - there's plenty of reasons, including those I've outlined in my previous email, as to why either of those options are a bad idea in the long run.<br>
</blockquote><div><br></div><div>Carry multiple default routes to all your providers.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For everyones sake, I would ask you to reconsider your position on this. Other operators have managed to do v6 in a way which does not cause these problems. I'm sure you can too.<br></blockquote><div><br></div><div>I totally understand your concerns. We are already doing as much aggregation as we can possible.  We only use 1 subnet per site (we're using /48 for that, so that we don't leak /64's). The attributes might look the same, but they're all originated from separate physical locations with no backbone in-between.</div>
<div><br></div><div>We use two /48's for Anycast, the ones that are often complained about reachability, these are originated from each of our nodes.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

That's bogus. You could say the same that /32 is a valid announcement for<br>
IPv4 table. It doesn't help.<br>
<br></blockquote></div></div></blockquote></blockquote><div><br></div><div>Again, i'm not looking at deaggregating the internet. We're using maximum possible aggregation per our deployments. a /48 is not a end user site, that would usually be considered a /64. We're not asking for /64's to be accepted, nor are we announcing them.</div>
<div><br></div><div>/48 is the generally accepted maximum prefix length visible in the table (and is visible to most major networks today).</div><div><br></div><div>Cheers,</div><div>Tom </div></div>