Subject: RE: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy)

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 28 Oct 2004 13:39:52 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Vijay Devarapalli
> Sent: jeudi 28 octobre 2004 01:37
> To: Ville Nuorvala
> Cc: [email-masked]; [email-masked]; Erik Nordmark
> Subject: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy)
> 
> sorry for the cross posting, but here is something to 
> consider when RFC 3775 is revised.
> 
> Ville Nuorvala wrote:
> > On Wed, 27 Oct 2004, Erik Nordmark wrote:
> > 
> > 
> >>When the CN sends packets to HoA(MN) it would match the 
> first binding.
> >>I don't think RFC 3775 prescribes what a CN should do when, after 
> >>applying the binding and adding RH2 to the packet, there is another 
> >>binding which matches what is then in the destination field of the 
> >>packet. (But it would make sense to check this in the spec).
> >>So different CN implementations might do different things such as:
> >>  - ignore the second binding
> >>  - apply the second binding in a recursive way i.e. add another RH2
> >>    header
> >>  - fail (drop the packet or crash)
> > 
> > 
> > RFC 3775 Section 6.1.7 says:
> > 
> >    Binding Updates for a care-of address which is not a 
> unicast routable
> >    address MUST be silently discarded.  Similarly, the 
> Binding Update
> >    MUST be silently discarded if the care-of address 
> appears as a home
> >    address in an existing Binding Cache entry, with its 
> current location
> >    creating a circular reference back to the home address 
> specified in
> >    the Binding Update (possibly through additional entries).
> > 
> > What this exactly means is open to interpretation. Strictly 
> speaking 
> > it might mean it is ok to have several linked entries as 
> long as they 
> > don't create a circular reference, but it is unlikely.
> 
> yes, it should be possible to have several linked binding 
> cache entries.
> 
> > 
> > I think the general assumption is that there will be just 
> one RH type 
> > 2 per packet. That's at least what we assume in MIPL, but 
> of course I 
> > can't speak on the behalf other implementations.
> 
> but we seem to have disallowed by the above by mistake in RFC 3775.
> 
> RFC 3775 restricts RH Type 2 to only one address (segments 
> left is always 1). RFC 2460 says a routing header can occur 
> only once in a packet. (except for destinations options 
> header, all other extension headers can appear only once in a packet).
> 
> RFC 3775 should have allowed more than one address in RH type 
> 2 and required that the desination address on the packet and 
> the next addressed to be processed in the routing header 
> belong to the same node. this would have allowed us to 
> include more than one address in the routing header, but 
> still satisfy the security requiements of Mobile IPv6.
> 

Agreed. That's actually part of the RRH spec. 

There's also a rule that enforces that the RH2 can only be forwarded
down the nested tree.
If you look at 

9.4  Processing of the extended Routing Header Type 2        in
http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-h
eader-05.txt

You'll find that the constraint of teh next hop being in a same node is
replaced by 
           
		/* new security check */
            if Address [i] doesn't belong to one of the Mobile Network
prefixes {
                discard the packet
                return
            }

Pascal