Subject: Comments on presentation of draft-lemon-stub-networks-ps-00

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 28 Jul 2020 14:58:09 +0200

Thank you for presenting draft-lemon-stub-networks-ps-00.

During today's presentation on the problem statement on Stub Networks, I 
had several questions to make, but there was not enough time.

- targetting an IPv4 setting: it would be difficult to work on that.  I 
mean, one could formulate a problem that says 'IPv4' among other things, 
but then when solution time arrives... write an I-D with a solution in 
IPv4 space at IETF?

Maybe formulate it as an 'IP' problem could be considered.

- more clearly defining a stub network might be necessary.  The slide 
showed a 'stub router' and a 'stub host' but I am not sure a stub 
network is made of a stub router and a stub host.  At the same time, it 
might be that a stub network connecting to another stub network renders 
this latter just a network (not a stub network).

This could make think that a stub network might be made of only one 
subnet(?)

- in the slide overviewing the solution space, an additional thing could 
be mentioned: that of using SLAAC with a non-64 prefix length.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jul 2020 09:06:09 -0400

On Jul 28, 2020, at 8:58 AM, Alexandre Petrescu <[email-masked]> wrote:
> - targetting an IPv4 setting: it would be difficult to work on that.  I mean, one could formulate a problem that says 'IPv4' among other things, but then when solution time arrives... write an I-D with a solution in IPv4 space at IETF?
> 

It’s a matter of practicality, whether it’s documented in the IETF or not. We know how to do NAT64, so one way to solve the “cloud-over-IPv4-infrastructure” problem is with NAT64. I don’t think this is unreasonable to document, and I’m certainly not suggesting that it be the primary answer. But practically speaking, if it’s not documented, it will just be done differently in each implementation.

> - more clearly defining a stub network might be necessary.  The slide showed a 'stub router' and a 'stub host' but I am not sure a stub network is made of a stub router and a stub host.  At the same time, it might be that a stub network connecting to another stub network renders this latter just a network (not a stub network).

I would definitely appreciate comments on the document. :)

> This could make think that a stub network might be made of only one subnet(?)

Yes, that’s explicit in the document—sorry for not explaining it.

> - in the slide overviewing the solution space, an additional thing could be mentioned: that of using SLAAC with a non-64 prefix length.

How would this help?  Do you mean something like the 6lo backbone router proposal?  How does subdividing the prefix help with that?

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 29 Jul 2020 14:04:01 +0200

Le 28/07/2020 à 15:06, Ted Lemon a écrit :
> On Jul 28, 2020, at 8:58 AM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
>> - targetting an IPv4 setting: it would be difficult to work on that. 
>>  I mean, one could formulate a problem that says 'IPv4' among other 
>> things, but then when solution time arrives... write an I-D with a 
>> solution in IPv4 space at IETF?
>>
> It’s a matter of practicality, whether it’s documented in the IETF or 
> not. We know how to do NAT64, so one way to solve the 
> “cloud-over-IPv4-infrastructure” problem is with NAT64. I don’t think 
> this is unreasonable to document, and I’m certainly not suggesting that 
> it be the primary answer. But practically speaking, if it’s not 
> documented, it will just be done differently in each implementation.
> 
>> network is made of a stub router and a stub host.  At the same time, 
>> it might be that a stub network connecting to another stub network 
>> renders this latter just a network (not a stub network).
> 

I will look at that separately.

>> - in the slide overviewing the solution space, an additional thing 
>> could be mentioned: that of using SLAAC with a non-64 prefix length.
> 
> How would this help?  Do you mean something like the 6lo backbone router 
> proposal?  How does subdividing the prefix help with that?

Well,  I did not mean something like proxies used in the 6lo backbone 
router proposals.

I meant a solution more like this:
- SLAAC with /65 in the stub network,
- stub router receives a /64 and from the core network,
- requirement R-1 from draft-ietf-dhc-dhcpv6-pd-relay-requirements is
   solutioned more generically for a router instead of the specific
    DHCPv6-PD Relay. ("The relay [or a Router that is not
   doing DHCPv6-PD Relay function but is the first hop router for the
   stub router, towards the Internet] MUST maintain a local routing table
   that is dynamically updated with prefixes and the associated next- 

   hops as they are delegated to clients").
- a common mechanism to subdivide a /64 prefix to other sub-prefixes,
   following a common way to express that division (some routers have
   such ways to express division in the command line).

If such kind of solution is performed then there is no need to proxy.

Alex