Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)

[Randy Bush <[e-mail]>]

sorry, but i have neither time, energy, ... to talk about pointed
sticks, horrible things which stupid people might do (which they can
do today anyway), and other hyperbole.  i am just trying to deal with
the reality of running networks.  and i will admit to being biased to
the opinions of those who actually run networks.  so can we focus on
the actual document?  in particular

---

4.  Recommendations

   For historical reasons, when a prefix is needed on a link, barring
   other considerations, a /64 is recommended [RFC7136].

   The length of the Interface Identifier in Stateless Address
   Autoconfiguration [RFC4862] is a parameter; its length SHOULD be
   sufficient for effective randomization for privacy reasons.  For
   example, a /48 might be sufficient.  But operationally we recommend,
   barring strong considerations to the contrary, using 64-bits for
   SLAAC in order not to discover bugs where 64 was hard-coded, and to
   favor portability of devices and operating systems.

   Nonetheless, there is no reason in theory why an IPv6 node should not
   operate with different interface identfier lengths on different
   physical interfaces.  Thus, a correct implementation of SLAAC must in
   fact allow for any prefix length, with the value being a parameter
   per interface.  For instance, the Interface Identifier length in the
   recommended (see [RFC8064]) algorithm for selecting stable interface
   identifiers [RFC7217] is a parameter, rather than a hardcoded value.

---

the above are actual reality today; the draft just tries to clarify
subtle confusions caused by existing and proposed ipv6 addressing
documents.  as the draft says, this is to prevernt mismatches between

   formal specification and long-standing field deployment practices are
   never wise, not least because of the strong risk of mis-
   implementation, which can easily result in serious operational
   problems.

in talking to operators here, at home, and ripe, i heard some desire
to say something to clarify that /128s (or /80s or whatever) to end
sites/customers etc. are not being recommended.  can we do this
without overly-prescribing how operators run their networks or
stepping into the RIR allocation policy swamp?

randy