Subject: RE: [Mip6] Recommendation for bootstrapping using DHCPv6

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 3 Aug 2006 21:19:30 -0700

Junghoon,

been through that endless loop. I will pass. :)

Vijay 

> -----Original Message-----
> From: Junghoon Jee [mailto:[email-masked]] 
> Sent: Thursday, August 03, 2006 6:05 PM
> To: 'Alper Yegin'; 'Basavaraj Patil'; [email-masked]
> Subject: RE: [Mip6] Recommendation for bootstrapping using DHCPv6
> 
> Feeling hard to intervene...
> However having looked at this issue over very long time again and
> again,
> eventually I spent sometime looking at this issue again and decided to
> share my thought at this time.
> 
> Disclaimer: I don't have so strong opinion on this issue, just to
> share my thought to try to resolve still unsolved issue.
> 
> > - The integrated bootstrapping solution depends on a number 
> > of protocol design work (1. DHCP options for HA discovery, 2. 
> > RADIUS attributes for HA discovery, 3. Diameter AVPs for HA 
> > discovery, 4. IKEv2 for HoA configuration, 5. RADIUS 
> > attributes for MIP6 authentication, 6. Diameter AVPs for MIP6 
> > authentication) and description (7) of how all such protocols 
> > plumb together to yield so-called "MIP6 bootstrapping." 
> > 
> > Now, item 7 is described in
> > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. All the 
> > others are currently described in separate documents, and 
> > that makes sense. Asking for
> > 1 and 7 be merged does not make sense. If it did, my 
> > questions was, why not merge the others as well. Do you see my
> point?
> 
> I also think above statements are reasonable. 
> BTW, it is true that some concerns arise from the behaviors in the
> draft-jang maybe throught the section 4.2.
> 
> Here is the section 4.2 for draft-jang.
> --------------------------------------------------
> 4.2.  Mobile Node Considerations
> 
>    When a Mobile IPv6 Mobile Node finds itself with neither a home
>    subnet prefix nor a home agent address, it may request the needed
>    information with Option Request option.  For instance, a mobile
> node
>    connecting to a network for the first time may acquire a DHCP
> address
>    and solicit for home network information at the same time.
> 
>    A mobile node MUST identify the desired information with Home
> Network
>    Identifier option.  For example, a DHCP server may have information
>    about home agents from several domains (and subnets).  It relies on
>    the mobile node to select the domain for determining which ones it
>    should provide in response to the client's request.
> 
>    When the mobile node gets more than one home agent address, it MUST
>    have a selection mechanism to determine which one to use for
>    establishing a Mobile IPv6 session.  In case it retrieves only home
>    subnet prefix(es), it needs to perform dynamic home agent discovery
>    to learn the IP addresses of the home agents.  Similarly, if FQDN
> of
>    a home agent is retrieved, the mobile node can use DNS to resolve
> it
>    to IPv6 address(es).
> ----------------------------------------------------------------
> 
> Vijay, could you pin-point out what specific texts are not comfortable
> based on the protocol behavior from the
> draft-ietf-mip6-bootstrapping-integrated-dhc-01?
> 
> Junghoon 
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

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

---

From: "Upadhyaya Saumya-a20369" <[email-masked]>
Date: Fri, 4 Aug 2006 21:28:21 +0800

Hi Alper,

With regard to the Diameter interface to obtain MIP6 bootstrapping
parameters, we have an individual draft 
(http://www.ietf.org/internet-drafts/draft-ram-dhc-dhcpv6-diam-app-00.tx
t) 
for the proposed interface between DHCP Server and AAA. This interface
could be used to get the mip6   
bootstrapping params from the AAA, although the primary purpose of this
draft 
is to authenticate the DHCPv6 service. 

Comments are solicited.

Regards,
Saumya

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Thursday, August 03, 2006 3:15 AM
To: 'Basavaraj Patil'; [email-masked]
Subject: RE: [Mip6] Recommendation for bootstrapping using DHCPv6

Hi Raj,

"Having the options specified in a stand-along document will not add
much value."

As we have been stating, draft-jang-mip6-hiopt-00.txt also has a use
that does not tie into the RADIUS-driven details -- the use where DHCP
server can be manually configured and has nothing to do with the AAA. 

Your above statement misses this point. 

Besides, while there is a standalone use for
draft-jang-mip6-hiopt-00.txt, there is none for the RADIUS and Diameter
specs we expect to document individually. Should we also merge those AAA
documents with the others?

Also, I'm not sure what specific concern you are raising with respect to
the quoted text below.

Alper

> From: Basavaraj Patil [mailto:[email-masked]]
> Sent: Tuesday, August 01, 2006 12:35 PM
> To: [email-masked]
> Subject: [Mip6] Recommendation for bootstrapping using DHCPv6
> 
> 
> Alper/Kuntal et al,
> 
> I have reviewed the drafts:
> 1. Problem Statement for bootstrapping Mobile IPv6
>    (draft-ietf-mip6-bootstrap-ps-05)
> 2. MIP6-bootstrapping via DHCPv6 for the Integrated Scenario
>    (draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt)
> 
> and
> 3. DHCP Option for Home Information Discovery in MIPv6
>    (draft-jang-mip6-hiopt-00.txt)
> 
> My conclusion from the review is that the integrated scenario 
> bootstrapping via DHCPv6 is covering the cases when DHCP is the 
> preferred method by MNs.
> 
> The WG I-D draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt in 
> sections 3.5 and 3.8 explain how DHCP would work. Having the options 
> specified in a stand-along document will not add much value. I am also

> concerned about the fact in draft-jang which states that: "
>    The availability of the requested information depends on the DHCP
>    server having prior knowledge or dynamically discovering it.  While
>    the specific details are outside the scope of this document, use of
>    static tables and AAA-assisted discovery are possible options "
> 
> Another concern that I have w.r.t bootstrapping with DHCPv6 is that 
> instead of having DHCP provide the HoA or the HL prefix to the MS, it 
> is better to only provide the address of an HA (or list of HAs) and 
> let the MS send a BU with unspecified address and obtain an address 
> from the HA. This will simplify bootstrapping and also reduce the 
> interaction between DHCP and the HA from an address management 
> perspective. Hence you may want to reconsider the DHCP option which 
> carry the HL Prefix or the HoA for the MS.
> 
> I recommend that the DHCP option specified in draft-jang be 
> incorporated into the WG I-D and progressed on standards track. As a 
> result the WG will have a mechanism for bootstrapping MIP6 with DHCP 
> that also includes the DHCP options in a single I-D.
> 
> -Raj
> 
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 4 Aug 2006 08:08:42 -0700

Hi Saumya,

the work on this is being done in the DIME WG. take a look at 
http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-00.txt 
http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt

Vijay

> From: Upadhyaya Saumya-a20369 [mailto:[email-masked]] 
> Sent: Friday, August 04, 2006 6:28 AM
> To: [email-masked]
> Subject: Re: [Mip6] Recommendation for bootstrapping using DHCPv6
> 
>  
> Hi Alper,
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 4 Aug 2006 23:12:12 -0700

Hi Hesham,

AAA extensions were needed for the split scenario and
integrated scenario. some are common. There are some 
common AVPs/attributes for NAS-AAA and HA-AAAH 
interfaces. also the AAA extensions can be used with 
RFC 4285, not just IKEv2/IPsec. from the beginning it 
was recognized that the expertise for the AAA 
extensions existed in the respective RADIUS and 
Diameter WGs. 

OTOH, defining new DHCP options can be done in any WG. 
we checked with Ralph. all was needed was just a review
from the DHC WG before the document was last called.

Vijay

> From: Soliman, Hesham [mailto:[email-masked]] 
> Sent: Friday, August 04, 2006 7:27 PM
> To: James Kempf; Alper Yegin; Basavaraj Patil; [email-masked]
> I agree with James that this should be done through 
> concensus. However,
> the other issue that I find puzzling is the inconsistency of 
> adding the
> DHCP option formats in this document, while expecting the
> Diameter/RADIUS AVPs/VSA to be done "somewhere else". Why is it ok for
> AAA stuff to be done somewhere else and not DHCP?
> 
> Hesham 
> 
>  > From: James Kempf [mailto:[email-masked]] 
>  > Sent: Saturday, August 05, 2006 7:27 AM
>  > To: Alper Yegin; 'Basavaraj Patil'; [email-masked]
>  > Um, you know, we've been discussing this topic now for over 
>  > a month. How 
>  > about we do a consensus call and see what the WG wants to do 
>  > with it? The 
>  > document is, after all, a WG document and therefore the 
>  > content is subject 
>  > to WG consensus.
>  > 
>  >             jak
>  > 
>  > ----- Original Message ----- 
>  > From: "Alper Yegin" <[email-masked]>
>  > To: "'Basavaraj Patil'" <[email-masked]>; 
> <[email-masked]>
>  > Sent: Friday, August 04, 2006 1:05 PM
>  > > Raj,
>  > > Your message simply tells me how we can combine the 
>  > documents. It does not
>  > > say why this is a better idea than keeping them separate. 
>  > More inlined
>  > > below.
>  > >
>  > >> much
>  > >> >> > value."
>  > >> >> > As we have been stating, 
>  > draft-jang-mip6-hiopt-00.txt also has a use
>  > >> that
>  > >> >> > does not tie into the RADIUS-driven details -- the 
>  > use where DHCP
>  > >> server
>  > >> >> can
>  > >> >> > be manually configured and has nothing to do with the AAA.
>  > >> >>
>  > >> >> But why do you believe that the WG I-D which is using 
>  > DHCP is RADIUS
>  > >> driven
>  > >> >> only and nothing else?
>  > >> >
>  > >> >AAA is integral to the current solutions designed by the 
>  > MIP6 WG for 
>  > >> >MIP6
>  > >> >bootstrapping.
>  > >>
>  > >> BP: Yes. I think we agreed when this work began that the 
>  > MN shared a
>  > >> BP: security association with an entity such as the AAA 
>  > in the home
>  > >> BP: network and not the HA (which is what RFC3775 is 
>  > based on). But
>  > >> BP: I dont see how the fact that AAA is an integral part of the
>  > >> BP: bootstrapping solution has anything to do with DHCP options
>  > >
>  > > Well, I was merely responding to your statement. Maybe I 
>  > misunderstood 
>  > > what
>  > > you meant.
>  > >
>  > >
>  > >> other
>  > >> BP: than the fact that AAA messages are used to obtain 
> information
>  > >> BP: such as the address of the HA and insert them in a DHCP
>  > >> BP: server. But that should be dealt with in the Dime WG (I-D:
>  > >> BP: draft-ietf-dime-mip6-integrated-00.txt) and the same 
>  > with Radius
>  > >> BP: as specified in I-D: draft-chowdhury-mip6-radius-02.
>  > >>
>  > >> >
>  > >> >> I mean it could just as well be used for the case
>  > >> >> where the bootstrapping information is manually 
>  > configured in the DHCP
>  > >> >> server. What is needed are the DHCP options and the 
>  > fact that the
>  > >> >> bootstrap
>  > >> >> parameters are available in the DHCP server either as 
>  > a result of some
>  > >> AAA
>  > >> >> messages or manual configuration does not matter.
>  > >> >
>  > >> >Yes, this is exactly what the draft-jang is saying.
>  > >>
>  > >> BP: I know. And my point is that the WG I-D:
>  > >> BP: draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt 
>  > is also doing
>  > >> BP: the similar thing in section 3.5.
>  > >
>  > > No, it is not. WG I-D is describing the DHCP relay 
>  > options, not the DHCP
>  > > options. I think we should move those to the other 
>  > document as well.
>  > >
>  > >> What I am recommending is that
>  > >> BP: the options that the I-D: 
>  > draft-jang-mip6-hiopt-00.txt specifies
>  > >> BP: in section 3 be included in section 3.5 of the WG I-D 
>  > and be done.
>  > >> BP: If you look at the title of the WG I-D, it says
>  > >> BP: "MIP6-bootstrapping via DHCPv6..." which to me 
> implies that it
>  > >
>  > > It was our mistake to name the document like that. You know, the 
>  > > integrated
>  > > solution involves EAP, RADIUS, Diameter, DHCP, IKEv2, etc. 
>  > It is not fair 
>  > > to
>  > > name it after only one of the protocols involved. We shall 
>  > fix the name, 
>  > > not
>  > > try to fit the content of the I-D to the mistaken name.
>  > >
>  > >> BP: should specify how bootstrapping is done with DHCPv6 and the
>  > >> BP: options that would be needed in DHCP to make this 
> work. I know
>  > >> BP: you would argue that if that were to be the case 
> then the AAA
>  > >> BP: aspects should also incorporated into the same. If it 
>  > was a matter
>  > >> BP: of only specifiying a couple of new AAA AVPs that could be a
>  > >> BP: solution. However at the moment it appears that a more
>  > >> BP: comprehensive AAA spec for Radius and Diameter are 
>  > needed as seen
>  > >> BP: from the AAA I-Ds mentioned above.
>  > >
>  > > This just tells me the amount of text for DHCP options is 
>  > less than the
>  > > amount of text for AAA, hence the former should be merged 
>  > and not the
>  > > latter. I think we should be more concerned about the 
>  > modularity of our
>  > > specifications.
>  > >
>  > draft-jang-mip6-hiopt-
>  > >> >> 00.txt,
>  > >> >> What is the standalone use of draft-jang?
>  > >> >
>  > >> >Standalone use is the one that does not require all that 
>  > AAA plumbing.
>  > >> For
>  > >> >example, when you manually configure the DHCP servers 
>  > with the MIP6
>  > >> >information.
>  > >>
>  > >> BP: If you were to manually configure the DHCP server with the
>  > >> BP: bootstrapping information, you could only bootstrap 
>  > an MS when it
>  > >> BP: is in its home network.
>  > >
>  > > Simply not true. You know DHCP runs across multiple IP 
>  > hops, with the help
>  > > of DHCP relays. A MN may very well be connected to a 
>  > foreign subnet and 
>  > > get
>  > > its configuration from a DHCP server in its home subnet.
>  > >
>  > >> But the manual configuration of the DHCP
>  > >> BP: server scenario is not ruled out by incorporating 
>  > these options in
>  > >> BP: the WG I-D either. So I disagree that you need to 
>  > specify the DHCP
>  > >> BP: options separetely from the document that specifies 
>  > the mechanism
>  > >> BP: of  how bootstrapping is done with DHCP.
>  > >
>  > > Again, this is not "how bootstrapping is done with DHCP". 
>  > This is "how
>  > > bootstrapping is done with EAP, RADIUS, Diameter, IKEv2, 
> DHCP". The
>  > > integrated solution does not revolve around DHCP. DHCP is 
>  > only used for HA
>  > > discovery component. MIP SA, and HoA are still handled 
> by the other
>  > > protocols.
>  > >
>  > >> >> The WG I-D needs to specify the
>  > >> >> DHCP options anyway. Why would that not be sufficient for any
>  > >> deployment
>  > >> >> scenario that you have in mind?
>  > >> >
>  > >> >I think there is a misunderstanding. I was not saying that.
>  > >>
>  > >> BP: Okay...
>  > >>
>  > >> >
>  > >> >
>  > >> >> > there is none for the RADIUS and Diameter specs we 
> expect to 
>  > >> >> > document
>  > >> >> > individually. Should we also merge those AAA 
>  > documents with the
>  > >> others?
>  > >> >>
>  > >> >> Are you refering to the Radius/Diameter mechanisms for 
>  > obtaining the
>  > >> >> bootstrap parameters and storing them in the DHCP 
>  > server? You could
>  > >> >> specify
>  > >> >> those mechanisms independently of the fact that there is a
>  > >> specification
>  > >> >> which explains how DHCP is used for bootstrapping and 
>  > the DHCP options
>  > >> to
>  > >> >> carry the bootstrap parameters between the MS and the 
>  > DHCP server. So 
>  > >> >> I
>  > >> >> don't expect that those drafts also be merged with the 
>  > current spec.
>  > >> >
>  > >> >
>  > >> >You misunderstood me. Let me re-iterate what I had 
>  > described on the list
>  > >> >earlier:
>  > >> >
>  > >> >- The integrated bootstrapping solution depends on a 
>  > number of protocol
>  > >> >design work (1. DHCP options for HA discovery, 2. RADIUS 
>  > attributes for
>  > >> HA
>  > >> >discovery, 3. Diameter AVPs for HA discovery, 4. IKEv2 for HoA
>  > >> >configuration, 5. RADIUS attributes for MIP6 
>  > authentication, 6. Diameter
>  > >> >AVPs for MIP6 authentication) and description (7) of 
> how all such
>  > >> protocols
>  > >> >draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. All 
>  > the others are
>  > >> >currently described in separate documents, and that 
>  > makes sense. Asking
>  > >> for
>  > questions was, why
>  > >> not
>  > >> >merge the others as well. Do you see my point?
>  > >>
>  > >> BP: I see your point... And I gave you my thoughts on the 
>  > integration
>  > >> BP: of AAA options as well in this document above. Elaborating:
>  > >> BP: 2 & 3 are more than just specifying RADIUS attributes 
>  > and Diameter
>  > >> BP: AVPs.
>  > >> BP: 4 does not really apply. How IKEv2 is iused once 
> you have the
>  > >> BP: bootstrap parameters at the MN is specified in the 
>  > split-scenario
>  > >> BP: and can be reused.
>  > >
>  > > That is not true. It is defined in 
>  > draft-ietf-mip6-ikev2-ipsec-04 and 
>  > > simply
>  > > referred by the split-scenario document (right thing to do!).
>  > >
>  > >
>  > >> BP: 5 & 6 are part of the interaction between HA and AAA and the
>  > >> BP: requirements for this captured in the WG I-D
>  > >> BP: draft-ietf-mip6-aaa-ha-goals-02, the intention of the 
>  > WG being to
>  > >> BP: develop AAA specifications separately.
>  > >
>  > > Yes, that's the right thing to do.
>  > >
>  > >> BP: With the case of DHCP options, this is already 
> covered in the
>  > >> BP: existing WG I-D.
>  > >>
>  > >> >
>  > >> >> >
>  > >> >> > Also, I'm not sure what specific concern you are 
>  > raising with 
>  > >> >> > respect
>  > >> to
>  > >> >> the
>  > >> >> > quoted text below.
>  > >> >>
>  > >> >> The concern that I have is the fact that the I-D 
>  > specifies the DHCP
>  > >> >> options
>  > >> >> for boostrapping. The bootstrap parameters are somehow 
>  > stored in the
>  > >> DHCP
>  > >> >> server. The I-D is basically saying that how the 
>  > parameters get into
>  > >> the
>  > >> >> DHCP server are not in scope here except giving an 
>  > example that manual
>  > >> >> configuration or AAA can be used. So it is incomplete 
>  > and unusable.
>  > >> >
>  > >> >
>  > >> >With the same token, documents 2..6 are also incomplete. 
>  > Even 7 is
>  > >> >incomplete. It is the modular combination of these 
>  > various protocol work
>  > >> >that makes a complete picture, no single one can make.
>  > >> >
>  > >>
>  > >> BP: To implement a complete bootstrapping solution, yes 
>  > you would need
>  > >> BP: to refer to multiple documents. But it does not 
> mean that for
>  > >> BP: every option you have a separate spec.  In this case, 
>  > my argument
>  > >> BP: yet again :) is that the WG I-D has a section for the 
>  > DHCP options
>  > >> BP: that are needed and the additional ones that are in 
> draft-jang
>  > >> BP: simply need to be incorporated into the WG doc.
>  > >>
>  > >> BP: There are no hard-and-fast rules or guidelines
>  > >> BP: which say that this is the way it should be done. 
> If the DHCP
>  > >> BP: options were to be specified separately, that would work as
>  > >> BP: well.
>  > >
>  > > I have yet to understand the fundamental problem with this 
>  > approach. Do 
>  > > you
>  > > have any?
>  > >
>  > > And I have a fundamental problem with arbitrarily merging 
>  > one of the
>  > > protocol components with the document that aims plumbing 
>  > those components.
>  > > My fundamental problem is, this component (more than the 
>  > others) have uses
>  > > beyond this very specific plumbing. Given that we like 
>  > designing protocols
>  > > that get used modularly (like the Lego pieces), it does 
>  > not make sense to
>  > > clump an otherwise-independent protocol piece with a 
> very specific
>  > > framework. There would be no gains but simply difficulty 
>  > in referencing 
>  > > that
>  > > specific protocol component out of a specific framework 
>  > when people need 
>  > > to
>  > > use it (but not the rest of the framework).
>  > >
>  > >> I am just recommending an approach that I believe in this
>  > >> BP: case is optimal.
>  > >
>  > >
>  > > Alper
>  > >
>  > >
>  > >
>  > >>
>  > >>
>  > >> -Raj
>  > >>
>  > >> >
>  > >> >> What
>  > >> >> you
>  > >> >> say above is that there will be additional I-Ds coming 
>  > to specify how
>  > >> that
>  > >> >> is done. The current WG integrated scenario with 
>  > DHCPv6 I-D has more
>  > >> >> details
>  > >> >> and explains at least how AAA is used. I guess manual 
>  > configuration is
>  > >> >> pretty straightforward and does not need secification. 
>  > But in the case
>  > >> >> when
>  > >> >> the MS is roaming and attached to some visited 
>  > network, how does it
>  > >> >> bootstrap with DHCP? My concern is the fact that the 
>  > I-D is incomplete
>  > >> and
>  > >> >> it simply sweeps the issue under the mat by saying it 
>  > is out of scope.
>  > >> >
>  > >> >Alper
>  > >> >
>  > >> >
>  > >> >
>  > >> >
>  > >> >
>  > >
>  > >
>  > >

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Mon, 7 Aug 2006 11:25:31 -0400

Hello Raj,

IMHO, the working group I-Ds are defining the necessary mechanism for
mip6 bootstrapping by using various components such as IKEv2, DHCP, AAA,
DNS etc. Some of the components are defined in already published RFCs
and some are in the process of being defined e.g. the AAA and the DHCP
components. I do not think it makes sense to proceed with separate
documents for the AAA components whereas merge the DHCP component. I
don't find a valid reason to justify this exception. Note that all the
components that these bootstrapping solutions are trying to use are work
of other WGs in IETF. 

There are simple use cases where a back-end AAA infrastructure is not
deployed but still DHCP options can be used to convey HA, HoA info from
a DHCP server to the MN (e.g. an enterprise network). 

If your reasoning is purely related to the documentation of the DHCP
options in IETF, I would suggest that we follow what other SDOs are
doing. Most of the ones I know of adopted the approach of short and
manageable documents that are easy to use, read, and update. It also
allows focused discussion on specific areas.

Regards,
Kuntal

> Sent: Thursday, August 03, 2006 2:29 PM
> To: ext Alper Yegin; [email-masked]
> Alper,
> Inline:
> On 8/2/06 4:45 PM, "ext Alper Yegin" <[email-masked]> wrote:
> 
> > Hi Raj,
> >
> > does not tie into the RADIUS-driven details -- the use where DHCP
server
> But why do you believe that the WG I-D which is using DHCP is RADIUS
> driven
> only and nothing else? I mean it could just as well be used for the
case
> where the bootstrapping information is manually configured in the DHCP
> server. What is needed are the DHCP options and the fact that the
> bootstrap
> parameters are available in the DHCP server either as a result of some
AAA
> > Besides, while there is a standalone use for draft-jang-mip6-hiopt-
> 00.txt,
> 
> What is the standalone use of draft-jang? The WG I-D needs to specify
the
deployment
> > there is none for the RADIUS and Diameter specs we expect to
document
> > individually. Should we also merge those AAA documents with the
others?
> 
> Are you refering to the Radius/Diameter mechanisms for obtaining the
> bootstrap parameters and storing them in the DHCP server? You could
> specify
specification
> which explains how DHCP is used for bootstrapping and the DHCP options
to
> carry the bootstrap parameters between the MS and the DHCP server. So
I
> don't expect that those drafts also be merged with the current spec.
> 
> >
> The concern that I have is the fact that the I-D specifies the DHCP
> options
> for boostrapping. The bootstrap parameters are somehow stored in the
DHCP
> server. The I-D is basically saying that how the parameters get into
the
> DHCP server are not in scope here except giving an example that manual
> configuration or AAA can be used. So it is incomplete and unusable.
What
> you
> say above is that there will be additional I-Ds coming to specify how
that
> is done. The current WG integrated scenario with DHCPv6 I-D has more
> details
> and explains at least how AAA is used. I guess manual configuration is
> pretty straightforward and does not need secification. But in the case
> when
> the MS is roaming and attached to some visited network, how does it
> bootstrap with DHCP? My concern is the fact that the I-D is incomplete
and
> it simply sweeps the issue under the mat by saying it is out of scope.
> 
> -Raj
> 
> >
> > Alper
> >
> >
> >

"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."