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

RE: RFC2461bis: Empty default router lists [was: RE: Comments for rc2461bis]



 > 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:
 > elwynd@xxxxxxxxxxxxxxxxxx
 >         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
ipv6@xxxxxxxx
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------