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

From: <[email-masked]>
Date: Thu, 3 Apr 2008 00:25:18 +0200

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: 1. huhtikuuta 2008 12:52
> To: [email-masked]
> 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: [email-masked]
> > Reply-To: [email-masked]
> > To: [email-masked]
> >
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mext
> 
> 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
> 
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 3 Apr 2008 09:28:15 +0100

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