[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RFC2461bis: Empty default router lists [was: RE: Comments for rc 2461bis]


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

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?


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:
        Harlow Laboratories     			ESN
        London Road, Harlow,    			Direct Line
        Essex, CM17 9NA, UK     		Fax
        Registered Office: 			Maidenhead Office Park,
Westacott Way,
        Company No. 3937799			Maidenhead, Berkshire, SSL6
This message may contain information proprietary to Nortel Networks plc so
unauthorised disclosure, copying or distribution of its contents is strictly
"The Folly is mostly mine"
and the opinions are mine and not those of my employer.

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6