Second Call for IPv6 WG agenda items
Hi, The RIPE meeting is now only a month away and we have not received a lot of proposals for our session yet. We would appreciate if you could approach us with proposals as soon as possible as we would like to publish a draft agenda well before the meeting. All topics that can contribute to a better understanding of the issues involved with the deployment of IPv6 are welcome: we can accommodate a single question that needs discussion to more complicated topics that need slides. Finally, other proposals for the plenary program can be submitted to the program committee via http://ripe63.ripe.net/programme/submit-a-topic/. Thanks, David, Marco and Shane --- Date: Mon, 29 Aug 2011 15:22:23 +0200 From: Marco Hogewoning <marcoh@marcoh.net> To: ipv6-wg@ripe.net Subject: [ipv6-wg] RIPE 63 Registration and call for IPv6 WG agenda items Dear Colleagues, Registration for RIPE 63 is now open, this meeting will take place from October 31 until November 4 in Vienna, Austria. More information about this meeting, the venue and the online registration form can be found at http://ripe63.ripe.net/. If you wish to add an item to the IPv6 Working Group agenda, either something to discuss or something you want to present, please contact us via ipv6-wg-chairs [at] ripe [dot] net. Alternatively proposals for content can be submitted to the programme committee via http://ripe63.ripe.net/programme/submit-a-topic/. Deadline for these proposals is September 18th. We hope to see you all in Vienna, The chairs of the IPv6 Working Group, Marco, David and Shane ----- End forwarded message -----
Hi, Trying to figure out how to do IPv6 address allocation for consumer customers connecting their end-hosts (Windows/OSX/Linux) directly to a Carrier Ethernet network/VLAN (obviously through some sort of fiber-to-Ethernet converter/bridge). The particular problem bothering me is user-to-address mapping traceability that you might need for regulatory/law enforcement reasons. I see the following options: #1 - use DHCPv6 instead of SLAAC ================================ Requires support for DHCPv6 Option37/38 and L3 switches all the way to the end-user (unless your favorite vendor supports L2 DHCPv6 extensions) and allows any third-party to track the user based on pretty static IPv6 address. Also requires DHCPv6 snooping/IPv6 source guard to prevent overly-easy spoofing. #2 - use SLAAC and don't care ============================= Consumer hosts will get random IPv6 addresses out of your Carrier Ethernet /64 prefix. Can you afford the "don't care" part of it? #3 - use CPE devices that only allow DHCPv6 IA_PD ================================================= This might be the cleanest approach (you map the customer into an IPv6 prefix), but it requires strict control of the CPE devices by the SP (think cable modems). #4 - use PPPoE over Carrier Ethernet ==================================== Been there, seen that. Not sure we can afford the performance/licensing hits. However, it does solve the authentication problems (PAP/CHAP), address tracking (RADIUS accounting records), randomized addresses (use local pool on the PE-router). Anything I've missed or is it really so bleak? Thanks Ivan
Hi,
#2 - use SLAAC and don't care ============================= Consumer hosts will get random IPv6 addresses out of your Carrier Ethernet /64 prefix. Can you afford the "don't care" part of it?
There is a sub-option here: use SLAAC and track/log which address is used by which customer (based on port and/or MAC address). It is easiest for the end user, it will provide data for the LEA, but it does require monitoring and logging of ND traffic. I know that some Dutch universities are doing it like this. Met vriendelijke groet, Sander Steffann
On 9/29/11 10:32 AM, Ivan Pepelnjak wrote:
#4 - use PPPoE over Carrier Ethernet ==================================== Been there, seen that. Not sure we can afford the performance/licensing hits.
However, it does solve the authentication problems (PAP/CHAP), address tracking (RADIUS accounting records), randomized addresses (use local pool on the PE-router).
Anything I've missed or is it really so bleak?
MIP6 or DSMIP6-TLS is also an option, but we need more mature product for that in the near future. /jan
#2 - use SLAAC and don't care ============================= Consumer hosts will get random IPv6 addresses out of your Carrier Ethernet /64 prefix. Can you afford the "don't care" part of it?
We provide a static /64 with SLAAC per connection, but allow static addresses within that /64 as well. Connections are provisioned as individual router subinterfaces, so user-to-address mapping happens on subnet level and URPF prevents spoofing. This naturally works only as long as you have a single customer/connection per VLAN, not so much with group-VLANs (which are shared by several connections). With SLAAC you can dig the MAC address from the IPv6-address, if necessary (MAC-spoofing can be a problem, but that's the case with DHCP and IPv4-world as well. ND-attacks are an issue as well.) The shortcomings with this approach include: - doesn't work with group-VLANs - the end-user has to configure DNS-servers manually ____________________________________ Tero Toikkanen Network Engineer Nebula Oy
You can't extract MAC from SLAACed IPv6 due to privacy extensions (RFC 4941). I like one-VLAN-per customer idea, but it doesn't always scale (in some environments you'd run out of VLANs). Thanks! Ivan
-----Original Message----- From: ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Tero Toikkanen Sent: Thursday, September 29, 2011 1:55 PM To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] End-host IPv6 address allocation on Carrier Ethernet
#2 - use SLAAC and don't care ============================= Consumer hosts will get random IPv6 addresses out of your Carrier Ethernet /64 prefix. Can you afford the "don't care" part of it?
We provide a static /64 with SLAAC per connection, but allow static addresses within that /64 as well. Connections are provisioned as individual router subinterfaces, so user-to-address mapping happens on subnet level and URPF prevents spoofing. This naturally works only as long as you have a single customer/connection per VLAN, not so much with group- VLANs (which are shared by several connections). With SLAAC you can dig the MAC address from the IPv6-address, if necessary (MAC-spoofing can be a problem, but that's the case with DHCP and IPv4-world as well. ND-attacks are an issue as well.)
The shortcomings with this approach include: - doesn't work with group-VLANs - the end-user has to configure DNS-servers manually
____________________________________ Tero Toikkanen Network Engineer Nebula Oy
You can't extract MAC from SLAACed IPv6 due to privacy extensions (RFC 4941).
Ah, I had already forgotten about that.
I like one-VLAN-per customer idea, but it doesn't always scale (in some environments you'd run out of VLANs).
Q-in-Q helps with the scaling, but admittedly only up to a certain point. As mentioned, we also have to come up with an alternative solution for the group-VLANs. So far DHCPv6 seems like the way to go in that case, but vendor support is still lacking. DHCPv6 IA_PD would be nice, but in 98% of the time we don't have control over the CPE. As Ivan mentioned, DHCPv6 Option37/38 would enable the same for IPv6, but the support just isn't there yet. Also, it's one thing to get vendor support and another thing to get bitstream operators to support it as well. ____________________________________ Tero Toikkanen Network Engineer Nebula Oy
On 9/29/11 2:04 PM, Ivan Pepelnjak wrote:
You can't extract MAC from SLAACed IPv6 due to privacy extensions (RFC 4941).
Listen on multicast and log. /jan
Hi, I'm Rolf from German Working Group on Data Retention (Arbeitskreis Vorratsdatenspeicherung). I'm on this list because we like to learn about the privacy impacts of the growing IPv6 deployment. On 29/09/11 10:32 +0200, Ivan Pepelnjak wrote:
Trying to figure out how to do IPv6 address allocation for consumer customers connecting their end-hosts (Windows/OSX/Linux) directly to a Carrier Ethernet network/VLAN (obviously through some sort of fiber-to-Ethernet converter/bridge).
The particular problem bothering me is user-to-address mapping traceability that you might need for regulatory/law enforcement reasons.
If I understand correctly there can not be a user-to-address mapping on IP level, just a nic-to-address mapping. In Germany it's not mandatory to log this kind of information proactively. Does law enforcement provide a list of mac address of the deviceѕ to be monitored? regards Rolf -- Sous les pavés, la plage
participants (7)
-
David Kessens -
Ivan Pepelnjak -
Jan Zorz -
Jan Zorz ＠ go6.si -
Rolf Kutz -
Sander Steffann -
Tero Toikkanen