Re: [MIPSHOP-MIH-DT] draft-ietf-mipshop-mstp-solution-02.txt

["Telemaco Melia (tmelia)" <[e-mail]>]

Hi Vijay,

The question was more about if a mip6-integrated-scenario alike solution
using DHCPv4 has ever been discussed (including related use cases).
I quote here some text from Gabor in a reply to Kevin:
"I-D.bajko-mos-dhcp-options defines extensions to discover MoS only in
visited network for the dhcpv4 case. If the MN is using MIPv4, then the
bootstrapping can happen using AAA. If the MN is only using dhcpv4, then
according to the current status of the work, it can only discover an MoS
in the visited network. To support MoS discovery in the home network
while roaming, using dhcpv4, we would need additional work (define a few
additional dhcpv4 extensions). The question is, do we have or foresee a
deployment scenario which would require this? "

tele
 

-----Original Message-----
From: Vijay Devarapalli [mailto:[e-mail]] 
Sent: Friday, April 11, 2008 5:24 PM
To: Telemaco Melia (tmelia)
Cc: [e-mail]; [e-mail]
Subject: Re: [MIPSHOP-MIH-DT] draft-ietf-mipshop-mstp-solution-02.txt

Hi Tele,

I assume you are talking about the following paragraph.

>    This section assumes the use of IPv6 and DHCPv6 based mechanisms to
>    discover MoS services in home while the MN is in visited network.
If
>    similar functionalities are desired for IPv4 additional DHCPv4
>    extensions would be required.  Since use cases requiring these
>    extensions were not identified at the time of writing this
document,
>    they were excluded from the scope of the document.

A simple question. Why is IPv6 assumed? A MOS should be reachable when
its address is IPv4 or IPv6. The mobile node MUST be able to reach the
MOS server whether it is on an IPv4 or IPv6 access network. Correct?

What is the point of discovering the IPv6 address of the MOS, when the
mobile node is on an IPv4 access network? For Mobile
IPv6 bootstrapping mechanisms we assume that the mobile node needs to
discover the IPv4 address of the home agent when it is on an IPv4 access
network.

I must be missing something.

Vijay

Telemaco Melia (tmelia) wrote:
> Gabor, all,
>  
> I updated the text according to your suggestions (slightly modified 
> though). Doc is attached.
>  
> I have been spending some time checking what would be the required 
> changes to delete the remark added at the end of section 5.3.
> I would like to know what Vijay and Stefano think about the issue. Do 
> you see use cases requiring an update to the specs?
> If yes, please let us know as soon as possible so we can update all 
> the docs.
> If not then we can post version -02 and boost the discussion around 
> the adoption of new documents.
>  
> thanks
> tele
>  
> ----------------------------------------------------------------------
> --
> *From:* [e-mail] [mailto:[e-mail]]
> *Sent:* Thursday, April 10, 2008 12:15 AM
> *To:* Telemaco Melia (tmelia); [e-mail]
> *Subject:* RE: [MIPSHOP-MIH-DT] 
> draft-ietf-mipshop-mstp-solution-02.txt
> 
> Hi Tele,
>  
> to the comment in 5.2 lets add this note (after the previous 
> paragraph, ending ' ... DNS query')
>  
> 
> When the discovery of an MoS at the visited network, using the FQDN 
> returned in the reverse DNS query, is not successful, the MN MAY 
> attempt to remove portions from the left side of the FQDN and attempt 
> discovery again. The process MAY be repeated iteratively until a
successful discovery.
> 
> section 5.4:
> 
> modify this sentence: "If the  MN does not yet know the domain name of

> the network, learning it may
>    require more than one operation, as pre-configuration and DHCP
>    methods can not be used."
> 
> to: "If the  MN does not yet know the domain name of the network, 
> learning it may
>    require more than one operation, as  DHCP based discovery can not 
> be used and pre-configuration is not a feasible solution in case of an

> arbitrary remote network."
> 
> regarding the comment in 5.3: rfc4004 does not specify how the 
> discovery of an MoS could be done, it doesn't have a general purpose
container.
> One would need to define an extension to 4004 to be able to fetch eg a

> preconfigured MoS address from the AAA (it could even be part of 
> draft-stupar-mos-diameter-options). I would reformulate it to this:
> 
> This section assumes the use of IPv6 or MIPv6 and DHCPv6 based
>    mechanisms to discover MoS services in home while the MN is in
>    visited network. If similar functionalities are desired for IPv4 or
> MIPv4 and DHCPv4, additional AAA and DHCPv4 extensions would be 
> required. Since use cases requiring these extensions were not 
> identified at  the time of writing this document, they were excluded 
> from the scope of the document.
> 
> Vijay has left azairnet and his email address doesn't work any longer.

> An implicit question is if he will continue with his mipshop chair 
> tasks or not. It may have an impact on these documents.
> 
> - Gabor
> 
> 
>
------------------------------------------------------------------------
>     *From:* [e-mail]
>     [mailto:[e-mail]] *On Behalf Of *ext
Telemaco
>     Melia (tmelia)
>     *Sent:* Monday, April 07, 2008 9:48 AM
>     *To:* [e-mail]
>     *Subject:* [MIPSHOP-MIH-DT] 
> draft-ietf-mipshop-mstp-solution-02.txt
> 
>     Hi guys,
>      
>     Here is the revised version. All editorial comments have been
>     hopefully digested.
>     There are only a couple of open points, you can track them looking
>     for [COMMENT].
>     One is for Gabor, the second one is about the use of DHCPv4 to
>     discover MoS in visited networks only. Your opinion is welcome.
>      
>     Please go through the document and let me know anything else
missing.
>      
>     Thanks
>     Tele
> 
> 
> ----------------------------------------------------------------------
> --
> 
> _______________________________________________
> MIPSHOP-MIH-DT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mipshop-mih-dt

_______________________________________________
MIPSHOP-MIH-DT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mipshop-mih-dt