Subject: RE: [Mipshop] Possible Solution to Duplicate Problem?

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 26 Aug 2005 13:43:01 -0400

> >=> How do you know that?? FMIP can easily require MNs to do whatever
 > >deemed necessary, provided that the attack above is significant.
 > >Please read the Node requirements doc, where it is clear that
 > >the default is stateless address config.
 > 
 > So how is an FMIP router going to ensure that an MN uses 
 > CGAs or 3041 
 > addresses? 

=> It doesn't. If this is a concern FMIP should recommend
the use of those addresses. If the MN doesn't comply, then 
it is potentially hurting itself (if this attack is a concern). 

Hesham

As you say, the Node requirements document 
 > defaults to stateless 
 > address configuration, which means that the node is in 
 > control of how the 
 > address is generated.
 > 
 >             jak 
 > 
 > 
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

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

---

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Mon, 29 Aug 2005 14:23:14 -0500

James, 
Yes, you are right. It can't be worse than standard MIP. I don't know what I was thinking when I wrote that :) 

Regards,
Vidya

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]] 
> Sent: Monday, August 29, 2005 12:22 PM
> To: Narayanan Vidya-CVN065; 'Theodoros Pagtzis'
> Cc: Soliman, Hesham; mipshop; Rajeev Koodli
> Subject: Re: [Mipshop] Possible Solution to Duplicate Problem?
> 
> 
> Vidya,
> 
> Stateful configuration can't possibly be slower than MIP,  
> because the MN 
> has to have an nCoA before it can do the BU to the HA and 
> correspondent 
> nodes.
> 
> But it could be substantially slower than stateless 
> autoconfiguration, 
> especially if the MN must send a DHCP CONFIRM for movement 
> detection to 
> check whether the old address is still valid after the 
> handover, which the 
> DHCPv6 spec currently requires.
> 
>         jak
> 
> ----- Original Message ----- 
> From: "Narayanan Vidya-CVN065" <[email-masked]>
> To: "'Theodoros Pagtzis'" <[email-masked]>
> Cc: "James Kempf" <[email-masked]>; "Soliman, Hesham" 
> <[email-masked]>; "mipshop" <[email-masked]>; 
> "Rajeev Koodli" 
> <[email-masked]>
> Sent: Saturday, August 27, 2005 9:19 AM
> Subject: RE: [Mipshop] Possible Solution to Duplicate Problem?
> 
> 
> > Hi Theo,
> > I do agree that reactive handovers with stateful CoA 
> configuration is
> > likely to be too slow - I won't be surprised if that is 
> actually slower 
> > than MIP, as you say. In the case of reactive handovers, 
> only stateless 
> > autoconfig seems to make sense to me. Even in the IPv4 
> world, post-MIT 
> > like approaches worked well when there were FA CoAs. With 
> CCoAs, the DHCP 
> > delays were ugly.
> >
> > The DHCP latency can surely be improved - but that is more 
> complex and
> > probably work that needs to occur separately.
> >
> > Vidya
> >
> >> -----Original Message-----
> >> From: Theodoros Pagtzis [mailto:[email-masked]]
> >> Sent: Saturday, August 27, 2005 5:24 AM
> >> To: Narayanan Vidya-CVN065
> >> Cc: James Kempf; Soliman, Hesham; mipshop; Rajeev Koodli
> >> Subject: Re: [Mipshop] Possible Solution to Duplicate Problem?
> >>
> >>
> >> Hi Vidya,
> >>
> >> Narayanan Vidya-CVN065 wrote:
> >> > My apologies for jumping in the discussion. The scenario under 
> >> > discussion here, with multiple AR-AR pairs present is a 
> case where 
> >> > unambiguous L2 triggers are not available (otherwise, 
> the MN would 
> >> > exactly know where it is about to handoff). Isn't the
> >> reactive handoff
> >> > case meant to handle such cases?
> >>
> >> Well maybe if you consider that you set up the WRONG 
> PCoA/NCoA tunnel 
> >> so your packet forwarding went south. There you will unavoidably
> >> have to do
> >> the whole thing reactively. But what is the reactive case? A
> >> MIPv6 case
> >> with late forwarding (to save ourselved from the BU latency) and
> >> stateful (i.e. DHCP of some funky fast sort - not the one we have
> >> currently). Since the DHCP is pretty slow currently I am yet to be
> >> convinced that currently FMIPv6 reactive will not yield a
> >> handoff that
> >> is in fact SLOWER than the plain MIPv6 one. Basically on 
> the reactive
> >> FMIPv6 handoff, we are going to have to focus ONLY on the
> >> DHCP latency
> >> optimisation. I have currently a number of doubts whether 
> DHCP can be
> >> optimised for this purpose successfully (and realistically).
> >>
> >>
> >> Also IF FMIPv6 MUST have FAST DHCPv6 to do a reactive 
> handoff it is 
> >> NOT anymore FMIPV6 BUT  FMIPv6+FAST DHCPv6. Remember when
> >> comparing MIPv6 we
> >> are comparing it MIPv6 vanilla, not MIPv6+CARD+FAST
> >> DHCPv6+the kitchen
> >> sink.. And this is the killer winner of MIPv6 which we 
> have to work 
> >> against while reducing SIGNIFICANTLY latency (if we want 
> to produce a 
> >> spec that does make a difference). Basically what I am 
> saying here is 
> >> that we also have to value the complexity of the protocol 
> too against 
> >> the latency performance optimisation instead of digging 
> cases which 
> >> will add more protos and make the FMIPv6 operation as big 
> as the IPv6 
> >> spec SUITE!!!
> >>
> >> Divide and conquer is good but the division is going to give us a 
> >> serious management problem..
> >>
> >>
> >> t.
> >>
> >> --
> >> theo
> >> Nets & Mobile Systems Group
> >> UCL-CS
> >>
> > 
> 
>