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

From: [email-masked]
Date: Wed, 11 Jul 2001 12:14:04 -0400

>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. 

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

Daniel Senie <[email-masked]>
07/11/01 11:11 AM

        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 11:08 AM 7/11/01, [email-masked] wrote:
>I noticed that the example uses a 1918 address. Do you only propose this
>enhancement for hosts using 1918 on the same net as zero conf?

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.

> >If a link-local device has only 169.254/16 in its admittedly small
>routing
> >table, won't it just look at the 10/8 address and decide there's no 
route
>
> >to that network?
>
>Sounds right to me, unless you mess with something else..

> >There's no default route, and no way for it to know that
> >it should try to ARP for that 10/8 address. So, it still won't
>communicate.
>
>Right. You'd need a router for this inter network communication, but...
>Please refer to my next note.
>
> >We may like to dictate that Device B MUST implement link-local 
addresses,
> >but the world doesn't work like that. If the vendor of Device B doesn't
> >have the engineering resources to implement link-local addresses, then 
is
> >it better for the user if the devices can talk safely, or not?
>
>This is starting to sound like the reasoning I used to propose gateway
>discovery/NAT solutions for Zeroconf nets. At that time I presented the
>idea that a "vendor of Device B doesn't have the engineering resources to
>implement link-local addresses". As you no doubt remember, this logic was
>rejected.
>
>To me, in addition to the fact that there are some relevant operational
>issues (like ARP) this idea sounds either like A) a bad/confusing idea, 
or
>B) a reason to re-open proposals for expanding zero conf functionality
>(hint). Also, IMHO, this is adding fuel to the dynamic gateway discovery
>argument.
>
>By the way, it's seems clear that hosts talking to both zero conf AND
>normal IP on the same net has some security implications. Backdoor,
>anyone? This was the core of the anti-NAT argument..

All good points.

> >Alternatively (and I'm not in favor of this alternative), we could say
>that
> >a box which is running link-local-only should indeed treat 0/0 as link
> >local, and ARP for any and all addresses. This would seem to be a very
>bad
> >idea. While it would allow a device in link-local-only mode to talk to 
a
> >box with both link-local and another address to function, it would also
> >allow a link-local-only box to talk to a box with only a configured
> >address. This box with the configured address would not know to ARP for
>the
> >link-local address on the local wire, though, if it's only configured 
for
>
> >non-link-local. I think any change in this area would require touching
>most
> >hosts code to ensure compatability.
>
>Other ideas that dont sound too good- Router based proxy ARP? That'll 
open
>up some issues. How about secondary IP addresses support on a host basis,
>so host know what specific, but seperate ranges to ARP for?
>
>Or, perhaps, we could just use NAT and a gateway discovery protocol to
>zero conf hosts talk to ""vendor of Device B doesn't have the engineering
>resources to implement link-local addresses", and keep zero conf host on
>their on little networks :-)

Ick. Let's see if we can find a way to stay far from this territory...

>
>:-) Spence
>
>
>
>
>
>
>
>Daniel Senie <[email-masked]>
>Sent by: [email-masked]
>07/11/01 09:34 AM
>
>
>         To:     Stuart Cheshire <[email-masked]>, "Jim Busse" 
> <[email-masked]>,
>"Thomas Narten" <[email-masked]>, <[email-masked]>
>         cc:
>         Subject:        RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt
>
>
>At 03:31 AM 7/11/01, Stuart Cheshire wrote:
> > >In my opinion, is no reason to change the wording to "should".  I 
think
>the
> > >concept that the169/254/16 prefix packets are coming from a 
"friendly"
> > >link-local network, the use of some other address may look like an
> > >"intruder".  I like the original wording best.  Maybe Thomas could 
give
>a
> > >reason for the "too strong"?
> >
> >I think the reasoning is this:
> >
> >Say you have two devices on the same physical Ethernet. Device A
> >implements link-local addresses, and has assigned itself one. Device B
> >does not implement link-local addresses, but has a manually configured
> >address of 10.0.0.1.
> >
> >These devices are on the same physical Ethernet. Is it useful for the
> >link-local draft to prohibit them from talking to each other?
>
>If a link-local device has only 169.254/16 in its admittedly small 
routing
>
>table, won't it just look at the 10/8 address and decide there's no route
>to that network? There's no default route, and no way for it to know that
>it should try to ARP for that 10/8 address. So, it still won't
>communicate.
>
> >We may like to dictate that Device B MUST implement link-local 
addresses,
> >but the world doesn't work like that. If the vendor of Device B doesn't
> >have the engineering resources to implement link-local addresses, then 
is
> >it better for the user if the devices can talk safely, or not?
>
>My point here is that if the other device tries to answer with the
>non-link-local address, a box working in link-local-only mode may have no
>way to respond. If boxes are going to use multiple addresses, then we 
have
>
>to handle communicating with boxes which don't know how to reach any
>addresses other than link-local.
>
>Alternatively (and I'm not in favor of this alternative), we could say
>that
>a box which is running link-local-only should indeed treat 0/0 as link
>local, and ARP for any and all addresses. This would seem to be a very 
bad
>
>idea. While it would allow a device in link-local-only mode to talk to a
>box with both link-local and another address to function, it would also
>allow a link-local-only box to talk to a box with only a configured
>address. This box with the configured address would not know to ARP for
>the
>link-local address on the local wire, though, if it's only configured for
>non-link-local. I think any change in this area would require touching
>most
>hosts code to ensure compatability.
>
>-----------------------------------------------------------------
>Daniel Senie                                        [email-masked]
>Amaranth Networks Inc.                    http://www.amaranth.com

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

---

From: Daniel Senie <[email-masked]>
Date: Wed, 11 Jul 2001 12:19:40 -0400

>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