On 09/05/08 17:02, Sebastien Roy wrote:
On Fri, 2008-09-05 at 16:56 -0700, Darren Reed wrote:
We clearly shouldn't allow 127.0.0.1 be used as a source address when
sending packets out on the wire, but there isn't any harm in letting
them be delivered locally is there?
If we fast forward to a post-crossbow solaris, where we
have a vswitch, don't we have a "soft" wire by implication?
Not for packets whose source and destination belong to the same IP
stack. The core question being asked is whether this should be allowed
for inter-shared-IP-zone communication which is looped-around within the
ip module.
I do believe that the same harm exists in allowing this type of traffic
to cross shared-IP zone boundaries than exists for packets that go out
on the wire. Either way, the packet can be considered a bogon that is
forged and claims to be from somewhere which it is not.
While I agree there is a possibility of harm or undesired
interaction, there is also the question of whether or not
there is a compliance problem...when the host requirements
RFC was written, they didn't have zones, so we need to
interpret what the RFC means with respect to a zone.
To put this matter in a different perspective, is there any
reason that I shouldn't be able to reconfigure lo0 to be
127.0.0.0/24 and to then use 127.0.1.0/24 between network
interfaces associated with shared instance zones? If the
packets never leave the host then they're not technically
in violation of any standards that say 127/8 packets must
not be seen on the wire.
Why might I choose to use 127.0.1.0/24 on my local box?
Maybe it is a router on the border of my network, we use
192.168/16, 10/8 and 172.12/24 internally and everything
else is somewhere on the internet, so all that is left for
me to safely use on the host itself is 127.something.
There are benefits to be able to use 127/8 for more than
lo0, e.g. interfaces for ntp...
Does "local to the host" mean "local to the IP instance"
or "local to the running operating system"? (of which
there is only one in either case.)
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
