Re: [v6ops] Implementation Status of PREF64

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Mark


As you point out, the idea is to maintain the well-known subnet aggregation boundary at /64,  so for the rest of the world your address plan does not change. If /118 is not enough, give a /112. Wasting "because we can" or "because it's cheap" is very convincing. This leaves a lot of room for future stuff in that subnet without impacting the global plan.

The old saying is s you say, old. We actually route a lot at L2 now (L2R / ISIS, LISP, eVPN, you name it). If we route in the subnet, let's aggregate as well.

Keep safe;

Pascal

> -----Original Message-----
> From: Mark Smith <[e-mail]>
> Sent: mardi 12 octobre 2021 10:45
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: Lorenzo Colitti <[e-mail]>; Ted Lemon <[e-mail]>;
> v6ops list <[e-mail]>
> Subject: Re: [v6ops] Implementation Status of PREF64
> 
> On Tue, 12 Oct 2021 at 19:13, Pascal Thubert (pthubert)
> <pthubert=[e-mail]> wrote:
> >
> > When that’s the case, and the node needs, say, less than 1000
> addresses, could we delegate a /118?
> >
> > This way, we can build a /64 NBMA subnet, which maintains the subnet
> boundary at /64, but allow routing inside.
> >
> > We could, e.g., terminate vxlan on the /118 and use routing over
> them.
> >
> > I would love to see that…
> >
> 
> How many nodes are these NBMA subnets?
> 
> Why not give each node a /64? If you're doing flat routing, which it
> sounds like you are, a /48 provides 64K /64s.
> 
> For GUA address space, APNIC RIR fees amount to about $0.03 Australian
> dollars or less per annum (not per month!) for a /48 (and they're
> effectively free if your IPv4 address space costs more than IPv6). GUA
> /48 space is very, very cheap. (In any organisation paying RIR fees,
> there probably isn't a cheaper per-unit cost resource. Pens in the
> stationary cupboard cost far more than that.)
> 
> If you're using ULA address space, each ULA you generate is a /48, so
> for example if your NBMA subnet is 250K nodes, you'll need only 4 x ULA
> /48s to give each node a /64.
> 
> (With some of the EVPN work that is going on regarding ND proxying to
> reduce multicast traffic, it has occurred to me that a lot of
> organisations could do a single EVPN across their whole network,
> fitting all devices within a single /64. In the 90s, before layer 3
> switches, there was a saying - "bridge where you can, route where you
> must". A big flat layer 2 domain, if you can do it, is quite a lot
> easier. If there is any need for subnet boundaries, it's more likely to
> be able to create security domains, although I don't entirely agree
> with that, I think zero trust networks is a far better idea.)
> 
> Regards,
> Mark.
> 
> >
> >
> > Pascal
> >
> >
> >
> > From: v6ops <[e-mail]> On Behalf Of Lorenzo Colitti
> > Sent: mardi 12 octobre 2021 6:39
> > To: Ted Lemon <[e-mail]>
> > Cc: v6ops list <[e-mail]>
> > Subject: Re: [v6ops] Implementation Status of PREF64
> >
> >
> >
> > On Tue, Oct 12, 2021 at 1:14 AM Ted Lemon <[e-mail]> wrote:
> >
> > However, they’re not going to want IA_PD addresses on the directly
> attached interface. They’re going to want IA_NA there and to route the
> IA_PD prefix to the host via ND resolution of the MAC of it’s IA_NA
> address.
> >
> >
> >
> > This isn't really necessary, although it's common practice. If the
> device is not going to use the prefix on the DHCP-ward link, it can use
> the address on the link it /does/ use the prefix on as its GUA. Its
> link-local address on the DHCP-ward link will suffice for routing, and
> is known to the DHCP server because that's the address it used to do
> the IA_PD.
> >
> >
> >
> > +1, that's how I think such an implementation would behave.
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops