Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 16 Feb 2007 12:22:07 -0500

Hi George,

Thanks for your comment. Please see inline....

-Kuntal

> -----Original Message-----
> From: Tsirtsis, George [mailto:[email-masked]]
> Sent: Wednesday, February 14, 2007 4:31 PM
> To: Basavaraj Patil; [email-masked]
> Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02
> 
> I have the following questions. I appologise in advance if this issues
> have been discussed sine I have not followed the discussions closely.
> 
> In section 3.2.2. (Home Agent allocation in the ASP), It is not clear
> what happens if the DHC server is not configured to assign local HAs
to
> visiting MNs.
[KC>] In that case the DHCP server won't return local HA address to the
MN. This is normal DHCP server behavior. It includes information in the
reply based on its configuration. RFC 3315 says the following:

"
If the client included an Option Request
   option in its message, the server includes options in the Reply
   message containing configuration parameters for all of the options
   identified in the Option Request option that the server has been
   configured to return to the client.  The server MAY return additional
   options to the client if it has been configured to do so.
"

So, it is upto the local DHCP server configuration and the availability
of the HA information in OPTION_MIP6-RELAY-Option. If the MN does not
receive what it requested i.e. HA in the local network, it can send
another information request to the DHCP server requesting HA address in
the home domain (MSP) or indicate no preference i.e. id-type=2.

> Also, would it be possible for a mobile to ask for both visited and
home
> HAs? One way would be to allow two Home Network Identifier Options,
one
> with id-type set to 1 and another with id-type set to 0 so that the MN
> can request both MSP and ASP HAs. Another way would be to define
> id-type=4 "Visited and home domain" in draft-ietf-mip6-hiopt-01.txt.
> 
> Thoughts?
> 
[KC>] It may be possible for the MN to request HA information for both
visited (ASP) and home (MSP) domains in the same information request
message. The current hiopt I-D has the necessary options / sub-options
defined to do what you suggested. We have to make sure that there is
appropriate text around it in that I-D.

> George
> 
> > -----Original Message-----
> > From: Basavaraj Patil [mailto:[email-masked]]
> > Sent: Wednesday, February 14, 2007 1:10 PM
> > To: [email-masked]
> > Subject: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02
> >
> >
> > Hello,
> >
> > This is a MIP6 Working group last call for the WG I-D:
> > "MIP6-bootstrapping for the Integrated Scenario",
> > draft-ietf-mip6-bootstrapping-integrated-02.txt
> >
> > I-D:
> >
>
http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated
> -
> > dhc
> > -02.txt
> >
> > Please review and submit your comments to the authors or the mailing
> > list. The WGLC will expire on March 1st, 07.
> >
> > -Chairs
> >
> >
> > _______________________________________________
> > Mip6 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mip6
> 
> _______________________________________________
> 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: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 21 Feb 2007 13:49:09 -0500

Hi Killian,

Thanks for reviewing the draft. I see that Heejin already responded to
you. Let me add some of my comments...please see inline.

Regards,
Kuntal

> From: Kilian Weniger [mailto:[email-masked]]
> Sent: Friday, February 16, 2007 2:31 AM
> Hi,
> please find below some comments about
> draft-ietf-mip6-bootstrapping-integrated-02.
> 
> The draft is well written and easy to understand (thanks to figures
and
> message sequence text). However, some details and corner cases are not
> addressed, which may need to be specified, e.g.:
> 
> - How does the NAS/relay map a DHCP request received from a specific
MN
>   to the cached home network information previously received from AAAH
>   for this MN, so that it can include the correct home network
>   information in a received DHCP request?

[KC>] Normally NAS maintain session states along with lower layer
identifiers such as tunnel ID, MAC address etc. These identifiers help
NAS in locating the correct cached info for the MN.

> - What is the conceptual data structure needed for this in the
NAS/DHCP
>   relay?
> - Any default value for how long NAS should cache home network
>   information received from AAA for a specific MN (i.e., when is NAS
>   allowed to delete cache entry?)? If this is specified in [MIP6-Dime]
>   or [MIP6-RADIUS] it should be mentioned and referenced.

[KC>] As Heejin mentioned, I think these are implementation specific
details.

> - What should NAS do if DHCP request with Home network identifier
>   option is received from a MN and NAS doesn't find valid home network
>   information for this MN in its cache (e.g., since the cache entry
>   has expired)?

[KC>] If a NAS implementation does not store the home network
information as long as the MN's session remains in the ASP, this
scenario may happen if the MN delays sending DHCP request. In such case,
the NAS/DHCP relay won't include the OPTION_MIP6-RELAY-Option in the
Relay Forward message.

> - What should DHCP relay/server do if the MN does not include the
>   OPTION_CLIENTID in the DHCP request or if OPTION_MIP6-RELAY-Option
>   is missing in request?
> 

[KC>] I think Heejin already clarified this with you.

> The draft may need better aligned with [HIOPT]. For instance, it is
not
> clear to me how exactly the home network identifier option and the
home
> network information option specified in [HIOPT] are allowed to be used
> in draft-ietf-mip6-bootstrapping-integrated-02:
> 
[KC>] This part was in this I-D. However, based on the consensus we had
in the WG, we decided to move all the DHCP related behavior to HIOT.
Please look at section 4 in HIOT.

> - [HIOPT] supports home address allocation. This is not mentioned in
>   draft-ietf-mip6-bootstrapping-integrated-02. Is this forbidden or
>   allowed or out-of-scope? If allowed, when does NAS set the A-flag in
>   the home network identifier option?

[KC>] Please see Heejin's clarification.

> - Is it allowed that multiple HA addresses are returned in the home
>   network information option?
[KC>] yes, it is allowed.

> - [HIOPT] allows that the home network identifier option includes an
>   identifier of a target network, which is different from home or
>   visited network of MN. This is not mentioned in
>   draft-ietf-mip6-bootstrapping-integrated-02. Is this allowed or
>   forbidden?
[KC>] the main assumption in integrated scenario is ASA == MSA. It is
the MSA that authorizes the MN for mobility service and assigns
appropriate number of Home Agents (in each MSPs if there are multiple
MSPs) for the MN. If the MN sends DHCP request with home network
identifier option set to one of the authorized MSPs and there is a HA
assignment for that MSP by the MSA, the MN will get that HA's address.
If the MN sends anything else (i.e. a domain that is not part of the
authorized list of MSPs by the MSA), the MN may not get any Home Agent
address in the reply. 

> - Which HA information should the MN use if it receives, e.g., an FQDN
>   and a HA address in DHCP reply? [HIOPT] refers to section 3.6 of
>   draft-ietf-mip6-bootstrapping-integrated-01, but this section
doesn't
>   exist in draft-ietf-mip6-bootstrapping-integrated-02 anymore...
> 
[KC>] This text was exported to HIOT draft.

> Some other comments:
> 
> - It would be good to have a section, which explicitly states
>   assumptions and applicability of the protocol. This should include:
> 	- MSA and ASA must be co-located (i.e., integrated scenario)

[KC>] The definition of integrated scenario exists in RFC 4640. 

> 	- AAA infrastructure assumed and some kind of roaming
>         relationship between ASP and MSA/ASA is required

[KC>] We have ample references to AAA infrastructure for ASA and MSA.
However, we can still add a sentence about the use of AAA infrastructure
to authenticate and authorize the MN. Regarding roaming, I think your
comment is valid. ASP <-> ASA/MSA and MSP <-> ASA/MSA roaming
relationships are basic requirements for any access auth/authz for the
MN. However, I think it is a generic requirement. Even in case of split
scenario, ASP <-> ASA and MSP <-> MSA roaming relationships are
necessary. Look at section 6 in RFC 4640 and let me know what you think.

> 	- MSP is either co-located with ASP or MSA or both
>         (Or are other target networks allowed; see above)?

[KC>] Why we need to mandate collocation of MSP with ASA or MSA? The
draft HIOT allows any target network, but that does not mean that in the
integrated scenario, the MSA can bootstrap the MN for any (random)
target network.

> 	- DHCP relay and NAS must be co-located
> 
[KC>] I think it is already mentioned in the draft:
"
Also, the mechanism defined in this document requires the NAS to support
Mobile IPv6 specific AAA attributes and a collocated DHCP relay agent.
"

> - At some places in the text the use of the term "MSP" is ambiguous,
>   since MSP can refer to at least home and visited network. Better
>   use "home MSP" for MSP in home network.
> 	- e.g., section 3.1:
>   "Note that a home agent for usage
>    with the mobile node might be selected in the access service
>    provider's network or alternatively in the *home* mobility service
>    provider's network."

[KC>] I understand your point. We can clarify by saying that:

"
Note that a home agent for usage with the mobile node might be selected
in the access service provider's network (ASP is the visited MSP in this
case) or alternatively in the *home* mobility service provider's network
(home MSP).
"
What do you think? If you agree, I will ensure that this is clarified
elsewhere in the document.

> 	- or in section 3.2:
>   "The message flows for home agent
>    allocation in the ASP and the *home* MSP are illustrated below.

[KC>] Similarly we can clarify:

" 
The message flows for home agent allocation in the ASP (ASP is the
visited MSP in this case) and the *home* MSP are illustrated below.
"

> 	- or in section 3.2.1:
>   "3.2.1.  Home Agent allocation in the *home* MSP",
>   "(4)... mobile node is requesting home agent information in the
>   *home* MSP..."
> 
> - Section 3.3 currently mentions DNS-based HA address discovery method
>   only, but [BOOT-SPLIT] also specifies an anycast-based HA address
>   discovery method. Either both or none should be mentioned.
> 
[KC>] I see your point. May be we just need to say that incase the DHCP
reply comes back with no Home Agent address, the MN may fallback to
other methods for Home Agent bootstrapping. Some of those methods are
mentioned in [BOOT-SPLIT]. 

> - The title of draft-ietf-mip6-bootstrapping-integrated-02 can cause
>   the impression that the draft defines a complete bootstrapping
>   procedure. But draft-ietf-mip6-bootstrapping-integrated-02 defines a
>   method for HA address assignment only. I think this is misleading.
>   Why not name the draft according to what it specifies (e.g., "HA
>   address assignment using DHCP and AAA" or "HA address assignment for
>   the integrated scenario using DHCP and AAA" instead of
>   "MIP6-bootstrapping for the integrated scenario")?
> 
[KC>] I agree with you that the Home Agent assignment is the focus of
the integrated scenario solution I-D. But, the suggested title change
will be misleading too. One of the primary assumption in the integrated
scenario for mip6 bootstrapping is ASA == MSA. This is the main reason
why the MSA can authorize the MN to have mobility service at the time of
access auth/authz at the ASA. As per this assumption, the MSA assigns
Home Agent info to the MN at the time of access auth. The MSA can
potentially assign the HoA as well (in some deployments that may very
well be the case), but we stayed away from mentioning that in the draft
based on consensus. Another reason was to reuse text from other drafts
as much possible. 

That said, the scope and focus of this I-D is to address mip6
bootstrapping solution for the "Integrated ASP Network Scenario" as
defined by RFC 4640. So, the current title is fine, IMHO.

> Regards,
> Kilian
> > Sent: Mittwoch, 14. Februar 2007 19:10
> > To: [email-masked]
> > http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-
> > integrated-dhc
> > -02.txt
> >
> Panasonic R&D Center Germany GmbH
> 63225 Langen, Hessen, Germany
> Reg: AG Offenbach (Hessen) HRB 33974
> Managing Director: Thomas Micke
> 
> 
>

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 22 Feb 2007 12:05:59 +0100

Hi Kuntal,

thanks for you comments. See my comments inline.

> From: Chowdhury, Kuntal [mailto:[email-masked]] 
> Sent: Mittwoch, 21. Februar 2007 19:49
> To: Kilian Weniger; Basavaraj Patil; [email-masked]

I will reply to Heejin in a separate mail.

> > Subject: RE: [Mip6] WGLC: 
> draft-ietf-mip6-bootstrapping-integrated-02
> > 
> > Hi,
> > 

ok, I was expecting that. Maybe this could be clarified in the draft for
better understanding (without mandating a specific lower layer
identifier of course).

> [KC>] As Heejin mentioned, I think these are implementation specific

yes, but I think some guidance with respect to values that make sense
might be helpful for implementors.

> the NAS/DHCP relay won't include the OPTION_MIP6-RELAY-Option in the

ok. Shouldn't the draft specify this behaviour?

> Please look at section 4 in HIOT.

ok. So the split is that HIOPT specifies all the DHCP related behaviour
and defines the DHCP messages/options and
draft-ietf-mip6-bootstrapping-integrated-02 defines how this interworks
with AAA and gives the overall picture? Is this correct? I think
draft-ietf-mip6-bootstrapping-integrated-02 should clearly say what its
scope is and how the split is with respect to HIOPT (and the reference
should be updated to new HIOPT-version).

> [KC>] yes, it is allowed.

ok. In general, I think all the supported features should be mentioned
in draft-ietf-mip6-bootstrapping-integrated-02. 

> authorized list of MSPs by the MSA), the MN may not get any Home Agent

I see. So every realm of any MSP that has a trust relationship to the
MN's MSA and that is supported by the MSA's allocation policy can be
included as target network in the home network identifier option, right?
(That's what I meant by "a target network, which is different from home
or visited network of MN".) 

Hmm, after checking RFC4640, it seems that there is a mismatch between
your comment and what the draft says: 

- Section 3.2.1 of draft-ietf-mip6-bootstrapping-integrated-02 says
"This section describes a scenario where the home agent is allocated in
the mobile node's *home MSP* network." 
- RFC 4640 says in section 6: "A network operator providing Mobile IPv6
service is called a mobility service provider (MSP). ...A network
operator that authenticates a mobile node and authorizes mobility
service is called a mobility service authorizer (MSA). If both types of
operation are performed by the same operator, that operator is called a
*home mobility service provider*.". 

So according to RFC4640 the home MSP is always the MSA. Since you said
HA allocation from other networks is supported, I think the use of "home
MSP" in the section 3.2.1 is not correct. Or am I missing something
here?

And I think the support of the feature of HA allocation from MSP != MSA
and != ASP should be mentioned in the draft. 

> necessary. Look at section 6 in RFC 4640 and let me know what 

ASP <-> ASA is general requirement for network access in roaming
scenarios, I agree. But the required MSP <-> ASA roaming relationship is
specific to this draft and it would be worth mentioning IMHO. 
You are right, the reader could deduced it to some extent from RFC4640,
which says that MSA <-> MSP roaming relationship is *supported* (not
required) for MIP bootstrapping and MSA = ASA is an assumption in
integrated scenario. I prefer to make a clear statement about
assumptions/requirements of solutions in the draft.

> integrated scenario, the MSA can bootstrap the MN for any (random)

This requirements comes from the misunderstanding about the home MSP
explained above. Since you clarified that target network != MSA and !=
ASP is supported, you are right that this requirement is not valid
anymore...

> Mobile IPv6 specific AAA attributes and a collocated DHCP relay agent.

yes, it is somewhat redundant. I just prefer it if the applicability and
all the requirements for the solution are clearly stated (preferably in
a separate section, as opposed to hidden in the text).

> elsewhere in the document.

Hmm, after having read your comments, "home MSP" might not be correct
here, since MSP can be != MSA (i.e., != home MSP) in this section. How
about "MSP different from ASP" instead of "home MSP"?

> visited MSP in this case) and the *home* MSP are illustrated below.

Home MSP might not be correct (see above). How about

"The message flows for home agent allocation in the MSP for the cases
that the MSP is equal to the ASP and different from the ASP are
illustrated below."

> mentioned in [BOOT-SPLIT]. 

sounds good.

> >   procedure. But 
> draft-ietf-mip6-bootstrapping-integrated-02 defines a

Since the introduction says "This document defines a mechanism for home
agent address discovery.  For the rest of components, please refer to
[BOOT-SPLIT].", I think the title is still ok. 

However, you mentioned that HoA allocation can be done by the MSA
(probably by using the method specified in HIOPT). If this shall be
supported in the integrated scenario, I think the draft has to mention
it. Currently, the draft clearly says that HoA allocation is according
to [BOOT-SPLIT]...

Regards,

Kilian 

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

---

From: Heejin Jang <[email-masked]>
Date: Mon, 26 Feb 2007 02:44:55 +0000 (GMT)

Hi, Kilian.

Thanks for the comments.

Regarding the use of term, the draft(hiopt) supports all the three following
networks as target networks

1) ASP (MN's currently visited network)

2) Home MSP (= MSA)

3) MSP (network which is nether  ASP nor Home MSP but has trust relationship
with MN's MSA)

The term 'home MSP' can be ambiguous since it does not include 3),

so we will modify it to 'MSP with roaming  relationship with MN's MSA'
for more clarification.

Thanks.

Regards,

Heejin.

------ Original Message -------
Sender : Kilian Weniger<[email-masked]>
Date : 2007-02-22 23:00
Title : RE: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02

Hi Heejin,

thanks for your comments, see my replies inline.

Please note that the comments in my mail were referring to

draft-ietf-mip6-bootstrapping-integrated-02. And since the reference

[HIOPT] in draft-ietf-mip6-bootstrapping-integrated-02 is hiopt-01, I

didn't consider hiopt-02.

> From: Heejin Jang [mailto:[email-masked]]

> Sent: Dienstag, 20. Februar 2007 08:31

> To: Kilian Weniger

> Cc: Basavaraj Patil; [email-masked]

> Subject: Re: RE: [Mip6] WGLC:

> Hi,  Kilian Weniger.

> Thanks for the detailedl comments.

> Please see the inline comments for the HIOPT draft.

> ------- Original Message -------

> Sender : Kilian Weniger<[email-masked]>

> Date : 2007-02-16 17:31

> Title : RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02

> The draft is well written and easy to understand (thanks to

> figures and

> message sequence text). However, some details and corner

> cases are not

> - How does the NAS/relay map a DHCP request received from a

> specific MN

>   to the cached home network information previously received

> from AAAH

> Hiopt>> The mapping mechanism is added in section 4.3 of the

> latest version of the document (hiopt-02).

It should be in section 4.2, since my question was related to the DHCP

relay behaviour. Maybe I missed it, but I can't see any related text in

section 4.2 of hiopt-02 about mapping of home information received from

AAA server to DHCP request received from MN. But Kuntal answered to my

question in his reply email.

> The information is mapped based on NAI not by NAS but by DHCP

> server. Rrefer to hiopt-02 for more details.

> - What is the conceptual data structure needed for this in

> the NAS/DHCP

>   allowed to delete cache entry?)? If this is specified in

> [MIP6-Dime]

> Hiopt>> This is implementation-specific. I'm not sure we need

> to describe down to the smallest detail.

A value doesn't need to be mandated, but I think some guidance to the

implementor would be good.

>   option is received from a MN and NAS doesn't find valid

> home network

> Hiopt>>In that case, there is nothing NAS can do. If the

> corresponding information

> is configured on the DHCP server (for e.g.,

> pre-configuration), the server will

> provide it. Otherwise, it will reply with 0-lengh option.

ok. My comment was that this should be documented (i.e., DHCP server

must reply with 0-lengh option in this case)

> Hiopt>> The existing DHCP options are handled according to [RFC 3315].

> The request not including OPTION_CLIENTID is discarded in the

> relay/server

> as described in 15.4 of [RFC 3315].

ok.

> The draft may need better aligned with [HIOPT]. For instance,

> it is not

> clear to me how exactly the home network identifier option

> and the home

> network information option specified in [HIOPT] are allowed

> to be used

>   allowed or out-of-scope? If allowed, when does NAS set the

> A-flag in

> Hiopt>> NAS SHOULD not modify the Home Network Identifier option.

> The A-flag is set to 0/1 only by the mobile node. If there is

> home address

> information at NAS that was acquired during AAA transaction,

> it is delivered

> to the DHCP server with MIP6-Relay option. (Refer hiopt-02.txt)

I was aware of HoA allocation support in [HIOPT]. My question was

whether it is supported in draft-ietf-mip6-bootstrapping-integrated-02

as well, since HoA allocation is not mentioned there.

> Hiopt>> It is allowed by using multiple home network

> information option.

>   "Multiple sub-options may exist in a Home Network Information option

>    to carry more than one home information." (in section 3.3.1)

> Hiopt>> A target network may or may not be home network of the MN.

good. I guess "home network" means "home MSP" in this case, right?

According to RFC4640, the "home MSP" is MN's MSA providing mobility

service to MN.

According to Kuntal's comment, also MSPs other than MSA (or "home MSP")

and ASP are supported as target networks. If this is true for hiopt (and

it should be if it is true for

draft-ietf-mip6-bootstrapping-integrated-02), then it seems that the

hiopt draft also uses the term "home MSP" differently than defined in

RFC4640. For instance, section 4.3, case C (id-type 2) says

"In case the server cannot not find any home information neither for

the local network nor for the *home MSP*, it MUST return a Home

Network

Information option with the 0-length data."

This would restrict HA/HoA allocation from ASP and MSA (=home MSP). I

guess you also want to support allocation from MSPs other than ASP and

MSA, no? So shouldn't "home MSP" be replaced by "any other MSP with

roaming relationship to MN's MSA"?

Same for id-type 1: section 3.1 says

"          id-type

The type of Home Network Identifier:

0    Visited domain (local ASP)

1    Home domain (home MSP)

....

Id-type 1 indicates the mobile node is interested in learning the

home network information that pertains to the given realm.  This type

can be used to discover home agents that are hosted by a user's home

domain (as indicated by his/her NAI-based username -- user@

HomeRealm).  The Home Network Identifier field MUST be set to the

target home MSP.  "

This text implies that HA/HoA allocation from other MSPs than home MSP

(which is equal to MSA) is not supported with id-type 1, even if those

MSPs have a roaming relationship with the MN's MSA. Is this true?

Regards,

Kilian

> In current draft, the server is supposed to provide the HA

> information if it has

> the corresponding information. If the given HA does not

> function as HA for

> the requesting MN, it will reply with the BA status = 132 or 133

> (Not home subnet / home agent for this mobile node) during

> MN's registration.

> - Which HA information should the MN use if it receives,

> e.g., an FQDN

>   draft-ietf-mip6-bootstrapping-integrated-01, but this

> section doesn't

> Hiopt>> It is within the MN's own discretion as follows.

> I don't think it should be standardized in HIOPT document.

> "For example, if the mobile node acquires both IPv6

> address(es) and FQDN(s)

>  of the home agents, it may try to use the address

> information of the home agent(s) first."

> - Section 3.3 currently mentions DNS-based HA address

> discovery method

>   procedure. But draft-ietf-mip6-bootstrapping-integrated-02

> defines a

>   address assignment using DHCP and AAA" or "HA address

> assignment for

> > -----Original Message-----

> > From: Basavaraj Patil [mailto:[email-masked]]

> > Sent: Mittwoch, 14. Februar 2007 19:10

> > To: [email-masked]

> > Subject: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02

> >

> >

> > Hello,

> >

> > This is a MIP6 Working group last call for the WG I-D:

> > "MIP6-bootstrapping for the Integrated Scenario",

> > draft-ietf-mip6-bootstrapping-integrated-02.txt

> >

> > I-D:

> > http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-

> > integrated-dhc

> > -02.txt

> >

> > Please review and submit your comments to the authors or

> the mailing

> > list. The WGLC will expire on March 1st, 07.

> >

> > -Chairs

> >

> >

> > _______________________________________________

> > Mip6 mailing list

> > [email-masked]

> > https://www1.ietf.org/mailman/listinfo/mip6

> >

> >

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 27 Feb 2007 15:50:26 -0500

Hi Kilian,

Please see inline....

I will start updating the I-D with your comments after the WGLC is over.

Regards,
Kuntal

> Sent: Thursday, February 22, 2007 5:06 AM
> To: Chowdhury, Kuntal
> Cc: [email-masked]; Basavaraj Patil
> > > The draft is well written and easy to understand (thanks to
figures
> > > - How does the NAS/relay map a DHCP request received from a
specific
> better understanding (without mandating a specific lower layer
[KC>] OK. I will try to clarify this in the next revision.

> might be helpful for implementors.
[KC>] We can say: how long the NAS caches the received mip6 bootstrap
information for a MN should be configurable.

> ok. Shouldn't the draft specify this behaviour?
[KC>] OK. I will clarify this.

> should be updated to new HIOPT-version).
[KC>] OK. I will see how to clarify this in the next revision. Of
course, feel free to provide text to me if you like.

> in draft-ietf-mip6-bootstrapping-integrated-02.
[KC>] OK. I will mention that the AAAH may return more than one home
agent for each of the MSPs.

> or visited network of MN".)
[KC>] Yes.

> MSP" in the section 3.2.1 is not correct. Or am I missing something
[KC>] Your interpretation of home MSP is correct. However, it is quite
possible that the home MSP/MSA can also assign (or authorize) Home Agent
in a different MSP e.g. local Home Agent assignment in the visited
domain (ASP). This is possible based on roaming agreements between the
home MSP and the ASP (ref section 3.2.2). 

I do understand the source of your confusion though. I think step 1 in
section 3.2.2 needs to be updated to show that the home MSP actually
authorizes the MN to get an HA address in the visited domain (ASP). The
NAS needs to indicate it's capability for local HA assignment. The NAS
will optionally indicate the HA address in the ASP that will be assigned
to the MN in case that option is authorized by the home MSP. These
clarifications will be added in the AAA drafts:
draft-ietf-dime-mip6-integrated-02.txt and
draft-ietf-mip6-radius-01.txt. 

> and != ASP should be mentioned in the draft.
[KC>] OK. I will add some text around that topic.

> assumptions/requirements of solutions in the draft.
[KC>] OK. Could you please suggest some text on this?

> a separate section, as opposed to hidden in the text).
[KC>] OK, I will add a section to state the assumptions.

> about "MSP different from ASP" instead of "home MSP"?
[KC>] OK. In that case, I will keep the existing text and modify it as
follows:

"Note that a Home Agent for usage with the MN might be selected in the
Access Service Provider's network (ASP == MSP) or in a different network
(ASP != MSP)"

> that the MSP is equal to the ASP and different from the ASP are
[KC>] OK.

> it. Currently, the draft clearly says that HoA allocation is according
[KC>] I agree. I am OK to include HoA assignment in the I-D to utilize
the full potential of HIOPT. I will include it unless there are
objections from the members.

> > > > Subject: [Mip6] WGLC:

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 27 Feb 2007 16:02:29 -0500

Thanks Heejin. I think your suggested clarification # 3 is good. 

-Kuntal

________________________________________
From: Heejin Jang [mailto:[email-masked]] 
Sent: Sunday, February 25, 2007 8:45 PM
To: Kilian Weniger
Cc: [email-masked]; Basavaraj Patil
Subject: Re: RE: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02

Hi, Kilian. 
Thanks for the comments. 
 
Regarding the use of term, the draft(hiopt) supports all the three following networks as target networks
1) ASP (MN's currently visited network)
2) Home MSP (= MSA)
3) MSP (network which is nether  ASP nor Home MSP but has trust relationship with MN's MSA)
 
The term 'home MSP' can be ambiguous since it does not include 3), 
so we will modify it to 'MSP with roaming  relationship with MN's MSA' for more clarification.
Thanks.
 
Regards, 
Heejin.

------ Original Message -------
Sender : Kilian Weniger<[email-masked]>
Date : 2007-02-22 23:00
Title : RE: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02

Hi Heejin, 

ok. 

"          id-type 

                     1    Home domain (home MSP) 
.... 

Regards, 

Kilian

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 28 Feb 2007 17:56:00 +0100

Hi Kuntal,

Please see my comments inline.

> Sent: Dienstag, 27. Februar 2007 21:50
> To: Kilian Weniger
> > > Thanks for reviewing the draft. I see that Heejin already 
> responded
> to

Ok. Additionally, we could say something like "The cache time should be
at least as long as the maximum time it can take to receive a DHCP
Information Request from a MN's DHCP client after a successful network
authentication.".

> course, feel free to provide text to me if you like.

How about:

"This draft enables HA and HoA assignment in the integrated scenario by
utilizing DHCP and AAA protocols. The specification is split in two
parts: Whereas [HIOPT] specifies the required DHCP protocol extensions
and DHCP server behaviour, this draft specifies the interworking with
AAA and gives an overview of the overall bootstrapping procedure in the
integrated scenario."

> 
> 
> > >
> > > > - [HIOPT] supports home address allocation. This is not 
> mentioned
> in
> > > > - [HIOPT] allows that the home network identifier 
> option includes
> an
> > operation are performed by the same operator, that operator 
> is called
> a

right.

> draft-ietf-mip6-radius-01.txt. 

Ok

ok. 

> > scenarios, I agree. But the required MSP <-> ASA roaming 
> relationship
> is

How about:

"The solution described in this draft is only applicable for the
integrated scenario, which means that it is assumed that MSA and ASA are
the same [boot-ps]. Further, it is assumed that the MSP is either equal
to the MSA/ASA (i.e., it is a home MSP) or has a roaming relationship
with the MSA/ASA. In the latter case, the MSP can be in the ASP or in
any other network."

> [KC>] OK, I will add a section to state the assumptions.

Ok. See above for a text proposal.

> Access Service Provider's network (ASP == MSP) or in a 

ok. Furthermore, the term "home MSP" in section 3.2.1 must be replaced,
e.g., by "MSP != ASP" (i.e., any MSP with roaming relationship with MSA,
but different from ASP).

> objections from the members.

Ok.

Thanks,

Kilian

---

From: <[email-masked]>
Date: Wed, 28 Feb 2007 20:02:31 +0100

Hi Kilian, 

> Sent: 28. helmikuuta 2007 18:55
> To: Korhonen, Jouni /TeliaSonera Finland Oyj
> Cc: Chowdhury, Kuntal; Heejin Jang; [email-masked]; Basavaraj Patil
> Hi Kuntal, Jouni, 
> yes, encoding the service in the Home Network Identifier 
> field would also be possible (probably with changes to 
> [HIOPT]). However, this has the danger of overloading the 
> semantics, since this would change the network identifier to 
> something like a "network+service" identifier. And don't we 

Hmmm.. lets be careful here. We are talking about only
assigning different flavors of HA, nothing more.

> need to standardize a format then, since the format for 
> encoding the service into the FQDN must be understood by the 
> MSA *and all ASPs*, right? 

No. We cannot really mandate specific format as we probably do it
wrong anyway for other SDOs in their architectures. Just state that
FQDNs can be used to assign different flavors of HAs if an operator 
or a SDO wishes to do so.

Cheers,
	Jouni

> Cheers,
> > From: Jouni Korhonen [mailto:[email-masked]]
> > Sent: Mittwoch, 28. Februar 2007 10:55
> > To: Kilian Weniger
> > Cc: Chowdhury, Kuntal; Heejin Jang; [email-masked]; Basavaraj Patil
> > Subject: Re: [Mip6] WGLC: 
> > [snip]
> > >> I heard at least one operator requesting such feature (and
> > note that
> > >> this is in principle possible with the HA discovery/assignment 
> > >> mechanisms defined in the split scenario bootstrapping draft). A
> > > simple
> > >> way to support this in the integrated scenario would be to add
> > > something
> > >> like a "type of requested HA service" field in the Home Network 
> > >> Identifier Option of the DHCP information request sent by
> > the MN. The
> > >> new field would encode the type of service, e.g., 0=MIPv6,
> > 1=DS-MIPv6,
> > >> 2=NEMO,...). Similarly, the Home Network Information
> > Sub-option could
> > >> include a "type of HA service" field to inform the MN
> > about the type
> > > of
> > 
> > Good point imho.
> > 
> > >> service supported by the HA offered in this option. 
> > However, since the
> > >> AAAH wouldn't know the HA service requested by the MN,
> > AAAH would need
> > >> to send at least one HA address per supported service to the NAS.
> > >>
> > > [KC>] Alternatively, we can encode the Home Network
> > Identifier (FQDN) as
> > > ha.dsmip6.domain, ha.mip6.domain. This is possible with 
> the current 
> > > HIOPT I-D, no? From the AAAH perspective, it (AAAH) needs
> > to send the HA
> > > address - Service pair. The service can be indicated by the
> > FQDN AVP. We
> > > have the following AVPs in draft-ietf-dime-mip6-integrated-03.txt:
> > > 
> > >                                 [ MIP6-Home-Agent-Address ]
> > >                                 [ MIP6-Home-Agent-FQDN ]
> > 
> > Using different FQDNs under the same operator domain for 
> > differentiating between types of service nodes is already 
> practised in 
> > some 'relevant'
> > SDOs. In that sense I think it could be a good approach. Dime's I-D 
> > draft-ietf-dime-mip6-integrated allows a NAS to give hints 
> already to 
> > the AAAH using AVPs mentioned above and since we are about 
> to revise 
> > the Dime I-D this part could be clarified further.
> > 
> > > Perhaps we can group them under a new AVP for service, e.g.
> > > MIP6-Home-Agent-Info AVP. For RADIUS we can perhaps link 
> the MIP6-HA 
> > > Attribute and MIP6-HA-FQDN Attribute.
> > 
> > There was also some other SDO asking for more generic 'ASP 
> info' AVP 
> > e.g. for local HA assignment. MAybe these could be combined.
> > IMHO this
> > discussion should be brought to Dime as well.
> > 
> > Cheers,
> > 	Jouni
> > 
> > > 
> > > 
> > > 
> > >> What do you think?
> > >>
> > >> Cheers,
> > >>
> > >> Kilian
> > >>
> > >>
> > >> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas 
> > >> Micke
> > >>
> > > 
> > >