Hi, we are planning to offer IPv6 connectivity to our xDSL and FTTH customer base via IPv6-6RD. (see <http://tools.ietf.org/html/draft-townsley-ipv6-6rd-01> or for a working implementation Free's presentation at RIPE-58: <http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/ipv6-free.pdf>). We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet). The IPRA now isn't sure how to proceed and after consultation with the Policy Development Manager asked me to pose the question to the community at large. What do you think, should RIPE NCC allocate larger than /32 blocks to LIRs for cases like this and not only based on the number of end-customers? Cheers Jan Swisscom IP-Plus - AS3303
Hi Jan,
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
In draft-townsley-ipv6-6rd-01 the following example is given: This example show how the 6rd prefix is created based on a /32 IPv6 prefix with a private IPv4 address were the first octet is "compressed" out: SP prefix: 2001:0DB8::/32 6rd IPv4 prefix: 10.0.0.0/8 6rd router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 With this scheme you can still give every customer out of an IPv4 /8 an IPv6 /56 subnet. If you have an IPv4 /16 with customers you could "compress" so that every customer has an IPv6 /48. And if you have more than 65k customers you should have no problem with getting a bigger IPv6 allocation. Because the IPRA refuses to give you more addresses based on your customer base I suspect that you have less than 65k customers. With a smart IPv4 <--> IPv6-RD mapping that should not be a problem for IPv6-RD. Can you give some extra background information that explains why you need more than a /32? - Sander
Hi Sander
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
In draft-townsley-ipv6-6rd-01 the following example is given:
This example show how the 6rd prefix is created based on a /32 IPv6 prefix with a private IPv4 address were the first octet is "compressed" out: SP prefix: 2001:0DB8::/32 6rd IPv4 prefix: 10.0.0.0/8 6rd router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
With this scheme you can still give every customer out of an IPv4 /8 an IPv6 /56 subnet. If you have an IPv4 /16 with customers you could "compress" so that every customer has an IPv6 /48. And if you have more than 65k customers you should have no problem with getting a bigger IPv6 allocation.
Because the IPRA refuses to give you more addresses based on your customer base I suspect that you have less than 65k customers. With a smart IPv4 <--> IPv6-RD mapping that should not be a problem for IPv6-RD.
Can you give some extra background information that explains why you need more than a /32?
we have much more than 65k customers, with IPv4 addresses dispersed in many different /8 We therefore cannot easily compress the IPv4 address and want to use the whole 32bit. However, we plan to allocate only a /60 subnet to the end customer. This results in a request for a /28 Jan
Hi Sander he didn't refuse it, yet. He asked me to get to the wg because he was unsure if this scenario is in the spirit of the RIPE policies. Cheers Jan Am 25.11.2009 um 17:35 schrieb Sander Steffann:
Hi Jan,
With that many customers getting more than a /32 shouldn't be any problem... Why did the IPRA refuse it? This might just be a misunderstanding somewhere...
Sander
Jan Boogman <boogman@ip-plus.net>schreef:
Hi Sander
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
In draft-townsley-ipv6-6rd-01 the following example is given:
This example show how the 6rd prefix is created based on a /32 IPv6 prefix with a private IPv4 address were the first octet is "compressed" out: SP prefix: 2001:0DB8::/32 6rd IPv4 prefix: 10.0.0.0/8 6rd router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
With this scheme you can still give every customer out of an IPv4 /8 an IPv6 /56 subnet. If you have an IPv4 /16 with customers you could "compress" so that every customer has an IPv6 /48. And if you have more than 65k customers you should have no problem with getting a bigger IPv6 allocation.
Because the IPRA refuses to give you more addresses based on your customer base I suspect that you have less than 65k customers. With a smart IPv4 <--> IPv6-RD mapping that should not be a problem for IPv6-RD.
Can you give some extra background information that explains why you need more than a /32?
we have much more than 65k customers, with IPv4 addresses dispersed in many different /8 We therefore cannot easily compress the IPv4 address and want to use the whole 32bit. However, we plan to allocate only a /60 subnet to the end customer. This results in a request for a /28
Jan
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
In draft-townsley-ipv6-6rd-01 the following example is given:
This example show how the 6rd prefix is created based on a /32 IPv6
Hi Jan, I see the problem you have trying to get a fragmented address space such as yours play nicely with 6rd. However, given the dimension of your network (some quick digging gave me a figure of roughly a million v4 addresses) do you think that asking for 4 billion /60 prefixes is a good idea? To borrow somebody else's words here, that doesn't scale. Here's another idea. You've got ~135 prefixes announced, but if I aggregate those to the nearest /16 (remember, if there are blocks of space that aren't yours in between it doesn't matter for 6rd because the ipv6 sp prefix will be different anyway) you end up with a (sparsely filled) block or 30. From there on it's a matter of a simple mapping to about 21 bits of uniquely identified addresses, removing an easy 3 orders of magnitude from your address requirement. All of a sudden, you no longer need to have a /28 for just migrating your v4 customers but a mere /39, giving you tons of space for deployment of new and exciting IPv6 services for years even with the standard /32 allocation. Since we're talking about drafts, not standards, perhaps something like this should be taken in consideration reviewing a new version of the draft. We've wasted enough IPv6 space in standards already, IMNSHO. Best, Remco -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jan Boogman Sent: woensdag 25 november 2009 17:13 To: Sander Steffann Cc: address-policy-wg@ripe.net; ipv6-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD Hi Sander prefix
with a private IPv4 address were the first octet is "compressed" out: SP prefix: 2001:0DB8::/32 6rd IPv4 prefix: 10.0.0.0/8 6rd router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
With this scheme you can still give every customer out of an IPv4 /8 an IPv6 /56 subnet. If you have an IPv4 /16 with customers you could "compress" so that every customer has an IPv6 /48. And if you have more than 65k customers you should have no problem with getting a bigger IPv6 allocation.
Because the IPRA refuses to give you more addresses based on your
customer
base I suspect that you have less than 65k customers. With a smart IPv4 <--> IPv6-RD mapping that should not be a problem for IPv6-RD.
Can you give some extra background information that explains why you need more than a /32?
we have much more than 65k customers, with IPv4 addresses dispersed in many different /8 We therefore cannot easily compress the IPv4 address and want to use the whole 32bit. However, we plan to allocate only a /60 subnet to the end customer. This results in a request for a /28 Jan This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
Hi Remco, Either you or me have a wrong understanding of how 6RD works. I understand it like that some high order bits of the IPv4 prefixes need to match so that you can aggregate. How many high order bits of IP addresses of which the first octet is <128 do you see matching with an octet being >=128? Cheers, Florian 2009/11/25 Remco van Mook <Remco.vanMook@eu.equinix.com>:
Hi Jan,
I see the problem you have trying to get a fragmented address space such as yours play nicely with 6rd. However, given the dimension of your network (some quick digging gave me a figure of roughly a million v4 addresses) do you think that asking for 4 billion /60 prefixes is a good idea? To borrow somebody else's words here, that doesn't scale.
Here's another idea. You've got ~135 prefixes announced, but if I aggregate those to the nearest /16 (remember, if there are blocks of space that aren't yours in between it doesn't matter for 6rd because the ipv6 sp prefix will be different anyway) you end up with a (sparsely filled) block or 30. From there on it's a matter of a simple mapping to about 21 bits of uniquely identified addresses, removing an easy 3 orders of magnitude from your address requirement. All of a sudden, you no longer need to have a /28 for just migrating your v4 customers but a mere /39, giving you tons of space for deployment of new and exciting IPv6 services for years even with the standard /32 allocation.
Since we're talking about drafts, not standards, perhaps something like this should be taken in consideration reviewing a new version of the draft. We've wasted enough IPv6 space in standards already, IMNSHO.
Best,
Remco
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jan Boogman Sent: woensdag 25 november 2009 17:13 To: Sander Steffann Cc: address-policy-wg@ripe.net; ipv6-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD
Hi Sander
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
In draft-townsley-ipv6-6rd-01 the following example is given:
This example show how the 6rd prefix is created based on a /32 IPv6 prefix with a private IPv4 address were the first octet is "compressed" out: SP prefix: 2001:0DB8::/32 6rd IPv4 prefix: 10.0.0.0/8 6rd router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
With this scheme you can still give every customer out of an IPv4 /8 an IPv6 /56 subnet. If you have an IPv4 /16 with customers you could "compress" so that every customer has an IPv6 /48. And if you have more than 65k customers you should have no problem with getting a bigger IPv6 allocation.
Because the IPRA refuses to give you more addresses based on your
customer
base I suspect that you have less than 65k customers. With a smart IPv4 <--> IPv6-RD mapping that should not be a problem for IPv6-RD.
Can you give some extra background information that explains why you need more than a /32?
we have much more than 65k customers, with IPv4 addresses dispersed in many different /8 We therefore cannot easily compress the IPv4 address and want to use the whole 32bit. However, we plan to allocate only a /60 subnet to the end customer. This results in a request for a /28
Jan
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
Hi Florian It's entirely possible my understanding of how 6rd should work is wrong, but at the same time we must realize it's a draft, not a standard and as far as I know nobody has implemented it anywhere yet. But I do see a few assumptions I don't like: - You can only do 6rd once in an entire network - It only works for IPv4 /8s and larger - It only works for IPv6 /32s and larger I don't see why it wouldn't work for multiple instances and arbitrary prefix sizes for both IPv4 and IPv6. So, taking the example from Mark Townsley's draft: SP prefix: 2001:0DB8::/32 6rd IPv4 prefix: 10.0.0.0/8 6rd router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 I don't see why this wouldn't work with a /44 SP prefix, a /16 of IPv4 and /60 6rd site IPv6 prefixes. Or any other CIDR-size, for that matter. Use multiple instances of 6rd of whatever size fits best (they don't even need to be identical) to cover whatever set of allocations you've received over the last 15 years. In Jan's case these instances together would easily fit in a /39 of space; even extending the site IPv6 prefix to a /56 wouldn't extend this beyond a /35 requirement. If a single 6rd instance is accepted as a rule the end result of that will be that every ISP in the world with non-contiguous allocations will be asking for a /24 next, knowing full well that they're only going to use 0,1% of the network side of that space, ever. Remco -----Original Message----- From: Florian Frotzler [mailto:florian@frotzler.priv.at] Sent: donderdag 26 november 2009 1:08 To: Remco van Mook Cc: Jan Boogman; Sander Steffann; address-policy-wg@ripe.net; ipv6-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD Hi Remco, Either you or me have a wrong understanding of how 6RD works. I understand it like that some high order bits of the IPv4 prefixes need to match so that you can aggregate. How many high order bits of IP addresses of which the first octet is <128 do you see matching with an octet being >=128? Cheers, Florian 2009/11/25 Remco van Mook <Remco.vanMook@eu.equinix.com>:
Hi Jan,
I see the problem you have trying to get a fragmented address space such as yours play nicely with 6rd. However, given the dimension of your network (some quick digging gave me a figure of roughly a million v4 addresses) do you think that asking for 4 billion /60 prefixes is a good idea? To borrow somebody else's words here, that doesn't scale.
Here's another idea. You've got ~135 prefixes announced, but if I aggregate those to the nearest /16 (remember, if there are blocks of space that aren't yours in between it doesn't matter for 6rd because the ipv6 sp prefix will be different anyway) you end up with a (sparsely filled) block or 30. From there on it's a matter of a simple mapping to about 21 bits of uniquely identified addresses, removing an easy 3 orders of magnitude from your address requirement. All of a sudden, you no longer need to have a /28 for just migrating your v4 customers but a mere /39, giving you tons of space for deployment of new and exciting IPv6 services for years even with the standard /32 allocation.
Since we're talking about drafts, not standards, perhaps something like this should be taken in consideration reviewing a new version of the draft. We've wasted enough IPv6 space in standards already, IMNSHO.
Best,
Remco
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jan Boogman Sent: woensdag 25 november 2009 17:13 To: Sander Steffann Cc: address-policy-wg@ripe.net; ipv6-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD
Hi Sander
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
In draft-townsley-ipv6-6rd-01 the following example is given:
This example show how the 6rd prefix is created based on a /32 IPv6 prefix with a private IPv4 address were the first octet is "compressed" out: SP prefix: 2001:0DB8::/32 6rd IPv4 prefix: 10.0.0.0/8 6rd router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
With this scheme you can still give every customer out of an IPv4 /8 an IPv6 /56 subnet. If you have an IPv4 /16 with customers you could "compress" so that every customer has an IPv6 /48. And if you have more than 65k customers you should have no problem with getting a bigger IPv6 allocation.
Because the IPRA refuses to give you more addresses based on your
customer
base I suspect that you have less than 65k customers. With a smart IPv4 <--> IPv6-RD mapping that should not be a problem for IPv6-RD.
Can you give some extra background information that explains why you need more than a /32?
we have much more than 65k customers, with IPv4 addresses dispersed in many different /8 We therefore cannot easily compress the IPv4 address and want to use the whole 32bit. However, we plan to allocate only a /60 subnet to the end customer. This results in a request for a /28
Jan
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
2009/11/26 Remco van Mook <Remco.vanMook@eu.equinix.com>:
Hi Florian
Hi Remco,
It's entirely possible my understanding of how 6rd should work is wrong, but at the same time we must realize it's a draft, not a standard and as far as I know nobody has implemented it anywhere yet. But I do see a few assumptions I don't like:
Free.fr is one of the largest providers in Europe offering IPv6 services to its customers. They are the reason why 6RD became known because they have a working installation of 6RD and are very successful. Please take a look at the link Jan postet in his original message.
- You can only do 6rd once in an entire network
If you have enought bits, you can subnet -> in front <- of the embedded IPv4 prefix (like free.fr did) and so you can address different 6RD gateways. This is infrastructure subnetting and not to be confused with customer subnetting like what Jan tries to establish. Multiple 6RD GWs are therefore technically possible IMHO, but may be messy regarding your CPE provisioning.
- It only works for IPv4 /8s and larger - It only works for IPv6 /32s and larger
Why? You can aggregate on any boundary as long as there are common high order bits.
I don't see why it wouldn't work for multiple instances and arbitrary prefix sizes for both IPv4 and IPv6. So, taking the example from Mark Townsley's draft:
SP prefix: 2001:0DB8::/32 6rd IPv4 prefix: 10.0.0.0/8 6rd router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
I don't see why this wouldn't work with a /44 SP prefix, a /16 of IPv4 and /60 6rd site IPv6 prefixes. Or any other CIDR-size, for that matter. Use multiple instances of 6rd of whatever size fits best (they don't even need to be identical) to cover whatever set of allocations you've received over the last 15 years. In Jan's case these instances together would easily fit in a /39 of space; even extending the site IPv6 prefix to a /56 wouldn't extend this beyond a /35 requirement.
If a single 6rd instance is accepted as a rule the end result of that will be that every ISP in the world with non-contiguous allocations will be asking for a /24 next, knowing full well that they're only going to use 0,1% of the network side of that space, ever.
Can you give an example? How does the GW chose the prefix for encapsulation if there is more than one possible?
Remco
Florian
-----Original Message----- From: Florian Frotzler [mailto:florian@frotzler.priv.at] Sent: donderdag 26 november 2009 1:08 To: Remco van Mook Cc: Jan Boogman; Sander Steffann; address-policy-wg@ripe.net; ipv6-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD
Hi Remco,
Either you or me have a wrong understanding of how 6RD works. I understand it like that some high order bits of the IPv4 prefixes need to match so that you can aggregate. How many high order bits of IP addresses of which the first octet is <128 do you see matching with an octet being >=128?
Cheers, Florian
2009/11/25 Remco van Mook <Remco.vanMook@eu.equinix.com>:
Hi Jan,
I see the problem you have trying to get a fragmented address space such as yours play nicely with 6rd. However, given the dimension of your network (some quick digging gave me a figure of roughly a million v4 addresses) do you think that asking for 4 billion /60 prefixes is a good idea? To borrow somebody else's words here, that doesn't scale.
Here's another idea. You've got ~135 prefixes announced, but if I aggregate those to the nearest /16 (remember, if there are blocks of space that aren't yours in between it doesn't matter for 6rd because the ipv6 sp prefix will be different anyway) you end up with a (sparsely filled) block or 30. From there on it's a matter of a simple mapping to about 21 bits of uniquely identified addresses, removing an easy 3 orders of magnitude from your address requirement. All of a sudden, you no longer need to have a /28 for just migrating your v4 customers but a mere /39, giving you tons of space for deployment of new and exciting IPv6 services for years even with the standard /32 allocation.
Since we're talking about drafts, not standards, perhaps something like this should be taken in consideration reviewing a new version of the draft. We've wasted enough IPv6 space in standards already, IMNSHO.
Best,
Remco
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jan Boogman Sent: woensdag 25 november 2009 17:13 To: Sander Steffann Cc: address-policy-wg@ripe.net; ipv6-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD
Hi Sander
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
In draft-townsley-ipv6-6rd-01 the following example is given:
This example show how the 6rd prefix is created based on a /32 IPv6 prefix with a private IPv4 address were the first octet is "compressed" out: SP prefix: 2001:0DB8::/32 6rd IPv4 prefix: 10.0.0.0/8 6rd router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
With this scheme you can still give every customer out of an IPv4 /8 an IPv6 /56 subnet. If you have an IPv4 /16 with customers you could "compress" so that every customer has an IPv6 /48. And if you have more than 65k customers you should have no problem with getting a bigger IPv6 allocation.
Because the IPRA refuses to give you more addresses based on your
customer
base I suspect that you have less than 65k customers. With a smart IPv4 <--> IPv6-RD mapping that should not be a problem for IPv6-RD.
Can you give some extra background information that explains why you need more than a /32?
we have much more than 65k customers, with IPv4 addresses dispersed in many different /8 We therefore cannot easily compress the IPv4 address and want to use the whole 32bit. However, we plan to allocate only a /60 subnet to the end customer. This results in a request for a /28
Jan
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
Hi Florian, 'it may be messy' is not a particularly strong argument I think, considering that the current deployed IPv4 setup is already more complicated than this. Every IPv4 subnet already has its own DHCP definition, adding a few lines to tell how that will translate isn't going to be hard. As for v6->v4 translation, every piece of v4 will have a separate v6 SP prefix so that's going to be easy, too. I was at RIPE58 to see Free's presentation and I don't see how any of that conflicts with what I'm trying to say here. Remco -----Original Message----- From: Florian Frotzler [mailto:florian@frotzler.priv.at] Sent: donderdag 26 november 2009 9:56 To: Remco van Mook Cc: Jan Boogman; Sander Steffann; address-policy-wg@ripe.net; ipv6-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD 2009/11/26 Remco van Mook <Remco.vanMook@eu.equinix.com>:
Hi Florian
Hi Remco,
It's entirely possible my understanding of how 6rd should work is wrong, but at the same time we must realize it's a draft, not a standard and as far as I know nobody has implemented it anywhere yet. But I do see a few assumptions I don't like:
Free.fr is one of the largest providers in Europe offering IPv6 services to its customers. They are the reason why 6RD became known because they have a working installation of 6RD and are very successful. Please take a look at the link Jan postet in his original message.
- You can only do 6rd once in an entire network
If you have enought bits, you can subnet -> in front <- of the embedded IPv4 prefix (like free.fr did) and so you can address different 6RD gateways. This is infrastructure subnetting and not to be confused with customer subnetting like what Jan tries to establish. Multiple 6RD GWs are therefore technically possible IMHO, but may be messy regarding your CPE provisioning.
- It only works for IPv4 /8s and larger - It only works for IPv6 /32s and larger
Why? You can aggregate on any boundary as long as there are common high order bits.
I don't see why it wouldn't work for multiple instances and arbitrary prefix sizes for both IPv4 and IPv6. So, taking the example from Mark Townsley's draft:
SP prefix: 2001:0DB8::/32 6rd IPv4 prefix: 10.0.0.0/8 6rd router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
I don't see why this wouldn't work with a /44 SP prefix, a /16 of IPv4 and /60 6rd site IPv6 prefixes. Or any other CIDR-size, for that matter. Use multiple instances of 6rd of whatever size fits best (they don't even need to be identical) to cover whatever set of allocations you've received over the last 15 years. In Jan's case these instances together would easily fit in a /39 of space; even extending the site IPv6 prefix to a /56 wouldn't extend this beyond a /35 requirement.
If a single 6rd instance is accepted as a rule the end result of that will be that every ISP in the world with non-contiguous allocations will be asking for a /24 next, knowing full well that they're only going to use 0,1% of the network side of that space, ever.
Can you give an example? How does the GW chose the prefix for encapsulation if there is more than one possible?
Remco
Florian
-----Original Message----- From: Florian Frotzler [mailto:florian@frotzler.priv.at] Sent: donderdag 26 november 2009 1:08 To: Remco van Mook Cc: Jan Boogman; Sander Steffann; address-policy-wg@ripe.net; ipv6-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD
Hi Remco,
Either you or me have a wrong understanding of how 6RD works. I understand it like that some high order bits of the IPv4 prefixes need to match so that you can aggregate. How many high order bits of IP addresses of which the first octet is <128 do you see matching with an octet being >=128?
Cheers, Florian
2009/11/25 Remco van Mook <Remco.vanMook@eu.equinix.com>:
Hi Jan,
I see the problem you have trying to get a fragmented address space such as yours play nicely with 6rd. However, given the dimension of your network (some quick digging gave me a figure of roughly a million v4 addresses) do you think that asking for 4 billion /60 prefixes is a good idea? To borrow somebody else's words here, that doesn't scale.
Here's another idea. You've got ~135 prefixes announced, but if I aggregate those to the nearest /16 (remember, if there are blocks of space that aren't yours in between it doesn't matter for 6rd because the ipv6 sp prefix will be different anyway) you end up with a (sparsely filled) block or 30. From there on it's a matter of a simple mapping to about 21 bits of uniquely identified addresses, removing an easy 3 orders of magnitude from your address requirement. All of a sudden, you no longer need to have a /28 for just migrating your v4 customers but a mere /39, giving you tons of space for deployment of new and exciting IPv6 services for years even with the standard /32 allocation.
Since we're talking about drafts, not standards, perhaps something like this should be taken in consideration reviewing a new version of the draft. We've wasted enough IPv6 space in standards already, IMNSHO.
Best,
Remco
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jan Boogman Sent: woensdag 25 november 2009 17:13 To: Sander Steffann Cc: address-policy-wg@ripe.net; ipv6-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD
Hi Sander
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
In draft-townsley-ipv6-6rd-01 the following example is given:
This example show how the 6rd prefix is created based on a /32 IPv6 prefix with a private IPv4 address were the first octet is "compressed" out: SP prefix: 2001:0DB8::/32 6rd IPv4 prefix: 10.0.0.0/8 6rd router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
With this scheme you can still give every customer out of an IPv4 /8 an IPv6 /56 subnet. If you have an IPv4 /16 with customers you could "compress" so that every customer has an IPv6 /48. And if you have more than 65k customers you should have no problem with getting a bigger IPv6 allocation.
Because the IPRA refuses to give you more addresses based on your
customer
base I suspect that you have less than 65k customers. With a smart IPv4 <--> IPv6-RD mapping that should not be a problem for IPv6-RD.
Can you give some extra background information that explains why you need more than a /32?
we have much more than 65k customers, with IPv4 addresses dispersed in many different /8 We therefore cannot easily compress the IPv4 address and want to use the whole 32bit. However, we plan to allocate only a /60 subnet to the end customer. This results in a request for a /28
Jan
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
If a single 6rd instance is accepted as a rule the end result of that will be that every ISP in the world with non-contiguous allocations will be asking for a /24 next, knowing full well that they're only going to use 0,1% of the network side of that space, ever.
A lot of numbers have been thrown around fairly casually in this conversation, but /24 is a nice one to focus on because everyone understands how many /24s there are in a number space. If we could have run the IPv4 Internet by only giving every ISP a single /24, then we would never have run out of IPv4 addresses. Conversely, giving every ISP an IPv6 /24 is not radical and is not even wasteful given the large number of /24s that we have in stock at RIPE and at IANA. As for your comment about 0.1%, I'd like to know how you calculated that number. In general, I'm only interested in numbers that count /56s (or /48s) and /32s since those are the only ones that are meaningful in making policy. --Michael Dillon
Fair enough, I'll bite. Given 2^32(or 4 billion) IPv4 addresses, and say, 4 million IP's allocated to the average ISP (I'm being generous here) there's your 0.1%. The rest of the space will go unused since we're using 32 bits to identify these sparse blocks in the v4->v6 translation. Not counting customer /56s, 48s, /60s or whatever. The more dangerous bit here is that you're going to have a hard time using the other pieces of that 32 bits you've allocated to 6rd elsewhere - it'll only give you v6 for people you're currently handing out a v4 address as well. I agree that handing an ISP a /24 should last them an eternity, but only if they make sensible use of it. Remco -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of michael.dillon@bt.com Sent: donderdag 26 november 2009 10:12 To: address-policy-wg@ripe.net; ipv6-wg@ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD
If a single 6rd instance is accepted as a rule the end result of that will be that every ISP in the world with non-contiguous allocations will be asking for a /24 next, knowing full well that they're only going to use 0,1% of the network side of that space, ever.
A lot of numbers have been thrown around fairly casually in this conversation, but /24 is a nice one to focus on because everyone understands how many /24s there are in a number space. If we could have run the IPv4 Internet by only giving every ISP a single /24, then we would never have run out of IPv4 addresses. Conversely, giving every ISP an IPv6 /24 is not radical and is not even wasteful given the large number of /24s that we have in stock at RIPE and at IANA. As for your comment about 0.1%, I'd like to know how you calculated that number. In general, I'm only interested in numbers that count /56s (or /48s) and /32s since those are the only ones that are meaningful in making policy. --Michael Dillon This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
Fair enough, I'll bite. Given 2^32(or 4 billion) IPv4 addresses, and say, 4 million IP's allocated to the average ISP (I'm being generous here) there's your 0.1%. The rest of the space will go unused since we're using 32 bits to identify these sparse blocks in the v4->v6 translation. Not counting customer /56s, 48s, /60s or whatever.
But customers, and /56s are the essential things to count. Again, you just throw in the number 4 million without explaining where it comes from. IPv4 ISPs come in all sizes with one /24 allocation and some with many allocations of sizes ranging from /17 to /12. Counting IP addresses in IPv6 makes no sense. The addressing hierarchy of IPv6 is designed to have large blocks of unused and unusable addresses. This is both to allow for expansion without changing the network architecture, and to allow for automated address assignment functions which rely on large sparse number spaces to avoid collisions. --Michael Dillon
Michael key words here are 'average' and 'generous'. Perhaps you should try to read first. Same goes for your statement of counting addresses. In cases like these, I think orders of magnitude are more interesting than narrowly defined numbers. 4 million is roughly 0.1% of the IPv4 pool. Since I think the AVERAGE ISP is probably smaller than that (either in customer count or allocated space), giving all of them 32 bits (or the full IPv4 space) PLUS 4-8 bits of network space (not host space!) for their 6rd plan sounds wasteful to me. The 6rd draft has prefix compression for a reason. Sparse number spaces for expansion and automation are fine. Very sparse number spaces you know from the outset will never be filled or usable for other purposes, are not. That is why deploying multiple instances of 6rd in order to benefit from prefix compression to collapse that required number space without losing functionality sounds like the right direction for me. Remco (and if we decide that a /24 is a better standard to hand out to LIRs than a /32, I can predict today that somebody will come up with a very clever reason to say that /16s are probably even better. Repeat until bored - or out of space.) -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of michael.dillon@bt.com Sent: vrijdag 27 november 2009 11:04 To: address-policy-wg@ripe.net; ipv6-wg@ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD
Fair enough, I'll bite. Given 2^32(or 4 billion) IPv4 addresses, and say, 4 million IP's allocated to the average ISP (I'm being generous here) there's your 0.1%. The rest of the space will go unused since we're using 32 bits to identify these sparse blocks in the v4->v6 translation. Not counting customer /56s, 48s, /60s or whatever.
But customers, and /56s are the essential things to count. Again, you just throw in the number 4 million without explaining where it comes from. IPv4 ISPs come in all sizes with one /24 allocation and some with many allocations of sizes ranging from /17 to /12. Counting IP addresses in IPv6 makes no sense. The addressing hierarchy of IPv6 is designed to have large blocks of unused and unusable addresses. This is both to allow for expansion without changing the network architecture, and to allow for automated address assignment functions which rely on large sparse number spaces to avoid collisions. --Michael Dillon This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
Remco van Mook wrote:
Michael
key words here are 'average' and 'generous'. Perhaps you should try to read first. Same goes for your statement of counting addresses. In cases like these, I think orders of magnitude are more interesting than narrowly defined numbers. 4 million is roughly 0.1% of the IPv4 pool. Since I think the AVERAGE ISP is probably smaller than that (either in customer count or allocated space), giving all of them 32 bits (or the full IPv4 space) PLUS 4-8 bits of network space (not host space!) for their 6rd plan sounds wasteful to me.
The 6rd draft has prefix compression for a reason. Sparse number spaces for expansion and automation are fine. Very sparse number spaces you know from the outset will never be filled or usable for other purposes, are not.
Actually, the main reason we added this is for easy and obvious compression for when an SP has decided to run NAT. The RFC1918 space is nicely aggregated. Please don't give SPs more reasons to deploy NATted IPv4 service. Most SPs I talk to don't really like the idea of compressing the global space, if nothing else because they have no assurance that the global IPv4 space they have now will be the same in the future. They'd sooner give the customer a /64, which I've already stated why I personally think is dangerous.
That is why deploying multiple instances of 6rd in order to benefit from prefix compression to collapse that required number space without losing functionality sounds like the right direction for me.
There is nothing prohibiting multiple instances of 6rd in the current version of the draft, however note that this does not come without operational complexity - which is exactly what 6rd is trying to allow an SP to avoid. So, there's a cost tradeoff here. Increased prudence of IPv6 space vs. increased cost for ISPs to deploy IPv6. It's quite easy to be penny-wise and pound-foolish here, and given the rate of native deployment of IPv6 thus far, I'd err on the side of getting IPv6 out the door in the short term until we are sure it no longer needs a boost. Consider it similar to stimulus funds to counter a depression if you must, but if an ISP which would otherwise qualify for a /30 needs a /28 or /26 to get IPv6 deployed now vs. later, I'd choose handing out a few more bits until we no longer think it necessary for native IPv6 adoption to occur. - Mark
Hi, On Thu, Nov 26, 2009 at 09:23:19AM +0100, Remco van Mook wrote:
If a single 6rd instance is accepted as a rule the end result of that will be that every ISP in the world with non-contiguous allocations will be asking for a /24 next, knowing full well that they're only going to use 0,1% of the network side of that space, ever.
Just to drop a bit of bait into this lively discussion :-9 - we could actually afford to give every organization that reasonably claims to serve IP connectivity to more than 1000 customers a /24. There's 10 million /24s inside FP 001. All in all, the RIRs have about 20.000 members today - 1/500th of that. Of course that's not my call to make, but would require a formal policy change (and isn't actually the point of this discussion - which is "provide guidance to the IPRAs on whether the WG is considering this to be acceptable use"). Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Just to drop a bit of bait into this lively discussion :-9 - we could actually afford to give every organization that reasonably claims to serve IP connectivity to more than 1000 customers a /24. There's 10 million /24s inside FP 001. All in all, the RIRs have about 20.000 members today - 1/500th of that.
I think I'm with Remco here, there is a way around it and it might be worth adding something on how to do that to the drafr. I don't think 'it's messy' or 'we have enough space' are strong arguments to simply give everybody a /24, let's not forget there was that day once when a /8 was the default assignment size. Groet, MarcoH
Just to drop a bit of bait into this lively discussion :-9 - we could actually afford to give every organization that reasonably claims to serve IP connectivity to more than 1000 customers a /24. There's 10 million /24s inside FP 001. All in all, the RIRs have about 20.000 members today - 1/500th of that.
Now those are numbers that I can understand. I think everyone knows what a /24 is, because even in IPv6 it is the same percentage of the total number space as it is in IPv4. Either we accept the fact that 6RD relies on assigning address blocks sparsely within the allocation for technical reasons, and just give 6RD ISP's an allocation big enough to do the job, or we write a special policy for 6RD ISPs. There are only 2 reasons that I can see to write a special policy. One is to encourage ISPs to assign /56 prefixes to customers, not longer ones like /60. And the other is to restrict 6RD allocations only to ISPs that maintain a certain amount of density, i.e. if an ISP has lots of IPv4 allocations scattered all around the IPv4 number space, we might say that they cannot have an IPv6 allocation to cover more than x number of IPv4 /8s. But given that there is no shortage of IPv6 addresses in the foreseeable future, I'm not yet convinced that a new policy is needed. --Michael Dillon
Just to drop a bit of bait into this lively discussion :-9 - we could actually afford to give every organization that reasonably claims to serve IP connectivity to more than 1000 customers a /24. There's 10 million /24s inside FP 001. All in all, the RIRs have about 20.000 members today - 1/500th of that.
Now those are numbers that I can understand. I think everyone knows what a /24 is, because even in IPv6 it is the same percentage of the total number space as it is in IPv4.
Either we accept the fact that 6RD relies on assigning address blocks sparsely within the allocation for technical reasons, and just give 6RD ISP's an allocation big enough to do the job, or we write a special policy for 6RD ISPs.
There are only 2 reasons that I can see to write a special policy. One is to encourage ISPs to assign /56 prefixes to customers, not longer ones like /60. Or /60s vs. /64s. I think you may be a little optimistic if you think
michael.dillon@bt.com wrote: that /60 is the low end of the totem pole here. Case in point is that when Free first offered its IPv6 service, it did so within the /32 it had by giving /64s to all its customers. A few folks like myself complained, and they changed it only because they were able to get a large enough allocation from RIPE (which they had to go back and ask for). If that had not happened, it's not like Free would have ripped out its entire DSLAM infrastructure and upgraded it to offer a /60 or /56. The choice would have been /64 or nothing. Period. So, here's a case where RIPE's decision, for whatever reason at the time, of asking Free to hand in its /32 (and, yes, Free gave it back AFAIK) and giving them a /26 instead directly affected the IPv6 service to myself and several hundred thousand IPv6 Internet subscribers in France. RIPE NCC, thank you kindly for that! (and for the socials!)
And the other is to restrict 6RD allocations only to ISPs that maintain a certain amount of density, i.e. if an ISP has lots of IPv4 allocations scattered all around the IPv4 number space, we might say that they cannot have an IPv6 allocation to cover more than x number of IPv4 /8s.
But given that there is no shortage of IPv6 addresses in the foreseeable future, I'm not yet convinced that a new policy is needed.
I'd be perfectly fine with no new policy, as long as ISPs, even relatively small ones, do not delay IPv6 deployment over lack of obtainable space. Right now, I'm seeing timelines for Ipv6 pushed up rather than pushed back, in a number of cases due to 6rd. As long as we are not reversing that trend, I'll calmly go back to not posting here :-) - Mark
--Michael Dillon
There are only 2 reasons that I can see to write a special policy. One is to encourage ISPs to assign /56 prefixes to customers, not longer ones like /60. Or /60s vs. /64s. I think you may be a little optimistic if you think that /60 is the low end of the totem pole here.
I don't believe that RIR policy should ever encourage ISPs to assign customer sites a prefix longer than /56. In fact, we really should discourage assigning anything other than a /48 or a /56 because part of the benefit of IPv6 comes from giving the customers a spacious number space in which they can subnet. This also allows for greater portability, i.e. I can switch providers without changing my network architecture, or I can relocate to another country and know that I will get the same prefix length assignment.
Case in point is that when Free first offered its IPv6 service, it did so within the /32 it had by giving /64s to all its customers. A few folks like myself complained, and they changed it only because they were able to get a large enough allocation from RIPE (which they had to go back and ask for). If that had not happened, it's not like Free would have ripped out its entire DSLAM infrastructure and upgraded it to offer a /60 or /56. The choice would have been /64 or nothing. Period.
The point is that it did happen. RIPE did give them enough address space to offer customers more than a /64. That is the way things should be because there is no shortage of IPv6 address space. In fact, RIPE should refuse to give ISPs an allocation so small that it forces them to offer customers anything longer than a /56 prefix.
I'd be perfectly fine with no new policy, as long as ISPs, even relatively small ones, do not delay IPv6 deployment over lack of obtainable space.
Yet another reason why RIPE should be liberal with IPv6 space. In IPv4, a /32 will number one host. In IPv6, the same prefix will provide many ISPs enough address space to last them 20 to 50 years. In IPv4, a /24 is something that you assign to customers and a /21 is a small ISP. Why should we be more restrictive in IPv6? I can see no good reason to not hand out ISPs a /24 or a /21 if they need it to make their IPv6 access service work. Even though my employer, a rather large ISP, expects to fit within a /21 with native IPv6 services, I do not see the need to require every other ISP to use their IPv6 allocation as efficiently as we do. Cost efficiency is more important, and if a medium sized ISP needs a /21 in order to get their IPv6 service rolled out faster, then I believe we should give them that /21. The sooner we get the IPv6 transition into full gear, the better it will be for all of us. Network effects demand that we help our competitors by removing any barriers that limit them or slow them down. --Michael Dillon
michael.dillon@bt.com wrote:
There are only 2 reasons that I can see to write a special policy. One is to encourage ISPs to assign /56 prefixes to customers, not longer ones like /60.
Or /60s vs. /64s. I think you may be a little optimistic if you think that /60 is the low end of the totem pole here.
I don't believe that RIR policy should ever encourage ISPs to assign customer sites a prefix longer than /56. In fact, we really should discourage assigning anything other than a /48 or a /56 because part of the benefit of IPv6 comes from giving the customers a spacious number space in which they can subnet. This also allows for greater portability, i.e. I can switch providers without changing my network architecture, or I can relocate to another country and know that I will get the same prefix length assignment.
Case in point is that when Free first offered its IPv6 service, it did so within the /32 it had by giving /64s to all its customers. A few folks like myself complained, and they changed it only because they were able to get a large enough allocation from RIPE (which they had to go back and ask for). If that had not happened, it's not like Free would have ripped out its entire DSLAM infrastructure and upgraded it to offer a /60 or /56. The choice would have been /64 or nothing. Period.
The point is that it did happen. RIPE did give them enough address space to offer customers more than a /64. That is the way things should be because there is no shortage of IPv6 address space.
In fact, RIPE should refuse to give ISPs an allocation so small that it forces them to offer customers anything longer than a /56 prefix.
I'm sure Free would have been happy to get a /22 vs. a /26, and might even pass that on to its customers via a /56 vs. a /60.
I'd be perfectly fine with no new policy, as long as ISPs, even relatively small ones, do not delay IPv6 deployment over lack of obtainable space.
Yet another reason why RIPE should be liberal with IPv6 space.
In IPv4, a /32 will number one host. In IPv6, the same prefix will provide many ISPs enough address space to last them 20 to 50 years. In IPv4, a /24 is something that you assign to customers and a /21 is a small ISP. Why should we be more restrictive in IPv6? I can see no good reason to not hand out ISPs a /24 or a /21 if they need it to make their IPv6 access service work.
I agree 100%, I'm just telling you my experience in talking with ISPs. In some cases, it starts with "why not a /128?" then once we get to the point that /64 is really the absolute minimum, then /56 is is the next target. It's often a battle just to get to that point though.
Even though my employer, a rather large ISP, expects to fit within a /21 with native IPv6 services, I do not see the need to require every other ISP to use their IPv6 allocation as efficiently as we do. Cost efficiency is more important, and if a medium sized ISP needs a /21 in order to get their IPv6 service rolled out faster, then I believe we should give them that /21. A /21 should be ample for any ISP to run 6rd and several other native services as well. The sooner we get the IPv6 transition into full gear, the better it will be for all of us. Network effects demand that we help our competitors by removing any barriers that limit them or slow them down.
Absolutely. The value of the network, and the protocol it runs on, is proportional to the square of the users of course. - Mark
--Michael Dillon
On Fri, 27 Nov 2009, michael.dillon@bt.com wrote:
There are only 2 reasons that I can see to write a special policy. One is to encourage ISPs to assign /56 prefixes to customers, not longer ones like /60. Or /60s vs. /64s. I think you may be a little optimistic if you think that /60 is the low end of the totem pole here.
I don't believe that RIR policy should ever encourage ISPs to assign customer sites a prefix longer than /56. In fact, we really should discourage assigning anything other than a /48 or a /56 because part of the benefit of IPv6 comes from giving the customers a spacious number space in which they can subnet. This also allows for greater portability, i.e. I can switch providers without changing my network architecture, or I can relocate to another country and know that I will get the same prefix length assignment.
Case in point is that when Free first offered its IPv6 service, it did so within the /32 it had by giving /64s to all its customers. A few folks like myself complained, and they changed it only because they were able to get a large enough allocation from RIPE (which they had to go back and ask for). If that had not happened, it's not like Free would have ripped out its entire DSLAM infrastructure and upgraded it to offer a /60 or /56. The choice would have been /64 or nothing. Period.
The point is that it did happen. RIPE did give them enough address space to offer customers more than a /64. That is the way things should be because there is no shortage of IPv6 address space.
In fact, RIPE should refuse to give ISPs an allocation so small that it forces them to offer customers anything longer than a /56 prefix.
I'd be perfectly fine with no new policy, as long as ISPs, even relatively small ones, do not delay IPv6 deployment over lack of obtainable space.
Yet another reason why RIPE should be liberal with IPv6 space.
In IPv4, a /32 will number one host. In IPv6, the same prefix will provide many ISPs enough address space to last them 20 to 50 years. In IPv4, a /24 is something that you assign to customers and a /21 is a small ISP. Why should we be more restrictive in IPv6? I can see no good reason to not hand out ISPs a /24 or a /21 if they need it to make their IPv6 access service work.
Even though my employer, a rather large ISP, expects to fit within a /21 with native IPv6 services, I do not see the need to require every other ISP to use their IPv6 allocation as efficiently as we do. Cost efficiency is more important, and if a medium sized ISP needs a /21 in order to get their IPv6 service rolled out faster, then I believe we should give them that /21.
The sooner we get the IPv6 transition into full gear, the better it will be for all of us. Network effects demand that we help our competitors by removing any barriers that limit them or slow them down.
--Michael Dillon
You forget an important point: 6RD is developed for large amount of small customers (e.g. home users). Giving them /56-/60 should not be a problem. 6RD is not universal! Larger customers your should implement dual-stack solution and give them /48. One size does not fit for all! Best Regards, Janos Mohacsi
You forget an important point: 6RD is developed for large amount of small customers (e.g. home users). Giving them /56-/60 should not be a problem. 6RD is not universal! Larger customers your should implement dual-stack solution and give them /48. One size does not fit for all!
I consider it a problem if anyone is giving private residence customers a /60. Nobody should get less than a /56 block and if anyone believes that RIPE rules force them to give less than a /56 block, then RIPE should either clarify the situation (education) or we should change the rules. Yes, I agree that non-residential customers should get a /48 and run dual stack on their network, or use other transition mechanisms like Teredo, 6to4, etc. The total cost of transition will be minimized this way. --Michael Dillon
Hi Remco,
Since we're talking about drafts, not standards, perhaps something like this should be taken in consideration reviewing a new version of the draft. We've wasted enough IPv6 space in standards already, IMNSHO.
Very good point. Sander
Since we're talking about drafts, not standards, perhaps something like this should be taken in consideration reviewing a new version of the draft. We've wasted enough IPv6 space in standards already, IMNSHO.
Very good point.
As a lurker in the ipv6-wg list I was going to offer something like that (though less constructive than Remco's message). Notwithstanding the mind-boggling size of IPv6 address space, giving every ISP a copy of the entire IPv4 address space for their 6rd customers doesn't look to me as though it would scale well; it's certainly not going to make efficient use of the assigned space. Sam Wilson Network Team, IT Infrastructure Information Services, The University of Edinburgh Edinburgh, Scotland, UK -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
we have much more than 65k customers, with IPv4 addresses dispersed in many different /8 We therefore cannot easily compress the IPv4 address and want to use the whole 32bit. However, we plan to allocate only a /60 subnet to the end customer. This results in a request for a /28
If you have a lot of customers then I see nothing wrong with giving an allocation larger than /32. There are clear technical reasons that make this necessary. However, I would like to see RIPE discourage end customer prefixes longer than /56 for general Internet access. In other words, I believe that you should get a bigger block than /28, big enough so that you can allocate /56 subnets to each customer. --Michael Dillon
Hi Sander, It is clearly stated in the draft that you can only aggregate IPv4 address space if there is a common prefix, like "10" in 10.0.0.0/8. If you use public address space this is not possible and you are forced to use all 32 bits. If you have an SP prefix of 32 bits and 32 bits for the IPv4 address you end up having none for subnetting. So yes, Swisscom needs more than a /32. But... Free.fr got a /26, as they state in their RIPE-58 presentation, so they obviously could argument their need for the address space in front of RIPE. This leaves two flows to follow... -> either it depends on who from the hostmasters is dealing with your allocation request, because why would RIPE deal with Swisscom different than with free.fr? -> or Swisscom could not argue the need to RIPE in the same way as free.fr? Maybe someone from RIPE can clarify this. Cheers, Florian 2009/11/25 Sander Steffann <sander@steffann.nl>:
Hi Jan,
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
In draft-townsley-ipv6-6rd-01 the following example is given:
This example show how the 6rd prefix is created based on a /32 IPv6 prefix with a private IPv4 address were the first octet is "compressed" out: SP prefix: 2001:0DB8::/32 6rd IPv4 prefix: 10.0.0.0/8 6rd router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
With this scheme you can still give every customer out of an IPv4 /8 an IPv6 /56 subnet. If you have an IPv4 /16 with customers you could "compress" so that every customer has an IPv6 /48. And if you have more than 65k customers you should have no problem with getting a bigger IPv6 allocation.
Because the IPRA refuses to give you more addresses based on your customer base I suspect that you have less than 65k customers. With a smart IPv4 <--> IPv6-RD mapping that should not be a problem for IPv6-RD.
Can you give some extra background information that explains why you need more than a /32?
- Sander
Hi Florian,
It is clearly stated in the draft that you can only aggregate IPv4 address space if there is a common prefix, like "10" in 10.0.0.0/8.
I was thinking about mapping different common prefixes to different IPv6 ranges by running several IPv6-6RD setups in parallel, but I don't even know if that is possible or feasible. It would be a waste of address space to use one IPv6-6RD setup with 32 bits for the IPv4 address when most of those addresses will never be used. We have a lot of bits in an IPv6 address, but doing this doesn't seem to make sense.
Free.fr got a /26, as they state in their RIPE-58 presentation, so they obviously could argument their need for the address space in front of RIPE. This leaves two flows to follow...
-> either it depends on who from the hostmasters is dealing with your allocation request, because why would RIPE deal with Swisscom different than with free.fr? -> or Swisscom could not argue the need to RIPE in the same way as free.fr?
Good question, but this is something that Swisscom and RIPE NCC should discuss. RIPE NCC won't publicly discuss allocation request details, and that confidentiality is good. What we need to do as address policy WG is think about how we want to deal with this in general. Do we want/need special policy for IPv6-6RD users? If we think we do, we should define the rules and conditions by writing a formal policy proposal. But we need to check if the current policy isn't good enough already. I think we should have as few 'special' policies as possible. Sander
Hi Sander, With the current draft of 6RD you can not use different IPv4 prefixes as the 6RD gateway just would not know when to use which prefix. IMHO, using public IP addresses you need to use 32 bit, but maybe this issue is corrected before it becomes an RFC, I don't know. This IS definitely a flaw in the 6RD design. I am not a fan of handing out everyone who implements 6RD a /28 or even larger allocation, but we should not hamper the rollout of v6 with this issue! Being this discussion a private one between RIPE-NCC and Swisscom or not, the IPRA explicitly asked Swisscom to take this topic to the community, so they have to bear with the question of whether it is fair to assign a /26 to free.fr and decline a /28 to Swisscom -> for the same implementation <- Was the address policy a different one at the time free.fr got their prefix? Cheers, Florian 2009/11/25 Sander Steffann <sander@steffann.nl>:
Hi Florian,
It is clearly stated in the draft that you can only aggregate IPv4 address space if there is a common prefix, like "10" in 10.0.0.0/8.
I was thinking about mapping different common prefixes to different IPv6 ranges by running several IPv6-6RD setups in parallel, but I don't even know if that is possible or feasible. It would be a waste of address space to use one IPv6-6RD setup with 32 bits for the IPv4 address when most of those addresses will never be used. We have a lot of bits in an IPv6 address, but doing this doesn't seem to make sense.
Free.fr got a /26, as they state in their RIPE-58 presentation, so they obviously could argument their need for the address space in front of RIPE. This leaves two flows to follow...
-> either it depends on who from the hostmasters is dealing with your allocation request, because why would RIPE deal with Swisscom different than with free.fr? -> or Swisscom could not argue the need to RIPE in the same way as free.fr?
Good question, but this is something that Swisscom and RIPE NCC should discuss. RIPE NCC won't publicly discuss allocation request details, and that confidentiality is good.
What we need to do as address policy WG is think about how we want to deal with this in general. Do we want/need special policy for IPv6-6RD users? If we think we do, we should define the rules and conditions by writing a formal policy proposal. But we need to check if the current policy isn't good enough already. I think we should have as few 'special' policies as possible.
Sander
Dear Colleagues,
I am not a fan of handing out everyone who implements 6RD a /28 or even larger allocation, but we should not hamper the rollout of v6 with this issue! Being this discussion a private one between RIPE-NCC and Swisscom or not, the IPRA explicitly asked Swisscom to take this topic to the community, so they have to bear with the question of whether it is fair to assign a /26 to free.fr and decline a /28 to Swisscom -> for the same implementation <-
The size of all allocations that we make is based on the information that the LIR supplies during the evaluation process and the IPv6 Address Policy. The details of the information that our members supply to us during the evaluation of their requests are confidential and therefore we cannot disclose these. We do ensure that all our members and their requests are treated in an impartial and fair way.
Was the address policy a different one at the time free.fr got their prefix?
There have been several changes to the address policies since Free.fr received their allocation, but their request would not result in a different size block today. Best regards, Alex Le Heux RIPE NCC
In ripe.address-policy-wg, you wrote:
we are planning to offer IPv6 connectivity to our xDSL and FTTH customer base via IPv6-6RD.
That's a bad idea. Please stick to 2002::/16 or simply provide native IPv6 in your backbone.
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
We choosed to announce 2001:0:d911:c000::/52 as well as 2002:d911:c000::/36 in order to overcoming the anycast hassles for the first months. After that we had production stable IPv6 and dropped such tunneling hacks. I oppose handing out large amounts of address space for such legacy methods to save costs in IPv6 rollout.
Hi Lutz, I totally disagree with you :-) This would slow down the IPv6 rollout. IPv6-RD is a good choice to bring IPv6 quickly to the customers and fight with the dual stack implementation later. Maybe you are working at a small ISP, but in the real world there are a lot of hazards on the way to implement end2end v6, especially with large ISPs. Cheers, Florian 2009/11/25 Lutz Donnerhacke <lutz@iks-jena.de>:
In ripe.address-policy-wg, you wrote:
we are planning to offer IPv6 connectivity to our xDSL and FTTH customer base via IPv6-6RD.
That's a bad idea. Please stick to 2002::/16 or simply provide native IPv6 in your backbone.
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
We choosed to announce 2001:0:d911:c000::/52 as well as 2002:d911:c000::/36 in order to overcoming the anycast hassles for the first months. After that we had production stable IPv6 and dropped such tunneling hacks.
I oppose handing out large amounts of address space for such legacy methods to save costs in IPv6 rollout.
On Wed, 25 Nov 2009, Florian Frotzler wrote:
Hi Lutz,
I totally disagree with you :-)
This would slow down the IPv6 rollout. IPv6-RD is a good choice to bring IPv6 quickly to the customers and fight with the dual stack implementation later. Maybe you are working at a small ISP, but in the real world there are a lot of hazards on the way to implement end2end v6, especially with large ISPs.
6rd is applicable only if the IP provider is controlling the CPE routers or 6rd is widely implemented in customers CPEs. So not so quick roll-out. Best Regards, Janos Mohacsi
Cheers, Florian
2009/11/25 Lutz Donnerhacke <lutz@iks-jena.de>:
In ripe.address-policy-wg, you wrote:
we are planning to offer IPv6 connectivity to our xDSL and FTTH customer base via IPv6-6RD.
That's a bad idea. Please stick to 2002::/16 or simply provide native IPv6 in your backbone.
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
We choosed to announce 2001:0:d911:c000::/52 as well as 2002:d911:c000::/36 in order to overcoming the anycast hassles for the first months. After that we had production stable IPv6 and dropped such tunneling hacks.
I oppose handing out large amounts of address space for such legacy methods to save costs in IPv6 rollout.
still quicker as teaching all your IT tools to speak v6... Cheers, Florian 2009/11/25 Mohacsi Janos <mohacsi@niif.hu>:
On Wed, 25 Nov 2009, Florian Frotzler wrote:
Hi Lutz,
I totally disagree with you :-)
This would slow down the IPv6 rollout. IPv6-RD is a good choice to bring IPv6 quickly to the customers and fight with the dual stack implementation later. Maybe you are working at a small ISP, but in the real world there are a lot of hazards on the way to implement end2end v6, especially with large ISPs.
6rd is applicable only if the IP provider is controlling the CPE routers or 6rd is widely implemented in customers CPEs. So not so quick roll-out. Best Regards, Janos Mohacsi
Cheers, Florian
2009/11/25 Lutz Donnerhacke <lutz@iks-jena.de>:
In ripe.address-policy-wg, you wrote:
we are planning to offer IPv6 connectivity to our xDSL and FTTH customer base via IPv6-6RD.
That's a bad idea. Please stick to 2002::/16 or simply provide native IPv6 in your backbone.
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
We choosed to announce 2001:0:d911:c000::/52 as well as 2002:d911:c000::/36 in order to overcoming the anycast hassles for the first months. After that we had production stable IPv6 and dropped such tunneling hacks.
I oppose handing out large amounts of address space for such legacy methods to save costs in IPv6 rollout.
On Wed, 25 Nov 2009, Florian Frotzler wrote:
still quicker as teaching all your IT tools to speak v6...
Use opensource, they are more IPv6 aware. By the way, you have to teach your IT tools to speak v6, since with 6RD you are using v6! Best Regards, Janos Mohacsi
Cheers, Florian
2009/11/25 Mohacsi Janos <mohacsi@niif.hu>:
On Wed, 25 Nov 2009, Florian Frotzler wrote:
Hi Lutz,
I totally disagree with you :-)
This would slow down the IPv6 rollout. IPv6-RD is a good choice to bring IPv6 quickly to the customers and fight with the dual stack implementation later. Maybe you are working at a small ISP, but in the real world there are a lot of hazards on the way to implement end2end v6, especially with large ISPs.
6rd is applicable only if the IP provider is controlling the CPE routers or 6rd is widely implemented in customers CPEs. So not so quick roll-out. Best Regards, Janos Mohacsi
Cheers, Florian
2009/11/25 Lutz Donnerhacke <lutz@iks-jena.de>:
In ripe.address-policy-wg, you wrote:
we are planning to offer IPv6 connectivity to our xDSL and FTTH customer base via IPv6-6RD.
That's a bad idea. Please stick to 2002::/16 or simply provide native IPv6 in your backbone.
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
We choosed to announce 2001:0:d911:c000::/52 as well as 2002:d911:c000::/36 in order to overcoming the anycast hassles for the first months. After that we had production stable IPv6 and dropped such tunneling hacks.
I oppose handing out large amounts of address space for such legacy methods to save costs in IPv6 rollout.
No, using 6RD I do not need to account v6 and I do not need to provision network elements with v6. Ah yes, and my network elements in between do need to speak v6 so that I can leave them in their normal life cycle instead of investing a lot of money. Cheers, Florian -----Ursprüngliche Nachricht----- Von: Mohacsi Janos [mailto:mohacsi@niif.hu] Gesendet: Mittwoch, 25. November 2009 19:23 An: Florian Frotzler Cc: address-policy-wg@ripe.net Betreff: Re: [address-policy-wg] IPv6 allocations for 6RD On Wed, 25 Nov 2009, Florian Frotzler wrote:
still quicker as teaching all your IT tools to speak v6...
Use opensource, they are more IPv6 aware. By the way, you have to teach your IT tools to speak v6, since with 6RD you are using v6! Best Regards, Janos Mohacsi
Cheers, Florian
2009/11/25 Mohacsi Janos <mohacsi@niif.hu>:
On Wed, 25 Nov 2009, Florian Frotzler wrote:
Hi Lutz,
I totally disagree with you :-)
This would slow down the IPv6 rollout. IPv6-RD is a good choice to bring IPv6 quickly to the customers and fight with the dual stack implementation later. Maybe you are working at a small ISP, but in the real world there are a lot of hazards on the way to implement end2end v6, especially with large ISPs.
6rd is applicable only if the IP provider is controlling the CPE routers
or
6rd is widely implemented in customers CPEs. So not so quick roll-out. Best Regards, Janos Mohacsi
Cheers, Florian
2009/11/25 Lutz Donnerhacke <lutz@iks-jena.de>:
In ripe.address-policy-wg, you wrote:
we are planning to offer IPv6 connectivity to our xDSL and FTTH
customer
base via IPv6-6RD.
That's a bad idea. Please stick to 2002::/16 or simply provide native IPv6 in your backbone.
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
We choosed to announce 2001:0:d911:c000::/52 as well as 2002:d911:c000::/36 in order to overcoming the anycast hassles for the first months. After that we had production stable IPv6 and dropped such tunneling hacks.
I oppose handing out large amounts of address space for such legacy methods to save costs in IPv6 rollout.
On Wed, 25 Nov 2009, Florian Frotzler wrote:
No, using 6RD I do not need to account v6 and I do not need to provision network elements with v6. Ah yes, and my network elements in between do need to speak v6 so that I can leave them in their normal life cycle instead of investing a lot of money.
You don't need provision CPE with IPv6, but you have to keep track IPv6 usage and allocations. You should be able to handle security incidents related to your IPv6 users. Better if you keep track complete IPv6 addresses, therefore some parts of your system needs v6 accounting. You can postopone upgrading some network elements to IPv6, but you need decent 6rd relay and IPv6 connectivity in your peers. Best Regards, Janos Mohacsi
Cheers, Florian
-----Ursprüngliche Nachricht----- Von: Mohacsi Janos [mailto:mohacsi@niif.hu] Gesendet: Mittwoch, 25. November 2009 19:23 An: Florian Frotzler Cc: address-policy-wg@ripe.net Betreff: Re: [address-policy-wg] IPv6 allocations for 6RD
On Wed, 25 Nov 2009, Florian Frotzler wrote:
still quicker as teaching all your IT tools to speak v6...
Use opensource, they are more IPv6 aware. By the way, you have to teach your IT tools to speak v6, since with 6RD you are using v6!
Best Regards, Janos Mohacsi
Cheers, Florian
2009/11/25 Mohacsi Janos <mohacsi@niif.hu>:
On Wed, 25 Nov 2009, Florian Frotzler wrote:
Hi Lutz,
I totally disagree with you :-)
This would slow down the IPv6 rollout. IPv6-RD is a good choice to bring IPv6 quickly to the customers and fight with the dual stack implementation later. Maybe you are working at a small ISP, but in the real world there are a lot of hazards on the way to implement end2end v6, especially with large ISPs.
6rd is applicable only if the IP provider is controlling the CPE routers
or
6rd is widely implemented in customers CPEs. So not so quick roll-out. Best Regards, Janos Mohacsi
Cheers, Florian
2009/11/25 Lutz Donnerhacke <lutz@iks-jena.de>:
In ripe.address-policy-wg, you wrote:
we are planning to offer IPv6 connectivity to our xDSL and FTTH
customer
base via IPv6-6RD.
That's a bad idea. Please stick to 2002::/16 or simply provide native IPv6 in your backbone.
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
We choosed to announce 2001:0:d911:c000::/52 as well as 2002:d911:c000::/36 in order to overcoming the anycast hassles for the first months. After that we had production stable IPv6 and dropped such tunneling hacks.
I oppose handing out large amounts of address space for such legacy methods to save costs in IPv6 rollout.
One major CPE vendor gave us a commitment for early next year. 6RD is in the next Linux kernel and also at least one of the large router vendors is implementing 6RD gateway functionality for mid next year regards Jan Am 25.11.2009 um 17:51 schrieb Mohacsi Janos:
On Wed, 25 Nov 2009, Florian Frotzler wrote:
Hi Lutz,
I totally disagree with you :-)
This would slow down the IPv6 rollout. IPv6-RD is a good choice to bring IPv6 quickly to the customers and fight with the dual stack implementation later. Maybe you are working at a small ISP, but in the real world there are a lot of hazards on the way to implement end2end v6, especially with large ISPs.
6rd is applicable only if the IP provider is controlling the CPE routers or 6rd is widely implemented in customers CPEs. So not so quick roll-out. Best Regards, Janos Mohacsi
Cheers, Florian
2009/11/25 Lutz Donnerhacke <lutz@iks-jena.de>:
In ripe.address-policy-wg, you wrote:
we are planning to offer IPv6 connectivity to our xDSL and FTTH customer base via IPv6-6RD.
That's a bad idea. Please stick to 2002::/16 or simply provide native IPv6 in your backbone.
We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet).
We choosed to announce 2001:0:d911:c000::/52 as well as 2002:d911:c000::/36 in order to overcoming the anycast hassles for the first months. After that we had production stable IPv6 and dropped such tunneling hacks.
I oppose handing out large amounts of address space for such legacy methods to save costs in IPv6 rollout.
Dear Colleagues, During the discussion on the APWG list about 6rd, several people have inquired about the exact way Registration Services evaluates requests for 6rd deployment. This email will try to answer these inquiries. The RIPE NCC considers current policy to be completely agnostic to 6rd, it neither specifically supports nor disallows 6rd deployment. This means that Registration Services will evaluate IPv6 allocation requests that include 6rd deployments according to the established policies and procedures of justified need. During the evaluation of an IPv6 allocation request the IPRA will look at the assignment size and the expected number of assignments to arrive at the size of the allocation that is justified. When an LIR wants to deploy 6rd by encoding the full 32 bits of the IPv4 addresses in the IPv6 end-user prefix, the allocation that would be needed is often much larger than would otherwise be justified using this principle as almost all of the reserved end-user prefixes would remain unused. Two examples with some numbers: An average size ISP has 1 million residential customers, intends to deploy 6rd and assign each end-user a /48. 1 million /48 end-site assignments would justify a /28, ignoring for the moment other requirements such as LIR infrastructure that might require more space. Deploying 6rd by encoding the full 32 bits of the IPv4 address would inflate the need to a /16. Currently, in this case, the IPRA would not consider allocating a /16 to be justified. Another LIR, who has 3 million customers, intends to deploy 6rd with / 60 assignments. Currently, the IPRA would consider 3 million /60 assignments to fit into a /38, thus the default /32, while the 6rd deployment would require a /28. Note that neither of these LIRs would qualify easily for an additional allocation under the HD-ratio rules. Best regards, Alex Le Heux RIPE NCC
Hello list, On Thu, 2009-12-03 at 14:28 +0100, Alex Le Heux wrote:
Dear Colleagues,
During the discussion on the APWG list about 6rd, several people have inquired about the exact way Registration Services evaluates requests for 6rd deployment. This email will try to answer these inquiries.
The RIPE NCC considers current policy to be completely agnostic to 6rd, it neither specifically supports nor disallows 6rd deployment. This means that Registration Services will evaluate IPv6 allocation requests that include 6rd deployments according to the established policies and procedures of justified need.
<snip>
Another LIR, who has 3 million customers, intends to deploy 6rd with / 60 assignments. Currently, the IPRA would consider 3 million /60 assignments to fit into a /38, thus the default /32, while the 6rd deployment would require a /28.
Note that neither of these LIRs would qualify easily for an additional allocation under the HD-ratio rules.
I am curious how LIRs that employ 6RD today plan to motivate their need for the 15 extra /32:s they would be allocated following the example above, with the /28-instead-of-/32, once the 6RD transition phase is complete. IIRC RIPE are currently spacing their /32 assignments on a /29 basis. Eg, anticimex@hsa:~$ for i in `seq 0 8`; do whois 2a02:9a$i::/32 | egrep '(inet6num|netname)' ; done inet6num: 2a02:9a0::/32 netname: SE-SCS-20090203 inet6num: 2a00::/12 netname: EU-ZZ-2A00 [...] inet6num: 2a02:9a8::/32 netname: IT-SPIN-20090204 I guess that it would be trivial to fall back to the first /32, or whatever less-than-6RD-inflated prefix you had before, once the transition is over, as long as the LIR plans ahead accordingly. Best regards, -- Martin Millnert <millnert@csbnet.se>
participants (13)
-
Alex Le Heux -
Florian Frotzler -
Gert Doering -
Jan Boogman -
Lutz Donnerhacke -
Marco Hogewoning -
Mark Townsley -
Martin Millnert -
michael.dillon＠bt.com -
Mohacsi Janos -
Remco van Mook -
Sam.Wilson＠ed.ac.uk -
Sander Steffann