[ipv6-wg] Draft Agenda (v1) for ipv6 wg RIPE51

Hello all,

About the /32's; they are announced on purpose. The reason is that we
have had problems with some ISP's BGP filters that are set to a maximum
size of /32. As a result did not our IPv6 customers get connectivity via
ISP's using the /32 size filters. Maybe this is a problem only we run in
to being one of the first using a very large prefix. However, the BGP
filters may be updated by now so we can stop announcing the /32's. 

Please note that this has been a temporary work around to maintain
connectivity for our customers. We also have old prefixes that we are
about to return to RIPE (2001:06C0::/35), but not yet had time to shout
down (affects many customers and links). It is of-cause the policy of
the TeliaSonera group to normally only announce one prefix. 

Any comments to this are most welcome.


Best regards   ///   Mattias Lignell


--------------------------------------------------------------
               Mattias Lignell
        TeliaSonera Sweden, IP-Networks

Phone:         +46 8 713 3706
Mobile:        +46 70 595 9068
Fax:           +46 70 615 6245
Email:         mattias.lignell at teliasonera.com
Address:       Vitsandsgatan 9, House-D, 123 86 Farsta, SWEDEN
ICQ UIN:       18690075
--------------------------------------------------------------

> -------------------------------------------------------------
> ----- Original Message -----
> From: "Jeroen Massar" <jeroen at unfix.org>
> To: "Gert Doering" <gert at space.net>; "David Kessens" 
> <david.kessens at nokia.com>
> Cc: "Amar Andersson" <amar at telia.net>; <ipv6-wg at ripe.net>
> Sent: Friday, September 30, 2005 3:06 PM
> Subject: Re: [ipv6-wg] Draft Agenda (v1) for ipv6 wg RIPE51
> 
> 
On Thu, 2005-09-29 at 20:46 -0700, David Kessens wrote:

One discussion point you might want to raise:
 - what are people going to do with 6bone address space as per 6/6/6 ?
   - filter it?
   - keep it going?
   - warn people?

In january I will send out a note to all the folks still announcing
6bone prefixes to remind them that they should be shutting it down
per 6/6/6. There doesn't seem to be a large movement in doing so yet...

> C. Discussion on:
>    Global IPv6 routing table status
>    (Gert Doering)

Maybe something related might be noted here, in the global routing
tables I've seen for instance, just a 'random' targetted pick.
http://www.sixxs.net/tools/grh/lg/?find=2001:2000::/20

[Notez bien: the question here is about what is going to become the
common policy and what is going to happen to the ipv6 routing, it is not
to 'attack' or critize an ISP on what they are doing]

2001:2000::/20 announced by AS1299 (TELIANET)
2001:2040::/32              AS3301 (TELIA-SWEDEN)
2001:2060::/32              AS1759 (SONERA-TRANSIT-AS)

No route6 for these 3 prefixes and no inet6nums exist for the the
two /32's. Which leads me to a couple of questions:

- is it mandatory to register route6's and inet6num's or is it
just 'being nice'

- is the trend going to be that >/32's will be announced as
separate /32's? This of course means that the ISP can be found
under one block but still affects the number of routes in the
routing table. One could filter the smaller ones if the parent
route is present. The idea of minimizing routing table size (yes
that is not an issue now, but behold the future) is totally gone
when ISP's will do this. I do understand why: to make the branches
independant and attract the traffic as local as possible.
On the otherside there are also ISP's simply requesting multiple
separate /32's from the various RIR's. eg UUNet:
2001:0600::/32 - Europe
2001:4440::/32 - Hongkong
2001:4441::/32 - Australia
2001:4442::/32 - Japan
2001:0588::/32 - South Africa

(I am ignoring the 6bone block they still have, with 1 other
already returned, as that one will disappear anyway)
The question in case of this setup is, why didn't they get 1 block?

The generic question: what is the correct plan for these setups?

> D. Report(s) about *actual* v6 traffic volume as compared to v4?
>    *what's real* out there, not what's on powerpoint?
>    (input from the audience)

http://www.sixxs.net/misc/traffic/ :)

Not much, but it is a bit and for the moment declining a bit weirdly
enough.

<SNIP>
>    For example, address fragmentation, a key problem in IPv4, degrades
>    address lookup performance in routers. Thus, a well-designed
>    address allocation policy needs to minimise fragmentation while
>    using the address space efficiently.

See my related note above.

Greets,
 Jeroen