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

From: Heejin Jang <[email-masked]>
Date: Tue, 20 Feb 2007 07:31:06 +0000 (GMT)

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

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?

Hiopt>> The mapping mechanism is added in section 4.3 of the latest
version of the document (hiopt-02).

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

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.

Hiopt>> This is implementation-specific. I'm not sure we need to describe
down to the smallest detail.

- 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)?

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.

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

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

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:

- [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?

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)

- Is it allowed that multiple HA addresses are returned in the home

network information option?

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] 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?

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

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

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

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

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)

- AAA infrastructure assumed and some kind of roaming

relationship between ASP and MSA/ASA is required

- MSP is either co-located with ASP or MSA or both

(Or are other target networks allowed; see above)?

- DHCP relay and NAS must be co-located

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

- or in section 3.2:

"The message flows for home agent

allocation in the ASP 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.

- 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")?

Regards,

Kilian

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

Panasonic R&D Center Germany GmbH

63225 Langen, Hessen, Germany

Reg: AG Offenbach (Hessen) HRB 33974

Managing Director: Thomas Micke

_______________________________________________

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: "Kilian Weniger" <[email-masked]>
Date: Thu, 22 Feb 2007 15:00:36 +0100

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: 
> draft-ietf-mip6-bootstrapping-integrated-02
> 
> Hi,  Kilian Weniger. 
> 
> 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.
> 
> 
> 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.

> 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

ok. My comment was that this should be documented (i.e., DHCP server
must reply with 0-lengh option in this case)

> as described in 15.4 of [RFC 3315]. 

ok.

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

>   "Multiple sub-options may exist in a Home Network Information option
> 
>    to carry more than one home information." (in section 3.3.1)
> 
> 

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
> 
> "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."
> 
>  
> 
> 
> Some other comments: 
>

---

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 23 Feb 2007 11:59:41 +0100

Hi Kuntal, Heejin, 
 
I have another comments wrt draft-ietf-mip6-bootstrapping-integrated-02
and draft-ietf-mip6-hiopt-02.txt: it seems service-based HA address
assignment is currently not supported. What I mean is, for instance,
that in case the MN wants to use DS-MIPv6 HA service, the network is
able to allocate a different HA to the MN than in case the MN wants to
use MIPv6 (RFC3775) HA service. 

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
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.
 
What do you think?
 
Cheers,
 
Kilian