Out of curiosity, what in form would a request for a /48 need to be? A
checkbox on the application form, or some sort of written
justification? Remember that with an initial RIR allocation of a /32,
you've got 65K /48s ... so they're pretty cheap to give away.
Scott Weeks wrote:
[..]
I have about 100K DSL customers at this time and most all are households.
65K wouldn't cover that. At this point, I doubt that I'd require much
more than just asking and making sure the person is understanding what
they're asking for. Mostly, that'd be the leased line customers.
Thus why didn't you request a larger prefix from ARIN then?
Clearly you can justify it.
Then again, if you are going to provide /56's to home users, nobody will
think you are a bad person and most people will be quite happy already.
In your case I would then reserve (probably topdown) /48's, for the
larger sites/businesses and start allocating bottom-up for /56's to
endusers.
Greets,
Jeroen
Another idea would be to give each non-/48 customer the
first /56 out of each /48. If you started out with a /30 or /31 RIR block , by
the time you run out of /48s, you can either start using up the
subsequent /56s out of the first /48, as it's likely that the first /56
customer out of the /48 would have needed the /48 by that time.
Alternatively you might have become more comfortable with giving each
customer a /48, and wouldn't require any of them to renumber - they'd
just have to shorten their prefix length.
Regards,
Mark.
Mark Smith wrote:
Another idea would be to give each non-/48 customer the
first /56 out of each /48. If you started out with a /30 or /31 RIR block , by
the time you run out of /48s, you can either start using up the
subsequent /56s out of the first /48, as it's likely that the first /56
customer out of the /48 would have needed the /48 by that time.
As stated, that approach has really negative implications for the number
of routes you carry in your IGP.
Mark Smith wrote:
>
> Another idea would be to give each non-/48 customer the
> first /56 out of each /48. If you started out with a /30 or /31 RIR block , by
> the time you run out of /48s, you can either start using up the
> subsequent /56s out of the first /48, as it's likely that the first /56
> customer out of the /48 would have needed the /48 by that time.As stated, that approach has really negative implications for the number
of routes you carry in your IGP.
Well, for 120K+ customers, I doubt you're using an IGP for anything
much more than BGP loopbacks - and you'd have to be aggregating routes
at a higher layer in your routing hierarchy anyway, to cope with 120K
routes, regardless of what method you use to dole out /48s or /56s to
end-sites.
>
> Mark Smith wrote:
>
> >
> > Another idea would be to give each non-/48 customer the
> > first /56 out of each /48. If you started out with a /30 or /31 RIR block , by
> > the time you run out of /48s, you can either start using up the
> > subsequent /56s out of the first /48, as it's likely that the first /56
> > customer out of the /48 would have needed the /48 by that time.
>
> As stated, that approach has really negative implications for the number
> of routes you carry in your IGP.
>Well, for 120K+ customers, I doubt you're using an IGP for anything
much more than BGP loopbacks - and you'd have to be aggregating routes
at a higher layer in your routing hierarchy anyway, to cope with 120K
routes, regardless of what method you use to dole out /48s or /56s to
end-sites.
It being New Year's Day and my brain not working right yet ... you'd
probably divide your RIR block up across your PoPs, and then could use
this technique within each PoP, with the PoP being the route aggregation
boundary.
Right, so you combine the downsides of both approaches.
It doesn't work when ARIN does it:
* 24.122.32.0/20 4.68.1.166 0 0 3356 6453 11290 i
* 24.122.48.0/20 4.68.1.166 0 0 3356 6453 11290 i
* 24.122.64.0/20 4.68.1.166 0 0 3356 6453 11290 i
* 24.122.80.0/20 4.68.1.166 0 0 3356 6453 11290 i
* 24.122.96.0/20 4.68.1.166 0 0 3356 6453 11290 i
* 24.122.112.0/20 4.68.1.166 0 0 3356 6453 11290 i
* 24.122.128.0/20 4.68.1.166 0 0 3356 6453 11290 i
* 24.122.144.0/20 4.68.1.166 0 0 3356 6453 11290 i
* 24.122.160.0/20 4.68.1.166 0 0 3356 6453 11290 i
* 24.122.176.0/20 4.68.1.166 0 0 3356 6453 11290 i
* 24.122.192.0/19 4.68.1.166 0 0 3356 6453 11290 i
* 24.122.224.0/20 4.68.1.166 0 0 3356 6453 11290 i
* 24.122.240.0/20 4.68.1.166 0 0 3356 6453 11290 i
And it's unlikely to work here: for those standard size blocks, you really don't want any per-user config: you want those to be assigned automatically. But for the /48s you do need per-user config, if only that this user gets a /48. So these two block sizes can't realistically come from the same (sub-) range.
> Another idea would be to give each non-/48 customer the
> first /56 out of each /48.Right, so you combine the downsides of both approaches.
It doesn't work when ARIN does it:
Well, ARIN aren't running the Internet route tables. If they were, I'd
assume they'd force AS6453 to do the right thing and aggregate their
address space.
* 24.122.32.0/20 4.68.1.166 0 0 3356 6453
11290 i
* 24.122.48.0/20 4.68.1.166 0 0 3356 6453
11290 i
* 24.122.64.0/20 4.68.1.166 0 0 3356 6453
11290 i
* 24.122.80.0/20 4.68.1.166 0 0 3356 6453
11290 i
* 24.122.96.0/20 4.68.1.166 0 0 3356 6453
11290 i
* 24.122.112.0/20 4.68.1.166 0 0 3356 6453
11290 i
* 24.122.128.0/20 4.68.1.166 0 0 3356 6453
11290 i
* 24.122.144.0/20 4.68.1.166 0 0 3356 6453
11290 i
* 24.122.160.0/20 4.68.1.166 0 0 3356 6453
11290 i
* 24.122.176.0/20 4.68.1.166 0 0 3356 6453
11290 i
* 24.122.192.0/19 4.68.1.166 0 0 3356 6453
11290 i
* 24.122.224.0/20 4.68.1.166 0 0 3356 6453
11290 i
* 24.122.240.0/20 4.68.1.166 0 0 3356 6453
11290 iAnd it's unlikely to work here: for those standard size blocks, you
really don't want any per-user config: you want those to be assigned
automatically. But for the /48s you do need per-user config, if only
that this user gets a /48. So these two block sizes can't
realistically come from the same (sub-) range.
Maybe I'm not understanding this correctly. Are you saying that
customers who have a /56 would get dynamic ones i.e. a different one
each time they reconnect? If they've got a routed downstream topology,
with multiple routers and subnets (because of course, they've got 256
of them), I don't think customers will be very happy about having to
renumber top /56 bits if e.g. they have a DSL line sync drop out and
get a different /56.
Static assignments of /56 to customers make sense to me, and that's the
assumption I've made when suggesting the addressing scheme I proposed.
Once you go static with /56s, you may as well make it easy for both
yourself and the customer to move to a /48 that encompasses the
original /56 (or configure the whole /48 for them from the outset).
Regards,
Mark.
>
>
> > Another idea would be to give each non-/48 customer the
> > first /56 out of each /48.
>
> Right, so you combine the downsides of both approaches.
>
> It doesn't work when ARIN does it:
>Well, ARIN aren't running the Internet route tables. If they were, I'd
assume they'd force AS6453 to do the right thing and aggregate their
address space.
11920 - cogeco who I presume (just guessing) is doing this either
because they have not aggregated by mistake or have to shed load and
load-balance). I don't think teleglobe (6453) is at fault here...
out of curiousity how is this sort of thing supposed to be done in v6?
(traffic engineering given the '1 prefix per ISP' standard mantra)
> * 24.122.32.0/20 4.68.1.166 0 0 3356 6453
> 11290 iStatic assignments of /56 to customers make sense to me, and that's the
assumption I've made when suggesting the addressing scheme I proposed.
Once you go static with /56s, you may as well make it easy for both
yourself and the customer to move to a /48 that encompasses the
original /56 (or configure the whole /48 for them from the outset).
I think the assumption most folks make with DSL/cable is that
end-users get dynamic assignments from a local (to the PE device)
pool, similar to ipv4. I suppose you could do static assignments, but
there's a management payment there that might not fit within the ISP's
cost plan. I presume that something accepting PD would be smart
enough to let the end-hosts/lans know when their top 56 bits
changed... and v6 includes auto-renumbering for 'free' right? So all
solved?
(yes some of that is joking... or at the very least pointing out a gotcha)
-Chris
>
>
> >
> >
> > > Another idea would be to give each non-/48 customer the
> > > first /56 out of each /48.
> >
> > Right, so you combine the downsides of both approaches.
> >
> > It doesn't work when ARIN does it:
> >
>
> Well, ARIN aren't running the Internet route tables. If they were, I'd
> assume they'd force AS6453 to do the right thing and aggregate their
> address space.
>11920 - cogeco who I presume (just guessing) is doing this either
because they have not aggregated by mistake or have to shed load and
load-balance). I don't think teleglobe (6453) is at fault here...out of curiousity how is this sort of thing supposed to be done in v6?
(traffic engineering given the '1 prefix per ISP' standard mantra)>
> > * 24.122.32.0/20 4.68.1.166 0 0 3356 6453
> > 11290 i
>
> Static assignments of /56 to customers make sense to me, and that's the
> assumption I've made when suggesting the addressing scheme I proposed.
> Once you go static with /56s, you may as well make it easy for both
> yourself and the customer to move to a /48 that encompasses the
> original /56 (or configure the whole /48 for them from the outset).I think the assumption most folks make with DSL/cable is that
end-users get dynamic assignments from a local (to the PE device)
pool, similar to ipv4.
IPv6 is different to IPv4, don't assume things are to be done the
same. Some things are, some things can be, somethings shouldn't be.
Why was dynamic addressing for residential customers in IPv4 put in in
the first place? Occasional dial up access would be my guess as to the
root reason - it was wasting IPv4 addresses if your infrastructure
couldn't handle all of your customers dialing up at once.
Broadband has of course changed that, when you sell a broadband service,
you have to assume that the customer will be connected 24x7, so you
need as many IPv4 addresses as you've got customers - and the same will
apply for IPv6. Why do dynamic when you don't need to?
>
>
> >
> >
> > > Another idea would be to give each non-/48 customer the
> > > first /56 out of each /48.
> >
> > Right, so you combine the downsides of both approaches.
> >
> > It doesn't work when ARIN does it:
> >
>
> Well, ARIN aren't running the Internet route tables. If they were, I'd
> assume they'd force AS6453 to do the right thing and aggregate their
> address space.
>11920 - cogeco who I presume (just guessing) is doing this either
because they have not aggregated by mistake or have to shed load and
load-balance). I don't think teleglobe (6453) is at fault here...
Yeah, you're right, I missed the line wrapped AS_PATH.
out of curiousity how is this sort of thing supposed to be done in v6?
(traffic engineering given the '1 prefix per ISP' standard mantra)
AS path prepending, local preference, that kind of thing...
Static assignments of /56 to customers make sense to me, and that's the
assumption I've made when suggesting the addressing scheme I proposed.
Once you go static with /56s, you may as well make it easy for both
yourself and the customer to move to a /48 that encompasses the
original /56 (or configure the whole /48 for them from the outset).
I think the assumption most folks make with DSL/cable is that
end-users get dynamic assignments from a local (to the PE device)
pool, similar to ipv4. I suppose you could do static assignments, but
there's a management payment there that might not fit within the ISP's
cost plan.
There is no "static" and "dynamic", only points along a line... Obviously you don't want your customers to renumber every day and twice on sunday, but you also don't want to keep configurations specific for each customer. A good DHCP server will keep giving you the same address until it's forced to give that address to someone else when you're not using it, or until it loses its assignment history. I assume something similar will happen here for most customers.
I presume that something accepting PD would be smart
enough to let the end-hosts/lans know when their top 56 bits
changed...
Cisco routers can change their RAs based on a new PD prefix and even align the lifetimes so the renumbering happens very smoothly.
and v6 includes auto-renumbering for 'free' right?
Yes, that must be why IPv6-capable firewalls are still hard to find. 
Common practice with IPv4 seems to suggest that those knobs aren't sufficient in real life; people still find it necessary to carve up their aggregates and announce more-specifics in strategic directions. I would suggest that not *all* observed instances of such deaggregation are due to operator ignorance 
I imagine that the same practice will continue (is continuing?) with IPv6, to the extent that peoples' bogon filters allow it to have any practical effect.
Joe
in real life; people still find it necessary to carve up their aggregates and announce more-specifics in strategic directions. I would suggest that not *all* observed instances of such deaggregation are due to operator ignorance
There's a big difference between deaggregating a couple of bits for TE purposes and announcing 64 /24's from your /18
We need to decide what's acceptable as a community and then enforce it as a community. If someone starts announcing dozens of prefixes in v6 then they get blocked they either get blocked or they get a filter that restricts them to their covering route (or blocks them if they don't have it).
-Don
We need to decide what's acceptable as a community and then enforce it as a community. If someone starts announcing dozens of prefixes in v6 then they get blocked they either get blocked or they get a filter that restricts them to their covering route (or blocks them if they don't have it).
I really need to fix my my terminal settings- that should have read:
If someone starts announcing dozens of prefixes in v6 then they either
get blocked or they get a filter that restricts them to their covering
route (or blocks them if they don't have it).
Sorry for the grammar failure.
-Don
Donald Stahl wrote:
in real life; people still find it necessary to carve up their
aggregates and announce more-specifics in strategic directions. I
would suggest that not *all* observed instances of such deaggregation
are due to operator ignoranceThere's a big difference between deaggregating a couple of bits for TE
purposes and announcing 64 /24's from your /18We need to decide what's acceptable as a community and then enforce it
as a community. If someone starts announcing dozens of prefixes in v6
then they get blocked they either get blocked or they get a filter that
restricts them to their covering route (or blocks them if they don't
have it).
On this note: In the v6 world when multihoming, what size network block is the minimum recommended allocation? In the v4 Internet, most major networks I've seen do not accept anything longer than /24 and this is what is allocated to customers with their own AS when multihoming regardless of the usage of the /24. I'm just curious if this is currently outlined somewhere already as what was decided. Are we going to see /64's, /56's or /48's polluting the v6 routing table just as /24's are today on the v4 table? I understand most of that pollution is not because of multihoming, but rather TE or negligence/lack of clue. With the advent of 32 bit ASN's, this could possibly become a concern however... that and people trying to do TE with their v6 space as they did with v4. I agree with the above reply that this needs to be ironed out as a community and was curious how multihoming customer networks fit into this equation.
I'm glad to see more people are starting to look at this issue. If you are just now beginning to look into the IPv6 Multihoming issue I would start with reading a few strings on IETF, NANOG and ARIN mail lists and the following document posted 2 years ago at: http://www.nro.org/documents/pdf/MultihomeIPv6procon.pdf
Decisions need to be made soon and all kinds of policy can effect that. Their are dueling issues at hand on this matter and we need to find a balance. Traffic Engineering and Multihoming is an Engineering requirement. Not exploding the tables is also a requirement. Right now policy only inadvertently supports PI to be used for Multihoming and policy inadvertently does not support TE or Multihoming. Not permitting TE or Multihoming on large networks is not going to be accepted by the large networks as an answer. So it would be a "good thing" if our community could work out a balance that permits TE and Multihoming on a managed scale. Otherwise those networks will just start doing whatever they want or need.
Cheers!
Marla
Broadband has of course changed that, when you sell a broadband service,
you have to assume that the customer will be connected 24x7, so you
need as many IPv4 addresses as you've got customers - and the same will
apply for IPv6. Why do dynamic when you don't need to?
There are several other arguments for dynamic addresses, for instance:
- Dynamic addresses often make it easier to perform bulk moves of large
numbers of customers.
- Dynamic addresses for residential customers is a way to justify higher
cost (and profit) for a "business" type service with static addresses.
Given that many service providers find dynamic addresses for residential
customers extremely convenient, *independent of the number of available
addresses*, is there any reason to believe this will change with IPv6?
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
> out of curiousity how is this sort of thing supposed to be done in v6?
> (traffic engineering given the '1 prefix per ISP' standard mantra)AS path prepending, local preference, that kind of thing...
there is only one prefix so this amounts to, essentially, on/off for a
peer/transit/customer. (you can distance yourself from all of a
provider directly connected or none...)
>> Static assignments of /56 to customers make sense to me, and that's
>> the
>> assumption I've made when suggesting the addressing scheme I
>> proposed.
>> Once you go static with /56s, you may as well make it easy for both
>> yourself and the customer to move to a /48 that encompasses the
>> original /56 (or configure the whole /48 for them from the outset).> I think the assumption most folks make with DSL/cable is that
> end-users get dynamic assignments from a local (to the PE device)
> pool, similar to ipv4. I suppose you could do static assignments, but
> there's a management payment there that might not fit within the ISP's
> cost plan.There is no "static" and "dynamic", only points along a line...
Obviously you don't want your customers to renumber every day and
twice on sunday, but you also don't want to keep configurations
specific for each customer. A good DHCP server will keep giving you
the same address until it's forced to give that address to someone
else when you're not using it, or until it loses its assignment
history. I assume something similar will happen here for most customers.
So, sure a dhcp server can do some of the work, but you may end up
with situations where customerX moves from pop1 to pop2 and if you
aggragated on pop boundaries you'll have to plan on leakages across
the boundaries, bloating your IGP some... or plan on the customer
being 'broken' until they call and get new address space. With a
'dynamic' (each login you get a randomly assigned PD from the local
pool) you'd avoid this and avoid the hassles when customerX leaves and
you all of a sudden have to deconflict customerX from
new-customer-Z... Cleanup classically has been a difficult art to
master 
(costly)
> I presume that something accepting PD would be smart
> enough to let the end-hosts/lans know when their top 56 bits
> changed...Cisco routers can change their RAs based on a new PD prefix and even
align the lifetimes so the renumbering happens very smoothly.
well see, we are almost half way there good think cisco bought
linksys, do linksys devices do v6? and PD and RA?
> and v6 includes auto-renumbering for 'free' right?
Yes, that must be why IPv6-capable firewalls are still hard to
find.
define 'capable'
I think this goes back to my point about DHCP, today there is a
business practice and set of business requirements that work for a
host of reasons. Expecting that in v6 these requirements will
evaporate is not wise. There will have to be some useful TE knobs, I
think the operations community would probably like to see those knobs
NOT be 'deaggragate' so what other options are there for someone with
a single prefix (especially when that prefix is very large).
-chris