Ipv6 Routing (from hell)

[Steve Bertrand]

...sorry about the long post. I didn't expect for it to go this way, I'm 
just a little out of sorts that I don't have many IPv6 people I can 
relate to.

> Folks are debating about giving such networks one routing slot already 
> (see the PI discussions), doing PI and BGP on those networks either 
> results in internal congestion (announcing a /48 on all ingress points 
> and forwarding the traffic all the way through the mesh to the 
> destination) or deaggregating to possibly hundreds of routing slots for 
> optimized ingress in reasonably sized networks.

Even on the smallest of ISP networks, this would be an administrative 
nightmare.

> And remind you, we are usually talking about dozens of el-cheapo 20 EUR 
> consumer DSL connections to different ISPs in those meshing networks, 
> there is just no way of getting native IPv6 with BGP on there.

We are a small ISP in southern Ontario Canada, and even with our 100Mbps 
LANx connection, can not get native IPv6 from our upstream. The 
temporary solution for the el-cheapos (as you put it) is obviously 
tunneling, but the real fix and long term solution is a massive 
collective vocal "we want IPv6!!" by all of the DSL consumers to their ISPs.

I'm all for IPv6, and this is the first time I've posted, so I may as 
well throw out my .02. Here are my thoughts, with the understanding that 
I've been fortunate enough to have had a very gracious person provide me 
with BGP peering for my /32 over a tunnel...because my upstream can 
not/does not provide native yet. (Believe me..I put pressure on them 
more than once per week).

- resi subs who are IPv6 knowledgeable need to express demand (not just 
desire) for access natively to the IPv6 Internet to their ISP

- commercial subs, and their responsible network ops should be just as 
vocal, if not more

- ISP's who ignore IPv6 and say they will never need it should wake up 
and at least acknowledge that IPv6 is on their doorstep and it needs to 
be looked at

- ISPs who are trying to gain native connectivity but can't, should 
withhold creating non-efficient, non-recommended routing slots. They 
should have a location where their users can express their desire. This 
sub feedback can be fuel for the ISP in need to take to their upstreams 
and start making demands.

Aside from that, this ISP should recommend known, well-established and 
respected tunnel providers that can supply them with a testing bed until 
the ISP themselves are online, and can supply a proper 
[insert-your-RIR-policy-v6-PA-size-block], or accept peering for 
[RIR-policy-PI-block]

If a subscriber is already in tune with the problems of native IPv6 
connectivity, they are most likely to understand an explanation as to 
why they should use an established party for testing (after all, the sub 
is in the EXACT situation the ISP is).

- ISP's that have native connectivity should actively promote it in ways 
that don't take away from their existing marketing strategy, but have 
enough exposure to let others know that they are responsible and are 
attempting to aid in the transition.

I never fathomed the work that the likes of the IETF did before, but 
following some of the mailing lists I have in my slow growth into 
maturity, it blows me away. All of these standard and policy makers work 
so hard to allow the Internet to 'just work'. Many of these people are 
documented in RFC's dated back to when IPv6 was but a concept, and even 
long before that. If you have native connectivity, something that says 
'IPv6 standards compliant' would be great.

 From what I have found, policy at the RIR level does not mix well with 
ops. However, if there are not enough case studies to provide precedence 
for allocation/assignment in the operational level, we may run into 
problems:

- IPv4 runout is causing people to contemplate lengthening acceptable 
prefix (some have even mentioned /29)
- Lack of IPv6 connectivity is causing people to contemplate lengthening 
acceptable prefix (to /64...what next)

If that trend continues, imagine the routing table when both prefixes 
max out, and the absolute chaos trying to shorten the prefixes in the 
years that follow the IPv4 fallout.

It's easy to throw hardware (RAM) at a problem, but just the thought of 
administration of so much routing information makes me think that it 
would be easier for a community of ops to come up with an 'ops' 
perspective that could be parlayed to the respective RIRs as a vote.

These have been just my thoughts. Not right or wrong, just personally 
venting after a long day, and frustrated I don't have the resources to 
do everything myself :)

Steve