Subject: Issue 3: on link assumption considered harmful

From: Soliman Hesham <[email-masked]>
Date: Tue, 28 Oct 2003 21:46:44 -0500

Folks, 

This is a fairly straight forward issue. 

see: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-onlinkassumption-00.txt

2461 says in section 5.2 :

   Next-hop determination for a given unicast destination operates as
   follows.  The sender performs a longest prefix match against the
   Prefix List to determine whether the packet's destination is on- or
   off-link.  If the destination is on-link, the next-hop address is the
   same as the packet's destination address.  Otherwise, the sender
   selects a router from the Default Router List (following the rules
   described in Section 6.3.6).  If the Default Router List is empty,
   the sender assumes that the destination is on-link.

According to the draft mentioned above, this statement
was made to allow two links, previously configured with
two different global prefixes, to be joined, without a 
router and allow hosts to communicate using their 
global prefixes. 

The problems of this assumption are discussed in section 3
of Alain's draft. The draft suggests that this assumption
should be removed from ND specs. Here is the suggestion:

      The last sentence of the second paragraph of section 5.2
      ("Conceptual Sending Algorithm") should be removed.  This sentence
      is currently, "If the Default Router List is empty, the sender
      assumes that the destination is on-link.

      Bullet item 3) in section 6.3.6 ("Default Router Selection")
      should be removed.  The item currently reads, "If the Default
      Router List is empty, assume that all destinations are on-link as
      specified in Section 5.2."

To allow the scenario mentioned above to work, hosts would
have to communicate using their link-local addresses. 

This seems like a reasonable suggestion, any objections?

Thanks,
Hesham

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Oct 2003 21:54:18 -0500

On Tue, 28 Oct 2003 21:46:44 -0500

> This seems like a reasonable suggestion, any objections?

yes.  I strenously object to any expectation that ordinary apps should
be able to use link-local addresses.

---

From: Sebastien Roy <[email-masked]>
Date: Tue, 28 Oct 2003 22:40:39 -0500

> be able to use link-local addresses.  

The alternative is to configure systems that reside on the same link
to have the same prefixes.  There's no expectation that apps
communicate using link-local addresses.
-Seb

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Oct 2003 23:31:32 -0500

> to have the same prefixes. 

there are lots of other ways to solve that problem.  none of them can be
adequately described in one sentence - there are too many cases to consider.

> There's no expectation that apps

so the scenario described above was one in which hosts communicate
using link-local addresses for some other purpose than to support apps?
(in case it isn't clear, this is a rhetorical question)

Keith

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 29 Oct 2003 13:52:41 +0900 (JST)

> This seems like a reasonable suggestion, any objections?

	the "scenario" is not significantly attractive to me.  on the other
	hand, the issue with the current conceptual sending algorithm (fallback
	to IPv4 gets deleyed severely) is severe, so i'm all for the suggested
	change.

itojun

---

From: Sebastien Roy <[email-masked]>
Date: Wed, 29 Oct 2003 00:12:46 -0500

> adequately described in one sentence - there are too many cases to consider.

Point taken.  There are other ways to solve the problem that the
on-link assumption was originally trying to solve.  Do you have
suggestions on how the draft can better address other possible
solutions (if at all)?

> using link-local addresses for some other purpose than to support apps?

No, the scenario described in the draft doesn't necessitate using
link-local addresses for any purpose.  Even if the on-link assumption
were taken out of the Neighbor Discovery sending algorithm, there
would be no need for apps to communicate using link-local addresses
given adequately configured hosts.

-Seb

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Wed, 29 Oct 2003 14:44:18 +0100

Hello, please read at the bottom:

On Wednesday 29 October 2003 05:52, Jun-ichiro itojun Hagino wrote:
> > see:
> > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-onlinkassumption-00.
> >txt
> >

I think this scenario is useful for IPv6 small-devices, so I don't quite agree
with you all.

I feel that we are undoing a lot of things and we will end up with no 
autoconfiguration features at all. This might be a good thing 
for sysadmins, though.

If I understand the onlinkassumption draft well, the main drawback
of sending packets on-link is that some malicious party would
be able to grab those packets. I wonder...., if you've got
a malicious party on your link, you're suck. Even if you send
packets to your default router, the malicious guy could grab ethernet
frames and stuff...

-- 
JFRH