During all this discussion about v6 and home networks, has anyone had a
look at ARIN's IPv6 wiki, in particular at the IPv6 Addressing Plans
page?
http://www.getipv6.info/index.php/IPv6_Addressing_Plans
Although it still has the original note about being a bit of a strawman
proposal it has incorporated a lot of input from earlier discussions on
the NANOG list and the IETF list. Item 12 on that page applies directly
to home networks:
12. All customers get one /48 unless they can show that they need more
than 65k subnets.
-Host count is irrelevant.
-Do not assign from PoP aggregates
-Carry customer networks in iBGP
-Aggregate only in eBGP
-If you have lots of consumer customers you may want to assign /56s
to private residence sites.
Aside from snarky remarks about the IETF, does anyone have anything
substantial to contribute that isn't already on that page? If you want
to you can use the "discussion" tab on the wiki to comment.
--Michael Dillon
[..]
-Do not assign from PoP aggregates
What do you mean with the above? If I understand the line correctly,
then I disagree with it.
IMHO generally ones network infrastructure is pretty aggregated
internally already as the physical structure is most likely also a
star/bus topology which fans out towards the endusers, while the core is
where you connect to the Internet. When you have 'home users' and even
residential users they generally get connected to a PoP for a certain
neighborhood. Generally these users won't move around the country. As
such, just give the PoP a /40 or whatever you need to serve the users
from that site. This keeps the number of internal routes low. Now if you
have a well paying customer who wants to take their /48 along, just
announce the more specific in iBGP. Of course never announce a de-agg of
the allocation you received into eBGP.
Or did you mean something different?
Greets,
Jeroen
> -Do not assign from PoP aggregates
What do you mean with the above? If I understand the line
correctly, then I disagree with it.
I don't mean anything by that, I just quoted it from the
wiki page. If you disgree then you should add something
to the page. I have a vague memory that this advice was
given in a NANOG presentation on IPv6 but it would not
surprise me if it was a case where one size does not fit all.
PoP aggregates sounds like a good idea to me, but given the
need to meet a certain HD ratio in order to get a larger
RIR allocation, it might be risky for an ISP to do that.
This is one area where the operator environment differs
from the enterprise.
--Michael Dillon
> > -Do not assign from PoP aggregates
>
> What do you mean with the above? If I understand the line
> correctly, then I disagree with it.
I don't mean anything by that, I just quoted it from the
wiki page. If you disgree then you should add something
to the page.
Probably even better, raise the point on the V6OPS working group mailing
list, so that it can be included in the "IPv6 Unicast Address
Assignment Considerations" Internet Draft/future RFC. Addressing
options, and the pros and cons of them are what the draft is about.
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addcon-07.txt
I have a vague memory that this advice was
given in a NANOG presentation on IPv6 but it would not
surprise me if it was a case where one size does not fit all.
PoP aggregates sounds like a good idea to me, but given the
need to meet a certain HD ratio in order to get a larger
RIR allocation, it might be risky for an ISP to do that.
This is one area where the operator environment differs
from the enterprise.
--Michael Dillon
Regards,
Mark.
William Herrin wrote:
-Do not assign from PoP aggregates
What do you mean with the above? If I understand the line correctly,
then I disagree with it.
Jeroen,
If I remember right, this came from a discussion on the ARIN PPML
list. I don't clearly remember the discussion, so my apologies in
advance if I get some of it wrong.
During discussion and analysis, allocation of addresses by POP was
found to be incompatible with a couple goals deemed more important.
The general consensus was that you should establish areas consisting
of multiple POPs and aggregate by area instead.
Area/PoP, that is a just a way to describe a route into a certain
direction. I guess the wording should be changed to resolve the issue I
have with it, eg "try to aggregate per area/PoP where possible to keep
IGP routes low"
However, ARIN is not
in the business of recommending routing best practices so the
recommendation was narrowed to just "don't aggregate by POP" meaning
"don't fine-tune your aggregation all the way down to the POP level;
stop somewhere above it."
Then put that in there, sounds more logical than the "Don't aggregate"
line that is in there now.
As for the rest of your mail, I would suggest putting it in the Wiki as
an explanation and referencing it from the above point as it clarifies a
number of things that people will not have to time to go lookup in the
mailinglists.
Greets,
Jeroen