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

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 27 Oct 2004 16:37:07 -0700

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.

Vijay

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Brian Haley <[email-masked]>
Date: Thu, 28 Oct 2004 11:23:07 -0400

>>>  - fail (drop the packet or crash)

I know I purposefully did 1) to not have nesting problems, it's just been a 
while since I played with that code to remember more.

>> create a circular reference, but it is unlikely.

But how can this happen?  If I'm a MN at COA1, would I ever send a BU to anyone 
to say COA1 is now at COA2?  I would think you'd just update the existing 
binding to point at COA2.

In the draft-thubert-nemo-reverse-routing-header-05.txt case, the HA would 
construct a multi-hop routing header, then send it to the first hop.

What am I missing?

> in the routing header, but still satisfy the security requiements

I guess I don't agree 100% with this since RH2 was supposed to be a special case 
to hold the HoA.  Extending it to have more than that seems to turn it into a 
glorified RH0 with MRs in it, but that's my opinion...

-Brian

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 28 Oct 2004 11:15:15 -0700

Brian Haley wrote:

> But how can this happen?  If I'm a MN at COA1, would I ever send a BU to 
> anyone to say COA1 is now at COA2?  I would think you'd just update the 
> existing binding to point at COA2.
> 
> In the draft-thubert-nemo-reverse-routing-header-05.txt case, the HA 
> would construct a multi-hop routing header, then send it to the first hop.
> 
> What am I missing?

The Nemo context where this was discussed.

There might be a MR which will help a MNN by sending BUs on its behalf
and the MNN might be a MIPv6 MN doing its own BUs.
The MR only "sees" what the MNN has as its CoA so we end up with the MR 
creating a binding in the CN from CoA(MN) -> CoA(MR) and the MN creating 
a binding in the same CN from HoA(MN) -> CoA(MN).

My question was whether RFC 3775 defined what would happen if this was 
done; for instance if it specified to ignore the second binding.
Seems like it does not.

   Erik