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).
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-----
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.
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.
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.
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.
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.
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
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.