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

From: Gerardo Giaretta <[email-masked]>
Date: Fri, 02 Dec 2005 19:03:23 +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].

--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
====================================================================

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 02 Dec 2005 17:35:39 -0800

> 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.

Vijay