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(_at_)s-lz(_dot_)net
=
= =
= You can rent this space for $$$ * PGP public Key on demand * =
==========================================================================