Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13

From: Heejin Jang <[email-masked]>
Date: Wed, 16 Apr 2008 10:04:22 +0000 (GMT)

See below. 

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, April 16, 2008 6:50 PM
> To: Premec, Domagoj
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13
> 
> 
> > In deployments where the per-MN prefix model is used, 
> letting the MN know the home prefix is equal to assigning the 
> address to the MN. I'm not clear if DHAAD works with per-MN 
> prefix model. I thought that the main purpose of the home 
> network prefix is the same as the MIP6_HOME_PREFIX attribute 
> from RFC 5026. For DHAAD, the better way might be to include 
> prefix length in the Home agent address option, and if the 
> bits after the prefix length are zero, the MN should run 
> DHAAD. In this way the MN could be told to run DHAAD with one 
> prefix and use another prefix for its home address configuration. 
> >   
> 
> Clearly we had different ideas about the use of the prefix in 
> hiopt. But I think it is intended for the use of DHAAD. See 
> paragraph 1 in Section 1.

As shown in Fig in page 10 of v13, the sub-option with sub-opt-code 1 
carries home network prefix together with valid & preferred lifetimes.
This means that the prefix also will be used for IPv6 address autoconfiguration.
I meant that the provided prefix was both for DHAAD and for Autoconf.

If the provided prefix is intended only for the use of DHAAD and 
the auto-configuration is not allowed with it, it should be mentioned clearly
in the document..isn't it?

> I don't think this draft should be extended to deal with the 
> home address configuration (be it per-mn prefix or individual 
> addresses).
> 
> Jari
> 
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Apr 2008 13:26:12 +0300

Heejin,

> in the document..isn't it?
I agree that this should be made clear in the document.

But I'm also getting the sense that we're piling on many things into
this document (including late changes), and it does not make me feel good.

I tried to trace which caused us to insert the lifetimes into the
document in version 11, but was unable to find it. Perhaps someone
complained about the inability to see prefix length (version 10 had that
problem)?

In any case, I really do not want this document to extend itself into
address configuration. You do not have the explanations or mechanisms in
the document to do that. For instance, how would it work with security,
i.e., avoiding grabbing someone else's address? Perhaps more to the
point, we have already stretched our ability to make changes in late
reviews, and we are close to sending it back to the WG.

I would suggest stating that the prefix information is for DHAAD only,
or alternatively removing the entire concept of sending prefix information.

Jari

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 17 Apr 2008 00:02:01 +0200

Jari,

> I would suggest stating that the prefix information is for 
> DHAAD only, or alternatively removing the entire concept of 
> sending prefix information.

I'm a bit worried about restricting the usage of the home prefix acquired via hiopt only to DHAAD. If we do that, we end up with two categories of home network prefixes: one that is allowed to be used only for DHAAD and the other one which is RFC 3775 conformant and is good for DHAAD, home link detection and address configuration. I don't think it should matter how the MN obtained the home link prefix. Once it gets it, it should be able to use it as per RFC 3775, without additional restrictions. 

Maybe the Home network prefix option should be removed from the draft and instead use the Home agent address option with IID bits set to zero to indicate DHAAD. This seems like a cleaner approach to me.

Having said that, I don't want to delay the hiopt draft, and I'm fine with progressing the draft as per your comments.

domagoj 

> Sent: 16. travanj 2008 12:26
> To: [email-masked]
> Cc: Premec, Domagoj; [email-masked]
> > If the provided prefix is intended only for the use of 
> DHAAD and the 
> > auto-configuration is not allowed with it, it should be mentioned 
> > clearly in the document..isn't it?
> >   
> But I'm also getting the sense that we're piling on many 
> things into this document (including late changes), and it 
> does not make me feel good.
> 
> I tried to trace which caused us to insert the lifetimes into 
> the document in version 11, but was unable to find it. 
> Perhaps someone complained about the inability to see prefix 
> length (version 10 had that problem)?
> 
> In any case, I really do not want this document to extend 
> itself into address configuration. You do not have the 
> explanations or mechanisms in the document to do that. For 
> instance, how would it work with security, i.e., avoiding 
> grabbing someone else's address? Perhaps more to the point, 
> we have already stretched our ability to make changes in late 
> I would suggest stating that the prefix information is for 
> DHAAD only, or alternatively removing the entire concept of 
> sending prefix information.
> 
> Jari
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Apr 2008 11:25:26 +0300

I am now happy with -14. I would like at least a few acknowledgments
from the WG members that they too are happy.

Jari

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 17 Apr 2008 09:49:36 +0100

I think the draft is generally OK.

Given the discussion we just had, however, the draft does not describe
at all what the MN is supposed to do with the information received. If
there are restrictions in terms of what the MN is supposed to do e.g.,
can not create an address out of the HNP, then that should be
indicated. I have to admit though that I am not sure why such
restrictions would be necessary, so being silent on the issue is OK
with me.

One more thing. Do you think that the relationship between the HA
information received and the link on which the MN is attached is
always clear? Would it be useful to say something about detecting
whether the HA information returned corresponds to an HA "on-link" wrt
to the requesting MN? e.g., the MN can compare the HNP received from
DHCP with the prefixes in the RA received on link, or instead an
explicit indication maybe included in the DHCP message when that is
the case..
Note that the MN may request for HA info of a specific MSP without
realizing that it is already connected to it.

Thanks
George

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Apr 2008 12:16:08 +0300

George,

> If

Section 3.3 does say that the prefix info is for dynamic discovery only.
Are you missing some other specific information?

> realizing that it is already connected to it.

Having DHCP indicate too much of what the mobile node should do with the
information would probably lead into problems. Mobile nodes have to be
able to deal with these things, with or without discovery, because they
can have multiple interfaces.

(I wouldn't mind if some additional clarifying text were added because
of the above.)

Jari

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 17 Apr 2008 10:20:58 +0100

OK, I earlier missed the text in section 3.3.
Thanks
George

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 17 Apr 2008 11:51:19 +0200

Jari, George,

> (I wouldn't mind if some additional clarifying text were 
> added because of the above.)

Would the following change be acceptable:

Old text:
Note that the provided prefix information MUST be used for
   the dynamic home agent discovery only. 

New text:
Note that the provided prefix information MUST be used only for
   the dynamic home agent discovery and home link detection.

domagoj

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jari Arkko
> Sent: 17. travanj 2008 11:16
> To: George Tsirtsis
> Cc: [email-masked]
> Having DHCP indicate too much of what the mobile node should 
> do with the information would probably lead into problems. 
> Mobile nodes have to be able to deal with these things, with 
> or without discovery, because they can have multiple interfaces.
> 
> (I wouldn't mind if some additional clarifying text were 
> added because of the above.)
> 
> Jari
> 
>

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 17 Apr 2008 11:04:54 +0100

Sorry, I was not going to say anything but the truth is that I do not
like this MUST statement. I would rephrase with something like this:

"The prefix information is provided so that the mobile node can
perform dynamic home agent discovery as defined in RFC3775. The
information may also be used to allow the mobile node to determine
whether the home agent information received via DHCPv6 corresponds to
a home agent on-link or not."

Regards
George

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Apr 2008 13:07:30 +0300

I like this text...

Jari

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 17 Apr 2008 12:52:35 +0200

That's fine by me, too...
domagoj

> Sent: 17. travanj 2008 12:07
> To: George Tsirtsis
> >>  > (I wouldn't mind if some additional clarifying text 
> were  > added 
> >> because of the above.)
> >>
> >>  > From: [email-masked] 
> [mailto:[email-masked]] On  > 
> >> Behalf Of Jari Arkko
> >>
> >>     
> >>  > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13  >
> >>
> >>
> >>     
> >>> George,
> >>>       
> >>  >
> >>  > > If

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 18 Apr 2008 15:50:30 +0300

> explicit indication maybe included in the DHCP message when that is

This requires the DHCP server to be aware of the prefix(es) advertised on the access link. And it may not be.

I think it is best if we leave that to the MN to figure out, as usual.

Alper

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Apr 2008 10:16:38 +0300

The last edits are in -15 now. Any additional people who want to comment
on this before its approved?

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 21 Apr 2008 11:33:32 +0200

Jari Arkko wrote:
> The last edits are in -15 now. Any additional people who want to 
> comment on this before its approved?

Hi Jari,

I am not familiar with the advancement of this document and the recent
discussion.

I have just quickly skimmed through it.

I am surprised by the intention to pursue the document and get it
approved.  Because I find a few incoherencies.  It may be I'm
not enough familiar with the document, if so my message can be discarded.

For example:
> 3.  DHCP options for HA Dynamic Discovery
> 
> This section introduces new DHCP options and their sub-options which 
> are used for dynamic discovery of the home agent's IPv6 address, IPv6
>  home network prefix,

So the home network prefix is discovered, presumably by MN.

> 3.1.  Home Network Information Option
> 
> This option is proposed to allow the exchange of home network 
> information between the mobile node (DHCP client) and the DHCP 
> server.  It is used to indicate the target home network requested by 
> the mobile node to the DHCP server in the Information-request 
> message.  In the Reply message, it conveys the home network 
> information assigned by the DHCP server to the mobile node.

The MN indicates the home network information to DHCP Server, and then
the DHCP Server indicates back to MN the home network information.  Is
this information the same?  Can it change?

If the MN knows the home network information then why does it need the
DHCP Server to tell it back the home network information?

Is the home network prefix part of the home network information?

> 4.3.  DHCP Server Behavior
> 
> When the server receives a Relay-forward message, it may include the 
> MIP6 Relay Agent option in case there was home information available 
> for the mobile node at the relay.

DHCP Server includes the MIP6 Relay Agent option into what?

Overall comments about some paragraphs:
> New DHCP options are defined which allow a mobile node to request the
>  home agent IP address, FQDN, or home network prefix and obtain it 
> via the DHCP response.

If this is a MN, then it could be a MR, and MR may need to learn Mobile
Network Prefixes.  Is it necessary to learn Mobile Network Prefixes as
well?  Just a question.

> A mobile node can indicate its home network identity when roaming to 
> a visited network in order to obtain the MIP6 bootstrap parameters 
> from the home network.  As an example, the visited network may 
> determine the home network of the mobile node based on the realm 
> portion of the NAI (Network Access Identifier) [RFC4282] used in 
> access authentication.

This is not a good example, it is not a good idea to decide the identity
of a subnet based on the realm part of NAI.  There is no relationship
about domain names and subnet addresses, and there shouldn't be any.  If
one needs to identify a subnet then it's by its IP subnet address, not
by its fqdn (there's no fqdn-subnet relationship).

I haven't read further.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Tue, 29 Apr 2008 22:53:13 -0700

Hi Jari, Heejin,

Its been a while since I looked at this document. A few minor comments.

The IANA registry for the sub-opt-code in the Home Network Information
option and the MIP6 Relay agent option should be relaxed to "Standards
Action or IESG approval". It would be good if the sub-opt-code can be
extended to carry additional pieces of information using Experimental
or Informational RFCs in the future. Mentioning "Standards Action"
means the sub-opt-code can only be extended by Standards Track RFCs.
This would require a minor change in the IANA considerations section.

I think a new registry should be created for the Id-type field in the
Home Network Information option (section 3.1). This is missing in the
IANA considerations section. Another minor comment related to this.
The value '0' should be used to indicate that the MN has no
preference, instead of the value '2' being used for no preference and
'0' used for visited domain home agent information. That seems more
conventional. But if this needs too many changes in the document, don'
t bother.

Finally, the introduction needs to be slightly re-written to say that
the main goal of this document is to deliver the  home agent
information to the mobile node using stateless DHCPv6. It currently
seems to say that the mail goal is to deliver a prefix so that the
mobile node can run DHAAD using that prefix. I don't remember if the
introduction always used to say this or if it was changed recently.

The document otherwise looks fine. Ready for approval by the IESG. :)

Vijay