Re: v6 vs gif

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 30 Jan 2009 11:18:07 -0500 (EST)
    From:        der Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <200901301626.LAA23521%Sparkle.Rodents-Montreal.ORG@localhost>

  | > Non /64 prefix lengths is contrary to du jure standard for prefixes
  | > in 2000::/3.  (rfc4291 section 2.5.4)
  | 
  | Oh, ouch.  That's just insane.

Yes it is.   Fortunately it is also a meaningless requirement, totally
unenforceable (or even detectable from outside).

There's some stuff that only works on /64 prefixes, and that's fine, as
long as you don't mind that stuff not working (which is almost certainly
going to be true on a gif link) then use whatever prefix length you like.

The only thing we need to watch for are that systems (like NetBSD) don't
start to try to enforce this gibberish - fortunately NetBSD has never
even considered it that I'm aware of.

  | Didn't the v6 people
  | learn _anything_ from the breakdown of v4 address classes?!

The people who designed v6 didn't include any of this trash,   This
has been added by people who want to be able to control other people's use
of address space for all kinds of stupid reasons.

  | > De facto reality is a completely different matter.  There is a
  | > notable amount of operational resistence to /64 on p2p links.
  | 
  | What would it even _mean_?

Part of the idea is that there are supposed to be a whole set of reserved
anycast addresses on every prefix, the idea is that given any address
you (anyone) can calculate the anycast address of the X on the link, if
there is one.   There's no requirement that there be an X on the link of
course, but they want everyone to reserve all these addresses anyway...

kre