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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Ma
rk ZZZ Smith writes:
> 
> 
> 
> 
> ________________________________
> From: Mark Andrews <[e-mail]>
> To: Mark ZZZ Smith <[e-mail]> 
> Cc: David Conrad <[e-mail]>; "[e-mail]" <[e-mail]> 
> Sent: Tuesday, 17 February 2015, 12:23
> Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-p
> refix-00.txt
> 
> 
> 
> The fundemental reason for 127.0.0.0/8 was to give each node a
> addresses block they could use. 127.0.0.1 evolved as the "standard"
> loopback address over time.
> 
> / Actually, 4.2BSD made added the '.1' as the default address, as the '0' the
> y'd originally chosen was the BSD broadcast address:
> 
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/sys/netinet/if_lo
> op.c

Yes, BSD squatted on the address.  I was well aware of the history.
 
>  For the most part no one uses the rest
> of 127.0.0.0/8 but it is useful to have available.
> 
> / I'm not sure I completely agree with the idea, however the NTP reference cl
> ock drivers use 127.127/16 addresses to make them available to the ntp daemon
> . I think this use is a bit different to what ICANN specified, as those addre
> sses only have local significance on the host that both the ntp daemon and th
> e reference clocks are attached to. Outside of that host they're unreachable 
> and have no meaning. Fortunately with millions of other addresses within 127/
> 8 there are plenty of others to use for other purposes on the host.

Yes, they have squatted on these address for internal uses.  The
only reason this doesn't cause issues is that for the most part
127.0.0.0/8 is not used.

> That said any
> use of the rest of 127.0.0.0/8 has to be negotiated between the
> users.  You can't just grab 127.0.0.2 and hope that no one else is
> using it for IP traffic.
> 
> 
> / I'm a bit confused by this. 127.0.0.2 traffic should not be leaking outside
>  of the host, as that is contrary to RFC990/RFC1122 rules. So the only risk o
> f collision is two users on the same host. That is of course possible, howeve
> r the great thing is that there are millions of other loopback addresses avai
> lable on the host that the users can choose from, and the ones in use can be 
> viewed with 'netstat -a -4 -n' or similar. Hosts have become pretty much sing
> le user too these days.

I have two different applications which have hard coded 127.0.0.2
port 2356 as the way to connect to them.  Which one gets to use
127.0.0.2 port 2356?  As I said the use of the rest of 127.0.0.0/8
needs to be negotiated.  No one and "rights" on any part of it.

> / ::1/128 is pretty much single user use.
> 
> In IPv6 we had both link local and site local addresses from the
> get go.  These gave the operator addresses they could use.  They
> were also slightly more complicated than a GUA as you needed to
> specify scope.  We now have ULA addresses which gets rid of the
> need to specify scope.  Just like with 127.0.0.2 you need to negotiate
> the use of a address.
> 
> Reserving a new block of addressing in IPv6 will not stop the need
> to negotiate address use.
> 
> If you need truly automatic assignment you need to go to IANA or a
> RIR (e.g. ARIN and 100.64/10) and request a block for a specific
> 
> purpose.  There is no other way to do truly automatic.
> 
> / From my draft:
> 
> "9.  IANA Considerations
> 
> IANA is requested to allocate 0001::/32 from within 0000::/8 of the
> Internet Protocol Version 6 Address Space, for use as a larger
> loopback prefix for IPv6, as detailed in this memo, and to record it
> in the [IANA-IPV6REG]."

And 1::1 will have what automatic meaning?  Which application get
*exclusive* use of 1::1?  1::/32 would be scratch space.

We already have enough mechanisms to create scatch space.  If you
need a /32 then you can get one from ULA space.  There are 16M /32's
ULA blocks for local assignment.

If a application needs reserved address space that will never collide
with anyone else then the vendor should request it from the RIR's
for the use of the application.  Even if 1::/32 is allocated it is
useless for that purpose.

Mark

> Mark
> 
> In message <[e-mail]>, M
> ar
> k ZZZ Smith writes:
> > So the fundamental problem is 'configured like this'. It's a manual operati
> on
> >  to generate and apply a ULA. ULAs on loopbacks aren't going to well known 
> or
> >  ubiquitous.
> > 
> > If you want something to be used you need to make it easy, and the best way
>  t
> > o make something easy is to make it automatic.
> > 
> > The value in 127/8, ::1 and a larger IPv6 loopback prefix is that it is or 
> wo
> > uld be automatically configured by the OS, with operator intervention. It's
>  a
> > lways there, and always available to use. The 4.1c/2.9BSD people though the
> re
> >  was value in automatic configuration of the loopback address on a loopback
>  i
> > nterface, way back in 1982/1983:
> > 
> > http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/sys/net/if_loop
> .c
> > 
> > http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/a/sys/netinet/if_loop.
> c
> > 
> > 
> > 
> > ----- Original Message -----
> > From: Mark Andrews <[e-mail]>
> > To: David Conrad <[e-mail]>
> > Cc: Mark ZZZ Smith <[e-mail]>; "[e-mail]" <v6ops@iet
> f.
> > org>
> > Sent: Tuesday, 17 February 2015, 10:22
> > Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback
> -p
> > refix-00.txt
> > 
> > 
> > We don't need *more* reserved address for this.  This is from my
> > laptop and it has been configured like this for years.
> > 
> > Yes, I have a ULA site on my loopback interface.  If your loopback
> > interface does not support this it is broken.
> > 
> > 
> > Mark
> > 
> > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
> >     options=3<RXCSUM,TXCSUM>
> >     inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
> >     inet 127.0.0.1 netmask 0xff000000 
> >     inet6 ::1 prefixlen 128 
> >     inet 10.53.0.1 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::1 prefixlen 64 
> >     inet 10.53.0.2 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::2 prefixlen 64 
> >     inet 10.53.0.3 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::3 prefixlen 64 
> >     inet 10.53.0.4 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::4 prefixlen 64 
> >     inet 10.53.0.5 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::5 prefixlen 64 
> >     inet 10.53.0.6 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::6 prefixlen 64 
> >     inet 10.53.0.7 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::7 prefixlen 64 
> >     inet 10.53.0.8 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::8 prefixlen 64 
> >     inet 10.53.0.9 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::9 prefixlen 64 
> >     inet 10.53.0.10 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::10 prefixlen 64 
> > 
> > -- 
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: [phone]                 INTERNET: [e-mail]
> 
> 
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]