Auto-configuring IPv6 transition mechanisms on customer devices
Are there any (draft, standard, or otherwise) defined mechanisms for indicating to customer-provided devices that they should configure IPv6 to IPv4 transition mechanisms such as MAP, 4rd, 464XLAT, etc. and providing the configuration details thereof? I'm not aware of any. It seems like this is something that, if defined, would make deployment of such mechanisms a lot easier even if SPs provide the customer edge router that implements said mechanisms. I guess they'd probably be implemented as extensions to DHCPv6 or similar or embedded in RAs (the latter seems ugly). -- Brandon Martin
Hi Brandon, This may help: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ It is in last call right now, I need to send a new version today/tomorrow, as the IESG review had some inputs, but nothing that change the document as you can read it now. Regards, Jordi -----Mensaje original----- De: NANOG <nanog-bounces@nanog.org> en nombre de Brandon Martin <lists.nanog@monmotha.net> Fecha: viernes, 14 de diciembre de 2018, 17:20 Para: "nanog@nanog.org" <nanog@nanog.org> Asunto: Auto-configuring IPv6 transition mechanisms on customer devices Are there any (draft, standard, or otherwise) defined mechanisms for indicating to customer-provided devices that they should configure IPv6 to IPv4 transition mechanisms such as MAP, 4rd, 464XLAT, etc. and providing the configuration details thereof? I'm not aware of any. It seems like this is something that, if defined, would make deployment of such mechanisms a lot easier even if SPs provide the customer edge router that implements said mechanisms. I guess they'd probably be implemented as extensions to DHCPv6 or similar or embedded in RAs (the latter seems ugly). -- Brandon Martin ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
On Fri, 14 Dec 2018, Brandon Martin wrote:
Are there any (draft, standard, or otherwise) defined mechanisms for indicating to customer-provided devices that they should configure IPv6 to IPv4 transition mechanisms such as MAP, 4rd, 464XLAT, etc. and providing the configuration details thereof?
I'm not aware of any. It seems like this is something that, if defined, would make deployment of such mechanisms a lot easier even if SPs provide the customer edge router that implements said mechanisms. I guess they'd probably be implemented as extensions to DHCPv6 or similar or embedded in RAs (the latter seems ugly).
We use this to configure LW4o6 tunnels using DHCPv6. This is already present in OpenWrt via the MAP package. It supports both MAP-E and LW4o6. https://tools.ietf.org/html/rfc7598 DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices. Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address plus Port (A+P) for providing IPv4 connectivity across an IPv6 network. -- Mikael Abrahamsson email: swmike@swm.pp.se
On 12/14/18 11:51 AM, Mikael Abrahamsson wrote:
We use this to configure LW4o6 tunnels using DHCPv6. This is already present in OpenWrt via the MAP package. It supports both MAP-E and LW4o6.
So I guess you're deploying "RG" style CPE routers to your customers that you've loaded OpenWRT onto? How's the maintainability of that? Any hardware recommendations? The mechanisms mentioned in this thread are exactly what I'm looking for, but I'm having trouble finding any COTS vendor support for them. I'm sure if I wanted to buy 100k units, somebody would put out some custom firmware for me, but as the network I'm doing this on is a brand new startup in a somewhat sparsely populated area, I'd be buying dozens at a time, not thousands. -- Brandon Martin
On Wed, 2 Jan 2019, Brandon Martin wrote:
On 12/14/18 11:51 AM, Mikael Abrahamsson wrote:
We use this to configure LW4o6 tunnels using DHCPv6. This is already present in OpenWrt via the MAP package. It supports both MAP-E and LW4o6.
So I guess you're deploying "RG" style CPE routers to your customers that you've loaded OpenWRT onto? How's the maintainability of that? Any hardware recommendations?
Yes, we're buying devices from a vendor that uses OpenWrt as base for their operating system. We're using this one currently: https://www.intenogroup.com/products/gateways/eg400/ We remotely manage it using Netconf/YANG from our NMS so we can do software upgrades (and other management). If you have low volume you can of course use SSH and script it if that's what you want. They also have TR-69 based management, and perhaps others.
The mechanisms mentioned in this thread are exactly what I'm looking for, but I'm having trouble finding any COTS vendor support for them. I'm sure if I wanted to buy 100k units, somebody would put out some custom firmware for me, but as the network I'm doing this on is a brand new startup in a somewhat sparsely populated area, I'd be buying dozens at a time, not thousands.
Get in touch with them, tell them I said hi. They might be able to accomodate your low volume by sending you gateways with their default software on it and you'd have to upgrade it to whatever image you want on it, yourself. It only takes a few minutes per box so should be perfectly doable with your low volume. -- Mikael Abrahamsson email: swmike@swm.pp.se
On 1/2/19 7:37 AM, Mikael Abrahamsson wrote:
Yes, we're buying devices from a vendor that uses OpenWrt as base for their operating system. We're using this one currently:
https://www.intenogroup.com/products/gateways/eg400/
We remotely manage it using Netconf/YANG from our NMS so we can do software upgrades (and other management). If you have low volume you can of course use SSH and script it if that's what you want. They also have TR-69 based management, and perhaps others.
If only Ubiquiti had so many (documented) options for management...
Get in touch with them, tell them I said hi. They might be able to accomodate your low volume by sending you gateways with their default software on it and you'd have to upgrade it to whatever image you want on it, yourself. It only takes a few minutes per box so should be perfectly doable with your low volume That could work. I'll give them a shout. Thanks for the pointer.
Out of curiosity, what do you use to terminate the MAP/LW4o6 tunnels/encaps to the public Internet? Plenty of options here, of course, especially at the traffic rates I'm moving. I'm just curious what others' experiences have been as these are still somewhat new in SP deployments, I think. -- Brandon Martin
On Wed, 2 Jan 2019, Brandon Martin wrote:
Out of curiosity, what do you use to terminate the MAP/LW4o6 tunnels/encaps to the public Internet? Plenty of options here, of course, especially at the traffic rates I'm moving. I'm just curious what others' experiences have been as these are still somewhat new in SP deployments, I think.
We use https://github.com/snabbco/snabb lwAFTR. We deploy an anycast based solution with self-check and ExaBGP to announce the anycast next-hop the RGs after the lwAFTR instance passes its self check. That means we can deploy these geographically diversely and also with redundancy, and can hitlessly take them out of service if needed. -- Mikael Abrahamsson email: swmike@swm.pp.se
On 1/2/19 7:59 AM, Brandon Martin wrote:
On 1/2/19 7:37 AM, Mikael Abrahamsson wrote:
Yes, we're buying devices from a vendor that uses OpenWrt as base for their operating system. We're using this one currently:
https://www.intenogroup.com/products/gateways/eg400/
We remotely manage it using Netconf/YANG from our NMS so we can do software upgrades (and other management). If you have low volume you can of course use SSH and script it if that's what you want. They also have TR-69 based management, and perhaps others.
If only Ubiquiti had so many (documented) options for management...
DHCPv6 is fine. Jordi did a panel a year ago at APNIC where he browbeat vendors about supporting transition mechanisms. The summary is that they said they have code, they just don't want to ship everything, because it's more to maintain. https://blog.apnic.net/2017/11/09/ce-vendors-share-thoughts-ipv6-support/ This led to the draft he mentioned upthread, requiring support. OpenWRT is still the only thing I've seen that wasn't a customer-specific build.
Get in touch with them, tell them I said hi. They might be able to accomodate your low volume by sending you gateways with their default software on it and you'd have to upgrade it to whatever image you want on it, yourself. It only takes a few minutes per box so should be perfectly doable with your low volume That could work. I'll give them a shout. Thanks for the pointer.
Out of curiosity, what do you use to terminate the MAP/LW4o6 tunnels/encaps to the public Internet? Plenty of options here, of course, especially at the traffic rates I'm moving. I'm just curious what others' experiences have been as these are still somewhat new in SP deployments, I think.
Open source software. For stateless transition mechanisms (MAP/LW4o6) it can be really fast. We have a build I'd be happy to share, if you want. Lee
On 1/2/19 10:10 AM, Lee Howard wrote:
DHCPv6 is fine.
Jordi did a panel a year ago at APNIC where he browbeat vendors about supporting transition mechanisms. The summary is that they said they have code, they just don't want to ship everything, because it's more to maintain. https://blog.apnic.net/2017/11/09/ce-vendors-share-thoughts-ipv6-support/
This led to the draft he mentioned upthread, requiring support. OpenWRT is still the only thing I've seen that wasn't a customer-specific build.
DHCPv6 looks perfectly fine for distributing LW4o6/MAP config info. That makes perfect sense as it's essentially part of address/interface configuration just for accessing an alternate protocol. I was referring more to the dearth of broader-range management features on Ubiquiti gear in particular. Get what you pay for, I guess. It slings packets just fine.
Open source software. For stateless transition mechanisms (MAP/LW4o6) it can be really fast. We have a build I'd be happy to share, if you want.
Oh I was certainly planning to use a OSS software platform. I'm sub-Gbps at the moment. I could probably do it on a RasPi. The SNABB lwAFTR option Mikael referred to looks like it would work fine but has some deployment complexities related to its focus on higher performance that are likely not relevant in my present situation, so I'd certainly be interested in other options. -- Brandon Martin
participants (4)
-
Brandon Martin -
JORDI PALET MARTINEZ -
Lee Howard -
Mikael Abrahamsson