[v6ops] Re: [E] New Version Notification for draft-mishra-v6ops-variable-iids-problem-statement-01.txt

[Daryll Swer <[e-mail]>]

Gert

Uh, interesting approach.  Which network would need more than
> 65536 multiaccess networks in a single site?

Please *thoroughly* read my IPv6 guide blog post
<https://www.daryllswer.com/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators/>
(I will not pollute this mailing list, with the equivalent of an entire
blog article), I've explained the reasoning behind my /44 choice. /44 per
site, /48 per function and *if* necessary, a function can have subfunction
(to help keep local/internal route filters simple and allow easy route
aggregation) sliced into /52s per sub-function from single function /48.

We can discuss it in depth, off this list, if you wish.


> point-to-point links can go unnumbered or /127 today, so there's
> nearly limitless p2p links in a single /64.
>

My model assumes, /64 for each Point-to-Point link (let's not discuss the
so called 'neighbour discovery table exhaustion' on this thread) or VLAN, I
have removed /126-127s completely from my professional deployments, and
many other v6-native consultants around the world (who are not on this
mailing list), also moved to direct /64 for PtP links/per VLAN, we have had
zero issues in SP and DC networks (don't know about enterprises, as I stay
away from that market segment).

In-spite of these assumptions, I do not require a /16, not even for large
(don't know if they are 'super large') networks, for which I've implemented
this model for.

 (A /44 per site would be violating RIPE policies, unless good
> documentation can be provided - but that might be different in other RIRs)

The very first network, I deployed this model for, was in the EU region,
didn't have any problems with RIPE/v6 space at RIR level that ways and
certainly didn't need an insane /16.

I've *heard* (cannot confirm/deny, never seen it first hand) from folks
that they have used my IPv6 guide as a source in their
documentation/justification requests to their RIRs to help them adopt a
model similar to mine (it's not necessarily that they did /44 or /48 per
site).

For my own PIA /32 space, it took some layer 8 push behind the scenes to
get it, but shortly after, APNIC, to my knowledge, has now normalised /32
per BGP speaker, without insane 'justification' requirements.

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://mailtrack.io/l/b5ee3eb21025d07da9704143c58a197d52ed838d?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=b4c389c820e63638>


On Sat, 28 Sept 2024 at 15:10, Gert Doering <[e-mail]> wrote:

> Hi,
>
> On Sat, Sep 28, 2024 at 03:02:20PM +0530, Daryll Swer wrote:
> > *Gert Doering*
> >
> > I'd love to see a network that is not "small enough" to fit into a /32.
> >
> > (The network itself, not the users of the network)
> >
> > The last time I remotely suggested something similar to this notion, I
> was
> > told that I was grossly 'under-sizing networks'. That being said, in my
> > preference, every site has a /44 instead of a /48,
>
> Uh, interesting approach.  Which network would need more than 65536
> multiaccess networks in a single site?
>
> point-to-point links can go unnumbered or /127 today, so there's nearly
> limitless p2p links in a single /64.
>
> (A /44 per site would be violating RIPE policies, unless good documentation
> can be provided - but that might be different in othre RIRs)
>
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Ingo
> Lalla,
>                                            Karin Schuler, Sebastian Cler
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: [phone]         USt-IdNr.: DE813185279
>