IPv6 end user addressing
owen at delong.com
Sat Aug 6 04:21:27 CDT 2011
On Aug 6, 2011, at 12:47 AM, Sascha Lenz wrote:
>> Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be
>> zeroing in on a /56 for production. Though some ISPs are using /64 for
>> their trials.
> IIRC, there's RfC6177 - covering almost exactly what the original poster asked for.
> Not sure if it was mentioned already.
RFC6177 sort of appears to recommend /56 if you don't look at it too closely.
What it really says is essentially "The IETF throws its hands up in the air and
refuses to make any recommendations in this arena leaving the entire thing
to RIRs and service providers where we probably should have put it in the
> /48 is what IPv6 was designed for, /48 per customer (or even per customer-site some might say) is supported by the RIR policies,
> and there are close to zero reasons not to use a /48. It also eases your administration
> processes and also operational things.
AMEN, Brother! ;-)
> Of course, if you only have John Average residential customers or whatever, use a /56 or /60.
> It's your choice. You know your customers best. We're not in a classful world again :-)
> But do your math, there is no address shortage, handing out a /48 to every type of customer
> as a single assignment size should be the sane choice.
> You waste precious time thinking too much about it.
Yep. Even if you only have John Average residential customer. Residential customers today are
not going to be the same as residential customers in 5, 15, or 25 years. Giving them /48s will save
you (and them) a lot of heartache down the road. (and yes, I mean a /48 per end site structure or
per tenant in a multi-tenant structure).
> At least don't make your life miserable by experimenting with too many different assignment sizes,
> or advocate /64s or something, that's considered a design fault which will come back to you some day.
> Read the RfCs and RIR policy discussions in the archives some years ago.
Also, please don't make your life miserable by trying to align things on odd bit boundaries. Stick
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2105 bytes
Desc: not available
More information about the NANOG