IPv6 routing /48s

Are there any parties out there routing /48 IPv6 networks globally? I ran
into a supposed Catch-22 with Verizon and IPv6 address space and was
looking for clarification.

We have been delegated a /48 by ARIN. We then went out to procure a
native IPv6 T1 from Verizon (*mainly for testing*). We requested that
Verizon route the /48 that we were provided by ARIN. Verizon's response
was "they do not route network smaller than a /32". Fair enough...
capacity planning for all the /48's would give a router a headache with
today's hardware... so we requested address delegated from Verizon's
larger block of addresses to be used for addressing. The response was
that we could not receive new address space until we returned our ARIN
provided address space... so in effect, go back and get a /32 from ARIN
or give up on ever owning address space again.

ARIN claims they are seeing /48s routed, at least in their route tables. I
have seen some new momentum on the allocation of /32's, don't know if that
is in response to rules like this?? Would be awefully difficult for our
organization to come up with the rationale to need 65K /48s internally to
justify a /32.

revo

We do.

At present, our policy is to route up to /48.

Cheers,

Mark.

There are a bunch of IXPs around who have been announcing /48s for a some
while. From a cursory glance around, it looks like Verizon is unreachable
from these at least AS2128, which announces a single /48. This would seem
to support your sales person's claim.

It will be interesting to see how long this policy lasts - or at least it
will be interesting to see at what stage carriers decide that the loss in
sales revenues hurts more than the cost of carrying /48s from PI delegatin
blocks.

Nick

You may want to post this issue to the ARIN PPML list (see http://www.arin.net/mailing_lists/index.html if you're not already subscribed), as that might be a useful venue for discussion as well.

You're right in noting that this is a catch-22. ARIN and other RIRs are now giving out PI /48s, but there is still a notion that /32 is considered the maximum routable prefix length. However, UCB sees a lot of globally-routed /48s (and /35s, /40s, etc.) in our DFZ routing table. (I also see some /48s disaggregated from a /32 and announced in at least one non-ARIN region, but I am sure this is happening elsewhere. :frowning: ) So, I do think that /48 is beginning to be the new /32 when it comes to prefix filtering, but I can also understand those who want to hold to the more strict IPv6 filtering policies.

I think in the end, we are going to end up generally accepting up to /48s. Basically, we're going to break the routing table anyway--the number of potential /32s is more than enough to do that, and forcing everyone who:

a. needs to be multi-homed; and
b. needs more than 1-2 subnets

to get a /32 has to be a waste, no matter how big the potential address space is overall.

One compromise would be to require that blocks that can be aggregated be aggregated, and then allow PI /48s. In theory, this could be enforced a number of ways, but I am sure we're all aware of how well that works...

michael

Are there any parties out there routing /48 IPv6 networks globally?

Yes. Some particularly visible examples are root and TLD server operators. There are some TLDs which are well-served by IPv6-capable nameservers, but which would be completely invisible to v6-only clients if their covering /48s were not accepted.

ASes which refuse prefixes longer than 32 bits across the board as a matter of policy are broken.

The last time I looked, the RIRs with v6 micro-assignment policies were all doing long-prefix assignments from an easy-to-identify range of addresses. Creating a general-purpose filter which lets through PI /48s but drops PA/deaggregated /48s is not rocket science.

I ran
into a supposed Catch-22 with Verizon and IPv6 address space and was
looking for clarification.

I was once told by another large carrier I was trying to buy from in Miami that "you are not allowed to announce your own addresses in IPv6; you have to use addresses from your upstream".

While the goal of encouraging use of PA addresses and discouraging deaggregation may be noble and good, it seems more education is required in some areas. "There is such a thing as PI in IPv6", for example, and perhaps "just because it's a /48 doesn't mean it's not PI".

Joe

As of June, 2008, at least, AfriNIC was not using a distinct range for these.
There was discussion of converting to this due to these problems.

We have been delegated a /48 by ARIN. We then went out to procure a

     native IPv6 T1 from Verizon (*mainly for testing*). We requested
     that

     Verizon route the /48 that we were provided by ARIN. Verizon's
     response

     was "they do not route network smaller than a /32".

   I wish them good luck in reaching the DNS root servers.
   They are in "critical infrastructure" space, which is a single /32 with
   /48s assigned[1] from that - or something like that.
   IXP space was mentioned.. I'm not sure that needs to be globally
   reachable. Maybe to stop uRPF breaking ICMP messages if routers on the
   exchange respond from their interface address.. though.. I'd prefer to
   make my routers respond from loopback or something.

Owen DeLong wrote:

As of June, 2008, at least, AfriNIC was not using a distinct range for
these.
There was discussion of converting to this due to these problems.

afrinic /48 are out of 2001:43f8::/29

http://www.afrinic.net/Registration/resources.htm

grep -w ipv6 delegated-afrinic-20081118 | grep -w 48
afrinic>TZ>ipv6|2001:43f8::|48|20070711|assigned
afrinic>KE>ipv6|2001:43f8:10::|48|20070713|assigned
afrinic>ZA>ipv6|2001:43f8:20::|48|20070726|assigned
afrinic>ZA>ipv6|2001:43f8:30::|48|20070730|assigned
afrinic>ZA>ipv6|2001:43f8:40::|48|20070921|assigned
afrinic>ZA>ipv6|2001:43f8:50::|48|20071029|assigned
afrinic>KE>ipv6|2001:43f8:60::|48|20080411|assigned
afrinic>NA>ipv6|2001:43f8:80::|48|20081107|assigned

Frank

Nathan Ward wrote:

I'd prefer to
   make my routers respond from loopback or something.

Wouldnt we all...how is that done again?

Let them signup to GRH (http://www.sixxs.net/tools/grh/) then it will be
very easy to see which chunks of the IPv6 routing table they are not seeing.

A /48 is perfectly fine.

Greets,
Jeroen

traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside
701) oh, not working...
traceroute6 to ipv6.google.com from inside 701, oh... not working either.

vzb's v6 table is far from complete :frowning: which is pretty painful.

-chris

And it just reinforces the fear that people have against putting AAAA records in DNS for their publicly-accessible resources, especially www.

michael

Michael Sinatra wrote:

    I wish them good luck in reaching the DNS root servers.
  They are in "critical infrastructure" space, which is a single /32
with

traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside
701) oh, not working...
traceroute6 to ipv6.google.com from inside 701, oh... not working either.

vzb's v6 table is far from complete :frowning: which is pretty painful.

And it just reinforces the fear that people have against putting AAAA
records in DNS for their publicly-accessible resources, especially www.

oddly enough I kind of expect my settlement free upstream to have
somewhat fewer routes than say those tier-2s that I also buy transit from.

if you want v6 adoption... latency, path length, jitter, performance
all should closely match v4 specs. Expecting a US customer to be 'ok'
with 300ms to reach a US site 30 miles (as the crow flies) via
Germany... not good.

V6 so far doesn't have the same $$ and interest from the 'user' so
it's not being optomized yet. Or so it seems.

-chris

Christopher Morrow wrote:

if you want v6 adoption... latency, path length, jitter, performance
all should closely match v4 specs. Expecting a US customer to be 'ok'
with 300ms to reach a US site 30 miles (as the crow flies) via
Germany... not good.

V6 so far doesn't have the same $$ and interest from the 'user' so
it's not being optomized yet. Or so it seems.

Until the peering topology of v6 matches v4, we will continue to see this issue. I expect to wait until the last minute when the NSP's suddenly realize that they need to switch, and as my dual stack peerings increase, so will the QOS. At that point, the content providers will add AAAA and the eyeball networks will have the worst of it. M$ seems to be coming along fine with IPv6, but the problem we'll see is all those modems/routers which do not support it and probably can't with the minimal flash space they have. I haven't even seen good alternatives yet to start pushing my customers into IPv6 routers.

Jack

In a message written on Tue, Nov 18, 2008 at 12:26:36PM -0500, Christopher Morrow wrote:

traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside
701) oh, not working...
traceroute6 to ipv6.google.com from inside 701, oh... not working either.

vzb's v6 table is far from complete :frowning: which is pretty painful.

It's only "Critical Infrastructure", and there's only like 50 of
them now (mostly root servers and CC-Tld's) in the ARIN region.

http://www.arin.net/reference/micro_allocations.html

Note too that they are not all /48's. A lot of people want to
filter the range with le 47 ge 49, and that doesn't work either.
F-Root's covering prefix is a /47, for example.

Michael Sinatra wrote:

    I wish them good luck in reaching the DNS root servers.
  They are in "critical infrastructure" space, which is a single /32
with

traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside
701) oh, not working...
traceroute6 to ipv6.google.com from inside 701, oh... not working either.

vzb's v6 table is far from complete :frowning: which is pretty painful.

And it just reinforces the fear that people have against putting AAAA
records in DNS for their publicly-accessible resources, especially www.

Having no route is not a problem, you should get a destination
unreachable directly and all is fine because IPv4 should be used as a
fallback.

The biggest issue at the moment with IPv6 for endusers is broken DNS
caches/forwarders that just drop AAAA queries and thus let the client
timeout and then optionally fallback to IPv4.

Wikimedia has also been doing tests like the Google one already for some
while, their results are publicly available here:
  http://ipv6and4.labs.wikimedia.org/

Greets,
Jeroen

(notice my usage of 'should' here, because other issues will break
things too :wink:

Leo Bicknell wrote:

In a message written on Tue, Nov 18, 2008 at 12:26:36PM -0500, Christopher Morrow wrote:

traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside
701) oh, not working...
traceroute6 to ipv6.google.com from inside 701, oh... not working either.

vzb's v6 table is far from complete :frowning: which is pretty painful.

It's only "Critical Infrastructure", and there's only like 50 of
them now (mostly root servers and CC-Tld's) in the ARIN region.

And a LOT and LOT more, don't forget the rest of the world please, there
is more than the ARIN region, even if this is the NA-nog list :wink:

Check: http://www.space.net/~gert/RIPE/ipv6-filters.html for a list of
suggested filter expressions that cover all of these correctly.

From Ghost Route Hunter : IPv6 DFP visibility :: SixXS - IPv6 Deployment & Tunnel Broker

    * 1x /13
    * 2x /19
    * 6x /20
    * 4x /21
    * 5x /22
    * 1x /23
    * 2x /24, 13x returned, 45x reclaimed
    * 2x /25
    * 5x /26
    * 4x /27
    * 9x /28, 14x returned, 42x reclaimed
    * 4x /29
    * 5x /30
    * 3x /31, 1x returned
    * 2112x /32, 45x returned, 22x reclaimed
    * 4x /35, 2x returned
    * 2x /40
    * 5x /41
    * 1x /42
    * 2x /43
    * 3x /44, 1x returned
    * 7x /45
    * 7x /46
    * 11x /47
    * 376x /48, 3x returned
    * 5x /64

Not everything is a /32 :wink:

Greets,
Jeroen

of the 1494 entries in the Ipv6 inter-domain routing table that is seen at the Ipv6 route-views router there are 347 /48's (and 1 /56 and 12 /64s, I dunno why)

More details at http://bgp.potaroo.net/v6/as6447/ if anyone is interested

That's not all that's broken at vzb. I've been trying to get them to troubleshoot/fix a possible PMTU problem for weeks now. Everytime I try turning up our tunnel with them we lose http connectivity to various web sites (you can still ping/traceroute the same sites) one of which is isc.org.

Antonio Querubin
whois: AQ7-ARIN