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
michael.dillon@bt.com 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. 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
On Thu, 27 Dec 2007 19:56:19 -0000 <michael.dillon@bt.com> 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.
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. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
participants (3)
-
Jeroen Massar -
Mark Smith -
michael.dillon＠bt.com