Subject: Will IPv4 be formally deprecated when IPv6 is good enough ?

From: Mark Smith <[email-masked]>
Date: Tue, 14 Oct 2003 23:43:36 +0930

Hi,

A recent discussion came up on the ipv6 mailing list regarding why the market picked up IPv4 NAT, initially asked by Geoff Huston, and posted to the list by Pekka Savola.

Archives of the discussion are available at 

http://marc.theaimsgroup.com/?l=ipng&m=106389565013129&w=2

and

http://marc.theaimsgroup.com/?l=ipng&m=106442112224359&w=2

A little later, it occured to me that maybe what the market might be missing is a statement from the IETF, IESG and/or IAB, that IPv6 is now *ready*, and can be deployed in production via the available transition mechanisms, slowly replacing IPv4 (+ NAT). Maybe the market is really just waiting for the engineers behind IPv6 to say "it's basically finished, its now ready for you to use, pending your applications being ported".

Having a brief look at the list of IPng requirements in rfc1752, it would appear to me, with my limited knowledge of all the IPv6 development that has occured, that most of the goals have been met :

"6.1 The IPng Technical Criteria document

   The criteria described in this document include: (from Kasten94)

   * complete specification - The proposal must completely describe the
     proposed protocol.  We must select an IPng by referencing specific
     documents, not to future work.
   * architectural simplicity - The IP-layer protocol should be as
     simple as possible with functions located elsewhere that are more
     appropriately performed at protocol layers other than the IP layer.
   * scale - The IPng Protocol must allow identifying and addressing at
     least 10**9 leaf-networks (and preferably much more)
   * topological flexibility - The routing architecture and protocols
     ofIPng must allow for many different network topologies.  They must
     not assume that the network's physical structure is a tree.
   * performance - A state of the art, commercial grade router must be
     able to process and forward IPng traffic at speeds capable of fully
     utilizing common, commercially available, high-speed media at the
     time.
   * robust service - The network service and its associated routing and
     control protocols must be robust.
   * transition -  The protocol must have a straightforward transition
     plan from IPv4.
   * media independence -  The protocol must work across an internetwork
     of many different LAN, MAN, and WAN media, with individual link
     speeds ranging from a ones-of-bits per second to hundreds of
     gigabits per second.
   * datagram service - The protocol must support an unreliable datagram
     delivery service.
   * configuration ease -  The protocol must permit easy and largely
     distributed configuration and operation. Automatic configuration of
     hosts and routers is required.
   * security - IPng must provide a secure network layer.
   * unique names - IPng must assign unique names to all IP-Layer
     objects in the global, ubiquitous, Internet.  These names may or
     may not have any location, topology, or routing significance.
   * access to standards -  The protocols that define IPng and its
     associated protocols should be as freely available and
     redistributable as the IPv4 and related RFCs.  There must be no
     specification-related licensing fees for implementing or selling
     IPng software.
   * multicast support - The protocol must support both unicast and
     multicast packet transmission.   Dynamic and automatic routing of
     multicasts is also required.
   * extensibility -  The protocol must be extensible; it must be able
     to evolve to meet the future service needs of the Internet. This
     evolution must be achievable without requiring network-wide
     software upgrades.
   * service classes - The protocol must allow network devices to
     associate packets with particular service classes and provide them
     with the  services specified by those classes.
   * mobility - The protocol must support mobile hosts, networks and
     internetworks.
   * control protocol - The protocol must include elementary support for
     testing and debugging networks. (e.g., ping and traceroute)
   * tunneling support -  IPng must allow users to build private
     internetworks on top of the basic Internet Infrastructure.  Both
     private IP-based internetworks and private non-IP-based (e.g., CLNP
     or AppleTalk) internetworks must be supported."

That brings to my mind two questions

a) Is IPv4 going to be formally deprecated when IPv6 is good enough? If so, are the related IPv4 NAT RFCs also going to be deprecated at that time ?

b) Is IPv6 good enough yet ?

Thanks,
Mark.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mans Nilsson <[email-masked]>
Date: Tue, 14 Oct 2003 17:32:58 +0200

> a) Is IPv4 going to be formally deprecated when IPv6 is good enough? If so, are the related IPv4 NAT RFCs also going to be deprecated at that time ?

Do not think so. Maybe it is my limited mind, but I find it hard not to keep 
v4 on some boxes. 
 
> b) Is IPv6 good enough yet ?

I think so. There are valid concerns on two things; multihoming and
address allocation procedures. There seems to be strong forces among the 
researchers and vendors advocting that we halt and wait for the
Grail of multihoming while we at the same time work very hard in preventing 
people from getting allocations, to preserve address space and keep
the routing table size down.

I think the address allocation problem is based on v4 habits. v6
is abundant. We need it to be available. Nothing will happen until
people can get real allocations with relative ease, not so easy
that nuisance allocations will occur, but almost. Give every AS
number holder a /32 or something, and watch deployment speed up.

With multihoming, strongly related to above, I suggest people cease
waiting for the Grail and instead adopt the v4 model, aided by the 
limited growth we'd see if people did not have to patch their nets
together using disjunct prefixes.  I believe routing table growth
would be much slower, and there are suggestions I find supportive
of this in some analyses of routing table characteristics, for
example in <http://www.caida.org/outreach/papers/2002/EGR/>:

	"Small ASes (those who originate only a few prefixes into
	the global routing system) do not contribute more than their
	fair share of either route entries or churn to the global
	routing system." 

Thus, if most ASen were able to contain all their hosts within one
single /32 per AS, we would see limited routing table growth for
some years, during which there would be time to develop more
sophisticated routing paradigms, if operational experience dictated
such a need was indeed present.

The key words here are "operational experience". We need to get people 
start using v6 for everyday things. 

-- 
Måns Nilsson         Systems Specialist
+46 70 681 7204         KTHNOC
                        MN1334-RIPE

This TOPS OFF my partygoing experience!  Someone I DON'T LIKE is
talking to me about a HEART-WARMING European film ...

---

From: Fred Baker <[email-masked]>
Date: Tue, 14 Oct 2003 10:19:58 -0700

At 07:13 AM 10/14/2003, Mark Smith wrote:
>A little later, it occured to me that maybe what the market might be 
>missing is a statement from the IETF, IESG and/or IAB, that IPv6 is now 
>*ready*, and can be deployed in production via the available transition 
>mechanisms, slowly replacing IPv4 (+ NAT). Maybe the market is really just 
>waiting for the engineers behind IPv6 to say "it's basically finished, its 
>now ready for you to use, pending your applications being ported".

I personally would be very surprised if either the market is waiting for a 
blessing or IPv4 is deprecated. You might ask yourself whether moving RIP 
to historic (deprecated) and OSPF as "required for implementation in all 
routers"

1058 Routing Information Protocol. C.L. Hedrick. Jun-01-1988. (Format:
      TXT=93285 bytes) (Updated by RFC1388, RFC1723) (Status: HISTORIC)

2328 OSPF Version 2. J. Moy. April 1998. (Format: TXT=447367 bytes)
      (Obsoletes RFC2178) (Also STD0054) (Status: STANDARD)

RFC 1812, section 7.2.1:
    "A router that implements any routing protocol (other than static
    routes) MUST IMPLEMENT OSPF (see Section [7.2.2]).  A router MAY
    implement additional IGPs."

has significantly affected anyone's willingness to configure RIP routing in 
a network. What *has* affected people's willingness to deploy or to do 
application work is a perception of someone else being willing to pay for 
them doing so and belief that it solves a problem they have.

---

From: Carlos Friacas <[email-masked]>
Date: Tue, 14 Oct 2003 18:27:17 +0100 (WEST)

My 2 (euro-)cents:

> a) Is IPv4 going to be formally deprecated when IPv6 is good enough?

No.

> If so, are the related IPv4 NAT RFCs also going to be deprecated at that
> time ?

No.

> b) Is IPv6 good enough yet ?

No. Still a lot of work to be done.

Regards,

./Carlos                                  "Upgrade the Internet! -- Now!"
--------------         [http://www.ip6.fccn.pt]        http://www.fccn.pt
<[email-masked]>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup
FCCN - Fundacao para a Computacao Cientifica Nacional  fax:+351 218472167

 "Internet is just routes (127855/472), naming (millions) and... people!"

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 15 Oct 2003 11:12:59 +0200

On 14 okt 2003, at 16:13, Mark Smith wrote:

> missing is a statement from the IETF, IESG and/or IAB, that IPv6 is 
> now *ready*, and can be deployed in production via the available 
> transition mechanisms, slowly replacing IPv4 (+ NAT). Maybe the market 
> is really just waiting for the engineers behind IPv6 to say "it's 
> basically finished, its now ready for you to use, pending your 
> applications being ported".

But unfortunately, IPv6 _isn't_ ready. See the site local debate. See 
the flowlabel goings-on. See the multihoming problem. I'm not sure what 
the status of DHCPv6 is except that I haven't seen it in the wild 
anywhere yet. And there are no reasonable other ways to dynamically 
find DNS servers in IPv6. That's all protocol stuff. Hopefully all of 
this can be fixed in the not too distant future. But there there is 
another extremely important issue that (in my not so humble opinion) 
must absolutely be fixed before making any such statement: the DNS. It 
is currently impossible to resolve DNS names over IPv6 transport, 
because the roots don't support IPv6 transport, none of the major gTLDs 
supports IPv6 transport and very few, if any, TLDs support IPv6 glue 
records for delegated domains.

I think we need IPv6 roots and at least one significant gTLD that fully 
supports IPv6, so that two IPv6-only sites can resolve each other's 
names and communicate without any IPv4 dependencies. We also need 
IPv6-only hosts to dynamically find DNS servers (or define some site 
anycast DNS addresses that can be hardcoded), have addresses that 
remain present/stable regardless of ISP connectivity. Some good 
multihoming wouldn't suck either, but since most end-users don't 
multihome this doesn't have to be a hard requirement. But with this 
other stuff in place such an announcement would be possible.

>      hosts and routers is required.

This test fails because of lack of dynamic DNS discovery.

>    * mobility - The protocol must support mobile hosts, networks and

Hm...

> If so, are the related IPv4 NAT RFCs also going to be deprecated at 
> that time ?

Would it be a smart move to deprecate something that 100% of the 
systems connected to the internet use?

> b) Is IPv6 good enough yet ?

Not yet... but we're making progress.

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 15 Oct 2003 12:02:50 +0200

-----BEGIN PGP SIGNED MESSAGE-----

Iljitsch van Beijnum wrote:

> the flowlabel goings-on. See the multihoming problem. I'm not 
> sure what the status of DHCPv6 is except that I haven't seen it in the wild 
> anywhere yet.

There is at least a Linux implementation in the wild:
http://sourceforge.net/projects/dhcpv6

And there is a quite-empty page at http://www.dhcpv6.org

> And there are no reasonable other ways to dynamically 
> find DNS servers in IPv6.

I would really like to see a 'default' IP address for DNS.
Anycast comes to mind here btw...

> That's all protocol stuff. Hopefully all of 
> because the roots don't support IPv6 transport, none of the 
> major gTLDs supports IPv6 transport and very few, if any, TLDs
> support IPv6 glue records for delegated domains.

Apparently there is work being done on this, but it is not very public.
We have www.rs.net providing this for some time, but unfortunatly
it has some issues: it doesn't allow 'access' to non-IPv6 capable
domains and there isn't a european part of that deployment; yet, I understood.

> Some good multihoming wouldn't suck either, but since most end-users don't 
> multihome this doesn't have to be a hard requirement

I would really like to see this, but indeed it isn't a showstopper.
It is a requirement for some "hosters" though, but as can be
seen from the TLA allocation lists even 'smaller' ISP's get a TLA
so that should not be a problem either. Basically if one can say
they have 200 clients they have a done deal. Thus the only
requirement for multihoming is for endusers, even if those are
very big organisations. As IPv6 deployment isn't that far (yet)
they probably can't find two uplinks at the moment anyways.

<SNIP>

> Not yet... but we're making progress.

Seeing that usage and traffic at tunnelbrokers is growing I think
it is really catching on. There are two issues though that are
mostly a chicken and egg problem:
 - Hosters don't support it because clients don't have it -> money
 - Clients can't use it because Hosters don't support it.

Client access and for some also hosting is taken care of by
using tunnelbrokers and other transition mechanisms. ISP's
should start enabling IPv6 on their native networks where
possible and start providing servers with IPv6 connectivity.
Then it is at least possible for clients to use it.
RIPE got a big 'awww' when they enabled their whois service
to support IPv6 as to the number of requests that suddenly
started to come in over IPv6 :)

So kick your ISP, access and hosting, to get doing IPv6 and
if the access to that ISP can't provide native IPv6 ask them
to set up a tunnelbroker system, 6to4 relay etc for solving
that problem.

Greets,
 Jeroen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 15 Oct 2003 12:10:39 +0200

> the routing table size down.

A very good property of IPv6 is that we get to avoid some of the 
mistakes that were made with IPv4. One of those mistakes was giving out 
addresses in ways that didn't scale. History teaches us that once 
something like this happens the cats don't want to be herded back into 
the bag, to abuse some metaphors here.

> number holder a /32 or something, and watch deployment speed up.

There are now less than 35000 free AS numbers. If such a policy would 
be adopted there would be a huge land rush, depleting the AS number 
supply and forever polluting the IPv6 routing table with 64000 or so 
routes, most of which don't need to be there. The fact that this also 
uses up 0.0016 percent of the IPv6 address space isn't a significant 
issue, of course.

> such a need was indeed present.

In IPv4 today multihoming is throttled by lack of routable address 
space. Without a /24 you don't get to multihome, and with a /24 - /21 
you're never sure if you're going to be filtered. In IPv6 those would 
all be /48s that everyone can get so it's likely that growth in 
multihoming is going to be higher than what we've seen before. Also 
note that just keeping it below the level of Moore's Law (60% per year) 
isn't enough as routing table processing scales worse than linear at O 
= n.log(n)

Iljitsch van Beijnum

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 15 Oct 2003 13:38:52 +0200

--On Wednesday, October 15, 2003 12:10:39 +0200 Iljitsch van Beijnum
<[email-masked]> wrote:

> A very good property of IPv6 is that we get to avoid some of the mistakes
> that were made with IPv4. One of those mistakes was giving out addresses
> in ways that didn't scale. History teaches us that once something like
> this happens the cats don't want to be herded back into the bag, to abuse
> some metaphors here.

Agree. But: The main problem is that people and organisations in the
sunrise phase were given too small allocations, leading to disjunct
allocations and a mess in the routing table. If we give small organisations
a /32 they won't  need another prefix for the forseeable future. This
"wasteful" policy was not possible in v4, but now it is. So, I concur that
there are things to be learnt from v4. 

> There are now less than 35000 free AS numbers. If such a policy would be
> adopted there would be a huge land rush, depleting the AS number supply
> and forever polluting the IPv6 routing table with 64000 or so routes,
> most of which don't need to be there. The fact that this also uses up
> 0.0016 percent of the IPv6 address space isn't a significant issue, of
> course.

The fix for this is 32-bit AS numbers. Those 35000 ASen will suffice while
we look at multihoming problems and routing table growth. Providing we get
people to use v6 instead of talking about it here -- we can't know unless
we test this, and the experience gained is worth some of the risk. 

-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 15 Oct 2003 14:55:58 +0300 (EEST)

On Wed, 15 Oct 2003, Måns Nilsson wrote:
[...]
> we test this, and the experience gained is worth some of the risk. 

Well, my personal take is that if we need 32-bit AS numbers, we have 
failed.

Failed how?

Failed to produce a multihoming solution for smaller enterprises which
would not need an AS number otherwise, but whose about only (clear) option
is to go and get an AS number for their site multihoming purposes.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 15 Oct 2003 14:04:53 +0200

> is to go and get an AS number for their site multihoming purposes.

I agree. This must be fixed.

---

From: Soohong Daniel Park <[email-masked]>
Date: Wed, 15 Oct 2003 21:36:30 +0900

> to set up a tunnelbroker system, 6to4 relay etc for solving

I guess it is one of v6ops role
ISP design team is trying to propose a valuable thing for us....

Regards

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics

---

From: Bill Manning <[email-masked]>
Date: Wed, 15 Oct 2003 06:00:32 -0700 (PDT)

% > is currently impossible to resolve DNS names over IPv6 transport, 
% > because the roots don't support IPv6 transport, none of the 
% > major gTLDs supports IPv6 transport and very few, if any, TLDs
% > support IPv6 glue records for delegated domains.
% 
% Apparently there is work being done on this, but it is not very public.
% We have www.rs.net providing this for some time, but unfortunatly
% it has some issues: it doesn't allow 'access' to non-IPv6 capable
% domains and there isn't a european part of that deployment; yet, I understood.

	last I checked, sweden was nearly european... :)
	and rs.net has full access to IPv4 only domains as 
	well.
	w/in the rs.net testbed all the roots are native IPv6 enabled
	and there are ~12 TLDs w/ fully IPv6 native servers.
	all of those TLDs support IPv6 registration for domains.

	its not quite as bad as you portray, in the testbed.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Mohsen Souissi <[email-masked]>
Date: Wed, 15 Oct 2003 15:20:10 +0200

On 15 Oct, Jeroen Massar wrote:
[...]
| 
| > That's all protocol stuff. Hopefully all of 
| > this can be fixed in the not too distant future. But there there is 
| > another extremely important issue that (in my not so humble opinion) 
| > must absolutely be fixed before making any such statement: 
| > the DNS. It 
| > is currently impossible to resolve DNS names over IPv6 transport, 
| > because the roots don't support IPv6 transport, none of the 
| > major gTLDs supports IPv6 transport and very few, if any, TLDs
| > support IPv6 glue records for delegated domains.
| 
| Apparently there is work being done on this, but it is not very public.

==> AFNIC (French Registry) has been running an official IPv6-capable
name server (ns3.nic.fr) for fr zone (also secondary for a dozzen of
other TLDs) since November 2001. AFNIC has been officially making
AAA-glue-aware-domain-name-delegations since 1st October 2003 (see the
Press-Release
http://www.afnic.fr/nouvelles/2003/press-release-afnic-ipv6.pdf,
announcement relayed by the IPv6 Task Force mailing-list).  More than
70 fr sub-zones are now served by IPv6-capable (IPv6 transport) name
servers.

| We have www.rs.net providing this for some time, but unfortunatly
| it has some issues: it doesn't allow 'access' to non-IPv6 capable
| domains and there isn't a european part of that deployment; yet, I
| understood.

==> Sounds ver strange... FR zone (it is a European for instance) has
been connected to rs.net (formerly OTDR) for more than one year
now. Both ns[12].dnssec.nic.fr (which are authoritative for FR zone in
rs.net testbed) support both IPv4 and IPv6 transport...

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 15 Oct 2003 17:26:40 +0200

-----BEGIN PGP SIGNED MESSAGE-----

[aggregated mail :)]

<SNIP>

> name server (ns3.nic.fr)

Yup, indeed, sorry I forgot, you have been running it and shouting
about for some time already :)
But did they put your AAAA as glue in the root already?

$ dig @e.root-servers.net ns3.nic.fr any
;; ANSWER SECTION:
ns3.nic.fr.             172800  IN      A       192.134.0.49

There are quite a lot of deployments who run IPv6 transport
capable dns servers, but as long as they are not bound into
the root it has little to no sense.

> rs.net testbed) support both IPv4 and IPv6 transport...

Indeed, for .fr but not for the root :(
What I meant to say that if you use the "IPv6 root" and try to resolve
a domain that only has IPv4 DNS servers, eg .com, currently it works again:

com.                    518400  IN      NS      COM-A.ip4.int.
COM-A.ip4.int.          518400  IN      AAAA    <SNIP>

But it is flaky and doesn't always work unfortunatly.
The not-work part also has to do with the fact that all these
servers reside in the US and not in Europe. I understood that
Daniel Karrenberg was working on that part though...

Soohong Daniel Park wrote:
> Jeroen Massar wrote:

<spam>
We haven't created SixXS for nothing, if an ISP needs a service
as said like above they can come to us and we will, in cooperation
with them set it up. It is a whitelabel tunnelbroker system, no
strings attached, nothing to pay, totally independent, open and
certainly not restricted to europe. </spam>

Jim Bound wrote:
> Reason, if it is to continue then additional input to response
> below would be actual deployment in process that is not waiting
> on the multihome solution specifically Military and Telco
> operations in the market and then there is the Moonv6 US Network
> Pilot in process where 25 vendors are testing products as I type
> this email.  www.moonv6.com

Neat to see such a project, a shame that I, and possibly others
didn't know about it. Speaking of which, isn't there a single
mailinglist/informationsource for finding such projects except
for googling around ofcourse or checking hs247.com but that
doesn't list it either...

Måns Nilsson wrote:
> The fix for this is 32-bit AS numbers. Those 35000 ASen will
> suffice while we look at multihoming problems and routing table
> growth.

IPv4 is 32bits, are we going to do IPv4 between the ASN's then
to keep the routing between ASN's up to scale? 32bit ASN's will
also cause a lot of changes in amongst others BGP and internals
of routers. IMHO I don't think that is the way to go. The way
to go is find a good solution now, there is enough time.

Greets,
 Jeroen

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 15 Oct 2003 17:34:26 +0200

-----BEGIN PGP SIGNED MESSAGE-----

> 	last I checked, sweden was nearly european... :)

Ah so the machine is active, but unfortunatly the routing is
still suboptimal with all routes to the NS's going over the US.
If wanted, I still am willing to sport a Root DNS in holland
for this project, natively connected and such. 300ms on average
is not nice performance IMHO. And it can be much better.

> 	and rs.net has full access to IPv4 only domains as well.

Yes, I just checked it again and indeed it is working.
When that was introduced it was kinda flaky and I got bitten
with some mailbounces due to unknown source domains *whistle*
But that is one of the reasons that it is a testbed

>	its not quite as bad as you portray, in the testbed.

That was a momententary snapshot ofcourse and fortunatly we
are in a moving world that has changed positively :)

Greets,
 Jeroen

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 15 Oct 2003 17:51:20 +0200

> is not nice performance IMHO. And it can be much better.

We are working on that.

- - kurtsi -

---

From: Mohsen Souissi <[email-masked]>
Date: Wed, 15 Oct 2003 18:05:10 +0200

On 15 Oct, Jeroen Massar wrote:
| -----BEGIN PGP SIGNED MESSAGE-----
| 
| [aggregated mail :)]
| 
| Mohsen Souissi [mailto:[email-masked]] wrote:
| 
| > On 15 Oct, Jeroen Massar wrote:
| <SNIP>
| 
| > | Apparently there is work being done on this, but it is not very public.
| > 
| > ==> AFNIC (French Registry) has been running an official IPv6-capable
| > name server (ns3.nic.fr)
| 
| Yup, indeed, sorry I forgot, you have been running it and shouting
| about for some time already :)

==> I'm glad you heard that... ;-)

| But did they put your AAAA as glue in the root already?

==> Unfortunately not yet :-( 

| 
| $ dig @e.root-servers.net ns3.nic.fr any
| ;; ANSWER SECTION:
| ns3.nic.fr.             172800  IN      A       192.134.0.49
| 
| There are quite a lot of deployments who run IPv6 transport
| capable dns servers, but as long as they are not bound into
| the root it has little to no sense.

==> I unfortunately agree with you :-( 

The fact that no TLD's IPv6 glue is registered in the root zone is
rather a layer-9 issue that a layer-7 one.  As far as FR zone is
concerned, we have officially applied for AAAA glue registration that
in Feb 2003. Technical proofs was then given to IANA that there were
no risk in adding AAAA glue in the root zone for FR zone (based on
Draft Vixie & Kato
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-respsize-00.txt)
Although that fact has been acknowledged by IANA and DNS experts, we
are still waiting...  We hope this issue will be solved very soon and
I believe that IPv6 networking will be then much more credible (we
will see real amounts of IPv6 traffic)...

Cheers,

Mohsen.

| 
| > | We have www.rs.net providing this for some time, but unfortunatly
| > | it has some issues: it doesn't allow 'access' to non-IPv6 capable
| > | domains and there isn't a european part of that deployment; yet, I
| > | understood.
| > 
| > ==> Sounds ver strange... FR zone (it is a European for instance) has
| > been connected to rs.net (formerly OTDR) for more than one year
| > now. Both ns[12].dnssec.nic.fr (which are authoritative for FR zone in
| > rs.net testbed) support both IPv4 and IPv6 transport...
| 
| Indeed, for .fr but not for the root :(
| What I meant to say that if you use the "IPv6 root" and try to resolve
| a domain that only has IPv4 DNS servers, eg .com, currently it works again:
| 
| com.                    518400  IN      NS      COM-A.ip4.int.
| COM-A.ip4.int.          518400  IN      AAAA    <SNIP>
| 
| But it is flaky and doesn't always work unfortunatly.
| The not-work part also has to do with the fact that all these
| servers reside in the US and not in Europe. I understood that
| Daniel Karrenberg was working on that part though...
| 
| Soohong Daniel Park wrote:
| > Jeroen Massar wrote:
| > > So kick your ISP, access and hosting, to get doing IPv6 and
| > > if the access to that ISP can't provide native IPv6 ask them
| > > to set up a tunnelbroker system, 6to4 relay etc for solving
| > > that problem.
| > 
| > I guess it is one of v6ops role
| > ISP design team is trying to propose a valuable thing for us....
| 
| <spam>
| We haven't created SixXS for nothing, if an ISP needs a service
| as said like above they can come to us and we will, in cooperation
| with them set it up. It is a whitelabel tunnelbroker system, no
| strings attached, nothing to pay, totally independent, open and
| certainly not restricted to europe. </spam>
| 
| Jim Bound wrote:
| > Reason, if it is to continue then additional input to response
| > below would be actual deployment in process that is not waiting
| > on the multihome solution specifically Military and Telco
| > operations in the market and then there is the Moonv6 US Network
| > Pilot in process where 25 vendors are testing products as I type
| > this email.  www.moonv6.com
| 
| Neat to see such a project, a shame that I, and possibly others
| didn't know about it. Speaking of which, isn't there a single
| mailinglist/informationsource for finding such projects except
| for googling around ofcourse or checking hs247.com but that
| doesn't list it either...
| 
| Måns Nilsson wrote:
| > The fix for this is 32-bit AS numbers. Those 35000 ASen will
| > suffice while we look at multihoming problems and routing table
| > growth.
| 
| IPv4 is 32bits, are we going to do IPv4 between the ASN's then
| to keep the routing between ASN's up to scale? 32bit ASN's will
| also cause a lot of changes in amongst others BGP and internals
| of routers. IMHO I don't think that is the way to go. The way
| to go is find a good solution now, there is enough time.
| 
| Greets,
|  Jeroen
| 
| -----BEGIN PGP SIGNATURE-----
| Version: Unfix PGP for Outlook Alpha 13 Int.
| Comment: Jeroen Massar / [email-masked] / http://unfix.org/~jeroen/
| 
| iQA/AwUBP41nMCmqKFIzPnwjEQL/mQCfaID56o60Hj3llkHpap4IFIXaLG8An2Xg
| YKMZFgtI/iB3eIdSAr3sjj2i
| =s1vg
| -----END PGP SIGNATURE-----