Subject: Re: 169.254/16 IP addresses

From: "Mike Borella" <[email-masked]>
Date: Fri, 14 Apr 2000 17:40:25 -0500

Oops, knee-jerk reaction on my part.  Some people have been
claiming that apps should be NAT aware and "discover" the NAT.
I misread the email.  You're right about the ARP issues, of course.

-Mike

Daniel Senie <[email-masked]> on 04/14/2000 04:14:07 PM

Sent by:  Daniel Senie <[email-masked]>

To:   Mike Borella/MW/US/3Com
cc:   [email-masked]
Subject:  Re: 169.254/16 IP addresses

Mike Borella wrote:
>
> NAT boxes don't need to be discovered, especially on these 1-hop
> subnets.

First client workstation self-assigns an address of 169.254.34.199.
Second client self assigns 169.254.250.12. The NAT box self-assigns
169.254.99.123.

The IP stacks on the clients need to have a default gateway set to know
they should route packets somewhere if the destination is not on the
local net (a /16 in this case).

How do you propose the default route gets set? If it doesn't get set, no
packets will be sent to a NAT box or anywhere else. Some sort of
discovery is thus necessary. This could be ICMP router discovery, for
example, but the answer can't be "NAT boxes don't need to be
discovered."

This isn't a point-to-point link where you can assume the box on the
other end of the wire is your default gateway.

> Daniel Senie <[email-masked]> on 04/14/2000 08:26:59 AM
>
> Sent by:  Daniel Senie <[email-masked]>
>
> To:   Mike Borella/MW/US/3Com
> cc:   [email-masked]
> Subject:  Re: 169.254/16 IP addresses
>
> Mike Borella wrote:
> >
> > People may be NATing linklocal addresses very soon or already.  The problem
> > is that quite a few large customers use private space for their networks,
but
> > want customized equipment that can be just dropped in (i.e. a small subnet
> > of logically distinct hosts and routers) and work with no IP configuration.
> > The solution is the linklocal space, with a NAT to the outside world.
> Choosing
> > any
> > other address space would cause major grief.
>
> What method is being used in these cases for discovering the NAT box? I
> can think of a few ways to do it, but am curious what products are doing
> this, and which mechanism(s) are used for the discovery.
>
> >
> > -Mike
> >
> > Richard Johnson <[email-masked]> on 04/14/2000 04:15:47 AM
> >
> > Sent by:  Richard Johnson <[email-masked]>
> >
> > To:   Mark Thompson <[email-masked]>
> > cc:   [email-masked] (Mike Borella/MW/US/3Com)
> > Subject:  Re: 169.254/16 IP addresses
> >
> > Mark Thompson writes:
> >  > I think the idea is that link-local addresses are used to communicate
> >  > *only* with devices on the local link, and that global addresses (or,
> >  > IYL, NATable addresses from Net10 etc.) are used for the "I want to
> >  > route to the outside world" cases.
> >  >
> >  > Actually, the draft does imply that IPv4 link-local autoconf is used to
> >  > "hunt" DHCP servers that appear after the local host comes up (Section
> >  > 4, "Ongoing checks for a DHCP server"). The idea is that your device
> >  > gets a link-local address when no globally-routable one (or NATed one)
> >  > is discovered, and then runs with it up until a DHCP server (or NAT gw)
> >  > becomes available.
> >
> > Unless there's some more recent version of the draft than what I've
> > seen, there's no mention of NAT in the draft at all.  It says:
> >
> >     Addresses allocated by this mechanism MUST NOT be routed by any net-
> >     work device.  The addresses are designed to be link local addresses.
> >     Link local address are to be, by definition, restricted to the local
> >     network segment.  Allocation of link-local addresses in an IPv6 net-
> >     work is described in [IPv6SAC].
> >
> > It's quite obvious why one would not want these addresses routed, but
> > there are very good reasons why someone may want to NAT these
> > addresses and there's no mention of whether NATing them is looked upon
> > as "good" or "bad".  I see no reason why it should be mandated that
> > NATing these addresses shouldn't be done.  I would bet that regardless
> > of what any document says, someone will end up allowing an option of
> > NATing these addresses anyway simply because some customer will demand
> > it.
> >
> >  > If you know by *specification* that the link-local addresses are only
ever
> >  > going to be seen by local devices, and that routers by *specification*
> >  > MUST NOT route/munge/forward packets destined to those addresses, I can
> >  > see cases where you can make certain assumptions about the communication
> >  > (topological location, security, etc. etc.) that you can't otherwise.
> >
> > I think the strongest reason here would probably be security, but even
> > that somewhat fails when one starts thinking of wireless networks.
> > Sounds like a false sense of security to me.
> >
> > /raj
>
> --
> -----------------------------------------------------------------
> Daniel Senie                                        [email-masked]
> Amaranth Networks Inc.                    http://www.amaranth.com

--
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 15 Apr 2000 12:45:59 -0700

>Second client self assigns 169.254.250.12. The NAT box self-assigns

Not sure what the use of this would be, since the purpose of the NAT
box probably is to connect the network to the Internet. It would
make more sense for the NAT box to assign itself a private IP
address (say from 192.168/16), and start up a mini-DHCP server to 
re-address the zeroconf workstations. In the process the zeroconf
workstations will also configure themselves with the default
gateway address and whatever else they need, via the mini-DHCP.

One interesting point here is whether the NAT box should assign
itself a preferred address (say 192.168.0.1), choose a "random"
address within the private address space, or take an address
that is persistent between reboots (e.g. a hash function applied
to the MAC address). 

Having an address that is persistent between reboots (whether
static or computed) may be desirable since this will make it
easier for hosts to renew DHCP leases, etc.

Personally, I think that statically choosing an address is
somewhat dangerous unless address conflict mechanisms are
used. So it is conceivable that a NAT box wouldn't be able
to obtain its "preferred" address anyway and therefore the
issue of persistence still arises.

---

From: Daniel Senie <[email-masked]>
Date: Sat, 15 Apr 2000 22:57:55 -0400

Bernard Aboba wrote:
> re-address the zeroconf workstations.

I agree with you entirely, but that was not the point of my message. I
was responding to a message saying that there was no need to discover a
default gateway in a network where addresses were self-assigned, and so
I described an example of a network where SOME sort of discovery would
have to happen.

The issue that was raised was that it was no problem to have a NAT box
handling a link-local address block. My message was pointing out the
problems which will arise.

> In the process the zeroconf

A "mini-DHCP" server is still a DHCP server. Aside from the transition
case, where a zeroconf node transitions to DHCP-assigned, the
DHCP-assigned case is outside of zeroconf scope.

> issue of persistence still arises.

An interesting discussion, which I'd like to continue. There are good
arguments for all cases. However, this is outside of zeroconf scope, so
that discussion should not occur here.