Addressing versus Routing (Was: Deploying IPv6 in a datacenter)

Wed Dec 21 19:34:06 UTC 2005

Kevin Day wrote:
[..]

I agree with your point that currently your IPv4-solution can't be
applied to IPv6 but..(see the helpful and nice thingy part at the end ;)

> 1) We've got separate POPs in different cities, with no dedicated
> connectivity between them. They act as entirely independent networks. We
> don't even have the same transit providers in each city. Some content is
> replicated to each POP, so we can dump content directly on peers where
> they want it, or for redundancy. Some content is only available on one
> POP (dynamic sites, etc), so traffic destined for that POP can only go
> to that POP.

> IPv4: We split our /20 into a /23 for each city, and announce only that.

This means you are taking up more routing slots. -> note the routing.

The 'problem' here is that we call these allocations "IPv6 Address
Space", not "xxx Routing Space". RIR's provide Address Space and do not
guarantee routability in any way. Hence the subject.

This is actually a more fundamental problem in the current IP ideology
than anything else.

> IPv6: We have to announce the entire /44, and aren't allowed to
> deaggregate it.

Well, that is actually not true, you can also, in IPv6, simply announce
/48's from a /32 or /44 or whatever. The same way you do that in IPv4.

The issue with announcing say a /48 is though that networks which filter
will filter it out and will only reach you over the aggregate. Of course
that is their choice, just like yours is to try to announce the /48's in
IPv6, or the /23's for IPv4. An IPv4 /28 doesn't reach far either.

The problem here is though that your /48 will propagate through ISP's
with less strict filters and they will act as transits for your /48.
My experience tells that the ones not filtering also have a not so-good
setup thus your connectivity tends to go all around the world.

<SNIP>

> 2) We use anycast to select the closest server on our network to a
> viewer, anycasted DNS for quicker lookups, and a few other anycast
> services.
> 
> IPv4: We have a /24 dedicated for anycast, and announce that block in
> each city.
> 
> IPv6: ??? I honestly have no idea how to do this with IPv6, and still
> announce only a single block, without effectively anycasting everything
> we do.

The same as IPv4 announce a /48. Have a fallback /32 for folks who do
filter it out.

> 3) We're far past the size where we can renumber every time we change
> transit providers.

Indeed, as you have those _Addresses_ assigned to devices.
The issue you have is routing though.

[..]
> The allocation and advertisement policies work great for small end-sites
> (they get many subnets, and more addresses than they'll ever need), and
> great for large providers (they have no problem justifying the need for
> a /32, and are able to break things up if needed). If you fit somewhere
> between those two though, I don't think the policies really address our
> needs.

Here you say it your self: "Advertisement policies" this is routing
again, which has not much to do with Address Space.

> Small to medium sized hosting providers, content networks and other
> non-bandwidth-supplying companies generally aren't providing transit to
> others, so they can't get a /32.

You don't have customers?

If you have say 201 customers, who each have a 1U box in a rack you
provide connectivity to, then give each one of them a /48, they are
endsites and maybe that endsite sets up VPN's.

As for the 201, that is what you might want to have once.
Tada current policy fulfilled. NEXT! :)

> They ARE used to being able to
> deaggregate when necessary though, anycast as needed, multihome
[..]

One can deaggregate in IPv6 also, just don't expect it to be accepted.
Just like a /24 won't be accepted by most folks.
Also note that policy _suggests_ that one announces it as a single chunk.

> I completely understand the need to reduce table growth, slow ASN
> allocations and not waste IPv6 space.

Nobody is complaining (yet) about ASN consumption. Also 4-byte ASN's
will solve that issue quite easily, except for the pain of hard/software
upgrades, though these have a much less expected impact than going for IPv6.

> -- Kevin
> 
> <waits for flame war to erupt> :)

</me donates his asbestos suite and tin foil hat> :)

The "helpful and nice thingy" part:

Apparently the problem faced here can be put into two parts:

*** Getting IPv6 address space from the RIR's in:
    - /44 chunks for PoPs/sites
    - /48 for anycast

 This Address Space can then be used for giving Addresses to hosts.
 This should not be to difficult to do, except for getting the policy
 spelled out correctly and getting it passed through: politics.
 One thing that should be included here and spelled out in big
 letters: it is Address Space and not a /32, expect it to be filtered.
 Also such blocks should come from one large block, eg a /20 per RIR,
 which makes it easy to exempt them in filters ala the IX blocks etc.

 Of course it might well be that for the forseeable future ISP's will
 be lenient in accepting prefixes upto a /48.

 This would be sort of similar to:
   http://www.arin.net/reference/micro_allocations.html

*** Multihoming / Route announcement trick that doesn't fill up slots

 This is the very hard part. (political and technical)
 But it might be years before we will hit the actual limits of BGP.
 We still have to be nice to our kids though as they will hit it ;)

 Currently I am aware of the following possible 'solutions':
 - SHIM6
 - SCTP
 - HIP
 - NOID
 - WIMP
 See:
  draft-huston-multi6-proposals
  draft-savola-multi6-nowwhat

 Most if not all of these have problems for some uses, eg Traffic
 Engineering is supposedly not possible anymore the way it is
 currently being done in BGP. Mindset changes will be required.

 Here is the area that needs attention.
 Only way to get that going is to currently either 'just do it' or
 get along in the train with the SHIM6 folks and help them out to
 make it the way you might want to see it.

Greets,
 Jeroen
   (already caught a nasty cold so come on with
    those flaming arguments to heat me up ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 238 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20051221/d23ab506/attachment.sig>