Subject: Re: FYI: New ID submission- GRP

From: [email-masked]
Date: Thu, 8 Mar 2001 15:34:30 -0500

Erik,

You talking about NAT, and whether you can live with it. GRP is about how
to get to a gateway. Maybe it's running NAT, maybe it's an application
layer gateway.

Again GRP does not equal NAT, so arguing about NAT does not effect the need
to get to a gateway. These are two differing things.

It sounds like re-writting the ID so that there is a clear independance
from NAT would go a long way, right?

Spence

Spencer Giacalone, Predictive Systems
---------------------------------------------------------------
"Nothing so much prevents our being natural
as the desire to seem so" -Francois, Duc de
La Rochefoucauld

     To:  "Bernard D. Aboba" <[email-masked]>
     cc:  [email-masked], Daniel Senie <[email-masked]>,
[email-masked]
     bcc:
     Subject:  Re: FYI: New ID submission- GRP
Erik Guttman <[email-masked]>

03/08/2001 12:15 PM CET
Please respond to Erik Guttman           <font size=-1></font>

> > The question is one of whether 169.254/16 will be allowed through ANY
> > gateway of any sort. There was quite a bit of discussion about this on
> > this mailing list in months past.
>
> I vote "NO" on this. No forwarding. No NAT. No use in 6to4. About the
> only thing I can live with is an application layer gateway (e.g. home web
> portal secured by SSL).
>

I completely agree with Bernard.  If remote access to the zeroconf
link-local network is desired, let it be through a secured gateway.

This could be an application layer gateway, or a secured tunnel.
An example of a secured tunnel would be a remote host using PPP,
which authenticates itself to a gateway.  Then, using a not-yet-
invented protocol, the remote host could obtain a link-local address
on the zeroconf link, with mediation of the gateway.

If I am not mistaken, this is similar to ideas Myron Hattig presented
back at the second NITS BOF in 99.  We decided at that time that we
would not attempt to charter work on secure remote access, though
there was great interest in it (especially among 'home networking'
vendors.)

Erik

---

From: Daniel Senie <[email-masked]>
Date: Thu, 08 Mar 2001 16:21:13 -0500

> to get to a gateway. Maybe it's running NAT, maybe it's an application

The application layer gateway should be located via service location,
which is discussed in the zeroconf requirements document. I believe
that'd be the best way to find an appropriate application gateway path
for a particular need or service.

> to get to a gateway. These are two differing things.

If there's no traffic off the zeroconf net, then there's no need to find
a gateway at the IP layer.

The reason to think in terms of service location, is there may be many
application gateways carrying application data (hopefully secured) on
and off the LAN. They may be providing different types of information to
different outside players. Having a way to find the "one true gateway"
is not necessarily a useful concept.

> from NAT would go a long way, right?

And from any discussion of forwarding. To answer your question from an
earlier email to the list, yes, I consider NAT a routing function: it's
gatewaying IP packets at layer 3 from one network to another. While it
does mangle the header information in the process, that makes it no less
a layer 3 forwarding function. You are carrying data from one realm to
another. I think other respondents have also made this same position
clear, for the same reasons.

Security is a big part of the reason for this stance. At a minimum, you
need to add the required security considerations section to your draft.
As you talk of a special code point use (an address), an IANA
considerations section should also be present.

I still don't see the need for GRP at all. Zeroconf requirements call
for the use of service location. Should we need to find gateways by
other means, we do have ICMP Router Discovery which could be employed,
though I hope we won't need to use it. It's not clear we need gateway
location protocol to find our way around 169.254/16.

The zeroconf requirements document gives the requirements for the
service location protocol. If you want to start thinking about how such
a protocol could be implemented, that'd be an area to explore. You'll
note, however, that the preset goals of the working group include only a
scoping of the problem, plus formal definition of the link-local address
space and a similar specification for multicast.

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