owen at delong.com
Mon Nov 22 09:23:40 CST 2010
>> I don't see a problem with people not assigning customers /56s so long
>> as they go in the correct direction and give /48s and not /60s or /64s.
> Many ISPs will end up handing their customers /64, /62 or other
> less-than-ideal prefixes. As soon as a customer needs to subnet their
> /64, the real fun starts. There is nothing we can do about it, other
> than trying to educated people and hope for the best.
If we educate a sufficient percentage of ISPs and solve the perception
problems of the RIR policies that are driving some ISPs to be overly
conservative (see proposal 121 in the ARIN region for an example of
what I think represents a reasonable solution), then, the other ISPs
will eventually find themselves at a competitive disadvantage as their
customers start to ask "Why can't I have a /48 like my friend Bob
got from provider Z?" This is a good thing, but, it means we need to
do what we can to educate as many ISPs as possible as quickly
as possible during this critical phase of deployment.
>>> I honestly think I never explained (as in, after I understood the
>>> matter, myself) netmasks other than as a bit vector. Unless you mean
>>> "write 255.255.255.0 in there cause that's what right for you".
>> Then you are young and never had to deal with systems that didn't
>> know about bit-vector syntax. I have had to explain the translation
>> between bit-vector syntax (/n) and bit-field syntax (255.255.255.240)
>> to many people. It's easy when n is a multiple of 8. After that,
>> it can be quite hard for some mathematically challenged individuals
>> unfamiliar with binary and BCD to wrap their heads around.
> I wish ;)
> Either the person can grasp that a dotted netmask can be transformed
> into a bit vector or I tell them "use 255.255.255.0 everywhere, it
> will work for everything you will ever need." 80/20 and all that.
Ah... OK... Sorry, I'm the guy that had to deal with all of your users
when they found themselves on one of my /27s and tried to use
255.255.255.0 there. :p
So... Don't worry, I ended up picking up the educational task where
you left off.
(OK, maybe not the exact same set of users, but, honest, you're not
the only one who took this approach and it did lead to interesting
breakages by users so educated in a number of places I have worked.)
>> Removing bitmath from operations where possible is a good thing
>> that reduces outages caused by human factors. It's just good human
>> factors engineering.
>> We can't do so in IPv4, there aren't enough bits to do it.
>> We seek to do so in IPv6 with ARIN draft policy 2010-8 and
>> proposal 121.
> If by bitmath you mean ending netmasks not on full bytes only, I could
> not agree more. This will reduce a lot of useless overhead.
> I really wish the RIRs would get unique a name space for their
> respective drafts. If even my person object needs a -RIPE suffix, I
> don't see why drafts etc don't.
Well, in IPv6, I think ending them on nibbles is fine. Specifically, see
ARIN Policy Proposal 121 (as mentioned above).
>> Should we all sing kumbayah now?
> Only if you bring a tambourine.
Sorry, I don't own a tambourine.
More information about the NANOG