Re: new(ish) ipv6 transition tech status on CPE

[Brock Tice]

On 10/11/2018 09:39 PM, Tom Ammon wrote:
> What did you experience with the dual-stack/CGN approach that keeps you
> from recommending it?

Nothing, sorry if my writing was confusing. It was the 464XLAT that I
don't recommend at this time, lack of vendor support by the brands we
currently use (especially Mikrotik and Ubiquiti) was the main issue.

RE: new(ish) ipv6 transition tech status on CPE

[Aaron Gould]

In my CGNat environment (~11,000 subs (5,000 dsl & 6,000 cable modem)) I had to 
solve issues with site-to-site vpn, console gaming and some webmail and banking 
web sites that seem to hand off authentication to another site and try to carry 
over the ip address … also had to try to accomplish load sharing amongst (3) 
cgnat nodes on my vrf-to-vrf boundary where I do natting…  here’s some things 
we did…

 

APP - consistent mapping for priv to pub ip's

 

EIM – stabilizes ports outbound

 

EIF - stabilizes ports inbound and allows for some hold-over (actual pinhole 
openings) for further comms from outside---to>inside

 

AMS LB - ams load balancing to occur on src-ip for removing the chance for more 
ip change*

 

AMS Member Failure options - more of adding resilience if/when underlying npu's 
fail

 

IGP (OSPF/LDP) routing - not cgnat related at all, and i recall more for load 
sharing amongst my mx960but was a big win for us when we found the (set 
protocols ldp track-igp-metric) trick or causing my PE's that would then use 
the real igp metric to route to the *igp closest* cgnat node 
(mx960/ms-mpc-128g) thus causing that cgnat node to always be used for that 
pe's set of priv ip subs... you must know that i had a triple cgnat node 
boundary ((3) mx960's w/ms-mpc's) and here again had an issue with all traffic 
going to the lowest bgp loopback ip tiebreaker since apparently inet.3 has 
metric 1 for every prefix... that trick ldp command copies inet.0 metric into 
inet.3 thus giving some real igp metric consideration to the bgp best path 
calculation

 

 

* pub ip pool is divided up over the number for npu/vpic's that are aggregated 
together in an ams... so there is a chance that your priv ip's will be hashed 
over any and all npu's thus causing greater change of pub ip differences

 

Btw, there are keepalives for eif and sessions limits for resource issues to be 
considered

 

- Aaron

 

From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Philip Loenneker
Sent: Thursday, October 11, 2018 10:58 PM
To: NANOG
Subject: RE: new(ish) ipv6 transition tech status on CPE

 

Hi Tom,

 

CGNAT is the most supported by the technology available in pretty much every 
device. Even keeping an audit trail of IP/port mappings is relatively easy 
(look into deterministic NAT – it will save you a lot of headache). You can 
likely lab it up with gear you already have, unlike the newer transition 
technologies that we’ve been discussing.

 

However, from my experience, the customer impact of going through 2 layers of 
NAT (NAT44) causes a lot of unhappy customers. I enabled it on my home 
connection for a few weeks to see how it went, and I was surprised that a lot 
of things just worked… Youtube, Netflix, etc had no issues. But there were key 
things such as Facebook Messenger voice and video calls that broke, which 
caused my family to get rather upset with me. Console gaming is also a common 
area of problems. For these types of Internet services, the profit margin can 
get eaten up quickly by the helpdesk calls.

 

As a side note, from internal discussions here (ie speculation, no real 
evidence to back it up), home users are likely to be impacted far more than 
business users, due to the difference in usage. 

 

Regards,

Philip

 

From: NANOG  On Behalf Of Tom Ammon
Sent: Friday, 12 October 2018 2:39 PM
To: NANOG 
Subject: Re: new(ish) ipv6 transition tech status on CPE

 

 

On Wed, Oct 10, 2018 at 3:08 PM Brock Tice  wrote:

On 10/09/2018 06:24 PM, Philip Loenneker wrote:
> I have asked several vendors we deal with about the newer technologies
> such as 464XLAT, and have had some responses indicating they will
> investigate internally, however we have not made much progress yet. One
> vendor suggested their device supports NAT46 and NAT64 so may support
> 464XLAT, but since it is incidental rather than an official feature, it
> may not support the full CLAT requirements. I have been meaning to do
> some tests but haven’t had a chance yet. It is also a higher price point
> than our current CPEs.
> 
>  
> 
> I have spoken to people who have looked into options such as OpenWRT
> (which supports several of these technolgoies), however the R and
> ongoing support is a significant roadblock to overcome.
> 

We looked into this somewhat intently ~6 months ago and had not much
luck from vendors. Barely on their radar if at all.

We used our own custom OpenWRT build on a few select, tested consumer
routers to do 464XLAT. In the end we went to dual-stack with CGN on
IPv4. I wrote up some documentation on how we did it on my blog, but in
the end I can't recommend the setup we used.

I would love RouterOS and (various mfgr) CPE support for 464XLAT, then I
would be ready to give it another shot.




It sounds like I am where you were 6 months ago. We've been looking at NAT64, 
MAP-T, potentially 464XLAT, and then dual stack with CGN on the v4 si

RE: new(ish) ipv6 transition tech status on CPE

[Philip Loenneker]

Hi Tom,

CGNAT is the most supported by the technology available in pretty much every 
device. Even keeping an audit trail of IP/port mappings is relatively easy 
(look into deterministic NAT – it will save you a lot of headache). You can 
likely lab it up with gear you already have, unlike the newer transition 
technologies that we’ve been discussing.

However, from my experience, the customer impact of going through 2 layers of 
NAT (NAT44) causes a lot of unhappy customers. I enabled it on my home 
connection for a few weeks to see how it went, and I was surprised that a lot 
of things just worked… Youtube, Netflix, etc had no issues. But there were key 
things such as Facebook Messenger voice and video calls that broke, which 
caused my family to get rather upset with me. Console gaming is also a common 
area of problems. For these types of Internet services, the profit margin can 
get eaten up quickly by the helpdesk calls.

As a side note, from internal discussions here (ie speculation, no real 
evidence to back it up), home users are likely to be impacted far more than 
business users, due to the difference in usage.

Regards,
Philip

From: NANOG  On Behalf Of Tom Ammon
Sent: Friday, 12 October 2018 2:39 PM
To: NANOG 
Subject: Re: new(ish) ipv6 transition tech status on CPE


On Wed, Oct 10, 2018 at 3:08 PM Brock Tice 
mailto:br...@bmwl.co>> wrote:
On 10/09/2018 06:24 PM, Philip Loenneker wrote:
> I have asked several vendors we deal with about the newer technologies
> such as 464XLAT, and have had some responses indicating they will
> investigate internally, however we have not made much progress yet. One
> vendor suggested their device supports NAT46 and NAT64 so may support
> 464XLAT, but since it is incidental rather than an official feature, it
> may not support the full CLAT requirements. I have been meaning to do
> some tests but haven’t had a chance yet. It is also a higher price point
> than our current CPEs.
>
>
>
> I have spoken to people who have looked into options such as OpenWRT
> (which supports several of these technolgoies), however the R and
> ongoing support is a significant roadblock to overcome.
>

We looked into this somewhat intently ~6 months ago and had not much
luck from vendors. Barely on their radar if at all.

We used our own custom OpenWRT build on a few select, tested consumer
routers to do 464XLAT. In the end we went to dual-stack with CGN on
IPv4. I wrote up some documentation on how we did it on my blog, but in
the end I can't recommend the setup we used.

I would love RouterOS and (various mfgr) CPE support for 464XLAT, then I
would be ready to give it another shot.

It sounds like I am where you were 6 months ago. We've been looking at NAT64, 
MAP-T, potentially 464XLAT, and then dual stack with CGN on the v4 side. What 
did you experience with the dual-stack/CGN approach that keeps you from 
recommending it? Academically, that setup seems the least fraught with problems 
among all of the options.




--
-
Tom Ammon
M: (801) 784-2628
thomasam...@gmail.com<mailto:thomasam...@gmail.com>
-

Re: new(ish) ipv6 transition tech status on CPE

[Tom Ammon]

On Wed, Oct 10, 2018 at 3:08 PM Brock Tice  wrote:

> On 10/09/2018 06:24 PM, Philip Loenneker wrote:
> > I have asked several vendors we deal with about the newer technologies
> > such as 464XLAT, and have had some responses indicating they will
> > investigate internally, however we have not made much progress yet. One
> > vendor suggested their device supports NAT46 and NAT64 so may support
> > 464XLAT, but since it is incidental rather than an official feature, it
> > may not support the full CLAT requirements. I have been meaning to do
> > some tests but haven’t had a chance yet. It is also a higher price point
> > than our current CPEs.
> >
> >
> >
> > I have spoken to people who have looked into options such as OpenWRT
> > (which supports several of these technolgoies), however the R and
> > ongoing support is a significant roadblock to overcome.
> >
>
> We looked into this somewhat intently ~6 months ago and had not much
> luck from vendors. Barely on their radar if at all.
>
> We used our own custom OpenWRT build on a few select, tested consumer
> routers to do 464XLAT. In the end we went to dual-stack with CGN on
> IPv4. I wrote up some documentation on how we did it on my blog, but in
> the end I can't recommend the setup we used.
>
> I would love RouterOS and (various mfgr) CPE support for 464XLAT, then I
> would be ready to give it another shot.
>

It sounds like I am where you were 6 months ago. We've been looking at
NAT64, MAP-T, potentially 464XLAT, and then dual stack with CGN on the v4
side. What did you experience with the dual-stack/CGN approach that keeps
you from recommending it? Academically, that setup seems the least fraught
with problems among all of the options.




-- 
-
Tom Ammon
M: (801) 784-2628
thomasam...@gmail.com
-

Re: new(ish) ipv6 transition tech status on CPE

[Brock Tice]

On 10/09/2018 06:24 PM, Philip Loenneker wrote:
> I have asked several vendors we deal with about the newer technologies
> such as 464XLAT, and have had some responses indicating they will
> investigate internally, however we have not made much progress yet. One
> vendor suggested their device supports NAT46 and NAT64 so may support
> 464XLAT, but since it is incidental rather than an official feature, it
> may not support the full CLAT requirements. I have been meaning to do
> some tests but haven’t had a chance yet. It is also a higher price point
> than our current CPEs.
> 
>  
> 
> I have spoken to people who have looked into options such as OpenWRT
> (which supports several of these technolgoies), however the R and
> ongoing support is a significant roadblock to overcome.
> 

We looked into this somewhat intently ~6 months ago and had not much
luck from vendors. Barely on their radar if at all.

We used our own custom OpenWRT build on a few select, tested consumer
routers to do 464XLAT. In the end we went to dual-stack with CGN on
IPv4. I wrote up some documentation on how we did it on my blog, but in
the end I can't recommend the setup we used.

I would love RouterOS and (various mfgr) CPE support for 464XLAT, then I
would be ready to give it another shot.

Re: new(ish) ipv6 transition tech status on CPE

[Ca By]

On Wed, Oct 10, 2018 at 6:50 AM Philip Loenneker <
philip.loenne...@tasmanet.com.au> wrote:

> Hi Tom,
>
>
>
> This article is now 11 months old, but may be of interest to you:
>
> https://blog.apnic.net/2017/11/09/ce-vendors-share-thoughts-ipv6-support/
>
>
>
> Some quotes:
>
>- The major issue is the lack of support provided by CE vendors for
>both older (DS-Lite, lw4o6), and newer (464XLAT, MAP T/E) transition
>mechanisms. Some vendors provide it ‘on-demand’ for big customers, but
>small and medium ISPs don’t have the same purchasing capability, creating a
>big issue for deployment.
>- All panellists said their service providers’ products supported
>lw4o6, MAP-E/T, and 464XLAT, but because of the lack of support for these
>mechanisms in RFC7084, it is not standard in retail CE.
>- There are no new hardware requirements that will exclude vendors
>supporting all these transitions mechanisms — it is really a matter of very
>few kilobytes.
>- The panel agreed that minimum orders were not considered when
>implementing these mechanisms. For them, the fact is that IPv6 needs to be
>implemented, and there is a need to support new transition mechanisms and
>support service providers and retail users. Also, there is a need for
>products to pass some certification requirements (again the idea of
>RFC7084-bis is strongly supported by the panellists).
>
>
>
> Telstra did a presentation as AusNOG back in September discussing their
> IPv6 implementation which was really great to see. They have their own
> branded CPEs with 464XLAT. Unfortunately I don’t think there is a video of
> it, only a rather short slide deck. You can see it here:
>
>
> https://www.ausnog.net/sites/default/files/ausnog-2018/presentations/2.8_David_Woolley_AusNOG2018.pdf
>
>
>
> I have asked several vendors we deal with about the newer technologies
> such as 464XLAT, and have had some responses indicating they will
> investigate internally, however we have not made much progress yet. One
> vendor suggested their device supports NAT46 and NAT64 so may support
> 464XLAT, but since it is incidental rather than an official feature, it may
> not support the full CLAT requirements. I have been meaning to do some
> tests but haven’t had a chance yet. It is also a higher price point than
> our current CPEs.
>
>
>
> I have spoken to people who have looked into options such as OpenWRT
> (which supports several of these technolgoies), however the R and ongoing
> support is a significant roadblock to overcome.
>
>
>
> I would like to hear how others are implementing these transition
> technologies.
>
>
>

Just my own personal musing below

There several mobile providers that planning to use 5G/4G for home
broadband.  Some are going to focus on urban areas while others will focus
on rural areas.

My expectation is that that these mobile providers will bring their
existing mobile approach to the wireless home broadband space.  That said,
i believe 464XLAT specifically will be used in home router deployments that
will have a mobile modem.  These devices are likely to look more like home
gateways than existing mobile  hotspot pucks.

Regards,
>
> Philip
>
>
>
>
>
> *From:* NANOG  *On Behalf Of *Tom Ammon
> *Sent:* Sunday, 7 October 2018 12:59 PM
> *To:* NANOG 
> *Subject:* new(ish) ipv6 transition tech status on CPE
>
>
>
> Are there any CPE vendors providing MAP-T features yet? I'm working on
> rolling v6 to residential subscribers and am trying to understand what the
> landscape looks like on the CPE side, for MAP-T specifically.
>
>
>
> What about 464XLAT on a CPE - is that a thing? I know that 464XLAT has
> been running for a while on some mobile provider networks, but are there
> any vendors out there with a decent/mature CLAT implementation in a CPE
> product that is ready to buy right now?
>
>
>
> Thanks,
>
> Tom
>
>
>
> --
>
>
> -
> Tom Ammon
> M: (801) 784-2628
> thomasam...@gmail.com
>
> -
>

RE: new(ish) ipv6 transition tech status on CPE

[Philip Loenneker]

Hi Tom,

This article is now 11 months old, but may be of interest to you:
https://blog.apnic.net/2017/11/09/ce-vendors-share-thoughts-ipv6-support/

Some quotes:

  *   The major issue is the lack of support provided by CE vendors for both 
older (DS-Lite, lw4o6), and newer (464XLAT, MAP T/E) transition mechanisms. 
Some vendors provide it ‘on-demand’ for big customers, but small and medium 
ISPs don’t have the same purchasing capability, creating a big issue for 
deployment.
  *   All panellists said their service providers’ products supported lw4o6, 
MAP-E/T, and 464XLAT, but because of the lack of support for these mechanisms 
in RFC7084, it is not standard in retail CE.
  *   There are no new hardware requirements that will exclude vendors 
supporting all these transitions mechanisms — it is really a matter of very few 
kilobytes.
  *   The panel agreed that minimum orders were not considered when 
implementing these mechanisms. For them, the fact is that IPv6 needs to be 
implemented, and there is a need to support new transition mechanisms and 
support service providers and retail users. Also, there is a need for products 
to pass some certification requirements (again the idea of RFC7084-bis is 
strongly supported by the panellists).

Telstra did a presentation as AusNOG back in September discussing their IPv6 
implementation which was really great to see. They have their own branded CPEs 
with 464XLAT. Unfortunately I don’t think there is a video of it, only a rather 
short slide deck. You can see it here:
https://www.ausnog.net/sites/default/files/ausnog-2018/presentations/2.8_David_Woolley_AusNOG2018.pdf

I have asked several vendors we deal with about the newer technologies such as 
464XLAT, and have had some responses indicating they will investigate 
internally, however we have not made much progress yet. One vendor suggested 
their device supports NAT46 and NAT64 so may support 464XLAT, but since it is 
incidental rather than an official feature, it may not support the full CLAT 
requirements. I have been meaning to do some tests but haven’t had a chance 
yet. It is also a higher price point than our current CPEs.

I have spoken to people who have looked into options such as OpenWRT (which 
supports several of these technolgoies), however the R and ongoing support is 
a significant roadblock to overcome.

I would like to hear how others are implementing these transition technologies.

Regards,
Philip


From: NANOG  On Behalf Of Tom Ammon
Sent: Sunday, 7 October 2018 12:59 PM
To: NANOG 
Subject: new(ish) ipv6 transition tech status on CPE

Are there any CPE vendors providing MAP-T features yet? I'm working on rolling 
v6 to residential subscribers and am trying to understand what the landscape 
looks like on the CPE side, for MAP-T specifically.

What about 464XLAT on a CPE - is that a thing? I know that 464XLAT has been 
running for a while on some mobile provider networks, but are there any vendors 
out there with a decent/mature CLAT implementation in a CPE product that is 
ready to buy right now?

Thanks,
Tom

--
-
Tom Ammon
M: (801) 784-2628
thomasam...@gmail.com
-

Re: new(ish) ipv6 transition tech status on CPE

[JORDI PALET MARTINEZ via NANOG]

You may use this document, which passed already the last-call and is in the 
AD/IESG review:

 

https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/

 

My co-authors may help you to get those products …

 

I’ve been using myself OpenWRT for such deployments.


Regards,

Jordi

 

 

 

De: NANOG  en nombre de Tom Ammon 

Fecha: miércoles, 10 de octubre de 2018, 0:14
Para: NANOG 
Asunto: new(ish) ipv6 transition tech status on CPE

 

Are there any CPE vendors providing MAP-T features yet? I'm working on rolling 
v6 to residential subscribers and am trying to understand what the landscape 
looks like on the CPE side, for MAP-T specifically.

 

What about 464XLAT on a CPE - is that a thing? I know that 464XLAT has been 
running for a while on some mobile provider networks, but are there any vendors 
out there with a decent/mature CLAT implementation in a CPE product that is 
ready to buy right now?

 

Thanks, 

Tom

 

-- 

-
Tom Ammon
M: (801) 784-2628
thomasam...@gmail.com
-



**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
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.

Re: new(ish) ipv6 transition tech status on CPE

[Daniel Corbe]

Tom Ammon  writes:

> Are there any CPE vendors providing MAP-T features yet? I'm working on 
> rolling v6 to residential subscribers and am trying to
> understand what the landscape looks like on the CPE side, for MAP-T 
> specifically.
>
> What about 464XLAT on a CPE - is that a thing? I know that 464XLAT has been 
> running for a while on some mobile provider networks,
> but are there any vendors out there with a decent/mature CLAT implementation 
> in a CPE product that is ready to buy right now?
>

Good luck.   I've been barking up the MAP-T tree with cable modem
vendors for a couple of years already.   Since I have literally 0 buying
power in comparison to the likes of Comcast and Cox, I've gotten nowhere.

-Daniel