Subject: RE: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 5 Feb 2002 11:14:54 +0100

Hi Erik

Sorry, I'm a bit behind on email.
  > 
  > I understand that this is a bit speculative but 
  > I'm trying to understand the details of the tradeoffs ...
  > 
  > Do you think the other two possible encodings (destination option 
  > or a different extension header altogether) would not allow
  > this behavior in the receiver?

=> I can say that the destination option would
not allow this behaviour because by definition
it will only be processed by the ultimate
receiver of the packet. As for another header
altogether, I think it depends on whether it 
can be processed by the Mobile router or not
(i.e. before it gets to the end host). 

I think it's important to explain my assumptions
here. The solution I'm referring to assumes that
the network behind the MR does not get 
renumbered. Only the MR's interface (facing 
the default (fixed) router) is renumbered. 
Essentially the MR acts as an FA by letting 
MNs use its address as a CoA. The reason 
I'm making this assumption is that I wanted 
to achieve fast mobility and assumed that 
renumbering the entire network would be 
too slow (*). 

  > It seems to me that at least a different extension header would have
  > close to identical properties to IPv6_NO_SRC.

=> Sure, but only if the can be processed by the MR. 
IP in IP would work provided that the outer dst 
address is the MR's address (MN's CoA).

Hesham

PS: FWIW I think IP in IP is the cleanest
way to solve this, it's been used and well
understood. But I understand that
people want to finish the spec and this 
might sound too revolutionary. 

(*) This is the approach we took in HMIPv6.
I do not claim that this is the best way
to do it. I was just explaining why it was
done. If MONET becomes a WG we might have
hbetter approaches.

---

From: "Glenn Morrow"<[email-masked]>
Date: Wed, 6 Feb 2002 16:14:03 -0600

Jari,

I am very relieved to hear that you agree that the overhead is a waste. I
hope others can see this as well and we can find an acceptable way to get
rid of the overhead as a team for MIPv6. Getting people to realize this was
the intent of the ID. 

The draft was trying to emulate existing precedent IDs related to tunneling
that did not specify such signaling specifics. These precedent IDs also gave
rough topolical deployment examples. This was the reason for the generalized
mode and the avoidance of signaling specific scope. I do see that there have
been other IDs that say "use this generic tunneling mechanisms with this
signaling" but we had to have the reference to the generic method 1st. 

If the WG can agree that the overhead is a waste and pick one of the end to
end alternatives:

- ZOD
    (relies solely on end to end fate sharing principle)
    (not as robust as overhead-based methods)

- More Robust ZOD  (as robust as the overhead-based methods)
   - flow label bit
   - traffic class bit
   If one of these are chosen we just need to pick one of the bits.

Then I will certainly volunteer to write a more formal and exact ID that is
MIPv6 signaling specific; though, I think that Charlie would probably do a
better job of just incorporating the change into the existing MIPv6 spec and
we can just let the existing ZOD ID expire. It will have served its purpose
at that point. The reasoning can be captured in the MIPv6 spec, itself, for
prosperity's sake. I also wouldn't mind if someone else wanted to author a
more specific ID.

If not, then I do not see much use in going through the effort of another
ID. There are other issues that need attention, too. I think I have
contributed enough on this topic and in sufficient detail to convey the
information at this time.

Thanks again,

Glenn

---

From: Francis Dupont <[email-masked]>
Date: Wed, 30 Jan 2002 12:08:55 +0100

=> not exactly, RH is said to need a careful usage so MIPv6 use and
other uses interfere in careful usage requirements (i.e. if we fix it
for MIPv6 we impede other uses).

   2. after, one idea to replace RH functionality is to create a new DO [Why
   not ...]

=> there are 4 propositions, one is a new DO.

   3. and now, it is proposed to place this new DO between the fragment header
   and the ... RH [!?!]
   
=> there is an issue about the position of the DO header with the DO...
This shows a new RH type is a good alternative to a new DO.

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 30 Jan 2002 11:01:21 +0100

=> I agree but this means there is no difference from the IPsec
point of view between a new DO and a new RH type (i.e. this
withdraws a possible argument in favour of a new DO).

Regards