Subject: Re: [Mipshop] figuring out P, I and V bits

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Nov 2003 09:04:03 -0800

If the MN wants to communicate with its AR, it can also use its LL address
as the source address.

            jak

----- Original Message ----- 
From: "gabriel montenegro" <[email-masked]>
To: "Soliman Hesham" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, November 24, 2003 7:03 AM
Subject: [Mipshop] figuring out P, I and V bits

>
> Hesham said:
> > => 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
>
> One could use the LCoA directly with the AR, or install a
> MN@LCoA binding at the AR using RO via the HA.
>
> > 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.
>
> 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.
>
> >  > > 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.
> ...
>
> At most, this seems to be a binary decision (one bit, not three).
>
> >  > >  > 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.
>
> 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
>
>
>
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
>

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