Subject: Re: Automatically connecting to stub networks...

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Dec 2020 16:16:00 -0500

(trying to clean out my inbox)

Ted Lemon <[email-masked]> wrote:
    > I mentioned prior to IETF 107 that I wanted to start a conversation
    > about this problem, but didn’t have time to write a draft.  I’ve
    > written one, which I think describes my view of the problem pretty
    > well; I’d like to know if what I’ve written here makes sense to others.

Ted, I think that your work addresses a problem space that is in some ways
similar to the "share64" concept.   Not the same, but similar.

I think that the use of ULA which is advertise to the "LAN" for reachability
does not have to be mutually exclusive with NAT64 for "cloud" reachability.

Since your document does not actually require any new protocol, but just
explains how to do something new using existing mechanism, I think that it
would fit into the current IOTOPS charter.

In answer to your question:
   State of the Art

   Currently there is one known way to accomplish what we are describing
   here [[Michael, does ANIMA have a second way?]]. 

The ANIMA ACP sets up an overlay network with /128 routing via RPL(RFC6550)
storing mode.

    > https://www.ietf.org/internet-drafts/draft-lemon-stub-networks-ps-00.txt
    
    > Abstract: IETF currently provides protocols for automatically
    > connecting single hosts to existing network infrastructure.  This
    > document describes a related problem: the problem of connecting a stub
    > network (a collection of hosts behind a router) automatically to
    > existing network infrastructure in the same manner.

Your criticism if HNCP is all true, but an important part is that it really
only provides for allocation of prefixes; not routing.
(I still think that the WG made a mistake not extending OSPFv3)
HNCP is not the part that's missing: it's the routing protocol in the home
that is what's needed to do something more complicated.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Dec 2020 18:24:01 -0500

> similar to the "share64" concept.   Not the same, but similar.

Yes. But I think share64 on a WiFi network would require proxy ND, which doesn’t scale well, particularly if you have multiple unmanaged routers providing readability and transit. 

> does not have to be mutually exclusive with NAT64 for "cloud" reachability.

Absolutely. That’s what we’re thinking for the ipv4 and dual stack cases. Doesn’t work for v6-only. 

> would fit into the current IOTOPS charter.

I don’t think this is IoT-specific. I would prefer to do the work in intarea. 

> The ANIMA ACP sets up an overlay network with /128 routing via RPL(RFC6550)

I don’t get a mental picture from this of how it helps. 

FWIW, Apple is now shipping a product (HomePod Mini) that does stub network routing for thread networks, and there’s also an open source implementation. Right now it only does the ULA solution. I’ll be writing a draft that describes this soon. 

Thanks for the review and comments!

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Dec 2020 18:42:32 -0500

Ted Lemon <[email-masked]> wrote:
    >> Ted, I think that your work addresses a problem space that is in some
    >> ways similar to the "share64" concept.  Not the same, but similar.

    > Yes. But I think share64 on a WiFi network would require proxy ND,
    > which doesn’t scale well, particularly if you have multiple unmanaged
    > routers providing readability and transit.

I wasn't saying that the same solution applies, but rather the problem space
is the same.   Device-X has some IPv6 on a network "behind" it, and wants to
share addresses on a wifi/LAN in front of it in order to enable connectivity.

I'm unclear from reading your document if the RA's would have L=0 or L=1.

    >> I think that the use of ULA which is advertise to the "LAN" for
    >> reachability does not have to be mutually exclusive with NAT64 for
    >> "cloud" reachability.

    > cases. Doesn’t work for v6-only.

So, if the LAN is v6-only and does not have DHCPv6-PD or HNCP+Babel, then I
think it's a fail for cloud connectivity.   In particular, in this case, it's
hard to report the failure to anyone offsite!

It might be worth describing how this failure case could be reported intelligently.
This is an operational kind of thing which is in charter for IOTOPS.

    >> Since your document does not actually require any new protocol, but
    >> just explains how to do something new using existing mechanism, I
    >> think that it would fit into the current IOTOPS charter.

    > I don’t think this is IoT-specific. I would prefer to do the work in

I don't think something needs to be IoT-only to belong in IOTOPS.

    >> In answer to your question: State of the Art
    >> 
    >> The ANIMA ACP sets up an overlay network with /128 routing via
    >> RPL(RFC6550) storing mode.

    > I don’t get a mental picture from this of how it helps.

I'm sorry, I didn't finish the thought.  "It does not help at all"

    > FWIW, Apple is now shipping a product (HomePod Mini) that does stub
    > network routing for thread networks, and there’s also an open source
    > implementation. Right now it only does the ULA solution. I’ll be
    > writing a draft that describes this soon.

I'm unclear what "this" is.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Dec 2020 18:47:38 -0500

“This” is what we did in the Apple thread border router. I’m nervous about anything in the IETF with IoT in the title because it will be subject to the Carsten Bormann DoS attack. 

I don’t know if we have visibility into the right part of Google to get the chrome problem fixed. Their IoT team is fairly far removed from their browser team. What’s the use case?

> On Dec 2, 2020, at 18:42, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Dec 2020 19:14:21 -0500

On Dec 2, 2020, at 18:47, Ted Lemon <[email-masked]> wrote:
> the Carsten Bormann DoS attack

BTW, I’m sorry for having ascribed this to Carsten. What I’m taking any is the tradition in some IoT working groups of having biweekly Interims. It’s a great idea on theory, but generally means I can’t participate in that WG because the time hit is too much.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Dec 2020 19:22:50 -0500

On Dec 2, 2020, at 19:14, Ted Lemon <[email-masked]> wrote:
> What I’m taking any
Talking about. Sigh.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 3 Dec 2020 10:01:47 +0000

Hi All,
This draft contradicts to RFC 8028. If IETF would approve both then overall progress would be “nowhere”.

It is the very principal question what should happen 1st on the host: next hop or source address choice?
RFC 8028 proposes source address selection as the 1st priority.
It does permit to solve MHMP problem in general case just on the level of SASA (RFC 6724). No need for RFC 4191 to tweak routing table on the host.
Well, in reality a little improvement is needed for host to choose only default routers that announced particular prefix used for source address. But it is not a big problem – it is the static rule.
Moreover, it does resolve even the case that I call “non-equal value prefixes”, when some prefix is walled garden of particular Carrier, or some complicated logic exist for prefix preferences.
It is because source address choose could permit to automate all other choices.

Alternative general approach is explained in RFC 7157: synchronous download of the same policy into SASA (by RFC 7078) and next hop selection (by RFC 4191), then current priority for next hop selection could be preserved.

This draft again assumes priority for next hop selection. Hence, again RFC 4191 to properly influence it.
And additionally, prefix is announced only from 1 stub router that contradicts to RFC 8028 logic too.

If IETF would continue to release documents that contradict to each other – we would never get a solution for MHMP (multi-hop multi-prefix). That I have initiated just a few days ago.

I vote for RFC 8028, because it is the solution for general case. “Stub” is by definition the “corner case”.

Eduard
From: ipv6 [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: 10 июля 2020 г. 9:25
To: 6MAN <[email-masked]>
Subject: Automatically connecting to stub networks...

I mentioned prior to IETF 107 that I wanted to start a conversation about this problem, but didn’t have time to write a draft.  I’ve written one, which I think describes my view of the problem pretty well; I’d like to know if what I’ve written here makes sense to others.  This is semi-related to the Homenet problem, but doesn’t try to do as much, which makes the problem a bit more tractable, and addresses at least one fairly important use case.

A new version of I-D, draft-lemon-stub-networks-ps-00.txt
has been successfully submitted by Ted Lemon and posted to the
IETF repository.

Name:                        draft-lemon-stub-networks-ps
Revision:       00
Title:             Self-configuring Stub Networks: Problem Statement
Document date:         2020-07-08
Group:                       Individual Submission
Pages:                        15
URL:            https://www.ietf.org/internet-drafts/draft-lemon-stub-networks-ps-00.txt
Status:         https://datatracker.ietf.org/doc/draft-lemon-stub-networks-ps/
Htmlized:       https://tools.ietf.org/html/draft-lemon-stub-networks-ps-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lemon-stub-networks-ps

Abstract:
  IETF currently provides protocols for automatically connecting single
  hosts to existing network infrastructure.  This document describes a
  related problem: the problem of connecting a stub network (a
  collection of hosts behind a router) automatically to existing
  network infrastructure in the same manner.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 3 Dec 2020 10:15:44 +0000

Hi Ted,
I believe that it is very big question should it be L2 or L3 solution for stub router?
Many ideas come to me on this subject immediately: L2 is not dependent on /64 problem, DNS is easy (including mDNS), etc.
But I do not know what is better – the matter is complex.
I have NOT found the discussion in your draft.
Eduard
From: ipv6 [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: 10 июля 2020 г. 9:25
To: 6MAN <[email-masked]>
Subject: Automatically connecting to stub networks...

Abstract:

The IETF Secretariat

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Dec 2020 08:45:59 -0500

> overall progress would be “nowhere”.

I don't understand.
It seems to entirely depend upon RFC8028, leverage it.

    > Alternative general approach is explained in RFC 7157: synchronous
    > download of the same policy into SASA (by RFC 7078) and next hop
    > selection (by RFC 4191), then current priority for next hop selection
    > could be preserved.

I don't understand how RFC7078 helps, given that a postulate of the
stub-network is that the home/enterprise DHCPv6-server is not capable of
being aware of the stub-network.

If it could, then we could do DHCPv6-PD.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 3 Dec 2020 14:16:56 +0000

Hi Michael,
You do not understand, because you have deleted explanation.
If I would read what is left below - I would not understand too.
Ed/
> -----Original Message-----
> From: Michael Richardson [mailto:[email-masked]]
> Sent: 3 декабря 2020 г. 16:46
> To: Vasilenko Eduard <[email-masked]>
> Cc: Ted Lemon <[email-masked]>; 6MAN <[email-masked]>
> Subject: Re: Automatically connecting to stub networks...
> 
> 
> I don't understand how RFC7078 helps, given that a postulate of the stub-
> network is that the home/enterprise DHCPv6-server is not capable of being
> aware of the stub-network.
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 3 Dec 2020 09:21:18 -0500

> It is the very principal question what should happen 1st on the host: next hop or source address choice?

Can you explain why you think there’s a conflict here? I’m not seeing it.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 3 Dec 2020 09:26:50 -0500

> I believe that it is very big question should it be L2 or L3 solution for stub router?

An L2 solution simply isn’t possible when the media in question have such different characteristics. E.g., there’s no way to do this with 6lowpan.  The closest you can easily get is proxy ARP, which is discussed in the document. This is particularly problematic if you have multiple ingresses to the stub network. Implementation becomes complex. Doing it at L3 is much simpler. My goal here is to come up with simple solutions, not interesting problems. :)

In any case, an L2 solution is simply a different solution. It’s not a stub network. If you can make it work for you, great, but if you can’t, that’s when a stub network solution may be a better choice.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 3 Dec 2020 14:30:24 +0000

You do discuss how RFC 4191 would help.
This RFC is not needed at all if source address chosen 1st
Because after source address selection it is trivial to decide about next hop
Without any tweaking of routing tables on the host.

Hence, You stick to the current mode of host operation: next hop is decided 1st.

I agree with RFC 8028 that it should be changed.
RFC 8028 is the only comprehensive solution now for the general MHMP case.

Ed/
From: Ted Lemon [mailto:[email-masked]]
Sent: 3 декабря 2020 г. 17:21
To: Vasilenko Eduard <[email-masked]>
Cc: 6MAN <[email-masked]>
Subject: Re: Automatically connecting to stub networks...

On Dec 3, 2020, at 5:01 AM, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
It is the very principal question what should happen 1st on the host: next hop or source address choice?

---

From: [email-masked]
Date: Thu, 3 Dec 2020 15:38:13 +0100

Vasilenko,

> RFC 8028 is the only comprehensive solution now for the general MHMP case.

No, unfortunately not. That only solves the problem when a host is directly connected to the exit routers.
You need SADR in addition. See RFC8043 and its references.

Best regards,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Thu, 3 Dec 2020 09:38:44 -0500

Eduard, you still haven’t actually describe the problem you think you see. Can you explain why source address selection matters in this case and what specifically could go wrong?

> On Dec 3, 2020, at 09:31, Vasilenko Eduard <[email-masked]> wrote:
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 3 Dec 2020 09:40:11 -0500

Oh, do you mean source address selection for hosts on the stub network?  That’sa good point. 

> On Dec 3, 2020, at 09:38, Ted Lemon <[email-masked]> wrote:
> 
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 3 Dec 2020 14:44:16 +0000

Pascal has developed good solution for multi-link. He claims that it is extremely good specifically for low powered wireless. I tend to believe him, but maybe I need additional investigation.
Fred is developing some sort of multi-link. For wireless again☺
You are talking about L2 proxy – it means that L2 was not ruled out completely.
But then why you are talking just about L2 proxy?
IMHO: it is better to say that L2 is ruled out in principle – put it out of the scope. It is “only routing” option research.
Or tell why WiND is not suitable. Look to other solutions above L2 proxy.

By the way, L2 solution would not have many problem of routing solution:
L2 is not dependent on /64 problem, DNS is easy (including mDNS), etc.
Does it matter for research?
Ed/
From: Ted Lemon [mailto:[email-masked]]
Sent: 3 декабря 2020 г. 17:27
To: Vasilenko Eduard <[email-masked]>
Cc: 6MAN <[email-masked]>
Subject: Re: Automatically connecting to stub networks...

On Dec 3, 2020, at 5:15 AM, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
I believe that it is very big question should it be L2 or L3 solution for stub router?

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 3 Dec 2020 14:47:26 +0000

Hi Ole,
Strictly speaking yes:
After the job on 1st hop would be done
Additional source routing is needed between routing hops.

But here was the context of 1st hop. I did have the liberty to omit source routing discussion.
May be wrong.
Eduard
> From: [email-masked] [mailto:[email-masked]]
> Sent: 3 декабря 2020 г. 17:38
> > This RFC is not needed at all if source address chosen 1st Because
> > after source address selection it is trivial to decide about next hop

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 3 Dec 2020 14:58:08 +0000

Ted,
This WG did half of the step (or ¾) to solve MHMP problem for general case.
Intentions are well specified in RFC 8028. ND, SASA and source routing for site networks are not corrected properly.
Nothing is enforced in MUST language. No one vendor has even considering to change host IP stack.

You try to specify corner case with MHMP.
It is inevitable that you have stepped into this problem.
You had no chance to pass by.
It is just the topic you chosen.
Eduard
From: Ted Lemon [mailto:[email-masked]]
Sent: 3 декабря 2020 г. 17:40
To: Vasilenko Eduard <[email-masked]>
Cc: 6MAN <[email-masked]>
Subject: Re: Automatically connecting to stub networks...

On Dec 3, 2020, at 09:38, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

On Dec 3, 2020, at 09:31, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:

Ed/
From: Ted Lemon [mailto:[email-masked]]
Sent: 3 декабря 2020 г. 17:21
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: 6MAN <[email-masked]<mailto:[email-masked]>>
Subject: Re: Automatically connecting to stub networks...

---

From: Ted Lemon <[email-masked]>
Date: Thu, 3 Dec 2020 11:22:16 -0500

> being aware of the stub-network.

In order to get a prefix to advertise on the stub network, DHCPv6-PD would work. Of course, no host on the stub network is ever going to do DHCPv6-PD, or if they do they’ll fail, but the draft does in that sense rely on DHCPv6-PD for the globally addressable prefix use case.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 3 Dec 2020 10:24:09 -0600

Michael,

On Wed, Dec 2, 2020 at 3:36 PM Michael Richardson <[email-masked]>
wrote:

> reachability

What is IOTOPS?

Behcet

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 3 Dec 2020 17:37:37 +0000

Ted,
I did think a little more
And come to conclusion
That it does not make sense to specify stub network as the routed network.
It is better to have it as multi-link (L2).

Because MHMP is still the big and unresolved problem on IPv6.
MHMP should coordinate:

1.      Source address selected

2.      With next hop on the host

3.      With source routing inside site (up to Carrier)
The good idea is presented in RFC 8028 - not pushed through all related RFCs and not accepted by the market yet.
Hence, it is better to avoid MHMP ground. All assumptions here are shaky.
Unfortunately, If you would insist on routed solution for stub network – you have to have to deal with MHMP.
/64, DNS, renumbering - would be bonus problems.

PS: IPv4 has just NAT on every border to Carrier to get the redundancy.

Ed
From: Vasilenko Eduard
Sent: 3 декабря 2020 г. 17:46
To: 'Ted Lemon' <[email-masked]>
Cc: 6MAN <[email-masked]>
Subject: RE: Automatically connecting to stub networks...

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 3 Dec 2020 18:49:01 +0100

On Wed, Dec 02, 2020 at 06:47:38PM -0500, Ted Lemon wrote:
> ???This??? is what we did in the Apple thread border router. I???m nervous about anything in the IETF with IoT in the title because it will be subject to the Carsten Bormann DoS attack. 

Whow, i guess its christmas time, so you're trying to spread some love ?

What's a CBDA ? Is that a badge of honor to wear ? I have a Van-o-Gram from the
1990'th. Maybe i can upgrade by breast plating with a CBDA ? What do i need to do to get one ?

Back to business.  Some high level suggestions for your doc:

- Move your rants about HNCP to an appendix

- Maybe also the rant about service discovery being an integral part of the problem to an appendix.
  although i agree that a good part of the IETF community may not have gotten the message how it is,
  but its still disturbing the flow of reading when preaching to the choir like me.

- Put IPv6 into the title if all you care about is really only IPv6.
  Before this gets adopted by a WG, native support for also IPv4 should be a key scope discussion.
  Not everybody may have the same IP6 centric only business goal.
  (I Have No Opinion. Just saying).

- It would be nice to start section 2 with a description of a generic model
  without being specific to the protocol so one can check if/what protocol options
  do meet the model - as opposed to only the two ones you think are in your interest.

- For example: Why not simply start with DHCP-PD ? IMHO, every home router getting
  a prefix via DHCP-PD from a service provider is a provider of such a stub network.
  Of course, service discovery as you expect does usually not work in that environment,
  so that would need to be added.
  
- Would be lovely to detail exaple use-cases such as that Apple device (e.g.: in an appendix)
  to provide better motivation and also justification for the proposed protocol choices...

Cheers
    Toerless

> I don???t know if we have visibility into the right part of Google to get the chrome problem fixed. Their IoT team is fairly far removed from their browser team. What???s the use case?
> 
> > ???
> >>>> about this problem, but didn???t have time to write a draft.  I???ve
> >>>> well; I???d like to know if what I???ve written here makes sense to
> >>>> others.
> >>> 
> >> which doesn???t scale well, particularly if you have multiple unmanaged
> >> Absolutely. That???s what we???re thinking for the ipv4 and dual stack
> >> cases. Doesn???t work for v6-only.
> > 
> >> I don???t think this is IoT-specific. I would prefer to do the work in
> >> intarea.
> > 
> >> I don???t get a mental picture from this of how it helps.
> > 
> >> network routing for thread networks, and there???s also an open source
> >> implementation. Right now it only does the ULA solution. I???ll be
> Iotops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iotops

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Dec 2020 13:25:13 -0500

> In order to get a prefix to advertise on the stub network, DHCPv6-PD
    > would work. Of course, no host on the stub network is ever going to do
    > DHCPv6-PD, or if they do they’ll fail, but the draft does in that sense
    > rely on DHCPv6-PD for the globally addressable prefix use case.

I'm assuming that it's the gateway that does DHCPv6-PD.
If that works, then we are done.
We don't necessarily need the ULA or the NAT64 at that point.
(Although, the delegated prefix might not be a GUA.)

It's when it does not work that I think your draft comes into play.
One is essentially bring IPv6 to a LAN where there might not any.
I think that's okay.
{I also think that the thing bring that ULA to the LAN should be a DHCPv6-PD
server as well: there could be another gateway that needs IPv6}

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Dec 2020 13:25:57 -0500

> What is IOTOPS?

https://datatracker.ietf.org/wg/iotops/about/
Proposed WG.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 3 Dec 2020 13:31:57 -0500

> 1990'th. Maybe i can upgrade by breast plating with a CBDA ? What do i need to do to get one ?

It’s me being a jerk. Sorry about that.

> - Move your rants about HNCP to an appendix

They aren’t rants. There is no deployable HNCP. HNCP was the first solution we thought of, and was my original preference for a solution, but it isn’t a solution for the reasons stated. That’s part of the problem statement. If you have specific text that you think is a rant, and not a problem statement, please propose changes.

>  but its still disturbing the flow of reading when preaching to the choir like me.

In what sense is this a rant? How do you discover hosts on the stub network without some kind of service discovery protocol? How do hosts on the stub network discover services on the infrastructure network? Consider this: is your internet connection useful if DNS is not available? (I mean _really_ not available, not just that you didn’t get the IP address of a resolver from your ISP).

>  (I Have No Opinion. Just saying).

I don’t know of a way to solve this with IPv4 without HNCP or something like it. That is, there’s no automatic mechanism that we could use in IPv4 that’s similar to what’s available in IPv6.

>  do meet the model - as opposed to only the two ones you think are in your interest.

Fair point.

>  so that would need to be added.

We didn’t start with DHCPv6-PD because we needed something that will work in any network, not just in networks where DHCPv6-PD is present.

>  to provide better motivation and also justification for the proposed protocol choices…

That sounds like a good idea. When I submitted the draft, this wasn’t an option because the product hadn’t yet been announced… :)

Thanks for the review and feedback. Sorry about being a jerk, and please let me know if there’s specific text that feels like it’s a rant.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 3 Dec 2020 13:36:28 -0500

> If that works, then we are done.

Not quite. We still need to advertise reachability to the prefix, and do all the work to set up numbering on the local link. Assume no management, and an arbitrary number of stub routers potentially connecting to an 802.15.4 mesh. How does DHCPv6-PD even work in this scenario? I’m not saying it can’t, but it’s not “just do DHCPv6-PD”!

> (Although, the delegated prefix might not be a GUA.)

Right, have to account for that. Also probably should account for the case where the infrastructure network provides NAT64 via ipv4only.arpa, so we don’t have to do it in the border router. This is obviously HIGHLY preferable. :)

> server as well: there could be another gateway that needs IPv6}

We have to use what we’re given. If there’s DHCPv6-PD, we should figure out a way to use that. The Apple solution is very careful not to add anything to the network that’s unnecessary—if  you have a prefix from your ISP, it doesn’t advertise an IPv6 prefix on the infrastructure link, because there’s already a usable prefix.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Dec 2020 13:51:59 -0500

> so that would need to be added.

While there is a CableLabs spec that argues for stacked DHCPv6-PD (and it was
presented in Homenet a few years back), to date, I'm aware of no deployed
home routers that operate a DHCPv6-PD server on their southbound interface.

Conceptually it's simple to implement.
Architecturally there are some who thinks it is gross, and some who think
it's brilliant.   I'm still sitting on the fence myself.

But, fundamentally, the issue Ted is trying to address is enabling
communications within the Home between layer-2s that can not, or should not,
be bridged.

I agree with your other suggestions for re-organization.
I have some ideas about how I would write this document.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Dec 2020 14:02:02 -0500

> Not quite. We still need to advertise reachability to the prefix, and
    > do all the work to set up numbering on the local link. Assume no
    > management, and an arbitrary number of stub routers potentially
    > connecting to an 802.15.4 mesh. How does DHCPv6-PD even work in this
    > scenario? I’m not saying it can’t, but it’s not “just do DHCPv6-PD”!

I guess I'm confused.
1) If the home router speaks IPv6, then it's already numbered the "LAN" link.

2) If it speaks DHCPv6-PD server, then when it allocates a prefix to the
802.15.4 router that asked for the prefix, then it sets up reachability.
{Of course, this fails if there are multiple gateways, a la homenet, but I
think that's out of scope for this situation}

What else is there?
It's true that the DHCPv6-RELAY stuff is a mess for PD, but there shouldn't
be any DHCPv6-relaying in a home.

{While the home gateway might have to go back to the ISP for another /64,
that's not a local problem.}

    > Right, have to account for that. Also probably should account for the
    > case where the infrastructure network provides NAT64 via ipv4only.arpa,
    > so we don’t have to do it in the border router. This is obviously
    > HIGHLY preferable. :)

Yes.
Basically, the border router should probably do reachability checks to see if
it can get to the cloudy places it cares about on both IPv4 and IPv6, and
then enable whatever it needs to make things work.
I think that this would make a really nice operational BCP document.

    > We have to use what we’re given. If there’s DHCPv6-PD, we should figure
    > out a way to use that. The Apple solution is very careful not to add
    > anything to the network that’s unnecessary—if  you have a prefix from
    > your ISP, it doesn’t advertise an IPv6 prefix on the infrastructure
    > link, because there’s already a usable prefix.

Good!
I think we are in violent agreement.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 3 Dec 2020 14:08:35 -0500

If we were to stack PD, that would not be a stub network, although I think it’s an interesting increment. But the way to do it is with DHCPv6 relays on the (no longer) stub routers. Otherwise you have a tree balancing problem that’s totally unnecessary. And you still need Babel or OSPF or something to manage routing.

I’d be happy to have a co-author, if you are interested, Michael. :)

> On Dec 3, 2020, at 1:51 PM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Philip Homburg <[email-masked]>
Date: Thu, 03 Dec 2020 22:02:20 +0100

>    Not quite. We still need to advertise reachability to the prefix,
>    and do all the work to set up numbering on the local link. Assume
>    no management, and an arbitrary number of stub routers potentially
>    connecting to an 802.15.4 mesh. How does DHCPv6-PD even work in
>    this scenario? I'm not saying it can't, but it's not "just do
>    DHCPv6-PD"!

If the network has a tree structure and DHCPv6-PD is done through a series
of relays then the DHCP server and each of the relays could install a
forwarding path for the delegated prefix. No need for any routing protocol.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 03 Dec 2020 22:04:59 +0100

>home routers that operate a DHCPv6-PD server on their southbound interface.

Some home routers do in fact provide DHCPv6-PD southbound. A colleague of 
mime got one with cable internet. I think the main limitation of that
box was that it would only delegate one /64.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 03 Dec 2020 22:09:42 +0100

>be any DHCPv6-relaying in a home.

I think there should be. I.e., if you have one router that is DHCPv6 server
for the entire home network, then all other router should have a 
relay on their downstream networks.

i.e., I assume that a relay is easier to implement than a downstream
dhcp server that has to get additional prefixes from upstream.

---

From: [email-masked]
Date: Thu, 3 Dec 2020 22:18:55 +0100

> dhcp server that has to get additional prefixes from upstream.

No need to rehash this, we have rehased this a few times before.

https://mailarchive.ietf.org/arch/msg/homenet/T_6Y9nooYQVm8TNolie46FBBtnk/

Cheers,
Ole

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Dec 2020 18:26:10 -0500

Ted Lemon <[email-masked]> wrote:
    > If we were to stack PD, that would not be a stub network, although I
    > think it’s an interesting increment.

I think that we must be talking past eachother.

1) DHCPv6-PD x 1: home-router to ISP.
2) DHCPv6-PD x 2: stub-router to home-router.

Behind the stub-router there would be no DHCPv6-PD, just RPL or Zigbee or
Thread, or whatever.

But, no current home routers support (2), so it won't work.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 3 Dec 2020 19:05:41 -0500

> But, no current home routers support (2), so it won't work.

I don’t think this assertion is true. I’m pretty sure Comcast put quite a bit of effort into making it not be true a few years back. It’s certainly true (last time I checked) that OpenWRT doesn’t support it, though.

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 4 Dec 2020 07:49:30 +0100

On Thu, Dec 03, 2020 at 01:31:57PM -0500, Ted Lemon wrote:
> They aren???t rants.

I was just referring to the style, not payload
 "long passionate explanation, i am sure was given repeatedly already" ;-)).

> There is no deployable HNCP. HNCP was the first solution we thought of, and was my original preference for a solution, but it isn???t a solution for the reasons stated. That???s part of the problem statement. If you have specific text that you think is a rant, and not a problem statement, please propose changes.

I probably don't disagree with whats said in the text, except that i am
only aware of all the discussion and alternatives back when it was designed,
but i lost track for the past few years,so i'd need to upgrade my current
status before i could say i fully agree. Just don't make it disturb the
flow and move it down into some appendix or the like.

> In what sense is this a rant? How do you discover hosts on the stub network without some kind of service discovery protocol? How do hosts on the stub network discover services on the infrastructure network? Consider this: is your internet connection useful if DNS is not available? (I mean _really_ not available, not just that you didn???t get the IP address of a resolver from your ISP).

IMHO, its a rant because everybody should know and agree.
And explanations for those not in the know should be in an appendix.

> I don???t know of a way to solve this with IPv4 without HNCP or something like it. That is, there???s no automatic mechanism that we could use in IPv4 that???s similar to what???s available in IPv6.
> 

To pick on on HNCP for example: The generic part could raise requirements, e.e.:

     Clients ---infra-network---- infra-router [A]

     Clients ----stub-network ---stub-router --- (new)-signaling --- infra-router [B]
                                                 infra-network

Goal of the document (IMHO) would be to:

a) make stub-network in [B] perform as much as possible equally to  infra-network in [A]
   ideally no changes. Of course,we'd need to define infra-network accordingly to
   support all required functions. Such as DNS-SD.

b) focus on defining the information elements on the [B] infra elements between
   infra-router and stub-router, so that stub-router can create  stub network.

b) is IMHO fundamental, because it would allow for supporters of protocols, let's say
HNCP that is not considered in this draf to equally build their own extension draft
also implementing the information elements from b) in a separate draft.

> We didn???t start with DHCPv6-PD because we needed something that will work in any network, not just in networks where DHCPv6-PD is present.

Given how seemingly new signaling extensions are required, the question is
what protocol is the best basis to extend, and DHCPv6 with PD seems like a good
basis. I understand how there are religious DHCP lower and haters though,
but from past work with SPs, i just know a lot of things DHCP can much more
nicely do than just RA. for example transparently passing through additional
DHCP options from the infra router through the stub-router to the clients.
So in doubt count me in as weak DHCP lover...

Of course, if the information elements are embodied into DHCP, then it is of course
also much easier to support IPv4 natively.

> >  to provide better motivation and also justification for the proposed protocol choices???
> 
> 
> That sounds like a good idea. When I submitted the draft, this wasn???t an option because the product hadn???t yet been announced??? :)

THanks. I am always motivated by real world data/needs.

> Thanks for the review and feedback. Sorry about being a jerk, and please let me know if there???s specific text that feels like it???s a rant.

I am sure carsten isn't worried and i do appreciate to have folks (such as him) in the community that help to improve our technologies for their field of expertise, even if that turns out to be a pain in unnamed body parts. Wouldn't want security folks to have a monopoloy on that role.

Wrt. "rant", consider it to be term of friendly stylistic nitpicking..

Cheers
    Toerless

-- 
---
[email-masked]

---

From: [email-masked]
Date: Fri, 4 Dec 2020 09:19:13 +0100

Let's me see if I can dissect Ted's arguments against HNCMP in https://tools.ietf.org/html/draft-lemon-stub-networks-ps-00#section-1.3, and if restricting the problem to only allowing stub routers to be connected to a single router helps. (A topology with a single root router and a single level of branches).

1) HNCP only works if all routers in the AS runs it. It's a routing protocol so that's not surprising.
Solutions would have to either participate in routing and a prefix assignment protocol.
The degenerate case for routing is default route upstream and a static route for the assigned prefix downstream.
All traffic to sieblings would go via root router.

Ted also mentions that HNCP does not deal with the case where only a /64 has been delegated to the site.
In homenet we did a conscious choice of requiring a site to get enough addressing to get a /64 for each link.
I do know that the implementation in OpenWRT does support a single /64 (it subnets into /80s and does DHCP address assignment).
How to deal with a case of not enough addresses assigned is not a problem unique to HNCP though.

The degenerate case for addressing is:
a) Split up a /64 in pools of addresses for DHCP
b) If less than a /64 (e.g. already shared) then NAT

2) HNCP is too complex and does too much and is not implemented.
Not enough details to make any arguments for or against this one.
If one standard isn't deployed and implemented is a weak argument for inventing a new protocol and standardising that, that's neither specified, implemented nor deployed.

Question, what are the requirements here?

A) Stub network. Is it possible to restrict the topology to a single root/single level of leafes?
It prohibits multi-homing. What about the case where a node is attached to the stub with a hypervisor and VMs requiring addressing?
Is sending all traffic via the root acceptable? Instead of short-cutting between stub routers?

B) Is it possible to restrict the solution to the site having been delegated enough address space?
Or do you need to handle the cases where the site has:
a) not received enough /64s to number all links
b) have only been delegated a single /64
c) have only a shared /64
d) have only a single address

Cheers,
Ole

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 4 Dec 2020 09:57:38 +0100

> Question, what are the requirements here?

Indeed. Lets first focus on that.

> A) Stub network. Is it possible to restrict the topology to a single root/single level of leafes?

I would fear the current business cases might be fine with such a limitation,
but i for once would find it dissatisfactory if the protocol solution
would be limited to just one level.

> d) have only a single address

Not trying to answer all these points, but:

To me the most simple model is around the following constraints/requirements:
  
      stub-router ----link --- infra-router

a) stub-router and infra-router are potentially different admin, aka:
   we do not want to use signaling between them such as a typical
   link-state-routing protocol where you can not create good trust-domain
   boundries within the topology. Dijkstra protos are a bit better, but
   i think no one has tried to come up with good definitions for "internal"
   trust boundaries.

b) infra-router hands out prefix(es) to stub-router. It shouldn't have
   anything to say about how stub-router uses them. So stub-router could
   subtend sub-prefixes as it sees fit. Infra router does NOT accept
   prefixes back from stub-router. 

Not sure yet about similar rules for the naming / services for DNS-SD,
but there may need to be some similar rules.

And from service provider use cases, i remember various other DHCP options
that infra-router may need to see proxied across stubb-router to clients
if/when clients rely on DHCP opions instead of DNS-SD to discover specific
services. Which for example in the home a lot of the service-provider
equipment such as IPTV STBs expects to be able to do.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: [email-masked]
Date: Fri, 4 Dec 2020 10:19:35 +0100

> would be limited to just one level.

Right, I already gave an example where that topology fails.

>   i think no one has tried to come up with good definitions for "internal"

Yes, I believe this was also discussed in homenet.
In Ted's case as well as many others devices are controlled with umbilical cords to other administrative domains.
They should in theory not be more trusted inside the network than a host from the outside.
This is a hard one.

>   prefixes back from stub-router.

Routing is of course tightly coupled with prefix assignment.
I also believe Ted's use case involves a stub network coming with it's own ULA that it wants to advertise routing for within the rest of the site(?).

> equipment such as IPTV STBs expects to be able to do.

There has to be a way of distributing configuration information (from multiple sources).

Cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Fri, 04 Dec 2020 11:51:39 +0100

>   prefixes back from stub-router. 

Indeed. We need to have a model where there can be a 'core network' that
either runs HNCP/Babel in the case of homes, small business or OSPF (or equiv)
and static configuration in the case of entrerprise.

Attached to those core routers are small trees that do not run a routing
protocol, but use a hierarchical mechanism to obtain prefixes.

A core router should provide the root of each tree with as many /64s as is
needed to number the tree.

We currently have a mechanisms for the hierarchical part, which is DHCPv6 PD.
It is far from ideal, but we can try to specify how it should be deployed.

Of course, this assumes that the core network has enough address space to 
number all of the trees.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 04 Dec 2020 08:42:04 -0500

> needed to number the tree.

In essence, this describes ISPs today, with the customers are the "small trees"

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ted Lemon <[email-masked]>
Date: Fri, 4 Dec 2020 16:19:37 -0500

> All traffic to sieblings would go via root router.

HNCP is not a routing protocol. Babel is a routing protocol. HNCP is a mesh discovery protocol. It has a lot in common with routing protocols, but it’s really its own beast.

For the stub network case, HNCP simply isn’t necessary. I think the disconnect with HNCP is that it is aimed at a problem nobody wants to solve. The stub network problem is a problem that we wanted to solve enough that we spent two years working on it. HNCP was a choice we considered, but it simply wasn’t an option. I guess if you want routable IPv4, HNCP would help with that for the stub network case, but I don’t find this compelling—IPv6 works fine.

> How to deal with a case of not enough addresses assigned is not a problem unique to HNCP though.

The point of saying that is that we need some way to do outbound connectivity in this case. Our solution to this problem is to use NAT64. Hopefully as v6only deployments happen, service providers will get real about assigning narrower prefixes.

> b) If less than a /64 (e.g. already shared) then NAT

No point in doing NAT66 when you can do NAT64.

> If one standard isn't deployed and implemented is a weak argument for inventing a new protocol and standardising that, that's neither specified, implemented nor deployed.

From my perspective, needing to ship a product that will work on real networks, and not rely on imaginary networks, the fact that there are no implementations and none coming meant that we simply couldn’t use HNCP, even though because of my time in the Homenet WG I was personally predisposed to do so and spent quite a bit of time evaluating it as a solution before abandoning it.

> Is sending all traffic via the root acceptable? Instead of short-cutting between stub routers?

I see no reason to do this.

> d) have only a single address

Our solution works in all of these cases except the v6-only /64-only case.

(I say our solution meaning what we did in the HomePod Mini and the open source Thread border router—we don’t have a specification yet, and didn’t actually do any protocol work.)

---

From: Ted Lemon <[email-masked]>
Date: Fri, 4 Dec 2020 16:22:48 -0500

> would be limited to just one level.

There isn’t really any new protocol work required.

> equipment such as IPTV STBs expects to be able to do.

Does anybody actually do that? I ask because I don’t know of any routers that support it. I guess some ISPs do custom routers and don’t let the customer choose?

Anyway, best is the enemy of good enough. We already have a solution for the self-configuring mesh; if that’s what we want, HNCP is our best option at present. There’s no need to do additional protocol work here.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 4 Dec 2020 16:27:30 -0500

> They should in theory not be more trusted inside the network than a host from the outside.

I think generally for IoT devices controlled by the cloud reach out to the cloud rather than the cloud reaching in. I think James Woodyatt years ago said that Nest did this with an IPv6 tunnel, but in any case I think these are provider-specific solutions and not really something the IETF needs to work on.

My goal in documenting our stub router solution is (1) so that people can point out issues they see with what we’ve done. Real issues, please. And (2) because it can serve as a base specification that various specific documents can reference. I think it has general utility, although my current use case is 802.15.4 mesh (Thread).

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 4 Dec 2020 22:03:21 +0000

> But, no current home routers support (2), so it won't work.

??
Plenty of ISP home routers support (2). I know AT&T's does.
CableLabs had tried to push for some standardized behavior around
this in homenet (which, IMO, was overly complex in what it was doing. 
But there wasn't enough interest -- everyone was
focused on HNCP or bust.
Barbara

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 4 Dec 2020 23:12:38 +0000

DHCPv6-PD fans, please have a look at the latest OMNI draft and see if it provides
the kind of prefix delegation services you would like to see for stub networks:

https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Fri, 4 Dec 2020 18:15:24 -0500

> the kind of prefix delegation services you would like to see for stub networks:

If you are extending DHCPv6-PD for OMNI, you should really do it as a separate document. OMNI is rather large, so making references to it isn’t ideal.

The only thing we need that isn’t specified anywhere is for the infrastructure router to add the prefix and destination to the routing infrastructure.