Why not IPv6 yet

JORDI PALET MARTINEZ jordi.palet at consulintel.es
Sat Apr 7 09:11:32 CEST 2007

Hi Michael,

In RIPE NCC you could go, if finally approved, for requesting a /32 under

In ARIN there are a few companies that got a /32. Even if you can consider
PACCAR as end user, I will say that probably you can justify also that you
are an ISP to your organization, and should be able to get from ARIN a PA

There is also in ARIN the /48 IPv6 PI policy, but I think your corporation
clearly qualifies for something bigger.

Feel free to contact me off-line if you want to discuss if and I can try to
see with either ARIN and/or RIPE NCC what are the problem you're having and
making sure you can move ahead.

Of course, same offer is for other people in similar situations. I'm
actually very happy to know about this type of cases, even if I'm not
allowed to disclose them, because it helps me to understand existing
policies problems and even if my policy proposals are good or not.


> De: Michael Sturtz <Michael.Sturtz at PACCAR.com>
> Responder a: <ipv6-ops-bounces+jordi.palet=consulintel.es at lists.cluenet.de>
> Fecha: Fri, 6 Apr 2007 13:48:04 -0700
> Para: <ipv6-ops at lists.cluenet.de>
> Conversación: Why not IPv6 yet
> Asunto: RE: Why not IPv6 yet
> 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. 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)

The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

More information about the ipv6-ops mailing list