Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt

[Mark ZZZ Smith <[e-mail]>]

Well, it was actually a completely new prefix (but similar to ::1/128 to make easy to remember ('1' at the front verses '1' at the end), so I think new behaviour is fine. I did propose slightly different loopback/forwarding processing for this new 1::/32 prefix to match how 127/8 is processed, different to the current ::1/128 rules:

5.2.  Router Rules
   IPv4 loopback packet processing rules for routers, specified in   [RFC1812], by default prohibited forwarding of packets with 127/8   destinations, other than those originated locally and returned back   to the router itself.  A software switch could be provided to disable   this prohibition.  This special case of allowing forwarding of   packets towards 127/8 destinations has been taken advantage of by   [RFC4379], for MPLS troubleshooting purposes.  An equivalent function   for IPv6 is provided by using the IPv4-Mapped IPv6 prefix of ::ffff:


Smith                    Expires August 24, 2013                [Page 7] Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013

   127.0.0.0/104.
   The existing ::1/128 packet processing rules for routers are the same   as those for IPv6 hosts [RFC4291].
   For the new larger loopback prefix, the IPv6 router processing rules   are changed to match those of IPv4, to suit future uses similar to   the MPLS troubleshooting case.
      From: Erik Kline <[e-mail]>
 To: Mark ZZZ Smith <[e-mail]> 
Cc: David Conrad <[e-mail]>; "[e-mail]" <[e-mail]> 
 Sent: Tuesday, 17 February 2015, 11:49
 Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt
   
I was wondering about maybe an update/doc that merged this use case?

I was in favor of your loopback prefix, as I recall (it would be
especially handy if any application should implicitly bind to
1::${RAND96} /without/ any special permissions), but I can't recall
the opposition at the time.

/me re-reads/

Ah, yeah it turns out the use cases I wanted it for are exactly the
ones that were opposed by others at the time (the implicit delivery of
all packets to destinations in this prefix is /technically/ new
behaviour).  Sad panda.