Hi.
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?
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?
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.
============================================================================
======
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
