On 5-jul-2006, at 18:12, Azinger, Marla wrote:
Yes, that's true. But a billion is still a lot closer to somethingreasonable than another nearly six orders of magnitude. And the crucial difference is that there is little chance of the the full ::/ 3 space being deaggregated into individual /32s, while leaking of significant numbers of "private" /48s into the global routing tableis something I fully expect to happen based on experiences with IPv4.<<<<<<<<<
I know we had/have prefix leaks with V4, but doesn't anyone think we as a community have learned the value in not leaking by now?
Sure, but that doesn't mean it can never again happen.
If we have lots of offenders like this, are they large Upstream providers? Or are they small End Users or ISP's that may not ever renumber into V6? I am curiouse how much we think this V4 problem really will be with V6.
Currently, there is no mass deployment of IPv6, so even if at some point an AS leaked all its internal routes, this would probably not have been all that many at this point.
I'm not as worried as I was with IPv4, because I think we really did learn something, but I would still not feel comfortable allowing /48s without limitation. As I wrote before, a mechanism where routes that are allowed out on purpose are tagged so that they can be recognized as such could make all the difference here. In certain setups, it's very easy to make a mistake that allows routes through that are supposed to be filtered out as allowing routes through is the default. But inappropriately tagging routes with a BGP community by accident is much harder because the default is not having the tag.
(I'm also VERY much annoyed by the fact that the RIRs say you can filter on /32 (see quote yesterday) but give out /48s at the same time, I've brought this up YEARS ago and no action so far. The fact that each RIR reinvents the wheel with little global coordination but we're dealing with a GLOBAL routing table and not several regional ones doesn't help.)<
I understand this frustration. However, the policy put forward so far has been done without any guidance from IETF to be taken into consideration.
I'm not so sure; filtering on /32 is pretty much on par with the 6bone routing guidelines that came from the IETF. The document I referred to was also orignally adopted by all the RIRs and IANA (which is now part of ICANN but used to be much closer aligned with the IETF).
With some written guidance to consider it is very possible policy can be adjusted and new policy can be made to follow the guidance.
If we can reach consensus on such a policy I'm sure that in due course the RIRs would add pointers to it. It would be helpful if you (and others) could explain what it is you want to accomplish, then we can see if it's possible to come up with something creative that addresses this while avoiding the issues that were mentioned earlier.