Subject: Re: [Iotops] Automatically connecting to stub networks...

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 7 Dec 2020 19:38:13 +0000

Ted, please have another look:

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

It now places a fully-formed DHCPv6 message inside of an OMNI option in
RS/RA messages so the stub network node can do DHCPv6-PD at the same
time it does RS/RA (this is something I have talked about before). However,
right now it only allows for a small-message DHCPv6 exchange from within
each RS/RA, which should provide ample space for most stub network
DHCPv6-PD users. Does it look like enough, or should we support bigger?

Thanks - Fred

From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, December 04, 2020 5:27 PM
To: Templin (US), Fred L <[email-masked]>
Cc: STARK, BARBARA H <[email-masked]>; Michael Richardson <[email-masked]>; Ole Trøan <[email-masked]>; 6MAN <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [Iotops] Automatically connecting to stub networks...

This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.

I can’t see that being useful for stub networks. The whole point of “stub” is to avoid complicated routing, since it’s not useful for a typical stub network.

On Dec 4, 2020, at 19:46, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Ted, the only aspects of OMNI you would need to see to grasp the concepts
are a quick scan of Sections 9.1.9 and 12.3 (approx. 1.25 total pages of text).

Basically, it imports DHCPv6 options into RS messages and asks the router
to send a “proxy DHCPv6-PD Solicit” to the DHCPv6 server on behalf of the
mobile node. After the router gets back the DHCPv6-PD Reply, it sends an
RA to the mobile node with the delegated prefix information.

This is something I suggested a long time ago, but that was before we had
the OMNI option concept. Now with the OMNI option, it can carry other
protocol information like DHCPv6 options just fine.

Fred

From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, December 04, 2020 3:15 PM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Cc: STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>; Michael Richardson <[email-masked]<mailto:[email-masked]>>; Ole Trøan <[email-masked]<mailto:[email-masked]>>; 6MAN <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [Iotops] Automatically connecting to stub networks...

On Dec 4, 2020, at 6:12 PM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
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:

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.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Dec 2020 15:11:29 -0500

> DHCPv6-PD users. Does it look like enough, or should we support bigger?

I’m sorry, Fred, but I’m just not seeing the point of this. Why not just do DHCPv6 PD?

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 7 Dec 2020 20:21:48 +0000

>I’m sorry, Fred, but I’m just not seeing the point of this. Why not just do DHCPv6 PD?

Ted, there is a need to reduce the number of messages especially on low end
wireless links like those used for aviation. So, if a terse DHCPv6 PD exchange
can be piggybacked on-board the RS/RA exchange that already needs to be
there in any case then there is a tangible savings on messages over the air.
This is good for more than just aviation, too, and applicable for mobile use
cases such as intelligent transportation systems and urban air mobility; maybe
even for pedestrians too.

Fred

Sent: Monday, December 07, 2020 12:11 PM

On Dec 7, 2020, at 2:38 PM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Dec 2020 15:27:53 -0500

> even for pedestrians too.

I still can’t think of a case where this applies to stub networks. E.g., if you decide to support stub networks on an airplane, you’re going to need a prefix to allocate stub network prefixes from. That’s one transaction over the satellite link to get that prefix, plus some maintenance. If your satellite link is so slow that this is a problem, it’s not going to be usable, so we don’t need to address that use case. 

If you are thinking that the airplane’s public WiFi network is itself a stub network, I think that would be out of scope for stub networks—the whole point of stub networks is to be able to automatically connect without an operator’s intervention, which doesn’t match your use case. Additionally, I would consider a home network connection to also be out of scope for stub networks, and that’s somewhat analogous to the airplane use case.

If you mean the airplane’s automation network, the same objection applies.

So I really don’t see where there’s overlap here.

---

From: Mark Smith <[email-masked]>
Date: Tue, 8 Dec 2020 07:37:28 +1100

> wireless links like those used for aviation. So, if a terse DHCPv6 PD
I would wonder if IPv6 is fundamentally the wrong tool for the job if you
care about going from 6 packets to 2.

Packets are cheap and are always getting cheaper.

By doing a lot of customising, you aren't really making things cheaper,
you're just shifting the cost you're trying to avoid.

Those 4 DHCPv6 PD packets you're saving could be paid for by the costs
incurred of reinventing, implementing, deploying and then training people
about the functional equivalents.

What bandwidth are these links?

> *From:* Ted Lemon [mailto:[email-masked]]
> *Sent:* Monday, December 07, 2020 12:11 PM
> *To:* Templin (US), Fred L <[email-masked]>
> *Cc:* STARK, BARBARA H <[email-masked]>; Michael Richardson <
> [email-masked]>; Ole Trøan <[email-masked]>; 6MAN <
> [email-masked]>; [email-masked]
> *Subject:* [EXTERNAL] Re: [Iotops] Automatically connecting to stub
> networks...
>
>
>
> This message was sent from outside of Boeing. Please do not click links or
> open attachments unless you recognize the sender and know that the content
> is safe.
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>