Why not IPv6 yet

[Michael Sturtz]

I work for a large multi-national corporation.  We have been looking at
IPv6 for over a year but have been stymied in our efforts due to the
"non-end user" restriction on obtaining PI v6 blocks.  We simply cannot
be chained to an ISP for addressing.  We currently own our own portable
/16 in v4 could use even a small allocation of portable v6 space.  The
current policy is a gating factor.  I understand the routing table bloat
issue however if allocations are restricted to multi-national
corporations then it would mitigate he routing table bloat.  I fully
understand the need to aggregate the addresses into as few routes as
possible but business reality is that most large corporations will not
want to be tied to a specific ISP for portable addresses.  
Michael Sturtz

-----Original Message-----
From: Jeroen Massar [mailto:jeroen at unfix.org] 
Sent: Thursday, March 22, 2007 7:00 PM
To: Nick Hilliard
Cc: ipv6-ops at lists.cluenet.de
Subject: Why not IPv6 yet (Re: IPv6 traffic data in Asian networks?)

[
 Operational Note:
   *.a.0.0.1.0.a.2.ip6.arpa SERVFAIL's on tinnie.arin.net
  Reported to ARIN&RIPE&dns-op, lets hope somebody fixes it :) ]


And now for a little enlightening of missing items... (it's not done in
a pretty I know, excuse me for that, it's just me)

Ignore the rant if you have read my others, because I am repeating
myself in this one ;)


Nick Hilliard wrote:
>> Note Google is much more than just a search engine.   They're
innovating
>> in other areas too, and thus getting just one such Google project 
>> that shows a potential benefit to Google would be good.
> 
> GOOG and ${GOOG} companies are advertising resellers with a variety of

> front-ends, mainly search engines.
> 
> Furthermore, for people with native ipv6 or IPv6 tunnels enabled - 
> whether by accident or design - connectivity almost certainly be 
> substantially degraded compared to ipv4 connectivity.
[..]

The main reason for the degraded connectivity is simple, they don't have
an anycasted IPv6 deployment yet, while for IPv4 they do. And for that
portion is amongst others: No real IPv6 Multihoming, No IPv6 Load
Balancer support (at least from most vendors, I only know that F5 do it
f.i., Squid only recently etc)

For that matter GTalk, the voice portion, would probably love IPv6, but
they already have a way around most of the NAT's by poking with STUN
through them.

I have to note that from the networks I use IPv6 the difference between
IPv4 and IPv6, latencywise, is non-existent. Remote networks tend to be
giving issues, but that is why, amongst others, this list exist, to find
the wrong configurations and to fix them up.

> The ipv6 DFZ is hazy and ill-defined; most ISPs don't support it at 
> all; reachability is often poor (ARIN and RIPE are two cases in point 
> where they should both have had sterling v6 connectivity but didn't. 
> That the IETF had serious connectivity problems is inexcusable);

Neustar at first put the IETF, wrongly, in their Critical Infrastructure
block, but as that was filtered out by a lot of people, and thus it had
connectivity issues. Neustar was not the problem here, remote
ISP/transits's where. These problems have been resolved now though, also
because Neustar, after asking them why IETF wrongly was in their CI
block, moved them to their /32. (As I mentioned in another mail...)

Thanks to a lot of participants on this list for solving these issues!

> we still have crazy-assed networks providing transit to everyone (not 
> going to mention any names here, but we all know some notorious 
> candidates)

If you don't like them, you, as a network operator have two options:
 a) Complain to them so that they finally fix it
 b) Filter them at BGP level
 c) Filter them at packetlevel (do return ICMP Admin Unreach then)

Just a note, I don't have enable on anything but AS8298, therefor I
complain to people and I do that a lot, and it seems to work really well
because over time, the people who are willing have fixed a lot and
together with a couple of other people who have been looking for
problems and contacting folks the network has become much and much
better. Good communication and relations is a key here too.
Unfortunately some networks don't have enough manpower, or interest in
fixing up problems even though they get pointed at often enough that
they are a problem. Fortunately some are cleaning up their messes :) It
will all gradually become fine, just takes a little bit of time and
getting used too...

> and sloppy network management practices in the far east where 
> commercial and NREN networks are not properly distinguished,

Since when are the US and Europe in the Far East? Unless you are looking
from an Asian point of view of course. Those NREN's are properly
distinguishing traffic between NREN and commercial. The only big issue
is that when you are in a commercial network that you are not going over
the GEANT or Abilene network in a lot of cases to reach the NREN in
question, which means you are taking transit to get there. Apparently it
is their policy to do so, the world would be (IMHO) much better if those
big REN-transits would allow commercial<->NRENtransit<->NREN traffic
also to be carried, routes to NRENs would then definitely become much
better.

The problem that I originally mentioned in this message, is that a lot
of US&European networks don't have a good transit provider which gives
them proper routes to the US. (Indeed you can get native IPv6 all the
way to Asia from a certain 3 letter acronym transit :)

> causing all sorts of weird-ass connectivity problems, and packets from

> points A and B in Europe being routed through Seoul and Beijing.

Sorry, but what has Asia to do with some ISP in Europe not being able to
buy a good transit service and thus using some poor Asian provider, who
indeed has configured transit for $world, to send it back to Europe for
him. Most of that blame lies with AS6939 as has been for years who have
been doing this practice. Of course nobody is forcing them to be used
and the ones who do simply should get a real transit.

<slag>

Quoting the magic quote from http://www.he.net/colo_ipv6.html
8<----------------------
Hurricane Electric is aggressively pursuing peering with all existing
IPv6 networks. Currently, our IPv6 routing is immeasurably superior to
other existing companies. Our routing table has more prefixes (routes)
and more paths to each prefix (ways to get to a destination address
block) than most other IPv6 providers. IPv6 BGP4+ peering is done via
tunnels over IPv4 and direct native IPv6 connections. Ultimately all
tunnel peering will be migrated to direct connections.
----------------------------->8

Indeed "immeasurably superior", because one can't measure broken
connectivity... Towards www.cernet2.net for instance:

 7  xe-1-4.r05.asbnva01.us.bb.gin.ntt.net (2001:418:0:2000::f2)  110.965
ms  109.397 ms  109.977 ms
 8  ash.ipv6.he.net (2001:504:0:2::6939:1)  191.989 ms  192.464 ms
190.967 ms
 9  2001:470:0:9::1 (2001:470:0:9::1)  191.991 ms  191.459 ms  191.979
ms 10  * *

Not even talking about:
grh.sixxs.net> show bgp 3ffe::/24
BGP routing table entry for 3ffe::/24
Paths: (25 available, best #3, table Default-IP-Routing-Table)
  Not advertised to any peer
  13645 6939 4555

24 paths end in 6939 4555, there is something to be said of course for
the originator and everybody who still accepts it too and still peers
with that ASN. Also 6939 would be cool if they would enable IPv6 for
instance in Amsterdam and peer with the rest of the world natively, but
unfortunately they don't even though they are "Ranked Top Ten in the
World" (http://he.net/releases/release103.html)

The other path is "8978 5609 4555" note that that is 5609, CSELT, Italy
and then a huge hop across the ocean to EP.net.

But enough bashing them in this email, there are other culprits too.

I would personally really like it if AS6939 cleaned up their tunnels.
Better no connectivity than broken connectivity. And YES I did report
this and various other things to them but clearly nobody cares there.
After so many years of brokenness a little slagging is allowed IMHO.

</slag>

> And we're talking about the merits of enabling AAAA for the top most 
> visited sites in the world?  How crazy is that?

Not so crazy as there are enough networks which have already done it and
they are not seeing any issues at all.

> We also still have no v6 PI.

We don't? http://www.arin.net/registration/templates/v6-end-user.txt
What is that URL then? It's dated July 2006. Check GRH for the amount of
allocations already given out, then look when they where given out, and
then take a look at how many are actually announced. Is it thus needed?
Clearly not, as even though companies get them they don't use them.


That the RIPE region can't formulate a proper way tsja. Apparently the
only push at the moment is to throw out the 200 rule and giving
everybody who wants then a /32, not because they need it, but because it
is more fun to do, or something silly which I still don't understand.
And clearly nobody else, otherwise they could have answered my questions
I asked for on the mailing list.

I am fine using my providers address space, they are very capable of
running stuff like routers 24/7. But if I where in a dire need for "IPv6
PI" (every body wants a slot in the routing table it seems) then I would
have long ago proposed a new policy at RIPE. Clearly nobody who has this
huge need for IPv6 PI has done so yet. And really, big ISP's can't care
less about doing it for you, if you want it, do it yourself.

> We have virtually no v6 on the last mile, and even less on the CPE
side of things.

DOCSIS 3.0 is coming soon (they claim), for the rest DSL can do native
IPv6 (I have it already for 2 years or so), there is PPPv6 which works
fine according to quite a number of ISP's too. In the Asian region there
are a lot of services.

See: http://www.sixxs.net/faq/connectivity/?faq=native for a long list.

If your last mile doesn't support it, then you can always go to the
fellows from Hexago and get a cool transition box. And of course there
is always SixXS who can help you out. Lastly, 6to4 + Teredo and never
forget: ISATAP.

> And we still have almost all
> of the problems that we discuss regularly on this mailing list - 
> broken routers, silly filtering policies that go unnoticed for months,

> and so on and so forth.

Those "silly filtering policies" are because of /48's, you know for PI.
Did you pay attention here, clearly not as you mentioned a couple of
lines above this one there is no IPv6 PI... /me donates coffee :)

> Look, outside a few very specific examples, IPv6 is a plaything right 
> now[1].

Quite a bad example, see below.

> [..] There is no commercial requirement for it

For a lot of companies there is a HUGE commercial requirement.
This is a global list, which means there are a lot of people on the list
who also have business in the US. That means they are doing work for the
US Government, who give them a lot of money. If your network toy doesn't
play along with IPv6 you don't get that money. Is that a big enough
commercial requirement for you? There are other examples too of course.

Also, even though this is not the case there are a lot of networks who
don't treat IPv6 as a toy part of their network, maybe you do, a lot of
operators don't. Thanks to all the people who DO care btw!

[..points..]

All these points have been made before by other people and are very well
understood. Also see above for most of the answers to your questions.

[..]

> [1] see the comcast talk on http://www.nanog.org/mtg-0606/durand.html
> for pretty much the only good example I've ever seen about why ipv6 
> should be deployed on a particular service provider's network.

Ehmm.. clearly you don't know WHY they are going to deploy it ;) Not for
the enduser, but for their own management infrastructure as they
couldn't get any more addresses from ARIN as they could not justify
them. If they could justify them then ARIN would have a hard time
getting 6x IPv4 /8 for them but it can be done, that address space is
still left in the pool. But in justifying that, having a prognosis and
nice trend lines is not good enough. For IPv6 it is easy: you just get
it. And what did Comcast get? 2001:558::/32 (allocated in 2003, still
not announced yet), good for 65k /48's or 268m /60's. According to
current allocation rules though they could only fill up 65k endsites
with that though. Comcast is one of those ISP's that if they wanted to
give IPv6 for endsites that they end up getting: 20m customers * /48 is
a IPv6 /24, which is why an ISP like Softbank (jp) got a /20 ;) Justify
it and get it, that is the rule.

</ipv6'ing 101>

Greets,
 Jeroen
  (steps off your toes, it is not meant to hurt, excuse if it does)