Bug 31891

On Sat, Nov 10, 2001 at 07:11:26AM +0300, .@babolo.ru wrote:
[snip]

> >Description:
> 
> There was 4.2 RELEASE, where packets with 127.0.0.0/24 source address
> droped on input interfaces. Now it changed to 127.0.0.0/8,
> which is incombatible with old configuration.
> This net - 127.0.0.0/8 is extremly useful
> as private net in clustering environment,
> so I propose configuration variable MYLOOP_MASKLEN,
> with default meaning that conforms RFC1122
> 
> >How-To-Repeat:
> 
> Try P2P addresses in 127.0.0.0/8 net.

This is a feature, not a bug. See RFC1122, "Requirements for Internet
Hosts,"

            (g)  { 127, <any> }

                 Internal host loopback address.  Addresses of this form
                 MUST NOT appear outside a host.

The 127/8 is never valid when coming from another host.

Do not use 127/8 as a private network, that's what RFC1918 addresses
are for.
-- 
Crist J. Clark                     |     cjclark@alum.mit.edu
                                   |     cjclark@jhu.edu
http://people.freebsd.org/~cjc/    |     cjc@freebsd.org

Comment 2 Crist J. Clark 2001-11-15 10:11:28 UTC

State Changed
From-To: open->closed

The reported problem is RFC-compliant behavior, not a bug.

Crist J. Clark writes:
> On Sat, Nov 10, 2001 at 07:11:26AM +0300, .@babolo.ru wrote:
> [snip]
> 
> > >Description:
> > 
> > There was 4.2 RELEASE, where packets with 127.0.0.0/24 source address
> > droped on input interfaces. Now it changed to 127.0.0.0/8,
> > which is incombatible with old configuration.
> > This net - 127.0.0.0/8 is extremly useful
> > as private net in clustering environment,
> > so I propose configuration variable MYLOOP_MASKLEN,
> > with default meaning that conforms RFC1122
> > 
> > >How-To-Repeat:
> > 
> > Try P2P addresses in 127.0.0.0/8 net.
> 
> This is a feature, not a bug. See RFC1122, "Requirements for Internet
> Hosts,"
> 
>             (g)  { 127, <any> }
> 
>                  Internal host loopback address.  Addresses of this form
>                  MUST NOT appear outside a host.
> 
> The 127/8 is never valid when coming from another host.
> 
> Do not use 127/8 as a private network, that's what RFC1918 addresses
> are for.
OK.
Lets it be feature.
Consider please case where more then one
kernel looks for outside world as one entity.
May be name "cluster" is good enough in this case.
There no protection beetween kernels in such
environment and use of 127.X nets for interface
inside cluster somehow protects from outside world.
Yes, I remember another means too.

Sorry my English is bad.

-- 
@BABOLO      http://links.ru/

On Thu, Nov 15, 2001 at 07:23:11PM +0300, .@babolo.ru wrote:
> Crist J. Clark writes:
> > On Sat, Nov 10, 2001 at 07:11:26AM +0300, .@babolo.ru wrote:
> > [snip]
> > 
> > > >Description:
> > > 
> > > There was 4.2 RELEASE, where packets with 127.0.0.0/24 source address
> > > droped on input interfaces. Now it changed to 127.0.0.0/8,
> > > which is incombatible with old configuration.
> > > This net - 127.0.0.0/8 is extremly useful
> > > as private net in clustering environment,
> > > so I propose configuration variable MYLOOP_MASKLEN,
> > > with default meaning that conforms RFC1122
> > > 
> > > >How-To-Repeat:
> > > 
> > > Try P2P addresses in 127.0.0.0/8 net.
> > 
> > This is a feature, not a bug. See RFC1122, "Requirements for Internet
> > Hosts,"
> > 
> >             (g)  { 127, <any> }
> > 
> >                  Internal host loopback address.  Addresses of this form
> >                  MUST NOT appear outside a host.
> > 
> > The 127/8 is never valid when coming from another host.
> > 
> > Do not use 127/8 as a private network, that's what RFC1918 addresses
> > are for.
> OK.
> Lets it be feature.
> Consider please case where more then one
> kernel looks for outside world as one entity.
> May be name "cluster" is good enough in this case.
> There no protection beetween kernels in such
> environment and use of 127.X nets for interface
> inside cluster somehow protects from outside world.

Using 127/8 affords no more "protection" from the outside world than
using an RFC1918 network. None of those networks is routed on the
Internet-at-large. Of course, none of that will protect you from
source routing. For a cluster as you describe, I would recommend a
firewall or better yet, disconnection from public networks.

But in any case, the Internet Standard is clear. 127/8 packets must
not ever be seen outside of a host. You should never see those
crossing a physical interface. It makes even less sense to treat
127/24 or some subnet of 127/8 like this, but not 127/8 as a whole.
Of course, you can feel free to break any standards you wish on your
own network (but don't complain too much when things stop working);
you already have the patches to do so. But I don't think there is any
desire to incorporate them into the base FreeBSD IP stack.
-- 
Crist J. Clark                     |     cjclark@alum.mit.edu
                                   |     cjclark@jhu.edu
http://people.freebsd.org/~cjc/    |     cjc@freebsd.org