Subject: Re: [v6ops] GRASP

From: Mark Smith <[email-masked]>
Date: Sun, 14 Jan 2018 14:54:13 +1100

Forgot to send this, still useful I think.

On 28 December 2017 at 10:07, james woodyatt <[email-masked]> wrote:
> On Dec 22, 2017, at 19:35, Brian E Carpenter <[email-masked]>
> wrote:
>
>
> I don't see that argument for homenets. ISPs don't seem reluctant to hand
> out /64, /56 or /48 to paying subscribers. I can see that if you want to do
> something fancy while roaming, you might have to deal with a single /128.
>
>
> They are very reluctant to deploy CPE gateways that use any current or
> forthcoming protocol to delegate automatically any portion of their prefix
> to routers on home network links. In shorter terms, they are happy to hand
> out /56 (less so /48) to CPE edge routers owned by paying customers, but
> there is no appetite for supporting customers with interior routers
> downstream of the CPE edge router. Certainly not in their provider
> provisioned CPE gateway devices that are more often than not bundled in the
> service agreement and quietly included in the total charge for access. Oh,
> they might have plans to use that number space with some non-standard prefix
> distribution protocol, but it appears there is very little appetite for
> adopting any standard made available for third parties to use freely.
>
> That’s why anybody planning to offer consumers technology solutions that
> include IPv6 router functions running on nodes located behind CPE routers
> are forced to resort to address amplifying NAT to operate as a router on the
> downstream links and a host on the upstream home network link behind the CPE
> router. Just as happened with IPv4 for pretty much the same reasons. I’ve
> spent the better part of three years trying to avoid that conclusion, and my
> experience in V6OPS and HOMENET has led me to conclude that it was a badly
> wasted effort. NAT66 is the wave of the future.

Is NAT66 the only option?

It seems to me that one of the fundamental problems with NAT,
including 1:1 NAT, is that it is somewhere in between simple IP
forwarding based on the IP header, and full host/application
processing. The context and state held in the true end-host and
application is not available in the NAT66 device, and that is why it
can't do a fully transparent translation. The NAT device neither a
router or a host.

I wonder if it would be better to have the "NAT66" device be the true
application end-point for all communications, and then have it
communicate with the down stream devices "internally" via a ULA
address space, as internal application inter-process communication.
The external host/application then has all of the context and
application state necessary to function, so none of the NAT issues
occur. Internally, IPv6 with ULA address just happens be being used as
an application message bus between the downstream devices and the
globally reachable application endpoint.

If the downsteam devices need to have globally unique identifiers and
indirectly globally reachable and visible, they could be generic
UUIDs. They don't need to be IPv6 addresses, because all access to
them is via messages sent to the application with the global IPv6
address.

Regards,
Mark.

>
> --james woodyatt <[email-masked]>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Sander Steffann <[email-masked]>
Date: Sun, 14 Jan 2018 12:12:30 +0100

Hi,

> address space, as internal application inter-process communication.

So, back to using proxy servers then.
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Jan 2018 07:46:27 +1300

> So, back to using proxy servers then.

a) The faulty email quoting in Mark's message made it look as if I might
have been advocating NAT66 - not so, that was James in respnse to me.

b) I don't see using proxies as a step backwards. On the contrary,
with home networks in particular likely to contain increasing numbers
of IoT devices with poor security, proxying a network behind a reasonably
secure device seems like an excellent idea.

c) If James is correct about the attitude of ISPs we (for some sense of
"we") need to do something about it. ISPs are motivated by revenue and
OPEX. How can we make support of prefix delegation more attractive to
ISPs?

    Brian

---

From: Ole Troan <[email-masked]>
Date: Mon, 15 Jan 2018 09:38:22 +0100

> OPEX. How can we make support of prefix delegation more attractive to

Let's clarify this a bit to avoid misunderstandings.

ISPs _do_ prefix delegation today.

What is missing is any further use of that address block inside of the home network.

1) Subnet the delegated prefix and assign /64s  to local interfaces.
2) Static routes
3) Sub-delegation with DHCP PD
4) HNCP

As far as I know only 1 is commonly supported.

You can argue to what extent this is an ISP problem or something else, depending on where the demarcation point is.
Likely a chicken and egg problem too, since internal routers a) haven't been that common b) don't support HNCP, c) there hasn't been that much of a use case.

Perhaps if we James can describe his use case, that might give us a bit more leverage.

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 15 Jan 2018 11:24:42 +0100

> As far as I know only 1 is commonly supported.

2 is also supported in ISP for home network.  The ISP I use has a web 
GUI on the CPE on which the end user at home ('grandma') can fill in 
IPv6 static routes.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 15 Jan 2018 19:51:32 +0900

On Mon, Jan 15, 2018 at 7:24 PM, Alexandre Petrescu <
[email-masked]> wrote:

> 2 is also supported in ISP for home network.  The ISP I use has a web GUI
> on the CPE on which the end user at home ('grandma') can fill in IPv6
> static routes.
>

My ISP also happens to support #2. But support is definitely not universal.

---

From: james woodyatt <[email-masked]>
Date: Tue, 16 Jan 2018 12:02:47 -0800

> Perhaps if we James can describe his use case, that might give us a bit more leverage.

Again? Okay.

Consider the Nest Secure system of products, which includes Nest Guard, Nest Detect, Nest Tag, et cetera. One product in particular is called Nest Connect. It’s a simple wall wart that provides Thread/WiFi border routing functionality. This functionality is also included in Nest Guard and other products with better marketing, but if you have a big house and you need to connect a Nest Guard to a Nest Detect too far away to reach over Thread, then you would use a Nest Connect for that.

All these devices have a Wi-Fi interface and a Thread interface.

  <https://store.nest.com/product/nest-connect/ <https://store.nest.com/product/nest-connect/>>

Here’s more about Thread border routers from the nice people at OpenThread:

  <https://openthread.io/guides/border_router/ <https://openthread.io/guides/border_router/>>

The basic use case is that each Thread mesh that depends from the home Wi-Fi network requires its own /64 prefix. But the Nest Connect cannot reliably get one on practically any currently deployed home networks, even those like Comcast which provide IPv6 service to hosts. Neither can the Nest Guard or any of the other products in system that operate as Thread border routers. Thread™ is a network layer, and not an application layer, but without a reliable method of acquiring a prefix, a border router can only be made to function passably with a NAT66 function.

There is no reason to be optimistic this will change. And IETF is making it worse by signaling that it won’t include HNCP and Babel or anything else that can solve this problem in its revision of the RFC 7084 recommendations for CPE routers. I’ve raised this topic before and the response has never been more than shoulder shrugs.

Sure, the Nest Guard and the Nest Connect currently work by providing a sort of application proxy: they establish a private virtual IPv6 network over an IPv4 tunnel between the home and the Nest Service. Because the Nest Service does not (currently) assign globally routed addresses to Thread border routers in the home, e.g. Nest Connect and Nest Guard, it’s not possible for any 3rd party product that joins the Thread network to reach anything other than the Nest Service, i.e., not even other devices on the home Wi-Fi network. Resolving that problem in the absence of a reliable system of assigning globally routed prefixes to interior routers on home networks is not easy. For a variety of reasons related to the weedy technical aspects of how Thread works, which are too tedious to explain here, using NAT66 instead of ND6 Proxy is really the only sensible way to work around the prefix delegation cluster-fail.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

p.s. Clever readers will naturally want to try to fix the problems in Thread that made ND6 proxy unsuitable for solving this problem. Good luck storming that castle. I tried and gave up.

---

From: Sander Steffann <[email-masked]>
Date: Wed, 17 Jan 2018 10:41:25 +0100

Hi,

> There is no reason to be optimistic this will change. And IETF is making it worse by signaling that it won’t include HNCP and Babel or anything else that can solve this problem in its revision of t…

More like silently crying :'(
Sander