IPV6 route registries

[Michael Sinatra]

Hi Brian:

On 09/14/11 15:03, Brian E Carpenter wrote:

> 2. For serious enterprise networks, renumbering still needs work (see RFC 5887).
> That work is starting, please join in: http://datatracker.ietf.org/wg/6renum/charter/
> The more operator input we have into that work, the better.

I took a look a the 6RENUM charter.  This "out-of-scope" part of the 
charter bugs me a bit:

> 3. ISP renumbering; this is potentially the most complex renumbering
> case. However, more benefit can be achieved by focusing effort on site
> renumbering. The enterprise site analysis should include the ISP's role
> in the site's renumbering events.

A huge chunk of the IPv4 table bloat is not coming from end sites 
announcing their multi-homed networks via BGP.[1,2]  A lot of v4 table 
bloat is caused by SPs that aren't able/willing to aggregate, either 
because they got their fragmented prefixes over many years or they 
acquired other providers and couldn't aggregate their prefixes (but 
still wanted the address space).

So far, most of the IPv6 renumbering effort has focused on end-sites. 
But in IPv4, there's a lot of theoretical ground to be gained by 
renumbering service providers, *in addition to* end sites.

I can imagine end sites looking askance at SPs who appear to keep 
focusing on site renumbering and ignoring the thorny, but important 
issue of SP renumbering.  As long as the costs appear skewed toward the 
end-sites, even if they are low, you're not going to get a whole lot of 
sites choosing end-site renumbering over BGP multihoming.  That's partly 
because the renumbering question only deals with the 
renumbering-avoidance motivation for BGP multihoming; the 6RENUM WG 
doesn't seem to delve into the fault-tolerance that is gained by the 
instantaneous failover that BGP multihoming provides.

Looks like interesting work, though, and I will take a closer look.

michael*

*speaking for myself, noting that I currently work at an ISP.


[1] See http://www.cidr-report.org/
[2] RAS's presentation at NANOG 50 was pretty good at going through the 
issues and not pointing (too many) fingers: 
http://www.nanog.org/meetings/nanog50/presentations/Monday/NANOG50.Talk49.Steenbergen.routingtable.pdf