Subject: RE: [Mip6] Comments on draft-ietf-mip6-bootstrapping-split-01.txt

From: Gerardo Giaretta <[email-masked]>
Date: Mon, 05 Dec 2005 18:17:20 +0100

> >  > > I agree, a lifetime is needed. The following is the prefix 
> > 
> >>information
> >>
> >>>option in rfc2461bis. I think we need valid and preferred 
> >>
> >>lifetimes too.
> >>
> >>>What do you think?
> >>
> >>its an overkill. since preferred lifetime is always
> >>less than valid lifetime, maybe we should just send
> >>the preferred lifetime. (?)
> >>
> > 
> > 
> > you may be right that it is not needed. However, I think it 
> is a cleaner
> > approach if we send the information as in a Router 
> Advertisement. This
> > would imply that the MN will have preferred and valid 
> lifetimes for the
> > HoA as for all other addresses configured based on [ADDRCONF].
> 
> we dont have to send everything thats there in a router
> advertisement through IKEv2 attributes. the mobile node
> can always run Mobile Prefix Discovery later on to find
> out the complete information about the home prefix.
> FWIW, Mobile Prefix Discovery was designed so that it
> can be a substitute for router advertisements when the
> mobile node is not at home.
> 

But why the MN should run MPD to know the valid lifetime of a prefix it
has already configured?
I was thinking that MPD would be used to discover new prefixes, not the
prefix discovered via IKEv2.

--Gerardo

> Vijay
> 
> > 
> > --Gerardo
> > 
> > 
> >>RFC 2461 says
> >>
> >>  Preferred Lifetime
> >>                      32-bit unsigned integer.  The length 
> of time in
> >>                      seconds (relative to the time the 
> >>packet is sent)
> >>                      that addresses generated from the prefix via
> >>                      stateless address autoconfiguration remain
> >>                      preferred [ADDRCONF].  A value of all one bits
> >>                      (0xffffffff) represents infinity.  See 
> >>[ADDRCONF].
> >>
> >>it might be sufficient to just send the preferred
> >>lifetime.
> >>
> >>Vijay
> >>
> >>
> >>>       0                   1                   2           
>         3
> >>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
> >>
> >>6 7 8 9 0 1
> >>
> >>>      
> >>
> >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>
> >>>      |     Type      |    Length     | Prefix Length |L|A| 
> >>
> >>Reserved1 |
> >>
> >>>      
> >>
> >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>
> >>>      |                         Valid Lifetime              
> >>
> >>          |
> >>
> >>>      
> >>
> >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>
> >>>      |                       Preferred Lifetime            
> >>
> >>          |
> >>
> >>>      
> >>
> >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>
> >>>      |                           Reserved2                 
> >>
> >>          |
> >>
> >>>      
> >>
> >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>
> >>>      |                                                     
> >>
> >>          |
> >>
> >>>      +                                                     
> >>
> >>          +
> >>
> >>>      |                                                     
> >>
> >>          |
> >>
> >>>      +                            Prefix                   
> >>
> >>          +
> >>
> >>>      |                                                     
> >>
> >>          |
> >>
> >>>      +                                                     
> >>
> >>          +
> >>
> >>>      |                                                     
> >>
> >>          |
> >>
> >>>      
> >>
> >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>
> >>>
> >>>--Gerardo
> >>> 
> >>>
> >>>
> >>>>>- Regarding DDNS updates, I share some of Francis concerns, 
> >>>>
> >>>>but I also
> >>>>
> >>>>
> >>>>>share the concerns of the DT stated in section 9.5.
> >>>>>(authentication/authorization of updates and 
> >>>>
> >>>>redirection-based flooding
> >>>>
> >>>>
> >>>>>issue, if MN updates DNS). IMHO some more 
> >>>>
> >>>>thoughts/discussions should be
> >>>>
> >>>>
> >>>>>spent on this issue. For instance, something like a cookie-based
> >>>>>reachability test (done by DNS server) of the address 
> >>>>
> >>>>claimed by MN in
> >>>>
> >>>>
> >>>>>the DNS update could be considered to address the 
> redirection-based
> >>>>>flooding attack concern. 
> >>>>
> >>>>agree. but I think modifications to DNS are beyond
> >>>>the scope of MIP6 bootstrapping work.
> >>>>
> >>>>Vijay
> >>>>
> >>>>
> >>>>_______________________________________________
> >>>>Mip6 mailing list
> >>>>[email-masked]
> >>>>https://www1.ietf.org/mailman/listinfo/mip6
> >>>>
> >>>
> >>>
> >>>
> >>>Gruppo Telecom Italia - Direzione e coordinamento di 
> >>
> >>Telecom Italia S.p.A.
> >>
> >>>===========================================================
> =========
> >>>CONFIDENTIALITY NOTICE
> >>>This message and its attachments are addressed solely to 
> the persons
> >>>above and may contain confidential information. If you 
> have received
> >>>the message in error, be informed that any use of the 
> content hereof
> >>>is prohibited. Please return it immediately to the sender 
> and delete
> >>>the message. Should you have any questions, please send an 
> e_mail to
> >>>[email-masked]. Thank you
> >>>===========================================================
> =========
> >>
> >>
> >>
> > 
> > 
> > Gruppo Telecom Italia - Direzione e coordinamento di 
> Telecom Italia S.p.A.
> > 
> > ====================================================================
> > CONFIDENTIALITY NOTICE
> > This message and its attachments are addressed solely to the persons
> > above and may contain confidential information. If you have received
> > the message in error, be informed that any use of the content hereof
> > is prohibited. Please return it immediately to the sender and delete
> > the message. Should you have any questions, please send an e_mail to
> > [email-masked]. Thank you
> > ====================================================================
> 
> 
> 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Dec 2005 11:52:18 -0800

> prefix discovered via IKEv2.

because we dont to replicate everything that is there in
the router advertisements through IKEv2 messages. :)

instead lets use MPD to get complete prefix information
once you have setup security associations with the HA.
this includes prefixes that you already know about. for
example MPD even replicates the various flags (M, O flags).

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Mon, 05 Dec 2005 22:27:15 +0100

In your previous mail you wrote:

=> it was what I believed (so I thought MPD was very secondary) but it
seems that in fact MPD is a full replacement for RA, so MPD is
the right place to deal with prefix lifetimes...

Regards

[email-masked]