Hello, please read at the bottom:
On Wednesday 29 October 2003 05:52, Jun-ichiro itojun Hagino wrote: > > 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? > > 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. 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
