|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: nanog@nanog.org From: Mel Beckman <mel@beckman.org> To: Baldur Norddahl <baldur.norddahl@gmail.com> Date: Wed, 15 Jul 2015 12:52:23 +0000 In-Reply-To: <CAPkb-7DHRwUoJ_1bS-ZW41RMEsDPwMvmBB2=nYyH2wjJs4_p=w@mail.gmail.com> Cc: "nanog@nanog.org" <nanog@nanog.org> Errors-To: nanog-bounces@nanog.org Did you deploy Mikrotik routers by any chance? -mel beckman > On Jul 15, 2015, at 3:29 AM, Baldur Norddahl <baldur.norddahl@gmail.com> = wrote: >=20 >> On 15 July 2015 at 02:02, Mike <mike-nanog@tiedyenetworks.com> wrote: >>=20 >> I am a small provider with a 16 bit asn, a /20 and a /22 of ipv4 and a /= 32 >> of v6, but no clue yet how to get from where I am today to where we all >> should be. The flame wars and vitrol and rhetoric is too much noise for = me >> to derive anything useful from. Someone needs to stand up and lead. I wi= ll >> happily follow. >>=20 >> Whats really needed, is for you gods of ipv6, to write that 'ipv6 for ip= v4 >> dummies', targeting service providers and telling us exactly what we nee= d >> to do. No religious wars about subnet allocation sizes or dhcpv6 vs slaa= c >> or anything. Tell us how to get it onto our network, give us reasonable >> deployment scenarios that leverage our experience with IPv4 and tell us >> what we are going to tell our customers. Help us understand WHY nat is n= ot >> a security model, and how to achieve the same benefits we have with nat >> now, in an ipv6 enabled world. >=20 >=20 > You can't be a "dummy" and a service provider... >=20 > There is a million ways to implement a service provider network and that > goes for both IPv4 and IPv6. Writing a simple text that covers all > possibilities is impossible. What is your setup like? >=20 > Implementing IPv6 can be very simple, almost just run the "on" command. O= r > it can be very hard. It depends on what equipment you got and what featur= es > you need. And your luck. >=20 > In my case it turned out to be hard. I thought it would be easy. I bought > equipment that had IPv6 written all over it and it was a greenfield > network. The plan was to have IPv6 from birth. That was not to be. >=20 > A year later knew far too much about: >=20 > DHCPv6 relay chaining - not supported. Relay chaining is when you have th= e > access switch tag the DHCPv6 request with a customer identifier and then > your access router has to do DHCPv6 relay on that. >=20 > DHCPv6 relay in supervlan - not supported. >=20 > IPv6 must not be enabled at the same time as MPLS layer 2 VPN (VPLS). >=20 > DHCPv6-PD: When we said we had DHCPv6 support we meant IA_NA not IA_PD. > DHCPv6 snooping not supported with prefix delegation. >=20 > MPLS VPNv6 not supported. >=20 > IPv6 prefixes more specific than /64 gets routed in CPU without any > warnings. >=20 > No support for route injection by DHCPv6-PD snooping. >=20 > Oh and they just said they fixed most of the above issue in a new firmwar= e > that is not compatible with the hardware I got. >=20 > I am afraid that even in 2015 many IPv6 implementations are still half > baked. I was left feeling like I was the first guy to actually test this > stuff. >=20 > I managed to duct tape it all together despite the above limitations. But > forget about easy. >=20 > Regards, >=20 > Baldur
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |