[6bone] RE: [ipv6-wg@ripe.net] Update on IPv6 filter recommendation

Gert Doering gert@space.net
Mon, 19 May 2003 13:09:07 +0200


Hi,

ok, now to followup on this:

On Tue, May 13, 2003 at 09:13:04PM -0700, Michel Py wrote:
> > I have just added an update to the "strict" filter list of
> > my IPv6 filter list recommendations on
> > http://www.space.net/~gert/RIPE/ipv6-filters.html
[..]
> > ipv6 prefix-list ipv6-ebgp-strict permit 2001:500::/32 ge 48 le 48
> 
> It would be interesting to have more refinement here. What I mean is
> that I would be open to allow a /48 that contains a root server but not
> a /48 that serves an IXP. More details/specifics to what is inside
> 2001:500::/32 would be appreciated.

Unfortunately the ARIN database is too broken to permit queries like
"tell me everything inside 2001:500::/32" (the RIPE and APNIC databases
do this just fine).  So you'll have to check them manually - tedious - 
or check 

     http://www.arin.net/registration/ipv6/micro_alloc.html.

Unfortunately, the URL only lists "those prefixes are allocated to 
IXPs" (from 2001:504::/32) and "those are for critical infrastructure"
(from 2001:500::/32), but without specifying for *what* parts of the
infrastructure...

Checking the allocations individually with "whois", I find:

  2001:500::/48  --> ISC
  2001:500:1::/48  --> US Army Research/H-ROOT-NET
  2001:500:2::/48  --> "Cogent Communications"
  2001:500:3::/48  --> ICANN/L-ROOT-NET

The docs on http://www.root-servers.org/ imply that 2001:500::/48 is also
used as root name server network (F), and most likely the network for
Cogent Communications will be used for (C).

> > ipv6 prefix-list ipv6-ebgp-strict permit 2001::/16 ge 35 le 35
> 
> I think this could be refined too. The range where /35s were originally
> allocated from is much smaller than 2001::/16.

Good point.  I will try to figure out what /35s are still out there 
and adapt the (strict) filter accordingly.

> > ipv6 prefix-list ipv6-ebgp-strict permit 2001::/16 ge 24 le 32
> 
> This could also be refined. Not all 2001::/16 has been delegated to
> RIRs. ARIN got a block, RIPE got a block, APNIC got a block, but there
> still is some undelegated space. The drawback of refining to that level
> is that it will inevitably induce a situation similar to 69/8 and will
> require maintenance, but the other side of that coin is that it would
> prevent people from hijacking prefixes from undelegated space.

Someone else already commented on this.  As the address space is pretty
sparsely populated, people still would be able to hijack addresses 
(like "2001:609::/32", which is adjacent to our /32, but right now just
unallocated).

So I'm not sure whether the drawbacks you mention are not really worth 
the gains.

(Also, the IPv6 address allocation strategy IANA -> RIRs is currently
so messy that quite frequent updates would be needed)

> As an example and please correct me if wrong in the address I picked
> because it's all from memory, if I hijack and announce 2001:FEED::/32
> that would pass your filter but this prefix can't be assigned to anybody
> now as it is not part of a larger block that has been delegated to a
> RIR, so it must be a hijack.

Yes, this is true.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  54495  (54267)

SpaceNet AG                 Mail: netmaster@Space.Net
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299