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

[Alexandre Petrescu <[e-mail]>]

Le 28/07/2020 à 15:06, Ted Lemon a écrit :
> On Jul 28, 2020, at 8:58 AM, Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>> 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?
>>
>> Maybe formulate it as an 'IP' problem could be considered.
> 
> 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. :)

I will look at that separately.

> 
>> 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?

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

>