From steve at ibctech.ca  Fri May  1 15:25:13 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 01 May 2009 09:25:13 -0400
Subject: Domain Registrar recommendation
Message-ID: <49FAF839.9070008@ibctech.ca>

Hi all,

Over the past 10 years or so, I've been dealing with a relatively small
registrar in my local area for my personal domains (canadiandomain.com).
Unfortunately, they can not provide IPv6 glue.

A few months ago, I registered a handful more personal domains (which
are currently idle) at godaddy.com, as apparently they can provide IPv6
glue.

I am going to set up one of the new domains as strictly IPv6 only for
statistics gathering. The point is, is that I haven't 'configured' any
of the domains at GoDaddy yet, so I am not experienced in regards to
their reliability.

Before I migrate my primary domain (ibctech.ca) to a new registrar so I
can have v6 glue, I'm looking for feedback on whether it is advisable to
move it to GoDaddy, or if I should look elsewhere.

I've heard horror stories about GoDaddy domains randomly being shut
down, and it taking weeks of circular dancing in order to justify having
it re-enabled. I can not have that happening. Moreover, I want as smooth
as possible transition

All feedback appreciated.

Steve

From daniel at kewlio.net  Fri May  1 16:41:58 2009
From: daniel at kewlio.net (Daniel Austin MBCS)
Date: Fri, 1 May 2009 15:41:58 +0100 (BST)
Subject: Domain Registrar recommendation
Message-ID: <dbcca56.f268d79152423275d58fdfa15a6bd577@mail.dan.me.uk>

Hi Steve,

I've always found Enom to be fine with IPv6 glue records (although I have to raise support tickets to get them done, they are usually done within a couple of hours)
I don't have any experience of Godaddy though - the name in itself has always been enough to put me off them :)

>---- Original Message ----
>From: Steve Bertrand <steve at ibctech.ca>
>To: ipv6-ops at lists.cluenet.de
>Sent: Fri, May 1, 2009, 2:25 PM
>Subject: Domain Registrar recommendation
>
>Hi all,
>
>Over the past 10 years or so, I've been dealing with a relatively small
>registrar in my local area for my personal domains (canadiandomain.com).
>Unfortunately, they can not provide IPv6 glue.
>
>A few months ago, I registered a handful more personal domains (which
>are currently idle) at godaddy.com, as apparently they can provide IPv6
>glue.
>
>I am going to set up one of the new domains as strictly IPv6 only for
>statistics gathering. The point is, is that I haven't 'configured' any
>of the domains at GoDaddy yet, so I am not experienced in regards to
>their reliability.
>
>Before I migrate my primary domain (ibctech.ca) to a new registrar so I
>can have v6 glue, I'm looking for feedback on whether it is advisable to
>move it to GoDaddy, or if I should look elsewhere.
>
>I've heard horror stories about GoDaddy domains randomly being shut
>down, and it taking weeks of circular dancing in order to justify having
>it re-enabled. I can not have that happening. Moreover, I want as smooth
>as possible transition


Thanks,

Daniel.


From Leo.Baltus at omroep.nl  Fri May  1 17:04:31 2009
From: Leo.Baltus at omroep.nl (Leo Baltus)
Date: Fri, 1 May 2009 17:04:31 +0200
Subject: Cannot assign requested address
Message-ID: <20090501150431.GE27210@nemo>

Hello,

We are trying to set up services using home-brewed scripts to set-up
ipv6 adresses and bind services to them, just as we do this for ipv4.

Using a fairly recent linux kernel (2.6.27.21), or any other linux
kernel I can get my hands on, the following scripts fails:

ip -f inet6 a add ::2/128 dev eth0 && nc -l ::2 1234
nc: Cannot assign requested address

An EADDRNOTAVAIL is issued.

Basically, we set up an ipv6 address and let nc listen on it.

Introducing a 2 sec. sleep between setting up the interface and
bind()'ing to it, seems to be the only workaround I have found.

Is there somebody here who knows what is going on, or why this is
different from ipv4?

-- 
Leo Baltus, internetbeheerder                         /\
NPO ICT Internet Services                            /NPO/\
Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \  /\/
beheer at omroep.nl, 035-6773555                         \/

From berni at birkenwald.de  Fri May  1 17:43:36 2009
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Fri, 01 May 2009 17:43:36 +0200
Subject: Cannot assign requested address
In-Reply-To: <20090501150431.GE27210@nemo>
References: <20090501150431.GE27210@nemo>
Message-ID: <49FB18A8.9060908@birkenwald.de>

Hi Leo,

> We are trying to set up services using home-brewed scripts to set-up
> ipv6 adresses and bind services to them, just as we do this for ipv4.
> 
> Using a fairly recent linux kernel (2.6.27.21), or any other linux
> kernel I can get my hands on, the following scripts fails:
> 
> ip -f inet6 a add ::2/128 dev eth0 && nc -l ::2 1234
> nc: Cannot assign requested address
> 
> An EADDRNOTAVAIL is issued.
> 
> Basically, we set up an ipv6 address and let nc listen on it.
> 
> Introducing a 2 sec. sleep between setting up the interface and
> bind()'ing to it, seems to be the only workaround I have found.

You are most probably hit by Duplicate Address Detection as defined in 
RFC2462 Section 5.4. You will probably see the address being "tentative" 
in ip -6 addr while the DAD is run.

You can disable DAD on the interface setting the sysctl variable 
net.ipv6.conf.et0.dad_transmits to 0, or enable the optimistic DAD 
support (RFC4429) in recent Linux kernels.

Bernhard

From Charles at thewybles.com  Fri May  1 18:46:26 2009
From: Charles at thewybles.com (Charles at thewybles.com)
Date: Fri, 1 May 2009 16:46:26 +0000
Subject: Domain Registrar recommendation
Message-ID: <1621250572-1241196397-cardhu_decombobulator_blackberry.rim.net-1489772927-@bxe1197.bisx.prod.on.blackberry>

I use domainsite and am rolling out my sites over v6. 


------Original Message------
From: Daniel Austin MBCS
Sender: ipv6-ops-bounces+charles=thewybles.com at lists.cluenet.de
To: ipv6-ops at lists.cluenet.de
To: Steve Bertrand
Subject: Re: Domain Registrar recommendation
Sent: May 1, 2009 7:41 AM

Hi Steve,

I've always found Enom to be fine with IPv6 glue records (although I have to raise support tickets to get them done, they are usually done within a couple of hours)
I don't have any experience of Godaddy though - the name in itself has always been enough to put me off them :)

>---- Original Message ----
>From: Steve Bertrand <steve at ibctech.ca>
>To: ipv6-ops at lists.cluenet.de
>Sent: Fri, May 1, 2009, 2:25 PM
>Subject: Domain Registrar recommendation
>
>Hi all,
>
>Over the past 10 years or so, I've been dealing with a relatively small
>registrar in my local area for my personal domains (canadiandomain.com).
>Unfortunately, they can not provide IPv6 glue.
>
>A few months ago, I registered a handful more personal domains (which
>are currently idle) at godaddy.com, as apparently they can provide IPv6
>glue.
>
>I am going to set up one of the new domains as strictly IPv6 only for
>statistics gathering. The point is, is that I haven't 'configured' any
>of the domains at GoDaddy yet, so I am not experienced in regards to
>their reliability.
>
>Before I migrate my primary domain (ibctech.ca) to a new registrar so I
>can have v6 glue, I'm looking for feedback on whether it is advisable to
>move it to GoDaddy, or if I should look elsewhere.
>
>I've heard horror stories about GoDaddy domains randomly being shut
>down, and it taking weeks of circular dancing in order to justify having
>it re-enabled. I can not have that happening. Moreover, I want as smooth
>as possible transition


Thanks,

Daniel.



Sent via BlackBerry from T-Mobile

From tim-projects at sentinelchicken.org  Fri May  1 18:55:32 2009
From: tim-projects at sentinelchicken.org (Tim)
Date: Fri, 1 May 2009 09:55:32 -0700
Subject: Domain Registrar recommendation
In-Reply-To: <1621250572-1241196397-cardhu_decombobulator_blackberry.rim.net-1489772927-@bxe1197.bisx.prod.on.blackberry>
References: <1621250572-1241196397-cardhu_decombobulator_blackberry.rim.net-1489772927-@bxe1197.bisx.prod.on.blackberry>
Message-ID: <20090501165532.GD2615@sentinelchicken.org>

I've been shopping for a cheap personal registrar as well and have
some of the same issues with GoDaddy.

> I use domainsite and am rolling out my sites over v6. 

Do they allow you to set v6 glue records?  What is the process?  Can
it be done through a web interface or does it require a support
ticket?

thanks!
tim

From Chris at 7of9b.org  Fri May  1 19:18:39 2009
From: Chris at 7of9b.org (Chris Burton)
Date: Fri, 1 May 2009 18:18:39 +0100
Subject: Domain Registrar recommendation
References: <dbcca56.f268d79152423275d58fdfa15a6bd577@mail.dan.me.uk>
Message-ID: <EFE3EC0DA8614174A7B4BEC7D7823FA9@murphy1>

> I've always found Enom to be fine with IPv6 glue records (although I have 
> to raise support tickets to get them done, they are usually done within a 
> couple of hours)
> I don't have any experience of Godaddy though - the name in itself has 
> always been enough to put me off them :)

I found enom OK after the first few tickets saying it wasn't possible, 
subsequent requests have gone through quite quickly though. You can setup 
just IPv4 OR IPv6 glue via the web interface just not both.

Chris. 



From steve at ibctech.ca  Fri May  1 19:35:33 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 01 May 2009 13:35:33 -0400
Subject: Domain Registrar recommendation
In-Reply-To: <20090501165532.GD2615@sentinelchicken.org>
References: <1621250572-1241196397-cardhu_decombobulator_blackberry.rim.net-1489772927-@bxe1197.bisx.prod.on.blackberry>
	<20090501165532.GD2615@sentinelchicken.org>
Message-ID: <49FB32E5.7070504@ibctech.ca>

Tim wrote:
> I've been shopping for a cheap personal registrar as well and have
> some of the same issues with GoDaddy.

Regarding issues, are you saying that you have experienced some of the
problems that I originally was enquiring about, ie. GoDaddy disabling
your domain for no apparent reason?

I'm going to enable the domains I have registered there now (after I get
my zones set up), but I am extremely hesitant about migrating my
existing domain until I can get more details/feedback from others.

My current domain is generally only used for email for myself and
family, but given that I belong to ~30 mailing lists and is my primary
source of personal email communication (~1k messages a day), it would
not be good if it went down, even for a short time.

>> I use domainsite and am rolling out my sites over v6. 
> 
> Do they allow you to set v6 glue records?  What is the process?  Can
> it be done through a web interface or does it require a support
> ticket?

The ISP I work for hosts ~400 domains, almost all of them are registered
through OpenSRS. My experience with them has been very good, and my
understanding is that they are in the process of rolling out IPv6 glue
ability at this time, and can manually do it for "critical" domains[1]
if a ticket is opened. I don't consider my domain to be 'critical', so
I'm holding off migrating my domain under the work account at OpenSRS.

Steve

[1] - http://opensrs.com/forums/comments.php?DiscussionID=11

From tim-projects at sentinelchicken.org  Fri May  1 20:35:27 2009
From: tim-projects at sentinelchicken.org (Tim)
Date: Fri, 1 May 2009 11:35:27 -0700
Subject: Domain Registrar recommendation
In-Reply-To: <49FB32E5.7070504@ibctech.ca>
References: <1621250572-1241196397-cardhu_decombobulator_blackberry.rim.net-1489772927-@bxe1197.bisx.prod.on.blackberry>
	<20090501165532.GD2615@sentinelchicken.org>
	<49FB32E5.7070504@ibctech.ca>
Message-ID: <20090501183527.GE2615@sentinelchicken.org>


> Regarding issues, are you saying that you have experienced some of the
> problems that I originally was enquiring about, ie. GoDaddy disabling
> your domain for no apparent reason?

I've just heard lots of bad things about them, directly related to the
issues you mentioned.

> My current domain is generally only used for email for myself and
> family, but given that I belong to ~30 mailing lists and is my primary
> source of personal email communication (~1k messages a day), it would
> not be good if it went down, even for a short time.

I'm basically in the same situation.

> The ISP I work for hosts ~400 domains, almost all of them are registered
> through OpenSRS. My experience with them has been very good, and my
> understanding is that they are in the process of rolling out IPv6 glue
> ability at this time, and can manually do it for "critical" domains[1]
> if a ticket is opened. I don't consider my domain to be 'critical', so
> I'm holding off migrating my domain under the work account at OpenSRS.

That's good to know.  I ran across bookmyname.com, which supposedly
supports v6 glue, but I'd love to hear others' experiences with them
before trying them out.

cheers,
tim

From steve at ibctech.ca  Fri May  1 22:28:44 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 01 May 2009 16:28:44 -0400
Subject: Domain Registrar recommendation
In-Reply-To: <20090501183527.GE2615@sentinelchicken.org>
References: <1621250572-1241196397-cardhu_decombobulator_blackberry.rim.net-1489772927-@bxe1197.bisx.prod.on.blackberry>	<20090501165532.GD2615@sentinelchicken.org>	<49FB32E5.7070504@ibctech.ca>
	<20090501183527.GE2615@sentinelchicken.org>
Message-ID: <49FB5B7C.7030001@ibctech.ca>

Tim wrote:
>> Regarding issues, are you saying that you have experienced some of the
>> problems that I originally was enquiring about, ie. GoDaddy disabling
>> your domain for no apparent reason?
> 
> I've just heard lots of bad things about them, directly related to the
> issues you mentioned.
> 
>> My current domain is generally only used for email for myself and
>> family, but given that I belong to ~30 mailing lists and is my primary
>> source of personal email communication (~1k messages a day), it would
>> not be good if it went down, even for a short time.
> 
> I'm basically in the same situation.
> 
>> The ISP I work for hosts ~400 domains, almost all of them are registered
>> through OpenSRS. My experience with them has been very good, and my
>> understanding is that they are in the process of rolling out IPv6 glue
>> ability at this time, and can manually do it for "critical" domains[1]
>> if a ticket is opened. I don't consider my domain to be 'critical', so
>> I'm holding off migrating my domain under the work account at OpenSRS.
> 
> That's good to know.  I ran across bookmyname.com, which supposedly
> supports v6 glue, but I'd love to hear others' experiences with them
> before trying them out.

Well, it appears as though I am out of luck. I should of read the fine
print ;)

All of my domains are .ca. Although CIRA is capable of handling IPv6
records, it doesn't appear as though ANY registrars are able to
accommodate IPv6 for .ca domains :(

Steve

From Leo.Baltus at omroep.nl  Fri May  1 22:30:56 2009
From: Leo.Baltus at omroep.nl (Leo Baltus)
Date: Fri, 1 May 2009 22:30:56 +0200
Subject: Cannot assign requested address
In-Reply-To: <49FB18A8.9060908@birkenwald.de>
References: <20090501150431.GE27210@nemo> <49FB18A8.9060908@birkenwald.de>
Message-ID: <20090501203056.GA10702@nemo>

Bernhard,

Op 01/05/2009 om 17:43:36 +0200, schreef Bernhard Schmidt:
>> We are trying to set up services using home-brewed scripts to set-up
>> ipv6 adresses and bind services to them, just as we do this for ipv4.
>>
>> Using a fairly recent linux kernel (2.6.27.21), or any other linux
>> kernel I can get my hands on, the following scripts fails:
>>
>> ip -f inet6 a add ::2/128 dev eth0 && nc -l ::2 1234
>> nc: Cannot assign requested address
>>
>> An EADDRNOTAVAIL is issued.
>>
>> Basically, we set up an ipv6 address and let nc listen on it.
>>
>> Introducing a 2 sec. sleep between setting up the interface and
>> bind()'ing to it, seems to be the only workaround I have found.
>
> You are most probably hit by Duplicate Address Detection as defined in  
> RFC2462 Section 5.4. You will probably see the address being "tentative"  
> in ip -6 addr while the DAD is run.
>
> You can disable DAD on the interface setting the sysctl variable  
> net.ipv6.conf.et0.dad_transmits to 0, or enable the optimistic DAD  
> support (RFC4429) in recent Linux kernels.

You were right, it was Duplicate Address Detection. However setting 
net.ipv6.conf.eth0.accept_dad=0 solved it.

Thanks a lot.

-- 
Leo Baltus, internetbeheerder                         /\
NPO ICT Internet Services                            /NPO/\
Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \  /\/
beheer at omroep.nl, 035-6773555                         \/

From ipv6-ops+phil at spodhuis.org  Sat May  2 02:28:57 2009
From: ipv6-ops+phil at spodhuis.org (Phil Pennock)
Date: Fri, 1 May 2009 17:28:57 -0700
Subject: Domain Registrar recommendation
In-Reply-To: <49FAF839.9070008@ibctech.ca>
References: <49FAF839.9070008@ibctech.ca>
Message-ID: <20090502002857.GA57121@redoubt.spodhuis.org>

On 2009-05-01 at 09:25 -0400, Steve Bertrand wrote:
> Unfortunately, they can not provide IPv6 glue.
[...]
> All feedback appreciated.

I see your note about no registrars providing IPv6 glue for .ca; for
anyone not dealing with .ca, I'll note that I'm happy with Joker, whose
web interface lets you register IPv6 glue normally, on parity with IPv4.
I have NS records with both IPv4 and IPv6 and another NS record with
only IPv6, it all works.

A couple of years back, this involved emails and special-casing by them,
which they did quickly and effectively; when I've had to do updates more
recently, they've fixed every issue I encountered and, AFAICT, IPv6 is
now on feature parity with IPv4.

Joker are based in Switzerland, can bill in multiple currencies and
their automated emails are PGP-signed (but without decent trust paths to
the signing key).

But .ca is not one of the TLDs which they cover.

-Phil

From nicholas.hatch at gmail.com  Sun May  3 02:38:13 2009
From: nicholas.hatch at gmail.com (nick hatch)
Date: Sat, 2 May 2009 17:38:13 -0700
Subject: Google, IPv6, and ... IPv4 multicast space?
Message-ID: <a71460720905021738x23a6a41fv564cd9eadea131db@mail.gmail.com>

I have been using Google services over IPv6 (SixXS tunnel) for a few days,
and noticed something odd.

Within Gmail, you can view the IP addresses which have recently logged into
your account for security purposes. When using gmail over IPv6, my IP
address shows up as being in IPv4 multicast space -- 239.93.229.239 .

I'm having a hard time wrapping my head around what they'd be using
multicast for. Perhaps its an internal hack to shim v6 addresses into a
management system which still expects IPv4 addresses?

Any idea what Google is doing?

-Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090502/07662a54/attachment.html 

From ccaputo at alt.net  Sun May  3 10:54:42 2009
From: ccaputo at alt.net (Chris Caputo)
Date: Sun, 3 May 2009 08:54:42 +0000 (UTC)
Subject: Quagga router redundancy determinism
Message-ID: <Pine.LNX.4.64.0905030851500.5812@nacho.alt.net>

I just posted a patch to quagga-dev to add RFC 4191 "default router 
preference" support for IPv6 router advertisements to Quagga:

  http://lists.quagga.net/pipermail/quagga-dev/2009-May/006547.html

The cool thing about router preference support is that if your host 
supports it (*), you can get some determinism in the choice of gateway 
used by IPv6 hosts when multiple routers are sending out router 
advertisements.  This enables deterministic gateway redundancy similar to 
HSRP/VRRP setups.

For example, remove any static IPv6 default routes from your hosts (**) 
and configure two routers on the same LAN as follows:

 Primary:

   interface eth0
    no ipv6 nd suppress-ra
    ipv6 nd ra-interval 1
    ipv6 nd ra-lifetime 3
    ipv6 nd router-preference high

 Backup:

   interface eth0
    no ipv6 nd suppress-ra
    ipv6 nd ra-interval 1
    ipv6 nd ra-lifetime 3
    ipv6 nd router-preference low

With the above configs, hosts which support router preference decoding 
will use the primary gateway unless a router advertisement is not seen 
from it in 3 seconds, in which case it will use the backup gateway.  And 
when the primary gateway returns, it will be used again.

Chris

* On linux, the kernel config option is CONFIG_IPV6_ROUTER_PREF.  Not sure 
about other platforms.

** In practical use, I also keep a static default route in place, albeit 
with a higher metric than what router advertisements are set at.  On my 
linux boxes, router advertisements have a metric of 1024 and I set my 
static fallback/worst case scenario route to have a metric higher than 
that (ex. 6666).

From jabley at hopcount.ca  Mon May  4 13:25:34 2009
From: jabley at hopcount.ca (Joe Abley)
Date: Mon, 4 May 2009 13:25:34 +0200
Subject: Domain Registrar recommendation
In-Reply-To: <49FB5B7C.7030001@ibctech.ca>
References: <1621250572-1241196397-cardhu_decombobulator_blackberry.rim.net-1489772927-@bxe1197.bisx.prod.on.blackberry>	<20090501165532.GD2615@sentinelchicken.org>	<49FB32E5.7070504@ibctech.ca>
	<20090501183527.GE2615@sentinelchicken.org>
	<49FB5B7C.7030001@ibctech.ca>
Message-ID: <694F581F-5F10-49EA-B644-A4C79703FB5C@hopcount.ca>


On 1-May-2009, at 22:28, Steve Bertrand wrote:

> All of my domains are .ca. Although CIRA is capable of handling IPv6
> records, it doesn't appear as though ANY registrars are able to
> accommodate IPv6 for .ca domains :(

Name your v6-capable nameservers under a different TLD?


Joe

From steve at ibctech.ca  Tue May  5 15:29:43 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Tue, 05 May 2009 09:29:43 -0400
Subject: Domain Registrar recommendation
In-Reply-To: <694F581F-5F10-49EA-B644-A4C79703FB5C@hopcount.ca>
References: <1621250572-1241196397-cardhu_decombobulator_blackberry.rim.net-1489772927-@bxe1197.bisx.prod.on.blackberry>	<20090501165532.GD2615@sentinelchicken.org>	<49FB32E5.7070504@ibctech.ca>	<20090501183527.GE2615@sentinelchicken.org>	<49FB5B7C.7030001@ibctech.ca>
	<694F581F-5F10-49EA-B644-A4C79703FB5C@hopcount.ca>
Message-ID: <4A003F47.9060108@ibctech.ca>

Joe Abley wrote:
> 
> On 1-May-2009, at 22:28, Steve Bertrand wrote:
> 
>> All of my domains are .ca. Although CIRA is capable of handling IPv6
>> records, it doesn't appear as though ANY registrars are able to
>> accommodate IPv6 for .ca domains :(
> 
> Name your v6-capable nameservers under a different TLD?

Thanks Joe... for some reason, I was thinking that I had to have glue on
the name servers within the actual domain.

Nonetheless, I've registered ipv6canada.com, and now on my way to get
things configured.

Steve

From steve at ibctech.ca  Fri May  8 06:28:22 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 08 May 2009 00:28:22 -0400
Subject: Looking for DNS/Operational experience
Message-ID: <4A03B4E6.9070104@ibctech.ca>

I've been moving forward quickly with IPv6 deployment, and am hoping
that I can garner some 'un-Googlable' information here.

I'm about to write up some Perl scripts to do some crafty work with
router information, but before I dedicate my time to it (I'm about all
we have at our small SP), I thought I'd ask if there is anything of the
like:

- any UNIX command-line tool to convert a compressed v6 addr into a
reverse DNS entry
- mechanism to create a reverse DNS entry, based on fwd lookup (I'm
thinking of writing a Perl app that can get from SNMP int,name,loc etc,
and creating a fwd & rev entry for DNS)

It would also be fantastic if some of the persons who have extensive
operational experience could speak up and share:

- the size of space received
- their number of clients and/or peers
- how they carved up their space
- why they carved it up that way
- what made them cut the space on specific boundaries
- what they did right
- what they wish that they had of done differently

Steve

From tore at linpro.no  Fri May  8 06:55:38 2009
From: tore at linpro.no (Tore Anderson)
Date: Fri, 08 May 2009 06:55:38 +0200
Subject: Looking for DNS/Operational experience
In-Reply-To: <4A03B4E6.9070104@ibctech.ca>
References: <4A03B4E6.9070104@ibctech.ca>
Message-ID: <4A03BB4A.6070705@linpro.no>

Hello,

* Steve Bertrand

> - any UNIX command-line tool to convert a compressed v6 addr into a 
> reverse DNS entry

I've used "dig" for this.  It's not exactly what it's built for but it
gets the job done:

tore at envy:~$ dig -x 2a02:c0:100::2 +noall +question

; <<>> DiG 9.5.1-P2-RedHat-9.5.1-2.P2.fc10 <<>> -x 2a02:c0:100::2 +noall +question
;; global options:  printcmd
;2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.c.0.0.2.0.a.2.ip6.arpa. IN PTR

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

From ccaputo at alt.net  Fri May  8 07:28:43 2009
From: ccaputo at alt.net (Chris Caputo)
Date: Fri, 8 May 2009 05:28:43 +0000 (UTC)
Subject: Looking for DNS/Operational experience
In-Reply-To: <4A03B4E6.9070104@ibctech.ca>
References: <4A03B4E6.9070104@ibctech.ca>
Message-ID: <Pine.LNX.4.64.0905080519171.21527@nacho.alt.net>

On Fri, 8 May 2009, Steve Bertrand wrote:
> - any UNIX command-line tool to convert a compressed v6 addr into a
> reverse DNS entry

Not a complete command-line tool, but one could easily be made using this 
function I wrote...  (below)

(Have your main() function call inet_pton() and then call this function 
with the result, along with the appropriate nibblecount.)

Let me know if it would be helpful to the community for me to write the 
command-line tool for this.  (You'll have to suggest the clever name for 
it though.)

Chris

/*
  Takes a in6_addr and returns a string in reverse DNS zone file format,
  for the number of nibbles needed for the DNS zone.

  So "2001:0DB8::1" in an in6_addr with a nibble count of 20 will return:

    "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0"
*/
char *
myV6rDNS(struct in6_addr *in6,
         int nibblecount)
{
  static char buf[32 * 2 + 1];  // 32 nibbles, 32 '.'s, 1 terminator
  char hex[] = "0123456789abcdef";
  int i = 0;
  int nibble = 0;

  memset(buf, 0, sizeof(buf));

  while (nibble < nibblecount)
    {
      if (0 != i)
        buf[i++] = '.';

      if (nibble % 2)
        buf[i++] = hex[in6->s6_addr[15 - nibble / 2] / 16];
      else
        buf[i++] = hex[in6->s6_addr[15 - nibble / 2] % 16];

      nibble++;
    }

  return buf;
}




From steve at ibctech.ca  Fri May  8 07:44:11 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 08 May 2009 01:44:11 -0400
Subject: Looking for DNS/Operational experience
In-Reply-To: <4A03BB4A.6070705@linpro.no>
References: <4A03B4E6.9070104@ibctech.ca> <4A03BB4A.6070705@linpro.no>
Message-ID: <4A03C6AB.8040502@ibctech.ca>

Tore Anderson wrote:
> Hello,
> 
> * Steve Bertrand
> 
>> - any UNIX command-line tool to convert a compressed v6 addr into a 
>> reverse DNS entry
> 
> I've used "dig" for this.  It's not exactly what it's built for but it
> gets the job done:
> 
> tore at envy:~$ dig -x 2a02:c0:100::2 +noall +question
> 
> ; <<>> DiG 9.5.1-P2-RedHat-9.5.1-2.P2.fc10 <<>> -x 2a02:c0:100::2 +noall +question
> ;; global options:  printcmd
> ;2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.c.0.0.2.0.a.2.ip6.arpa. IN PTR

Thanks for all the feedback thus far.

I've been weighing options in all regards (v6-wise), and I'm finding
things to be difficult.

I'm a FreeBSD person (not strictly, but inherently), and am just now in
the process of building a bunch of jails so I can give them out to
IPv6-testers.

Reverse DNS for my v6 wasn't important to me, until I turned up my third
BGP feed, and realized that my traces were taking a while on a
particular hop:

pearl# traceroute6 ipv6.google.com
 2  2607:f118:1:2:211:bbff:fe58:4240  0.982 ms  0.812 ms  0.979 ms

The IP is one of my edge devices that 'pearl' is closely connected to.
My PtP connections between P and PE are /64 eui, and iBGP is across
loopback.

Loopbacks are defined and documented:

2607:f118::c1 == P1
2607:f118::c2 == P2
2607:f118::e1 == PE1
2607:f118::e2 == PE2

etc.

The PtP (I don't have a distribution layer... I'm very small, and
although I'm sure of my ability to ``insert'' one, I'm still open to
advice as to why I need one) are within the x:x:1:x scope. For instance:

2607:f118:1:1 == P1 - P2
2607:f118:1:2 == P1 - PE2
2607:f118:1:3 == P1 - PE3

My scope in the grand scheme of things is very minute (/21 & /32), but I
feel quite honoured to be a part of IPv6, and I take great pride in it.

I've recently registered ipv6canada.com (which gave me glue for my
personal .ca domain), and onlyv6.com, which I'm using as literally a v6
only domain for statistics gathering thanks to FBSD & IPv6 capable
jails. Neither domain is completely standards-compliant, but they will
be within a couple of days.

Even during the writing of this long-drawn out message, I've got several
responses... thanks ;)

What I propose, and what I am going to work on, is a tool that will:

- look at the router (SNMP, RANCID gatherings, or otherwise)
- identify the interface and locale details of the router
- turn the IP 2607:f118:1:2:211:bbff:fe58:4240 into a DNS fwd & rev name
(information on proper interface naming standards for a real ISP welcome...)
- have the tool integrate with both BIND and TinyDNS

I also plan on moving forward with IPv6 no matter who says what, and I
plan on learning from every single mistake that I make, so I might be
able to provide the next person with information so they can progress
the protocol one step further than I was able to.

Steve






From steve at ibctech.ca  Fri May  8 08:25:36 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 08 May 2009 02:25:36 -0400
Subject: Looking for DNS/Operational experience
In-Reply-To: <Pine.LNX.4.64.0905080519171.21527@nacho.alt.net>
References: <4A03B4E6.9070104@ibctech.ca>
	<Pine.LNX.4.64.0905080519171.21527@nacho.alt.net>
Message-ID: <4A03D060.1090100@ibctech.ca>

Chris Caputo wrote:
> On Fri, 8 May 2009, Steve Bertrand wrote:
>> - any UNIX command-line tool to convert a compressed v6 addr into a
>> reverse DNS entry
> 
> Not a complete command-line tool, but one could easily be made using this 
> function I wrote...  (below)
> 
> (Have your main() function call inet_pton() and then call this function 
> with the result, along with the appropriate nibblecount.)
> 
> Let me know if it would be helpful to the community for me to write the 
> command-line tool for this.  (You'll have to suggest the clever name for 
> it though.)

I think that your function is something that we can clearly use as a
base. Thank you for the code snip.

I'm in EST and I'm way past my bedtime right now, so I'll review this
when I'm back in the office in five hours and go from there ;)

Perl is my most familiar "language", but I can identify with C enough to
read it (to some degree) to the point I can wrap, compile and sometimes
patch it.

Producing a universal application would be most beneficial, but in no
way am I qualified to ensure that the code is secure, or how a C program
can be protected.

It seems as though there is quite a bit of interest in DNS management
for v6 addresses (garnered off-list), so perhaps an "I want/I need"
should be thrown out there.

In regards to IPv6, who wants what for address management? What are your
biggest complaints? What do you wish you had to manage your space? Who
here is using a spreadsheet to manage their allocation?

Steve

From hahn at berkom.de  Fri May  8 08:52:08 2009
From: hahn at berkom.de (Christian Hahn)
Date: Fri, 08 May 2009 08:52:08 +0200
Subject: Looking for DNS/Operational experience
In-Reply-To: <4A03BB4A.6070705@linpro.no>
References: <4A03B4E6.9070104@ibctech.ca> <4A03BB4A.6070705@linpro.no>
Message-ID: <4A03D698.1020706@berkom.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Steve,
> Hello,
> 
> * Steve Bertrand
> 
>> - any UNIX command-line tool to convert a compressed v6 addr into a 
>> reverse DNS entry
> 
> I've used "dig" for this.  It's not exactly what it's built for but it
> gets the job done:
> 
> tore at envy:~$ dig -x 2a02:c0:100::2 +noall +question
> 
> ; <<>> DiG 9.5.1-P2-RedHat-9.5.1-2.P2.fc10 <<>> -x 2a02:c0:100::2 +noall +question
> ;; global options:  printcmd
> ;2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.c.0.0.2.0.a.2.ip6.arpa. IN PTR
A good tool for manipulating IPv6 addresses is ipv6calc.

chh at urlux:~ $ ipv6calc 2001:db8:0:abcd::7 --out revnibbles.arpa
No input type specified, try autodetection...found type: ipv6addr
7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.c.b.a.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

cheers,
Christian
> 
> Best regards,

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkoD1pQACgkQ6kMW7HW8621JEgCfdaRc5XpTHhytf/QZ4QPCalwt
EFYAoLNBSkJaPTSpjzhrO3d6kzhkjMId
=OLqA
-----END PGP SIGNATURE-----

From mleber at he.net  Fri May  8 09:52:00 2009
From: mleber at he.net (Mike Leber)
Date: Fri, 08 May 2009 00:52:00 -0700
Subject: Looking for DNS/Operational experience
In-Reply-To: <4A03B4E6.9070104@ibctech.ca>
References: <4A03B4E6.9070104@ibctech.ca>
Message-ID: <4A03E4A0.2090501@he.net>


Steve Bertrand wrote:
> I'm about to write up some Perl scripts to do some crafty work with
> router information, but before I dedicate my time to it (I'm about all
> we have at our small SP), I thought I'd ask if there is anything of the
> like:
> 
> - any UNIX command-line tool to convert a compressed v6 addr into a
> reverse DNS entry

Since you mentioned Perl, here is a way to do it with Perl:

$ perl -e 'use Net::IP;$ip=new Net::IP("2a02:c0:100::2/128");print 
($ip->reverse_ip()."\n");'

2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.c.0.0.2.0.a.2.ip6.arpa.

You'll probably find Net::IP very useful.  You can use it to write code 
that is nearly address family agnostic.

Mike.

-- 
+---------------- H U R R I C A N E - E L E C T R I C ----------------+
| Mike Leber        Wholesale IPv4 and IPv6 Transit      510 580 4100 |
| Hurricane Electric                                           AS6939 |
| mleber at he.net     Internet Backbone & Colocation      http://he.net |
+---------------------------------------------------------------------+


From Andreas.Schwarz at hansenet.com  Fri May  8 11:41:41 2009
From: Andreas.Schwarz at hansenet.com (Andreas.Schwarz at hansenet.com)
Date: Fri, 8 May 2009 11:41:41 +0200
Subject: Looking for DNS/Operational experience
In-Reply-To: <4A03B4E6.9070104@ibctech.ca>
Message-ID: <04648A48E504B54685A820CED162641E026EBA0B@BRAIN.corp.hansenet.com>

Steve Bertrand wrote:

Hi Steve,

> I've been moving forward quickly with IPv6 deployment, and am hoping
> that I can garner some 'un-Googlable' information here.
> 
> I'm about to write up some Perl scripts to do some crafty work with
> router information, but before I dedicate my time to it (I'm about all
> we have at our small SP), I thought I'd ask if there is
> anything of the
> like:
> 
> - any UNIX command-line tool to convert a compressed v6 addr into a
> reverse DNS entry 

Have also a look at "sipcalc".

asc at opossum:~ $ sipcalc -r 2a01:c08::14
-[ipv6 : 2a01:c08::14] - 0

[IPV6 DNS]
Reverse DNS (ip6.arpa)  -
4.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.0.c.0.1.0.a.2.ip6.arpa.



best regards,
Andreas

-- 
     HanseNet Telekommunikation GmbH
     Andreas Schwarz, TOS, GPG KeyID 0x3C40103A
     ?berseering 33a, D-22297 Hamburg
     fon: +49-40-23726-3892, fax: +49-40-23726-3772

From bjorn at mork.no  Fri May  8 12:20:31 2009
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Fri, 08 May 2009 12:20:31 +0200
Subject: Looking for DNS/Operational experience
In-Reply-To: <4A03E4A0.2090501@he.net> (Mike Leber's message of "Fri, 08 May
	2009 00:52:00 -0700")
References: <4A03B4E6.9070104@ibctech.ca> <4A03E4A0.2090501@he.net>
Message-ID: <8763gbew0g.fsf@nemi.mork.no>

Mike Leber <mleber at he.net> writes:

> Since you mentioned Perl, here is a way to do it with Perl:
>
> $ perl -e 'use Net::IP;$ip=new Net::IP("2a02:c0:100::2/128");print
> ($ip->reverse_ip()."\n");'
>
> 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.c.0.0.2.0.a.2.ip6.arpa.
>
> You'll probably find Net::IP very useful.  You can use it to write
> code that is nearly address family agnostic.

No, you can't.  You can use it for IPv6, but it fails for IPv4 (CIDR):

bjorn at nemi:/tmp$  perl -e 'use Net::IP;$ip=new Net::IP("192.168.4.0/24");print $ip->reverse_ip()."\n"'
4.168.192.in-addr.arpa.
bjorn at nemi:/tmp$  perl -e 'use Net::IP;$ip=new Net::IP("192.168.0.0/24");print $ip->reverse_ip()."\n"'
168.192.in-addr.arpa.


The output of the latter should of course have been
0.168.192.in-addr.arpa.


Bj?rn

From mleber at he.net  Fri May  8 17:13:16 2009
From: mleber at he.net (Mike Leber)
Date: Fri, 08 May 2009 08:13:16 -0700
Subject: Looking for DNS/Operational experience
In-Reply-To: <8763gbew0g.fsf@nemi.mork.no>
References: <4A03B4E6.9070104@ibctech.ca> <4A03E4A0.2090501@he.net>
	<8763gbew0g.fsf@nemi.mork.no>
Message-ID: <4A044C0C.5060903@he.net>


Bj?rn Mork wrote:
> Mike Leber <mleber at he.net> writes:
> 
>> Since you mentioned Perl, here is a way to do it with Perl:
>>
>> $ perl -e 'use Net::IP;$ip=new Net::IP("2a02:c0:100::2/128");print
>> ($ip->reverse_ip()."\n");'
>>
>> 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.c.0.0.2.0.a.2.ip6.arpa.
>>
>> You'll probably find Net::IP very useful.  You can use it to write
>> code that is nearly address family agnostic.
> 
> No, you can't.  You can use it for IPv6, but it fails for IPv4 (CIDR):

To date, I'd bet Net::IP has been used in more IPv4 code than IPv6.

The documentation for the reverse_ip function is:

QUOTE
Return the reverse IP for a given IP address (in.addr. format).
ENDQUOTE

It says IP address (not prefix) plus they probably didn't test for 
somebody using .0 of a prefix.

This function is just one of 27.

If you find a behavior in a package you don't agree with:

1) Find out how other people made it work correctly.  Read the 
documentation and use Google.  Look at what how the module writer 
actually wrote the function you are using.

2) Write your own perl code to handle it.

3) Find another package that does what you want.

4) Fix the module, or write a fixed version of the function, and mail 
the module writer.  Other people will probably run into the same thing.

Mike.

> 
> bjorn at nemi:/tmp$  perl -e 'use Net::IP;$ip=new Net::IP("192.168.4.0/24");print $ip->reverse_ip()."\n"'
> 4.168.192.in-addr.arpa.
> bjorn at nemi:/tmp$  perl -e 'use Net::IP;$ip=new Net::IP("192.168.0.0/24");print $ip->reverse_ip()."\n"'
> 168.192.in-addr.arpa.
> 
> 
> The output of the latter should of course have been
> 0.168.192.in-addr.arpa.
> 
> 
> Bj?rn

-- 
+---------------- H U R R I C A N E - E L E C T R I C ----------------+
| Mike Leber        Wholesale IPv4 and IPv6 Transit      510 580 4100 |
| Hurricane Electric                                           AS6939 |
| mleber at he.net     Internet Backbone & Colocation      http://he.net |
+---------------------------------------------------------------------+


From bjorn at mork.no  Fri May  8 18:58:08 2009
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Fri, 08 May 2009 18:58:08 +0200
Subject: Looking for DNS/Operational experience
In-Reply-To: <4A044C0C.5060903@he.net> (Mike Leber's message of "Fri, 08 May
	2009 08:13:16 -0700")
References: <4A03B4E6.9070104@ibctech.ca> <4A03E4A0.2090501@he.net>
	<8763gbew0g.fsf@nemi.mork.no> <4A044C0C.5060903@he.net>
Message-ID: <87hbzvcz1b.fsf@nemi.mork.no>

Mike Leber <mleber at he.net> writes:
> Bj?rn Mork wrote:
>> Mike Leber <mleber at he.net> writes:
>>
>>> Since you mentioned Perl, here is a way to do it with Perl:
>>>
>>> $ perl -e 'use Net::IP;$ip=new Net::IP("2a02:c0:100::2/128");print
>>> ($ip->reverse_ip()."\n");'
>>>
>>> 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.c.0.0.2.0.a.2.ip6.arpa.
>>>
>>> You'll probably find Net::IP very useful.  You can use it to write
>>> code that is nearly address family agnostic.
>>
>> No, you can't.  You can use it for IPv6, but it fails for IPv4 (CIDR):
>
> To date, I'd bet Net::IP has been used in more IPv4 code than IPv6.

Sure.  You just can't use the reverse_ip function.  The rest of Net::IP
is quite nice, and I certainly use it for IPv6.

> The documentation for the reverse_ip function is:
>
> QUOTE
> Return the reverse IP for a given IP address (in.addr. format).
> ENDQUOTE
>
> It says IP address (not prefix)

Oh, but it doesn't work any better with an IP address:

bjorn at nemi:/tmp$ perl -e 'use Net::IP;$ip=new Net::IP("192.168.4.0");print $ip->reverse_ip()."\n"'
4.168.192.in-addr.arpa.

> plus they probably didn't test for somebody using .0 of a prefix.

No, the probably didn't.  Which probably is why it doesn't work :-)

> This function is just one of 27.
>
> If you find a behavior in a package you don't agree with:
>
> 1) Find out how other people made it work correctly.  Read the
> documentation and use Google.  Look at what how the module writer
> actually wrote the function you are using.

I did.   I sent this patch to the author in february 2008:

diff -urN a/Net/IP.pm b/Net/IP.pm
--- a/Net/IP.pm	2008-02-06 11:47:39.870067846 +0100
+++ b/Net/IP.pm	2008-02-06 11:54:26.622068489 +0100
@@ -1769,15 +1769,12 @@
 
     if ($ip_version == 4) {
         my @quads    = split /\./, $ip;
-        my $no_quads = ($len / 8);
+        my $first_quad_index = $len ? 4 - (int($len / 8)) : 0;
 
         my @reverse_quads = reverse @quads;
 
-        while (@reverse_quads and $reverse_quads[0] == 0) {
-            shift(@reverse_quads);
-        }
-
-        return join '.', @reverse_quads, 'in-addr', 'arpa.';
+        return join '.', @reverse_quads[ $first_quad_index .. $#reverse_quads ],
+          'in-addr', 'arpa.';
     }
     elsif ($ip_version == 6) {
         my @rev_groups = reverse split /:/, $ip;


> 2) Write your own perl code to handle it.

I did.  It's not like it's a big problem.

> 3) Find another package that does what you want.

It's not that important to me. 

>
> 4) Fix the module, or write a fixed version of the function, and mail
> the module writer.  Other people will probably run into the same
> thing.

Oh, they already did.  See

http://rt.cpan.org/Public/Bug/Display.html?id=42793
http://rt.cpan.org/Public/Bug/Display.html?id=25169


Bj?rn

From mleber at he.net  Sat May  9 03:28:13 2009
From: mleber at he.net (Mike Leber)
Date: Fri, 08 May 2009 18:28:13 -0700
Subject: Looking for DNS/Operational experience
In-Reply-To: <87hbzvcz1b.fsf@nemi.mork.no>
References: <4A03B4E6.9070104@ibctech.ca>
	<4A03E4A0.2090501@he.net>	<8763gbew0g.fsf@nemi.mork.no>
	<4A044C0C.5060903@he.net> <87hbzvcz1b.fsf@nemi.mork.no>
Message-ID: <4A04DC2D.5000709@he.net>


Hehehe, that's pretty cool that you already submitted a patch for it! :)

Mike.

Bj?rn Mork wrote:
> Mike Leber <mleber at he.net> writes:
>> Bj?rn Mork wrote:
>>> Mike Leber <mleber at he.net> writes:
>>>
>>>> Since you mentioned Perl, here is a way to do it with Perl:
>>>>
>>>> $ perl -e 'use Net::IP;$ip=new Net::IP("2a02:c0:100::2/128");print
>>>> ($ip->reverse_ip()."\n");'
>>>>
>>>> 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.c.0.0.2.0.a.2.ip6.arpa.
>>>>
>>>> You'll probably find Net::IP very useful.  You can use it to write
>>>> code that is nearly address family agnostic.
>>> No, you can't.  You can use it for IPv6, but it fails for IPv4 (CIDR):
>> To date, I'd bet Net::IP has been used in more IPv4 code than IPv6.
> 
> Sure.  You just can't use the reverse_ip function.  The rest of Net::IP
> is quite nice, and I certainly use it for IPv6.
> 
>> The documentation for the reverse_ip function is:
>>
>> QUOTE
>> Return the reverse IP for a given IP address (in.addr. format).
>> ENDQUOTE
>>
>> It says IP address (not prefix)
> 
> Oh, but it doesn't work any better with an IP address:
> 
> bjorn at nemi:/tmp$ perl -e 'use Net::IP;$ip=new Net::IP("192.168.4.0");print $ip->reverse_ip()."\n"'
> 4.168.192.in-addr.arpa.
> 
>> plus they probably didn't test for somebody using .0 of a prefix.
> 
> No, the probably didn't.  Which probably is why it doesn't work :-)
> 
>> This function is just one of 27.
>>
>> If you find a behavior in a package you don't agree with:
>>
>> 1) Find out how other people made it work correctly.  Read the
>> documentation and use Google.  Look at what how the module writer
>> actually wrote the function you are using.
> 
> I did.   I sent this patch to the author in february 2008:
> 
> diff -urN a/Net/IP.pm b/Net/IP.pm
> --- a/Net/IP.pm	2008-02-06 11:47:39.870067846 +0100
> +++ b/Net/IP.pm	2008-02-06 11:54:26.622068489 +0100
> @@ -1769,15 +1769,12 @@
>  
>      if ($ip_version == 4) {
>          my @quads    = split /\./, $ip;
> -        my $no_quads = ($len / 8);
> +        my $first_quad_index = $len ? 4 - (int($len / 8)) : 0;
>  
>          my @reverse_quads = reverse @quads;
>  
> -        while (@reverse_quads and $reverse_quads[0] == 0) {
> -            shift(@reverse_quads);
> -        }
> -
> -        return join '.', @reverse_quads, 'in-addr', 'arpa.';
> +        return join '.', @reverse_quads[ $first_quad_index .. $#reverse_quads ],
> +          'in-addr', 'arpa.';
>      }
>      elsif ($ip_version == 6) {
>          my @rev_groups = reverse split /:/, $ip;
> 
> 
>> 2) Write your own perl code to handle it.
> 
> I did.  It's not like it's a big problem.
> 
>> 3) Find another package that does what you want.
> 
> It's not that important to me. 
> 
>> 4) Fix the module, or write a fixed version of the function, and mail
>> the module writer.  Other people will probably run into the same
>> thing.
> 
> Oh, they already did.  See
> 
> http://rt.cpan.org/Public/Bug/Display.html?id=42793
> http://rt.cpan.org/Public/Bug/Display.html?id=25169
> 
> 
> Bj?rn

-- 
+---------------- H U R R I C A N E - E L E C T R I C ----------------+
| Mike Leber        Wholesale IPv4 and IPv6 Transit      510 580 4100 |
| Hurricane Electric                                           AS6939 |
| mleber at he.net     Internet Backbone & Colocation      http://he.net |
+---------------------------------------------------------------------+

From michael.dillon at bt.com  Sat May  9 14:23:49 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Sat, 9 May 2009 13:23:49 +0100
Subject: IPv6 End User Assignments
Message-ID: <28E139F46D45AF49A31950F88C497458FFD28E@E03MVZ2-UKDY.domain1.systemhost.net>

 
I just posted the following to a private ARIN members'
mailing list, and I thought I would post it here to
see if there are any comments on the advice that I gave.

> > /48 as per standard.
> 
> What standard are you referring to?

None.
"As per standard" is a colloquial way of saying "standard practice"
which refers to the way that people have been doing things for the past
few years. Of course it all started with an RFC like 3177 which says:

-----quoted text------
This document provides recommendations to the addressing registries
(APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks
to end sites. In particular, it recommends the assignment of 

   /48 in the general case, /64 when it is known that one and only one
   subnet is needed and /128 when it is absolutely known that one and
   only one device is connecting.

The original recommendations were made in an IAB/IESG statement mailed
to the registries on September 1, 2000. This document refines the
original recommendation and documents it for the historical record. 
-----end quote-------

> From what I'm reading, a longer prefix, such as /56 is acceptable:

Yes it is acceptable but it is not standard practice. That change to
policy was adopted to address an issue that a few very large ISPs have
with the HD ratio.

The change was introduced with policy proposal 2005-8 but please note
the first sentence of the policy text of these guidelines:

The following guidelines may be useful
(but they are only guidelines):
- /64 when it is known that one and only
  one subnet is needed
- /56 for small sites, those expected to
  need only a few subnets over the next 5 years.
- /48 for larger sites

A large part of the rationale for this change to allow /56 was in an
earlier version of this Internet draft:
<http://smakd.potaroo.net/ietf/idref/draft-narten-ipv6-3177bis-48boundar
y/index.html>

There is a good section there explaining how /56 for residential users
still maintains RFC 3177's goals.

> "Ideally, residential networks would be given an address range of a
> /48 or /56 [RIPE_Nov07] such that multiple /64 subnets could be used 
> within the residence." [1]
> 
> 1. RFC 5375 - IPv6 Unicast Address Assignment Considerations, Section 
> 2.4

Like I said, /48 for residential networks is still standard practice.

I believe that the idea for a /56 first came from Geoff Huston in this
analysis:
<http://www.potaroo.net/ispcol/2005-07/ipv6size.html>

If you have a network architecture which requires you to assign /48s to
each POTENTIAL customer, then you are at risk of not qualifying for
additional blocks because ARIN only counts ACTUAL customers. But, if you
assign /56s to each POTENTIAL customer, you are almost certain to never
need to go back to ARIN.
Some cable providers need to assign a block to every residence that
their cable goes past, which is why the policy was changed to allow for
/56 assignments.

And, as the policy states, these are only guidelines.
Some ISPs will need to assign a /47 or /46 per customer because their
business model requires it. Maybe they specialise in connecting hotels
who have a complex subnet plan to accomodate guest wifi subnets, room TV
subnets, room telephony subnets, maid subnets per trolley, management
subnets per section of each floor, banquet room subnets, conference
subnets per kiosk, kitchen subnets, staff network subnets, bar wifi
subnet, restaurant staff subnets, and lord knows what else. ARIN cannot
dictate one size fits all, because increasingly, the ISP business is
diversifying and there are all kinds of strange things out there.

--Michael Dillon


From martin at airwire.ie  Sat May  9 14:29:07 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Sat, 09 May 2009 13:29:07 +0100
Subject: IPv6 End User Assignments
In-Reply-To: <28E139F46D45AF49A31950F88C497458FFD28E@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C497458FFD28E@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4A057713.4060503@airwire.ie>

michael.dillon at bt.com wrote:
> And, as the policy states, these are only guidelines.
> Some ISPs will need to assign a /47 or /46 per customer because their
> business model requires it. Maybe they specialise in connecting hotels
> who have a complex subnet plan to accomodate guest wifi subnets, room TV
> subnets, room telephony subnets, maid subnets per trolley, management
> subnets per section of each floor, banquet room subnets, conference
> subnets per kiosk, kitchen subnets, staff network subnets, bar wifi
> subnet, restaurant staff subnets, and lord knows what else. ARIN cannot
> dictate one size fits all, because increasingly, the ISP business is
> diversifying and there are all kinds of strange things out there.

If you want to assign anything larger than a /48 to one location  you
will have to discuss that with RIPE and obtain their permission. And to
my knowledge, this case has not been made yet. Mind you, an end-user can
have multiple /48's, as long as they are on different locations.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From gert at space.net  Sat May  9 18:09:34 2009
From: gert at space.net (Gert Doering)
Date: Sat, 9 May 2009 18:09:34 +0200
Subject: IPv6 End User Assignments
In-Reply-To: <28E139F46D45AF49A31950F88C497458FFD28E@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C497458FFD28E@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <20090509160933.GJ39082@Space.Net>

Hi,

On Sat, May 09, 2009 at 01:23:49PM +0100, michael.dillon at bt.com wrote:
> And, as the policy states, these are only guidelines.
> Some ISPs will need to assign a /47 or /46 per customer because their
> business model requires it. 

This would require approval from the RIPE NCC if done in the RIPE region.

/48.../64 is something the ISP can choose, but /47 or shorter needs
hostmaster approval in every single case.

Gert Doering
        -- APWG chair
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From leo.vegoda at icann.org  Sat May  9 18:13:55 2009
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Sat, 9 May 2009 09:13:55 -0700
Subject: IPv6 End User Assignments
In-Reply-To: <20090509160933.GJ39082@Space.Net>
Message-ID: <C62AF9D3.28F01%leo.vegoda@icann.org>

On 09/05/2009 9:09, "Gert Doering" <gert at space.net> wrote:

[...]

>> And, as the policy states, these are only guidelines.
>> Some ISPs will need to assign a /47 or /46 per customer because their
>> business model requires it.
> 
> This would require approval from the RIPE NCC if done in the RIPE region.
> 
> /48.../64 is something the ISP can choose, but /47 or shorter needs
> hostmaster approval in every single case.

But a /47 sub-allocation does not need RIR approval. So the ISP can provide
a /47 prefix which the customer can assign as two separate /48, one to each
half of its 'site'.

Regards,

Leo


From gert at space.net  Sat May  9 18:17:33 2009
From: gert at space.net (Gert Doering)
Date: Sat, 9 May 2009 18:17:33 +0200
Subject: IPv6 End User Assignments
In-Reply-To: <C62AF9D3.28F01%leo.vegoda@icann.org>
References: <20090509160933.GJ39082@Space.Net>
	<C62AF9D3.28F01%leo.vegoda@icann.org>
Message-ID: <20090509161733.GL39082@Space.Net>

Hi,

On Sat, May 09, 2009 at 09:13:55AM -0700, Leo Vegoda wrote:
> [...]
> 
> >> And, as the policy states, these are only guidelines.
> >> Some ISPs will need to assign a /47 or /46 per customer because their
> >> business model requires it.
> > 
> > This would require approval from the RIPE NCC if done in the RIPE region.
> > 
> > /48.../64 is something the ISP can choose, but /47 or shorter needs
> > hostmaster approval in every single case.
> 
> But a /47 sub-allocation does not need RIR approval. So the ISP can provide
> a /47 prefix which the customer can assign as two separate /48, one to each
> half of its 'site'.

I would call this "bending the policy".  Even if you do sub-allocations, 
the assignment rule of "maximum of a /48 per site" still holds (and the
NCC is going to ask the LIR questions about this).

Of course, if the customer actually *has* two sites, two /48s would 
obviously be fine.

(And yes, I'm aware that "site" isn't one of the best-defined terms)

Gert Doering
        -- APWG chair
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090509/45fc2bec/attachment.bin 

From david.freedman at uk.clara.net  Sat May  9 18:34:04 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Sat, 9 May 2009 17:34:04 +0100
Subject: IPv6 End User Assignments
References: <20090509160933.GJ39082@Space.Net><C62AF9D3.28F01%leo.vegoda@icann.org>
	<20090509161733.GL39082@Space.Net>
Message-ID: <7B8B0D6F623C3A40A0D0A80A66756E2B010547@EXVS01.claranet.local>

>(And yes, I'm aware that "site" isn't one of the best-defined terms)

Isn't this one of the reasons we deprecated site-local addressing? (RFC3879)

Dave.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090509/ab87d751/attachment.html 

From leo.vegoda at icann.org  Sat May  9 18:42:36 2009
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Sat, 9 May 2009 09:42:36 -0700
Subject: IPv6 End User Assignments
In-Reply-To: <20090509161733.GL39082@Space.Net>
Message-ID: <C62B008C.28F09%leo.vegoda@icann.org>

On 09/05/2009 9:17, "Gert Doering" <gert at space.net> wrote:

[...]

>> But a /47 sub-allocation does not need RIR approval. So the ISP can provide
>> a /47 prefix which the customer can assign as two separate /48, one to each
>> half of its 'site'.
> 
> I would call this "bending the policy".

I agree with you.

> Even if you do sub-allocations,
> the assignment rule of "maximum of a /48 per site" still holds (and the
> NCC is going to ask the LIR questions about this).
> 
> Of course, if the customer actually *has* two sites, two /48s would
> obviously be fine.

In practical terms, I think that any site large enough to have even a vague
need for two /48s could legitimately claim to be two sites and so not worry.
I think the only potential reason to worry is that the /48 might become the
new "Class C" and network consultants will want to use one per floor, room,
department or whatever.

I suspect we can worry about this trend if and when we see it.

Regards,

Leo


From michael.dillon at bt.com  Sat May  9 19:35:28 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Sat, 9 May 2009 18:35:28 +0100
Subject: IPv6 End User Assignments
In-Reply-To: <4A057713.4060503@airwire.ie>
Message-ID: <28E139F46D45AF49A31950F88C497458FFD296@E03MVZ2-UKDY.domain1.systemhost.net>

> If you want to assign anything larger than a /48 to one 
> location  you will have to discuss that with RIPE and obtain 
> their permission.

Only in the RIPE region and that is a non-issue since
RIPE will readily agree if the ISP can show that the
site needs more than a /48. This is just a 
procedural issue that will be worked out as we gain
some volume of experience in IPv6 assignments, as
opposed to allocations.

--Michael Dillon

From steve at ibctech.ca  Sat May  9 19:56:53 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Sat, 09 May 2009 13:56:53 -0400
Subject: IPv6 End User Assignments
In-Reply-To: <C62B008C.28F09%leo.vegoda@icann.org>
References: <C62B008C.28F09%leo.vegoda@icann.org>
Message-ID: <4A05C3E5.3060207@ibctech.ca>

Leo Vegoda wrote:
> On 09/05/2009 9:17, "Gert Doering" <gert at space.net> wrote:
> 
> [...]
> 
>>> But a /47 sub-allocation does not need RIR approval. So the ISP can provide
>>> a /47 prefix which the customer can assign as two separate /48, one to each
>>> half of its 'site'.
>> I would call this "bending the policy".
> 
> I agree with you.
> 
>> Even if you do sub-allocations,
>> the assignment rule of "maximum of a /48 per site" still holds (and the
>> NCC is going to ask the LIR questions about this).
>>
>> Of course, if the customer actually *has* two sites, two /48s would
>> obviously be fine.
> 
> In practical terms, I think that any site large enough to have even a vague
> need for two /48s could legitimately claim to be two sites and so not worry.
> I think the only potential reason to worry is that the /48 might become the
> new "Class C" and network consultants will want to use one per floor, room,
> department or whatever.
> 
> I suspect we can worry about this trend if and when we see it.

I've heard it said that once 2000::/3 nears an end, we will have had
enough operational experience to really decide on a decent policy
regarding assignments.

Unfortunately, it seems as there are more people fighting each other as
to what *should* be done, and not enough of the larger (or even small
for that matter) *SPs sharing information as to what is currently
working for them, and what is not working for them.

_Personally_, I don't see /48s by default as a good thing, but I know
for a fact that I'm still (unfortunately) having difficulty moving away
from the v4 mindset in regard to ``you have this type of link, you get
this much space''. This incorrect mindset is still prevalent due to not
enough operational experience, and having no context to have learnt from
mistakes.

At this point, personally, I'm rolling with a /64 PtP, and a /56 to ALL
clients (some may never use the routed /56, just the /64), but I'm also
reserving the encompassing /48 for those /56s, just in case ARIN policy
changes to reflect 48 for everyone. If it doesn't, and operational BCP
states that anything less than /48 is what we do, then I can begin using
those reserved encompassing /48s to other clients attached to the same PE.

I don't like /64 where only one subnet is needed, because I've made that
mistake before. Inevitably, the site will need more space (says Murphy).
I do like /56 for all, unless a /48 can be forseen by yourself as the
network op, or warranted immediately by the client.

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090509/f0986b97/attachment-0001.bin 

From gert at space.net  Sun May 10 14:53:14 2009
From: gert at space.net (Gert Doering)
Date: Sun, 10 May 2009 14:53:14 +0200
Subject: IPv6 End User Assignments
In-Reply-To: <C62B008C.28F09%leo.vegoda@icann.org>
References: <20090509161733.GL39082@Space.Net>
	<C62B008C.28F09%leo.vegoda@icann.org>
Message-ID: <20090510125314.GO39082@Space.Net>

Hi,

On Sat, May 09, 2009 at 09:42:36AM -0700, Leo Vegoda wrote:
> I suspect we can worry about this trend if and when we see it.

Definitely.  I just wanted to have a pointer to the current policy in
this thread, to avoid confusion if someone stumbles across the discussion
in the archives.

gert
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090510/410856ec/attachment.bin 

From jabley at hopcount.ca  Mon May 11 13:24:52 2009
From: jabley at hopcount.ca (Joe Abley)
Date: Mon, 11 May 2009 14:24:52 +0300
Subject: Looking for DNS/Operational experience
In-Reply-To: <Pine.LNX.4.64.0905080519171.21527@nacho.alt.net>
References: <4A03B4E6.9070104@ibctech.ca>
	<Pine.LNX.4.64.0905080519171.21527@nacho.alt.net>
Message-ID: <EE01DE15-B548-4446-B1F4-EC71869F47EA@hopcount.ca>


On 8-May-2009, at 08:28, Chris Caputo wrote:

> Not a complete command-line tool, but one could easily be made using  
> this
> function I wrote...  (below)

Here's one I wrote a while back in awk. You know, for that other  
person in the observable universe who still likes to use awk.

# dealing with IPv6 addresses in awk is, well, awkward
# take advil now

function v6ptr(address) {
   n = split(address, a, /:/);
   m = split(address, b, /::/);

   if (m == 2) {
     # normalise :: notation
     address = b[1];
     for (i = 0; i < 9 - n; i++)
       address = address ":0";
     address = address ":" b[2];
   }

   # produce a dot-separated list of nybbles
   nybbles = "";
   split(address, a, /:/);
   for (i = 1; i < 9; i++) {
     for (j = 0; j < 4 - length(a[i]); j++)
       nybbles = "0" (nybbles ? "." nybbles : "");
     for (j = 1; j < length(a[i]) + 1; j++)
       nybbles = substr(a[i], j, 1) (nybbles ? "." nybbles : "");
   }

   return nybbles;
}

This function was wrapped in a script that produced a full set of PTR  
records from configs retrieved by rancid (I wrote parsers for IOS and  
JUNOS).


Joe


From internetplumber at gmail.com  Mon May 11 19:35:30 2009
From: internetplumber at gmail.com (Rob Evans)
Date: Mon, 11 May 2009 18:35:30 +0100
Subject: IPv6 End User Assignments
In-Reply-To: <4A057713.4060503@airwire.ie>
References: <28E139F46D45AF49A31950F88C497458FFD28E@E03MVZ2-UKDY.domain1.systemhost.net>
	<4A057713.4060503@airwire.ie>
Message-ID: <9a8fa98b0905111035h2718b59fifeb0761d6e295028@mail.gmail.com>

> If you want to assign anything larger than a /48 to one location ?you
> will have to discuss that with RIPE and obtain their permission. And to
> my knowledge, this case has not been made yet.

Just as an aside, the case has been made at least once.  We (JANET)
did it for one of our customers, and I recall someone else mentioning
they'd done it too.

Cheers,
Rob

From tedm at ipinc.net  Thu May 14 23:32:11 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 14 May 2009 14:32:11 -0700
Subject: Question about 6to4
Message-ID: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>

Hi All,

 I apologize in advance if this has been asked before a million times but
I have what is probably a stupid question about 6to4.

 We are in process of connecting to native IPv6, I am currently getting
the IPv6 BGP table from our upstream.

  I see that Linksys is supporting IPv6 out-of-the-box in some of it's
routers, via 6to4

  I figured this might be useful for some of our customers, to setup
a 6to4 relay router for these Linksys devices to use.  I have found plenty
of info on the Internet to setup a router as a 6to4 relay.

  My question concerns how exactly 6to4 -works-

  My understanding is that RFC3068 defines 2002:c058:6301:: as the
anycast for the (in this case) customer router to find the 6to4 relay I
create.  And that a 6to4 relay then uses a manufactured 2002:: IPv6
address formed by using it's IPv4 address with the 2002:: prefix, and
that any 6to4 routers tunneled into it are using their manufactured
2002:xxxx:: addresses.

  So, if this is the case then wouldn't every 6to4 relay that's advertising
on the Intenet be present in the IPv6 BGP table?

  In looking at the various IPv6 looking glasses on the Internet, I see
a handful of 2002:: routes out there.

  But there seems to be no consistency anywhere.  Most of the looking
glasses
seem to show Hurricaine Electric's 2002:: advertisement, including my
own table.

  But beyond that, the advertisements for other relays seem to exist in
one router, but not in others.

  Advertisements for native routes do seem to be consistent.

  How exactly do routers know where to forward IPv6 packets destined for
a given 6to4   2002:: address if there is no route in their table?  And if
they are just sending 6to4 traffic to HE then how does HE know what to
do with it if it's not for their network?

Thanks,
Ted



From stevewilcox at google.com  Thu May 14 23:49:20 2009
From: stevewilcox at google.com (Steve Wilcox)
Date: Thu, 14 May 2009 22:49:20 +0100
Subject: Question about 6to4
In-Reply-To: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>
Message-ID: <922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>

Hey Ted,
 you sort of answered your own question - the aggregate is announced as an
anycast and the v6 routing table doesn't know where the individual v6
packets are destined.

So the v6 packets find their way to the nearest 6to4 relay, that then
converts to v4 and its routed out as v4. As you say HE is one major sink for
that, as a result of them being so well connected.

Thats one of the downsides with 6to4 - the packet may go in the wrong
direction in v6 before passing through the relay and then heading in the
opposite direction to find the v4 endpoint.

Steve


On Thu, May 14, 2009 at 10:32 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:

> Hi All,
>
>  I apologize in advance if this has been asked before a million times but
> I have what is probably a stupid question about 6to4.
>
>  We are in process of connecting to native IPv6, I am currently getting
> the IPv6 BGP table from our upstream.
>
>  I see that Linksys is supporting IPv6 out-of-the-box in some of it's
> routers, via 6to4
>
>  I figured this might be useful for some of our customers, to setup
> a 6to4 relay router for these Linksys devices to use.  I have found plenty
> of info on the Internet to setup a router as a 6to4 relay.
>
>  My question concerns how exactly 6to4 -works-
>
>  My understanding is that RFC3068 defines 2002:c058:6301:: as the
> anycast for the (in this case) customer router to find the 6to4 relay I
> create.  And that a 6to4 relay then uses a manufactured 2002:: IPv6
> address formed by using it's IPv4 address with the 2002:: prefix, and
> that any 6to4 routers tunneled into it are using their manufactured
> 2002:xxxx:: addresses.
>
>  So, if this is the case then wouldn't every 6to4 relay that's advertising
> on the Intenet be present in the IPv6 BGP table?
>
>  In looking at the various IPv6 looking glasses on the Internet, I see
> a handful of 2002:: routes out there.
>
>  But there seems to be no consistency anywhere.  Most of the looking
> glasses
> seem to show Hurricaine Electric's 2002:: advertisement, including my
> own table.
>
>  But beyond that, the advertisements for other relays seem to exist in
> one router, but not in others.
>
>  Advertisements for native routes do seem to be consistent.
>
>  How exactly do routers know where to forward IPv6 packets destined for
> a given 6to4   2002:: address if there is no route in their table?  And if
> they are just sending 6to4 traffic to HE then how does HE know what to
> do with it if it's not for their network?
>
> Thanks,
> Ted
>
>
>


-- 
Network Operations - Standards & Design
Google Inc.
E: stevewilcox at google.com
M: +44 7920 041930
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090514/7a4b743c/attachment.html 

From martin at airwire.ie  Fri May 15 00:04:31 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Thu, 14 May 2009 23:04:31 +0100
Subject: Question about 6to4
In-Reply-To: <922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>
	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>
Message-ID: <4A0C956F.9060107@airwire.ie>

Steve Wilcox wrote:
> Hey Ted,
>  you sort of answered your own question - the aggregate is announced as an
> anycast and the v6 routing table doesn't know where the individual v6
> packets are destined.
> 
> So the v6 packets find their way to the nearest 6to4 relay, that then
> converts to v4 and its routed out as v4. As you say HE is one major sink for
> that, as a result of them being so well connected.
> 
> Thats one of the downsides with 6to4 - the packet may go in the wrong
> direction in v6 before passing through the relay and then heading in the
> opposite direction to find the v4 endpoint.


And just to add to that, the v4 side works exactly the same. The anycast
prefix there is 192.88.99.0/24.

In our case (we're in Ireland), the relays in our path were in Sweden,
Germany and Italy, which never is a good result, so we set our own
gateway up.

Now, talking about 6to4, 6to4 is never to be preferred. If you can get
people to use native IPv6, you should at any time prefer that solution,
or 6in4 tunnels for that sake.

The issue with 6to4 is exactly it's anycast nature.

Let's say, I'm using 6to4 and I'm connecting t a native IPv6 host. My
traffic goes to the nearest gateway announcing 192.88.99.0/24 and is
translated to IPv6 there. Now the IPv6 host answers, and the answer goes
to it's nearest 6to4 host that announces 2002::/16.

This gateway does not have to be the same as the one I used and if any
one of them is but, nothing works. The issue is, that without having
access to both ends of that connection, I can't even troubleshoot it, so
it's often very difficult to diagnose where things went wrong with 6to4
to solve it.

It is a migration mechanism and nothing more than that. It should be
treated like that.

Kind regards,
Martin List-Petersen


> 
> On Thu, May 14, 2009 at 10:32 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
> 
>> Hi All,
>>
>>  I apologize in advance if this has been asked before a million times but
>> I have what is probably a stupid question about 6to4.
>>
>>  We are in process of connecting to native IPv6, I am currently getting
>> the IPv6 BGP table from our upstream.
>>
>>  I see that Linksys is supporting IPv6 out-of-the-box in some of it's
>> routers, via 6to4
>>
>>  I figured this might be useful for some of our customers, to setup
>> a 6to4 relay router for these Linksys devices to use.  I have found plenty
>> of info on the Internet to setup a router as a 6to4 relay.
>>
>>  My question concerns how exactly 6to4 -works-
>>
>>  My understanding is that RFC3068 defines 2002:c058:6301:: as the
>> anycast for the (in this case) customer router to find the 6to4 relay I
>> create.  And that a 6to4 relay then uses a manufactured 2002:: IPv6
>> address formed by using it's IPv4 address with the 2002:: prefix, and
>> that any 6to4 routers tunneled into it are using their manufactured
>> 2002:xxxx:: addresses.
>>
>>  So, if this is the case then wouldn't every 6to4 relay that's advertising
>> on the Intenet be present in the IPv6 BGP table?
>>
>>  In looking at the various IPv6 looking glasses on the Internet, I see
>> a handful of 2002:: routes out there.
>>
>>  But there seems to be no consistency anywhere.  Most of the looking
>> glasses
>> seem to show Hurricaine Electric's 2002:: advertisement, including my
>> own table.
>>
>>  But beyond that, the advertisements for other relays seem to exist in
>> one router, but not in others.
>>
>>  Advertisements for native routes do seem to be consistent.
>>
>>  How exactly do routers know where to forward IPv6 packets destined for
>> a given 6to4   2002:: address if there is no route in their table?  And if
>> they are just sending 6to4 traffic to HE then how does HE know what to
>> do with it if it's not for their network?
>>
>> Thanks,
>> Ted
>>
>>
>>
> 
> 


-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From alan.batie at peakinternet.com  Fri May 15 00:04:48 2009
From: alan.batie at peakinternet.com (Alan Batie)
Date: Thu, 14 May 2009 15:04:48 -0700
Subject: IPv6 End User Assignments
Message-ID: <4A0C9580.3050409@peakinternet.com>

Steve Bertrand wrote:

> > ... and not enough of the larger (or even small
> > for that matter) *SPs sharing information as to what is currently
> > working for them, and what is not working for them.

FWIW, this is what we're (a small regional ISP) starting to set up and
the thoughts behind it...

> > I don't like /64 where only one subnet is needed, because I've made that
> > mistake before. Inevitably, the site will need more space (says Murphy).
> > I do like /56 for all, unless a /48 can be forseen by yourself as the
> > network op, or warranted immediately by the client.

My feeling is yes /64 is a mistake, but likewise, /48 seems way overkill
for the vast majority of customers.  We have 2607:f678::0/32, which I've
start allocating out (to willing guinea pigs, we're still in the process
of connecting up) with 2607:f678:1::0/36 for our dsl block, with a
default allocation of /60, but with allocations starting from the left,
as I've seen recommended elsewhere, and which I'm pretty sure is SOP:

2607:f678:10::0/60 Cust 1
          11::0/60 Cust 2
...
          1F::0/60
          101::0/60
          102::0/60
...
          10F
...
          1FF
          1001
...

By growing from the left, if any customer needs a larger space, all we
have to do is change the prefix length.  By the time the two ends come
anywhere near meeting (if they ever do), we'll have enough experience to
decide how to handle it.

The main point is that it is easier to shorten a prefix than to lengthen
it, as the latter runs the risk of having to remove service (almost
guaranteed, as customers are likely to follow the left to right
allocation practice as well).  Thus, it seems logical to be conservative
(for a somewhat liberal definition of "conservative") in the initial
allocations since it's nearly trivial to expand them.

Being a small regional provider, we don't have many large enterprise
customers, but for that class, I'd probably break out a separate block,
say 2607:f678:2::0/36 which is allocated similarly but defaulting to /48
to keep from complicating the "small user" space.

The main issue is deciding how wide to spread the "top" --- if it's too
wide, we could fragment our space and some future change in the business
 cause us to have to intermix (e.g. some dsl, some colo), but there's so
much room, it's hard to see that happening: there's still 13 /36's left
in the block to accomodate future needs (using a whole /36 for our
internal use).

If we limit the "small user" space to /56's, that gives us 1M small
users; likewise, the "large user" space gives us 64K /48's (and I can't
see any of them needing more, for most /56 is probably plenty), way more
than we'll ever have in our wildest dreams...

On the other hand, 64K /48's *would* cover our entire customer base
several times over, but it just seems hideously wasteful.  That might
argue for not bothering with the separate "large user" space, but it
just seems administratively cleaner.

From gert at space.net  Fri May 15 00:12:23 2009
From: gert at space.net (Gert Doering)
Date: Fri, 15 May 2009 00:12:23 +0200
Subject: IPv6 End User Assignments
In-Reply-To: <4A0C9580.3050409@peakinternet.com>
References: <4A0C9580.3050409@peakinternet.com>
Message-ID: <20090514221223.GQ2776@Space.Net>

Hi,

On Thu, May 14, 2009 at 03:04:48PM -0700, Alan Batie wrote:
> On the other hand, 64K /48's *would* cover our entire customer base
> several times over, 

So why bother adding extra administrative overhead?

Get rid of that v4 thinking of yours :)

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From tedm at ipinc.net  Fri May 15 00:16:51 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 14 May 2009 15:16:51 -0700
Subject: Question about 6to4
In-Reply-To: <922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>
	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>
Message-ID: <072D03365FF441BCA786599BB791FE7A@tedsdesk>

Ah, I get it now.  So basically in other words if I want to setup a 6to4
relay either I have
to make it private, in which case I will definitely only be de-encapsulating
6to4 traffic that is originating
from my network, or make it public, in which case I will still definitely
only be de-encapsulating
6to4 traffic that is originating from my network, but there is only a small
increased chance that I will
be re-encapsulating incoming traffic to my network and forwarding it to
customers, since it is
completely up to how far my IPv6 advertisement is propagated, but almost
certainly I will be
de-encapsulating traffic for a whole lot of other networks.
 
Am I correct in assuming this is a severe disincentive to putting up IPv6
public relays? ;-)
 
I guess that is why RFC3964 was written.  Looks like the Linksys code is a
dud, then.
 
Ted
 



  _____  

From: ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de
[mailto:ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de] On Behalf Of Steve
Wilcox
Sent: Thursday, May 14, 2009 2:49 PM
To: Ted Mittelstaedt
Cc: ipv6-ops at lists.cluenet.de
Subject: Re: Question about 6to4


Hey Ted,
 you sort of answered your own question - the aggregate is announced as an
anycast and the v6 routing table doesn't know where the individual v6
packets are destined.

So the v6 packets find their way to the nearest 6to4 relay, that then
converts to v4 and its routed out as v4. As you say HE is one major sink for
that, as a result of them being so well connected.

Thats one of the downsides with 6to4 - the packet may go in the wrong
direction in v6 before passing through the relay and then heading in the
opposite direction to find the v4 endpoint.

Steve



On Thu, May 14, 2009 at 10:32 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:


Hi All,

 I apologize in advance if this has been asked before a million times but
I have what is probably a stupid question about 6to4.

 We are in process of connecting to native IPv6, I am currently getting
the IPv6 BGP table from our upstream.

 I see that Linksys is supporting IPv6 out-of-the-box in some of it's
routers, via 6to4

 I figured this might be useful for some of our customers, to setup
a 6to4 relay router for these Linksys devices to use.  I have found plenty
of info on the Internet to setup a router as a 6to4 relay.

 My question concerns how exactly 6to4 -works-

 My understanding is that RFC3068 defines 2002:c058:6301:: as the
anycast for the (in this case) customer router to find the 6to4 relay I
create.  And that a 6to4 relay then uses a manufactured 2002:: IPv6
address formed by using it's IPv4 address with the 2002:: prefix, and
that any 6to4 routers tunneled into it are using their manufactured
2002:xxxx:: addresses.

 So, if this is the case then wouldn't every 6to4 relay that's advertising
on the Intenet be present in the IPv6 BGP table?

 In looking at the various IPv6 looking glasses on the Internet, I see
a handful of 2002:: routes out there.

 But there seems to be no consistency anywhere.  Most of the looking
glasses
seem to show Hurricaine Electric's 2002:: advertisement, including my
own table.

 But beyond that, the advertisements for other relays seem to exist in
one router, but not in others.

 Advertisements for native routes do seem to be consistent.

 How exactly do routers know where to forward IPv6 packets destined for
a given 6to4   2002:: address if there is no route in their table?  And if
they are just sending 6to4 traffic to HE then how does HE know what to
do with it if it's not for their network?

Thanks,
Ted







-- 
Network Operations - Standards & Design
Google Inc.
E: stevewilcox at google.com
M: +44 7920 041930


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090514/df685a4e/attachment-0001.html 

From alan.batie at peakinternet.com  Fri May 15 00:44:27 2009
From: alan.batie at peakinternet.com (Alan Batie)
Date: Thu, 14 May 2009 15:44:27 -0700
Subject: zero suppression vs compression in addresses
Message-ID: <4A0C9ECB.6060301@peakinternet.com>

I think I may have misinterpreted how zero compression and suppression
work:  when I say 2607:f678:1::0/60, I expect the "::" to mean "all 0's
from the preceding digit to the next", but from what I'm seeing
configuring things, (leading) zero *suppression* seems to be happening
at the same time within word (32 bit) boundaries, which colons always
delineate, making that really 2607:f678:0001::0/60.  Thus what I really
wanted to say was 2607:f678:1000::0/60.

From tedm at ipinc.net  Fri May 15 00:47:44 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 14 May 2009 15:47:44 -0700
Subject: Question about 6to4
In-Reply-To: <4A0C956F.9060107@airwire.ie>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>
	<4A0C956F.9060107@airwire.ie>
Message-ID: <C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>

 

> -----Original Message-----
> From: ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de 
> [mailto:ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de] On 
> Behalf Of Martin List-Petersen
> Sent: Thursday, May 14, 2009 3:05 PM
> To: Ted Mittelstaedt
> Cc: ipv6-ops at lists.cluenet.de
> Subject: Re: Question about 6to4
> 
> Steve Wilcox wrote:
> > Hey Ted,
> >  you sort of answered your own question - the aggregate is 
> announced 
> > as an anycast and the v6 routing table doesn't know where the 
> > individual v6 packets are destined.
> > 
> > So the v6 packets find their way to the nearest 6to4 relay, 
> that then 
> > converts to v4 and its routed out as v4. As you say HE is one major 
> > sink for that, as a result of them being so well connected.
> > 
> > Thats one of the downsides with 6to4 - the packet may go in 
> the wrong 
> > direction in v6 before passing through the relay and then 
> heading in 
> > the opposite direction to find the v4 endpoint.
> 
> 
> And just to add to that, the v4 side works exactly the same. 
> The anycast prefix there is 192.88.99.0/24.
> 
> In our case (we're in Ireland), the relays in our path were 
> in Sweden, Germany and Italy, which never is a good result, 
> so we set our own gateway up.
> 
> Now, talking about 6to4, 6to4 is never to be preferred. If 
> you can get people to use native IPv6, you should at any time 
> prefer that solution, or 6in4 tunnels for that sake.
> 

The problem is finding a cheap router costing under $40 that
can be used on the end of a DSL line, and that speaks IPv6 and
is supported from the manufacturer.  Right
now what seems to be the popular route to go is the dd-wrt.com
firmware but all the routers that are in that price range are
4MB flash and will only run the mini loads, not the mega loads
(ie: Linksys WRT54GL, ASUS WL520GU, etc.) and getting IPv6 running
in 4MB on those is a lot of configuration work that I can see
is just waiting to crash and burn and create a support issue.
Going with a better router like in the $80 range is fine for the
small business customers but the residential people won't go for
that unless they are the early adopter/experimenter types.  I
really want to stay in the role of ISP providing the pipe, not
ISP providing the pipe and fixing your $40 router :-(

Ted


From alan.batie at peakinternet.com  Fri May 15 00:49:19 2009
From: alan.batie at peakinternet.com (Alan Batie)
Date: Thu, 14 May 2009 15:49:19 -0700
Subject: IPv6 End User Assignments
In-Reply-To: <20090514221223.GQ2776@Space.Net>
References: <4A0C9580.3050409@peakinternet.com>
	<20090514221223.GQ2776@Space.Net>
Message-ID: <4A0C9FEF.2020402@peakinternet.com>

Gert Doering wrote:

> So why bother adding extra administrative overhead?
> 
> Get rid of that v4 thinking of yours :)

A decade or two won't go down without a fight ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3315 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090514/b103e598/attachment.bin 

From martin at airwire.ie  Fri May 15 01:27:57 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Fri, 15 May 2009 00:27:57 +0100
Subject: Question about 6to4
In-Reply-To: <C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>
	<4A0C956F.9060107@airwire.ie>
	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>
Message-ID: <4A0CA8FD.5040501@airwire.ie>

Ted Mittelstaedt wrote:
> 
> The problem is finding a cheap router costing under $40 that
> can be used on the end of a DSL line, and that speaks IPv6 and
> is supported from the manufacturer.  Right
> now what seems to be the popular route to go is the dd-wrt.com
> firmware but all the routers that are in that price range are
> 4MB flash and will only run the mini loads, not the mega loads
> (ie: Linksys WRT54GL, ASUS WL520GU, etc.) and getting IPv6 running
> in 4MB on those is a lot of configuration work that I can see
> is just waiting to crash and burn and create a support issue.


Correct. That's precisely the issue that every ISP, that currently wants
to deploy IPv6 to end-users is facing. I asked TP-Link at CeBit, when
IPv6 would be available in their routers. The answer was: We have no
plans !!

> Going with a better router like in the $80 range is fine for the
> small business customers but the residential people won't go for
> that unless they are the early adopter/experimenter types.  I
> really want to stay in the role of ISP providing the pipe, not
> ISP providing the pipe and fixing your $40 router :-(

So. We'll have to push the vendors to fix that gap and ask over and over
and over again for IPv6 support. Eventually, they will listen.

Or do it like Free.fr, that has their own R&D, which also requires a
certain amount of funding.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From martin at airwire.ie  Fri May 15 01:29:12 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Fri, 15 May 2009 00:29:12 +0100
Subject: IPv6 End User Assignments
In-Reply-To: <4A0C9FEF.2020402@peakinternet.com>
References: <4A0C9580.3050409@peakinternet.com>	<20090514221223.GQ2776@Space.Net>
	<4A0C9FEF.2020402@peakinternet.com>
Message-ID: <4A0CA948.7060804@airwire.ie>

Alan Batie wrote:
> Gert Doering wrote:
> 
>> So why bother adding extra administrative overhead?
>>
>> Get rid of that v4 thinking of yours :)
> 
> A decade or two won't go down without a fight ;-)

The first decade is gone. And your users can still access IPv4, if you
provide them with a NAT-PT gateway :)

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From alan.batie at peakinternet.com  Fri May 15 01:34:16 2009
From: alan.batie at peakinternet.com (Alan Batie)
Date: Thu, 14 May 2009 16:34:16 -0700
Subject: Question about 6to4
In-Reply-To: <4A0CA8FD.5040501@airwire.ie>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>
	<4A0CA8FD.5040501@airwire.ie>
Message-ID: <4A0CAA78.1060608@peakinternet.com>

Martin List-Petersen wrote:

> So. We'll have to push the vendors to fix that gap and ask over and over
> and over again for IPv6 support. Eventually, they will listen.

It seems to me we're at the egg phase of the chicken problem.  At the
moment, the only "reason" for a residential customer to adopt ipv6 is
because it's cool and geeky.  There's not much they can actually do with
it (even google's site breaks when you have a custom home page there,
and you don't stay in v6 land long when you use it).  The linksys GL
with ddwrt isn't a bad solution for the early adopter phase we're in,
and once enough of those are on board you demonstrate a market for the
vendors to get on board.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3315 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090514/7fec448b/attachment.bin 

From alan.batie at peakinternet.com  Fri May 15 01:45:00 2009
From: alan.batie at peakinternet.com (Alan Batie)
Date: Thu, 14 May 2009 16:45:00 -0700
Subject: IPv6 End User Assignments
In-Reply-To: <4A0CA948.7060804@airwire.ie>
References: <4A0C9580.3050409@peakinternet.com>	<20090514221223.GQ2776@Space.Net>	<4A0C9FEF.2020402@peakinternet.com>
	<4A0CA948.7060804@airwire.ie>
Message-ID: <4A0CACFC.9090105@peakinternet.com>

Martin List-Petersen wrote:

>>> Get rid of that v4 thinking of yours :)
>> A decade or two won't go down without a fight ;-)
> 
> The first decade is gone.

I meant a decade or two of v4 thinking...

> And your users can still access IPv4, if you
> provide them with a NAT-PT gateway :)

We just got our external connection working yesterday ;-)

I'm dual stacking at home; next phase is to link it in, as well as
getting our web server linked in.  With that in place, we can start
getting some usage experience to take the next step...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3315 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090514/d5b9ddd0/attachment-0001.bin 

From martin at airwire.ie  Fri May 15 01:45:43 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Fri, 15 May 2009 00:45:43 +0100
Subject: Question about 6to4
In-Reply-To: <4A0CAA78.1060608@peakinternet.com>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>	<4A0CA8FD.5040501@airwire.ie>
	<4A0CAA78.1060608@peakinternet.com>
Message-ID: <4A0CAD27.20500@airwire.ie>

Alan Batie wrote:
> Martin List-Petersen wrote:
> 
>> So. We'll have to push the vendors to fix that gap and ask over and over
>> and over again for IPv6 support. Eventually, they will listen.
> 
> It seems to me we're at the egg phase of the chicken problem.  At the
> moment, the only "reason" for a residential customer to adopt ipv6 is
> because it's cool and geeky.  There's not much they can actually do with
> it (even google's site breaks when you have a custom home page there,
> and you don't stay in v6 land long when you use it).  The linksys GL
> with ddwrt isn't a bad solution for the early adopter phase we're in,
> and once enough of those are on board you demonstrate a market for the
> vendors to get on board.


There are a few more. m0n0wall will run on pretty much any x86 based
platform and you can configure IPv6 via GUI, it does 6to4, native, 6in4
and SixXS dynamic tunnels, not ayiya, too.

OpenWRT and DD-WRT (haven't looked at them lately) offer IPv6, but no
GUI configuration for it.

There are certain exception releases of routers that do, like the D-Link
DIR-615 rev: C1 (and yes, it's not in rev B or rev D)

The Apple Airport Xtreme does it .. again .. that's the $80+ range and
well, as of recent the lab firmware for the AVM Fritz! routers, but they
are well over $80+

In the end, it could maybe be worth to take the approach like Fon, with
the Fonero routers, that are just the Atheros platform, a modified
version of OpenWRT with custom webinterface, get IPv6 support in there
and get somebody to manufacture a bunch of'em.

Hell .. maybe we should ask Fon to implement V6 in their Fonero and in
return give every user a Fonero with hotspot facility for Fon :)

No, honestly, it is matter of fact just the question of volume. Once one
of the larger ISPs takes the step, it'll be there. Free.fr unfortunately
had their own platform already, so that didn't benefit the market.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From alan.batie at peakinternet.com  Fri May 15 01:49:05 2009
From: alan.batie at peakinternet.com (Alan Batie)
Date: Thu, 14 May 2009 16:49:05 -0700
Subject: Question about 6to4
In-Reply-To: <4A0CAD27.20500@airwire.ie>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>	<4A0CA8FD.5040501@airwire.ie>
	<4A0CAA78.1060608@peakinternet.com> <4A0CAD27.20500@airwire.ie>
Message-ID: <4A0CADF1.9080905@peakinternet.com>

Martin List-Petersen wrote:

> There are a few more. m0n0wall will run on pretty much any x86 based
> platform and you can configure IPv6 via GUI, it does 6to4, native, 6in4
> and SixXS dynamic tunnels, not ayiya, too.

That's actually what I'm running on a soekris (soon to be an alix,
arrives tomorrow) at home, but that's a pricey solution for the general
case.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3315 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090514/4da5fdcd/attachment.bin 

From martin at airwire.ie  Fri May 15 01:52:03 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Fri, 15 May 2009 00:52:03 +0100
Subject: Question about 6to4
In-Reply-To: <4A0CADF1.9080905@peakinternet.com>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>	<4A0CA8FD.5040501@airwire.ie>	<4A0CAA78.1060608@peakinternet.com>
	<4A0CAD27.20500@airwire.ie> <4A0CADF1.9080905@peakinternet.com>
Message-ID: <4A0CAEA3.3060900@airwire.ie>

Alan Batie wrote:
> Martin List-Petersen wrote:
> 
>> There are a few more. m0n0wall will run on pretty much any x86 based
>> platform and you can configure IPv6 via GUI, it does 6to4, native, 6in4
>> and SixXS dynamic tunnels, not ayiya, too.
> 
> That's actually what I'm running on a soekris (soon to be an alix,
> arrives tomorrow) at home, but that's a pricey solution for the general
> case.


Correct. I've got two WRAPs, the version before the ALIX, same platform
as the Soekris, running m0n0wall lying around here.

The interface is nice and it's exactly what would be needed for the
end-user.

All we need to do now, is to find a cheap platform to put it on and get
somebody to flashload the whole she-bang from factory :) The whole end
product for under $40.

Anybody with contacts in China ?

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From surfer at mauigateway.com  Fri May 15 02:28:57 2009
From: surfer at mauigateway.com (Scott Weeks)
Date: Thu, 14 May 2009 17:28:57 -0700
Subject: IPv6 End User Assignments
Message-ID: <20090514172857.415C5D1C@resin17.mta.everyone.net>


--- martin at airwire.ie wrote:
Alan Batie wrote:
> Gert Doering wrote:
> 
>> So why bother adding extra administrative overhead?
>>
>> Get rid of that v4 thinking of yours :)
> 
> A decade or two won't go down without a fight ;-)

The first decade is gone. And your users can still access IPv4, if you
provide them with a NAT-PT gateway :)
----------------------------------------------


You mean Modified NAT-PT?  :-)
http://www.ietf.org/proceedings/08mar/slides/v6ops-1.pdf

scott

From dwhite at olp.net  Fri May 15 02:42:59 2009
From: dwhite at olp.net (Dan White)
Date: Thu, 14 May 2009 19:42:59 -0500
Subject: Question about 6to4
In-Reply-To: <C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>
	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>
Message-ID: <4A0CBA93.4020506@olp.net>

Ted Mittelstaedt wrote:
>
> The problem is finding a cheap router costing under $40 that
> can be used on the end of a DSL line, and that speaks IPv6 and
> is supported from the manufacturer.

The good news is that many ADSL2+ and VDSL2 modems being distributed 
today are based on open source/Linux environments from Broadcom. Upon 
request they must provide source for these modems to you (if you have 
purchased one from them). I recommend a polite, but direct, request for 
their "Consumer BCRM source release".

I've been successful in obtaining Comtrend source for their wireless 
VDSL2 modem (CT-5372), and have been promised source for an ADSL2+ 
modem. Zyxel has also been receptive to requests for source, although I 
haven't received anything yet.

The nice thing about the Consumer source release is that it includes 
pre-compiled binaries for the proprietary Broadcom drivers and apps. 
Within a couple of hours after obtaining it, I had a new firmware 
compiled and installed on the modem.

The source includes:
linux
busybox
bridge-utils
ebtables
iproute2
ipsec-tools
iptables
openssl
zebra
and a few others

which is plenty for implementing an IPv6 router with some modification 
to the build environment.

An easy way to determine if you have a modem/cpe with this environment:

telnet 192.168.1.1
<user>
<pass>
echo `/bin/msh 1>&2`
  or
ping `/bin/msh 1>&2`

to drop into a busybox shell. then take a look in /proc and /etc (if ls 
doesn't exist, do 'cd /etc/', then 'echo *'). Your /etc should look 
something like:

adsl
bandwidth.backup
clink.backup
default.cfg
dhcp
ethertypes
fstab
gateway.conf
group
inetd.conf
init.d
inittab
ipsec.conf
modules_install
passwd
ppp
pppmsg
profile
psk.txt
racoon.conf
resolv.conf
rsa_host_key
services
snmp
sysmsg
udhcpd.conf
udhcpd.leases

I'll try to get the source posted somewhere (it's fairly large).

- Dan

From niels=cluenet at bakker.net  Fri May 15 02:51:36 2009
From: niels=cluenet at bakker.net (niels=cluenet at bakker.net)
Date: Fri, 15 May 2009 02:51:36 +0200
Subject: Question about 6to4
In-Reply-To: <4A0CAD27.20500@airwire.ie>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>
	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>
	<4A0C956F.9060107@airwire.ie>
	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>
	<4A0CA8FD.5040501@airwire.ie>
	<4A0CAA78.1060608@peakinternet.com> <4A0CAD27.20500@airwire.ie>
Message-ID: <20090515005136.GH84365@burnout.tpb.net>

* martin at airwire.ie (Martin List-Petersen) [Fri 15 May 2009, 01:46 CEST]:
>OpenWRT and DD-WRT (haven't looked at them lately) offer IPv6, but 
>no GUI configuration for it.

DD-WRT dumped IPv6 support years ago (after v22; current is v24), 
citing lack of space


	-- Niels.

From alan.batie at peakinternet.com  Fri May 15 03:05:29 2009
From: alan.batie at peakinternet.com (Alan Batie)
Date: Thu, 14 May 2009 18:05:29 -0700
Subject: Question about 6to4
In-Reply-To: <4A0CBA93.4020506@olp.net>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>
	<4A0CBA93.4020506@olp.net>
Message-ID: <4A0CBFD9.4010704@peakinternet.com>

Dan White wrote:

> The good news is that many ADSL2+ and VDSL2 modems being distributed
> today are based on open source/Linux environments from Broadcom.

We just got a response from a vendor (clearaccess) we recently started
migrating to that they don't support ipv6 specifically because the
broadcom chips they use don't support it...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3315 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090514/c9cc44a0/attachment.bin 

From martin at airwire.ie  Fri May 15 03:14:21 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Fri, 15 May 2009 02:14:21 +0100
Subject: Question about 6to4
In-Reply-To: <20090515005136.GH84365@burnout.tpb.net>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>	<4A0CA8FD.5040501@airwire.ie>	<4A0CAA78.1060608@peakinternet.com>
	<4A0CAD27.20500@airwire.ie>
	<20090515005136.GH84365@burnout.tpb.net>
Message-ID: <4A0CC1ED.4060806@airwire.ie>

niels=cluenet at bakker.net wrote:
> * martin at airwire.ie (Martin List-Petersen) [Fri 15 May 2009, 01:46 CEST]:
>> OpenWRT and DD-WRT (haven't looked at them lately) offer IPv6, but no
>> GUI configuration for it.
> 
> DD-WRT dumped IPv6 support years ago (after v22; current is v24), citing
> lack of space
> 

That dumps DD-WRT off the list and into the bin. Lack of addressing,
instead of lack of space :)

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From martin at airwire.ie  Fri May 15 03:15:30 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Fri, 15 May 2009 02:15:30 +0100
Subject: Question about 6to4
In-Reply-To: <4A0CBFD9.4010704@peakinternet.com>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>	<4A0CBA93.4020506@olp.net>
	<4A0CBFD9.4010704@peakinternet.com>
Message-ID: <4A0CC232.8060009@airwire.ie>

Alan Batie wrote:
> Dan White wrote:
> 
>> The good news is that many ADSL2+ and VDSL2 modems being distributed
>> today are based on open source/Linux environments from Broadcom.
> 
> We just got a response from a vendor (clearaccess) we recently started
> migrating to that they don't support ipv6 specifically because the
> broadcom chips they use don't support it...

Lazy excuse you mean. The chips don't care what protocol you run on them.

They guy that answered that, clearly didn't know what he was talking about.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From dougb at dougbarton.us  Fri May 15 03:32:32 2009
From: dougb at dougbarton.us (Doug Barton)
Date: Thu, 14 May 2009 21:32:32 -0400
Subject: Question about 6to4
In-Reply-To: <4A0CAD27.20500@airwire.ie>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>	<4A0CA8FD.5040501@airwire.ie>	<4A0CAA78.1060608@peakinternet.com>
	<4A0CAD27.20500@airwire.ie>
Message-ID: <4A0CC630.4010609@dougbarton.us>

I've used a WRT54G + OpenWRT + HE Tunnel for IPv6 @home for almost a
year now with very good results. OpenWRT runs on lots of other
hardware as well. The link below may be of use.

hth,

Doug

http://www.tunnelbroker.net/forums/index.php?topic=106.0

From dwhite at olp.net  Fri May 15 05:33:54 2009
From: dwhite at olp.net (Dan White)
Date: Thu, 14 May 2009 22:33:54 -0500
Subject: Question about 6to4
In-Reply-To: <4A0CC232.8060009@airwire.ie>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>	<4A0CBA93.4020506@olp.net>	<4A0CBFD9.4010704@peakinternet.com>
	<4A0CC232.8060009@airwire.ie>
Message-ID: <4A0CE2A2.2070402@olp.net>

Martin List-Petersen wrote:
> Alan Batie wrote:
>   
>>
>> We just got a response from a vendor (clearaccess) we recently started
>> migrating to that they don't support ipv6 specifically because the
>> broadcom chips they use don't support it...
>>     
>
> Lazy excuse you mean. The chips don't care what protocol you run on them.
>
> They guy that answered that, clearly didn't know what he was talking about.
>   

Exactly. I've got a Clear Access modem as well. I'll make a request for 
source.

The other primary reason that I started asking for source is that I'm 
convinced that the security model of Broadcom's TR-069 implementation 
(based on their default configs using total predictable credentials) is 
broken. That's a bit off topic though.

- Dan

From bruns at 2mbit.com  Fri May 15 06:47:55 2009
From: bruns at 2mbit.com (Brielle Bruns)
Date: Thu, 14 May 2009 22:47:55 -0600
Subject: Question about 6to4
In-Reply-To: <20090515005136.GH84365@burnout.tpb.net>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>	<4A0CA8FD.5040501@airwire.ie>	<4A0CAA78.1060608@peakinternet.com>
	<4A0CAD27.20500@airwire.ie>
	<20090515005136.GH84365@burnout.tpb.net>
Message-ID: <4A0CF3FB.4090409@2mbit.com>

On 5/14/09 6:51 PM, niels=cluenet at bakker.net wrote:
> * martin at airwire.ie (Martin List-Petersen) [Fri 15 May 2009, 01:46 CEST]:
>> OpenWRT and DD-WRT (haven't looked at them lately) offer IPv6, but no
>> GUI configuration for it.
>
> DD-WRT dumped IPv6 support years ago (after v22; current is v24), citing
> lack of space
>
>
> -- Niels.


Thats not true - if you get the std nokaid version, the module for ipv6 
is present, you just need to load it and configure it via the 
shell/command line.  IIRC, the mega versions also include it as well.





-- 
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org    /     http://www.ahbl.org

From kloch at kl.net  Fri May 15 07:00:39 2009
From: kloch at kl.net (Kevin Loch)
Date: Fri, 15 May 2009 01:00:39 -0400
Subject: Question about 6to4
In-Reply-To: <922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>
	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>
Message-ID: <4A0CF6F7.403@kl.net>

Steve Wilcox wrote:

> Thats one of the downsides with 6to4 - the packet may go in the wrong 
> direction in v6 before passing through the relay and then heading in the 
> opposite direction to find the v4 endpoint.

This is why it is best for both ends to be as close to a relay as
possible.  Route efficiency should be vastly better for the "real"
endpoint IPs than for the few public relays that will likely involve a
significant detour.

I can't recommend the proliferation of public relays as they
cause more problems than they solve.  Private relays are another
story as they help mitigate the problems of the anycast relays.  If
every service provider ran private 6to4 relays for their customers
it would be a Good Thing.

- Kevin

From ek at google.com  Fri May 15 07:19:50 2009
From: ek at google.com (Erik Kline)
Date: Thu, 14 May 2009 22:19:50 -0700
Subject: Question about 6to4
In-Reply-To: <4A0CF6F7.403@kl.net>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>
	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>
	<4A0CF6F7.403@kl.net>
Message-ID: <2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com>

2009/5/14 Kevin Loch <kloch at kl.net>

> Steve Wilcox wrote:
>
>  Thats one of the downsides with 6to4 - the packet may go in the wrong
>> direction in v6 before passing through the relay and then heading in the
>> opposite direction to find the v4 endpoint.
>>
>
> This is why it is best for both ends to be as close to a relay as
> possible.  Route efficiency should be vastly better for the "real"
> endpoint IPs than for the few public relays that will likely involve a
> significant detour.
>
> I can't recommend the proliferation of public relays as they
> cause more problems than they solve.  Private relays are another
> story as they help mitigate the problems of the anycast relays.  If
> every service provider ran private 6to4 relays for their customers
> it would be a Good Thing.
>
> - Kevin
>

The problem is that only addresses half the flow.  You've succeeded in
helping your customers get their packets onto the IPv6 Internet efficiently
(yay!).  But to get them back 1 of 2 things needs to happen:

    (1) Every content provider/destination needs to have good, and
preferably local, access to a 2002::/16 return device so it can re-encap the
packets and send them to their IPv4 origin.  Otherwise they go off into
wherever 2002:/16 happens to point at that time.

Obviously, this doesn't scale so well.

    (2) You attempt to advertise your own IPv4 networks under 2002::/16,
thereby adding portions of the IPv4 routing table into IPv6  (assuming you
could even get anything longer than a /32 past everyone's filters).

This also doesn't scale.

Unfortunately Lorenzo's latest presentation from RIPE 58 isn't up, but in it
he showed how we see roughly ~100msec extra latency with the various relay
mechanisms like 6to4 and Teredo over native and static tunnel methods.

Personally, I'm a fan of 6rd.  That's what works for free.fr.  That, or just
go native.

2c,
-Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090514/970ab5fd/attachment.html 

From stevel at dedicatedservers.net.au  Fri May 15 07:27:12 2009
From: stevel at dedicatedservers.net.au (Steven Lisson)
Date: Fri, 15 May 2009 15:27:12 +1000
Subject: Question about 6to4
In-Reply-To: <2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com>
Message-ID: <C035DD0A88EFF241A24578B7B8D5B505015DF565@intranet.mail.hostingshop.com.au>

Hi,

 

Do not advertise anything more specific than 2002::/16, it is specific
in the RFC that this is not allowed to prevent BGP table bloat. You
either advertise 2002::/16 or nothing.

 

6to4 is a transition mechanism, we don't want the ipv6 bgp table
becoming twice the size with hosts advertising both their IPv6
allocation and any 6to4 addresses from their IPv4 allocations.

 

Regards,

Steven

 

________________________________

From: ipv6-ops-bounces+stevel=dedicatedservers.net.au at lists.cluenet.de
[mailto:ipv6-ops-bounces+stevel=dedicatedservers.net.au at lists.cluenet.de
] On Behalf Of Erik Kline
Sent: Friday, 15 May 2009 3:20 PM
To: Kevin Loch
Cc: ipv6-ops at lists.cluenet.de
Subject: Re: Question about 6to4

 

 

2009/5/14 Kevin Loch <kloch at kl.net>

Steve Wilcox wrote:

Thats one of the downsides with 6to4 - the packet may go in the wrong
direction in v6 before passing through the relay and then heading in the
opposite direction to find the v4 endpoint.

 

This is why it is best for both ends to be as close to a relay as
possible.  Route efficiency should be vastly better for the "real"
endpoint IPs than for the few public relays that will likely involve a
significant detour.

I can't recommend the proliferation of public relays as they
cause more problems than they solve.  Private relays are another
story as they help mitigate the problems of the anycast relays.  If
every service provider ran private 6to4 relays for their customers
it would be a Good Thing.

- Kevin


The problem is that only addresses half the flow.  You've succeeded in
helping your customers get their packets onto the IPv6 Internet
efficiently (yay!).  But to get them back 1 of 2 things needs to happen:

    (1) Every content provider/destination needs to have good, and
preferably local, access to a 2002::/16 return device so it can re-encap
the packets and send them to their IPv4 origin.  Otherwise they go off
into wherever 2002:/16 happens to point at that time.

Obviously, this doesn't scale so well.

    (2) You attempt to advertise your own IPv4 networks under 2002::/16,
thereby adding portions of the IPv4 routing table into IPv6  (assuming
you could even get anything longer than a /32 past everyone's filters).

This also doesn't scale.

Unfortunately Lorenzo's latest presentation from RIPE 58 isn't up, but
in it he showed how we see roughly ~100msec extra latency with the
various relay mechanisms like 6to4 and Teredo over native and static
tunnel methods.

Personally, I'm a fan of 6rd.  That's what works for free.fr.  That, or
just go native.

2c,
-Erik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090515/d35a14a7/attachment-0001.html 

From ek at google.com  Fri May 15 07:43:27 2009
From: ek at google.com (Erik Kline)
Date: Thu, 14 May 2009 22:43:27 -0700
Subject: Question about 6to4
In-Reply-To: <C035DD0A88EFF241A24578B7B8D5B505015DF565@intranet.mail.hostingshop.com.au>
References: <2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com>
	<C035DD0A88EFF241A24578B7B8D5B505015DF565@intranet.mail.hostingshop.com.au>
Message-ID: <2e8c64260905142243i3049b0b8ya5af8fd2361c43fd@mail.gmail.com>

I certainly wasn't advocating it.  Just pointing out how futile it is.

2009/5/14 Steven Lisson <stevel at dedicatedservers.net.au>

>  Hi,
>
>
>
> Do not advertise anything more specific than 2002::/16, it is specific in
> the RFC that this is not allowed to prevent BGP table bloat. You either
> advertise 2002::/16 or nothing.
>
>
>
> 6to4 is a transition mechanism, we don?t want the ipv6 bgp table becoming
> twice the size with hosts advertising both their IPv6 allocation and any
> 6to4 addresses from their IPv4 allocations.
>
>
>
> Regards,
>
> Steven
>
>
>  ------------------------------
>
> *From:* ipv6-ops-bounces+stevel=dedicatedservers.net.au at lists.cluenet.de[mailto:
> ipv6-ops-bounces+stevel <ipv6-ops-bounces%2Bstevel>=
> dedicatedservers.net.au at lists.cluenet.de] *On Behalf Of *Erik Kline
> *Sent:* Friday, 15 May 2009 3:20 PM
> *To:* Kevin Loch
> *Cc:* ipv6-ops at lists.cluenet.de
> *Subject:* Re: Question about 6to4
>
>
>
>
>
> 2009/5/14 Kevin Loch <kloch at kl.net>
>
> Steve Wilcox wrote:
>
> Thats one of the downsides with 6to4 - the packet may go in the wrong
> direction in v6 before passing through the relay and then heading in the
> opposite direction to find the v4 endpoint.
>
>
>
> This is why it is best for both ends to be as close to a relay as
> possible.  Route efficiency should be vastly better for the "real"
> endpoint IPs than for the few public relays that will likely involve a
> significant detour.
>
> I can't recommend the proliferation of public relays as they
> cause more problems than they solve.  Private relays are another
> story as they help mitigate the problems of the anycast relays.  If
> every service provider ran private 6to4 relays for their customers
> it would be a Good Thing.
>
> - Kevin
>
>
> The problem is that only addresses half the flow.  You've succeeded in
> helping your customers get their packets onto the IPv6 Internet efficiently
> (yay!).  But to get them back 1 of 2 things needs to happen:
>
>     (1) Every content provider/destination needs to have good, and
> preferably local, access to a 2002::/16 return device so it can re-encap the
> packets and send them to their IPv4 origin.  Otherwise they go off into
> wherever 2002:/16 happens to point at that time.
>
> Obviously, this doesn't scale so well.
>
>     (2) You attempt to advertise your own IPv4 networks under 2002::/16,
> thereby adding portions of the IPv4 routing table into IPv6  (assuming you
> could even get anything longer than a /32 past everyone's filters).
>
> This also doesn't scale.
>
> Unfortunately Lorenzo's latest presentation from RIPE 58 isn't up, but in
> it he showed how we see roughly ~100msec extra latency with the various
> relay mechanisms like 6to4 and Teredo over native and static tunnel methods.
>
> Personally, I'm a fan of 6rd.  That's what works for free.fr.  That, or
> just go native.
>
> 2c,
> -Erik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090514/1ebad2ee/attachment.html 

From martin at airwire.ie  Fri May 15 13:34:38 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Fri, 15 May 2009 12:34:38 +0100
Subject: Question about 6to4
In-Reply-To: <2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0CF6F7.403@kl.net>
	<2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com>
Message-ID: <4A0D534E.60306@airwire.ie>

Erik Kline wrote:
> Personally, I'm a fan of 6rd.  That's what works for free.fr.  That, or just
> go native.

The issue with 6rd is, that it's consuming extreme amounts of IP's.
Free.fr got a /26 IPv6 allocated just to do this for all of their customers.

Native, this probably could have been done well within a /32 or /30 at
the most.

So I wouldn't even try to advocate to go down the route, that Free did
and use 6rd.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From dr at cluenet.de  Fri May 15 14:30:18 2009
From: dr at cluenet.de (Daniel Roesen)
Date: Fri, 15 May 2009 14:30:18 +0200
Subject: zero suppression vs compression in addresses
In-Reply-To: <4A0C9ECB.6060301@peakinternet.com>
References: <4A0C9ECB.6060301@peakinternet.com>
Message-ID: <20090515123018.GA2378@srv03.cluenet.de>

On Thu, May 14, 2009 at 03:44:27PM -0700, Alan Batie wrote:
> I think I may have misinterpreted how zero compression and suppression
> work:  when I say 2607:f678:1::0/60, I expect the "::" to mean "all 0's
> from the preceding digit to the next", but from what I'm seeing
> configuring things, (leading) zero *suppression* seems to be happening
> at the same time within word (32 bit) boundaries, which colons always
> delineate, making that really 2607:f678:0001::0/60.  Thus what I really
> wanted to say was 2607:f678:1000::0/60.

Correct. The double-colon form replaces 1-n 32-bit "words" of zeros.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0

From drake at begriffli.ch  Fri May 15 14:52:32 2009
From: drake at begriffli.ch (Drake Wilson)
Date: Fri, 15 May 2009 07:52:32 -0500
Subject: zero suppression vs compression in addresses
In-Reply-To: <20090515123018.GA2378@srv03.cluenet.de>
References: <4A0C9ECB.6060301@peakinternet.com>
	<20090515123018.GA2378@srv03.cluenet.de>
Message-ID: <20090515125232.GA1977@drache.begriffli.ch>

Quoth Daniel Roesen <dr at cluenet.de>, on 2009-05-15 14:30:18 +0200:
> On Thu, May 14, 2009 at 03:44:27PM -0700, Alan Batie wrote:
> > (leading) zero *suppression* seems to be happening
> > at the same time within word (32 bit) boundaries, which colons always
> > delineate, making that really 2607:f678:0001::0/60.  Thus what I really
> > wanted to say was 2607:f678:1000::0/60.
> 
> Correct. The double-colon form replaces 1-n 32-bit "words" of zeros.

16-bit, no?  E.g., 2001:db8:1122:3344:5566:: uses a trailing
double-colon for the last 48 bits.

> Best regards,
> Daniel

   ---> Drake Wilson

From michael.dillon at bt.com  Fri May 15 15:00:57 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 15 May 2009 14:00:57 +0100
Subject: zero suppression vs compression in addresses
In-Reply-To: <4A0C9ECB.6060301@peakinternet.com>
Message-ID: <28E139F46D45AF49A31950F88C49745801214653@E03MVZ2-UKDY.domain1.systemhost.net>


> I think I may have misinterpreted how zero compression and suppression
> work:  when I say 2607:f678:1::0/60, I expect the "::" to 
> mean "all 0's from the preceding digit to the next", but from 
> what I'm seeing configuring things, (leading) zero 
> *suppression* seems to be happening at the same time within 
> word (32 bit) boundaries, which colons always delineate, 
> making that really 2607:f678:0001::0/60.  Thus what I really 
> wanted to say was 2607:f678:1000::0/60.

The rules on this may be about to change. See this draft:
<http://tools.ietf.org/search/draft-kawamura-ipv6-text-representation-02
>

--Michael Dillon
 

From jabley at hopcount.ca  Fri May 15 15:33:12 2009
From: jabley at hopcount.ca (Joe Abley)
Date: Fri, 15 May 2009 16:33:12 +0300
Subject: zero suppression vs compression in addresses
In-Reply-To: <28E139F46D45AF49A31950F88C49745801214653@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745801214653@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <8396B579-162B-4320-B5FE-15A17F3F526A@hopcount.ca>


On 15-May-2009, at 16:00, <michael.dillon at bt.com>  
<michael.dillon at bt.com> wrote:

>> I think I may have misinterpreted how zero compression and  
>> suppression
>> work:  when I say 2607:f678:1::0/60, I expect the "::" to
>> mean "all 0's from the preceding digit to the next", but from
>> what I'm seeing configuring things, (leading) zero
>> *suppression* seems to be happening at the same time within
>> word (32 bit) boundaries, which colons always delineate,
>> making that really 2607:f678:0001::0/60.  Thus what I really
>> wanted to say was 2607:f678:1000::0/60.
>
> The rules on this may be about to change. See this draft:
> http://tools.ietf.org/search/draft-kawamura-ipv6-text- 
> representation-02

Unless I am missing some text, that document is promoting a canonical  
representation for presentation of addresses, not changing the rules  
by which addresses are parsed.


Joe


From gert at space.net  Fri May 15 16:57:49 2009
From: gert at space.net (Gert Doering)
Date: Fri, 15 May 2009 16:57:49 +0200
Subject: IPv6 End User Assignments
In-Reply-To: <4A0CACFC.9090105@peakinternet.com>
References: <4A0C9580.3050409@peakinternet.com>
	<20090514221223.GQ2776@Space.Net>
	<4A0C9FEF.2020402@peakinternet.com> <4A0CA948.7060804@airwire.ie>
	<4A0CACFC.9090105@peakinternet.com>
Message-ID: <20090515145749.GU2776@Space.Net>

Hi,

On Thu, May 14, 2009 at 04:45:00PM -0700, Alan Batie wrote:
> We just got our external connection working yesterday ;-)

Congratulations! :)

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From kloch at kl.net  Fri May 15 16:59:16 2009
From: kloch at kl.net (Kevin Loch)
Date: Fri, 15 May 2009 10:59:16 -0400
Subject: Question about 6to4
In-Reply-To: <2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0CF6F7.403@kl.net>
	<2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com>
Message-ID: <4A0D8344.50304@kl.net>

Erik Kline wrote:

> 2009/5/14 Kevin Loch <kloch at kl.net <mailto:kloch at kl.net>>

>     I can't recommend the proliferation of public relays as they
>     cause more problems than they solve.  Private relays are another
>     story as they help mitigate the problems of the anycast relays.  If
>     every service provider ran private 6to4 relays for their customers
>     it would be a Good Thing.
> 
>     - Kevin
> 
> 
> The problem is that only addresses half the flow.  You've succeeded in 
> helping your customers get their packets onto the IPv6 Internet 
> efficiently (yay!).  But to get them back 1 of 2 things needs to happen:
> 
>     (1) Every content provider/destination needs to have good, and 
> preferably local, access to a 2002::/16 return device so it can re-encap 
> the packets and send them to their IPv4 origin.  Otherwise they go off 
> into wherever 2002:/16 happens to point at that time.
> 
> Obviously, this doesn't scale so well.

Actually, that is exactly what I meant.  ISP's and hosting/content
providers should have local 192.88.99.0/24 and 2002::/16 relays
whenever possible.  Every relay closer to the endpoints helps.

The more IPv6 is deployed and used the larger the
6to4 problems will become.  Eventually running local 6to4
relays will need to be as common as local DNS resolvers.

- Kevin

From martin at airwire.ie  Fri May 15 17:04:08 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Fri, 15 May 2009 16:04:08 +0100
Subject: Question about 6to4
In-Reply-To: <4A0D8344.50304@kl.net>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0CF6F7.403@kl.net>	<2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com>
	<4A0D8344.50304@kl.net>
Message-ID: <4A0D8468.2070605@airwire.ie>

Kevin Loch wrote:
> Erik Kline wrote:
> 
>> 2009/5/14 Kevin Loch <kloch at kl.net <mailto:kloch at kl.net>>
> 
>>     I can't recommend the proliferation of public relays as they
>>     cause more problems than they solve.  Private relays are another
>>     story as they help mitigate the problems of the anycast relays.  If
>>     every service provider ran private 6to4 relays for their customers
>>     it would be a Good Thing.
>>
>>     - Kevin
>>
>>
>> The problem is that only addresses half the flow.  You've succeeded in
>> helping your customers get their packets onto the IPv6 Internet
>> efficiently (yay!).  But to get them back 1 of 2 things needs to happen:
>>
>>     (1) Every content provider/destination needs to have good, and
>> preferably local, access to a 2002::/16 return device so it can
>> re-encap the packets and send them to their IPv4 origin.  Otherwise
>> they go off into wherever 2002:/16 happens to point at that time.
>>
>> Obviously, this doesn't scale so well.
> 
> Actually, that is exactly what I meant.  ISP's and hosting/content
> providers should have local 192.88.99.0/24 and 2002::/16 relays
> whenever possible.  Every relay closer to the endpoints helps.
> 
> The more IPv6 is deployed and used the larger the
> 6to4 problems will become.  Eventually running local 6to4
> relays will need to be as common as local DNS resolvers.

Please combine that with a teredo/miredo relay. Most of the 6to4 traffic
to date comes from teredo and back.

But as such, yes, at an optimum and until we get rid of 6to4, that would
be the scenario.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From dr at cluenet.de  Fri May 15 17:11:31 2009
From: dr at cluenet.de (Daniel Roesen)
Date: Fri, 15 May 2009 17:11:31 +0200
Subject: zero suppression vs compression in addresses
In-Reply-To: <20090515125232.GA1977@drache.begriffli.ch>
References: <4A0C9ECB.6060301@peakinternet.com>
	<20090515123018.GA2378@srv03.cluenet.de>
	<20090515125232.GA1977@drache.begriffli.ch>
Message-ID: <20090515151131.GA989@srv03.cluenet.de>

On Fri, May 15, 2009 at 07:52:32AM -0500, Drake Wilson wrote:
> > Correct. The double-colon form replaces 1-n 32-bit "words" of zeros.
> 
> 16-bit, no?  E.g., 2001:db8:1122:3344:5566:: uses a trailing
> double-colon for the last 48 bits.

Of course, sorry for confusion. 1-n aligned 16-bit groups.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0

From a at foo.be  Fri May 15 17:20:54 2009
From: a at foo.be (Alexandre Dulaunoy)
Date: Fri, 15 May 2009 17:20:54 +0200
Subject: IPv6 End User Assignments
In-Reply-To: <20090514172857.415C5D1C@resin17.mta.everyone.net>
References: <20090514172857.415C5D1C@resin17.mta.everyone.net>
Message-ID: <1baa801f0905150820k6199d730i2072f138ed4fdac@mail.gmail.com>

On Fri, May 15, 2009 at 2:28 AM, Scott Weeks <surfer at mauigateway.com> wrote:

> You mean Modified NAT-PT? ?:-)
> http://www.ietf.org/proceedings/08mar/slides/v6ops-1.pdf

Is there an official free software/open source implementation
of the Modified NAT-PT?

The old Korean implementation seems a bit unmaintained.

Regarding NAT-64 (replacing NAT-PT?) , I have a similar question.
Is there a free software/open source implementation of NAT-64?

This is often one of the blocking point for IPv6-only satellite[1] terminal
that would still need to reach IPv4 networks.

[1] A free software/open source implementation would help some
satellite hub vendors to implement it.

-- 
--                   Alexandre Dulaunoy (adulau) -- http://www.foo.be/
--                             http://www.foo.be/cgi-bin/wiki.pl/Diary
--         "Knowledge can create problems, it is not through ignorance
--                                that we can solve them" Isaac Asimov

From tedm at ipinc.net  Fri May 15 18:52:22 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 15 May 2009 09:52:22 -0700
Subject: Question about 6to4
In-Reply-To: <4A0CAA78.1060608@peakinternet.com>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk><4A0CA8FD.5040501@airwire.ie>
	<4A0CAA78.1060608@peakinternet.com>
Message-ID: <F719F2E855FA42E1A0C518B372CE2395@tedsdesk>

 

> -----Original Message-----
> From: ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de 
> [mailto:ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de] On 
> Behalf Of Alan Batie
> Sent: Thursday, May 14, 2009 4:34 PM
> To: ipv6-ops at lists.cluenet.de
> Subject: Re: Question about 6to4
> 
> Martin List-Petersen wrote:
> 
> > So. We'll have to push the vendors to fix that gap and ask over and 
> > over and over again for IPv6 support. Eventually, they will listen.
> 
> It seems to me we're at the egg phase of the chicken problem. 
>  At the moment, the only "reason" for a residential customer 
> to adopt ipv6 is because it's cool and geeky.  There's not 
> much they can actually do with it (even google's site breaks 
> when you have a custom home page there, and you don't stay in 
> v6 land long when you use it).  The linksys GL with ddwrt 
> isn't a bad solution for the early adopter phase we're in, 
> and once enough of those are on board you demonstrate a 
> market for the vendors to get on board.
> 

Most early residential adopters are going to have a few extra
PC's sitting around that they can run FreeBSD or Linux on, which
make far more flexible IPv6 routers.

The hardware routers AKA Buffalo, Linksys, etc. are mainly useful
when your dropping a router at a residence where the residents don't
know jack about networking and don't want to know about it.  That's
why the necessity is for something that's corporate-standardized and
supported.

Ted


From dwhite at olp.net  Fri May 15 18:58:36 2009
From: dwhite at olp.net (Dan White)
Date: Fri, 15 May 2009 11:58:36 -0500
Subject: Question about 6to4
In-Reply-To: <4A0CBA93.4020506@olp.net>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>
	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>
	<4A0CBA93.4020506@olp.net>
Message-ID: <4A0D9F3C.4050604@olp.net>

Dan White wrote:
> Ted Mittelstaedt wrote:
>>
>> The problem is finding a cheap router costing under $40 that
>> can be used on the end of a DSL line, and that speaks IPv6 and
>> is supported from the manufacturer.
>
> The good news is that many ADSL2+ and VDSL2 modems being distributed 
> today are based on open source/Linux environments from Broadcom. 
As a followup - Zyxel released source for one of their modems:

ftp://opensource.zyxel.com/P-663H-51/

- Dan

From tedm at ipinc.net  Fri May 15 19:21:08 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 15 May 2009 10:21:08 -0700
Subject: Question about 6to4
In-Reply-To: <4A0D8468.2070605@airwire.ie>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0CF6F7.403@kl.net>	<2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com><4A0D8344.50304@kl.net>
	<4A0D8468.2070605@airwire.ie>
Message-ID: <7505DCB083E8464EA2BB3E83FF2E7C4D@tedsdesk>

 

> -----Original Message-----
> From: ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de 
> [mailto:ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de] On 
> Behalf Of Martin List-Petersen
> Sent: Friday, May 15, 2009 8:04 AM
> To: Kevin Loch
> Cc: ipv6-ops at lists.cluenet.de
> Subject: Re: Question about 6to4
> 
> Kevin Loch wrote:
> > Erik Kline wrote:
> > 
> >> 2009/5/14 Kevin Loch <kloch at kl.net <mailto:kloch at kl.net>>
> > 
> >>     I can't recommend the proliferation of public relays as they
> >>     cause more problems than they solve.  Private relays 
> are another
> >>     story as they help mitigate the problems of the 
> anycast relays.  If
> >>     every service provider ran private 6to4 relays for 
> their customers
> >>     it would be a Good Thing.
> >>
> >>     - Kevin
> >>
> >>
> >> The problem is that only addresses half the flow.  You've 
> succeeded 
> >> in helping your customers get their packets onto the IPv6 Internet 
> >> efficiently (yay!).  But to get them back 1 of 2 things 
> needs to happen:
> >>
> >>     (1) Every content provider/destination needs to have good, and 
> >> preferably local, access to a 2002::/16 return device so it can 
> >> re-encap the packets and send them to their IPv4 origin.  
> Otherwise 
> >> they go off into wherever 2002:/16 happens to point at that time.
> >>
> >> Obviously, this doesn't scale so well.
> > 
> > Actually, that is exactly what I meant.  ISP's and hosting/content 
> > providers should have local 192.88.99.0/24 and 2002::/16 relays 
> > whenever possible.  Every relay closer to the endpoints helps.
> > 
> > The more IPv6 is deployed and used the larger the
> > 6to4 problems will become.  Eventually running local 6to4 
> relays will 
> > need to be as common as local DNS resolvers.
> 
> Please combine that with a teredo/miredo relay. Most of the 
> 6to4 traffic to date comes from teredo and back.
> 
> But as such, yes, at an optimum and until we get rid of 6to4, 
> that would be the scenario.
> 

The ONLY reason I was even looking at 6to4 was because Linksys
supported it in their corporate firmware load on the RVS 4000 which
is one of the few really cheap routers on the market that has
full stateful inspection, can block p2p protocols by looking at
the data payload, and does a lot of way-cool stuff that is really
essential for a small business.  Stuff that you CANNOT do on a
dd-wrt load on a sub-$40 low-flash router. I had thought
that such support might indicate they would migrate 6to4 downward
to their cheap products.

But, after understanding how it works, it is just not worth pursuing.

I see this as a chicken-and-egg issue.  Linksys won't migrate 6to4
down to their cheap product unless a lot of ISP's start fielding
6to4 gateways.

However, the 6to4 system design takes so much control of where the
traffic routes away from ISP's that nobody looking at this from
a business perspective could possibly support the scheme.  The
largest amount of ISP network support for end users deals with the "last
mile" the traffic path from your peers to their desktop.  With 6to4 you
now have user's return traffic streams passing through gateways you have
no control over, from hosts you have very little control over, and by
the time it's passed from a peer to you, there's been far more
chances to screw it up than a usual IPv4 packet.

I could just see me calling Paypal for example and telling them that
they have to contact Hurricaine Electric and tell HE to fix a routing
problem because one of my customers is having trouble logging onto
Paypal's IPv6 server.  That conversation would be a true exercise in
futility because anybody at Paypal who really understood the problem
would just laugh and tell me that my network shortcomings that are
making me push my customer to use 6to4 to begin with, are not their
problem, and if I ran native IPv6 to my customer they would help me,
otherwise, kiss off.

6to4 isn't a transition mechanism, it's a laboratory experiment that
escaped from the lab and is being supported by a few die-hard techs who
have no understanding of business.  Seriously!!!

I'd much rather see ISP's deploying IPv6, such as the ISP I work for,
strongly discourage 6to4 so that vendors like Linksys don't take
development time away from incorporating native IPv6.

Ted


From martin at airwire.ie  Fri May 15 19:22:36 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Fri, 15 May 2009 18:22:36 +0100
Subject: IPv6 End User Assignments
In-Reply-To: <1baa801f0905150820k6199d730i2072f138ed4fdac@mail.gmail.com>
References: <20090514172857.415C5D1C@resin17.mta.everyone.net>
	<1baa801f0905150820k6199d730i2072f138ed4fdac@mail.gmail.com>
Message-ID: <4A0DA4DC.2020008@airwire.ie>

Alexandre Dulaunoy wrote:
> On Fri, May 15, 2009 at 2:28 AM, Scott Weeks <surfer at mauigateway.com> wrote:
> 
>> You mean Modified NAT-PT?  :-)
>> http://www.ietf.org/proceedings/08mar/slides/v6ops-1.pdf
> 
> Is there an official free software/open source implementation
> of the Modified NAT-PT?
> 
> The old Korean implementation seems a bit unmaintained.
> 
> Regarding NAT-64 (replacing NAT-PT?) , I have a similar question.
> Is there a free software/open source implementation of NAT-64?

Nothing that works(tm). I'm using a Cisco 2620XM for now, which is sort
of rated for 15 mbit/s cef forwarding max.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From martin at airwire.ie  Fri May 15 19:27:16 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Fri, 15 May 2009 18:27:16 +0100
Subject: Question about 6to4
In-Reply-To: <7505DCB083E8464EA2BB3E83FF2E7C4D@tedsdesk>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0CF6F7.403@kl.net>	<2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com><4A0D8344.50304@kl.net>
	<4A0D8468.2070605@airwire.ie>
	<7505DCB083E8464EA2BB3E83FF2E7C4D@tedsdesk>
Message-ID: <4A0DA5F4.9010208@airwire.ie>

Ted Mittelstaedt wrote:
> 6to4 isn't a transition mechanism, it's a laboratory experiment that
> escaped from the lab and is being supported by a few die-hard techs who
> have no understanding of business.  Seriously!!!

This is unfortunatly where you are going ENTIRELY wrong. The issue is
something different.

Every Windows XP, Vista, 7 box out, every Mac OS X box, that has IPv6
enabled uses either teredo, when it gets a non-public IPv4 or 6to4, when
it gets a public IPv4, unless it gets a proper IPv6 address assigned
either statically, via router advertisements or via DHCPv6.

This means, that you have 6to4 and teredo traffic on your network
already, if you want it or not.

This has nothing to do with understanding a business or not. That's the
pure and utter fact.

Ever checked your netflows for proto 41 traffic ?

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From tedm at ipinc.net  Fri May 15 19:47:39 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 15 May 2009 10:47:39 -0700
Subject: Question about 6to4
In-Reply-To: <20090515005136.GH84365@burnout.tpb.net>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com><4A0C956F.9060107@airwire.ie><C81D786EB1F94499AE960899C0AD3A5E@tedsdesk><4A0CA8FD.5040501@airwire.ie><4A0CAA78.1060608@peakinternet.com>
	<4A0CAD27.20500@airwire.ie>
	<20090515005136.GH84365@burnout.tpb.net>
Message-ID: <BC3525E2339345D4AD452F156FD363A8@tedsdesk>

 

> -----Original Message-----
> From: ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de 
> [mailto:ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de] On 
> Behalf Of niels=cluenet at bakker.net
> Sent: Thursday, May 14, 2009 5:52 PM
> To: ipv6-ops at lists.cluenet.de
> Subject: Re: Question about 6to4
> 
> * martin at airwire.ie (Martin List-Petersen) [Fri 15 May 2009, 
> 01:46 CEST]:
> >OpenWRT and DD-WRT (haven't looked at them lately) offer 
> IPv6, but no 
> >GUI configuration for it.
> 
> DD-WRT dumped IPv6 support years ago (after v22; current is 
> v24), citing lack of space
> 
> 

Only in the micro loads.  DD-wrt started out on the Linksys WRT54G
routers and over the years as sales volume of these units increased,
very minor cost-cutting measures became able to yield major amounts
of money.  One of these was cutting the amount of flash in the router
from 4MB to 2MB, all newer 54G routers past version 7 I think, have
the smaller amount of flash.

In response to this dd-wrt released the micro load of firmware which
not only dropped the IPv6 module, it dropped basic commands like ls

Linksys then proceeded to release a version of the 54G with model # of
wrt54GL  (trailing L) that retained the 4MB of flash, this was aimed
at dd-wrt users.  While it doesn't cost more, it is never sold through
retail so your never going to see it discounted with an on-sale price
like you see the 54G on sale from time to time.

Ted



From alan.batie at peakinternet.com  Fri May 15 19:55:36 2009
From: alan.batie at peakinternet.com (Alan Batie)
Date: Fri, 15 May 2009 10:55:36 -0700
Subject: zero suppression vs compression in addresses
In-Reply-To: <20090515125232.GA1977@drache.begriffli.ch>
References: <4A0C9ECB.6060301@peakinternet.com>	<20090515123018.GA2378@srv03.cluenet.de>
	<20090515125232.GA1977@drache.begriffli.ch>
Message-ID: <4A0DAC98.3050403@peakinternet.com>

Drake Wilson wrote:

> 16-bit, no?  E.g., 2001:db8:1122:3344:5566:: uses a trailing
> double-colon for the last 48 bits.

doh! Yes, I meant 16-bit...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3315 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090515/a432d189/attachment.bin 

From nicholas.hatch at gmail.com  Fri May 15 20:05:04 2009
From: nicholas.hatch at gmail.com (nick hatch)
Date: Fri, 15 May 2009 11:05:04 -0700
Subject: Question about 6to4
In-Reply-To: <BC3525E2339345D4AD452F156FD363A8@tedsdesk>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>
	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com> 
	<4A0C956F.9060107@airwire.ie>
	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk> 
	<4A0CA8FD.5040501@airwire.ie> <4A0CAA78.1060608@peakinternet.com> 
	<4A0CAD27.20500@airwire.ie> <20090515005136.GH84365@burnout.tpb.net> 
	<BC3525E2339345D4AD452F156FD363A8@tedsdesk>
Message-ID: <a71460720905151105h3b155063h5493787b746ccb8a@mail.gmail.com>

On Fri, May 15, 2009 at 10:47 AM, Ted Mittelstaedt <tedm at ipinc.net> wrote:

>
>
> > -----Original Message-----
> > From: ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de
> > [mailto:ipv6-ops-bounces+tedm <ipv6-ops-bounces%2Btedm>=ipinc.net@
> lists.cluenet.de] On
> > Behalf Of niels=cluenet at bakker.net
> > Sent: Thursday, May 14, 2009 5:52 PM
> > To: ipv6-ops at lists.cluenet.de
> > Subject: Re: Question about 6to4
> >
> > * martin at airwire.ie (Martin List-Petersen) [Fri 15 May 2009,
> > 01:46 CEST]:
> > >OpenWRT and DD-WRT (haven't looked at them lately) offer
> > IPv6, but no
> > >GUI configuration for it.
> >
> > DD-WRT dumped IPv6 support years ago (after v22; current is
> > v24), citing lack of space
> >
> >
>
> Only in the micro loads.


I'm no DD-WRT expert, but having recently jumped through the hoops to get a
tunnel up and running, I think it's important to point out what qualifies as
IPv6 support in DD-WRT... It's not pretty, it's not point and click, and you
won't be configuring it from the GUI.

The v24 IPv6 support means that the required kernel modules are available to
load (by you), routes can be configured (manually), and you can get IPv6
working without having to recompile the firmware. For an example of the type
of configuration required, see this post:
http://dd-wrt.com/phpBB2/viewtopic.php?p=190390#190390

For a service provider, you'd might as well go back to OpenWRT and start
there for R&D. As an "early adopting" home user, I'm planning on getting an
Alix box up and running: I'd rather be using OpenBSD/pf anyways. Embedded
devices are only fun to play with for so long, unless you like jffs and
praying to the gods for an extra kilobyte or two.

-Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090515/e3d71440/attachment.html 

From tvest at pch.net  Fri May 15 20:14:32 2009
From: tvest at pch.net (Tom Vest)
Date: Fri, 15 May 2009 14:14:32 -0400
Subject: Factors,
	actions influencing the possibility/timing of IDR for IPv6-based
	routing domains?
Message-ID: <04BBB069-AF1B-4B20-8A0B-1B94F528147C@pch.net>

Hi all,

Would be very grateful for assistance from list members.... apologies  
for any duplication...

I'm trying to compile a list of environmental factors or actions that  
might affect the probability and timing of direct participation in  
interdomain routing becoming practical, specifically for routing  
domains that start out with some IPv6 but without even one publicly  
routable IPv4 address.

The question I'd like help with is: what individual actions -- either  
undertaken directly by the aspiring IDR participant, or by the  
operators of other, established routing domains --  could directly or  
indirectly impact the probability, timing, and extent of this becoming  
generally possible?

Please note (if it wasn't already obvious) that I'm *not* talking  
about the possibility of becoming a pure/direct customer of another  
routing service provider, nor am I asking/making presumptions about  
IDR-related activities that are not commonplace, much less  
"guaranteed" for routing service providers in general (ubiquitous  
settlement-free peering, etc.). The basic idea is that there is a  
range of "normal" or "conventional" activities that operators of  
routing domains may choose to participate in today (e.g., exchanging  
traffic, indirectly or directly, potentially with most if all other  
routing domains; participating as a third party in traffic exchange  
between other routing domains -- aka providing transit; pursuing,  
accepting, and/or rejecting direct and indirect traffic exchange  
relationships; influencing traffic flows across those  
interconnections, etc.), none of which would be possible today for an  
operator of a pure IPv6-based (or any post-IPv4 runout) routing  
domain. The question is: what's going to change that?

My current provisional list of things that might incrementally change  
that includes:

1. New entrant(s) obtain an independently routable quantity of IPv4  
from someone/somewhere, which can be used to mediate traffic exchange  
between internal IPv6-based resources and external IPv4-based network  
elements.
2. Existing, IPv4-based routing domains offer native IPv6-based IP  
transit that is physically accessible by the aspiring new entrant(s).
3. Existing, Pv4-based routing service providers begin to accommodate  
incremental growth of existing and new customers using IPv6 *in a way  
that makes those new elements transparently reachable via native IPv6- 
based IDR.*
4. Existing, Pv4-based routing domains make some or all of their  
current, public-facing resources reachable via native IPv6-based IDR.

What else should be on the list? Additional comments, questions, or  
suggestions would be greatly appreciated!

Thanks in advance,

TV










  

From niels=cluenet at bakker.net  Fri May 15 20:21:48 2009
From: niels=cluenet at bakker.net (niels=cluenet at bakker.net)
Date: Fri, 15 May 2009 20:21:48 +0200
Subject: Question about 6to4
In-Reply-To: <BC3525E2339345D4AD452F156FD363A8@tedsdesk>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>
	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>
	<4A0C956F.9060107@airwire.ie>
	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>
	<4A0CA8FD.5040501@airwire.ie>
	<4A0CAA78.1060608@peakinternet.com> <4A0CAD27.20500@airwire.ie>
	<20090515005136.GH84365@burnout.tpb.net>
	<BC3525E2339345D4AD452F156FD363A8@tedsdesk>
Message-ID: <20090515182147.GL84365@burnout.tpb.net>

>> DD-WRT dumped IPv6 support years ago (after v22; current is 
>> v24), citing lack of space

* tedm at ipinc.net (Ted Mittelstaedt) [Fri 15 May 2009, 19:48 CEST]:
>Only in the micro loads.

Actually, no: 
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=79003&sid=0eaa669d3c866ba125b8392eb7256fc2#79003

Although support was recently reintroduced for the bigger builds 
according to other posts in that forum, 
http://www.dd-wrt.com/phpBB2/viewtopic.php?t=34022 
but I cannot verify that on any std image of DD-WRT I have running 
(as in: no file on the FS with ipv6 in its name).  And of course 
you can build your own custom firmware based on it.  Or hack a bit: 
http://www.dd-wrt.com/wiki/index.php/IPv6_on_v24


[..]
>Linksys then proceeded to release a version of the 54G with model # of 
>wrt54GL  (trailing L) that retained the 4MB of flash, this was aimed 
>at dd-wrt users.  While it doesn't cost more, it is never sold through 
>retail so your never going to see it discounted with an on-sale price 
>like you see the 54G on sale from time to time.

It is easily available here in western Europe though does generally cost 
more (EUR 70 vs 50, generally).  Of course, these days nobody buys non-N 
anymore so *shrug*


	-- Niels.

From charles at thewybles.com  Fri May 15 20:22:23 2009
From: charles at thewybles.com (Charles Wyble)
Date: Fri, 15 May 2009 11:22:23 -0700
Subject: tunneling native v6  connectivity
Message-ID: <4A0DB2DF.8080106@thewybles.com>

All,

I have a Linux virtual machine in the UK which has native v6 
connectivity. (a /64). I'm also doing some consulting for a virtual 
server vendor in the United States on providing v6 in their offering.

I would like to tunnel native v6 connectivity to my house from my 
virtual server. I realize it won't be the best performance, but it's an 
experiment/lab environment. I have already been using some he.net 
tunnels for a while.


What would people recommend for this? I was thinking of using OpenVPN 
and Vyatta.



From tedm at ipinc.net  Fri May 15 20:35:54 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 15 May 2009 11:35:54 -0700
Subject: Question about 6to4
In-Reply-To: <4A0DA5F4.9010208@airwire.ie>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0CF6F7.403@kl.net>	<2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com><4A0D8344.50304@kl.net>
	<4A0D8468.2070605@airwire.ie>
	<7505DCB083E8464EA2BB3E83FF2E7C4D@tedsdesk>
	<4A0DA5F4.9010208@airwire.ie>
Message-ID: <9989EF840A1D45B0B96C3E3C95252557@tedsdesk>

 

> -----Original Message-----
> From: Martin List-Petersen [mailto:martin at airwire.ie] 
> Sent: Friday, May 15, 2009 10:27 AM
> To: Ted Mittelstaedt
> Cc: ipv6-ops at lists.cluenet.de
> Subject: Re: Question about 6to4
> 
> Ted Mittelstaedt wrote:
> > 6to4 isn't a transition mechanism, it's a laboratory 
> experiment that 
> > escaped from the lab and is being supported by a few die-hard techs 
> > who have no understanding of business.  Seriously!!!
> 
> This is unfortunatly where you are going ENTIRELY wrong. The 
> issue is something different.
> 
> Every Windows XP, Vista, 7 box out, every Mac OS X box, that 
> has IPv6 enabled uses either teredo, when it gets a 
> non-public IPv4 or 6to4, when it gets a public IPv4, unless 
> it gets a proper IPv6 address assigned either statically, via 
> router advertisements or via DHCPv6.
> 
> This means, that you have 6to4 and teredo traffic on your 
> network already, if you want it or not.
> 
> This has nothing to do with understanding a business or not. 
> That's the pure and utter fact.
> 
> Ever checked your netflows for proto 41 traffic ?
> 

Your missing the point.  To put it very simply, it is clear in looking
at 6to4 that there is at least equally if not more work involved in
making a 6to4 private relay a supported product offering than just making
native IPv6 a supported product offering.

What OUR goal is, is when that first customer calls us asking
for 6to4 support, we can tell him that we don't support 6to4 because we
offer native IPv6.  Of course, that does not mean I won't reserve the right
to run a 6to4 private relay for my own amusement, (because I am a die-hard
tech after all ;-)) and if customers discover it and are able to make use of
it, great.  Just don't expect support, and also expect that when I
get bored with it, it might go away if it starts sucking my time.

Beyond that, from a business point of view I don't give a rat's ass if
customers we have now are currently running
6to4.  They are doing this to get access to IPv6, and I'm pretty confident
that any of them who are doing this will immediately chuck out that 6to4
stuff when they know they can get native IPv6.

The only possible stumbling block would be is if the router they are using
doesn't route IPv6 natively and only supports 6to4.  But if that is the
case,
then our decision is that they can either toss away the router they have
and get one that supports native routing, whereupon they can get support
from
us, or they can continue to use 6to4 and NOT get any support from us.


Ted


From martin at airwire.ie  Fri May 15 20:45:28 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Fri, 15 May 2009 19:45:28 +0100
Subject: Question about 6to4
In-Reply-To: <9989EF840A1D45B0B96C3E3C95252557@tedsdesk>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0CF6F7.403@kl.net>	<2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com><4A0D8344.50304@kl.net>
	<4A0D8468.2070605@airwire.ie>
	<7505DCB083E8464EA2BB3E83FF2E7C4D@tedsdesk>
	<4A0DA5F4.9010208@airwire.ie>
	<9989EF840A1D45B0B96C3E3C95252557@tedsdesk>
Message-ID: <4A0DB848.4090408@airwire.ie>

Ted Mittelstaedt wrote:
> Your missing the point.  To put it very simply, it is clear in looking
> at 6to4 that there is at least equally if not more work involved in
> making a 6to4 private relay a supported product offering than just making
> native IPv6 a supported product offering.

Correct. It's not in any way or will ever be a supported product offering.

The only ISP that has gone down to route (so far and hopefully it'll
stay like that) is free.fr and that's because they changed it in a way
where they were using their own brand CPE and their own prefix for the
adressing only using the 6to4 mechanisms. Essentially staying in charge
of both ends of the translation. It's called 6rd.

[snip]

> Beyond that, from a business point of view I don't give a rat's ass if
> customers we have now are currently running
> 6to4.  They are doing this to get access to IPv6, and I'm pretty confident
> that any of them who are doing this will immediately chuck out that 6to4
> stuff when they know they can get native IPv6.

There is no way from a business perspective to support 6to4. Everybody
who has tried to look at it should know that. It's a best effort, no
SLA, service, that allows users, who don't have the choice of native
IPv6 to get using IPv6. That's all and nothing else.


> The only possible stumbling block would be is if the router they are using
> doesn't route IPv6 natively and only supports 6to4.  But if that is the
> case,
> then our decision is that they can either toss away the router they have
> and get one that supports native routing, whereupon they can get support
> from
> us, or they can continue to use 6to4 and NOT get any support from us.

The better solution here is to offer them 6in4 tunnels. Basically a
tunnelbroker setup. We have a SixXS PoP in house, that allows for
static, dynamic or AYIYA (nat-piercing) tunnels. The difference to 6to4
is, that there is a common translation point: our PoP.

The tunnel could worst case be initiated from their PC.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From tedm at ipinc.net  Fri May 15 20:57:24 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 15 May 2009 11:57:24 -0700
Subject: Question about 6to4
In-Reply-To: <a71460720905151105h3b155063h5493787b746ccb8a@mail.gmail.com>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>
	<4A0C956F.9060107@airwire.ie><C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>
	<4A0CA8FD.5040501@airwire.ie>
	<4A0CAA78.1060608@peakinternet.com> <4A0CAD27.20500@airwire.ie>
	<20090515005136.GH84365@burnout.tpb.net>
	<BC3525E2339345D4AD452F156FD363A8@tedsdesk>
	<a71460720905151105h3b155063h5493787b746ccb8a@mail.gmail.com>
Message-ID: <D93CE2A00D1D4231A34F1409E0FCE289@tedsdesk>

I've looked at OpenWRT and in fact I even set aside a spare WRT to load it.
Unfortunately
when I found myself referring back to the dd-wrt website for instructions on
flashing
openwrt I put that project on the back burner.  The dd-wrt people seem to
have a lot
better handle on basics like different hardware revisions of the linksys
devices will
require different flashing procedures, and bugs exist that are tickled on
some hardware
platforms but not others.
 
openwrt is kind of like the tomato project - they assume everyone has the
exact same
box.  I would still like to try it out one of these days, but the openwrt
people really need
to clean that mess of a website of theirs up because right now it's
extremely time
consuming to find out anything about the project from it.
 
As far as difficulty of configuring dd-wrt, that's not really a concern
since it's only difficult
to figure out how to configure it the first time - after that, you have a
template you work from
and you just clone the configuration from box to box, and the only real
concern is the amount
of time you spend modifying the off-the-shelf box to the preconfigured box
that your selling
to your customers.  It doesn't bother me if the end users
can't make head or tail out of a command line, in fact that's probably a
good thing since it
will keep them out of the box and keep them from messing it up.
 
What matters the most here is reliability and price.  I've got a $49.95
dd-wrt box at home
with a 250 day uptime that used to have an average 7-day uptime before I
loaded dd-wrt on it.
That's a terrifically powerful argument to using it.
 
Ted



  _____  

From: ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de
[mailto:ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de] On Behalf Of nick
hatch
Sent: Friday, May 15, 2009 11:05 AM
To: ipv6-ops at lists.cluenet.de
Subject: Re: Question about 6to4


On Fri, May 15, 2009 at 10:47 AM, Ted Mittelstaedt <tedm at ipinc.net> wrote:




> -----Original Message-----
> From: ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de
> [mailto:ipv6-ops-bounces+tedm <mailto:ipv6-ops-bounces%2Btedm>
=ipinc.net at lists.cluenet.de] On

> Behalf Of niels=cluenet at bakker.net
> Sent: Thursday, May 14, 2009 5:52 PM
> To: ipv6-ops at lists.cluenet.de
> Subject: Re: Question about 6to4
>

> * martin at airwire.ie (Martin List-Petersen) [Fri 15 May 2009,
> 01:46 CEST]:
> >OpenWRT and DD-WRT (haven't looked at them lately) offer
> IPv6, but no
> >GUI configuration for it.
>
> DD-WRT dumped IPv6 support years ago (after v22; current is
> v24), citing lack of space
>
>


Only in the micro loads.  


I'm no DD-WRT expert, but having recently jumped through the hoops to get a
tunnel up and running, I think it's important to point out what qualifies as
IPv6 support in DD-WRT... It's not pretty, it's not point and click, and you
won't be configuring it from the GUI.

The v24 IPv6 support means that the required kernel modules are available to
load (by you), routes can be configured (manually), and you can get IPv6
working without having to recompile the firmware. For an example of the type
of configuration required, see this post:
http://dd-wrt.com/phpBB2/viewtopic.php?p=190390#190390 


For a service provider, you'd might as well go back to OpenWRT and start
there for R&D. As an "early adopting" home user, I'm planning on getting an
Alix box up and running: I'd rather be using OpenBSD/pf anyways. Embedded
devices are only fun to play with for so long, unless you like jffs and
praying to the gods for an extra kilobyte or two.

-Nick


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090515/a92b9bd6/attachment.html 

From tedm at ipinc.net  Fri May 15 21:11:09 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 15 May 2009 12:11:09 -0700
Subject: Question about 6to4
In-Reply-To: <4A0DB848.4090408@airwire.ie>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0CF6F7.403@kl.net>	<2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com><4A0D8344.50304@kl.net>
	<4A0D8468.2070605@airwire.ie>
	<7505DCB083E8464EA2BB3E83FF2E7C4D@tedsdesk>
	<4A0DA5F4.9010208@airwire.ie>
	<9989EF840A1D45B0B96C3E3C95252557@tedsdesk>
	<4A0DB848.4090408@airwire.ie>
Message-ID: <7F33E13BD0304B0084A15DA04A1CC783@tedsdesk>

 

> -----Original Message-----
> From: Martin List-Petersen [mailto:martin at airwire.ie] 
> Sent: Friday, May 15, 2009 11:45 AM
> To: Ted Mittelstaedt
> Cc: ipv6-ops at lists.cluenet.de
> Subject: Re: Question about 6to4
> 
> 
> 
> The better solution here is to offer them 6in4 tunnels. 
> Basically a tunnelbroker setup. We have a SixXS PoP in house, 
> that allows for static, dynamic or AYIYA (nat-piercing) 
> tunnels. 

What do you use for this, Linux on a PC or a hardware device
of some sort?

> The difference to 6to4 is, that there is a common 
> translation point: our PoP.
> 
> The tunnel could worst case be initiated from their PC.
> 

My preference is to do as little as possible on the end user
host.  What works the best is if you can tell them to open a command
prompt and ping w.x.y.z  or ping 2001:xxxx:xxxx:xxxx  whatever
and have that work.  If we have to get beyond doing that, it's
money lost (both labor and overhead) on 
a connectivity issue that could end up being that their kids
downloaded some porno the night before the put a trojan on
their PC.  Or, they didn't enable automatic updates and their
system got a virus.

The cheap residential router with native IPv6 is really the best solution.
We recommend these for every IPv4 customer, including the ones with a
single PC.  On occasion we get a call from a customer who has a
system that is literally so crapped up that it cannot even ping
the local router anymore.  Believe it or not it is actually
cheaper for a tech to stop by their house, plug in a laptop
to the router, demonstrate the circuit and Internet works perfectly,
then leave them to decide where they are going to take their
PC to get it decontaminated.  At most, one of those stops takes
20 minutes, plus maybe another 10 minutes on the initial call
that determines they are a hopeless case.  Over the phone I've seen
these support calls stretch over an hour or more.

Ted


From martin at airwire.ie  Fri May 15 21:15:56 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Fri, 15 May 2009 20:15:56 +0100
Subject: Question about 6to4
In-Reply-To: <7F33E13BD0304B0084A15DA04A1CC783@tedsdesk>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0CF6F7.403@kl.net>	<2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com><4A0D8344.50304@kl.net>
	<4A0D8468.2070605@airwire.ie>
	<7505DCB083E8464EA2BB3E83FF2E7C4D@tedsdesk>
	<4A0DA5F4.9010208@airwire.ie>
	<9989EF840A1D45B0B96C3E3C95252557@tedsdesk>
	<4A0DB848.4090408@airwire.ie>
	<7F33E13BD0304B0084A15DA04A1CC783@tedsdesk>
Message-ID: <4A0DBF6C.2040506@airwire.ie>

Ted Mittelstaedt wrote:
>>
>> The better solution here is to offer them 6in4 tunnels. 
>> Basically a tunnelbroker setup. We have a SixXS PoP in house, 
>> that allows for static, dynamic or AYIYA (nat-piercing) 
>> tunnels. 
> 
> What do you use for this, Linux on a PC or a hardware device
> of some sort?


A lot of devices support 6in4 tunnels. For SixXS we use a Linux based
box.  Cisco does 6in4, too, just not the nat-piercing protocol.

>> The difference to 6to4 is, that there is a common 
>> translation point: our PoP.
>>
>> The tunnel could worst case be initiated from their PC.
>>
> 
> My preference is to do as little as possible on the end user
> host.  What works the best is if you can tell them to open a command
> prompt and ping w.x.y.z  or ping 2001:xxxx:xxxx:xxxx  whatever
> and have that work.  If we have to get beyond doing that, it's
> money lost (both labor and overhead) on 
> a connectivity issue that could end up being that their kids
> downloaded some porno the night before the put a trojan on
> their PC.  Or, they didn't enable automatic updates and their
> system got a virus.
> 
> The cheap residential router with native IPv6 is really the best solution.
> We recommend these for every IPv4 customer, including the ones with a
> single PC.  On occasion we get a call from a customer who has a
> system that is literally so crapped up that it cannot even ping
> the local router anymore.  Believe it or not it is actually
> cheaper for a tech to stop by their house, plug in a laptop
> to the router, demonstrate the circuit and Internet works perfectly,
> then leave them to decide where they are going to take their
> PC to get it decontaminated.  At most, one of those stops takes
> 20 minutes, plus maybe another 10 minutes on the initial call
> that determines they are a hopeless case.  Over the phone I've seen
> these support calls stretch over an hour or more.

Again, OpenWRT, DD-WRT etc. support 6in4 also. So you could initiate the
6in4 tunnel from a router like that and give the customer on the
lan-port native. Same issue as before though.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From jay at impulse.net  Fri May 15 22:20:02 2009
From: jay at impulse.net (Jay Hennigan)
Date: Fri, 15 May 2009 13:20:02 -0700
Subject: Question about 6to4
In-Reply-To: <4A0CAD27.20500@airwire.ie>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>	<4A0CA8FD.5040501@airwire.ie>	<4A0CAA78.1060608@peakinternet.com>
	<4A0CAD27.20500@airwire.ie>
Message-ID: <4A0DCE72.6030505@impulse.net>

Martin List-Petersen wrote:

> 
> There are a few more. m0n0wall will run on pretty much any x86 based
> platform and you can configure IPv6 via GUI, it does 6to4, native, 6in4
> and SixXS dynamic tunnels, not ayiya, too.
> 
> OpenWRT and DD-WRT (haven't looked at them lately) offer IPv6, but no
> GUI configuration for it.

Do they support V6DHCP?

> There are certain exception releases of routers that do, like the D-Link
> DIR-615 rev: C1 (and yes, it's not in rev B or rev D)

Same question.

> The Apple Airport Xtreme does it .. again .. that's the $80+ range and
> well, as of recent the lab firmware for the AVM Fritz! routers, but they
> are well over $80+

Are you sure the Apple Airport supports native?  I'm aware that it does 
tunnels, also same question for V6DHCP.

We're providing a V6DHCP /56 to home DSL users, and the only CPE that 
supports dual-stack with V6DHCP I've found is the Cisco 8XX series.  Not 
really practical for the masses.

-- 
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

From tedm at ipinc.net  Sat May 16 00:41:48 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 15 May 2009 15:41:48 -0700
Subject: Factors, actions influencing the possibility/timing of IDR for
	IPv6-basedrouting domains?
In-Reply-To: <04BBB069-AF1B-4B20-8A0B-1B94F528147C@pch.net>
References: <04BBB069-AF1B-4B20-8A0B-1B94F528147C@pch.net>
Message-ID: <3E8BEB47BAAC4480A53CE6AF3D3FDC08@tedsdesk>


Here is how I envision this thing happening.  You can adjust the
dates as you see fit.

Sometime in 2013 IANA and rest of the RIR's run out of "virgin IPv4".  The
general news media starts making a big deal out of it.  Many ISP's who
had no clue will get clueful.  ARIN will embark on "low-hanging-fruit"
reclamation projects to attempt to pull back abandoned IPv4.  This will
satisfy the smaller requestors.  The larger requestors (eg. Comcast) will
embark on "internal IPv4 reclamation" projects.  The Internet will still
generally run on IPv4.  Cell phone providers will begin heavily deploying
IPv6 along with IPv6-IPv4 proxy systems

Between the years of 2013 and 2015 the RIR's will gradually exhaust 
"low-hanging-fruit" IPv4 reclamation projects and a paid, transfer market
in IPv4 will arise.  By 2017 this transfer market will be in full swing
and it will be regarded as customary for "aspiring IDR participants" to
purchase IPv4 blocks.  Large orgs will be in full swing with internal IPv4
reclamation projects, both for their own needs and to sell to newcomers.
Content providers who run websites will be heavily pressured to connect to
the IPv6 network.

By 2020 we will see the end of the transfer market as price increases
push block prices to the point that they will never be able to generate
a return on investment.  By now, all orgs will be deploying IPv6 as SOP for
"native" IP connectivity, along
with RFC1918 addresses for IPv4 connectivity, or extra-cost public IPv4.
Small orgs will likely be doing the same as well as heavy experimentation
and use of web and other proxies to get IPv6 assigned address customers to
IPv4 providers on the Internet.  Large orgs will have forced all major
content providers to offer content via IPv6 in addition to IPv4

>From 2020 to 2025 will be the IPv4 end game.  The paid transfer market
will have collapsed and no large requestors will be asking for IPv4 from
the RIR's.  We will have the appearance of IPv6-only content providers,
and this trend will accelerate.  New IDR participants likely will be
only requesting nominal amounts of IPv4 to assist in accessing the
remaining content providers who haven't switched.

By 2025 everyone offering a website on the Internet will be IPv6.  An
increasing number of Internet customers will decline even the free
RFC1918 IPv4 addressing.  Gaps and issues with route propagation of the
IPv4 BGP table will become increasingly regular.

By 2030 IPv4 will have been reduced to a handful of sites still advertising
it mainly because they have not bothered to clean up their internal
networks.
A majority of transit AS's will be actively filtering IPv4 advertisements.
IPv4 will essentially be dead.


So, in answer to your question of:

"...what individual actions 
 -- either undertaken directly by the aspiring IDR 
 participant, or by the operators of other, established 
 routing domains --  could directly or indirectly impact the 
 probability, timing, and extent of this becoming generally possible?

I would say:

GIVE AWAY SERVICE.

Sign up more customers.  Get people on the Internet who are not
currently on the Internet.  What ultimately pushes IPv6 is 
a shortage of IPv4, and the only thing that creates this is
consumption of IPv4.

This is likely why the United States is going to have the worst
time to switch to IPv6.  We have likely reached saturation for
the Internet market, and thus everyone in the country already has
an IPv4 address.  What is going to drive the US to IPv6 is the
rest of the world offering content on IPv6 and US customers wanting
to get at it.  Unfortunately, the US is the largest supplier of
content in the world, as George Carlin used to say:

"America's most profitable business is still the manufacture,
packaging, distribution and marketing of bullshit"
---George Carlin: "You Are All Diseased (1999)"

Ted

> -----Original Message-----
> From: ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de 
> [mailto:ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de] On 
> Behalf Of Tom Vest
> Sent: Friday, May 15, 2009 11:15 AM
> To: IPv6 Ops list
> Subject: Factors,actions influencing the possibility/timing 
> of IDR for IPv6-basedrouting domains?
> 
> Hi all,
> 
> Would be very grateful for assistance from list members.... 
> apologies for any duplication...
> 
> I'm trying to compile a list of environmental factors or 
> actions that might affect the probability and timing of 
> direct participation in interdomain routing becoming 
> practical, specifically for routing domains that start out 
> with some IPv6 but without even one publicly routable IPv4 address.
> 
> The question I'd like help with is: what individual actions 
> -- either undertaken directly by the aspiring IDR 
> participant, or by the operators of other, established 
> routing domains --  could directly or indirectly impact the 
> probability, timing, and extent of this becoming generally possible?
> 
> Please note (if it wasn't already obvious) that I'm *not* 
> talking about the possibility of becoming a pure/direct 
> customer of another routing service provider, nor am I 
> asking/making presumptions about IDR-related activities that 
> are not commonplace, much less "guaranteed" for routing 
> service providers in general (ubiquitous settlement-free 
> peering, etc.). The basic idea is that there is a range of 
> "normal" or "conventional" activities that operators of 
> routing domains may choose to participate in today (e.g., 
> exchanging traffic, indirectly or directly, potentially with 
> most if all other routing domains; participating as a third 
> party in traffic exchange between other routing domains -- 
> aka providing transit; pursuing, accepting, and/or rejecting 
> direct and indirect traffic exchange relationships; 
> influencing traffic flows across those interconnections, 
> etc.), none of which would be possible today for an operator 
> of a pure IPv6-based (or any post-IPv4 runout) routing 
> domain. The question is: what's going to change that?
> 
> My current provisional list of things that might 
> incrementally change that includes:
> 
> 1. New entrant(s) obtain an independently routable quantity 
> of IPv4 from someone/somewhere, which can be used to mediate 
> traffic exchange between internal IPv6-based resources and 
> external IPv4-based network elements.
> 2. Existing, IPv4-based routing domains offer native 
> IPv6-based IP transit that is physically accessible by the 
> aspiring new entrant(s).
> 3. Existing, Pv4-based routing service providers begin to 
> accommodate incremental growth of existing and new customers 
> using IPv6 *in a way that makes those new elements 
> transparently reachable via native IPv6- based IDR.* 4. 
> Existing, Pv4-based routing domains make some or all of their 
> current, public-facing resources reachable via native IPv6-based IDR.
> 
> What else should be on the list? Additional comments, 
> questions, or suggestions would be greatly appreciated!
> 
> Thanks in advance,
> 
> TV
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   
> 


From steve at ibctech.ca  Sat May 16 01:56:31 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 15 May 2009 19:56:31 -0400
Subject: Question about 6to4
In-Reply-To: <4A0DCE72.6030505@impulse.net>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>	<4A0CA8FD.5040501@airwire.ie>	<4A0CAA78.1060608@peakinternet.com>	<4A0CAD27.20500@airwire.ie>
	<4A0DCE72.6030505@impulse.net>
Message-ID: <4A0E012F.4070109@ibctech.ca>

Jay Hennigan wrote:
> Martin List-Petersen wrote:
> 
>>
>> There are a few more. m0n0wall will run on pretty much any x86 based
>> platform and you can configure IPv6 via GUI, it does 6to4, native, 6in4
>> and SixXS dynamic tunnels, not ayiya, too.
>>
>> OpenWRT and DD-WRT (haven't looked at them lately) offer IPv6, but no
>> GUI configuration for it.
> 
> Do they support V6DHCP?
> 
>> There are certain exception releases of routers that do, like the D-Link
>> DIR-615 rev: C1 (and yes, it's not in rev B or rev D)
> 
> Same question.
> 
>> The Apple Airport Xtreme does it .. again .. that's the $80+ range and
>> well, as of recent the lab firmware for the AVM Fritz! routers, but they
>> are well over $80+
> 
> Are you sure the Apple Airport supports native?  I'm aware that it does
> tunnels, also same question for V6DHCP.
> 
> We're providing a V6DHCP /56 to home DSL users, and the only CPE that
> supports dual-stack with V6DHCP I've found is the Cisco 8XX series.  Not
> really practical for the masses.

For resi CPE, we use Ovislink ADSL NAT gateways.

They have generally been quite receptive to listen to software change
requests in the past (and we only buy ~40/month). We do not send out any
CPE to resi clients that isn't configured with PPPoE and NAT, which
saves us obvious headaches down the road (well, double-NAT is off-topic
here).

Their equipment uses Busybox. Thanks to Dan White's post, I was able to
verify that ``ifconfig'' took an IPv6 assignment command without error,
but it didn't show up in the config afterward.

Does anyone else use Ovislink products for their resi DSL subs? The gear
is in the price range we are after, and I'm sure it wouldn't take much
for them to add in v6 support if a few of us went with the request together.

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090515/a7498619/attachment.bin 

From jay at west.net  Sat May 16 02:24:22 2009
From: jay at west.net (Jay Hennigan)
Date: Fri, 15 May 2009 17:24:22 -0700
Subject: zero suppression vs compression in addresses
In-Reply-To: <4A0C9ECB.6060301@peakinternet.com>
References: <4A0C9ECB.6060301@peakinternet.com>
Message-ID: <4A0E07B6.3040109@west.net>

Alan Batie wrote:
> I think I may have misinterpreted how zero compression and suppression
> work:  when I say 2607:f678:1::0/60, I expect the "::" to mean "all 0's
> from the preceding digit to the next", but from what I'm seeing
> configuring things, (leading) zero *suppression* seems to be happening
> at the same time within word (32 bit) boundaries, which colons always
> delineate, making that really 2607:f678:0001::0/60.  Thus what I really
> wanted to say was 2607:f678:1000::0/60.

1.  IPv6 addresses are 128 bits, written as eight quads of hex digits. 
Each quad is delimited by a colon.

2.  Within each quad, leading zeros may be dropped, but (for this step) 
if a quad is all zeros leave a single zero.

3. After doing this, if one or more successive quads is zero, that group 
of zeros can be replaced with a double colon, BUT only one double colon 
can appear per address.

(You can reverse steps 2 and 3 if you choose)

So, if you have:

2001:0030:0000:0000:02a4:0000:0000:00d3

    it becomes

2001:30:0:0:2a4:0:0:d3

Which can EITHER be expressed as

2001:30::2a4:0:0:d3

        OR

2001:30:0:0:2a4::d3

     BUT NOT

2001:30::2a4::d3


--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

From leo.vegoda at icann.org  Sat May 16 02:59:28 2009
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Fri, 15 May 2009 17:59:28 -0700
Subject: zero suppression vs compression in addresses
In-Reply-To: <8396B579-162B-4320-B5FE-15A17F3F526A@hopcount.ca>
Message-ID: <C6335E00.29346%leo.vegoda@icann.org>

On 15/05/2009 6:33, "Joe Abley" <jabley at hopcount.ca> wrote:

[...]

>> The rules on this may be about to change. See this draft:
>> http://tools.ietf.org/search/draft-kawamura-ipv6-text-
>> representation-02
> 
> Unless I am missing some text, that document is promoting a canonical
> representation for presentation of addresses, not changing the rules
> by which addresses are parsed.

The intended status is Informational so if published as an RFC I don't think
the representation it promotes should be considered canonical, just
suggested.

Regards,

Leo


From tvest at pch.net  Sat May 16 04:12:23 2009
From: tvest at pch.net (Tom Vest)
Date: Fri, 15 May 2009 22:12:23 -0400
Subject: Factors, actions influencing the possibility/timing of IDR for
	IPv6-basedrouting domains?
In-Reply-To: <3E8BEB47BAAC4480A53CE6AF3D3FDC08@tedsdesk>
References: <04BBB069-AF1B-4B20-8A0B-1B94F528147C@pch.net>
	<3E8BEB47BAAC4480A53CE6AF3D3FDC08@tedsdesk>
Message-ID: <DBFE2B4E-032E-4EB5-9108-BF1D8F1FE28F@pch.net>

Hi Ted,

Thanks for the reactions.
I'm going to attempt to rephrase slightly to fit them into the  
framework that I attempted to describe in my original request.
Please let me know if I've missed or misinterpreted anything.

Some factors/actions that you cite:
1. RIRs will attempt to recover some IPv4 for redistribution.
2. Some operators will undertake internal "rationalization" of their  
own IPv4 assets.

These are interesting, but not directly relevant to my question about  
prospects for native v6 IDR (except perhaps as potential confounding/ 
delaying factors).

Others that you mention:
3. Some IPv4-based operators will sell IPv4, and some aspiring new  
entrants will buy IPv4.
4. Mobile access providers will increasingly use IPv6 to add new  
customers and services.

(3) is a perfect match with my original list, and (4) is a special  
case of another factor that I cited initially.

You also suggest that:
5. Content providers will increasingly "connect to the IPv6 network."

This one is ambiguous. Are you suggesting that online content  
providers will build out their own wide area native-IPv6 distribution  
platforms to reach native IPv6 wireless/mobile access customers? Are  
you anticipating other sources of demand for native IPv6-based content  
-- i.e., other than recently added wireless access customers? Are you  
anticipating other distribution mechanisms (e.g., other than DIY) for  
getting native IPv6-based content to those new native IPv6 sources of  
demand? Presumably not all online content providers will have the  
scale or means to build their own national/international  
infrastructure platforms...

And finally:
6. Somebody (IPv4-based operators? IPv6-based new entrants?) will  
"give way free service."

I don't know what this means actually. I'm assuming that you mean that  
someone will (or should) provide some kind of deeply (perhaps 100%)  
discounted service, the results of which would be increased demand for  
native IPv6-based IDR -- but I don't know who or what you have in mind  
specifically. Would this be a recommendation that straddles one of the  
other points above (e.g., for native IPv6-based mobile access/access  
providers, or IPv6-based content hosting businesses?), or something  
else entirely?

Sorry if this re-parsing seems excessively literal; I'm trying to  
enumerate specific factors that should be included in a formal model  
for simulating the evolving probability of establishing/sustaining  
native IPv6-based inter-domain routing services.

Thanks again,

TV

On May 15, 2009, at 6:41 PM, Ted Mittelstaedt wrote:

>
> Here is how I envision this thing happening.  You can adjust the
> dates as you see fit.
>
> Sometime in 2013 IANA and rest of the RIR's run out of "virgin  
> IPv4".  The
> general news media starts making a big deal out of it.  Many ISP's who
> had no clue will get clueful.  ARIN will embark on "low-hanging-fruit"
> reclamation projects to attempt to pull back abandoned IPv4.  This  
> will
> satisfy the smaller requestors.  The larger requestors (eg. Comcast)  
> will
> embark on "internal IPv4 reclamation" projects.  The Internet will  
> still
> generally run on IPv4.  Cell phone providers will begin heavily  
> deploying
> IPv6 along with IPv6-IPv4 proxy systems
>
> Between the years of 2013 and 2015 the RIR's will gradually exhaust
> "low-hanging-fruit" IPv4 reclamation projects and a paid, transfer  
> market
> in IPv4 will arise.  By 2017 this transfer market will be in full  
> swing
> and it will be regarded as customary for "aspiring IDR participants"  
> to
> purchase IPv4 blocks.  Large orgs will be in full swing with  
> internal IPv4
> reclamation projects, both for their own needs and to sell to  
> newcomers.
> Content providers who run websites will be heavily pressured to  
> connect to
> the IPv6 network.
>
> By 2020 we will see the end of the transfer market as price increases
> push block prices to the point that they will never be able to  
> generate
> a return on investment.  By now, all orgs will be deploying IPv6 as  
> SOP for
> "native" IP connectivity, along
> with RFC1918 addresses for IPv4 connectivity, or extra-cost public  
> IPv4.
> Small orgs will likely be doing the same as well as heavy  
> experimentation
> and use of web and other proxies to get IPv6 assigned address  
> customers to
> IPv4 providers on the Internet.  Large orgs will have forced all major
> content providers to offer content via IPv6 in addition to IPv4
>
> From 2020 to 2025 will be the IPv4 end game.  The paid transfer market
> will have collapsed and no large requestors will be asking for IPv4  
> from
> the RIR's.  We will have the appearance of IPv6-only content  
> providers,
> and this trend will accelerate.  New IDR participants likely will be
> only requesting nominal amounts of IPv4 to assist in accessing the
> remaining content providers who haven't switched.
>
> By 2025 everyone offering a website on the Internet will be IPv6.  An
> increasing number of Internet customers will decline even the free
> RFC1918 IPv4 addressing.  Gaps and issues with route propagation of  
> the
> IPv4 BGP table will become increasingly regular.
>
> By 2030 IPv4 will have been reduced to a handful of sites still  
> advertising
> it mainly because they have not bothered to clean up their internal
> networks.
> A majority of transit AS's will be actively filtering IPv4  
> advertisements.
> IPv4 will essentially be dead.
>
>
> So, in answer to your question of:
>
> "...what individual actions
> -- either undertaken directly by the aspiring IDR 
> participant, or by the operators of other, established
> routing domains --  could directly or indirectly impact the
> probability, timing, and extent of this becoming generally possible?
>
> I would say:
>
> GIVE AWAY SERVICE.
>
> Sign up more customers.  Get people on the Internet who are not
> currently on the Internet.  What ultimately pushes IPv6 is
> a shortage of IPv4, and the only thing that creates this is
> consumption of IPv4.
>
> This is likely why the United States is going to have the worst
> time to switch to IPv6.  We have likely reached saturation for
> the Internet market, and thus everyone in the country already has
> an IPv4 address.  What is going to drive the US to IPv6 is the
> rest of the world offering content on IPv6 and US customers wanting
> to get at it.  Unfortunately, the US is the largest supplier of
> content in the world, as George Carlin used to say:
>
> "America's most profitable business is still the manufacture,
> packaging, distribution and marketing of bullshit"
> ---George Carlin: "You Are All Diseased (1999)"
>
> Ted
>
>> -----Original Message-----
>> From: ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de
>> [mailto:ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de] On
>> Behalf Of Tom Vest
>> Sent: Friday, May 15, 2009 11:15 AM
>> To: IPv6 Ops list
>> Subject: Factors,actions influencing the possibility/timing
>> of IDR for IPv6-basedrouting domains?
>>
>> Hi all,
>>
>> Would be very grateful for assistance from list members....
>> apologies for any duplication...
>>
>> I'm trying to compile a list of environmental factors or
>> actions that might affect the probability and timing of
>> direct participation in interdomain routing becoming
>> practical, specifically for routing domains that start out
>> with some IPv6 but without even one publicly routable IPv4 address.
>>
>> The question I'd like help with is: what individual actions
>> -- either undertaken directly by the aspiring IDR 
>> participant, or by the operators of other, established
>> routing domains --  could directly or indirectly impact the
>> probability, timing, and extent of this becoming generally possible?
>>
>> Please note (if it wasn't already obvious) that I'm *not*
>> talking about the possibility of becoming a pure/direct
>> customer of another routing service provider, nor am I
>> asking/making presumptions about IDR-related activities that
>> are not commonplace, much less "guaranteed" for routing
>> service providers in general (ubiquitous settlement-free
>> peering, etc.). The basic idea is that there is a range of
>> "normal" or "conventional" activities that operators of
>> routing domains may choose to participate in today (e.g.,
>> exchanging traffic, indirectly or directly, potentially with
>> most if all other routing domains; participating as a third
>> party in traffic exchange between other routing domains --
>> aka providing transit; pursuing, accepting, and/or rejecting
>> direct and indirect traffic exchange relationships;
>> influencing traffic flows across those interconnections,
>> etc.), none of which would be possible today for an operator
>> of a pure IPv6-based (or any post-IPv4 runout) routing
>> domain. The question is: what's going to change that?
>>
>> My current provisional list of things that might
>> incrementally change that includes:
>>
>> 1. New entrant(s) obtain an independently routable quantity
>> of IPv4 from someone/somewhere, which can be used to mediate
>> traffic exchange between internal IPv6-based resources and
>> external IPv4-based network elements.
>> 2. Existing, IPv4-based routing domains offer native
>> IPv6-based IP transit that is physically accessible by the
>> aspiring new entrant(s).
>> 3. Existing, Pv4-based routing service providers begin to
>> accommodate incremental growth of existing and new customers
>> using IPv6 *in a way that makes those new elements
>> transparently reachable via native IPv6- based IDR.* 4.
>> Existing, Pv4-based routing domains make some or all of their
>> current, public-facing resources reachable via native IPv6-based IDR.
>>
>> What else should be on the list? Additional comments,
>> questions, or suggestions would be greatly appreciated!
>>
>> Thanks in advance,
>>
>> TV
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>


From martin at airwire.ie  Sat May 16 12:15:10 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Sat, 16 May 2009 11:15:10 +0100
Subject: Question about 6to4
In-Reply-To: <4A0DCE72.6030505@impulse.net>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>	<4A0CA8FD.5040501@airwire.ie>	<4A0CAA78.1060608@peakinternet.com>	<4A0CAD27.20500@airwire.ie>
	<4A0DCE72.6030505@impulse.net>
Message-ID: <4A0E922E.4040203@airwire.ie>

Jay Hennigan wrote:
> Martin List-Petersen wrote:
> 
>>
>> There are a few more. m0n0wall will run on pretty much any x86 based
>> platform and you can configure IPv6 via GUI, it does 6to4, native, 6in4
>> and SixXS dynamic tunnels, not ayiya, too.
>>
>> OpenWRT and DD-WRT (haven't looked at them lately) offer IPv6, but no
>> GUI configuration for it.
> 
> Do they support V6DHCP?

If you install a dhcp-v6 on there, sure.

>> There are certain exception releases of routers that do, like the D-Link
>> DIR-615 rev: C1 (and yes, it's not in rev B or rev D)
> 
> Same question.

No. This box does route advertisements only, I believe.

> 
>> The Apple Airport Xtreme does it .. again .. that's the $80+ range and
>> well, as of recent the lab firmware for the AVM Fritz! routers, but they
>> are well over $80+
> 
> Are you sure the Apple Airport supports native?  I'm aware that it does
> tunnels, also same question for V6DHCP.

I was tempted to buy one recently to check out what exactly is
supported. I might still do that :)

> We're providing a V6DHCP /56 to home DSL users, and the only CPE that
> supports dual-stack with V6DHCP I've found is the Cisco 8XX series.  Not
> really practical for the masses.

Well, DHCPv6 is not very common yet. Most routers will do
route-advertisements. We even got Mikrotik to support the advertisement
of nameservers via rdnssd, which actually also make that a fully usually
auto-configuration then.

I spoke to AVM at CeBIT, and they are planning on doing DHCPv6 for the
Fritz! box family, but it's not in there yet. Currently it's
route-advertisements only.

Also be aware, that you can't use DHCPv6 only. You need
route-advertisements, too, because DHCPv6 doesn't set a default gateway.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From gert at space.net  Sat May 16 12:43:56 2009
From: gert at space.net (Gert Doering)
Date: Sat, 16 May 2009 12:43:56 +0200
Subject: Question about 6to4
In-Reply-To: <BC3525E2339345D4AD452F156FD363A8@tedsdesk>
References: <4A0CAD27.20500@airwire.ie>
	<20090515005136.GH84365@burnout.tpb.net>
	<BC3525E2339345D4AD452F156FD363A8@tedsdesk>
Message-ID: <20090516104356.GX2776@Space.Net>

Hi,

On Fri, May 15, 2009 at 10:47:39AM -0700, Ted Mittelstaedt wrote:
> Linksys then proceeded to release a version of the 54G with model # of
> wrt54GL  (trailing L) that retained the 4MB of flash, this was aimed
> at dd-wrt users.  While it doesn't cost more, it is never sold through
> retail so your never going to see it discounted with an on-sale price
> like you see the 54G on sale from time to time.

Amazon.de is selling the 54GL, and that's good-enough retail for me :)

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From gert at space.net  Sat May 16 13:06:09 2009
From: gert at space.net (Gert Doering)
Date: Sat, 16 May 2009 13:06:09 +0200
Subject: Question about 6to4
In-Reply-To: <072D03365FF441BCA786599BB791FE7A@tedsdesk>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>
	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>
	<072D03365FF441BCA786599BB791FE7A@tedsdesk>
Message-ID: <20090516110609.GY2776@Space.Net>

Hi,

On Thu, May 14, 2009 at 03:16:51PM -0700, Ted Mittelstaedt wrote:
> Am I correct in assuming this is a severe disincentive to putting up IPv6
> public relays? ;-)

Well, it really depends on how many other relays are around, and how
far your advertisements for the 2002::/16 and the IPv4 /24 are propagating.

We run a semi-private relay - it's advertised to our BGP customers, but
not to peers or upstreams.  This helps our customers, and doesn't have
impact on other networks.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From jay at west.net  Sat May 16 16:00:34 2009
From: jay at west.net (Jay Hennigan)
Date: Sat, 16 May 2009 07:00:34 -0700
Subject: Question about 6to4
In-Reply-To: <4A0E922E.4040203@airwire.ie>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>	<4A0C956F.9060107@airwire.ie>	<C81D786EB1F94499AE960899C0AD3A5E@tedsdesk>	<4A0CA8FD.5040501@airwire.ie>	<4A0CAA78.1060608@peakinternet.com>	<4A0CAD27.20500@airwire.ie>	<4A0DCE72.6030505@impulse.net>
	<4A0E922E.4040203@airwire.ie>
Message-ID: <4A0EC702.5030005@west.net>

Martin List-Petersen wrote:

> Well, DHCPv6 is not very common yet. Most routers will do
> route-advertisements. We even got Mikrotik to support the advertisement
> of nameservers via rdnssd, which actually also make that a fully usually
> auto-configuration then.
> 
> I spoke to AVM at CeBIT, and they are planning on doing DHCPv6 for the
> Fritz! box family, but it's not in there yet. Currently it's
> route-advertisements only.
> 
> Also be aware, that you can't use DHCPv6 only. You need
> route-advertisements, too, because DHCPv6 doesn't set a default gateway.

Yes, I'm aware.  The problem I'm trying to solve relates to a discussion 
on the NANOG list regarding subnet size for DSL small office and home 
users.  There's discussion regarding /56 vs /48 but pretty much everyone 
agrees that home DSL users should get more than just a /64.  We concur, 
and opted for /56.

The goal is that the customer's CPE will learn the /56 (or /48) from our 
provider edge router and then assign a /64 from within that space to 
each customer LAN subnet automatically.  We're doing this now with early 
adopters using DHCPv6 and Cisco gear, typically refurbished 8xx and 1721 
series.  This doesn't scale from a price and support perspective.  If 
there is a way to accomplish this without a DHCPv6 client in the home 
router, I'm all ears.  I openly confess to being a newbie with regard to 
IPv6, but I think we're ahead of the curve with respect to most ISPs in 
the US.

Just router advertisements seems to work if we assign a /64 and there is 
one subnet with a simple switch or bridge at the customer end but this 
doesn't scale or play well in a dual-stack scenario as straight IPv6 
bridged pass-through coupled with an IPv4 NAT scenario on the same CPE 
doesn't seem to be supported by any existing CPE.  This method only 
allows for a single /64 to the customer as well, which we're trying to 
avoid.

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

From michael.dillon at bt.com  Sun May 17 16:45:09 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Sun, 17 May 2009 15:45:09 +0100
Subject: zero suppression vs compression in addresses
In-Reply-To: <C6335E00.29346%leo.vegoda@icann.org>
Message-ID: <28E139F46D45AF49A31950F88C4974580129E5E5@E03MVZ2-UKDY.domain1.systemhost.net>

> The intended status is Informational so if published as an 
> RFC I don't think the representation it promotes should be 
> considered canonical, just suggested.

Watch your language!
If your read
<http://tools.ietf.org/html/draft-kawamura-ipv6-text-representation-02>
you will notice that it uses the word "canonical"
several times. Also, the draft could very well change
status by the time it becomes an RFC, or another RFC
might cover this topic.

The point is that the text representation of IPv6 addresses
might be about to change, so if you are writing code to
read IPv6 text format addresses, you probably want to 
accept the format defined in this draft. Unless of course,
there is some fundamental flaw in which case you might 
want to communicate that to the author of the draft.

--Michael Dillon

From gert at space.net  Sun May 17 17:30:59 2009
From: gert at space.net (Gert Doering)
Date: Sun, 17 May 2009 17:30:59 +0200
Subject: zero suppression vs compression in addresses
In-Reply-To: <28E139F46D45AF49A31950F88C4974580129E5E5@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C6335E00.29346%leo.vegoda@icann.org>
	<28E139F46D45AF49A31950F88C4974580129E5E5@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <20090517153059.GE2776@Space.Net>

Hi,

On Sun, May 17, 2009 at 03:45:09PM +0100, michael.dillon at bt.com wrote:
> The point is that the text representation of IPv6 addresses
> might be about to change, so if you are writing code to
> read IPv6 text format addresses, you probably want to 
> accept the format defined in this draft. Unless of course,
> there is some fundamental flaw in which case you might 
> want to communicate that to the author of the draft.

The whole point of this draw is the *output* format of an IPv6 address
(and it's using fairly weak language, like "should" instead of "SHOULD",
at that).

Input parsers need to understand every possible representation, as long
as it's syntactically correct.  This draft doesn't change what is to be
considered a syntactically correct representation, so for a *reader*,
it is just not very relevant.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From spz at serpens.de  Sun May 17 19:20:00 2009
From: spz at serpens.de (S.P.Zeidler)
Date: Sun, 17 May 2009 19:20:00 +0200
Subject: zero suppression vs compression in addresses
In-Reply-To: <28E139F46D45AF49A31950F88C4974580129E5E5@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C6335E00.29346%leo.vegoda@icann.org>
	<28E139F46D45AF49A31950F88C4974580129E5E5@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <20090517172000.GY14542@serpens.de>

Thus wrote michael.dillon at bt.com (michael.dillon at bt.com):

[...]
> The point is that the text representation of IPv6 addresses
> might be about to change
[...]

Have you read the draft? it does not change the text representation
of IPv6 addresses, it just specifies which of the dozen variants
allowed now should be preferred for output in order to get a
deterministic representation of a given v6 address.

(Unlike going from asdot to asplain for extended autnums, f.e.; that's a
change.)

regards,
	spz
-- 
spz at serpens.de (S.P.Zeidler)

From mohacsi at niif.hu  Mon May 18 11:40:20 2009
From: mohacsi at niif.hu (Mohacsi Janos)
Date: Mon, 18 May 2009 11:40:20 +0200 (CEST)
Subject: Question about 6to4
In-Reply-To: <4A0D534E.60306@airwire.ie>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>
	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>
	<4A0CF6F7.403@kl.net>
	<2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com>
	<4A0D534E.60306@airwire.ie>
Message-ID: <alpine.BSF.2.00.0905181138000.9657@mignon.ki.iif.hu>

Hi,


On Fri, 15 May 2009, Martin List-Petersen wrote:

> Erik Kline wrote:
>> Personally, I'm a fan of 6rd.  That's what works for free.fr.  That, or just
>> go native.
>
> The issue with 6rd is, that it's consuming extreme amounts of IP's.
> Free.fr got a /26 IPv6 allocated just to do this for all of their customers.
>
> Native, this probably could have been done well within a /32 or /30 at
> the most.
>
> So I wouldn't even try to advocate to go down the route, that Free did
> and use 6rd.


I think there is a bigger problem from 6rd: the provider should have 
control over customers' home router - at least forcing of upgrade of 
firmware and push some configuration parameters 6rd routing...

Best Regards,

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882


From michael.dillon at bt.com  Mon May 18 11:51:28 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 18 May 2009 10:51:28 +0100
Subject: zero suppression vs compression in addresses
In-Reply-To: <20090517153059.GE2776@Space.Net>
Message-ID: <28E139F46D45AF49A31950F88C4974580129E9F4@E03MVZ2-UKDY.domain1.systemhost.net>


> Input parsers need to understand every possible 
> representation, as long as it's syntactically correct.  This 
> draft doesn't change what is to be considered a syntactically 
> correct representation, so for a *reader*, it is just not 
> very relevant.

People have been saying that a double colon can appear
once and only once in an IPv6 address. If you write code
that will only accept a single occurence of double colon
and it meets one of these canonical IPv6 addresses, then
it won't work.

So, this draft *DOES* change what is considered to be
a syntactically correct when it allows "::" to be used
twice. Admittedly, section 4.2.3 is not very clear and
it may not survive future discussion, but the bulk of
this draft is very clear and well-reasoned. It is worth
reading by anyone who is working on code that converts
between IPv6 binary and text representations. Regardless
of its status, the recommendation to output text addresses
using only lowercase abcdef is a good one.

--Michael Dillon



From martin at airwire.ie  Mon May 18 12:04:49 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Mon, 18 May 2009 11:04:49 +0100
Subject: Question about 6to4
In-Reply-To: <alpine.BSF.2.00.0905181138000.9657@mignon.ki.iif.hu>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk>
	<922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com>
	<4A0CF6F7.403@kl.net>
	<2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com>
	<4A0D534E.60306@airwire.ie>
	<alpine.BSF.2.00.0905181138000.9657@mignon.ki.iif.hu>
Message-ID: <4A1132C1.4020000@airwire.ie>

Mohacsi Janos wrote:
> Hi,
> 
> 
> On Fri, 15 May 2009, Martin List-Petersen wrote:
> 
>> Erik Kline wrote:
>>> Personally, I'm a fan of 6rd.  That's what works for free.fr.  That,
>>> or just
>>> go native.
>>
>> The issue with 6rd is, that it's consuming extreme amounts of IP's.
>> Free.fr got a /26 IPv6 allocated just to do this for all of their
>> customers.
>>
>> Native, this probably could have been done well within a /32 or /30 at
>> the most.
>>
>> So I wouldn't even try to advocate to go down the route, that Free did
>> and use 6rd.
> 
> 
> I think there is a bigger problem from 6rd: the provider should have
> control over customers' home router - at least forcing of upgrade of
> firmware and push some configuration parameters 6rd routing...

Correct. With free.fr's approach, that is the case. It's their own
router/cpe device that they supply to the customers, so they can easily
do that, but it wouldn't be very common to have that.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From bjorn at mork.no  Mon May 18 12:44:24 2009
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Mon, 18 May 2009 12:44:24 +0200
Subject: zero suppression vs compression in addresses
In-Reply-To: <28E139F46D45AF49A31950F88C4974580129E9F4@E03MVZ2-UKDY.domain1.systemhost.net>
	(michael dillon's message of "Mon, 18 May 2009 10:51:28 +0100")
References: <28E139F46D45AF49A31950F88C4974580129E9F4@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <87ab5asnav.fsf@nemi.mork.no>

<michael.dillon at bt.com> writes:

> So, this draft *DOES* change what is considered to be
> a syntactically correct when it allows "::" to be used
> twice. 

That's clearly not the intent.  For reference, quoting from the
beginning of section 4:

  "A recommendation for a canonical text representation format of IPv6
   addresses is presented in this section.  The recommendation in this
   document is one that, complies fully with [RFC4291], is implemented
   by various operating systems, and is human friendly. "


> Admittedly, section 4.2.3 is not very clear and it may not survive
> future discussion,

I guess it should not survive, given your interpretation of it.

The point of section 4.2.3, as I read it, is: If there are more than one
sequence of 16 bit groups of zeroes, compress the longest.  In case of a
tie, compress the first sequence.

E.g.

2001:db8:0:0:0:1:0:0 => 2001:db8::1:0:0 (longest match win)
2001:db8:0:0:1:0:0:0 => 2001:db8:0:0:1:: (longest match win)
2001:db8:0:0:1:0:0:1 => 2001:db8::1:0:0:1 (first of equal length win)



Bj?rn

From david.freedman at uk.clara.net  Mon May 18 13:13:07 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Mon, 18 May 2009 12:13:07 +0100
Subject: tunneling native v6  connectivity
In-Reply-To: <4A0DB2DF.8080106@thewybles.com>
References: <4A0DB2DF.8080106@thewybles.com>
Message-ID: <4A1142C3.5070806@uk.clara.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> What would people recommend for this? I was thinking of using OpenVPN
> and Vyatta.

Why not just use Linux static tunnels?

http://tldp.org/HOWTO/Linux+IPv6-HOWTO/configuring-ipv6to4-tunnels.html

Unless you are after encryption in such case use a VPN s/w product to
create an SA for your tunnel endpoint pair and tunnel over this.

Dave.


> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoRQsMACgkQtFWeqpgEZrJ/eACePXN7TXnZzDiYBswwooIqQbfZ
IRoAn2kszT+JWVvxA8+BCvjiRHtFuIiU
=SksZ
-----END PGP SIGNATURE-----

From evyncke at cisco.com  Mon May 18 13:54:06 2009
From: evyncke at cisco.com (Eric Vyncke (evyncke))
Date: Mon, 18 May 2009 13:54:06 +0200
Subject: Question about 6to4
In-Reply-To: <alpine.BSF.2.00.0905181138000.9657@mignon.ki.iif.hu>
References: <FDB6E8A1ACED411C87EA436CA4664E63@tedsdesk><922f6670905141449s69b08e26pf6c4a6c66940936e@mail.gmail.com><4A0CF6F7.403@kl.net><2e8c64260905142219l61d6655el9648de964b345530@mail.gmail.com><4A0D534E.60306@airwire.ie>
	<alpine.BSF.2.00.0905181138000.9657@mignon.ki.iif.hu>
Message-ID: <CE2BF2A7B1008C459FD7978065C6ECE008DCEAC4@xmb-ams-33a.emea.cisco.com>

Actually, R?mi has a draft to push the 6RD parameters via DHCPv4, so, it could be implemented by any CPE (or even RG through GUI), even non-managed CPE

-?ric 

> -----Original Message-----
> From: ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de 
> [mailto:ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de] 
> On Behalf Of Mohacsi Janos
> Sent: lundi 18 mai 2009 11:40
> To: Martin List-Petersen
> Cc: Erik Kline; ipv6-ops at lists.cluenet.de
> Subject: Re: Question about 6to4
> 
> Hi,
> 
> 
> On Fri, 15 May 2009, Martin List-Petersen wrote:
> 
> > Erik Kline wrote:
> >> Personally, I'm a fan of 6rd.  That's what works for 
> free.fr.  That, 
> >> or just go native.
> >
> > The issue with 6rd is, that it's consuming extreme amounts of IP's.
> > Free.fr got a /26 IPv6 allocated just to do this for all of 
> their customers.
> >
> > Native, this probably could have been done well within a 
> /32 or /30 at 
> > the most.
> >
> > So I wouldn't even try to advocate to go down the route, 
> that Free did 
> > and use 6rd.
> 
> 
> I think there is a bigger problem from 6rd: the provider 
> should have control over customers' home router - at least 
> forcing of upgrade of firmware and push some configuration 
> parameters 6rd routing...
> 
> Best Regards,
> 
> Janos Mohacsi
> Network Engineer, Research Associate, Head of Network 
> Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: 
> DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882
> 
> 

From tedm at ipinc.net  Mon May 18 19:09:04 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 18 May 2009 10:09:04 -0700
Subject: zero suppression vs compression in addresses
In-Reply-To: <20090517153059.GE2776@Space.Net>
References: <C6335E00.29346%leo.vegoda@icann.org><28E139F46D45AF49A31950F88C4974580129E5E5@E03MVZ2-UKDY.domain1.systemhost.net>
	<20090517153059.GE2776@Space.Net>
Message-ID: <01655AAD02814993A27DBE3A1CC67E44@tedsdesk>

 

> -----Original Message-----
> From: ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de 
> [mailto:ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de] On 
> Behalf Of Gert Doering
> Sent: Sunday, May 17, 2009 8:31 AM
> To: michael.dillon at bt.com
> Cc: ipv6-ops at lists.cluenet.de
> Subject: Re: zero suppression vs compression in addresses
> 
> Hi,
> 
> On Sun, May 17, 2009 at 03:45:09PM +0100, michael.dillon at bt.com wrote:
> > The point is that the text representation of IPv6 addresses 
> might be 
> > about to change, so if you are writing code to read IPv6 
> text format 
> > addresses, you probably want to accept the format defined in this 
> > draft. Unless of course, there is some fundamental flaw in 
> which case 
> > you might want to communicate that to the author of the draft.
> 
> The whole point of this draw is the *output* format of an 
> IPv6 address (and it's using fairly weak language, like 
> "should" instead of "SHOULD", at that).
> 
> Input parsers need to understand every possible 
> representation, as long as it's syntactically correct. 

Only for automated or script-fed input, if it's a webform your
presenting to a user to input the IP address, you can always
stick with making the user enter the "long-form" of the address,
IMHO.

HaCi for example accepts the shortened IPv6 then expands it and
displays it as long-form when it's displaying the tree.  I can
see lots of potential for trouble if the RFC changes the logic and
people are copying and pasting addresses from configs to the HaCi input
form from a device using different parser rules to display addresses
in a shortened form.

Ted


From jay at west.net  Mon May 18 19:30:49 2009
From: jay at west.net (Jay Hennigan)
Date: Mon, 18 May 2009 10:30:49 -0700
Subject: zero suppression vs compression in addresses
In-Reply-To: <28E139F46D45AF49A31950F88C4974580129E9F4@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C4974580129E9F4@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4A119B49.2080500@west.net>

michael.dillon at bt.com wrote:

> So, this draft *DOES* change what is considered to be
> a syntactically correct when it allows "::" to be used
> twice. Admittedly, section 4.2.3 is not very clear and
> it may not survive future discussion, but the bulk of
> this draft is very clear and well-reasoned. It is worth
> reading by anyone who is working on code that converts
> between IPv6 binary and text representations. Regardless
> of its status, the recommendation to output text addresses
> using only lowercase abcdef is a good one.

That isn't how I read the draft.  It does not allow :: to be used twice. 
  Rather, it addresses the ambiguity for those addresses where there are 
more than one "zero" fields separated by a non-zero field.  Such 
addresses have two different places where a :: could be used.  Hence the 
title of 4.2.3 of "When '::' Can Be Used Twice".  It *can't* be used 
twice, but there are some addresses where there are two opportunities to 
use it once.  4.2.3 defines which *one* of those opportunities should be 
used.

The title of 4.2.3 is poorly written, IMHO.  It should be something like 
"Precedence of '::' in cases where there are multiple "0" fields".

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

From tedm at ipinc.net  Mon May 18 20:23:18 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 18 May 2009 11:23:18 -0700
Subject: Factors, actions influencing the possibility/timing of IDR for
	IPv6-basedrouting domains?
In-Reply-To: <DBFE2B4E-032E-4EB5-9108-BF1D8F1FE28F@pch.net>
References: <04BBB069-AF1B-4B20-8A0B-1B94F528147C@pch.net>
	<3E8BEB47BAAC4480A53CE6AF3D3FDC08@tedsdesk>
	<DBFE2B4E-032E-4EB5-9108-BF1D8F1FE28F@pch.net>
Message-ID: <F910D18AF8C04992A1435594CAEF15CA@tedsdesk>

 

> -----Original Message-----
> From: Tom Vest [mailto:tvest at pch.net] 
> Sent: Friday, May 15, 2009 7:12 PM
> To: Ted Mittelstaedt
> Cc: 'IPv6 Ops list'
> Subject: Re: Factors,actions influencing the 
> possibility/timing of IDR for IPv6-basedrouting domains?
> 
> Hi Ted,
> 
> Thanks for the reactions.
> I'm going to attempt to rephrase slightly to fit them into 
> the framework that I attempted to describe in my original request.
> Please let me know if I've missed or misinterpreted anything.
> 
> Some factors/actions that you cite:
> 1. RIRs will attempt to recover some IPv4 for redistribution.
> 2. Some operators will undertake internal "rationalization" 
> of their own IPv4 assets.
> 
> These are interesting, but not directly relevant to my 
> question about prospects for native v6 IDR (except perhaps as 
> potential confounding/ delaying factors).
> 

You had asked what actions operators of other routing domains
could take that would affect standalone IPv6 routing becoming
possible.  If operators of other domains refuse engage in IPv4
recovery, IPv6 will come a lot faster.

I think if you look at the math of it, this is much more of a
major issue than most people think.  Right now only about 1/2
the IPv4 allocated is advertised in the dfz, if aggressive
transfer sales and reclamation take place, in conjunction with
heavy use of NAT, it could potentially stall the IPv6 effort
indefinitely.

Also if end users accepted private IPv4 from the ISP as a matter of
course, I think it would be a very big disincentive to rolling
out IPv6.  And end users are
not known for being very smart about networking.

It's too early to tell what impact that IPv4 reclamation will have,
some people say a lot, some say a little.  I do think that
this is an area where perception becomes the reality - I think if
the perception is that IPv6 is adopting very slowly, that
reclamation efforts will be pursued with much more vigor and
will yield a lot more fruit.  By contrast if perception is IPv6
uptake is fast, then reclamation will not be vigorously pursued
and will die away.

Another thing too about the transfer market is that if perception
is IPv6 is adopting slowly, then even though reclamation will
be vigorous, orgs doing the reclaiming will keep the IPv4 to
themselves.  This will of course prolong IPv4 usage and make it
a lot harder for new entrants to get IPv4 numbering.

I also think that the amount of freed-up IPv4 an ISP can
create (for resale or use with new customers) is proportional to
the amount of effort they spend on reclamation.

> Others that you mention:
> 3. Some IPv4-based operators will sell IPv4, and some 
> aspiring new entrants will buy IPv4.
> 4. Mobile access providers will increasingly use IPv6 to add 
> new customers and services.
> 
> (3) is a perfect match with my original list, and (4) is a 
> special case of another factor that I cited initially.
> 
> You also suggest that:
> 5. Content providers will increasingly "connect to the IPv6 network."
> 
> This one is ambiguous. Are you suggesting that online content 
> providers will build out their own wide area native-IPv6 
> distribution platforms to reach native IPv6 wireless/mobile 
> access customers? Are you anticipating other sources of 
> demand for native IPv6-based content
> -- i.e., other than recently added wireless access customers? 
> Are you anticipating other distribution mechanisms (e.g., 
> other than DIY) for getting native IPv6-based content to 
> those new native IPv6 sources of demand? Presumably not all 
> online content providers will have the scale or means to 
> build their own national/international infrastructure platforms...
> 

No.  What I am saying is that the large content providers - Google and
the like - are already onboard with this IPv6 deployment and are
working on becoming dual-stacked now.  It is not to capture more
customers as much as it's a community service effort, at this point.
To those providers, getting IPv6 compliant is a money-saver in the
long run because they know that ultimately they are going to have to
spend the development dollars to get their stuff compliant, and
if they get complaint now, then in the future when they have built out
more stuff they will have less stuff to change, and it will be cheaper.

What I mean more are the smaller content providers.  For example, go
to Google, type in "barbeque" and you will get about 100 links to a bunch
of small time people who are selling bbq sauces and suchlike, and
providing content such as recipes and cooking tips to attract people
to their sites.

Just about all of these folks are hosting on one of the large 
virtual server farms, run by one of the virtual server companies
on the Internet.  None of those people are going to go to their
server farm operators and demand the operator add IPv6.

But, those farms know the same thing Google knows, which is that
eventually there's going to be IPv6-only clients out there, and
they don't want those clients complaining to their own customers,
and their own customers perhaps leaving without even saying anything.
Plus, you never know exactly what Google is going to use as search
criteria.  Google is spending big bucks on their own IPv6 deployment,
and it wouldn't be farfetched to imagine that Google might one day
quietly slip "Reachable by both IPv4 and IPv6" on to their list of
items that increase your page ranking.

You have to take it as fact that this is going to be a transition - 
first IPv4-only, next dual-stacked, last IPv6-only.  And likely it
will be on a classic bell curve.  In the beginning the number of
dual-stacked sites will be small, but when it hits 20% then everyone
and their dog will climb on, then the rate of adoption of dual stack
will peter off after it hits 80%.  Then the rate of IPv6-only will
follow the same curve.

The content providers will be further along this curve because nobody
wants to be NOT dual-stacked when the first customer with money in
their pocket that is IPv6-only hits the Internet.

Then the content providers will be the LAST on the curve to shut down
dual-stacking and go to IPv6-only, for the same reason.

> And finally:
> 6. Somebody (IPv4-based operators? IPv6-based new entrants?) 
> will "give way free service."
> 
> I don't know what this means actually. I'm assuming that you 
> mean that someone will (or should) provide some kind of 
> deeply (perhaps 100%) discounted service, the results of 
> which would be increased demand for native IPv6-based IDR -- 
> but I don't know who or what you have in mind specifically. 
> Would this be a recommendation that straddles one of the 
> other points above (e.g., for native IPv6-based mobile 
> access/access providers, or IPv6-based content hosting 
> businesses?), or something else entirely?
>

I know as I'm sure you do that we aren't going to see wide-spread
giving away of free service.  What I was discussing is that
the progression to adoption is going to specifically be a unique
problem for the US because of 2 factors, first the US sources a
lot of content on the Internet, second the US has much more
built-out IPv4 infrastructure.  You will see US content providers
dual-stacking early, BUT when most end-users and content-providers
are dual-stacked, it will be the end-users wanting to single-stack
to IPv6 and the content providers holding things back - and the
content providers in the US will be the worst about becoming
IPv6-only because of their heavy investment in IPv4 infrastructure.

Obviously, ISP's and networks (like the cell network) that provide
connectivity to end-users are the biggest consumers of IP addresses.
It is quite logical that they would be the most interested in
getting rid of IPv4 - once all of the content providers on the
Internet have dual-stacked.  So once the content providers have
done it, the retail ISP's will feel comfortable levying surcharges
and suchlike to their customers to push them into IPv6-only.  But of
course, not all customers will do this and as long as some are
foot-dragging, the content providers will stay dual-stacked.

Ted

> Sorry if this re-parsing seems excessively literal; I'm 
> trying to enumerate specific factors that should be included 
> in a formal model for simulating the evolving probability of 
> establishing/sustaining native IPv6-based inter-domain 
> routing services.
> 
> Thanks again,
> 
> TV
> 
> On May 15, 2009, at 6:41 PM, Ted Mittelstaedt wrote:
> 
> >
> > Here is how I envision this thing happening.  You can 
> adjust the dates 
> > as you see fit.
> >
> > Sometime in 2013 IANA and rest of the RIR's run out of 
> "virgin IPv4".  
> > The general news media starts making a big deal out of it.  
> Many ISP's 
> > who had no clue will get clueful.  ARIN will embark on 
> > "low-hanging-fruit"
> > reclamation projects to attempt to pull back abandoned IPv4.  This 
> > will satisfy the smaller requestors.  The larger requestors (eg. 
> > Comcast) will embark on "internal IPv4 reclamation" projects.  The 
> > Internet will still generally run on IPv4.  Cell phone 
> providers will 
> > begin heavily deploying
> > IPv6 along with IPv6-IPv4 proxy systems
> >
> > Between the years of 2013 and 2015 the RIR's will gradually exhaust 
> > "low-hanging-fruit" IPv4 reclamation projects and a paid, transfer 
> > market in IPv4 will arise.  By 2017 this transfer market will be in 
> > full swing and it will be regarded as customary for "aspiring IDR 
> > participants"
> > to
> > purchase IPv4 blocks.  Large orgs will be in full swing 
> with internal 
> > IPv4 reclamation projects, both for their own needs and to sell to 
> > newcomers.
> > Content providers who run websites will be heavily pressured to 
> > connect to the IPv6 network.
> >
> > By 2020 we will see the end of the transfer market as price 
> increases 
> > push block prices to the point that they will never be able to 
> > generate a return on investment.  By now, all orgs will be 
> deploying 
> > IPv6 as SOP for "native" IP connectivity, along with 
> RFC1918 addresses 
> > for IPv4 connectivity, or extra-cost public IPv4.
> > Small orgs will likely be doing the same as well as heavy 
> > experimentation and use of web and other proxies to get 
> IPv6 assigned 
> > address customers to
> > IPv4 providers on the Internet.  Large orgs will have 
> forced all major 
> > content providers to offer content via IPv6 in addition to IPv4
> >
> > From 2020 to 2025 will be the IPv4 end game.  The paid 
> transfer market 
> > will have collapsed and no large requestors will be asking for IPv4 
> > from the RIR's.  We will have the appearance of IPv6-only content 
> > providers, and this trend will accelerate.  New IDR participants 
> > likely will be only requesting nominal amounts of IPv4 to assist in 
> > accessing the remaining content providers who haven't switched.
> >
> > By 2025 everyone offering a website on the Internet will be 
> IPv6.  An 
> > increasing number of Internet customers will decline even the free
> > RFC1918 IPv4 addressing.  Gaps and issues with route propagation of 
> > the
> > IPv4 BGP table will become increasingly regular.
> >
> > By 2030 IPv4 will have been reduced to a handful of sites still 
> > advertising it mainly because they have not bothered to 
> clean up their 
> > internal networks.
> > A majority of transit AS's will be actively filtering IPv4 
> > advertisements.
> > IPv4 will essentially be dead.
> >
> >
> > So, in answer to your question of:
> >
> > "...what individual actions
> > -- either undertaken directly by the aspiring IDR 
> participant, or by 
> > the operators of other, established routing domains --  
> could directly 
> > or indirectly impact the probability, timing, and extent of this 
> > becoming generally possible?
> >
> > I would say:
> >
> > GIVE AWAY SERVICE.
> >
> > Sign up more customers.  Get people on the Internet who are not 
> > currently on the Internet.  What ultimately pushes IPv6 is 
> a shortage 
> > of IPv4, and the only thing that creates this is 
> consumption of IPv4.
> >
> > This is likely why the United States is going to have the 
> worst time 
> > to switch to IPv6.  We have likely reached saturation for 
> the Internet 
> > market, and thus everyone in the country already has an 
> IPv4 address.  
> > What is going to drive the US to IPv6 is the rest of the world 
> > offering content on IPv6 and US customers wanting to get at it.  
> > Unfortunately, the US is the largest supplier of content in 
> the world, 
> > as George Carlin used to say:
> >
> > "America's most profitable business is still the manufacture, 
> > packaging, distribution and marketing of bullshit"
> > ---George Carlin: "You Are All Diseased (1999)"
> >
> > Ted
> >
> >> -----Original Message-----
> >> From: ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de
> >> [mailto:ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de] 
> On Behalf 
> >> Of Tom Vest
> >> Sent: Friday, May 15, 2009 11:15 AM
> >> To: IPv6 Ops list
> >> Subject: Factors,actions influencing the possibility/timing of IDR 
> >> for IPv6-basedrouting domains?
> >>
> >> Hi all,
> >>
> >> Would be very grateful for assistance from list members....
> >> apologies for any duplication...
> >>
> >> I'm trying to compile a list of environmental factors or 
> actions that 
> >> might affect the probability and timing of direct participation in 
> >> interdomain routing becoming practical, specifically for routing 
> >> domains that start out with some IPv6 but without even one 
> publicly 
> >> routable IPv4 address.
> >>
> >> The question I'd like help with is: what individual actions
> >> -- either undertaken directly by the aspiring IDR 
> participant, or by 
> >> the operators of other, established routing domains --  could 
> >> directly or indirectly impact the probability, timing, and 
> extent of 
> >> this becoming generally possible?
> >>
> >> Please note (if it wasn't already obvious) that I'm *not* talking 
> >> about the possibility of becoming a pure/direct customer 
> of another 
> >> routing service provider, nor am I asking/making 
> presumptions about 
> >> IDR-related activities that are not commonplace, much less 
> >> "guaranteed" for routing service providers in general (ubiquitous 
> >> settlement-free peering, etc.). The basic idea is that there is a 
> >> range of "normal" or "conventional" activities that operators of 
> >> routing domains may choose to participate in today (e.g., 
> exchanging 
> >> traffic, indirectly or directly, potentially with most if 
> all other 
> >> routing domains; participating as a third party in traffic 
> exchange 
> >> between other routing domains -- aka providing transit; pursuing, 
> >> accepting, and/or rejecting direct and indirect traffic exchange 
> >> relationships; influencing traffic flows across those 
> >> interconnections, etc.), none of which would be possible 
> today for an 
> >> operator of a pure IPv6-based (or any post-IPv4 runout) routing 
> >> domain. The question is: what's going to change that?
> >>
> >> My current provisional list of things that might 
> incrementally change 
> >> that includes:
> >>
> >> 1. New entrant(s) obtain an independently routable 
> quantity of IPv4 
> >> from someone/somewhere, which can be used to mediate 
> traffic exchange 
> >> between internal IPv6-based resources and external 
> IPv4-based network 
> >> elements.
> >> 2. Existing, IPv4-based routing domains offer native IPv6-based IP 
> >> transit that is physically accessible by the aspiring new 
> entrant(s).
> >> 3. Existing, Pv4-based routing service providers begin to 
> accommodate 
> >> incremental growth of existing and new customers using 
> IPv6 *in a way 
> >> that makes those new elements transparently reachable via native 
> >> IPv6- based IDR.* 4.
> >> Existing, Pv4-based routing domains make some or all of their 
> >> current, public-facing resources reachable via native 
> IPv6-based IDR.
> >>
> >> What else should be on the list? Additional comments, 
> questions, or 
> >> suggestions would be greatly appreciated!
> >>
> >> Thanks in advance,
> >>
> >> TV
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> 
> 


From charles at thewybles.com  Mon May 18 21:20:26 2009
From: charles at thewybles.com (Charles Wyble)
Date: Mon, 18 May 2009 12:20:26 -0700
Subject: tunneling native v6  connectivity
In-Reply-To: <4A1142C3.5070806@uk.clara.net>
References: <4A0DB2DF.8080106@thewybles.com> <4A1142C3.5070806@uk.clara.net>
Message-ID: <4A11B4FA.5050206@thewybles.com>



David Freedman wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
>> What would people recommend for this? I was thinking of using OpenVPN
>> and Vyatta.
> 
> Why not just use Linux static tunnels?
> 
> http://tldp.org/HOWTO/Linux+IPv6-HOWTO/configuring-ipv6to4-tunnels.html
> 
> Unless you are after encryption in such case use a VPN s/w product to
> create an SA for your tunnel endpoint pair and tunnel over this.


Thanks. I'll look into that.



From michael.dillon at bt.com  Tue May 19 11:48:00 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 19 May 2009 10:48:00 +0100
Subject: Factors, actions influencing the possibility/timing of IDR
	forIPv6-basedrouting domains?
In-Reply-To: <F910D18AF8C04992A1435594CAEF15CA@tedsdesk>
Message-ID: <28E139F46D45AF49A31950F88C49745801346329@E03MVZ2-UKDY.domain1.systemhost.net>

> Just about all of these folks are hosting on one of the large 
> virtual server farms, run by one of the virtual server 
> companies on the Internet.  None of those people are going to 
> go to their server farm operators and demand the operator add IPv6.
> 
> But, those farms know the same thing Google knows, which is 
> that eventually there's going to be IPv6-only clients out 
> there, and they don't want those clients complaining to their 
> own customers, and their own customers perhaps leaving 
> without even saying anything.

At least two of those "farms" are currently developing an
IPv6 container for IPv4 virtual servers. Basically, you use
XEN on Linux or OpenSolaris, both of which provide virtual
switch and router capabilities. The IPv4 machine's image is
loaded into XEN and the underlying OS provides the various 
translation/proxy services needed to make it work seemlessly
on the IPv6 Internet.

This type of service takes the pain out of moving a content
site to IPv6, and in fact, a hosting provider could just 
insert these translation/proxy services between the servers
and the Internet. But the virtual machine package is important
because when people start to offer this commercially, and
content providers decide to switch hosting providers to take
advantage of this easy migration path, it will pressure the
hosting providers to just bundle IPv6 gateway services into
their standard product offering.

These things will speed the shift to IPv6. It is not like
the early days of the Internet where the competing protocols
like NETBEUI, IPX, DECNET and so on, where fundamentally
incompatible with TCP/IP. Therefore I believe that the 
IPv6 transition will happen quite a bit faster than the
transition to IPv4.

> and the content providers in the US 
> will be the worst about becoming IPv6-only because of their 
> heavy investment in IPv4 infrastructure.

Possibly. But due to the elapsed time, one would think that
they have mostly recouped their investment. Given the global
economic situation, it is likely that the IPv6 transition will
coincide with a general improvement in the economy. At that
time, everyone will be ready to invest again, and IPv6 seems
like a low-hanging fruit scenario, i.e. it does not cost that
much to start using it.

--Michael Dillon

From tore at linpro.no  Sun May 24 13:51:00 2009
From: tore at linpro.no (Tore Anderson)
Date: Sun, 24 May 2009 13:51:00 +0200
Subject: NAT64 and DNS64 implementations
Message-ID: <4A1934A4.5040308@linpro.no>

Hi list,

I've been reading the NAT64/DNS64 drafts with great interest - it
definitely seems like something I could successfully deploy.  I'd like
to play around a bit with it, but I haven't been able to find actual
implementations so far.  Is there any?  Or is someone working on it?

I'd prefer an open-source based solution (e.g. a BIND patch for DNS64
and a Linux/Netfilter target for NAT64), but I'm not picky...

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

From tedm at ipinc.net  Tue May 26 20:03:14 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 26 May 2009 11:03:14 -0700
Subject: NAT64 and DNS64 implementations
In-Reply-To: <4A1934A4.5040308@linpro.no>
References: <4A1934A4.5040308@linpro.no>
Message-ID: <4A1C2EE2.9090103@ipinc.net>

Tore Anderson wrote:
> Hi list,
> 
> I've been reading the NAT64/DNS64 drafts with great interest - it
> definitely seems like something I could successfully deploy.  I'd like
> to play around a bit with it, but I haven't been able to find actual
> implementations so far.  Is there any?  Or is someone working on it?
> 
> I'd prefer an open-source based solution (e.g. a BIND patch for DNS64
> and a Linux/Netfilter target for NAT64), but I'm not picky...
> 
> Best regards,

You need to go here:

http://www.ietf.org/internet-drafts/draft-bagnulo-behave-nat64-03.txt

and at the bottom of the document you will find the e-mail addresses for 
Marcelo and Philip, then e-mail them.  If anyone is aware of an 
implementation, the authors of the draft will be.

IMHO, NAT64 will suffer the same fate as NAT-PT, but your welcome
to try...

Ted


From stevel at dedicatedservers.net.au  Tue May 26 20:29:45 2009
From: stevel at dedicatedservers.net.au (Steven Lisson)
Date: Wed, 27 May 2009 04:29:45 +1000
Subject: NAT64 and DNS64 implementations
In-Reply-To: <4A1C2EE2.9090103@ipinc.net>
Message-ID: <C035DD0A88EFF241A24578B7B8D5B505015DF79D@intranet.mail.hostingshop.com.au>



-----Original Message-----
From: ipv6-ops-bounces+stevel=dedicatedservers.net.au at lists.cluenet.de
[mailto:ipv6-ops-bounces+stevel=dedicatedservers.net.au at lists.cluenet.de
] On Behalf Of Ted Mittelstaedt
Sent: Wednesday, 27 May 2009 4:03 AM
To: Tore Anderson
Cc: ipv6-ops list
Subject: Re: NAT64 and DNS64 implementations

Tore Anderson wrote:
> Hi list,
> 
> I've been reading the NAT64/DNS64 drafts with great interest - it
> definitely seems like something I could successfully deploy.  I'd like
> to play around a bit with it, but I haven't been able to find actual
> implementations so far.  Is there any?  Or is someone working on it?
> 
> I'd prefer an open-source based solution (e.g. a BIND patch for DNS64
> and a Linux/Netfilter target for NAT64), but I'm not picky...
> 
> Best regards,

You need to go here:

http://www.ietf.org/internet-drafts/draft-bagnulo-behave-nat64-03.txt

and at the bottom of the document you will find the e-mail addresses for

Marcelo and Philip, then e-mail them.  If anyone is aware of an 
implementation, the authors of the draft will be.

IMHO, NAT64 will suffer the same fate as NAT-PT, but your welcome
to try...

Ted


From stevel at dedicatedservers.net.au  Tue May 26 20:31:57 2009
From: stevel at dedicatedservers.net.au (Steven Lisson)
Date: Wed, 27 May 2009 04:31:57 +1000
Subject: NAT64 and DNS64 implementations
In-Reply-To: <4A1C2EE2.9090103@ipinc.net>
Message-ID: <C035DD0A88EFF241A24578B7B8D5B505015DF79E@intranet.mail.hostingshop.com.au>

Hi,

Apologies both to the list for sending a blank response and to Ted for
responding directly (first was a result of trying to correct the
second).

If someone does find an implementation that works please post to the
list, I would like to give it a try on my network at home and am sure
that others would like to as well.

Regards,
Steven

-----Original Message-----
From: ipv6-ops-bounces+stevel=dedicatedservers.net.au at lists.cluenet.de
[mailto:ipv6-ops-bounces+stevel=dedicatedservers.net.au at lists.cluenet.de
] On Behalf Of Ted Mittelstaedt
Sent: Wednesday, 27 May 2009 4:03 AM
To: Tore Anderson
Cc: ipv6-ops list
Subject: Re: NAT64 and DNS64 implementations

Tore Anderson wrote:
> Hi list,
> 
> I've been reading the NAT64/DNS64 drafts with great interest - it
> definitely seems like something I could successfully deploy.  I'd like
> to play around a bit with it, but I haven't been able to find actual
> implementations so far.  Is there any?  Or is someone working on it?
> 
> I'd prefer an open-source based solution (e.g. a BIND patch for DNS64
> and a Linux/Netfilter target for NAT64), but I'm not picky...
> 
> Best regards,

You need to go here:

http://www.ietf.org/internet-drafts/draft-bagnulo-behave-nat64-03.txt

and at the bottom of the document you will find the e-mail addresses for

Marcelo and Philip, then e-mail them.  If anyone is aware of an 
implementation, the authors of the draft will be.

IMHO, NAT64 will suffer the same fate as NAT-PT, but your welcome
to try...

Ted


From stevel at dedicatedservers.net.au  Tue May 26 20:41:44 2009
From: stevel at dedicatedservers.net.au (Steven Lisson)
Date: Wed, 27 May 2009 04:41:44 +1000
Subject: IPv6 DNS server addresses on WinXP
Message-ID: <C035DD0A88EFF241A24578B7B8D5B505015DF79F@intranet.mail.hostingshop.com.au>

Hi,

I have a bit of a query about IPv6 on WinXP, ipconfig /all shows the
following for DNS servers, but does not appear to work, I know the
addresses are depreciated, however, if the above commands show them,
they should at least be used right?

DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                    fec0:0:0:ffff::2%1
                                    fec0:0:0:ffff::3%1

I have made sure that anything entering the work network to those
addresses gets forwards to a few DNS servers and have confirmed that
they respond on IPv6:

# dig www.google.com.au @fec0:0:0:ffff::1

; <<>> DiG 9.5.1-P1 <<>> www.google.com.au @fec0:0:0:ffff::1
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58797
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 7, ADDITIONAL: 7

;; QUESTION SECTION:
;www.google.com.au.             IN      A

;; ANSWER SECTION:
www.google.com.au.      27280   IN      CNAME   www.google.com.

[..etc..]

To show this I have a secondary config for IPv4 address config on my
laptop, if it doesn't get a DHCP lease over wireless after a few minutes
it configures itself (don't have DHCP at home, but do on other networks
connect to and changing it all the time is not fun).

During the couple of minutes its waiting for DHCPv4 it has a IPv6
address via RA but I am unable to ping www.arrnet.edu.au or any other
DNS address (should at least get an IP, doesn't matter queries are over
IPv6, should get any address available).

Am I missing something or are those DNS servers reported just eye candy?

Steve

From jeroen at unfix.org  Tue May 26 20:48:47 2009
From: jeroen at unfix.org (Jeroen Massar)
Date: Tue, 26 May 2009 20:48:47 +0200
Subject: IPv6 DNS server addresses on WinXP
In-Reply-To: <C035DD0A88EFF241A24578B7B8D5B505015DF79F@intranet.mail.hostingshop.com.au>
References: <C035DD0A88EFF241A24578B7B8D5B505015DF79F@intranet.mail.hostingshop.com.au>
Message-ID: <4A1C398F.5070901@spaghetti.zurich.ibm.com>

Steven Lisson wrote:
> Hi,
> 
> I have a bit of a query about IPv6 on WinXP, ipconfig /all shows the
> following for DNS servers, but does not appear to work, I know the
> addresses are depreciated, however, if the above commands show them,
> they should at least be used right?
> 
> DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
>                                     fec0:0:0:ffff::2%1
>                                     fec0:0:0:ffff::3%1

I have never understood why Microsoft configures those or how one could
even remove them, they seem to be always there and are dormant.

The latter is logical though:
   Windows XP's DNS resolver does not support DNS queries over IPv6.

(IPv6 transport that is, it does do AAAA queries)

Complain to Microsoft for that.... (they will most likely tell you to
upgrade to Windows 7 now though...)

Greets,
 Jeroen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090526/7714d16c/attachment.bin 

From kloch at kl.net  Tue May 26 21:23:46 2009
From: kloch at kl.net (Kevin Loch)
Date: Tue, 26 May 2009 15:23:46 -0400
Subject: IPv6 DNS server addresses on WinXP
In-Reply-To: <4A1C398F.5070901@spaghetti.zurich.ibm.com>
References: <C035DD0A88EFF241A24578B7B8D5B505015DF79F@intranet.mail.hostingshop.com.au>
	<4A1C398F.5070901@spaghetti.zurich.ibm.com>
Message-ID: <4A1C41C2.1080504@kl.net>

Jeroen Massar wrote:
> Steven Lisson wrote:
>> Hi,
>>
>> I have a bit of a query about IPv6 on WinXP, ipconfig /all shows the
>> following for DNS servers, but does not appear to work, I know the
>> addresses are depreciated, however, if the above commands show them,
>> they should at least be used right?
>>
>> DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
>>                                     fec0:0:0:ffff::2%1
>>                                     fec0:0:0:ffff::3%1
> 
> I have never understood why Microsoft configures those or how one could
> even remove them, they seem to be always there and are dormant.
> 
> The latter is logical though:
>    Windows XP's DNS resolver does not support DNS queries over IPv6.
> 
> (IPv6 transport that is, it does do AAAA queries)
> 
> Complain to Microsoft for that.... (they will most likely tell you to
> upgrade to Windows 7 now though...)
> 

There used to be a draft for DNS autodiscovery that specified those
addresses.  I used to see frequent DNS queries to those IPs when
I ran a 6to4 relay.  As a courtesy I added them to my relay and
ran a DNS resolver on them.  I'm not sure if it was WinXP but
something was doing DNS queries over IPv6 to those addresses.

- Kevin

From jeroen at unfix.org  Tue May 26 22:45:57 2009
From: jeroen at unfix.org (Jeroen Massar)
Date: Tue, 26 May 2009 22:45:57 +0200
Subject: IPv6 DNS server addresses on WinXP
In-Reply-To: <4A1C41C2.1080504@kl.net>
References: <C035DD0A88EFF241A24578B7B8D5B505015DF79F@intranet.mail.hostingshop.com.au>	<4A1C398F.5070901@spaghetti.zurich.ibm.com>
	<4A1C41C2.1080504@kl.net>
Message-ID: <4A1C5505.8050202@spaghetti.zurich.ibm.com>

Kevin Loch wrote:
> Jeroen Massar wrote:
>> Steven Lisson wrote:
[..]
>> The latter is logical though:
>>    Windows XP's DNS resolver does not support DNS queries over IPv6.
>>
>> (IPv6 transport that is, it does do AAAA queries)
>>
>> Complain to Microsoft for that.... (they will most likely tell you to
>> upgrade to Windows 7 now though...)
>>
> 
> There used to be a draft for DNS autodiscovery that specified those
> addresses.  I used to see frequent DNS queries to those IPs when
> I ran a 6to4 relay.  As a courtesy I added them to my relay and
> ran a DNS resolver on them.  I'm not sure if it was WinXP but
> something was doing DNS queries over IPv6 to those addresses.

Yeah, the DNS auto-discovery prolly has to do with it. Which is a draft
to solve the "we use just RA, but where do we get our DNS servers from".
(I am still in favor of a well known prefix for a 'local dns cache')

Prolly Vista/Win7 then, as the XP + 2000 + NT4 stacks never supported
DNS over IPv6 transport.

Effectively you should never ever see fec0::/10 as that was once
site-local and has been deprecated, site-local was never intended to be
routed (one of those reasons for only routing 2000::/3 on some boxes).

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090526/031420d6/attachment.bin 

From ipv6-ops at c0mplx.org  Thu May 28 11:27:11 2009
From: ipv6-ops at c0mplx.org (Kurt Jaeger)
Date: Thu, 28 May 2009 11:27:11 +0200
Subject: www.apache.org with IPv6, not reachable ?
Message-ID: <20090528092711.GP19455@home.opsec.eu>

Hi!

I just found out that www.apache.org got itself an AAAA record,
but it's not reachable from here.

Is it just me or ... ?

-- 
pi at opsec.eu            +49 171 3101372                        11 years to go !

From martin at airwire.ie  Thu May 28 11:29:19 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Thu, 28 May 2009 10:29:19 +0100
Subject: www.apache.org with IPv6, not reachable ?
In-Reply-To: <20090528092711.GP19455@home.opsec.eu>
References: <20090528092711.GP19455@home.opsec.eu>
Message-ID: <4A1E596F.3080502@airwire.ie>

Kurt Jaeger wrote:
> Hi!
> 
> I just found out that www.apache.org got itself an AAAA record,
> but it's not reachable from here.
> 
> Is it just me or ... ?

No, it's not just you and it's most likely a local configuration issue
on the server, as the trace goes all the way into the prefix, of where
it's hosted.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From jeroen at unfix.org  Thu May 28 11:30:11 2009
From: jeroen at unfix.org (Jeroen Massar)
Date: Thu, 28 May 2009 11:30:11 +0200
Subject: www.apache.org with IPv6, not reachable ?
In-Reply-To: <20090528092711.GP19455@home.opsec.eu>
References: <20090528092711.GP19455@home.opsec.eu>
Message-ID: <4A1E59A3.9020403@spaghetti.zurich.ibm.com>

Kurt Jaeger wrote:
> Hi!
> 
> I just found out that www.apache.org got itself an AAAA record,
> but it's not reachable from here.
> 
> Is it just me or ... ?

Looks firewalled to me.

BCC'd to people who might be able to peek at it.

apache.org serial is 2009050400, thus possibly the last change was more
than 3 weeks ago.

Greets,
 Jeroen



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090528/6e59b36d/attachment.bin 

From dom at earth.li  Thu May 28 13:53:15 2009
From: dom at earth.li (Dominic Hargreaves)
Date: Thu, 28 May 2009 12:53:15 +0100
Subject: www.apache.org with IPv6, not reachable ?
In-Reply-To: <20090528092711.GP19455@home.opsec.eu>
References: <20090528092711.GP19455@home.opsec.eu>
Message-ID: <20090528115315.GO10621@urchin.earth.li>

On Thu, May 28, 2009 at 11:27:11AM +0200, Kurt Jaeger wrote:
> Hi!
> 
> I just found out that www.apache.org got itself an AAAA record,
> but it's not reachable from here.
> 
> Is it just me or ... ?

Not reachable from the two IPv6 locations I have access to either:

traceroute to www.apache.org (2001:610:1:80bc:192:87:106:226) from 2001:8b0:1bf::1, 30 hops max, 16 byte packets
 1  b.armless.thn.aaisp.net.uk (2001:8b0:0:53::5a9b:3507)  28.983 ms  28.062 ms  28.482 ms
 2  a.restless.thn.aaisp.net.uk (2001:8b0:0:53::5a9b:3504)  28.203 ms  28.384 ms  28.192 ms
 3  linx.he.net (2001:7f8:4::1b1b:1)  28.789 ms  28.354 ms  28.471 ms
 4  10gigabitethernet1-1.core1.ams1.he.net (2001:470:0:3f::2)  36.106 ms  36.901 ms  35.796 ms
 5  XSR03.Asd001A.surf.net (2001:7f8:1::a500:1103:1)  37.271 ms  37.534 ms  37.2 ms
 6  AE2.500.JNR01.Asd001A.surf.net (2001:610:e08:76::78)  36.894 ms  37.001 ms  38.455 ms
 7  2001:610:f01:9168::170 (2001:610:f01:9168::170)  37.69 ms  37.937 ms  37.309 ms
 8  * * *
 9  * * 2001:610:f01:9168::170 (2001:610:f01:9168::170)  3037.12 ms !H
10  2001:610:f01:9168::170 (2001:610:f01:9168::170)  3033.79 ms !H  3033.75 ms !H  3036.28 ms !H

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

From gert at space.net  Thu May 28 15:29:37 2009
From: gert at space.net (Gert Doering)
Date: Thu, 28 May 2009 15:29:37 +0200
Subject: www.apache.org with IPv6, not reachable ?
In-Reply-To: <20090528092711.GP19455@home.opsec.eu>
References: <20090528092711.GP19455@home.opsec.eu>
Message-ID: <20090528132937.GY2776@Space.Net>

Hi,

On Thu, May 28, 2009 at 11:27:11AM +0200, Kurt Jaeger wrote:
> I just found out that www.apache.org got itself an AAAA record,
> but it's not reachable from here.
> 
> Is it just me or ... ?

Same here.  Routed to surfnet, but no response from anything host-ish.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From Wim.Biemolt at surfnet.nl  Thu May 28 15:27:45 2009
From: Wim.Biemolt at surfnet.nl (Wim Biemolt)
Date: Thu, 28 May 2009 15:27:45 +0200
Subject: [IPv6] Re: www.apache.org with IPv6, not reachable ?
In-Reply-To: <4A1E59A3.9020403@spaghetti.zurich.ibm.com>
References: <20090528092711.GP19455@home.opsec.eu>
	<4A1E59A3.9020403@spaghetti.zurich.ibm.com>
Message-ID: <4A1E9151.4030302@surfnet.nl>

Jeroen,

Jeroen Massar wrote:

> Looks firewalled to me.
> 
> BCC'd to people who might be able to peek at it.
> 
> apache.org serial is 2009050400, thus possibly the last change was more
> than 3 weeks ago.

Last time we mentiond this issue to them they replied

===

Yes, we have moved services back to XXXXXX (which doesn't have IPv6
right now  :(  ), because we are upgrading xxxxxx.apache.org, the
machine that normally hosts the website.

===

Cheers,

-Wim -/- SURFnet

From gert at space.net  Sat May 30 13:37:04 2009
From: gert at space.net (Gert Doering)
Date: Sat, 30 May 2009 13:37:04 +0200
Subject: [IPv6] Re: www.apache.org with IPv6, not reachable ?
In-Reply-To: <4A1E9151.4030302@surfnet.nl>
References: <20090528092711.GP19455@home.opsec.eu>
	<4A1E59A3.9020403@spaghetti.zurich.ibm.com>
	<4A1E9151.4030302@surfnet.nl>
Message-ID: <20090530113704.GO2776@Space.Net>

Hi,

On Thu, May 28, 2009 at 03:27:45PM +0200, Wim Biemolt wrote:
> Last time we mentiond this issue to them they replied
> 
> ===
> 
> Yes, we have moved services back to XXXXXX (which doesn't have IPv6
> right now  :(  ), because we are upgrading xxxxxx.apache.org, the
> machine that normally hosts the website.
> 
> ===

IPv6 *is* "Rocket Science", after all... like "removing AAAA entries
when you know the machine will be down for a week"...

*sigh*

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279