Re: [MEXT] Home Link Detection [Fwd: I-DAction:draft-krishnan-mext-hld-01.txt]

["George Tsirtsis" <[e-mail]>]

Hi Jouni,

I think your comments as well as comments from Julien and others
correctly suggest that the way address allocation is performed on a
link does not matter. So the draft should not assume anything. This
essentially means that the first 4 bullets of section 4:

"   o  The MN sends out a Router Solicitation
   o  The MN receives a Router Advertisement in response with one or
      more Prefix Information Options as specified in [RFC4861].
   o  The MN autoconfigures an address from one of the received prefixes
      that have the autonomous address configuration flag set.  This
      address is referred to as the Current MN Address (CMA)
   o  The MN stores all the prefix(es) received along with their prefix
      lengths in the RA in a conceptual list called the Current Link
      Prefix List (CLPL)"

...should be replaced with one bullet that says something like "the MN
learns the on-link prefixes and configures an address according to
mechanisms available on the link-type it is connected to."

Suresh can also add an arbitrary number of acronyms to make it sound
more importnant :-)

Regards
George

On Wed, Apr 2, 2008 at 11:25 PM,  <[e-mail]> wrote:
> Suresh, Julien,
>
>  The MN might also configure the IPv6 address the MIP6 client
>  sees using e.g. IKEv2 (in a case of a remote VPN access and
>  assuming MIP6 is run on top of this VPN tunnel, which is
>  possible). In that case the CMA is learned via IKEv2 signaling,
>  and the CLPL is updated accordingly based on  the configured
>  IPv6 address and its prefix (e.g. from the IKEv2 INTERNAL_IP6_ADDRESS
>  payload).
>
>  IMHO, it might be better not to define the MN operation on
>  how CMA and CLPL get populated. Just assume they exist
>  somehow. The last 5 bullets in section 4 are fine with
>  Julien's changes.
>
>  What do you think?
>
>  Cheers,
>         Jouni
>
>
>
>  > -----Original Message-----
>  > From: [e-mail] [mailto:[e-mail]] On
>  > Behalf Of Julien Laganier
>  > Sent: 1. huhtikuuta 2008 12:52
>  > To: [e-mail]
>  > Subject: Re: [MEXT] Home Link Detection [Fwd:
>  > I-DAction:draft-krishnan-mext-hld-01.txt]
>  >
>  >
>  > Hi Suresh,
>  >
>  > Two comments:
>  >
>  > - The draft seems to assume that SLAAC is used by the MN.
>  > However that
>  > is not needed per se, DHCP could be used to configure the
>  > MN's address.
>  > The only requirement is that the MN obtain one or more PIOs, how the
>  > MN's address is configured is irrelevant. Thus, I think you should
>  > reword as:
>  >
>  > 4.  Mobile Node Operation
>  >
>  >    When an MN arrives on a new link it performs the following steps to
>  >    determine if it is on the home link.
>  >    o  The MN sends out a Router Solicitation
>  >    o  The MN receives a Router Advertisement in response with one or
>  >       more Prefix Information Options as specified in [RFC4861].
>  >    o  The MN configures one or more addresses, referred to as the
>  >       Current MN Addresses (CMA), via DHCPv6 if the"Managed address
>  >       configuration" (M) flag is set in the Router
>  > Solicitation, or via
>  >       SLAAC if one or more of the received prefixes has the
>  > "autonomous
>  >       address configuration" (A) flag set.
>  >    o  The MN stores all the prefix(es) received along with
>  > their prefix
>  >       lengths in the RA in a conceptual list called the Current Link
>  >       Prefix List (CLPL)
>  >    o  The MN uses one of the addresses in the CMA to initiate the
>  >       bootstrapping procedure described in [RFC5026].  The MN MUST
>  >       include the MIP6_HOME_PREFIX attribute in the
>  > CFG_REQUEST message.
>  >    o  The MN receives the home prefix and the corresponding prefix
>  >       length from the HA contained in the MIP6_HOME_PREFIX
>  > attribute in
>  >       the CFG_REPLY message.  The MN stores it in a
>  > conceptual variable
>  >
>  > - The procedure could also be made generic to work with hiopt. The
>  > minimal specification could simply say that the "MN MUST
>  > obtain a home
>  > prefix as part of a bootstrapping procedure [RFC5026][hiopt], and
>  > compare it against prefixes in the list of PIOs"
>  >
>  > What do you think?
>  >
>  > --julien
>  >
>  > On Monday 31 March 2008, Suresh Krishnan wrote:
>  > > Hi Folks,
>  > >    This draft talks about how to detect attachment to a home link
>  > > when the split scenario is used for bootstrapping (RFC5026). Please
>  > > take some time to review it.
>  > >
>  > > Thanks
>  > > Suresh
>  > >
>  > > -------- Original Message --------
>  > > Subject: I-D Action:draft-krishnan-mext-hld-01.txt
>  > > Date: Mon, 31 Mar 2008 08:00:01 -0700 (PDT)
>  > > From: [e-mail]
>  > > Reply-To: [e-mail]
>  > > To: [e-mail]
>  > >
>  > > A New Internet-Draft is available from the on-line Internet-Drafts
>  > > directories.
>  > >
>  > >     Title           : MIPv6 Home Link Detection
>  > >     Author(s)       : S. Krishnan, G. Tsirtsis
>  > >     Filename        : draft-krishnan-mext-hld-01.txt
>  > >     Pages           : 6
>  > >     Date            : 2008-03-31
>  > >
>  > > The MIPv6 bootstrapping procedure allows the mobile node to
>  > > dynamically discover its home prefix using an IKEv2 exchange.  Since
>  > > the home prefix is not statically configured on the mobile node,
>  > > there is a need to specify a mechanism for the mobile node to detect
>  > > if it is on its home link.  This document specifies one such
>  > > mechanism.
>  > >
>  > > A URL for this Internet-Draft is:
>  > > http://www.ietf.org/internet-drafts/draft-krishnan-mext-hld-01.txt
>  > >
>  > > Internet-Drafts are also available by anonymous FTP at:
>  > > ftp://ftp.ietf.org/internet-drafts/
>  > >
>  > > Below is the data which will enable a MIME compliant mail reader
>  > > implementation to automatically retrieve the ASCII version of the
>  > > Internet-Draft.
>  > >
>  > > _______________________________________________
>  > > MEXT mailing list
>  > > [e-mail]
>  > > https://www.ietf.org/mailman/listinfo/mext
>  >
>  >
>  > _______________________________________________
>  > MEXT mailing list
>  > [e-mail]
>  > https://www.ietf.org/mailman/listinfo/mext
>  >
>  _______________________________________________
>  MEXT mailing list
>  [e-mail]
>  https://www.ietf.org/mailman/listinfo/mext
>
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext