Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt

From: [email-masked]
Date: Wed, 11 Jul 2001 14:21:20 -0400

>We may be getting back to an argument that dual addressing is more 
trouble 
>than it's worth, but we have to deal with the same issue in IPv6 
>deployments, so we might as well figure out how to deal with it in all 
cases.

Agreed- My point before was that these issues, to me, seem similar to the 
concerns which where rasied with the gateway/NAT draft. If my perspective 
is correct (which it may very well not be), it would seem logical that 
this proposal would be DOA. 

Spencer Giacalone, Predictive Systems
---------------------------------------------------------------
"What is real? How do you define real?" 
 -Morpheus 

Daniel Senie <[email-masked]>
07/11/01 12:19 PM

        To:     [email-masked]
        cc:     Stuart Cheshire <[email-masked]>, "Jim Busse" <[email-masked]>, 
"Thomas Narten" <[email-masked]>, [email-masked], 
[email-masked]
        Subject:        RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt

At 12:14 PM 7/11/01, [email-masked] wrote:
> >Thomas had used that as an example, so I did too, but I don't see this 
as
>a
> >case where the fact that the address is RFC1918 vs. publicly routable 
has
>
> >any bearing.
>
>In the case of using dual zero+normal IP hosts as backdoors, it might.

The issue of backdoors with dual addressing applies regardless. Even with 
RFC1918 addresses, it can apply. Firewall boxes often include a feature to 

forward specific ports to specific addresses on the private network, which 

are usually in RFC 1918 space. As such, looking at whether an address is 
RFC 1918 or not is insufficient to determine whether the other host is to 
be trusted or not.

We may be getting back to an argument that dual addressing is more trouble 

than it's worth, but we have to deal with the same issue in IPv6 
deployments, so we might as well figure out how to deal with it in all 
cases.
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com