Prefix Delegation documents

Hello,

I'm wondering what is the current status of the Prefix Delegation  
documents for NEMO: one seems to be still active and is referenced by  
the NEMO charter page (draft-ietf-nemo-prefix-delegation) but the  
other WG document (draft-ietf-nemo-dhcpv6-pd) does not appear  
anymore. Is it still supported by the WG?

Regards,
--

-- 
Romain KUNTZ
kuntz <at> lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

Re: Prefix Delegation documents

Romain KUNTZ wrote:
> Hello,
> 
> I'm wondering what is the current status of the Prefix Delegation 
> documents for NEMO: one seems to be still active and is referenced by
>  the NEMO charter page (draft-ietf-nemo-prefix-delegation) but the 
> other WG document (draft-ietf-nemo-dhcpv6-pd) does not appear 
> anymore. Is it still supported by the WG?

I would like to second the question, thanks for the replies.

The work is mentioned in MEXT WG Charter "(B.3) Finish working group
documents that are currently in process, and submit for RFC. This
includes prefix delegation protocol mechanism for network mobility, and
a MIB for NEMO Basic Support."

(Personally, I've made up my mind.  If until now I supported both, I
think only the one doing DHCPv6 Prefix Delegation makes sense.

The issue with the one doing prefix allocation with BU/BAck is that a
similar thing is proposed in NETLMM WG: put ::/0 in PBU and receive
prefix in PBAck.

These two things (MNP in BAck and HNP in PBAck) are practically the same
thing; but done with different encodings, with different assumptions and
  different technologies - an incoherency.

DHCPv6-PD can do that and much more, more advanced architectures are
supported, lifetimes, advanced configuration, and so on.  BEsides, there
are some implementations opensource.)

Re: Prefix Delegation documents

Re: Prefix Delegation documents

Behcet Sarikaya wrote:
> I agree with Alex. DHAAD extension proposed in NEMO DHCP PD draft is I 
> think a stretch and may probably be not needed.

Err?  Sorry, I'm happy you agree with me, but I think the NEMO DHCP PD 
draft doesn't propose DHAAD extensions...(?)

draft-ietf-nemo-prefix-delegation-02.txt proposes exensions to PBU/PBAck 
to request and receive a prefix.

The NEMODHCP PD draft that I've seen last time (Ralph+Pascal) and whose 
draft name I can't find doesn't propose DHAAD extensions either, it just 
pictures the roles of MR and of HA as Requestor and Delegator, (IIRC 
terminology), normal DHCP PD roles.  It didn't define new message 
formats/flags, IIRC.

Alex

> 
> Regards,
> 
> Behcet
> 
> ----- Original Message ----
> From: Alexandru Petrescu <alexandru.petrescu <at> gmail.com>
> To: Romain KUNTZ <kuntz <at> clarinet.u-strasbg.fr>
> Cc: nemo <at> ietf.org
> Sent: Monday, October 1, 2007 4:17:41 AM
> Subject: Re: [nemo] Prefix Delegation documents
> 
> Romain KUNTZ wrote:
>  > Hello,
>  >
>  > I'm wondering what is the current status of the Prefix Delegation
>  > documents for NEMO: one seems to be still active and is referenced by
>  >  the NEMO charter page (draft-ietf-nemo-prefix-delegation) but the
>  > other WG document (draft-ietf-nemo-dhcpv6-pd) does not appear
>  > anymore. Is it still supported by the WG?
> 
> I would like to second the question, thanks for the replies.
> 
> The work is mentioned in MEXT WG Charter "(B.3) Finish working group
> documents that are currently in process, and submit for RFC. This
> includes prefix delegation protocol mechanism for network mobility, and
> a MIB for NEMO Basic Support."
> 
> (Personally, I've made up my mind.  If until now I supported both, I
> think only the one doing DHCPv6 Prefix Delegation makes sense.
> 
> The issue with the one doing prefix allocation with BU/BAck is that a
> similar thing is proposed in NETLMM WG: put ::/0 in PBU and receive
> prefix in PBAck.
> 
> These two things (MNP in BAck and HNP in PBAck) are practically the same
> thing; but done with different encodings, with different assumptions and
>   different technologies - an incoherency.
> 
> DHCPv6-PD can do that and much more, more advanced architectures are
> supported, lifetimes, advanced configuration, and so on.  BEsides, there
> are some implementations opensource.)
> 
> Alex
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> 
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: Prefix Delegation documents

Hi Alex,

On 2007/10/01, at 23:34, Alexandru Petrescu wrote:
> Behcet Sarikaya wrote:
>> I agree with Alex. DHAAD extension proposed in NEMO DHCP PD draft  
>> is I think a stretch and may probably be not needed.
>
> Err?  Sorry, I'm happy you agree with me, but I think the NEMO DHCP  
> PD draft doesn't propose DHAAD extensions...(?)

draft-ietf-nemo-dhcpv6-pd-02 adds a new D flag to DHAAD in section 3.5.
And I agree with Behcet that this may not be useful, as the MIP6  
bootstrapping work does not rely on DHAAD to assign HA addresses. It  
could be interesting to integrate this work better in the MIP6  
bootstrapping effort.

Romain

>> ----- Original Message ----
>> From: Alexandru Petrescu <alexandru.petrescu <at> gmail.com>
>> To: Romain KUNTZ <kuntz <at> clarinet.u-strasbg.fr>
>> Cc: nemo <at> ietf.org
>> Sent: Monday, October 1, 2007 4:17:41 AM
>> Subject: Re: [nemo] Prefix Delegation documents
>> Romain KUNTZ wrote:
>>  > Hello,
>>  >
>>  > I'm wondering what is the current status of the Prefix Delegation
>>  > documents for NEMO: one seems to be still active and is  
>> referenced by
>>  >  the NEMO charter page (draft-ietf-nemo-prefix-delegation) but the
>>  > other WG document (draft-ietf-nemo-dhcpv6-pd) does not appear
>>  > anymore. Is it still supported by the WG?
>> I would like to second the question, thanks for the replies.
>> The work is mentioned in MEXT WG Charter "(B.3) Finish working group
>> documents that are currently in process, and submit for RFC. This
>> includes prefix delegation protocol mechanism for network  
>> mobility, and
>> a MIB for NEMO Basic Support."
>> (Personally, I've made up my mind.  If until now I supported both, I
>> think only the one doing DHCPv6 Prefix Delegation makes sense.
>> The issue with the one doing prefix allocation with BU/BAck is that a
>> similar thing is proposed in NETLMM WG: put ::/0 in PBU and receive
>> prefix in PBAck.
>> These two things (MNP in BAck and HNP in PBAck) are practically  
>> the same
>> thing; but done with different encodings, with different  
>> assumptions and
>>   different technologies - an incoherency.
>> DHCPv6-PD can do that and much more, more advanced architectures are
>> supported, lifetimes, advanced configuration, and so on.  BEsides,  
>> there
>> are some implementations opensource.)
>> Alex
>> _____________________________________________________________________ 
>> _
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> _____________________________________________________________________ 
>> _
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email  
> ______________________________________________________________________
>

Re: [Mip6] DSMIPv6 current status

Hi Hesham,

Thanks for the update. Can we expect a revised I-D with all the LC comments
addressed sometime in the next week or so? Assuming we can get the IKE issue
dealt with as well.

-Raj

On 9/27/07 10:49 PM, "ext Hesham Soliman" <Hesham <at> elevatemobile.com> wrote:

> Folks, 
> 
> Just a quick progress on the draft. There is currently one issue being
> discussed, which is the use of IKE in DSMIPv6. This was raised by Christian
> last week. Other than that, all the comments are pretty straight forward.
> 
> I'll send an update with one or more proposals soon.
> 
> Hesham
> 
> 
> 
> _______________________________________________
> Mip6 mailing list
> Mip6 <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mip6

RE: [Mip6] DSMIPv6 current status

Hi Raj, 

Yes, all other comments are included. It would be great if we can handle the
IKE issue soon, I'm trying to come up with solutions, I encourage others to
do the same. 

Hesham 

 > -----Original Message-----
 > From: Basavaraj Patil [mailto:basavaraj.patil <at> nsn.com] 
 > Sent: Saturday, October 06, 2007 6:27 AM
 > To: ext Hesham Soliman; mip6 <at> ietf.org; nemo <at> ietf.org
 > Subject: Re: [Mip6] DSMIPv6 current status
 > 
 > 
 > Hi Hesham,
 > 
 > Thanks for the update. Can we expect a revised I-D with all 
 > the LC comments
 > addressed sometime in the next week or so? Assuming we can 
 > get the IKE issue
 > dealt with as well.
 > 
 > -Raj
 > 
 > 
 > On 9/27/07 10:49 PM, "ext Hesham Soliman" 
 > <Hesham <at> elevatemobile.com> wrote:
 > 
 > > Folks, 
 > > 
 > > Just a quick progress on the draft. There is currently one 
 > issue being
 > > discussed, which is the use of IKE in DSMIPv6. This was 
 > raised by Christian
 > > last week. Other than that, all the comments are pretty 
 > straight forward.
 > > 
 > > I'll send an update with one or more proposals soon.
 > > 
 > > Hesham
 > > 
 > > 
 > > 
 > > _______________________________________________
 > > Mip6 mailing list
 > > Mip6 <at> ietf.org
 > > https://www1.ietf.org/mailman/listinfo/mip6
 > 
 > 

RFC 4980 on Analysis of Multihoming in Network Mobility Support

A new Request for Comments is now available in online RFC libraries.

        
        RFC 4980

        Title:      Analysis of Multihoming in Network 
                    Mobility Support 
        Author:     C. Ng, T. Ernst,
                    E. Paik, M. Bagnulo
        Status:     Informational
        Date:       October 2007
        Mailbox:    chanwah.ng <at> sg.panasonic.com, 
                    thierry.ernst <at> inria.fr, 
                    euna <at> kt.co.kr,  marcelo <at> it.uc3m.es
        Pages:      39
        Characters: 88572
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-nemo-multihoming-issues-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4980.txt

This document is an analysis of multihoming in the context of network
mobility (NEMO) in IPv6.  As there are many situations in which
mobile networks may be multihomed, a taxonomy is proposed to classify
the possible configurations.  The possible deployment scenarios of
multihomed mobile networks are described together with the associated
issues when network mobility is supported by RFC 3963 (NEMO Basic
Support).  Recommendations are offered on how to address these
issues.  This memo provides information for the Internet community.

This document is a product of the Network Mobility
Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community. 
It does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 

help: ways_to_get_rfcs. For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

DSMIPv6 and IKE

Folks, 

We had a discussion in a smaller group about this problem, which was
initially raised in one of Christain Kaas-Petersen's emails. The problem of
integrating IKE and DSMIPv6 is fairly tricky because of the fact that each
mechanism has its own NAT traversal method. 

So after discussing this with a couple of people I'll present three possible
ways of solving this issue. Thanks to Pasi for writing up about 7 different
options, Raj and Vidya for their input. 

Problem description:
--------------------

DSMIPv6 obviously needs to provide a NAT traversal mechanism. The detection
of a NAT relies on the BU/BA message exchange. If a NAT were detected, UDP
encapsulation follows. Now, the problem is, for the BU to be sent, we need
to run IKE, which has it's own ports/traversal mechanisms. 
So if we run IKE and send the BU over the IKE tunnel, the HA will not know
what port number/address to send the MN's traffic to. Note that the MN
cannot include the port number 
and address because clearly it doesn't know what those values are since
they're allocated by the NAT. 

If we send the BU over port 4500 then we need to send another message (not
secured) using DSMIPv6 port to the HA with every handover. I think this is
unacceptable because we basically need to send two messages for handover and
one of them has zero security. So the idea of using two ports (4500 and
DSMIPv6 port) doesn't really work. 
And we don't have a way today of sending the BU separately over DSMIPv6
port. I.e., what's described in the draft is not possible today. 

Solution space:
---------------

There are basically three ideas that were discussed in a small group:

1. Allow DSMIPv6 to look like a virtual link for IKE. Hence, IKE will simply
run over IPv6 and will not be aware of IPv4 at all. 

2. Run IKE over port 4500, but add "DSMIPV6_UDP_ENCAPSULATION" notification
when negotiating ESP SAs

3. Add a new message in MIP6 that creates a port mapping in the NAT. The BU
is still sent over 4500 and the new message is either insecure or (a long
shot) secured by a crypto token exchanged in the BU/BA. 

Message format for solution 1:
------------------------------

IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT)
IPv6 header (src=V6HOA, dst=HAADDR)
ESP header
Mobility header
BU [IPv4 HAO]
IPv4 CoA option

And IKE messages would look like:

IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT)
IPv6 header (src=V6HOA, dst=HAADDR)
UDP header (src=500, dst=500)
IKE message...

With this solution, the HA would essentially store the route information for
the IKE messages (the port and address received in the outer header) and use
them as dst address and port in the respose message. This information must
not be stored permanently in the HA, only to respond to the messages.
Obviously, if the IKE daemon in the HA silents ignores an IKE message then
this information would have to be removed, so there would need to be a
timeout or inter-process communication in the implementation. For the MN
it's a lot simpler, source address selection for the IKE implementation
would always return the V6HoA. 

Message format for solution 2:
------------------------------

IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT)
ESP header
IPv6 header (src=V6HOA, dst=HAADDR)
Mobility header
BU [IPv4 HAO]
IPv4 CoA option

In this option we run IKE over port 4500, but add
"DSMIPV6_UDP_ENCAPSULATION"
notification when negotiating ESP SAs. Those ESP SAs would use src/dst
port DSMIPv6-PORT. 

But we would still have to rely on IKE to either implicitly or explicitly
update its ports and addresses whenever the mobile node moves. 

Option 3:
---------

Basically we didn't work out message formats for this option. I think we all
agreed that it's a long shot and, while interesting, it essentially involves
designing a new method for MIPv6 security, which is not the best or fastest
way to handle this problem. 

Conclusions:

IMO each one of those solutions has it's own flaws. There is no clean and
perfect solution above, but there are no clean solutions with NATs
unfortunately. I'm personally inclined to go with alternative 1 but let's
hear some opinions on this. Time is critical because there is a lot of
pressure to move this draft to the IESG. Please send comments. 

Thanks, 
Hesham

Re: [Mip6] DSMIPv6 and IKE

Hi Hesham, all,

On 2007-10-17 15:59 Hesham Soliman said the following:
> Folks, 
> 
> We had a discussion in a smaller group about this problem, which was
> initially raised in one of Christain Kaas-Petersen's emails...

...
> There are basically three ideas that were discussed in a small group:
> 
> 1. Allow DSMIPv6 to look like a virtual link for IKE. Hence, IKE will simply
> run over IPv6 and will not be aware of IPv4 at all. ...

...
> IMO each one of those solutions has it's own flaws. There is no clean and
> perfect solution above, but there are no clean solutions with NATs
> unfortunately. I'm personally inclined to go with alternative 1 but let's
> hear some opinions on this. Time is critical because there is a lot of
> pressure to move this draft to the IESG. Please send comments. 

I concur.  Alternative 1 would be my preference, too.

	Henrik