Mailing List Archive: nsp: ipv6

Hosting provider allocation advice

1 2

View All

Index | Next | Previous | View Threaded

wouter at widexs

Oct 15, 2009, 3:32 AM

Post #1 of 38 (2036 views)
Permalink

Hosting provider allocation advice

Hi,

We're a Hosting provider and basicly we have (for now)
3 different product-groups we want to launch IPv6 on.

1 - Shared Hosting
These servers (Linux), are all in 1 vlan.
Each server has 1 IPv4 address from the subnet that's configured on the
vlan.
Then we have an IPv4 /24 routed to each of the servers
(each server has 1 /24 to host sites on).

Here I'd assign a single /64 and use static addressing.
And perhaps additionaly take this single /64 and divide it up like IPv4
:
One subnet (/112?) for the 'main' server IPv6 addresses,
and route a /112 per server to the main IPv6 address.

2 - Premium Managed & Unmanaged Hosting (Co-location).
Each customer has one (or more) dedicated subnets and vlans.

Here I'd assign a /64 per vlan.
I'd do static addressing for Managed, but probably provide
RA (EUI-64) for Unmanaged.

3 - Managed and Umanaged Hosting (Co-location).
These servers are in 'shared' subnets, ranging from /23 to /26,
and each customer get's assigned at least 1 IP from this subnet
and more if they can justify. For customers needing 'large' subnets,
we'd route a different subnet to their server of choice.

Here, I'm not sure what to do...

You should at least assign a /64 per customer, but how would one do that

when they are in shared subnets/vlans... ?

If for every server I'd need to assign a /64 secondary to our vlan
interfaces,
I'd trip the maximums
(Nortel Passport 8600 used for these customers has quite some
limitations on IPv6).
It would be nice though, cause once IPv4 is no longer used (...) we
could
move customers to another/dedicated vlan.

We've also fiddled with the idea of assigning one /48 to each of these
vlans,
and let each 'server' use a /64 out of it. This still seems a bit weird
though...

Also, since we do IP based billing here,
we'd never know if one has 'hijacked' some IP space.

Yes, we'd know for un-assigned addresses
(not assigned but has traffic -> alert),
but I don't expect a customer to use all addresses out of 'their' /64,
so the not used addresses could be easily be abused.

For IPv4, all addresses are usually really used and the customer
who's IP's are hijacked, would almost definitely hang on the phone in
no-time.

Some advice would be very appreciated, cause I'm banging my head against
the
wall to find the best options and then we're ready to roll.
We already provide it to some customers on a 'beta' request basis,
but we would like to setup a good policy and then provide all customers
with IPv6
by default as well.

Many thanks & best regards,

Wouter de Jong
WideXS

gert at space

Oct 15, 2009, 4:15 AM

Post #2 of 38 (1983 views)
Permalink

Re: Hosting provider allocation advice [In reply to]

Hi,

On Thu, Oct 15, 2009 at 12:32:53PM +0200, Wouter de Jong wrote:
> You should at least assign a /64 per customer, but how would one do that
> when they are in shared subnets/vlans... ?

"unshare the VLAN"...?

(Which might not be possible if the number of customers is too high...)

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

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

tedm at ipinc

Oct 15, 2009, 6:57 AM

Post #3 of 38 (1971 views)
Permalink

Re: Hosting provider allocation advice [In reply to]

Wouter de Jong wrote:
> Hi,
>
> We're a Hosting provider and basicly we have (for now)
> 3 different product-groups we want to launch IPv6 on.
>
>
> 1 - Shared Hosting
> These servers (Linux), are all in 1 vlan.
> Each server has 1 IPv4 address from the subnet that's configured on the
> vlan.
> Then we have an IPv4 /24 routed to each of the servers
> (each server has 1 /24 to host sites on).
>
> Here I'd assign a single /64 and use static addressing.
> And perhaps additionaly take this single /64 and divide it up like IPv4
> :
> One subnet (/112?) for the 'main' server IPv6 addresses,
> and route a /112 per server to the main IPv6 address.
>
>
> 2 - Premium Managed & Unmanaged Hosting (Co-location).
> Each customer has one (or more) dedicated subnets and vlans.
>
> Here I'd assign a /64 per vlan.
> I'd do static addressing for Managed, but probably provide
> RA (EUI-64) for Unmanaged.
>
>
> 3 - Managed and Umanaged Hosting (Co-location).
> These servers are in 'shared' subnets, ranging from /23 to /26,
> and each customer get's assigned at least 1 IP from this subnet
> and more if they can justify. For customers needing 'large' subnets,
> we'd route a different subnet to their server of choice.
>
> Here, I'm not sure what to do...
>
>
> You should at least assign a /64 per customer, but how would one do that
>
> when they are in shared subnets/vlans... ?
>
> If for every server I'd need to assign a /64 secondary to our vlan
> interfaces,
> I'd trip the maximums
> (Nortel Passport 8600 used for these customers has quite some
> limitations on IPv6).
> It would be nice though, cause once IPv4 is no longer used (...) we
> could
> move customers to another/dedicated vlan.
>
> We've also fiddled with the idea of assigning one /48 to each of these
> vlans,
> and let each 'server' use a /64 out of it. This still seems a bit weird
> though...
>

No it's not when you understand IPv6

You use DNS names, right? You can always renumber.

> Also, since we do IP based billing here,
> we'd never know if one has 'hijacked' some IP space.
>

"IP based billing" will be the first casualty of IPv6.

There's a shortage of IPv4 which is why you can bill for
each IPv4 number.

There's no shortage of IPv6. Your competitors won't hesitate
to spread around IPv6 numbers like peanut butter.

Ted

> Yes, we'd know for un-assigned addresses
> (not assigned but has traffic -> alert),
> but I don't expect a customer to use all addresses out of 'their' /64,
> so the not used addresses could be easily be abused.
>
> For IPv4, all addresses are usually really used and the customer
> who's IP's are hijacked, would almost definitely hang on the phone in
> no-time.
>
>
> Some advice would be very appreciated, cause I'm banging my head against
> the
> wall to find the best options and then we're ready to roll.
> We already provide it to some customers on a 'beta' request basis,
> but we would like to setup a good policy and then provide all customers
> with IPv6
> by default as well.
>
> Many thanks & best regards,
>
> Wouter de Jong
> WideXS
>
>

d.bay at rrbone-bb

Oct 15, 2009, 7:04 AM

Post #4 of 38 (1968 views)
Permalink

Re: Hosting provider allocation advice [In reply to]

Ted Mittelstaedt schrieb:
> Wouter de Jong wrote:
[snip]
>> Also, since we do IP based billing here, we'd never know if one has
>> 'hijacked' some IP space.
>>
>
> "IP based billing" will be the first casualty of IPv6.
>
> There's a shortage of IPv4 which is why you can bill for
> each IPv4 number.
>
> There's no shortage of IPv6. Your competitors won't hesitate
> to spread around IPv6 numbers like peanut butter.

I read it like "We do IP-based Traffic Accounting" and not as "Our
Customers pay per IP on their box".

Kind regards,
Dominik

wouter at widexs

Oct 15, 2009, 7:05 AM

Post #5 of 38 (1972 views)
Permalink

RE: Hosting provider allocation advice [In reply to]

Hi Gert,

> -----Original Message-----
> From: Gert Doering [mailto:gert [at] space]
> Sent: Thursday, October 15, 2009 13:16
> To: Wouter de Jong
> Cc: ipv6-ops [at] lists
> Subject: Re: Hosting provider allocation advice
>
> > You should at least assign a /64 per customer, but how would one do
> that
> > when they are in shared subnets/vlans... ?
>
> "unshare the VLAN"...?
>
> (Which might not be possible if the number of customers is too
high...)

Well, if each customer would have it's own subnet...
yes, we would be able to do that.
However, they don't... they share IP's out of the same /23 - /26's.
It would also give us way more then 1024 vlan's, which could potentially

lead to problems with our access-layer (max 255 vlans per stack).
Private vlans might be an option to bypass that one,
but I think that imposes a lot of other trouble,
and I'm almost certain that our access-layer doesn't support it.

> Gert Doering

Thanks & regards,

Wouter

michael.dillon at bt

Oct 15, 2009, 7:11 AM

Post #6 of 38 (1975 views)
Permalink

RE: Hosting provider allocation advice [In reply to]

Rather than add IPv6 to existing services or convert each existing
service to an IPv6 version, I would rethink it from the ground up.

To start with, it seems that a shared service would be good enough for
most people since very few are pumping enough traffic to require a
dedicated server or dedicated VLAN. That could be done on one /64. You
would never need any more addresses for this no matter how large your
data center grows. Of course, you might want to offer different classes
of shared service with separate /64s, i.e. one in which porn hosting is
acceptable and one in which it is not. Also a class of shared hosting
that allows email servers to use port 25. That way there will be less
issues with shared fate from others using the same /64.

When you get to the point where people want to do multiple website
hosting on a single dedicated server, then perhaps a /64 per server
would be right since it means that they do not share fate with the same
subnet prefix as the spammer next door. This also fits the model of
renting a dedicated server to someone who then runs VM software and
builds an entire network of virtual machines on their server.

For people who have multiple physical servers, again one /64 per
customer VLAN.

Please avoid ever using a prefix longer than /64 because a) you don't
need to, b) nobody will ever thank you for saving a few addresses, c) it
will cost you more in complexity, and d) any customers on such long
prefixes will share fate with everyone else in the /64. The outside
world will always assume that multiple addresses from the same /64 are
the responsibility of one customer.

For your own internal use (monitoring systems etc.) use a ULA block.

And don't be afraid to allocate more /64s than you had planned, if it
makes your life easier in some way. If you approach IPv6 as a new and
separate service/network from the existing stuff, perhaps you can
simplify things by wasting/spending some of those lovely addresses that
you have received.

--Michael Dillon

wouter at widexs

Oct 15, 2009, 7:12 AM

Post #7 of 38 (1969 views)
Permalink

RE: Hosting provider allocation advice [In reply to]

Hi Ted,

> -----Original Message-----
> From: Ted Mittelstaedt [mailto:tedm [at] ipinc]
> Sent: Thursday, October 15, 2009 15:58
> To: Wouter de Jong
> Cc: ipv6-ops [at] lists
> Subject: Re: Hosting provider allocation advice

> > We've also fiddled with the idea of assigning one /48 to each of
> these
> > vlans,
> > and let each 'server' use a /64 out of it. This still seems a bit
> weird
> > though...
> >
>
> No it's not when you understand IPv6
>
> You use DNS names, right? You can always renumber.

I'm not really sure I understand what you mean,
could you clarify a bit perhaps ?

> > Also, since we do IP based billing here,
> > we'd never know if one has 'hijacked' some IP space.
> >
>
> "IP based billing" will be the first casualty of IPv6.
>
> There's a shortage of IPv4 which is why you can bill for
> each IPv4 number.
>
> There's no shortage of IPv6. Your competitors won't hesitate
> to spread around IPv6 numbers like peanut butter.

I meant traffic billing based on IP number :)

>
> Ted

Regards,

Wouter

michael.dillon at bt

Oct 15, 2009, 7:14 AM

Post #8 of 38 (1968 views)
Permalink

RE: Hosting provider allocation advice [In reply to]

> lead to problems with our access-layer (max 255 vlans per stack).
> Private vlans might be an option to bypass that one, but I
> think that imposes a lot of other trouble, and I'm almost
> certain that our access-layer doesn't support it.

It sounds like you need to look for opportunities to do aggregation at a
higher level, i.e. one /60 block (or /56) to one area of the network.

--Michael Dillon

wouter at widexs

Oct 15, 2009, 7:48 AM

Post #9 of 38 (1980 views)
Permalink

RE: Hosting provider allocation advice [In reply to]

Hi Dominik,

> -----Original Message-----
> From: ipv6-ops-bounces+wouter=widexs.nl [at] lists [mailto:ipv6-
> ops-bounces+wouter=widexs.nl [at] lists] On Behalf Of Dominik
Bay
> Sent: Thursday, October 15, 2009 16:04
> Cc: ipv6-ops [at] lists
> Subject: Re: Hosting provider allocation advice
>
> I read it like "We do IP-based Traffic Accounting" and not as "Our
> Customers pay per IP on their box".

Exactly :)

> Kind regards,
> Dominik

Regards,

Wouter

wouter at widexs

Oct 15, 2009, 8:09 AM

Post #10 of 38 (1968 views)
Permalink

RE: Hosting provider allocation advice [In reply to]

Hi Michael,

> -----Original Message-----
> From: ipv6-ops-bounces+wouter=widexs.nl [at] lists [mailto:ipv6-
> ops-bounces+wouter=widexs.nl [at] lists] On Behalf Of
> michael.dillon [at] bt
> Sent: Thursday, October 15, 2009 16:14
> To: ipv6-ops [at] lists
> Subject: RE: Hosting provider allocation advice
>
> > lead to problems with our access-layer (max 255 vlans per stack).
> > Private vlans might be an option to bypass that one, but I
> > think that imposes a lot of other trouble, and I'm almost
> > certain that our access-layer doesn't support it.
>
> It sounds like you need to look for opportunities to do aggregation at
> a
> higher level, i.e. one /60 block (or /56) to one area of the network.

With access-layer switches I refer to the switches where our customers
servers are directly connected to. Those are only L2 capable, so the L3
(per vlan) is done on the core-switch in this case.

> --Michael Dillon

Regards,

Wouter

tedm at ipinc

Oct 15, 2009, 8:16 AM

Post #11 of 38 (1977 views)
Permalink

Re: Hosting provider allocation advice [In reply to]

Wouter de Jong wrote:
> Hi Ted,
>
>> -----Original Message-----
>> From: Ted Mittelstaedt [mailto:tedm [at] ipinc]
>> Sent: Thursday, October 15, 2009 15:58
>> To: Wouter de Jong
>> Cc: ipv6-ops [at] lists
>> Subject: Re: Hosting provider allocation advice
>
>
>>> We've also fiddled with the idea of assigning one /48 to each of
>> these
>>> vlans,
>>> and let each 'server' use a /64 out of it. This still seems a bit
>> weird
>>> though...
>>>
>> No it's not when you understand IPv6
>>
>> You use DNS names, right? You can always renumber.
>
> I'm not really sure I understand what you mean,
> could you clarify a bit perhaps ?
>

What I was meaning is don't be too hung up about making the
wrong decision about allocating subnets right now. If you force
reliance on DNS from the absolute beginning then if you need to
renumber later to reallocate your subnets, it's no big deal.

Buried in the fine print of our own shared web hosting contracts
is language that states the customer's server is never guaranteed
to keep a specific IP address.

Granted, few customers READ the fine print, but we make every
effort when setting them up to not mention IP addresses

>>> Also, since we do IP based billing here,
>>> we'd never know if one has 'hijacked' some IP space.
>>>
>> "IP based billing" will be the first casualty of IPv6.
>>
>> There's a shortage of IPv4 which is why you can bill for
>> each IPv4 number.
>>
>> There's no shortage of IPv6. Your competitors won't hesitate
>> to spread around IPv6 numbers like peanut butter.
>
> I meant traffic billing based on IP number :)
>

Doctor it hurts when I do this!

Then don't do that!

Seriously, you need to rethink your billing data collection. How
difficult is it to go to your router that's feeding your network and
setup a permit access list and count packets that pass through it?
Construct the list with whatever granularity you want.

Ted

>> Ted
>
> Regards,
>
> Wouter
>

wouter at widexs

Oct 15, 2009, 8:36 AM

Post #12 of 38 (1980 views)
Permalink

RE: Hosting provider allocation advice [In reply to]

Hi Ted,

> -----Original Message-----
> From: Ted Mittelstaedt [mailto:tedm [at] ipinc]
> Sent: Thursday, October 15, 2009 17:16
> To: Wouter de Jong
> Cc: ipv6-ops [at] lists
> Subject: Re: Hosting provider allocation advice

Thanks for explaning :)

> What I was meaning is don't be too hung up about making the
> wrong decision about allocating subnets right now. If you force
> reliance on DNS from the absolute beginning then if you need to
> renumber later to reallocate your subnets, it's no big deal.

(most) Firewalls, ACL's, RBL's ... like IP's instead of hostnames.
So that could be a bummer.
Especially if a customer would manage a lot of remote networks
from his server in our DC.

> Buried in the fine print of our own shared web hosting contracts
> is language that states the customer's server is never guaranteed
> to keep a specific IP address.

While this makes perfectly sense from 'our' side of the view,
a lot of our customers would leave us instantly.
They'd have to change IP's their anyway, but that won't stop them.
We've done it in the past, and they we're not amused.
I'd never get approval for it from $management,
in these times they want to keep every client at all (reasonable) cost.

> Granted, few customers READ the fine print, but we make every
> effort when setting them up to not mention IP addresses
>
> >>> Also, since we do IP based billing here,
> >>> we'd never know if one has 'hijacked' some IP space.
> >>>
> >> "IP based billing" will be the first casualty of IPv6.
> >>
> >> There's a shortage of IPv4 which is why you can bill for
> >> each IPv4 number.
> >>
> >> There's no shortage of IPv6. Your competitors won't hesitate
> >> to spread around IPv6 numbers like peanut butter.
> >
> > I meant traffic billing based on IP number :)
> >
>
> Doctor it hurts when I do this!
>
> Then don't do that!
>
> Seriously, you need to rethink your billing data collection. How
> difficult is it to go to your router that's feeding your network and
> setup a permit access list and count packets that pass through it?
> Construct the list with whatever granularity you want.

It can be hard, cause your device must support it :))

We've put a fiber-tap between our fibers to our
border routers, and run an accounting program that fills a database with

src dst traffic insert-date. So internal traffic from vlan <-> vlan is
for free,
but traffic that goes to our Peerings/Transit, get's billed.

Though with IPv6, it'll get a lot more records :)
But I'm least worried about that.
I'd rather implement a good policy, and solve my billing later on.

The thing that frustrates me is that I just don't know how to give our
our 3rd product group (the ones with shared vlan/subnet) IPv6 in a sane
way.

> Ted

Regards,

Wouter

jay at impulse

Oct 15, 2009, 9:42 AM

Post #13 of 38 (1963 views)
Permalink

Re: Hosting provider allocation advice [In reply to]

Dominik Bay wrote:

> I read it like "We do IP-based Traffic Accounting" and not as "Our
> Customers pay per IP on their box".

That's better than "Our Customers pay or IP on their box".

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

gert at space

Oct 15, 2009, 10:56 AM

Post #14 of 38 (1955 views)
Permalink

Re: Hosting provider allocation advice [In reply to]

Hi,

On Thu, Oct 15, 2009 at 03:11:53PM +0100, michael.dillon [at] bt wrote:
> To start with, it seems that a shared service would be good enough for
> most people since very few are pumping enough traffic to require a
> dedicated server or dedicated VLAN. That could be done on one /64.

The fundamental problem with shared service (as defined in: one shared
layer 2 network, multiple machines, real or VM, admin'ned by different
persons) is security. You see abuse coming from one specific IPv6
address - which machine is using it?

(Worse: you get complaints about abuse that happened yesterday, from
one specific IPv6 address, but that address is no longer visible anywhere
and has never been officially assigned to any of these servers...)

"One VLAN per customer" (+uRPF) nicely solves that part, but indeed
brings up some other problems (number of VLANs, etc.). This is the way
we decided to do that.

"Static neighbour configuration plus lots of L2 security" also helps, but
not all necessary gear is available yet. This is the way some of the
big "WeHostMillions" providers need to take.

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

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

gert at space

Oct 15, 2009, 10:59 AM

Post #15 of 38 (1959 views)
Permalink

Re: Hosting provider allocation advice [In reply to]

Hi,

On Thu, Oct 15, 2009 at 08:16:08AM -0700, Ted Mittelstaedt wrote:
> Seriously, you need to rethink your billing data collection. How
> difficult is it to go to your router that's feeding your network and
> setup a permit access list and count packets that pass through it?
> Construct the list with whatever granularity you want.

So this is not "ip based billing"?

And how exactly does this protect against customer A bluntly using
IPv6 addresses that belong to customer B, but are carried in the same
layer 2 segment?

(private VLANs + static MAC assignment + port security + static ND
+ L3 ACLs on L2 switch port can fix this to some extent, but it's
messy)

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

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

berni at birkenwald

Oct 15, 2009, 11:04 AM

Post #16 of 38 (1970 views)
Permalink

Re: Hosting provider allocation advice [In reply to]

On Thu, Oct 15, 2009 at 12:32:53PM +0200, Wouter de Jong wrote:

Hi,

> 3 - Managed and Umanaged Hosting (Co-location).
> These servers are in 'shared' subnets, ranging from /23 to /26,
> and each customer get's assigned at least 1 IP from this subnet
> and more if they can justify. For customers needing 'large' subnets,
> we'd route a different subnet to their server of choice.
>
> Here, I'm not sure what to do...
>
> You should at least assign a /64 per customer, but how would one do that
> when they are in shared subnets/vlans... ?

As Gert already said, "unshare that VLAN".

If this is not possible, I (probably not the only one) thought of the
following approach that at least one company is using already:

a) do not use global addresses on the transport VLAN at all
b) assign a /64 or /48 per customer, route it to their link-local
address

customer configuration won't change, they can still statically configure
their own prefix on their ethernet port and learn the default gateway
from RA (or set a static route, but that needs a link-local next-hop as
well).

c) (optional) set a static neighbor entry for the LL addr to their MAC
d) (optional) set port security to only allow the MAC on their port
e) (optional) enable private VLAN

This solves a number of spoofing issues (attackers in the same VLAN
cannot redirect traffic to the customer by spoofing ND and thus cannot
spoof TCP) and is compatible with private VLAN. However, attackers can
still send packets from the wrong source address, so any address based
billing is suspectible to attack.

Fixing that won't be possible without L2 infrastructure that can so some
filtering (e.g. IPv6 ACL) per customer port.

Bernhard

tedm at ipinc

Oct 15, 2009, 12:01 PM

Post #17 of 38 (1952 views)
Permalink

Re: Hosting provider allocation advice [In reply to]

Wouter de Jong wrote:
> Hi Ted,
>
>> -----Original Message-----
>> From: Ted Mittelstaedt [mailto:tedm [at] ipinc]
>> Sent: Thursday, October 15, 2009 17:16
>> To: Wouter de Jong
>> Cc: ipv6-ops [at] lists
>> Subject: Re: Hosting provider allocation advice
>
> Thanks for explaning :)
>
>> What I was meaning is don't be too hung up about making the
>> wrong decision about allocating subnets right now. If you force
>> reliance on DNS from the absolute beginning then if you need to
>> renumber later to reallocate your subnets, it's no big deal.
>
> (most) Firewalls, ACL's, RBL's ... like IP's instead of hostnames.
> So that could be a bummer.

That's why you get paid the big bucks.

Let me know when your mechanic starts complaining about how hard it
is to fix cars. ;-)

> Especially if a customer would manage a lot of remote networks
> from his server in our DC.
>

If the customer is educated enough to know how to do that, they
are educated enough to know that there's no IP permanence unless
you request your numbers from an RIR.

>> Buried in the fine print of our own shared web hosting contracts
>> is language that states the customer's server is never guaranteed
>> to keep a specific IP address.
>
> While this makes perfectly sense from 'our' side of the view,
> a lot of our customers would leave us instantly.
> They'd have to change IP's their anyway, but that won't stop them.
> We've done it in the past, and they we're not amused.
> I'd never get approval for it from $management,
> in these times they want to keep every client at all (reasonable) cost.
>

Renumbering IPv4 is a lot more painful than renumbering IPv6.

Your customers who want IPv6 from you aren't going to be
among the subset of troglodyte customers you have that every ISP
has to deal with.

Keep in mind every other ISP offering IPv6 is going to be
doing this initially. As long as you aren't renumbering the
IPv4 they have from you, the few customers of yours who want
IPv6 will be understanding. After all if they leave, where
are they going to go to? Another hoster who doesn't even
offer IPv6 at all? Or another hoster that only offers IPv6
with the same stipulations your offering - that IP#s may
change? Highly unlikely.

Think of how many IPv6 hosters out there aren't even
running native, but using tunneled numbers from Hurricane
or some such.

You have time to play around with this stuff, don't cut
yourself short.

Ted

>> Granted, few customers READ the fine print, but we make every
>> effort when setting them up to not mention IP addresses
>>
>>>>> Also, since we do IP based billing here,
>>>>> we'd never know if one has 'hijacked' some IP space.
>>>>>
>>>> "IP based billing" will be the first casualty of IPv6.
>>>>
>>>> There's a shortage of IPv4 which is why you can bill for
>>>> each IPv4 number.
>>>>
>>>> There's no shortage of IPv6. Your competitors won't hesitate
>>>> to spread around IPv6 numbers like peanut butter.
>>> I meant traffic billing based on IP number :)
>>>
>> Doctor it hurts when I do this!
>>
>> Then don't do that!
>>
>> Seriously, you need to rethink your billing data collection. How
>> difficult is it to go to your router that's feeding your network and
>> setup a permit access list and count packets that pass through it?
>> Construct the list with whatever granularity you want.
>
> It can be hard, cause your device must support it :))
>
> We've put a fiber-tap between our fibers to our
> border routers, and run an accounting program that fills a database with
>
> src dst traffic insert-date. So internal traffic from vlan <-> vlan is
> for free,
> but traffic that goes to our Peerings/Transit, get's billed.
>
> Though with IPv6, it'll get a lot more records :)
> But I'm least worried about that.
> I'd rather implement a good policy, and solve my billing later on.
>
> The thing that frustrates me is that I just don't know how to give our
> our 3rd product group (the ones with shared vlan/subnet) IPv6 in a sane
> way.
>
>> Ted
>
> Regards,
>
> Wouter
>

tedm at ipinc

Oct 15, 2009, 12:06 PM

Post #18 of 38 (1952 views)
Permalink

Re: Hosting provider allocation advice [In reply to]

Gert Doering wrote:
> Hi,
>
> On Thu, Oct 15, 2009 at 08:16:08AM -0700, Ted Mittelstaedt wrote:
>> Seriously, you need to rethink your billing data collection. How
>> difficult is it to go to your router that's feeding your network and
>> setup a permit access list and count packets that pass through it?
>> Construct the list with whatever granularity you want.
>
> So this is not "ip based billing"?
>
> And how exactly does this protect against customer A bluntly using
> IPv6 addresses that belong to customer B, but are carried in the same
> layer 2 segment?
>

He already said he's OK with that happening, because it causes
customer B to call him, then he knows that this is happening.

> (private VLANs + static MAC assignment + port security + static ND
> + L3 ACLs on L2 switch port can fix this to some extent, but it's
> messy)
>

I didn't want to launch into a discussion of how messed up I think
his existing network was, for him to be using one customer stomping
on another customer as a kind of early warning device. I just wanted
to give him a possible bandaid to add to the bandaids he already has
on the monster.

At least he's looking at IPv6 - that's probably 1000% better than
most of the hosters out there.

Ted

alan.batie at peakinternet

Oct 15, 2009, 12:07 PM

Post #19 of 38 (1964 views)
Permalink

Re: Hosting provider allocation advice [In reply to]

Ted Mittelstaedt wrote:

> Let me know when your mechanic starts complaining about how hard it
> is to fix cars. ;-)

Ask your mechanic about that sometime, particularly someone who's worked
on 60's vintage cars vs post 70's cars... you'll likely get an earful :-)

tedm at ipinc

Oct 15, 2009, 12:40 PM

Post #20 of 38 (1949 views)
Permalink

Re: Hosting provider allocation advice [In reply to]

Alan Batie wrote:
> Ted Mittelstaedt wrote:
>
>> Let me know when your mechanic starts complaining about how hard it
>> is to fix cars. ;-)
>
> Ask your mechanic about that sometime, particularly someone who's worked
> on 60's vintage cars vs post 70's cars... you'll likely get an earful :-)

Heh

I do all my own wrenching on my own vehicles. The only thing I
don't do is subassemby rebuilds since those take a lot of expensive
specialized tools, and it's almost always cheaper to get a used
engine/transmission/diff/ac compressor/etc. than rebuild one.

I own a 68 Torino, and a couple 95 minivans with EFI and
computer-controlled transmissions and engines. The minivans are
no more difficult to work on. The only difference is the
troubleshooting techniques and tools.

It IS a lot harder to fix a modern vehicle with 60's era tools
and techniques. But 90's techniques are not hard to learn and
although the tooling is more expensive, it's still cheaper than
paying someone to do it. (besides the fact that I know the
procedure has been done properly, some of the stuff I've seen
in used vehicles I've bought over the years would make you
faint)

Actually, though, the point I was making earlier is that most
mechanics don't generally waste a lot of time complaining to
customers - they are more than happy to get the newer vehicles
because the repair times are so much longer on them (due to
the tight quarters making it necessary to practically take
the entire vehicle apart to get at what's broken) and the longer
the repair time, the more profitable.

Presumably, the OP is wanting to offer IPv6 so as to be able to
charge extra for it, save money with it, or attract more customers
with it (thus making money) - this is a business after all - thus
he should welcome the added complexity (you can charge more money
for it).

Ted

gdolley at arpnetworks

Oct 15, 2009, 4:35 PM

Post #21 of 38 (1940 views)
Permalink

Re: Hosting provider allocation advice [In reply to]

On Thu, Oct 15, 2009 at 05:36:09PM +0200, Wouter de Jong wrote:
> It can be hard, cause your device must support it :))
>
> We've put a fiber-tap between our fibers to our
> border routers, and run an accounting program that fills a database with
>
> src dst traffic insert-date. So internal traffic from vlan <-> vlan is
> for free,
> but traffic that goes to our Peerings/Transit, get's billed.

Man, you guys are sure doing it the hard way ;)

Why not just monitor customer interfaces, whether it be VLANs,
physical ports on routers/switches, even *nix boxes, pop the data in
Cacti / RRD, and write some scripts to report 95th percentile and/or
total data transfer? Cacti already has templates for both of these
methods.

--
Garry Dolley
ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181
Data center, VPS, and IP Transit solutions
Member Los Angeles County REACT, Unit 336 | WQGK336
Blog http://scie.nti.st

nuno.vieira at nfsi

Oct 15, 2009, 4:47 PM

Post #22 of 38 (1956 views)
Permalink

Re: Hosting provider allocation advice [In reply to]

Hi Garry,

I'd love to do that on my XMR's ve interfaces, if i could.

What solutions do you guys use out there to read ve / vlan counters on Foundry XMR switches ?

cheers,
---
Nuno Vieira
nfsi telecom, lda.

[Email] nuno.vieira [at] nfsi
[Phone] +351 21 114 2315
[Phone] +351 21 142 2300
[Mobile] +351 91 925 5561
[Fax] +351 21 114 2301
[Web] http://www.nfsi.pt/

----- Original Message -----
From: "Garry Dolley" <gdolley [at] arpnetworks>
To: "Wouter de Jong" <wouter [at] widexs>
Cc: ipv6-ops [at] lists
Sent: Friday, 16 October, 2009 12:35:25 AM
Subject: Re: Hosting provider allocation advice

On Thu, Oct 15, 2009 at 05:36:09PM +0200, Wouter de Jong wrote:
> It can be hard, cause your device must support it :))
>
> We've put a fiber-tap between our fibers to our
> border routers, and run an accounting program that fills a database with
>
> src dst traffic insert-date. So internal traffic from vlan <-> vlan is
> for free,
> but traffic that goes to our Peerings/Transit, get's billed.

Man, you guys are sure doing it the hard way ;)

Why not just monitor customer interfaces, whether it be VLANs,
physical ports on routers/switches, even *nix boxes, pop the data in
Cacti / RRD, and write some scripts to report 95th percentile and/or
total data transfer? Cacti already has templates for both of these
methods.

--
Garry Dolley
ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181
Data center, VPS, and IP Transit solutions
Member Los Angeles County REACT, Unit 336 | WQGK336
Blog http://scie.nti.st

wouter at widexs

Oct 16, 2009, 2:24 AM

Post #23 of 38 (1933 views)
Permalink

RE: Hosting provider allocation advice [In reply to]

Hi Ted,

> -----Original Message-----
> From: ipv6-ops-bounces+wouter=widexs.nl [at] lists [mailto:ipv6-
> ops-bounces+wouter=widexs.nl [at] lists] On Behalf Of Ted
> Mittelstaedt
> Sent: Thursday, October 15, 2009 21:41
> To: Alan Batie
> Cc: ipv6-ops [at] lists
> Subject: Re: Hosting provider allocation advice

> Presumably, the OP is wanting to offer IPv6 so as to be able to
> charge extra for it, save money with it, or attract more customers
> with it (thus making money) - this is a business after all - thus
> he should welcome the added complexity (you can charge more money
> for it).

We won't charge extra for IPv6, the primary intention for rolling
out IPv6 is to be ready for IPv6-only connectivity once that
becomes common. And ofcourse, that also has a commercial twist.
'Yes, we can deliver you IPv6 so you are fully reachble over IPv4 and/or
IPv6.'

:)

> Ted

Regards,

Wouter

wouter at widexs

Oct 16, 2009, 2:30 AM

Post #24 of 38 (1938 views)
Permalink

RE: Hosting provider allocation advice [In reply to]

Hi Garry,

> -----Original Message-----
> From: Garry Dolley [mailto:gdolley [at] arpnetworks]
> Sent: Friday, October 16, 2009 01:35
> To: Wouter de Jong
> Cc: ipv6-ops [at] lists
> Subject: Re: Hosting provider allocation advice
>
> Man, you guys are sure doing it the hard way ;)
>
> Why not just monitor customer interfaces, whether it be VLANs,
> physical ports on routers/switches, even *nix boxes, pop the data in
> Cacti / RRD, and write some scripts to report 95th percentile and/or
> total data transfer? Cacti already has templates for both of these
> methods.

The main reason for this, is that we don't charge backup traffic or
traffic
between servers from a customer, because these can be in different
vlans.
And some other reasons I don't know the details of.

I would be very happy with 95% based billing myself though.

Regards,

Wouter

benny+usenet at amorsen

Oct 16, 2009, 3:15 AM

Post #25 of 38 (1941 views)
Permalink

Re: Hosting provider allocation advice [In reply to]

<michael.dillon [at] bt> writes:

> Rather than add IPv6 to existing services or convert each existing
> service to an IPv6 version, I would rethink it from the ground up.

This is actually one of the few large problems with dual-stack: With
IPv4 you're often forced to put a lot of hosts into one subnet, because
the waste of 3 addresses per subnet potentially quadruples your IP
address requirements. To make that work you use switch-based firewalls
which make sure that the hosts on each port can only use the assigned IP
addresses and only access other ports according to the security policy.
With IPv4 DHCP you can even dynamically assign static addresses based on
switchport number.

This model is completely unnecessary in IPv6, and it is probably
difficult to get the fancy switch-based firewalls to work for IPv6
anyway. Even if you succeed, you still have to do all the static
allocation and address management for IPv6, because automatic addressing
(or just letting the customer handle it, within their subnet) just
doesn't work in this model.

The obvious way to do this in IPv6 is to route in the firewall instead
of switching. However, I haven't seen any device other than a modern
Unix box which can choose switching or routing based on whether a packet
is v4 or v6...

In summary, shared hosting centers now need to run a cable for IPv4 and
a cable for IPv6, and double the number of ports in their
switches/routers.

/Benny

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads