> Quoting from S5.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). > > So if there are no routers admitting to be connected to the > link and the > prefix list is empty (no routers to fill it), what happens > here? Presumably > the longest prefix match will fail implying that the address > is off link. > Hence we have to find a router, but there isn't one. What > do we do with the > packet?
=> There are two basic cases to consider: 1. Dst address is off-link (i.e. longest prefix match fails). In this case you'll either send it over the tunnel or drop the packet if there is no tunnel. 2. Longest prefix match works, destination is on-link. This will work. > > With a point-to-point link (like the tunnels) we could just > stuff the packet > down the link and hand off the decision to the other end. > For an isolated > multiaccess link the decision is not so simple: Just having > our own address > doesn't allow us to decide whether any other address is on > link, so if the > destination is not in the neighbor cache already what do we > do? Toss the > packet or assume it is on-link? Being able to configure an > on-link prefix > would solve the problem IMO. > > Am I missing something here? => You must be assuming that you can have a link with no routers and inconsistent prefixes on different hosts. For instance, you're assuming that you can have an isolated link where host1's address is configured from one prefix and host2's address is configured based on a completely different one. When we discussed this issue last year there was agreement that if you have this scenario, hosts should be configured from the same prefix. If that happens, there should not be a problem with on-link determination. You don't need to manually add a prefix to the prefix list here, you simply configure all addresses using the same prefix. Hesham > > Regards, > elwyn > > Original Message > ================ > [S5: Prefix List: Having removed the 'assume it is on > link' if no routers, > it might be useful to allow a prefix to be inserted into the > prefix list by > manual configuration when dealing with a single link net.] > => Is this really needed? Isn't enough to be able to > configure an address > given that the next hop > determination is based on a longest prefix match? I won't > add this unless > you see a reason for it. > s5.2: It ought to be stated that if the default router list > is empty then > off-link unicast packets will have to be dropped and an > 'unreachable' ICMP > message sent.[whether the packet ought to have got as far as > the interface > processing is a moot point]. > => Hmmm. How does this work in the case where the > destination address is > on the other > end of an IPv4 tunnel and there is no default router in the > list? This is > why the onlink assumption > was removed. > > > ------------------------------------------------------------- > --------------- > ------ > > Elwyn B Davies > > Routing and Addressing Strategy Prime & IPv6 Core Team Leader > CTO Office, Portfolio Integration Solutions Ready > > > Nortel Networks plc Email: > [EMAIL PROTECTED] > Harlow Laboratories ESN > 6-742-5498 > London Road, Harlow, Direct Line > +44-1279-405498 > Essex, CM17 9NA, UK Fax > +44-1279-402047 > Registered Office: Maidenhead Office Park, > Westacott Way, > Company No. 3937799 Maidenhead, > Berkshire, SSL6 > 3QH > ------------------------------------------------------------- > --------------- > This message may contain information proprietary to Nortel > Networks plc so > any > unauthorised disclosure, copying or distribution of its > contents is strictly > prohibited. > ------------------------------------------------------------- > --------------- > "The Folly is mostly mine" > and the opinions are mine and not those of my employer. > ============================================================= > =============== > ====== > > > =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
