Re: Automatically connecting stub networks...

[Ted Lemon <[e-mail]>]

Who would we need the extra bit?  This is a stub router, so by definition it can only use one prefix. Unless you are thinking that a stub router might route for more than one stub network?

> On Jul 10, 2020, at 05:13, Alexandre Petrescu <[e-mail]> wrote:
> 
> 
> and there should be a requirement also on 'nesting' - a stub that attaches to a stub that attaches to a stub...
> 
> Alex
> 
> Le 10/07/2020 à 11:12, Alexandre Petrescu a écrit :
>> as titled I think the draft makes sense. 
>> 
>> In the requirements section, the requirements which talk about Prefix Delegation, I think it makes sense to think about a new requirement: that of automatically forming sub-prefixes. 
>> 
>> This is a potentially very simple operation, so simple that it might get unnoticed when implemented.  Yet some implementations do differ in the way they form sub-prefixes. 
>> 
>> I mean, in this text: 
>>> 2.3.4.  Requirements 
>>> 
>>>    o  Infrastructure network must support prefix allocation using DHCPv6 
>>>       prefix delegation. 
>>> 
>>>    o  Infrastructure network must install routes to prefixes provided 
>>>       using DHCPv6 prefix delegation. 
>>> 
>>>    o  In the case of multiple stub routers, stub routers must cooperate 
>>>       both in acquiring and renewing prefixes acquired using prefix 
>>>       delegation.  Stub routers must communicate complete routing 
>>>       information to the DHCPv6 prefix delegation server so that it can 
>>>       install routes. 
>> 
>> Suggested additional requirement: A stub router should be able to automatically form at least one /65 out of the /64 received from the DHCPv6 Prefix Delegation Server. 
>> 
>> Something like that. 
>> 
>> There are several potential rules that can be written down in a programmatic manner.  These rules might express how many sub-prefixes to form, of which length. 
>> 
>> This formation of sub-prefixes out of a received prefix should not be hardcoded.  The immediate rule that comes to mind is to form /65s out of a /64.   But it is not the only rule, and as such it should not be hardcoded. 
>> 
>> (but that's disgressing into the solution space) 
>> 
>> Alex 
>> 
>> 
>> Alex 
>> 
>> 
>>> Le 10/07/2020 à 08:25, Ted Lemon a écrit : 
>>> 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 
>>> 
>>> -------------------------------------------------------------------- 
>>> IETF IPv6 working group mailing list 
>>> [e-mail] 
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 
>>> -------------------------------------------------------------------- 
>>> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------