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

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

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: [email-masked]
Date: Wed, 11 Jul 2001 11:08:34 -0400

routing 

communicate.

that 
bad 
the 

most 

 
:-) Spence

        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

the
a