Gerardo Giaretta | 1 May 11:30 2006
Picon

Re: DHCP options (was Re: Questions on draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt)

Alexandru Petrescu <alexandru.petrescu <at> motorola.com> wrote:

> It's still uncommon to see a document titled "MIPv6 bootsrapping" in the
> MIP6 WG only with DHCP messages modified, no MIP6 messaging, no MIP6
> data structure, no keyword "binding" present, no CoA and only one
> occurence of "home address" (the one to be boot-strapped).  Maybe the
> title should be "DHCPv6-based MIPv6 bootstrapping for integrated scenario"?
>

Current title is already DHCPv6-based since it is "MIP6-bootstrapping
via DHCPv6 for the Integrated Scenario". I don't see any big
difference in what you are proposing.

--Gerardo

> Alex
>
> _______________________________________________
> Mip6 mailing list
> Mip6 <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mip6
>
Gerardo Giaretta | 1 May 11:38 2006
Picon

Re: How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)?

Hi Alex and Kuntal,

one comment below...

> > If operator considers storing 3 fqdns in each phone as not minimal,
> what
> > protocol would operator use to store each location's HA address in the
> > DNS?  And how would MN know to query the DNS for a specific location
> HA
> > when all it has is just one fqdn?
> >
> [KC>] Normally, allocation of the most optimum home agent based on the
> MN's point of attachment is done in the network. I think your question
> is a valid one, i.e. how does the operator do that using DNS. May be
> some clarification is required on this (if not there already).
>

Currently this is not possible using the solution defined for split
scenario. In this draft, only HA discovery is possible and this is not
possible to achieve a "location-based" HA assignment. Note that this
is also a consequence of split scenario definition: there is no link
between the location of the MN (i.e. ASP) and the MSP.

IMO, this limitation is well covered in the draft, also discussing
load balancing. But, please any suggestion on how to improve the
document is welcome.

I think HA assignment is much more useful in integrated scenario; this
is why the DT chose DHCP in that scenario.

(Continue reading)

Francis Dupont | 1 May 18:16 2006
Picon

Re: WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt

 In your previous mail you wrote:

   => Ok. So at least there is one agreement here, that is, for the 
   "MIPv6 application" transport mode makes sense since the communication
   is between MN and HA.

=> yes, transport mode is this case is the best solution, this is why
it has been *the* solution before the tunnel all mode proposal.

   Also, there is no double tunneling since there is 
   only one header in this case and the HAO.

=> note that the HAO can be considered as a degenerated tunnel.

   There would be unnecessary
   tunnelling IMO in tunnel mode for the BU or MPD.

=> the tunnel all mode is just full tunnel in place of degenerated tunnel,
something less bad than double tunnel...

Regards   

Francis.Dupont <at> point6.net
Wei Ye | 1 May 19:09 2006
Picon

CFP: ACM Workshop on Underwater Networks (WUWNet 2006)

Our Apologies if you have received multiple copies of the CFP.

Volkan Rodoplu and Wei Ye
WUWNet 2006 Publicity Co-Chairs

-----------------------------------------------------
      The First ACM International Workshop on
         UnderWater Networks (WUWNet 2006)
           http://wuwnet.engr.uconn.edu/

        In conjunction with ACM MobiCom 2006
                 September 29, 2006
           Los Angeles, California, USA
            Sponsored by ACM SIGMOBILE
-----------------------------------------------------

Overview & Scope  
****************

The oceans cover 71% of the earth's surface and represent 
one of the least explored frontiers, yet the oceans are 
integral to climate regulation, nutrient production, oil 
retrieval and transportation. As such, there is significant 
interest in monitoring aquatic environments for scientific, 
environmental, commercial, safety, and military reasons. 
While there is a need for highly precise, real-time, fine 
grained spatio-temporal sampling of the ocean environment, 
current methods such as remote telemetry and sequential 
local sensing cannot satisfy current needs, let alone 
future needs. The notion of an underwater network is 
(Continue reading)

Soliman, Hesham | 1 May 20:19 2006

RE: WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt


 >    Also, there is no double tunneling since there is 
 >    only one header in this case and the HAO.
 > 
 > => note that the HAO can be considered as a degenerated tunnel.

=> Sure.

 > 
 >    There would be unnecessary
 >    tunnelling IMO in tunnel mode for the BU or MPD.
 >    
 > => the tunnel all mode is just full tunnel in place of 
 > degenerated tunnel,
 > something less bad than double tunnel...

=> But we don't have a double tunnel today. So no need
for the "less bad" either. 

Hesham

 >    
 > Regards   
 >    
 > Francis.Dupont <at> point6.net
 > 
Vijay Devarapalli | 1 May 23:57 2006

Re: FW: DISCUSS and COMMENT: draft-ietf-mip6-bootstrap-ps

Gerardo Giaretta wrote:
> Hi Sam,
> 
> thanks for the comments and sorry for very late answers.
> 
> Concerning the EAP issue, I think that both solutions that are under
> definition in the WG does not follow the directions you mentioned.
> After your and others' comments (also during ICOS BOF and HOAKEY BOF)
> the WG has been producing solutions where network access
> authentication and mobility service authentication are considered
> fully separated. It seems to me that this problem statement does not
> suggest this kind of solutions. Please let me know if you think some
> clarifying text needs to be added to this problem statement.
> 
> Concerning rfc4285, the WG is currently not working on a solutions for
> bootstrapping rfc4285 SAs. I'm OK with removing all references to
> rfc4285. Is this your suggestion?

couple of contexts where RFC 4285 is mentioned are
okay. RFC 4285 is mentioned as a mechanism for
securing the BU. thats is fine. we could say it
exists, but this problem statement does not address
4285 bootstrapping. completely ignoring it would
be a bad idea.

Vijay

> 
>> Comment:
>> The claim in section 5.2.1 that use of certificates would require
(Continue reading)

Gerardo Giaretta | 2 May 10:17 2006
Picon

Re: FW: DISCUSS and COMMENT: draft-ietf-mip6-bootstrap-ps

Hi Sam,

sorry for that. It's my fault.

Find the email below.

--Gerardo

On 5/2/06, Sam Hartman <hartmans-ietf <at> mit.edu> wrote:
> Hi.  I don't seem to have the original mail to which this is a reply.
>
>

--------------------------------------------------------------

Hi Sam,

thanks for the comments and sorry for very late answers.

Concerning the EAP issue, I think that both solutions that are under
definition in the WG does not follow the directions you mentioned.
After your and others' comments (also during ICOS BOF and HOAKEY BOF)
the WG has been producing solutions where network access
authentication and mobility service authentication are considered
fully separated. It seems to me that this problem statement does not
suggest this kind of solutions. Please let me know if you think some
clarifying text needs to be added to this problem statement.

Concerning rfc4285, the WG is currently not working on a solutions for
bootstrapping rfc4285 SAs. I'm OK with removing all references to
(Continue reading)

Alexandru Petrescu | 2 May 14:01 2006

Re: How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)?

Gerardo Giaretta wrote:
> Hi Alex and Kuntal,
> 
> one comment below...
> 
>>> If operator considers storing 3 fqdns in each phone as not 
>>> minimal,
>> what
>>> protocol would operator use to store each location's HA address 
>>> in the DNS?  And how would MN know to query the DNS for a 
>>> specific location
>> HA
>>> when all it has is just one fqdn?
>>> 
>> [KC>] Normally, allocation of the most optimum home agent based on 
>> the MN's point of attachment is done in the network. I think your 
>> question is a valid one, i.e. how does the operator do that using 
>> DNS. May be some clarification is required on this (if not there 
>> already).
>> 
> 
> Currently this is not possible using the solution defined for split 
> scenario. In this draft, only HA discovery is possible and this is 
> not possible to achieve a "location-based" HA assignment. Note that 
> this is also a consequence of split scenario definition: there is no 
> link between the location of the MN (i.e. ASP) and the MSP.
> 
> IMO, this limitation is well covered in the draft, also discussing 
> load balancing. But, please any suggestion on how to improve the 
> document is welcome.
(Continue reading)

NJEDJOU Eric RD-RESA-REN | 2 May 14:01 2006

New Draft: Problem Statement for Global IP Mobility

Hi all,

There was an Ad-Hoc BOF on the right mobility management architecture for the Internet initiated by James Kempf during the Dallas Meeting. Global IP Mobility Management was discussed and a rough consensus was made to develop the discussions to make the problem better understood. Couple IAB members were present.

draft-njedjou-netlmm-globalmm-ps-00.txt was presented and received several comments. Following the Ad-Hoc, a new version has just been released

Name: draft-njedjou-netlmm-globalmm-ps-01.txt
Title: Problem Statement for Global IP Mobility
Authors: Eric Njedjou, Julien Riera, France Telecom

Abstract:
This document discusses the problem of global IP mobility management in a context where some mobile operators and service providers are looking for adequate solutions to the inter-system IP mobility problem. The document addresses the specific issue of moving between IP access domains that use different mobility management protocols and mechanisms. Indeed this type of movement would be an important subset of global IP mobility scenarios.

Version 01 is available at the following link:
http://perso.rd.francetelecom.fr/njedjou/draft-njedjou-netlmm-globalmm-ps-01.txt

Major changes from 00 include:

  • Re-defining global IP mobility
  • Adressing both single and multiple operators mobility scenarios (with both terminal and network centric schemes)
  • Adressing other comments received during the ad-hoc
  • Developing issues with existing global IP mobility solutions

Please provide comments


Best Regards
Eric Njedjou

_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop
Alexandru Petrescu | 2 May 14:02 2006

Re: DHCP options (was Re: Questions on draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt)

Gerardo Giaretta wrote:
> Alexandru Petrescu <alexandru.petrescu <at> motorola.com> wrote:
> 
>> It's still uncommon to see a document titled "MIPv6 bootsrapping" 
>> in the MIP6 WG only with DHCP messages modified, no MIP6 messaging,
>>  no MIP6 data structure, no keyword "binding" present, no CoA and 
>> only one occurence of "home address" (the one to be boot-strapped).
>>  Maybe the title should be "DHCPv6-based MIPv6 bootstrapping for 
>> integrated scenario"?
>> 
> 
> Current title is already DHCPv6-based since it is "MIP6-bootstrapping
>  via DHCPv6 for the Integrated Scenario". I don't see any big 
> difference in what you are proposing.

Ok.  We could argue endlessly about a title, but you seem to agree that
the draft is mainly about DHCP, me too.

Alex

Gmane