This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg] IPv6 prefix delegation BCOP document available for comments and suggestions
- Previous message (by thread): [ipv6-wg] IPv6 prefix delegation BCOP document available for comments and suggestions
- Next message (by thread): [ipv6-wg] IPv6 prefix delegation BCOP document available for comments and suggestions
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Claudio Ferronato
claudio.ferronato at hynet.it
Thu Apr 6 10:16:10 CEST 2017
Il 06/04/2017 07:04, Mikael Abrahamsson ha scritto: > On Wed, 5 Apr 2017, Claudio Ferronato wrote: > >> Because I'm talking from a WISP perspective, where there isn't a >> "real" access switch. > > There can be. Slide 10. > > https://meetings.ripe.net/see5/files/SEE5_20160419_IPv6_Community_Wifi_Final.pdf Ok, thank you. But, this is a kind of configuration that not so many WISP could accept easily. If the CPE (and not UE) does captive portal login (maybe via MAC auth), to give global IPv6 addresses, it can be reachable from the Internet and this widen the surface attack (http://tinyurl.com/z2dvvfl). Yes, firewall rules are a good solution, but another way is to simply bridge ethernet to radio interface. There are some drawbacks of the last way, as PPPoE encapsulation removes the capacity to do QoS for VoIP traffic on the CPE device. But the main point is: pppoe is not dead (yet). Regards Claudio
- Previous message (by thread): [ipv6-wg] IPv6 prefix delegation BCOP document available for comments and suggestions
- Next message (by thread): [ipv6-wg] IPv6 prefix delegation BCOP document available for comments and suggestions
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]