Subject: RE: [Mipshop] Last Call Comments on draft-ietf-mishop-hmipv6-00.t xt

From: Soliman Hesham <[email-masked]>
Date: Wed, 19 Nov 2003 04:59:29 -0500

> > => It's always the case that we use reverse tunnelling, 
 > > the I flag is there to tell the MN that it can do that. 
 > 
 > Actually, the I flag only indicates that the RCoA may be used
 > as a source address.  It doesn't indicate reverse tunneling at all.

=> Right. 

 > "Since RCoA is used as a source address for outgoing packets, the
 >     mobile node must consider the content of the P, I and V flags to
 >     decide whether packets should be sent directly with RCoA 
 > as a source,
 >     or tunnel packets to the MAP. When tunnelling outgoing 
 > packets to the
 >     MAP, the source address in the outer header is the 
 > mobile nodeËs LCoA
 >     and the destination address is the MAPs address. "
 > 
 > 
 > What the actual intention is and what the specification
 > is seem to be out-of-sync.
 > Certainly, it's not necessary to have all three of I, P and V.
 > 
 > V=1 is assumed as default.
 > 
 > P and I seem to be way of indicating alternatives to reverse
 > tunneling (but I'm not sure why any more).

=> They were used to distinguish the case where the operator
says that the MN MUST use RCoA Vs MAY use RCoA. And yes, 
they can all be removed and only one way can be assumed.
But this would mean that if the MN wants to communicate
with its default router (which happens to have an app)
then it has to reverse tunnel to the MAP. This is why 
I was saying that the only thing is to decide whether
this is an important case (together with eliminating 
the tunnel on the uplink) or we don't care about that.

 > > However, I think it's useful to have a flag that
 > > tells the MN that location privacy is available through
 > > reverse tunnelling or directly sending packets with RCoA
 > > as a src. 
 > 
 > Isn't location privacy always available (through reverse tunneling)?

=> I don't know what every operator wants to do.
I would hope that this is the norm.

 > >  > At least until the BU to the new MAP occurs (and return
 > >  > routability tests to CNs have completed) it's valuable
 > >  > to maintain both connections to MAPs.
 > > 
 > > => This is possible, operators just have to configure
 > > their routers accordingly.
 > 
 > The issue is that a MAP may only be applicable to one operator,
 > and using the MAP during handover to another operator's MAP
 > will lose packets (since the new operator will drop packets
 > with the old RCoA as a source address).

=> Inter-operator handover is just not possible today
in any system. So I would assume that the norm is that
operators will not forward to the MN in a new operator's
network. Packet loss is certainly expected in this case.

Hesham

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

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 24 Nov 2003 16:03:23 +0100

> then it has to reverse tunnel to the MAP. This is why

One could use the LCoA directly with the AR, or install a
MN@LCoA binding at the AR using RO via the HA.

> the tunnel on the uplink) or we don't care about that.

I've voted before, but basically, I'd rather simplify the protocol
and get rid of these by assuming reverse tunneling to the MAP
using the RCoA.

>  > > reverse tunnelling or directly sending packets with RCoA
...

At most, this seems to be a binary decision (one bit, not three).

> network. Packet loss is certainly expected in this case.

Let's not consider inter-operator handover, just like we haven't
considered it for MIPv6 basic. Basically, this implies that ingress
filtering is not homogeneously applied thoughout an installation, contrary
to IETF recommendation. I'd rather not go there.

My question is: if we assume ingress filtering is always one (as I believe
we should), then which bits (if any) are needed?

-gabriel

---

From: "James Kempf" <[email-masked]>
Date: Tue, 25 Nov 2003 15:37:58 -0800

Agree.

            jak

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "gabriel montenegro" <[email-masked]>; "Soliman Hesham"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, November 25, 2003 3:10 PM
Subject: Re: [Mipshop] figuring out P, I and V bits

> Hi James,
>
> James Kempf wrote:
> > If the MN wants to communicate with its AR, it can also use its LL
address
> > as the source address.
>
> I think there's some resistance to source address
> selection using LL for general applications.
>
> In this case, we may as well use a global and no
> MIPv6, since it's as effective for (very) short
> communications exchanges.
>
> Let's not (over) specify these sort of details though,
> unless it's necessary.  It's sufficient to have the
> reverse tunneling when using HMIPv6.  It's not
> strictly necessary to use HMIPv6 within the domain,
> for non MIPv6 communication, is it?
>
> Is this what we're trying to work out?
>
> Greg
>
>