Hay, On Mon, Dec 08, 2003 at 10:16:03PM +0100, Gert Doering wrote:
Hi,
On Mon, Dec 08, 2003 at 10:01:53PM +0100, Jeroen Massar wrote:
There are currently quite some ISP's who filter anything >/35. Generally ISP's should be filtering on allocation boundaries. Thus if a certain prefix is allocated as a /32, they should not be accepting anything smaller (/33, /34 etc)
There is no commonly agreed-upon best practice for this yet.
We do *not* suppress more-specifics from those address blocks, as we think it's a legitimate wish for certain networks to be multihomed, and currently there is no other solution than to go for the pragmatic approach, and just announce a /40 or even /48.
I agree that things that are more specific than a /48 should not be out there.
Well I think everyone agrees, that Prefixes longer than /48 should definately not show up in the global routing table, simlar to prefixes longer than /24 in the IPv4 world. I even could somehow understand, that we might not want /48s, i.e. "end-sites" to be in the global BGP table. But what i really oppose is, that there should or must be filters on RIR Allocation boundaries, i.e. /32's and shorter. _At_least_ "NLA" space (yes, i know, NLA-acronym is depreciated) must be routable and accepted everywhere, for example Sub-Allocations to smaller ISPs or non-commarcial organisations who do not want to get a RIR membership or simply can't afford it (there is no low-cost membership for non-commercial organisations available at any RIR AFAICS). Otherwise this would be a huge discrimination in my eyes, which cannot be even in today's totally commercialized Internet. Consider the other options: - People with money would start making things up to get a RIR allocation just like they do nowerdays some times to get portable address space ("PI" Assignments or a PA Block of a /20 or something) Everyone can get a RIR member, even end-users. They now get an IPv4 Allocation as soon as they are member (an can show some need for IP-space). Current IPv6 policy forbids "end-sites" to get an Allocation, but why the difference? Even if this part stays in the policy, people will start to make up things, "we have 100 employees and 100 contractors which we connect in their home-office and assign them /48s" .. and they most likely will have their /32 to announce globally. On the other hand, organisations who don't have the money will be completely discriminated. - Rather focus on the "one (or few) Prefixes per AS" part As already stated within this thread, IPv6 fixes the biggest problem by design - many many many Prefixes per AS will be no issue. Now if we also consider that many many many customers (end-sites) who have PI space, ASNs, BGP Multihoming just because there was no other solution in the IPv4 world back some years at all... Most _are_ happy with whatever IPv6 Multihoming solution other than BGP-Multihoming is out there, for example multiple lines to the same ISPs, Fallback-Tunnels or whatever the other IPv6 multihoming draft was about... Not everyone who does full BGP multihoming today does really need it. BUT - noone who really wants "real" Multihoming like it is done today by announcing a unique prefix, should be denied that. This just won't work in the real world, because some customers need this, and some non-commercial organisations rather want to invest in their infrastructure than in a RIR membership when they only have whatever, 200 members and are happy with a /40. The routers do not care if a prefix is a /32 or a /40 or even a /48. No much difference, the amount of Prefixes is the problem. So, probably we should rethink the global IPv6 Policy anyways. As Gert said - this lack of IPv6 Multihoming possibility with the current Policy and filters just hinders IPv6 deployment at the moment. "I can't do this in IPv6? On sorry, then i don't see why i need it when my connectivity gets worse than with IPv4" BTW: I announce several /40s and don't really see routing problems up to now. I really thought, all those folks who fought the holy war for strict filters were long gone? Am I wrong? -- ========================================================================== = Sascha 'master' Lenz SL277-RIPE slz@s-lz.net = = = = You can rent this space for $$$ * PGP public Key on demand * = ==========================================================================