[ipv6-wg at ripe.net] RE: /48 micro allocations for v6 root servers, was: national security

hi 

The ranges for APNIC (IPv4, IPv6 and ASNs) are documented at:

http://www.apnic.net/db/ranges.html

See the 'Notes' section for details of the 'special' ranges.


cheers,
Anne

_____________________________________________________________________
Anne Lord, Manager, Policy Liaison                  <anne at apnic.net>
Asia Pacific Network Information Centre       phone: +61 7 3858 3100
http://www.apnic.net                            fax: +61 7 3858 3199
----------------------------------------------------------------------

On Tue, 9 Dec 2003, David Kessens wrote:

> 
> Jeroen,
> 
> Would you be willing to put a presentation together regarding all the
> 'special' ranges of addresses that you have found/know about so that
> we can have a discussion regarding this topic on the next RIPE meeting?
> 
> Thanks,
> 
> David K.
> PS The RIPE meeting is coming up in January so I am very much interested in
>    input for agenda items!
> ---
> 
> On Tue, Dec 09, 2003 at 12:20:20AM +0100, Jeroen Massar wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > 
> > Gert Doering [mailto:gert at space.net] wrote:
> > 
> > > 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.
> > 
> > Some ISP's do it, most don't.
> > 
> > Btw CH-SUNRISE-20031124 = 2001:1700::/27, so Libertel isn't the
> > biggest girl on the block anymore with their /31 :)
> > 
> > > 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.
> > 
> > Indeed. And yes there are ISP's announcing /128's etc.
> > And private ASN's for that matter or even using them as transit.
> > 
> > <SNIP>
> > 
> > > As you cite my page, you will also know that it does not make a specific
> > > recommendation on the subject of "filtering things between /35 and /48"...
> > 
> > Yups and I fully support that argument.
> > 
> > If it was done we would currently see 413 prefixes, those are the
> > 'allocated' prefixes that are getting announced.
> > In GRH each of the ~30 peers have an average of 459 prefixes.
> > Checking just know, the highest number of prefixes send to GRH
> > was 515 prefixes, which is far from the 20k or even 30k if all
> > the ASN's would announce 1 IPv6 prefix.
> > 
> > At the moment that is certainly no problem and it shouldn't be
> > for years to come, unless IPv6 really takes off. Google/Doom3 IPv6 anyone?
> > 
> > The biggest advantage that IPv6 already has is that a single
> > ISP already gets enough space, thus it doesn't need to 
> > 
> > Iljitsch van Beijnum [mailto:iljitsch at muada.com] wrote:
> > 
> > > On 8-dec-03, at 22:01, 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)
> > > 
> > > So how are ISPs supposed to know what the allocation size for a 
> > > particular prefix is? This type of filtering only works if the filter 
> > > list is relatively short and pretty much never changes. Anything else 
> > > and the cure is worse than the disease.
> > 
> > The proposed "Redistribution of Cooperative Filtering Information" draft
> > could help out there which allows one to redistribute 'good prefix' lists.
> > See https://www1.ietf.org/mail-archive/working-groups/idr/current/msg00201.html
> > for the draft or http://arneill-py.sacramento.ca.us/redisfilter.ppt for
> > the presentation given in Minneapolis.
> > 
> > Without that or a similar system, it would be a pain indeed.
> > That's why I pointed to Gert's page which has a better and
> > currently working solution.
> > 
> > <SNIP>
> > 
> > > > Currently the !3! IX blocks (2001:7f8::/32 + 2001:504::/32 + 
> > > > 2001:7fa::/32)
> > > > are seen being announced in pieces too. Maybe these IX blocks, which
> > > > are common already could be used for assigning 'critical infra' from?
> > >
> > > Note that announcing the actual prefix for an internet exchange subnet 
> > > tickles an undesirable BGP feature in places where the prefix isn't 
> > > filtered, so these prefixes are best not announced.
> > 
> > As far as I can see with the GRH tools etc, all the prefixes
> > that are allocated as "IX Prefixes" and those that are in use
> > are currently visible worldwide.
> > 
> > > The allocations seem to be /48s and not /64s though, so in
> > > practice this shouldn't be a problem but still no reason why
> > > these should be globally visible.
> > 
> > The only reason I heared so far is so that people in Tokio can
> > ping the IX interface in London or a similar kind of scenario.
> > They argue that it is handy for debugging. My take is that if
> > it isn't your network, you can't fix it either, so if a traceroute
> > ends on that box, contact them, they can really figure it out.
> > 
> > > Root nameservers are a very different story of course...
> > 
> > A /32 contains 65k /48's, so these IX blocks could provide for
> > enough /48's for 65k IX's, thus unless that switch at the back
> > of my desk, which connects 'neighbours' too is to be called an
> > IX, because they have a linux router and me too and they speak
> > BGP is going to be called an IX it shouldn't be a problem if
> > the same block is used for 26? and maybe 3 tld servers per country.
> > 
> > At least everybody will know that that /32 will have more specifics.
> > 
> > Greets,
> >  Jeroen
> > 
> > -----BEGIN PGP SIGNATURE-----
> > Version: Unfix PGP for Outlook Alpha 13 Int.
> > Comment: Jeroen Massar / jeroen at unfix.org / http://unfix.org/~jeroen/
> > 
> > iQA/AwUBP9UHMymqKFIzPnwjEQLiLwCgta1mOkrixvXcZD8mTLheePv9ERYAn3GK
> > Rt2Hp+dk8HVBDuFaub0lf6Rt
> > =OqJO
> > -----END PGP SIGNATURE-----
>