From sethm at rollernet.us  Wed Oct  1 20:20:16 2008
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 01 Oct 2008 11:20:16 -0700
Subject: Sprint IPv6
Message-ID: <48E3BF60.4050509@rollernet.us>

Does anyone know about the current state of IPv6 over at Sprint? Last I
heard they were supposed to have native dual-stack in early 2008. I've
tried asking ipv6-support at sprint.net on September 4th, but haven't heard
from anyone yet.

~Seth

From ik5pvx at gmail.com  Wed Oct  1 20:22:35 2008
From: ik5pvx at gmail.com (Pierfrancesco Caci)
Date: Wed, 1 Oct 2008 20:22:35 +0200
Subject: Sprint IPv6
In-Reply-To: <48E3BF60.4050509@rollernet.us>
References: <48E3BF60.4050509@rollernet.us>
Message-ID: <4013b2300810011122l5541f646l81ef3164c347e6c5@mail.gmail.com>

On Wed, Oct 1, 2008 at 8:20 PM, Seth Mattinen <sethm at rollernet.us> wrote:
> Does anyone know about the current state of IPv6 over at Sprint? Last I
> heard they were supposed to have native dual-stack in early 2008. I've
> tried asking ipv6-support at sprint.net on September 4th, but haven't heard
> from anyone yet.
>

last I heard it was "late 2008"



-- 
 Pierfrancesco Caci, ik5pvx

From lambert at psc.edu  Wed Oct  1 20:24:46 2008
From: lambert at psc.edu (Michael Lambert)
Date: Wed, 1 Oct 2008 14:24:46 -0400
Subject: Sprint IPv6
In-Reply-To: <4013b2300810011122l5541f646l81ef3164c347e6c5@mail.gmail.com>
References: <48E3BF60.4050509@rollernet.us>
	<4013b2300810011122l5541f646l81ef3164c347e6c5@mail.gmail.com>
Message-ID: <273A6ACB-3143-4AF1-A60B-3F4DC989A541@psc.edu>

On 1 Oct 2008, at 14:22, Pierfrancesco Caci wrote:

> On Wed, Oct 1, 2008 at 8:20 PM, Seth Mattinen <sethm at rollernet.us>  
> wrote:
>> Does anyone know about the current state of IPv6 over at Sprint?  
>> Last I
>> heard they were supposed to have native dual-stack in early 2008.  
>> I've
>> tried asking ipv6-support at sprint.net on September 4th, but haven't  
>> heard
>> from anyone yet.
>>
>
> last I heard it was "late 2008"

They are still just tunneled.  My understanding is that "late 2008" is  
optimistic.

Michael


From dwhite at olp.net  Wed Oct  1 20:26:07 2008
From: dwhite at olp.net (Dan White)
Date: Wed, 01 Oct 2008 13:26:07 -0500
Subject: Sprint IPv6
In-Reply-To: <48E3BF60.4050509@rollernet.us>
References: <48E3BF60.4050509@rollernet.us>
Message-ID: <48E3C0BF.5040405@olp.net>

Seth Mattinen wrote:
> Does anyone know about the current state of IPv6 over at Sprint? Last I
> heard they were supposed to have native dual-stack in early 2008. I've
> tried asking ipv6-support at sprint.net on September 4th, but haven't heard
> from anyone yet.
>
> ~Seth
>   


I received the same response when I asked last year. When I asked about 
being a beta tester for native IPv6 service (we're a Private Line 
customer, over DS3), I was told that they were working on a roll out for 
early 2008, and that perhaps they could include our upstream routers as 
some of the first to upgrade.

- Dan

From md at Linux.IT  Wed Oct  1 20:53:25 2008
From: md at Linux.IT (Marco d'Itri)
Date: Wed, 1 Oct 2008 20:53:25 +0200
Subject: Sprint IPv6
In-Reply-To: <48E3BF60.4050509@rollernet.us>
References: <48E3BF60.4050509@rollernet.us>
Message-ID: <20081001185325.GA22406@bongo.bofh.it>

On Oct 01, Seth Mattinen <sethm at rollernet.us> wrote:

> Does anyone know about the current state of IPv6 over at Sprint? Last I
> heard they were supposed to have native dual-stack in early 2008. I've
I have been told that native v6 (or even more tunnel routers) was very
close for about four years.
Then I switched to GBLX.

-- 
ciao,
Marco

From gert at space.net  Wed Oct  1 22:56:30 2008
From: gert at space.net (Gert Doering)
Date: Wed, 1 Oct 2008 22:56:30 +0200
Subject: Sprint IPv6
In-Reply-To: <20081001185325.GA22406@bongo.bofh.it>
References: <48E3BF60.4050509@rollernet.us>
	<20081001185325.GA22406@bongo.bofh.it>
Message-ID: <20081001205630.GF28549@Space.Net>

Hi,

On Wed, Oct 01, 2008 at 08:53:25PM +0200, Marco d'Itri wrote:
> Then I switched to GBLX.

... so you got 6PE instead.  Dunno whether that's better.

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 ik5pvx at gmail.com  Thu Oct  2 08:50:46 2008
From: ik5pvx at gmail.com (Pierfrancesco Caci)
Date: Thu, 2 Oct 2008 08:50:46 +0200
Subject: Sprint IPv6
In-Reply-To: <20081001205630.GF28549@Space.Net>
References: <48E3BF60.4050509@rollernet.us>
	<20081001185325.GA22406@bongo.bofh.it>
	<20081001205630.GF28549@Space.Net>
Message-ID: <4013b2300810012350u1aaaa977s596cf3a8ffded300@mail.gmail.com>

On Wed, Oct 1, 2008 at 10:56 PM, Gert Doering <gert at space.net> wrote:
> Hi,
>
> On Wed, Oct 01, 2008 at 08:53:25PM +0200, Marco d'Itri wrote:
>> Then I switched to GBLX.
>
> ... so you got 6PE instead.  Dunno whether that's better.

Why would that matter? have you seen issues with providers/peers that use 6PE?




-- 
 Pierfrancesco Caci, ik5pvx

From gert at space.net  Thu Oct  2 09:44:50 2008
From: gert at space.net (Gert Doering)
Date: Thu, 2 Oct 2008 09:44:50 +0200
Subject: Sprint IPv6
In-Reply-To: <4013b2300810012350u1aaaa977s596cf3a8ffded300@mail.gmail.com>
References: <48E3BF60.4050509@rollernet.us>
	<20081001185325.GA22406@bongo.bofh.it>
	<20081001205630.GF28549@Space.Net>
	<4013b2300810012350u1aaaa977s596cf3a8ffded300@mail.gmail.com>
Message-ID: <20081002074450.GH28549@Space.Net>

Hi,

On Thu, Oct 02, 2008 at 08:50:46AM +0200, Pierfrancesco Caci wrote:
> On Wed, Oct 1, 2008 at 10:56 PM, Gert Doering <gert at space.net> wrote:
> >
> > On Wed, Oct 01, 2008 at 08:53:25PM +0200, Marco d'Itri wrote:
> >> Then I switched to GBLX.
> >
> > ... so you got 6PE instead.  Dunno whether that's better.
> 
> Why would that matter? 

Well, it's "swap one tunnel technology to another tunnel technology",
so the general question needs to be "why would that tunnel variant be
any better?".

> have you seen issues with providers/peers that use 6PE?

Oh yes.  Especially with this one.

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 ik5pvx at gmail.com  Thu Oct  2 10:33:09 2008
From: ik5pvx at gmail.com (Pierfrancesco Caci)
Date: Thu, 2 Oct 2008 10:33:09 +0200
Subject: Sprint IPv6
In-Reply-To: <20081002074450.GH28549@Space.Net>
References: <48E3BF60.4050509@rollernet.us>
	<20081001185325.GA22406@bongo.bofh.it>
	<20081001205630.GF28549@Space.Net>
	<4013b2300810012350u1aaaa977s596cf3a8ffded300@mail.gmail.com>
	<20081002074450.GH28549@Space.Net>
Message-ID: <4013b2300810020133t7bb3e633y1ceb14ea5cbf2bd0@mail.gmail.com>

On Thu, Oct 2, 2008 at 9:44 AM, Gert Doering <gert at space.net> wrote:
> Hi,
>
> On Thu, Oct 02, 2008 at 08:50:46AM +0200, Pierfrancesco Caci wrote:
>> On Wed, Oct 1, 2008 at 10:56 PM, Gert Doering <gert at space.net> wrote:
>> >
>> > On Wed, Oct 01, 2008 at 08:53:25PM +0200, Marco d'Itri wrote:
>> >> Then I switched to GBLX.
>> >
>> > ... so you got 6PE instead.  Dunno whether that's better.
>>
>> Why would that matter?
>
> Well, it's "swap one tunnel technology to another tunnel technology",
> so the general question needs to be "why would that tunnel variant be
> any better?".
>

because you already have mpls on your net?


>> have you seen issues with providers/peers that use 6PE?
>
> Oh yes.  Especially with this one.


without entering in a "let's blame my provider" contest, can you tell
us what kind of problems did you see? I'm interested because we also
use 6PE and, besides that time I disabled mpls on a link trying to
solve a different problem, I have not received any feedback (positive
or negative) from my customers. Usually, that means things just work,
but you can never tell



-- 
 Pierfrancesco Caci, ik5pvx

From gert at space.net  Thu Oct  2 10:39:27 2008
From: gert at space.net (Gert Doering)
Date: Thu, 2 Oct 2008 10:39:27 +0200
Subject: Sprint IPv6
In-Reply-To: <4013b2300810020133t7bb3e633y1ceb14ea5cbf2bd0@mail.gmail.com>
References: <48E3BF60.4050509@rollernet.us>
	<20081001185325.GA22406@bongo.bofh.it>
	<20081001205630.GF28549@Space.Net>
	<4013b2300810012350u1aaaa977s596cf3a8ffded300@mail.gmail.com>
	<20081002074450.GH28549@Space.Net>
	<4013b2300810020133t7bb3e633y1ceb14ea5cbf2bd0@mail.gmail.com>
Message-ID: <20081002083927.GM28549@Space.Net>

Hi,

On Thu, Oct 02, 2008 at 10:33:09AM +0200, Pierfrancesco Caci wrote:
> >> have you seen issues with providers/peers that use 6PE?
> > Oh yes.  Especially with this one.
> 
> without entering in a "let's blame my provider" contest, can you tell
> us what kind of problems did you see? I'm interested because we also
> use 6PE and, besides that time I disabled mpls on a link trying to
> solve a different problem, I have not received any feedback (positive
> or negative) from my customers. Usually, that means things just work,
> but you can never tell

As a customer, we really really dislike seeing 6PE used in our upstreams'
networks because it means that traceroute6 is becoming useless - you can
see that "there is a problem somewhere in the upstream network", but 
you have no chance of pinpointing things like packet loss or (worse)
black holes to the routers/links where it's happening.

In this specific case, there were some problems with RSVP reservations
that led to MPLS tunnels going down completely in case of link outages,
which the control plane didn't notice - so BGP claimed "everything is
fine" while the data packets disappeared into a big black hole.

(I'm not sure on the underlying details, as we've never done 6PE+RSVP,
but that's how things have been explained to 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
-------------- 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/20081002/266faa15/attachment.bin 

From Olaf.Bonness at t-systems.com  Thu Oct  2 10:51:25 2008
From: Olaf.Bonness at t-systems.com (Bonness, Olaf)
Date: Thu, 2 Oct 2008 10:51:25 +0200
Subject: Sprint IPv6
In-Reply-To: <20081002083927.GM28549@Space.Net>
References: <48E3BF60.4050509@rollernet.us><20081001185325.GA22406@bongo.bofh.it><20081001205630.GF28549@Space.Net><4013b2300810012350u1aaaa977s596cf3a8ffded300@mail.gmail.com><20081002074450.GH28549@Space.Net><4013b2300810020133t7bb3e633y1ceb14ea5cbf2bd0@mail.gmail.com>
	<20081002083927.GM28549@Space.Net>
Message-ID: <D83105B2AC38794CB78ADA2959F2C44F017F4C9C@S4DE9JSAACY.ost.t-com.de>

Comments inline. 

> -----Original Message-----
> From: 
> ipv6-ops-bounces+olaf.bonness=t-systems.com at lists.cluenet.de 
> [mailto:ipv6-ops-bounces+olaf.bonness=t-systems.com at lists.clue
> net.de] On Behalf Of Gert Doering
> Sent: Thursday, October 02, 2008 10:39 AM
> To: Pierfrancesco Caci
> Cc: Gert Doering; ipv6-ops at lists.cluenet.de
> Subject: Re: Sprint IPv6
> 
> Hi,
> 
> On Thu, Oct 02, 2008 at 10:33:09AM +0200, Pierfrancesco Caci wrote:
> > >> have you seen issues with providers/peers that use 6PE?
> > > Oh yes.  Especially with this one.
> > 
> > without entering in a "let's blame my provider" contest, 
> can you tell
> > us what kind of problems did you see? I'm interested because we also
> > use 6PE and, besides that time I disabled mpls on a link trying to
> > solve a different problem, I have not received any feedback 
> (positive
> > or negative) from my customers. Usually, that means things 
> just work,
> > but you can never tell
> 
> As a customer, we really really dislike seeing 6PE used in 
> our upstreams'
> networks because it means that traceroute6 is becoming 
> useless - you can
> see that "there is a problem somewhere in the upstream network", but 
> you have no chance of pinpointing things like packet loss or (worse)
> black holes to the routers/links where it's happening.
> 

But this seems true for all tunneling techniques and not only for 6PE or am I misssing something?

br 
olaf


> ... skipped ...

From jeroen at unfix.org  Thu Oct  2 10:53:56 2008
From: jeroen at unfix.org (Jeroen Massar)
Date: Thu, 02 Oct 2008 10:53:56 +0200
Subject: Sprint IPv6
In-Reply-To: <D83105B2AC38794CB78ADA2959F2C44F017F4C9C@S4DE9JSAACY.ost.t-com.de>
References: <48E3BF60.4050509@rollernet.us><20081001185325.GA22406@bongo.bofh.it><20081001205630.GF28549@Space.Net><4013b2300810012350u1aaaa977s596cf3a8ffded300@mail.gmail.com><20081002074450.GH28549@Space.Net><4013b2300810020133t7bb3e633y1ceb14ea5cbf2bd0@mail.gmail.com>	<20081002083927.GM28549@Space.Net>
	<D83105B2AC38794CB78ADA2959F2C44F017F4C9C@S4DE9JSAACY.ost.t-com.de>
Message-ID: <48E48C24.1070709@spaghetti.zurich.ibm.com>

Bonness, Olaf wrote:
[..]
> But this seems true for all tunneling techniques and not only for
> 6PE or am I misssing something?

I guess, the 'using it' factor is what you are missing? :)

Traceroutes work like a charm for proto-41, ayiya, openvpn, tinc,
everything else I can name....

(Unless you misconfigure stuff like MTU, or do ICMP
ratelimitting/filtering of course :)

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/20081002/3c0c8449/attachment-0001.bin 

From ik5pvx at gmail.com  Thu Oct  2 10:56:34 2008
From: ik5pvx at gmail.com (Pierfrancesco Caci)
Date: Thu, 2 Oct 2008 10:56:34 +0200
Subject: Sprint IPv6
In-Reply-To: <20081002083927.GM28549@Space.Net>
References: <48E3BF60.4050509@rollernet.us>
	<20081001185325.GA22406@bongo.bofh.it>
	<20081001205630.GF28549@Space.Net>
	<4013b2300810012350u1aaaa977s596cf3a8ffded300@mail.gmail.com>
	<20081002074450.GH28549@Space.Net>
	<4013b2300810020133t7bb3e633y1ceb14ea5cbf2bd0@mail.gmail.com>
	<20081002083927.GM28549@Space.Net>
Message-ID: <4013b2300810020156v55e0290egd0e4e9aed0c4c1a8@mail.gmail.com>

On Thu, Oct 2, 2008 at 10:39 AM, Gert Doering <gert at space.net> wrote:

>
> As a customer, we really really dislike seeing 6PE used in our upstreams'
> networks because it means that traceroute6 is becoming useless - you can
> see that "there is a problem somewhere in the upstream network", but
> you have no chance of pinpointing things like packet loss or (worse)
> black holes to the routers/links where it's happening.


this happens with  ipv4 as well. Of course you can make intermediate
steps visibile by setting 'mpls ip propagate-ttl', but then you'd end
up with a horde of whiners complaining that traceroutes take 500ms...

>
> In this specific case, there were some problems with RSVP reservations
> that led to MPLS tunnels going down completely in case of link outages,
> which the control plane didn't notice - so BGP claimed "everything is
> fine" while the data packets disappeared into a big black hole.
>
> (I'm not sure on the underlying details, as we've never done 6PE+RSVP,
> but that's how things have been explained to me).


Ok. Was the problem confined to IPv6, or did you experience some fun
in v4 as well, at the same time?






-- 
 Pierfrancesco Caci, ik5pvx

From gert at space.net  Thu Oct  2 11:17:24 2008
From: gert at space.net (Gert Doering)
Date: Thu, 2 Oct 2008 11:17:24 +0200
Subject: Sprint IPv6
In-Reply-To: <D83105B2AC38794CB78ADA2959F2C44F017F4C9C@S4DE9JSAACY.ost.t-com.de>
References: <20081002083927.GM28549@Space.Net>
	<D83105B2AC38794CB78ADA2959F2C44F017F4C9C@S4DE9JSAACY.ost.t-com.de>
Message-ID: <20081002091724.GN28549@Space.Net>

Hi,

On Thu, Oct 02, 2008 at 10:51:25AM +0200, Bonness, Olaf wrote:
> > As a customer, we really really dislike seeing 6PE used in 
> > our upstreams'
> > networks because it means that traceroute6 is becoming 
> > useless - you can
> > see that "there is a problem somewhere in the upstream network", but 
> > you have no chance of pinpointing things like packet loss or (worse)
> > black holes to the routers/links where it's happening.
> 
> But this seems true for all tunneling techniques and not only for 6PE 
> or am I misssing something?

Yes.  6PE has somewhat nastier failure modes due to the decoupling of
data and control plane, though.

(If a "normal" tunnel breaks, usually the IGP used will notice that the
tunnel isn't working anymore, and will route around it and/or the BGP
session will break)

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
-------------- 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/20081002/ea57d86a/attachment.bin 

From gert at space.net  Thu Oct  2 11:18:34 2008
From: gert at space.net (Gert Doering)
Date: Thu, 2 Oct 2008 11:18:34 +0200
Subject: Sprint IPv6
In-Reply-To: <48E48C24.1070709@spaghetti.zurich.ibm.com>
References: <20081002083927.GM28549@Space.Net>
	<D83105B2AC38794CB78ADA2959F2C44F017F4C9C@S4DE9JSAACY.ost.t-com.de>
	<48E48C24.1070709@spaghetti.zurich.ibm.com>
Message-ID: <20081002091834.GO28549@Space.Net>

Hi,

On Thu, Oct 02, 2008 at 10:53:56AM +0200, Jeroen Massar wrote:
> Bonness, Olaf wrote:
> [..]
> > But this seems true for all tunneling techniques and not only for
> > 6PE or am I misssing something?
> 
> I guess, the 'using it' factor is what you are missing? :)
> 
> Traceroutes work like a charm for proto-41, ayiya, openvpn, tinc,
> everything else I can name....

Well, actually, it doesn't.  You can see "before the tunnel it's fast,
after the tunnel, it's slow" - but there is no way to figure out 
at which point of the underlying non-tunneled infrastructure the bottleneck
might be.

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
-------------- 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/20081002/70444fc4/attachment.bin 

From gert at space.net  Thu Oct  2 11:19:04 2008
From: gert at space.net (Gert Doering)
Date: Thu, 2 Oct 2008 11:19:04 +0200
Subject: Sprint IPv6
In-Reply-To: <4013b2300810020156v55e0290egd0e4e9aed0c4c1a8@mail.gmail.com>
References: <48E3BF60.4050509@rollernet.us>
	<20081001185325.GA22406@bongo.bofh.it>
	<20081001205630.GF28549@Space.Net>
	<4013b2300810012350u1aaaa977s596cf3a8ffded300@mail.gmail.com>
	<20081002074450.GH28549@Space.Net>
	<4013b2300810020133t7bb3e633y1ceb14ea5cbf2bd0@mail.gmail.com>
	<20081002083927.GM28549@Space.Net>
	<4013b2300810020156v55e0290egd0e4e9aed0c4c1a8@mail.gmail.com>
Message-ID: <20081002091904.GP28549@Space.Net>

Hi,

On Thu, Oct 02, 2008 at 10:56:34AM +0200, Pierfrancesco Caci wrote:
> Ok. Was the problem confined to IPv6, or did you experience some fun
> in v4 as well, at the same time?

That was only IPv6.

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
-------------- 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/20081002/6ecf3615/attachment.bin 

From jeroen at unfix.org  Thu Oct  2 11:24:29 2008
From: jeroen at unfix.org (Jeroen Massar)
Date: Thu, 02 Oct 2008 11:24:29 +0200
Subject: Sprint IPv6
In-Reply-To: <20081002091834.GO28549@Space.Net>
References: <20081002083927.GM28549@Space.Net>
	<D83105B2AC38794CB78ADA2959F2C44F017F4C9C@S4DE9JSAACY.ost.t-com.de>
	<48E48C24.1070709@spaghetti.zurich.ibm.com>
	<20081002091834.GO28549@Space.Net>
Message-ID: <48E4934D.2050805@spaghetti.zurich.ibm.com>

Gert Doering wrote:
> Hi,
> 
> On Thu, Oct 02, 2008 at 10:53:56AM +0200, Jeroen Massar wrote:
>> Bonness, Olaf wrote:
>> [..]
>>> But this seems true for all tunneling techniques and not only for
>>> 6PE or am I misssing something?
>> I guess, the 'using it' factor is what you are missing? :)
>>
>> Traceroutes work like a charm for proto-41, ayiya, openvpn, tinc,
>> everything else I can name....
> 
> Well, actually, it doesn't.  You can see "before the tunnel it's fast,
> after the tunnel, it's slow" - but there is no way to figure out 
> at which point of the underlying non-tunneled infrastructure the bottleneck
> might be.

Of course, tunneling adds overhead and latency because of encap/decap.
Those things tend to be difficult to determine.

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/20081002/2c04e817/attachment.bin 

From gert at space.net  Thu Oct  2 11:34:30 2008
From: gert at space.net (Gert Doering)
Date: Thu, 2 Oct 2008 11:34:30 +0200
Subject: Sprint IPv6
In-Reply-To: <48E4934D.2050805@spaghetti.zurich.ibm.com>
References: <20081002083927.GM28549@Space.Net>
	<D83105B2AC38794CB78ADA2959F2C44F017F4C9C@S4DE9JSAACY.ost.t-com.de>
	<48E48C24.1070709@spaghetti.zurich.ibm.com>
	<20081002091834.GO28549@Space.Net>
	<48E4934D.2050805@spaghetti.zurich.ibm.com>
Message-ID: <20081002093429.GQ28549@Space.Net>

Hi,

On Thu, Oct 02, 2008 at 11:24:29AM +0200, Jeroen Massar wrote:
> >> Traceroutes work like a charm for proto-41, ayiya, openvpn, tinc,
> >> everything else I can name....
> > 
> > Well, actually, it doesn't.  You can see "before the tunnel it's fast,
> > after the tunnel, it's slow" - but there is no way to figure out 
> > at which point of the underlying non-tunneled infrastructure the bottleneck
> > might be.
> 
> Of course, tunneling adds overhead and latency because of encap/decap.
> Those things tend to be difficult to determine.

That's not the point - the point is "tunneling hides topology", and if
there is a problem in that topology, with tunnels, your options to 
diagnose issues are reduced.

I'm not talking about "local" tunnels, skipping a non-IPv6-capable BRAS
or such, but about "packets enters upstream network in Frankfurt, Germany,
and reappears in some place in the US, and somewhere in between you 
have a bigger-than-normal latency jump and packet loss".  

Usually worsened by "when we run tests from our hotline desk, we cannot
see anything unusual".

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
-------------- 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/20081002/edaed3df/attachment.bin 

From jeroen at unfix.org  Thu Oct  2 11:46:22 2008
From: jeroen at unfix.org (Jeroen Massar)
Date: Thu, 02 Oct 2008 11:46:22 +0200
Subject: Sprint IPv6
In-Reply-To: <20081002093429.GQ28549@Space.Net>
References: <20081002083927.GM28549@Space.Net>
	<D83105B2AC38794CB78ADA2959F2C44F017F4C9C@S4DE9JSAACY.ost.t-com.de>
	<48E48C24.1070709@spaghetti.zurich.ibm.com>
	<20081002091834.GO28549@Space.Net>
	<48E4934D.2050805@spaghetti.zurich.ibm.com>
	<20081002093429.GQ28549@Space.Net>
Message-ID: <48E4986E.5010708@spaghetti.zurich.ibm.com>

Gert Doering wrote:
[..]
> That's not the point - the point is "tunneling hides topology", and if
> there is a problem in that topology, with tunnels, your options to 
> diagnose issues are reduced.

Point taken.

IMHO a tunnel is just a transport method, just like DSL is, which would
be IPv4 over Ethernet->ATM over a phone line, that is in effect three
levels already, and then some people tunnel add IPv6 tunnels inside that.

If one doesn't own/control/see the topology where a tunnel goes over,
for one that is just one hop. Indeed this makes diagnosing things from
an external point of view really hard.

> I'm not talking about "local" tunnels, skipping a non-IPv6-capable BRAS
> or such, but about "packets enters upstream network in Frankfurt, Germany,
> and reappears in some place in the US, and somewhere in between you 
> have a bigger-than-normal latency jump and packet loss".  

Depends on your network design of course, but I definitely would not do
that kind of setup; but I think on the level of IP mostly and not on the
layers below it.

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/20081002/0aac0924/attachment.bin 

From truman at suspicious.org  Thu Oct  2 20:16:58 2008
From: truman at suspicious.org (Truman Boyes)
Date: Thu, 2 Oct 2008 14:16:58 -0400
Subject: Sprint IPv6
In-Reply-To: <20081002091834.GO28549@Space.Net>
References: <20081002083927.GM28549@Space.Net>
	<D83105B2AC38794CB78ADA2959F2C44F017F4C9C@S4DE9JSAACY.ost.t-com.de>
	<48E48C24.1070709@spaghetti.zurich.ibm.com>
	<20081002091834.GO28549@Space.Net>
Message-ID: <5036A57C-62E9-4E2F-BA75-D37AF956B7BD@suspicious.org>

This issue that you describe is not specific to IPv6, but rather is an  
issue with any networks that use MPLS VPNs, and do not propagate TTL.  
When providers put the "internet" table into VRFs that same issue is  
presented, and there are *many* ISPs that have decided to carry inet  
routes into VPNs for various reasons.

As you pointed out there are complications with doing this; but 6PE  
doesn't have to "hide" the hops of the MPLS core. It just happens to  
be a method that providers have adopted. The previous statement around  
"normal tunnels" being detected by IGP would stand true with MPLS  
networks as well, assuming the IGP is being used simply to provide  
reachability to loopback addresses, and tunnels are constructed  
between loopbacks, and routes are solved to tunnel interfaces. Its  
recursion, but it all comes back to normal IP hops.

Truman

On 2/10/2008, at 5:18 AM, Gert Doering wrote:

> Hi,
>
> On Thu, Oct 02, 2008 at 10:53:56AM +0200, Jeroen Massar wrote:
>> Bonness, Olaf wrote:
>> [..]
>>> But this seems true for all tunneling techniques and not only for
>>> 6PE or am I misssing something?
>>
>> I guess, the 'using it' factor is what you are missing? :)
>>
>> Traceroutes work like a charm for proto-41, ayiya, openvpn, tinc,
>> everything else I can name....
>
> Well, actually, it doesn't.  You can see "before the tunnel it's fast,
> after the tunnel, it's slow" - but there is no way to figure out
> at which point of the underlying non-tunneled infrastructure the  
> bottleneck
> might be.
>
> 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  Thu Oct  2 23:12:34 2008
From: gert at space.net (Gert Doering)
Date: Thu, 2 Oct 2008 23:12:34 +0200
Subject: Sprint IPv6
In-Reply-To: <5036A57C-62E9-4E2F-BA75-D37AF956B7BD@suspicious.org>
References: <20081002083927.GM28549@Space.Net>
	<D83105B2AC38794CB78ADA2959F2C44F017F4C9C@S4DE9JSAACY.ost.t-com.de>
	<48E48C24.1070709@spaghetti.zurich.ibm.com>
	<20081002091834.GO28549@Space.Net>
	<5036A57C-62E9-4E2F-BA75-D37AF956B7BD@suspicious.org>
Message-ID: <20081002211234.GR28549@Space.Net>

Hi,

On Thu, Oct 02, 2008 at 02:16:58PM -0400, Truman Boyes wrote:
> This issue that you describe is not specific to IPv6, but rather is an  
> issue with any networks that use MPLS VPNs, and do not propagate TTL.  

Except that with IPv6 over MPLS, you can't even do TTL-propagation - how
is an IPv4+MPLS router to respond to an IPv6 traceroute?

(Which is the way it's typically deployed today - "don't mess with this
IPv6 thingie in our core, just tunnel it via MPLS across the core").

You can't run a MPLS core without IPv4 - but you can very well run it 
without IPv6.

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
-------------- 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/20081002/c8ce5790/attachment.bin 

From gall at switch.ch  Fri Oct  3 16:19:27 2008
From: gall at switch.ch (Alexander Gall)
Date: Fri, 3 Oct 2008 16:19:27 +0200
Subject: Sprint IPv6
In-Reply-To: <20081002083927.GM28549@Space.Net>
References: <48E3BF60.4050509@rollernet.us>
	<20081001185325.GA22406@bongo.bofh.it>
	<20081001205630.GF28549@Space.Net>
	<4013b2300810012350u1aaaa977s596cf3a8ffded300@mail.gmail.com>
	<20081002074450.GH28549@Space.Net>
	<4013b2300810020133t7bb3e633y1ceb14ea5cbf2bd0@mail.gmail.com>
	<20081002083927.GM28549@Space.Net>
Message-ID: <18662.10735.63059.850667@hadron.switch.ch>

On Thu, 2 Oct 2008 10:39:27 +0200, Gert Doering <gert at space.net> said:

> Hi,
> On Thu, Oct 02, 2008 at 10:33:09AM +0200, Pierfrancesco Caci wrote:
>> >> have you seen issues with providers/peers that use 6PE?
>> > Oh yes.  Especially with this one.
>> 
>> without entering in a "let's blame my provider" contest, can you tell
>> us what kind of problems did you see? I'm interested because we also
>> use 6PE and, besides that time I disabled mpls on a link trying to
>> solve a different problem, I have not received any feedback (positive
>> or negative) from my customers. Usually, that means things just work,
>> but you can never tell

> As a customer, we really really dislike seeing 6PE used in our upstreams'
> networks because it means that traceroute6 is becoming useless - you can
> see that "there is a problem somewhere in the upstream network", but 
> you have no chance of pinpointing things like packet loss or (worse)
> black holes to the routers/links where it's happening.

> In this specific case, there were some problems with RSVP reservations
> that led to MPLS tunnels going down completely in case of link outages,
> which the control plane didn't notice - so BGP claimed "everything is
> fine" while the data packets disappeared into a big black hole.

I'd like to chime in here, because my frustration level with the 6PE
implementation of GBLX has just increased by another notch these days.
We've been using them as IPv6 upstream for a couple of years and had
numerous issues with routing blackholes, which they are just unable to
fix permanently (or they just don't care enough).  They never notice
these issues themselves, then "bounce a tunnel" (as they call it) to
fix it or simply drag it on long enough without doing anything until
the problem disappears by itself.  Sigh.

We never had any problems with other upstreams that have simple IPv6
overlays.  Help me god when they start deploying "production" IPv6
using 6PE :-(

-- 
Alex


From gert at space.net  Mon Oct  6 15:46:49 2008
From: gert at space.net (Gert Doering)
Date: Mon, 6 Oct 2008 15:46:49 +0200
Subject: Sprint IPv6
In-Reply-To: <20081006133959.GB26220@bo.mcbone.net>
References: <20081002083927.GM28549@Space.Net>
	<D83105B2AC38794CB78ADA2959F2C44F017F4C9C@S4DE9JSAACY.ost.t-com.de>
	<48E48C24.1070709@spaghetti.zurich.ibm.com>
	<20081002091834.GO28549@Space.Net>
	<5036A57C-62E9-4E2F-BA75-D37AF956B7BD@suspicious.org>
	<20081002211234.GR28549@Space.Net>
	<20081006133959.GB26220@bo.mcbone.net>
Message-ID: <20081006134649.GM28549@Space.Net>

Hi,

On Mon, Oct 06, 2008 at 03:39:59PM +0200, Jens Rosenboom wrote:
> On Thu, Oct 02, 2008 at 11:12:34PM +0200, Gert Doering wrote:
> > On Thu, Oct 02, 2008 at 02:16:58PM -0400, Truman Boyes wrote:
> > > This issue that you describe is not specific to IPv6, but rather is an  
> > > issue with any networks that use MPLS VPNs, and do not propagate TTL.  
> > 
> > Except that with IPv6 over MPLS, you can't even do TTL-propagation - how
> > is an IPv4+MPLS router to respond to an IPv6 traceroute?
> 
> It should place the time-exceeded message into the tunnel just as
> it would do for v4 VPNs and let the egress router take care of deciding
> on the proper path back to the source. Which has the "nice" side effect
> of all hops of the tunnel seeming to be as far away as the egress
> in terms of RTT measurements.

Which isn't overly useful in figuring out *where* a given path breaks...

> Or are you talking about core routers that do not implement IPv6 at all?

As well :)

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
-------------- 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/20081006/c16304b9/attachment.bin 

From jens.rosenboom at freenet.ag  Mon Oct  6 15:39:59 2008
From: jens.rosenboom at freenet.ag (Jens Rosenboom)
Date: Mon, 6 Oct 2008 15:39:59 +0200
Subject: Sprint IPv6
In-Reply-To: <20081002211234.GR28549@Space.Net>
References: <20081002083927.GM28549@Space.Net>
	<D83105B2AC38794CB78ADA2959F2C44F017F4C9C@S4DE9JSAACY.ost.t-com.de>
	<48E48C24.1070709@spaghetti.zurich.ibm.com>
	<20081002091834.GO28549@Space.Net>
	<5036A57C-62E9-4E2F-BA75-D37AF956B7BD@suspicious.org>
	<20081002211234.GR28549@Space.Net>
Message-ID: <20081006133959.GB26220@bo.mcbone.net>

On Thu, Oct 02, 2008 at 11:12:34PM +0200, Gert Doering wrote:
> Hi,
> 
> On Thu, Oct 02, 2008 at 02:16:58PM -0400, Truman Boyes wrote:
> > This issue that you describe is not specific to IPv6, but rather is an  
> > issue with any networks that use MPLS VPNs, and do not propagate TTL.  
> 
> Except that with IPv6 over MPLS, you can't even do TTL-propagation - how
> is an IPv4+MPLS router to respond to an IPv6 traceroute?

It should place the time-exceeded message into the tunnel just as
it would do for v4 VPNs and let the egress router take care of deciding
on the proper path back to the source. Which has the "nice" side effect
of all hops of the tunnel seeming to be as far away as the egress
in terms of RTT measurements.

Or are you talking about core routers that do not implement IPv6 at all?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20081006/fce2835d/attachment.bin 

From gert at space.net  Thu Oct  9 11:37:28 2008
From: gert at space.net (Gert Doering)
Date: Thu, 9 Oct 2008 11:37:28 +0200
Subject: 6to4 relay on IOS <-> CEF switching?
Message-ID: <20081009093728.GA24807@Space.Net>

Hi Folks,

we've just moved our 6to4 relay to a new router (well, it's still an old
router, but a dedicated machine to that purpose).

It's a 3640 with 12.3(22) on it, and "bog standard" 6to4 relay config:

interface Tunnel2002
 description 6to4 relay - RFC 3056 (sp1)
 no ip address
 no ip redirects
 load-interval 30
 ipv6 address 2002:C195:2CD0::1/128
 tunnel source 192.88.99.1
 tunnel mode ipv6ip 6to4
ipv6 route 2002::/16 Tunnel2002

... and it's working well, that is, packets move back and forth and
the latency is good.

What I'm unhappy about is the CPU load - these packets are not CEF switched
("show int switching" etc), and as such, measly 15 Mbit/s create 99% CPU 
load.

There is no fragmentation going on, so it seems to be more a matter of 
"CEF not supporting 6to4 in 12.3".

Before I start upgrading things (adding RAM etc) - what are your experiences
with 6to4 relays on IOS?  Which combination of hardware and software are
you using, and does it properly CEF switch these packets?

So far, I have received comments about 12.2SB, which seems to do CEF
switching on egress but not on ingress (!?), and 12.4 on 2800, which
seems to do both directions.


(Just for the records: we're offering native IPv6 to all our customers, and
we're not announcing the relay to "the world" - so something that can 
do 20-30 mbit/s is perfectly fine for our needs, as in 'the occasional
customer that has never considered IPv6 but 6to4 just happened to his
machine by virtue of a MacOS device nearby')

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 dcp at dcptech.com  Thu Oct  9 15:59:17 2008
From: dcp at dcptech.com (David Prall)
Date: Thu, 9 Oct 2008 09:59:17 -0400
Subject: 6to4 relay on IOS <-> CEF switching?
In-Reply-To: <20081009093728.GA24807@Space.Net>
References: <20081009093728.GA24807@Space.Net>
Message-ID: <012c01c92a17$3a50ad70$aef20850$@com>

Gert,
The feature is called
"IPv6 Switching: CEFv6 Switched Automatic IPv4-compatible Tunnels"

http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-roadmap.htm
l

First release was 12.3(2)T. So 12.3T or 12.4 should work well.

David

--
http://dcp.dcptech.com
 

> -----Original Message-----
> From: ipv6-ops-bounces+dcp=dcptech.com at lists.cluenet.de [mailto:ipv6-
> ops-bounces+dcp=dcptech.com at lists.cluenet.de] On Behalf Of Gert Doering
> Sent: Thursday, October 09, 2008 5:37 AM
> To: ipv6-ops at lists.cluenet.de
> Subject: 6to4 relay on IOS <-> CEF switching?
> 
> Hi Folks,
> 
> we've just moved our 6to4 relay to a new router (well, it's still an
> old
> router, but a dedicated machine to that purpose).
> 
> It's a 3640 with 12.3(22) on it, and "bog standard" 6to4 relay config:
> 
> interface Tunnel2002
>  description 6to4 relay - RFC 3056 (sp1)
>  no ip address
>  no ip redirects
>  load-interval 30
>  ipv6 address 2002:C195:2CD0::1/128
>  tunnel source 192.88.99.1
>  tunnel mode ipv6ip 6to4
> ipv6 route 2002::/16 Tunnel2002
> 
> ... and it's working well, that is, packets move back and forth and
> the latency is good.
> 
> What I'm unhappy about is the CPU load - these packets are not CEF
> switched
> ("show int switching" etc), and as such, measly 15 Mbit/s create 99%
> CPU
> load.
> 
> There is no fragmentation going on, so it seems to be more a matter of
> "CEF not supporting 6to4 in 12.3".
> 
> Before I start upgrading things (adding RAM etc) - what are your
> experiences
> with 6to4 relays on IOS?  Which combination of hardware and software
> are
> you using, and does it properly CEF switch these packets?
> 
> So far, I have received comments about 12.2SB, which seems to do CEF
> switching on egress but not on ingress (!?), and 12.4 on 2800, which
> seems to do both directions.
> 
> 
> (Just for the records: we're offering native IPv6 to all our customers,
> and
> we're not announcing the relay to "the world" - so something that can
> do 20-30 mbit/s is perfectly fine for our needs, as in 'the occasional
> customer that has never considered IPv6 but 6to4 just happened to his
> machine by virtue of a MacOS device nearby')
> 
> 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  Thu Oct  9 16:01:41 2008
From: gert at space.net (Gert Doering)
Date: Thu, 9 Oct 2008 16:01:41 +0200
Subject: 6to4 relay on IOS <-> CEF switching?
In-Reply-To: <012c01c92a17$3a50ad70$aef20850$@com>
References: <20081009093728.GA24807@Space.Net>
	<012c01c92a17$3a50ad70$aef20850$@com>
Message-ID: <20081009140141.GP28549@Space.Net>

Hi,

On Thu, Oct 09, 2008 at 09:59:17AM -0400, David Prall wrote:
> The feature is called
> "IPv6 Switching: CEFv6 Switched Automatic IPv4-compatible Tunnels"
> 
> http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-roadmap.htm
> l
> 
> First release was 12.3(2)T. So 12.3T or 12.4 should work well.

"should" is something I'd rather see verified by someone with first-hand
experience... :-)

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
-------------- 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/20081009/1ce95f60/attachment.bin 

From dwcarder at wisc.edu  Thu Oct  9 16:54:18 2008
From: dwcarder at wisc.edu (Dale W. Carder)
Date: Thu, 09 Oct 2008 09:54:18 -0500
Subject: 6to4 relay on IOS <-> CEF switching?
In-Reply-To: <20081009140141.GP28549@Space.Net>
References: <20081009093728.GA24807@Space.Net>
	<012c01c92a17$3a50ad70$aef20850$@com>
	<20081009140141.GP28549@Space.Net>
Message-ID: <504AD078-5776-4391-A831-21519C97AB85@wisc.edu>

Hey Gert,

On Oct 9, 2008, at 9:01 AM, Gert Doering wrote:
> On Thu, Oct 09, 2008 at 09:59:17AM -0400, David Prall wrote:
>> The feature is called
>> "IPv6 Switching: CEFv6 Switched Automatic IPv4-compatible Tunnels"
>>
>> http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-roadmap.htm
>> l
>>
>> First release was 12.3(2)T. So 12.3T or 12.4 should work well.
>
> "should" is something I'd rather see verified by someone with first- 
> hand
> experience... :-)

We've been running a dedicated 6to4 relay w/ 12.4(19a) on a 7301
for about 4 months.

Dale

From gert at space.net  Thu Oct  9 16:58:10 2008
From: gert at space.net (Gert Doering)
Date: Thu, 9 Oct 2008 16:58:10 +0200
Subject: 6to4 relay on IOS <-> CEF switching?
In-Reply-To: <504AD078-5776-4391-A831-21519C97AB85@wisc.edu>
References: <20081009093728.GA24807@Space.Net>
	<012c01c92a17$3a50ad70$aef20850$@com>
	<20081009140141.GP28549@Space.Net>
	<504AD078-5776-4391-A831-21519C97AB85@wisc.edu>
Message-ID: <20081009145809.GR28549@Space.Net>

Hi,

On Thu, Oct 09, 2008 at 09:54:18AM -0500, Dale W. Carder wrote:
> We've been running a dedicated 6to4 relay w/ 12.4(19a) on a 7301
> for about 4 months.

Out of interest: what traffic levels are you observing?  How much CPU
load?  Does "show int <tunnel> stat" show processor-switched packets,
or is it all properly CEF switched?

thanks,

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
-------------- 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/20081009/4a002843/attachment.bin 

From dwcarder at wisc.edu  Thu Oct  9 17:19:30 2008
From: dwcarder at wisc.edu (Dale W. Carder)
Date: Thu, 09 Oct 2008 10:19:30 -0500
Subject: 6to4 relay on IOS <-> CEF switching?
In-Reply-To: <20081009145809.GR28549@Space.Net>
References: <20081009093728.GA24807@Space.Net>
	<012c01c92a17$3a50ad70$aef20850$@com>
	<20081009140141.GP28549@Space.Net>
	<504AD078-5776-4391-A831-21519C97AB85@wisc.edu>
	<20081009145809.GR28549@Space.Net>
Message-ID: <84DE7C42-26D8-4141-A29C-1EE9757DF294@wisc.edu>


On Oct 9, 2008, at 9:58 AM, Gert Doering wrote:
> On Thu, Oct 09, 2008 at 09:54:18AM -0500, Dale W. Carder wrote:
>> We've been running a dedicated 6to4 relay w/ 12.4(19a) on a 7301
>> for about 4 months.
>
> Out of interest: what traffic levels are you observing?

Abysmally nothing.  Maybe a megabit or two max.

>  How much CPU
> load?  Does "show int <tunnel> stat" show processor-switched packets,
> or is it all properly CEF switched?


Looks like there is some process switching.  If I have things
configured wrong (config attached below), I'd like to get it fixed.


r-cssc-b217-3-lab#show int switching
GigabitEthernet0/0
     Protocol  IP
           Switching path    Pkts In   Chars In   Pkts Out  Chars Out
                  Process   22729767 4711885253    3362173  679592609
             Cache misses        482          -          -          -
                     Fast       1346     124673   10148597 3016175956
                Auton/SSE          0          0          0          0
     Protocol  IPv6
           Switching path    Pkts In   Chars In   Pkts Out  Chars Out
                  Process    1627198  194659225   18693462 3355364255
             Cache misses          0          -          -          -
                     Fast   10169298 2844834384          0          0
                Auton/SSE          0          0          0          0


Loopback0
     Protocol  IP
           Switching path    Pkts In   Chars In   Pkts Out  Chars Out
                  Process          4        400          0          0
             Cache misses          0          -          -          -
                     Fast          0          0          0          0
                Auton/SSE          0          0          0          0

     Protocol  IPv6
           Switching path    Pkts In   Chars In   Pkts Out  Chars Out
                  Process          8        608          8        608
             Cache misses          0          -          -          -
                     Fast          0          0          0          0
                Auton/SSE          0          0          0          0


Tunnel2002 6to4 relay service
     Protocol  IPv6
           Switching path    Pkts In   Chars In   Pkts Out  Chars Out
                  Process   17144451 3283090356      75824    7405613
             Cache misses          0          -          -          -
                     Fast          0          0   10148348 2874053002
                Auton/SSE          0          0          0          0




ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
  ip address 192.88.99.1 255.255.255.255 secondary
  ip address 10.151.163.35 255.255.255.255
  ipv6 address 2607:F388:0:100::7/128
  ipv6 enable
  ipv6 ospf 1 area 0
!
interface Tunnel2002
  description 6to4 relay service
  no ip address
  no ip redirects
  ipv6 address 2002:C058:6301::/128
  tunnel source Loopback0
  tunnel mode ipv6ip 6to4
!
interface GigabitEthernet0/0
  ip address 10.151.177.94 255.255.255.252
  duplex auto
  speed auto
  media-type rj45
  no negotiation auto
  ipv6 address 2607:F388:0:20E::2/64
  ipv6 enable
  ipv6 ospf 1 area 0
!
ip route 192.88.99.0 255.255.255.0 Null0
ipv6 route 2002::/16 Tunnel2002



      
661221111211161161111612116121156111141112631122211221112611111211111111
100
  90
  80
  70
  60
  50
  40
  30
  20
  10 **           *  *    *    *    **         *              *
     
0 
....5....1....1....2....2....3....3....4....4....5....5....6....6....7..
              0    5    0    5    0    5    0    5    0    5    0     
5    0
                    CPU% per hour (last 72 hours)
                   * = maximum CPU%   # = average CPU%




From gert at space.net  Thu Oct  9 17:26:15 2008
From: gert at space.net (Gert Doering)
Date: Thu, 9 Oct 2008 17:26:15 +0200
Subject: 6to4 relay on IOS <-> CEF switching?
In-Reply-To: <84DE7C42-26D8-4141-A29C-1EE9757DF294@wisc.edu>
References: <20081009093728.GA24807@Space.Net>
	<012c01c92a17$3a50ad70$aef20850$@com>
	<20081009140141.GP28549@Space.Net>
	<504AD078-5776-4391-A831-21519C97AB85@wisc.edu>
	<20081009145809.GR28549@Space.Net>
	<84DE7C42-26D8-4141-A29C-1EE9757DF294@wisc.edu>
Message-ID: <20081009152615.GU28549@Space.Net>

Hi,

On Thu, Oct 09, 2008 at 10:19:30AM -0500, Dale W. Carder wrote:
> Tunnel2002 6to4 relay service
>     Protocol  IPv6
>           Switching path    Pkts In   Chars In   Pkts Out  Chars Out
>                  Process   17144451 3283090356      75824    7405613
>             Cache misses          0          -          -          -
>                     Fast          0          0   10148348 2874053002
>                Auton/SSE          0          0          0          0

This is certainly not the way it should look like.

... but I can't tell you whether that's just software buggery, or a
misconfiguration.  

I have seen output from a 2800 that was all nicely CEF switched, with
12.4 mainline, so in theory it should work.

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
-------------- 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/20081009/f2a91640/attachment.bin 

From dwcarder at wisc.edu  Thu Oct  9 17:27:29 2008
From: dwcarder at wisc.edu (Dale W. Carder)
Date: Thu, 09 Oct 2008 10:27:29 -0500
Subject: 6to4 relay on IOS <-> CEF switching?
In-Reply-To: <0K8H00K0H98YA300@smtp5.wiscmail.wisc.edu>
References: <20081009093728.GA24807@Space.Net>
	<012c01c92a17$3a50ad70$aef20850$@com>
	<20081009140141.GP28549@Space.Net>
	<504AD078-5776-4391-A831-21519C97AB85@wisc.edu>
	<20081009145809.GR28549@Space.Net>
	<0K8H00K0H98YA300@smtp5.wiscmail.wisc.edu>
Message-ID: <BECA8D68-115D-4D74-90A2-47EFA29A71F5@wisc.edu>


On Oct 9, 2008, at 10:19 AM, Dale W. Carder wrote:
>
> Looks like there is some process switching.  If I have things
> configured wrong (config attached below), I'd like to get it fixed.

More interesting data:

r-cssc-b217-3-lab#sh cef int tunnel2002
Tunnel2002 is up (if_number 11)
   Corresponding hwidb fast_if_number 11
   Corresponding hwidb firstsw->if_number 11
   Internet Protocol processing disabled
   Interface is marked as tunnel interface
   Packets switched to this interface are punted to the next slow  
path: Unsupported tunnel mode
   Hardware idb is Tunnel2002
   Fast switching type 14, interface type 0
   IP CEF switching disabled
   IP Null turbo vector
   IP Null turbo vector
   Input fast flags 0x0, Input fast flags2 0x0, Output fast flags 0x0,  
Output fast flags2 0x0
   ifindex 9(9)
   Slot -1 Slot unit -1 Unit 2002 VC -1
   Transmit limit accumulator 0x0 (0x0)
   IP MTU 1480


r-cssc-b217-3-lab#sh ipv6 cef summ
IPv6 CEF is enabled and running centrally.
Slow processing intvl = 1 seconds backoff level current/max 0/0
0 unresolved prefixes, 0 requiring adjacency update
IPv6 CEF default table
64 prefixes



From d.bay at cablesurf.de  Thu Oct  9 19:04:14 2008
From: d.bay at cablesurf.de (Dominik Bay)
Date: Thu, 9 Oct 2008 19:04:14 +0200
Subject: 6to4 relay on IOS <-> CEF switching?
In-Reply-To: <20081009152615.GU28549@Space.Net>
References: <20081009093728.GA24807@Space.Net>
	<012c01c92a17$3a50ad70$aef20850$@com>
	<20081009140141.GP28549@Space.Net>
	<504AD078-5776-4391-A831-21519C97AB85@wisc.edu>
	<20081009145809.GR28549@Space.Net>
	<84DE7C42-26D8-4141-A29C-1EE9757DF294@wisc.edu>
	<20081009152615.GU28549@Space.Net>
Message-ID: <4A500B3B-4320-4609-B406-9C41420F5789@cablesurf.de>

Hi,

Am 09.10.2008 um 17:26 schrieb Gert Doering:
>  I have seen output from a 2800 that was all nicely CEF switched, with
> 12.4 mainline, so in theory it should work.

#sh cef int tun2002
Tunnel2002 is up (if_number 18)
   Corresponding hwidb fast_if_number 18
   Corresponding hwidb firstsw->if_number 18
   Internet Protocol processing disabled
   Interface is marked as tunnel interface
   Packets switched to this interface are punted to the next slow  
path: Unsupported tunnel mode
   Hardware idb is Tunnel2002
   Fast switching type 14, interface type 0
   IP CEF switching disabled
   IP Null turbo vector
   Input fast flags 0x0, Input fast flags2 0x0, Output fast flags 0x0,  
Output fast flags2 0x0
   ifindex 15(15)
   Slot -1 Slot unit -1 Unit 2002 VC -1
   Transmit limit accumulator 0x0 (0x0)
   IP MTU 1480

#sh int tun2002 stats
Tunnel2002
           Switching path    Pkts In   Chars In   Pkts Out  Chars Out
                Processor    1318134 1128731936     504142   76165243
           Route cache  299007180 3735509587   68376334 3207098151
                Total  300325314 4864241523   68880476 3283263394

#sh ipv6 cef sum
IPv6 CEF is enabled and running centrally.
Slow processing intvl = 1 seconds backoff level current/max 0/0
0 unresolved prefixes, 0 requiring adjacency update
IPv6 CEF default table
36 prefixes


#sh ver
Cisco IOS Software, 2801 Software (C2801-ADVENTERPRISEK9-M), Version  
12.4(19a), RELEASE SOFTWARE (fc1)
[...]
System image file is "flash:c2801-adventerprisek9-mz.124-19a.bin"

This Box is also doing ISATAP and Static v6 Tunnels without  
Performance Issues.
(I've to test again, but I'm rather sure that I've seen 80Mbps with  
full MTU Packets on this Box)


Regards,
Dominik

From cfriacas at fccn.pt  Mon Oct 13 13:25:07 2008
From: cfriacas at fccn.pt (Carlos Friacas)
Date: Mon, 13 Oct 2008 12:25:07 +0100 (WEST)
Subject: 6to4 relay on IOS <-> CEF switching?
In-Reply-To: <20081009145809.GR28549@Space.Net>
References: <20081009093728.GA24807@Space.Net>
	<012c01c92a17$3a50ad70$aef20850$@com>
	<20081009140141.GP28549@Space.Net>
	<504AD078-5776-4391-A831-21519C97AB85@wisc.edu>
	<20081009145809.GR28549@Space.Net>
Message-ID: <Pine.LNX.4.64.0810131221020.5371@gauntlet.fccn.pt>

On Thu, 9 Oct 2008, Gert Doering wrote:

> Hi,
>
> On Thu, Oct 09, 2008 at 09:54:18AM -0500, Dale W. Carder wrote:
>> We've been running a dedicated 6to4 relay w/ 12.4(19a) on a 7301
>> for about 4 months.

7206 NPE-G1 here, running other stuff as well.


> Out of interest: what traffic levels are you observing?

Not more than 3Mbps.


> How much CPU
> load?

Around 30%, but it's not dedicated to 6to4...


> Does "show int <tunnel> stat" show processor-switched packets,
> or is it all properly CEF switched?

Tunnel101
              Switch path    Pkts In   Chars In   Pkts Out  Chars Out
                Processor          0          0  511222955 1510818065
              Route cache          0          0          0          0
                    Total          0          0  511222955 1510818065

Tunnel102
              Switch path    Pkts In   Chars In   Pkts Out  Chars Out
                Processor  650025329 1413610886      10738     919270
              Route cache          0 1557092020          0          0
                    Total  650025329 2970702906      10738     919270




> thanks,
>
> 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
>


-------------------------------------------------------------------------
Carlos Friac,as                                           See:
Wide Area Network Working Group (WAN)                     www.gigapix.pt
FCCN - Fundacao para a Computacao Cientifica Nacional     www.6deploy.org
Av. do Brasil, n.101                                      www.ipv6.eu
1700-066 Lisboa, Portugal, Europe
Tel: +351 218440100 Fax: +351 218472167                   www.fccn.pt
-------------------------------------------------------------------------
           The end is near........ see http://ipv4.potaroo.net
"Internet is just routes (282391/1511), naming (billions) and... people!"

    Esta mensagem foi enviada de: / This message was sent from:
 		 2001:690:2080:8004:250:daff:fe3b:2830

Aviso de Confidencialidade
Esta mensagem e' exclusivamente destinada ao seu destinatario, podendo
conter informacao CONFIDENCIAL, cuja divulgacao esta' expressamente
vedada nos termos da lei. Caso tenha recepcionado indevidamente esta
mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta
via ou para o telefone +351 218440100 devendo apagar o seu conteudo
de imediato.

Warning
This message is intended exclusively for its addressee.
It may contain CONFIDENTIAL information protected by law. If this
message has been received due to any error, please notify us via
e-mail or by telephone +351 218440100 and delete it immediately.

From jabley at hopcount.ca  Thu Oct 23 15:12:51 2008
From: jabley at hopcount.ca (Joe Abley)
Date: Thu, 23 Oct 2008 09:12:51 -0400
Subject: RADIUS/IPv6CP bits and pieces for IPv6 subscriber access
Message-ID: <FD8724B2-1EAF-4A4D-9D7A-2B70BF759992@hopcount.ca>

Hey,

Does anybody have any examples of how they are handing out v6  
addresses to customers using PPPoE?

I'm working on some config, but I'm not sure of the appropriate  
conventions. For example, should I be handing out a host address for  
the customer router as a /128, along with a customer-side /48 (or /64  
or whatever; I figured we'd just give everybody static /48s for now)  
which should be routed towards the /128, or something different?

In case it helps to know, this is using JUNOSe 8.2 on ERX310s for LNS,  
subscribers see PPPoE, we see L2TP on the LNS, the mysterious cloud in  
the middle is run by Bell Canada (who use ERXes to switch the  
tunnels). The subscriber equipment I'm playing with right now is a  
cisco 2600 with DSL WICs running 12.3(23).


Joe

From nick-lists at netability.ie  Thu Oct 23 15:29:52 2008
From: nick-lists at netability.ie (Nick Hilliard)
Date: Thu, 23 Oct 2008 14:29:52 +0100
Subject: RADIUS/IPv6CP bits and pieces for IPv6 subscriber access
In-Reply-To: <FD8724B2-1EAF-4A4D-9D7A-2B70BF759992@hopcount.ca>
References: <FD8724B2-1EAF-4A4D-9D7A-2B70BF759992@hopcount.ca>
Message-ID: <49007C50.2000303@netability.ie>

Joe Abley wrote:
> Does anybody have any examples of how they are handing out v6 addresses
> to customers using PPPoE?
> 
> I'm working on some config, but I'm not sure of the appropriate
> conventions. For example, should I be handing out a host address for the
> customer router as a /128, along with a customer-side /48 (or /64 or
> whatever; I figured we'd just give everybody static /48s for now) which
> should be routed towards the /128, or something different?
> 
> In case it helps to know, this is using JUNOSe 8.2 on ERX310s for LNS,
> subscribers see PPPoE, we see L2TP on the LNS, the mysterious cloud in
> the middle is run by Bell Canada (who use ERXes to switch the tunnels).
> The subscriber equipment I'm playing with right now is a cisco 2600 with
> DSL WICs running 12.3(23).

For SMEs and upwards, the approach of handing out /48 (or more likely /56
once we finally come to terms with the fact that most SMEs won't really
require 65536 ipv6 networks) seems to be a relatively good one.  Also,
there appears to me to be no good reason not to use /128 for single host
access or /126 for link addresses.  Static configuration at the customer
side is probably appropriate.

The difficulty is in dealing with small business and home users, most of
whom will have no requirement for anything other than a single /64 + /128
for the gateway.  For this, RA is not going to suffice, and realistically,
you're going to need to implement dhcpv6 + rfc 3633 prefix delegation.  Of
course, you're also going to need a CPE device which supports this.  For
that, I leave you to browse the results of these links.

http://www.google.com/search?q=ipv6+site:www.netgear.com+-docsis
http://www.google.com/search?q=ipv6+site:www.belkin.com
http://www.google.com/search?q=ipv6+site:www.linksys.com
http://www.google.com/search?q=ipv6+site:www.zyxel.com

... etc, etc, etc.

Nick


From martin at airwire.ie  Thu Oct 23 15:50:23 2008
From: martin at airwire.ie (Martin List-Petersen)
Date: Thu, 23 Oct 2008 14:50:23 +0100
Subject: RADIUS/IPv6CP bits and pieces for IPv6 subscriber access
In-Reply-To: <FD8724B2-1EAF-4A4D-9D7A-2B70BF759992@hopcount.ca>
References: <FD8724B2-1EAF-4A4D-9D7A-2B70BF759992@hopcount.ca>
Message-ID: <4900811F.5070407@airwire.ie>

Joe Abley wrote:
> Hey,
>
> Does anybody have any examples of how they are handing out v6 
> addresses to customers using PPPoE?
>
> I'm working on some config, but I'm not sure of the appropriate 
> conventions. For example, should I be handing out a host address for 
> the customer router as a /128, along with a customer-side /48 (or /64 
> or whatever; I figured we'd just give everybody static /48s for now) 
> which should be routed towards the /128, or something different?
>
> In case it helps to know, this is using JUNOSe 8.2 on ERX310s for LNS, 
> subscribers see PPPoE, we see L2TP on the LNS, the mysterious cloud in 
> the middle is run by Bell Canada (who use ERXes to switch the 
> tunnels). The subscriber equipment I'm playing with right now is a 
> cisco 2600 with DSL WICs running 12.3(23).

Be aware, that some router and cpe equipment can't handle less than /64 
subnets. I've seen approaches where the /48, /56, /64 has been assigned 
using link-local instead. Not sure, if that'll work over PPPoE, as we 
don't use it in our setup.

Kind regards,
Martin List-Petersen

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


From jens.rosenboom at freenet.ag  Fri Oct 24 11:22:07 2008
From: jens.rosenboom at freenet.ag (Jens Rosenboom)
Date: Fri, 24 Oct 2008 11:22:07 +0200
Subject: RADIUS/IPv6CP bits and pieces for IPv6 subscriber access
In-Reply-To: <FD8724B2-1EAF-4A4D-9D7A-2B70BF759992@hopcount.ca>
References: <FD8724B2-1EAF-4A4D-9D7A-2B70BF759992@hopcount.ca>
Message-ID: <20081024092207.GH5388@bo.mcbone.net>

On Thu, Oct 23, 2008 at 09:12:51AM -0400, Joe Abley wrote:
> Hey,
> 
> Does anybody have any examples of how they are handing out v6  
> addresses to customers using PPPoE?
> 
> I'm working on some config, but I'm not sure of the appropriate  
> conventions. For example, should I be handing out a host address for  
> the customer router as a /128, along with a customer-side /48 (or /64  
> or whatever; I figured we'd just give everybody static /48s for now)  
> which should be routed towards the /128, or something different?
> 
> In case it helps to know, this is using JUNOSe 8.2 on ERX310s for LNS,  
> subscribers see PPPoE, we see L2TP on the LNS, the mysterious cloud in  
> the middle is run by Bell Canada (who use ERXes to switch the  
> tunnels). The subscriber equipment I'm playing with right now is a  
> cisco 2600 with DSL WICs running 12.3(23).

Our current lab setup uses a Cisco 876 running 12.4(6)T10, we do
dhcpv6 local server on the ERX getting the prefix to be assigned
via Radius. The CPE fetches this prefix and announces it on the
local client LAN, seems to work pretty well except that 
autoconfig of the outside CPE address is broken.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20081024/72147360/attachment.bin 

From nick-lists at netability.ie  Fri Oct 24 17:52:37 2008
From: nick-lists at netability.ie (Nick Hilliard)
Date: Fri, 24 Oct 2008 16:52:37 +0100
Subject: RADIUS/IPv6CP bits and pieces for IPv6 subscriber access
In-Reply-To: <49007C50.2000303@netability.ie>
References: <FD8724B2-1EAF-4A4D-9D7A-2B70BF759992@hopcount.ca>
	<49007C50.2000303@netability.ie>
Message-ID: <4901EF45.6030706@netability.ie>

Nick Hilliard wrote:
> The difficulty is in dealing with small business and home users, most of
> whom will have no requirement for anything other than a single /64 + /128
> for the gateway.  For this, RA is not going to suffice, and realistically,
> you're going to need to implement dhcpv6 + rfc 3633 prefix delegation.

The recommendation in RFC5072 in Appendix A for customer LAN side
autoconfiguration is to use either RA + Prefix Information option, or else
dhcpv6.  Messy.

Previous note still applies:

> Of
> course, you're also going to need a CPE device which supports this.

Nick

From dr at cluenet.de  Fri Oct 24 18:59:00 2008
From: dr at cluenet.de (Daniel Roesen)
Date: Fri, 24 Oct 2008 18:59:00 +0200
Subject: RADIUS/IPv6CP bits and pieces for IPv6 subscriber access
In-Reply-To: <20081024092207.GH5388@bo.mcbone.net>
References: <FD8724B2-1EAF-4A4D-9D7A-2B70BF759992@hopcount.ca>
	<20081024092207.GH5388@bo.mcbone.net>
Message-ID: <20081024165900.GA30213@srv03.cluenet.de>

On Fri, Oct 24, 2008 at 11:22:07AM +0200, Jens Rosenboom wrote:
> Our current lab setup uses a Cisco 876 running 12.4(6)T10, we do
> dhcpv6 local server on the ERX getting the prefix to be assigned
> via Radius. The CPE fetches this prefix and announces it on the
> local client LAN, seems to work pretty well except that 
> autoconfig of the outside CPE address is broken.

Fancy to post some config examples for ERX and IOS?

Best regards,
Daniel

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

From LLE at dk.ibm.com  Sat Oct 25 12:04:56 2008
From: LLE at dk.ibm.com (Lasse Leegaard)
Date: Sat, 25 Oct 2008 12:04:56 +0200
Subject: AUTO: Lasse Leegaard is out of the office. (returning 04-11-2008)
Message-ID: <OFB802A38A.62E8383C-ONC12574ED.00376247-C12574ED.00376247@dk.ibm.com>


I am out of the office until 04-11-2008.

Messages received in this period will not be acted upon - please resend
after I return if you want my attention

For changes, incidents and problems contact SDDK infrastructure
(dm129core at dk.ibm.com) or Kim Lundsteen (kim5 at dk.ibm.com)
For management escalations contact Michael Claus Hansen
(hansenmi at dk.ibm.com)


Note: This is an automated response to your message  "ipv6-ops Digest, Vol
43, Issue 10" sent on 25/10/08 12:00:01.

This is the only notification you will receive while this person is away.


From berni at birkenwald.de  Sun Oct 26 14:17:53 2008
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Sun, 26 Oct 2008 14:17:53 +0100
Subject: Some leaks in China/Hongkong
Message-ID: <20081026131752.GA7741@pest>

Hello everyone,

I had a very unpleasant experience when I looked at my RTT monitoring
this morning.

a) 

bschmidt at lxbsc01:~$ traceroute6 -q1 2001:470:0:69::2
traceroute to 2001:470:0:69::2 (2001:470:0:69::2) from 2001:4ca0:0:f000:211:43ff:fe7e:3a76, port 33434, from port 36641, 30 hops max, 60 bytepackets
 1  vl-23.csr1-2wr.lrz-muenchen.de (2001:4ca0:0:f000::1)  0.374 ms
 2  xr-gar1-te1-3-108.x-win.dfn.de (2001:638:c:a003::1)  0.441 ms
 3  2001:638:c:c043::2 (2001:638:c:c043::2)  8.484 ms
 4  dfn.rt1.fra.de.geant2.net (2001:798:14:10aa::1)  7.879 ms
 5  abilene-wash-gw.rt1.fra.de.geant2.net (2001:798:14:10aa::12)  100.643 ms
 6  so-0-2-0.0.rtr.chic.net.internet2.edu (2001:468:ff:209::2)  117.230 ms
 7  so-4-3-0.rtr.kans.net.internet2.edu (2001:468:ff:204:8000::2)  127.967 ms
 8  so-0-0-0.0.rtr.salt.net.internet2.edu (2001:468:ff:407::2)  181.439 ms
 9  so-0-0-0.0.rtr.seat.net.internet2.edu (2001:468:ff:716::1)  181.476 ms
10  kreonet-1-lo-jmb-706.sttlwa.pacificwave.net (2001:504:b:10::6)  169.102 ms
11  2001:320:1b00:1::1 (2001:320:1b00:1::1)  283.341 ms
12  hurricaneelectric-RGE.hkix.net (2001:7fa:0:1::ca28:a19e)  327.876 ms
13  v1026.core1.sjc1.he.net (2001:470:0:c3::1)  331.108 ms
14  10gigabitethernet2-1.core1.sjc2.he.net (2001:470:0:55::2)  327.817 ms
15  10gigabitethernet1-3.core1.nyc4.he.net (2001:470:0:33::2)  327.861 ms
16  10gigabitethernet1-2.core1.lon1.he.net (2001:470:0:3e::2)  327.785 ms
17  10gigabitethernet1-1.core1.ams1.he.net (2001:470:0:3f::2)  327.827 ms
18  10gigabitethernet1-1.core1.fra1.he.net (2001:470:0:47::2)  327.742 ms
19  1g-bge0.tserv6.fra1.ipv6.he.net (2001:470:0:69::2)  328.126 ms

  680 20965 11537 17579 4635 6939
    2001:638:C:A003::1 from 2001:638:C:A003::1 (188.1.200.38)
      Origin IGP, localpref 90, valid, external, best
      Community: 680:77 11537:2501 12816:2100 12816:2110 20965:11537

This, apparently new or newly leaking, peering between AS4635 and AS6939
affects about 200 prefixes that are detoured through Hongkong for all
users behind 20965 (the european REN, comparable to I2) or 11537 (I2).
So, I guess, a not-too-small two-digit slice of the current IPv6 users.

b)

bschmidt at lxbsc01:~$ traceroute6 -q1 ipv6.google.com
traceroute to ipv6.google.com (2001:4860:0:1001::68) from 2001:4ca0:0:f000:211:43ff:fe7e:3a76, port 33434, from port 34321, 30 hops max, 60 byte packets
 1  vl-23.csr1-2wr.lrz-muenchen.de (2001:4ca0:0:f000::1)  0.384 ms
 2  xr-gar1-te1-3-108.x-win.dfn.de (2001:638:c:a003::1)  0.482 ms
 3  2001:638:c:c043::2 (2001:638:c:c043::2)  8.283 ms
 4  dfn.rt1.fra.de.geant2.net (2001:798:14:10aa::1)  7.876 ms
 5  abilene-wash-gw.rt1.fra.de.geant2.net (2001:798:14:10aa::12)  100.596 ms
 6  so-0-2-0.0.rtr.chic.net.internet2.edu (2001:468:ff:209::2)  117.203 ms
 7  so-4-3-0.rtr.kans.net.internet2.edu (2001:468:ff:204:8000::2)  127.765 ms
 8  so-0-0-0.0.rtr.salt.net.internet2.edu (2001:468:ff:407::2)  181.408 ms
 9  so-0-0-0.0.rtr.seat.net.internet2.edu (2001:468:ff:716::1)  181.495 ms
10  kreonet-1-lo-jmb-706.sttlwa.pacificwave.net (2001:504:b:10::6)  169.117 ms
11  2001:320:1b00:1::1 (2001:320:1b00:1::1)  283.376 ms
12  2001:320:8300:30::11 (2001:320:8300:30::11)  274.199 ms
13  2001:252:0:101::2 (2001:252:0:101::2)  300.406 ms
14  *
15  *
16  2001:4860:0:1001::68 (2001:4860:0:1001::68)  348.676 ms

  680 20965 11537 17579 23911 15169, (aggregated by 15169 64.233.175.244)
    2001:638:C:A003::1 from 2001:638:C:A003::1 (188.1.200.38)
      Origin IGP, localpref 90, valid, external, best
      Community: 680:77 11537:2501 12816:2100 12816:2110 20965:11537

again, affects all users in GEANT2 and I2. 

AS4635 has a very bad reputation regarding leaking fulltables where they
don't belong, AS17579 has not been a saint either. Additionally, these
problems are very much amplified by the current policy of most RENs to
prefer (through localpref) their fellow RENs and tag their prefixes
accordingly. As soon as someone does this on an unfiltered link, as
Abilene does for Kreonet, it creates havoc.

In this case, 680 has direct peering with both 6939 and 15169, so I
would not have seen anything without these localpref games. And both
GEANT2 and I2 should see 6939 and 15169 through at most one transit ASN.

No wonder people are reluctant to use IPv6 for serious production use if
we can't fix those problems for good. Thankfully I could fix it for our
users by depreffing those paths and switching to our commercial (backup)
transit, but that's far from optimal.

Regards,
Bernhard

From mleber at he.net  Sun Oct 26 16:59:38 2008
From: mleber at he.net (Mike Leber)
Date: Sun, 26 Oct 2008 08:59:38 -0700
Subject: Some leaks in China/Hongkong
In-Reply-To: <20081026131752.GA7741@pest>
References: <20081026131752.GA7741@pest>
Message-ID: <490493EA.4050009@he.net>


Several of the parties in the path you list are intentionally preferring 
to send traffic to Hong Kong and perhaps being publicly shamed is the 
only way to get them to change it.

We are not "leaking full tables" in Hong Kong.  We went live in Hong 
Kong a few weeks ago and have a few IPv6 customers in Hong Kong, 
including some Chinese research and education networks.

The fact that none of the parties involved bothers to have the necessary 
transit route to reach that customer prefix in Europe and instead 
prefers to use a Chinese university network as their transit of last 
resort, is something to ask them not us.

dfn, geant2, or internet2 don't currently get a decent full view 
otherwise they wouldn't send traffic to Hong Kong.

Anybody that actually cares about decent routing can fix this in Europe 
by either peering with us in Europe, taking IPv6 transit from us 
directly in Europe, *or* by turning off their transit provider that has 
to use a Chinese University as their upstream transit provider for their 
European network.  There are a bunch of other decent European IPv6 
transit networks that would be happy to sell you service!

For your convenience if you'd like to peer directly, meet us at any of 
the following exchanges:

We are AS6939.

NAP             Status  Speed   IPv4            IPv6
--------------- ------- ------- --------------- ------------------------
EQUINIX-ASH     UP      10GigE  206.223.115.37  2001:504:0:2::6939:1
EQUINIX-CHI     UP      10GigE  206.223.119.37  2001:504:0:4::6939:1
EQUINIX-DAL     UP      10GigE  206.223.118.37  2001:504:0:5::6939:1
EQUINIX-LAX     UP      10GigE  206.223.123.37  2001:504:0:3::6939:1
EQUINIX-SJC     UP      10GigE  206.223.116.37  2001:504:0:1::6939:1
LINX            UP      10GigE  195.66.224.21   2001:7f8:4:0::1b1b:1
LoNAP           UP      GigE    193.203.5.128   2001:7f8:17::1b1b:1
AMS-IX          UP      10GigE  195.69.145.150  2001:7f8:1::a500:6939:1
NL-IX           UP      GigE    193.239.116.14  2001:7f8:13::a500:6939:1
PAIX Palo Alto  UP      10GigE  198.32.176.20   2001:504:d::10
PAIX New York   UP      10GigE  198.32.118.57   2001:504:f::39
NYIIX           UP      10GigE  198.32.160.61   2001:504:1::a500:6939:1
LAIIX           UP      GigE    198.32.146.50   2001:504:a::a500:6939:1
NYCX            UP      GigE    198.32.229.22
BIGEAPE         UP      100BT                   2001:458:26:2::500
SIX             UP      10GigE  198.32.180.40   2001:478:180::40
PaNAP           UP      10GigE  62.35.254.111   2001:860:0:6::6939:1
DE-CIX          UP      10GigE  80.81.192.172   2001:7f8::1b1b:0:1
NOTA            UP      10GigE  198.32.124.176  2001:478:124::176
Any2-LAX        UP      10GigE  206.223.143.122 2001:504:13:0:0:0:0:1A
HKIX            UP      GigE    202.40.161.158  2001:7fa:0:1::ca28:a19e
Telx-Atlanta    UP      10GigE  198.32.132.75   2001:478:132::75

Mike.

Bernhard Schmidt wrote:
> Hello everyone,
> 
> I had a very unpleasant experience when I looked at my RTT monitoring
> this morning.
> 
> a) 
> 
> bschmidt at lxbsc01:~$ traceroute6 -q1 2001:470:0:69::2
> traceroute to 2001:470:0:69::2 (2001:470:0:69::2) from 2001:4ca0:0:f000:211:43ff:fe7e:3a76, port 33434, from port 36641, 30 hops max, 60 bytepackets
>  1  vl-23.csr1-2wr.lrz-muenchen.de (2001:4ca0:0:f000::1)  0.374 ms
>  2  xr-gar1-te1-3-108.x-win.dfn.de (2001:638:c:a003::1)  0.441 ms
>  3  2001:638:c:c043::2 (2001:638:c:c043::2)  8.484 ms
>  4  dfn.rt1.fra.de.geant2.net (2001:798:14:10aa::1)  7.879 ms
>  5  abilene-wash-gw.rt1.fra.de.geant2.net (2001:798:14:10aa::12)  100.643 ms
>  6  so-0-2-0.0.rtr.chic.net.internet2.edu (2001:468:ff:209::2)  117.230 ms
>  7  so-4-3-0.rtr.kans.net.internet2.edu (2001:468:ff:204:8000::2)  127.967 ms
>  8  so-0-0-0.0.rtr.salt.net.internet2.edu (2001:468:ff:407::2)  181.439 ms
>  9  so-0-0-0.0.rtr.seat.net.internet2.edu (2001:468:ff:716::1)  181.476 ms
> 10  kreonet-1-lo-jmb-706.sttlwa.pacificwave.net (2001:504:b:10::6)  169.102 ms
> 11  2001:320:1b00:1::1 (2001:320:1b00:1::1)  283.341 ms
> 12  hurricaneelectric-RGE.hkix.net (2001:7fa:0:1::ca28:a19e)  327.876 ms
> 13  v1026.core1.sjc1.he.net (2001:470:0:c3::1)  331.108 ms
> 14  10gigabitethernet2-1.core1.sjc2.he.net (2001:470:0:55::2)  327.817 ms
> 15  10gigabitethernet1-3.core1.nyc4.he.net (2001:470:0:33::2)  327.861 ms
> 16  10gigabitethernet1-2.core1.lon1.he.net (2001:470:0:3e::2)  327.785 ms
> 17  10gigabitethernet1-1.core1.ams1.he.net (2001:470:0:3f::2)  327.827 ms
> 18  10gigabitethernet1-1.core1.fra1.he.net (2001:470:0:47::2)  327.742 ms
> 19  1g-bge0.tserv6.fra1.ipv6.he.net (2001:470:0:69::2)  328.126 ms
> 
>   680 20965 11537 17579 4635 6939
>     2001:638:C:A003::1 from 2001:638:C:A003::1 (188.1.200.38)
>       Origin IGP, localpref 90, valid, external, best
>       Community: 680:77 11537:2501 12816:2100 12816:2110 20965:11537
> 
> This, apparently new or newly leaking, peering between AS4635 and AS6939
> affects about 200 prefixes that are detoured through Hongkong for all
> users behind 20965 (the european REN, comparable to I2) or 11537 (I2).
> So, I guess, a not-too-small two-digit slice of the current IPv6 users.
> 
> b)
> 
> bschmidt at lxbsc01:~$ traceroute6 -q1 ipv6.google.com
> traceroute to ipv6.google.com (2001:4860:0:1001::68) from 2001:4ca0:0:f000:211:43ff:fe7e:3a76, port 33434, from port 34321, 30 hops max, 60 byte packets
>  1  vl-23.csr1-2wr.lrz-muenchen.de (2001:4ca0:0:f000::1)  0.384 ms
>  2  xr-gar1-te1-3-108.x-win.dfn.de (2001:638:c:a003::1)  0.482 ms
>  3  2001:638:c:c043::2 (2001:638:c:c043::2)  8.283 ms
>  4  dfn.rt1.fra.de.geant2.net (2001:798:14:10aa::1)  7.876 ms
>  5  abilene-wash-gw.rt1.fra.de.geant2.net (2001:798:14:10aa::12)  100.596 ms
>  6  so-0-2-0.0.rtr.chic.net.internet2.edu (2001:468:ff:209::2)  117.203 ms
>  7  so-4-3-0.rtr.kans.net.internet2.edu (2001:468:ff:204:8000::2)  127.765 ms
>  8  so-0-0-0.0.rtr.salt.net.internet2.edu (2001:468:ff:407::2)  181.408 ms
>  9  so-0-0-0.0.rtr.seat.net.internet2.edu (2001:468:ff:716::1)  181.495 ms
> 10  kreonet-1-lo-jmb-706.sttlwa.pacificwave.net (2001:504:b:10::6)  169.117 ms
> 11  2001:320:1b00:1::1 (2001:320:1b00:1::1)  283.376 ms
> 12  2001:320:8300:30::11 (2001:320:8300:30::11)  274.199 ms
> 13  2001:252:0:101::2 (2001:252:0:101::2)  300.406 ms
> 14  *
> 15  *
> 16  2001:4860:0:1001::68 (2001:4860:0:1001::68)  348.676 ms
> 
>   680 20965 11537 17579 23911 15169, (aggregated by 15169 64.233.175.244)
>     2001:638:C:A003::1 from 2001:638:C:A003::1 (188.1.200.38)
>       Origin IGP, localpref 90, valid, external, best
>       Community: 680:77 11537:2501 12816:2100 12816:2110 20965:11537
> 
> again, affects all users in GEANT2 and I2. 
> 
> AS4635 has a very bad reputation regarding leaking fulltables where they
> don't belong, AS17579 has not been a saint either. Additionally, these
> problems are very much amplified by the current policy of most RENs to
> prefer (through localpref) their fellow RENs and tag their prefixes
> accordingly. As soon as someone does this on an unfiltered link, as
> Abilene does for Kreonet, it creates havoc.
> 
> In this case, 680 has direct peering with both 6939 and 15169, so I
> would not have seen anything without these localpref games. And both
> GEANT2 and I2 should see 6939 and 15169 through at most one transit ASN.
> 
> No wonder people are reluctant to use IPv6 for serious production use if
> we can't fix those problems for good. Thankfully I could fix it for our
> users by depreffing those paths and switching to our commercial (backup)
> transit, but that's far from optimal.
> 
> Regards,
> Bernhard

-- 
+---------------- 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 he at nordu.net  Sun Oct 26 17:28:29 2008
From: he at nordu.net (Havard Eidnes)
Date: Sun, 26 Oct 2008 17:28:29 +0100 (CET)
Subject: Some leaks in China/Hongkong
In-Reply-To: <490493EA.4050009@he.net>
References: <20081026131752.GA7741@pest>
	<490493EA.4050009@he.net>
Message-ID: <20081026.172829.11589080.he@uninett.no>

Hi,

I think you are misunderstanding or overlooking a passage in
Bernhard's message:

> Additionally, these problems are very much amplified by the
> current policy of most RENs to prefer (through localpref) their
> fellow RENs and tag their prefixes accordingly. As soon as
> someone does this on an unfiltered link, as Abilene does for
> Kreonet, it creates havoc.

As is the case for NORDUnet as well.  We see the route via a
shorter AS path since we peer with HE.net, but due to local-pref
for routes we receive from our R&E network providers, we
currently prefer the long path around:

he at dk-ore-re1> show route 2001:470:0:69::2                                  

inet6.0: 1431 destinations, 4445 routes (1429 active, 0 holddown, 634 hidden)
+ = Active Route, - = Last Active, * = Both

2001:470::/32      *[BGP/170] 1d 12:01:46, localpref 110
                      AS path: 20965 11537 17579 4635 6939 I
                    > to 2001:798:15:10aa::1 via so-0/1/0.0
                    [BGP/170] 1w2d 13:55:47, MED 1, localpref 100
                      AS path: 6939 I
                    > to 2001:7f8:1::a500:6939:1 via ge-0/2/0.501
                    [BGP/170] 4w2d 15:29:58, MED 2583, localpref 100
                      AS path: 3549 6939 ?
                    > to 2001:450:2002:c::1 via ge-2/2/0.0

he at dk-ore-re1> 

It also doesn't help that the BGP community marking we receive
from G?ANT and Internet2 gives precious little clue to discern
the route from "proper" R&E routes: we get 11537:2501 which says
"transit to international network" (not a useful distinction in
our view, we might want to use G?ANT and Internet2 to go to the
Korean R&E network) and 20965:11537 which says "we got this route
from Internet2" (an even less useful distinction).

OK, so one might argue that using local-pref is a stupid idea
anyway, but unfortunately it's a tool we need to use in order to
in some important cases prefer the appropriate path.

So, "sigh", I get to tweak our inbound routing policy for import
of G?ANT routes into NORDUnet once again (now done).

Regards,

- H?vard

From ipv6-ops at c0mplx.org  Sun Oct 26 21:57:03 2008
From: ipv6-ops at c0mplx.org (Kurt Jaeger)
Date: Sun, 26 Oct 2008 21:57:03 +0100
Subject: RADIUS/IPv6CP bits and pieces for IPv6 subscriber access
In-Reply-To: <FD8724B2-1EAF-4A4D-9D7A-2B70BF759992@hopcount.ca>
References: <FD8724B2-1EAF-4A4D-9D7A-2B70BF759992@hopcount.ca>
Message-ID: <20081026205703.GU2820@home.opsec.eu>

Hi!

> Does anybody have any examples of how they are handing out v6  
> addresses to customers using PPPoE?

Not yet in production, but that's what I plan to do:

One /128 to the CPE, and some prefix(es) (/64, /48) in addition to that.

If there's a way that the CPE learns the prefix(es) we assign to it
and does some clever things with them, I want to learn more 8-}

Are there known CPE which barf on receiving IPv6CP ?

How do you handle all the "corner" cases ?

- One PPPoE session with both v4 and v6
- One PPPoE session with only v4
- One PPPoE session with only v6

Are you using different vpdn groups for it ?

-- 
pi at opsec.eu            +49 171 3101372                        12 years to go !

From gert at space.net  Mon Oct 27 06:05:56 2008
From: gert at space.net (Gert Doering)
Date: Mon, 27 Oct 2008 06:05:56 +0100
Subject: Some leaks in China/Hongkong
In-Reply-To: <20081026.172829.11589080.he@uninett.no>
References: <20081026131752.GA7741@pest> <490493EA.4050009@he.net>
	<20081026.172829.11589080.he@uninett.no>
Message-ID: <20081027050555.GN21072@Space.Net>

Hi,

On Sun, Oct 26, 2008 at 05:28:29PM +0100, Havard Eidnes wrote:
> OK, so one might argue that using local-pref is a stupid idea
> anyway, 

I would certainly argue that way.  Unconditionally preferring things
"just because they come in via a peering point / NREN / ..." is always
going to end up with funny paths.

> but unfortunately it's a tool we need to use in order to
> in some important cases prefer the appropriate path.

Why not prefer the appropriate path *specifically* for those "important
cases"?  This is something where the local-pref tool is very useful - but
generalizing on "certain classes of BGP neighbours are superiour" has
bitten us in the past as well, so we've learned from it and stopped doing 
so.

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  Mon Oct 27 06:17:54 2008
From: gert at space.net (Gert Doering)
Date: Mon, 27 Oct 2008 06:17:54 +0100
Subject: Some leaks in China/Hongkong
In-Reply-To: <490493EA.4050009@he.net>
References: <20081026131752.GA7741@pest> <490493EA.4050009@he.net>
Message-ID: <20081027051754.GO21072@Space.Net>

Hi,

On Sun, Oct 26, 2008 at 08:59:38AM -0700, Mike Leber wrote:
> dfn, geant2, or internet2 don't currently get a decent full view 
> otherwise they wouldn't send traffic to Hong Kong.

It's much worse.  At least DFN *has* a full view, but they prefer Geant2
routes, because "NREN stuff needs to go there".

And since I2 seems to be really unwilling to properly sort out their 
routing (properly distinguish between "customers", "peers", and "upstream/
transit", with the proper filters in place to avoid leaking everything
everywhere) this is causing harm again and again.


I have some more of these... Egyptian REN more specifics being leaked by 
I2 all over the place...

grh.sixxs.net> show bgp ipv6 2001:4300:2001::/48
BGP routing table entry for 2001:4300:2001::/48
Paths: (14 available, best #3, table Default-IP-Routing-Table)
  Not advertised to any peer
  13645 19151 9304 4635 17579 11537 33789 24863
    2001:5b8:fffe:: from 2001:5b8:fffe:: (64.135.0.0)
      Origin IGP, localpref 100, valid, external
      Community: 13645:3121
      Last update: Sun Oct 26 10:33:10 2008

  20932 30781 5511 10764 11537 33789 24863
    2001:41e0:0:f::1 from 2001:41e0:0:f::1 (217.169.143.20)
      Origin IGP, metric 0, localpref 100, valid, external
      Last update: Fri Oct 24 21:43:41 2008

...

(19 /48s in total, only visible via 11537)

The really bad thing about that is that the /32 in question seems to have
direct transit via Sprint, which is not used now, since "longest prefix
wins"...

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 jens.rosenboom at freenet.ag  Mon Oct 27 14:54:18 2008
From: jens.rosenboom at freenet.ag (Jens Rosenboom)
Date: Mon, 27 Oct 2008 14:54:18 +0100
Subject: RADIUS/IPv6CP bits and pieces for IPv6 subscriber access
In-Reply-To: <20081024165900.GA30213@srv03.cluenet.de>
References: <FD8724B2-1EAF-4A4D-9D7A-2B70BF759992@hopcount.ca>
	<20081024092207.GH5388@bo.mcbone.net>
	<20081024165900.GA30213@srv03.cluenet.de>
Message-ID: <20081027135418.GP5388@bo.mcbone.net>

On Fri, Oct 24, 2008 at 06:59:00PM +0200, Daniel Roesen wrote:
> On Fri, Oct 24, 2008 at 11:22:07AM +0200, Jens Rosenboom wrote:
> > Our current lab setup uses a Cisco 876 running 12.4(6)T10, we do
> > dhcpv6 local server on the ERX getting the prefix to be assigned
> > via Radius. The CPE fetches this prefix and announces it on the
> > local client LAN, seems to work pretty well except that 
> > autoconfig of the outside CPE address is broken.
> 
> Fancy to post some config examples for ERX and IOS?

For the ERX there is just

profile myprofile
 ipv6 unnumbered loopback 0
 ipv6 nd other-config-flag
!
service dhcpv6-local

and then on the RADIUS server something like

Framed-Ipv6-Prefix = 2001:748:42:cc00::/56

to define what the ERX will send via DHCPv6. For IOS I have:

interface Dialer1
 ipv6 address autoconfig default
 ipv6 dhcp client pd LAN
!
interface Vlan1
 ipv6 address LAN 1111::1/64

Roughly the same behaviour can be done on a *nix box running
the wide dhcpv6-client and this config:

# cat /etc/wide-dhcpv6/dhcp6c.conf 
interface ppp0
{
  send ia-pd 0;
};

id-assoc pd {
    prefix-interface eth1 {
        sla-id 1;
        sla-len 8;
    };
};


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20081027/b630db00/attachment.bin 

From jens.rosenboom at freenet.ag  Mon Oct 27 15:03:45 2008
From: jens.rosenboom at freenet.ag (Jens Rosenboom)
Date: Mon, 27 Oct 2008 15:03:45 +0100
Subject: RADIUS/IPv6CP bits and pieces for IPv6 subscriber access
In-Reply-To: <20081026205703.GU2820@home.opsec.eu>
References: <FD8724B2-1EAF-4A4D-9D7A-2B70BF759992@hopcount.ca>
	<20081026205703.GU2820@home.opsec.eu>
Message-ID: <20081027140345.GQ5388@bo.mcbone.net>

On Sun, Oct 26, 2008 at 09:57:03PM +0100, Kurt Jaeger wrote:
...
> Are there known CPE which barf on receiving IPv6CP ?
> 
> How do you handle all the "corner" cases ?
> 
> - One PPPoE session with both v4 and v6
> - One PPPoE session with only v4
> - One PPPoE session with only v6
> 
> Are you using different vpdn groups for it ?

Our server does not initiate IPv6CP actively, it needs to be triggered
by the CPE, so older equipment should continue to work as before with
no change required.

If the CPE refuses to do IPCP, the server still continues and tries
to negotiate v4 every now and then again, but that doesn't seem to
affect v6 either.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20081027/f832d085/attachment.bin 

From nick-lists at netability.ie  Mon Oct 27 16:51:13 2008
From: nick-lists at netability.ie (Nick Hilliard)
Date: Mon, 27 Oct 2008 15:51:13 +0000
Subject: RADIUS/IPv6CP bits and pieces for IPv6 subscriber access
In-Reply-To: <20081027140345.GQ5388@bo.mcbone.net>
References: <FD8724B2-1EAF-4A4D-9D7A-2B70BF759992@hopcount.ca>	<20081026205703.GU2820@home.opsec.eu>
	<20081027140345.GQ5388@bo.mcbone.net>
Message-ID: <4905E371.60108@netability.ie>

On 27/10/2008 14:03, Jens Rosenboom wrote:
> Our server does not initiate IPv6CP actively, it needs to be triggered
> by the CPE, so older equipment should continue to work as before with
> no change required.

I love these devices built on the "be liberal in what you send, and 
conservative in what you accept" principal.

Nick

From gert at space.net  Wed Oct 29 09:08:14 2008
From: gert at space.net (Gert Doering)
Date: Wed, 29 Oct 2008 09:08:14 +0100
Subject: Some leaks in China/Hongkong
In-Reply-To: <490739B1.3040500@dfn.de>
References: <20081026131752.GA7741@pest> <490493EA.4050009@he.net>
	<20081027051754.GO21072@Space.Net> <490739B1.3040500@dfn.de>
Message-ID: <20081029080814.GB21072@Space.Net>

Hi,

On Tue, Oct 28, 2008 at 05:11:29PM +0100, Thomas Schmid wrote:
> > It's much worse.  At least DFN *has* a full view, but they prefer Geant2
> > routes, because "NREN stuff needs to go there".
>
> that's right and this is badly needed today and in the future. We don't want
> to send any NREN traffic via unknown peering paths alone because this
> affects mutltiple Gigs of traffic and might flood quite some links.

So you're sending *non*-NREN traffic over scenic paths round the world?

Some time in the last century, we did local-pref our DECIX-peers, because
"peering is cool, upstream is expensive".  Shortly afterwards, we were
seeing a path with some 10 AS hops over peering, while transit would 
have been 3 AS hops, and much better bandwidth.  Guess where our packets
went...

Since then we've stuck to "AS-Path lenght is a useful metric, MED will
be taken into account, and local-pref will only be used in well-defined(!)
exceptions".

Just local-prefing anything that comes via a NREN link does not sound
very well-defined, so this is guaranteed to cause issues again and again.

[..]
> I don't see an easy solution for the time being. So manual reaction on people
> complaining is currently the only way to deal with the problem.

You're currently using the reactive approach "local-pref everything, 
maintain (negative) exception lists".  Our experience has been that 
"local-pref nothing, maintain (positive) exception lists" is usually 
causing much less pain to our customers.

But then, our definition of "happy packets" is "fast delivery" - other
people might consider a scenic world tour a nice way to make happy
packets...


To be a bit more constructive: you could maintain a list of AS numbers
that belong to known research networks and should be reached via Geant2,
and local-pref these.  Anything else coming in via Geant2 should not be 
local-prefed (don't necessarily *drop*, even if that might be prudent given
some of the crap I2 is leaking, but at least do not *force*) - which would 
avoid routing Google traffic to Hongkong, instead of Amsterdam.


We're trying to convince content providers that they should publish
AAAA records - and e.g. google rightly says "as long as people's routing 
is so f****ed up, publishing AAAA records is going to hurt our users".

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
-------------- 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/20081029/4f063444/attachment.bin 

From schmid at dfn.de  Tue Oct 28 17:11:29 2008
From: schmid at dfn.de (Thomas Schmid)
Date: Tue, 28 Oct 2008 17:11:29 +0100
Subject: Some leaks in China/Hongkong
In-Reply-To: <20081027051754.GO21072@Space.Net>
References: <20081026131752.GA7741@pest> <490493EA.4050009@he.net>
	<20081027051754.GO21072@Space.Net>
Message-ID: <490739B1.3040500@dfn.de>

Hi all,

Gert Doering wrote:
> Hi,
> 
> On Sun, Oct 26, 2008 at 08:59:38AM -0700, Mike Leber wrote:
>> dfn, geant2, or internet2 don't currently get a decent full view 
>> otherwise they wouldn't send traffic to Hong Kong.
> 
> It's much worse.  At least DFN *has* a full view, but they prefer Geant2
> routes, because "NREN stuff needs to go there".
> 

that's right and this is badly needed today and in the future. We don't want
to send any NREN traffic via unknown peering paths alone because this
affects mutltiple Gigs of traffic and might flood quite some links.

> And since I2 seems to be really unwilling to properly sort out their 
> routing (properly distinguish between "customers", "peers", and "upstream/
> transit", with the proper filters in place to avoid leaking everything
> everywhere) this is causing harm again and again.
> 

here we go ...

> 
> I have some more of these... Egyptian REN more specifics being leaked by 
> I2 all over the place...
> 
> grh.sixxs.net> show bgp ipv6 2001:4300:2001::/48
> BGP routing table entry for 2001:4300:2001::/48
> Paths: (14 available, best #3, table Default-IP-Routing-Table)
>   Not advertised to any peer
>   13645 19151 9304 4635 17579 11537 33789 24863
>     2001:5b8:fffe:: from 2001:5b8:fffe:: (64.135.0.0)
>       Origin IGP, localpref 100, valid, external
>       Community: 13645:3121
>       Last update: Sun Oct 26 10:33:10 2008
> 
>   20932 30781 5511 10764 11537 33789 24863
>     2001:41e0:0:f::1 from 2001:41e0:0:f::1 (217.169.143.20)
>       Origin IGP, metric 0, localpref 100, valid, external
>       Last update: Fri Oct 24 21:43:41 2008
> 
> ...
> 
> (19 /48s in total, only visible via 11537)
> 
> The really bad thing about that is that the /32 in question seems to have
> direct transit via Sprint, which is not used now, since "longest prefix
> wins"...
> 

I don't see an easy solution for the time being. So manual reaction on people
complaining is currently the only way to deal with the problem.

Regards,

  Thomas


From schmid at dfn.de  Wed Oct 29 14:01:30 2008
From: schmid at dfn.de (Thomas Schmid)
Date: Wed, 29 Oct 2008 14:01:30 +0100
Subject: Some leaks in China/Hongkong
In-Reply-To: <20081029080814.GB21072@Space.Net>
References: <20081026131752.GA7741@pest> <490493EA.4050009@he.net>
	<20081027051754.GO21072@Space.Net> <490739B1.3040500@dfn.de>
	<20081029080814.GB21072@Space.Net>
Message-ID: <49085EAA.8060404@dfn.de>

Hi Gert,

Gert Doering wrote:
> Hi,
> 
> On Tue, Oct 28, 2008 at 05:11:29PM +0100, Thomas Schmid wrote:
>>> It's much worse.  At least DFN *has* a full view, but they prefer Geant2
>>> routes, because "NREN stuff needs to go there".
>> that's right and this is badly needed today and in the future. We don't want
>> to send any NREN traffic via unknown peering paths alone because this
>> affects mutltiple Gigs of traffic and might flood quite some links.
> 
> So you're sending *non*-NREN traffic over scenic paths round the world?
> 

we're not talking about normal traffic here, but about a leak that took
place via a university in Hong Kong. So no, we're not sending traffic
intentionally via the scenic path.

Additionally, the topic GBLX IPv6 upstream was discussed here before -
and we had to shut the BGP session more than once because of problems there -
The other IPv6 upstream is under way, but initial implementation failed with
technical problems. My feeling is that Geant v6-upstream
is not causing more trouble than the other ones. This is a general problem
with IPv6 routing worldwide.

> Some time in the last century, we did local-pref our DECIX-peers, because
> "peering is cool, upstream is expensive".  Shortly afterwards, we were
> seeing a path with some 10 AS hops over peering, while transit would 
> have been 3 AS hops, and much better bandwidth.  Guess where our packets
> went...
> 
> Since then we've stuck to "AS-Path lenght is a useful metric, MED will
> be taken into account, and local-pref will only be used in well-defined(!)
> exceptions".
> 

we're as NRN in a different situation as mentioned. Look at the
GN2+NRN cloud as some sort of loose corporate network.

> Just local-prefing anything that comes via a NREN link does not sound
> very well-defined, so this is guaranteed to cause issues again and again.
> 

this is based on BGP communities that in this case did not match the actual
policy that was announced in these prefixes. The community set was 20965:11537
and translates into 'Routes received from Abilene'. I somehow have to rely
on the fact that the tagging reflects the nature of the routes.

> [..]
>> I don't see an easy solution for the time being. So manual reaction on people
>> complaining is currently the only way to deal with the problem.
> 
> You're currently using the reactive approach "local-pref everything, 
> maintain (negative) exception lists".  Our experience has been that 
> "local-pref nothing, maintain (positive) exception lists" is usually 
> causing much less pain to our customers.
> 

the exception list is generated by presence or absence of certain BGP communities.

> But then, our definition of "happy packets" is "fast delivery" - other
> people might consider a scenic world tour a nice way to make happy
> packets...
> 

I assume you forgot a smiley here?

> 
> To be a bit more constructive: you could maintain a list of AS numbers
> that belong to known research networks and should be reached via Geant2,
> and local-pref these.  Anything else coming in via Geant2 should not be 
> local-prefed (don't necessarily *drop*, even if that might be prudent given
> some of the crap I2 is leaking, but at least do not *force*) - which would 
> avoid routing Google traffic to Hongkong, instead of Amsterdam.
>

again, the current tool used for this is BGP communties. The list is very
dynamic with the constant world wide extension of the Geant2-interconnections.
We must rely on the correct tagging of the routes. You can not prevent
leaks with this, but a static list is *not* a scalable solution. Is RADB
a solution? In theory yes, in praxis no.

> 
> We're trying to convince content providers that they should publish
> AAAA records - and e.g. google rightly says "as long as people's routing 
> is so f****ed up, publishing AAAA records is going to hurt our users".
> 

tell this to the people in Hong Kong. Again - the routing is f****d up
not because some local pref was used somewhere, but because people in the world
don't care about routing-policies in IPv6 as much as they do in IPv4.

But to settle the issue: we took the pragmatic approach and removed the local pref
setting for some IPv6 paths. This contradicts the approach of
treating v4 and v6 the same, but pays tribute to the fact that the v6
routing is still not ripe for equal treatment as v4. Also, this will only stay
in place until v6 traffic reaches Gbit level or people start complaining
about suboptimal (i.e. non-GN2) v6-routing to asian NRNs.

Best regards,

   Thomas