Subject: [Mip6] Re: FW: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt

From: Jari Arkko <[email-masked]>
Date: Fri, 16 Feb 2007 00:47:09 +0200

Hi George,

Sorry for the delay in the answer. Too much going on elsewhere...

I have reviewed your new version and the answer below.
I'm not completely happy with the new text, but I would nevertheless
like to take the draft forward. I do have three suggested
changes below, which I have tentatively added as RFC Editor
notes in the ID tracker. I'm putting the draft up for IESG
evaluation and unless you object, the edits will be considered
if and when the draft is approved. Or, if there are other
reasons to edit the draft after the evaluation, you can adopt
them for the next revision.

Inline:
>   
>>> Is this true under all circumstances? For instance,
>>> is it true if one uses RFC 4285 or EAP for Mobile IPv6
>>> authentication?
>>>
>>> Depending on the answer, please reword
>>> and add the necessary explanations.
>>>     
>>>       
>> GT> I believe that, assuming nothing is changed, what the draft says
>>     
> is
>   
>> accurate since typically applications/protocols can not share keys
>> unless security is implemented at a lower layer than that of the
>> application/protocol. Still, I will add something to indicate that for
>> some of the mechanisms listed and with further work, it might be
>> possible to optimize operations.
>>   
>>     
> Do you have text? We are not talking about typical applications,
> we are talking about a very specific case. And there are many
> applications that can share the same credentials through, say,
> AAA.
>
> GT> Here is what I have. 
> " In addition, deploying both protocols will require duplication of
>    security credentials on mobile nodes and home agents.  This includes,
>    IPsec security associations, keying material, and new authentication
>    protocols for Mobile IPv6, in addition to the security credentials
>    and associations required by Mobile IPv4.  Depending on the security
>    mechanisms used and with some further work it might be possible to
>    optimize some of these processes.  Assuming nothing else changes,
>    however, such duplication is again significant with no gain to the
>    operator or the mobile node."
>   
Mumble. Perhaps "... possible to rely on one set of
set common credentials. Assuming ..."

But I wish the draft could say something specific
about the actual possibility to do this. For instance,
the draft could argue the neither RFC 4285 or EAP
can support Mobile IPv4 authentication (if that is the
case).

>   
>>>> 3.1. Implementation burdens
>>>>
>>>>    As mentioned above, a node that is IPv4 and IPv6 capable mustalso
>>>>         
> be
>   
>>>>       
>>>>    MIPv4 and MIPv6 capable to roam within the Internet. Clearly this
>>>>    will add implementation efforts, which, we argue, are not
>>>>         
> necessary.
>   
>>>>       
>>>>    In addition to the implementation efforts, some vendors may not
>>>>    support both protocols in either mobile nodes or home agents.
>>>>    Although this is more of a commercial issue, it does affect the
>>>>    large-scale deployment of mobile devices on the Internet.
>>>>
>>>>       
>>>>         
>>> I'm not sure this section reflects the complete
>>> picture. In a situation where host vendors
>>> are independent of those who deploy the
>>> mobility infrastructure, for instance, its
>>> not clear that there is any reduction in
>>> implementation effort.
>>>
>>> Please reword for better balance.
>>>
>>>     
>>>       
>> GT> OK, I will clarify 
>>   
>>     
> Good. Again, I would like to see the text...
>
> GT> Here it is:
> " As mentioned above, a node that is IPv4 and IPv6 capable must also be
>    MIPv4 and MIPv6 capable to roam within the Internet.  Clearly this
>    increases the complexity of implementations for vendors that decide
>    to support both protocols.
>    Some vendors, however, may not support both protocols in either
>    mobile nodes or home agents.  Although this is more of a commercial
>    issue, it does affect the large-scale deployment of mobile devices on
>    the Internet."
>   
I don't think this reflects the issue that I had. Here's a
different wording:

   As mentioned above, a node that is IPv4 and IPv6 capable must also be
   MIPv4 and MIPv6 capable to roam within the Internet. The ability
   to employ both IP versions from one mobility protocol makes
   it possible to implement just that one protocol, assuming the
   protocol choice is known. However, in situations where the mobile
   node must be capable of working in any network it may still
   need two protocols.

>   
>>>> 3.0 Problem description
>>>>       
>>>>         
>>> I am missing an explanation of why various existing,
>>> non-mobility related transition mechanisms are insufficient
>>> for solving the issues listed in this document. I believe
>>> they are insufficient, but the document needs to explain
>>> why.
>>>
>>> Please add the explanation.
>>>     
>>>       
>> GT> It is a bit difficult to write general negative statements like
>> this. I will add a section on this and add something generic about the
>> fact that current transition mechanisms do not seem to deal with
>> mobility. 
>>   
>>     
> Ok. Text needed.
>
> GT> Here it is: 
> "4.5.  IPv4 to IPv6 Transition Mechanisms
>
>    The IETF has standardized a number of transition mechanisms to allow
>    networks and end nodes to gain IPv6 connectivity while the Internet
>    is migrating from IPv4 to IPv6.  A cursory examination of such
>    transition mechanisms indicates that none of them is designed to deal
>    with mobile nodes.  While some transition mechanisms can be combined
>    with Mobile IPv4 or Mobile IPv6, non of the known mechanisms have
>    been shown to assist with the issues described in this document."
>   
Hmm... maybe it is not a good idea to reveal that we've
only performed "a cursory examination" of the other
possible approaches :-)

Here's what I'd suggest:

   The IETF has standardized a number of transition mechanisms to allow
   networks and end nodes to gain IPv6 connectivity while the Internet
   is migrating from IPv4 to IPv6.  However, while some transition 
   mechanisms can be combined with Mobile IPv4 or Mobile IPv6, none 
   of the known mechanisms have been shown to assist with the issues
   described in this document.

Jari

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Feb 2007 11:34:04 +0100

> Hi George,
[...]
>    described in this document.

I'm sorry to interfere here late at a pre-submission stage.

Known mechanisms have been shown to assist with the issues described in
this document: 6to4 tunnel between MN and a Gateway, RAs over that
tunnel and HA separated from the gateway. Just 6to4, ND and Mobile IPv6,
no protocol modifications.

The experiment was described in a personal draft a few years ago, in the
NEMO context with a vehicular MR attaching to IPv6-WiFi and IPv4-GPRS.
The description was not using 6to4/MIP6 terms, it was targeted at
showing network mobility is possible.

I've not felt the need to document this 6to4/MIP6 behaviour because it
is very straightforward. When discussing the dsmipv6 protocol and
problem statement other WG members mentioned that this 6to4/MIP6 may be
possible.

NAT Traversal and MIP6 and 6to4 works ok too with _certain_ types of
NATs, tried that in lab.

MIP6 and MIP4-NAT Traversal works ok too, but in order to traverse more
special NATs some protocol enhancements to MIP4-NAT Traversal are
necessary. These enhancements have been implemented and tested routinely
in my lab. New message formats were designed. I copypaste that in the
postscriptum.

Again, I am not trying to interfere with the advancement of the problem
statement draft, just to say that alternatives to DS-MIPv6 exist live
and well. Being rejected by IETF doesn't mean they don't exist.

Alex

PS:
IPv4 NAT Traversal for IPv6 Mobile Nodes

HA is an IPv4 HA (implementing Mobile IPv4).  HA aka GW.

     MN                                    HA
      |  ---- Tunnel Request ------------> |
      |  <--- Tunnel Reply --------------- |
      |  ---- Tunnel "Acknowledgement" --> |
      ~           ...                      ~
      |  -----Tunnel "Keepalive" --------> |

No NAT Present

     MN                                    HA
      |  ---- Tunnel Request ------------> |
      |       IP src address               |
      |       Tentative UDP dst port number|
      |       Tentative MN Tunnel Address  |
      |                                    |
      |  <--- Tunnel Reply --------------- |
      |       Echoed Src Address           |
      |       Echoed Dst port number       |
      |       Tentative HA Tunnel Address  |
      |       Accepted TMTA, reply code 0  |
      |       TMTA
      |                                    |
      |  ---- Tunnel "Acknowledgement" --> |
      |       Accepted THTA                |
      |       THTA                         |
      |       Reply Code 2 (no NAT)        |

NAT Present

     MN                                    HA
      |  ---- Tunnel Request ------------> |
      |       IP src address               |
      |       Tentative UDP dst port number|
      |       Tentative MN Tunnel Address  |
      |                                    |
      |  <--- Tunnel Reply --------------- |
      |       Echoed Src Address           |
      |       Echoed Dst port number       |
      |       Tentative HA Tunnel Address  |
      |       Reply Code 0 "Accepted TMTA" |
      |       TMTA                         |
      |                                    |
      |  ---- Tunnel "Acknowledgement" --> |
      |       Connection ID                |
      |       Reply Code 0 "Accepted HA and port"
      |       THTA                         |
      |       DPN (destination port number)
      |                                    |
      |  -----Tunnel "Keepalive" --------> |
      |       Connection ID                |
      ~             ...                    ~
      |  -----Tunnel "Keepalive" --------> |
      |       Connection ID                |
      |                                    |

NAT Present, Dst Port Number Discovery

     MN                                    HA
      |  ---- Tunnel Request ------------> |
      |       IP src address               |
      |       Tentative UDP dst port number1
      |       Tentative MN Tunnel Address  |
      ~            ...                     ~
      |  ---- Tunnel Request ------------> |
      |       IP src address               |
      |       Tentative UDP dst port number2
      |       Tentative MN Tunnel Address  |
      |                                    |
      |  <--- Tunnel Reply --------------- |
      |       Echoed Src Address           |
      |       Echoed Dst port number       |
      |       Tentative HA Tunnel Address  |
      |       Reply Code 0 "Accepted MN and port"   |
      |       TMTA
      |                                    |
      |  ---- Tunnel "Acknowledgement" --> |
      |       Connection ID                |
      |       Reply Code 0 "Accepted HA and port"   |
      |       THTA
      |       DPN
      ~            ...                     ~
      |  -----Tunnel "Keepalive" --------> |
      |       Connection ID                |
      |                                    |

Auto-configuration of MN Tunnel Address

     MN                                    HA
      |  ---- Tunnel Request ------------> |
      |       IP src address               |
      |       Tentative UDP dst port number|
      |       Tentative MN Tunnel Address1 |
      |                                    |
      |  <--- Tunnel Reply --------------- |
      |       Echoed Src Address           |
      |       Echoed Dst port number       |
      |       Tentative HA Tunnel Address  |
      |       Reply Code 1 "Not Accepted MN"
      |       TMTA
      |                                    |
      |  ---- Tunnel Request ------------> |
      |       Tentative MN Tunnel Address2 |
      |       Sub-type 3 "Accepted HA, new MN"
      |       THTA
      |                                    |
      |  <--- Tunnel Reply --------------- |
      |       Reply Code 0 "Accepted MN"   |
      |       TMTA
      |                                    |
      |  ---- Tunnel "Acknowledgement" --> |
      |       Reply Code 0 "Accepted"      |
      |                                    |
      ~           ...                      ~
      |  -----Tunnel "Keepalive" --------> |
      |       Connection ID                |
      |                                    |

Auto-configuration of HA Tunnel Address

     MN                                    HA
      |  ---- Tunnel Request ------------> |
      |       IP src address               |
      |       Tentative UDP dst port number|
      |       Tentative MN Tunnel Address  |
      |                                    |
      |  <--- Tunnel Reply --------------- |
      |       Echoed Src Address           |
      |       Echoed Dst port number       |
      |       Tentative HA Tunnel Address  |
      |       Reply Code 0 "Accepted MN"   |
      |                                    |
      |  ---- Tunnel Request ------------> |
      |       Sub-type 4 "Not Accepted HA" |
      |                                    |
      |  <--- Tunnel Reply --------------- |
      |       Tentative HA Tunnel Address2 |
      |                                    |
      |  ---- Tunnel "Acknowledgement" --> |
      |       Connection ID                |
      |       Reply Code 0 "Accepted"      |
      |                                    |
      ~           ...                      ~
      |  -----Tunnel "Keepalive" --------> |
      |       Connection ID                |
      |                                    |

UDP Tunnel Request Extension, MN to HA

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     |    Sub-Type   |   Reserved 1  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |F|R| Reserved 2| Encapsulation |          Reserved 3           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Tentative MN Tunnel Address                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Sub-type:
               1 Discover NAT, port and propose address

    MN Tunnel Address:
                   suggests local IPv4 address that will be used as
                   local tunnel endpoint.

UDP Tunnel Reply Extension, HA to MN
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     |    Sub-Type   |  Reply Code   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |F|        Reserved             |     Keepalive Interval        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      HA Tunnel Address                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Echoed Source Address                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Echoed Dst Port Number       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type: 44

    Sub-type:
               1  Echoed src addr/port and propose address

    Reply Code:
                0  Accepted MN Tunnel Address
                1  Not Accepted MN Tunnel Address

UDP Tunnel Reply Extension, "Acknowledgement", MN to HA

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     |    Sub-Type   |  Reply Code   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |F|        Reserved             |     Keepalive Interval        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Connection ID                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type: 44

    Sub-type:
               2 Acknowledgement

    Reply Code:
                0  Accepted HA Tunnel Address
                1  Not Accepted HA Tunnel Address
                2  No NAT Present, don't use any Connection ID
                   (and Connection ID field not present).
                   (and Keepalive Interval field not present).

UDP Tunnel Request Extension, "Keepalive", MN to HA
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     |    Sub-Type   |   Reserved 1  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |F|R| Reserved 2| Encapsulation |          Reserved 3           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Connection ID                                                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type:
          144

    Sub-type:
              2 HA-NAT State Keepalive (TBA)

Tunnel Data Message
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |  Next Header  |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3012, Generalized MIP Auth Extension

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Subtype    |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              SPI                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Authenticator ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: Jari Arkko <[email-masked]>
Date: Fri, 16 Feb 2007 12:41:27 +0200

Hi Alex,

> no protocol modifications.
Ok. Do you have alternative suggested text that would
better characterize the situation?

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Feb 2007 11:50:59 +0100

Jari Arkko wrote:
> Hi Alex,
> 
> 
>> Known mechanisms have been shown to assist with the issues 
>> described in this document: 6to4 tunnel between MN and a Gateway, 
>> RAs over that tunnel and HA separated from the gateway. Just 6to4, 
>> ND and Mobile IPv6, no protocol modifications.
>> 
> Ok. Do you have alternative suggested text that would better 
> characterize the situation?

It is very difficult to write text along these lines.  It is very
difficult to discard existing IETF transitioning methods as not
addressing the needs of DS-MIPv6.

Maybe this:

> mechanisms could be combined with Mobile IPv6, it takes too much time 
> to analyze how they could work together, hence the need to design
> from scratch a new extension to MIPv6.

Not sure how else could I put it.

Alex

---

From: Jari Arkko <[email-masked]>
Date: Tue, 20 Feb 2007 17:52:35 +0200

George, others? I don't really like either the original
formulation and I hope what Alex suggested isn't
true either. I'm sure there are technical issues
that you could talk about. Please suggest text --
the draft is up for discussion in Thursday's IESG
telechat so I would like to see a better proposal
before that.

Jari

Alexandru Petrescu kirjoitti:
> Jari Arkko wrote:
>> Hi Alex,
>>
>>
>>> Known mechanisms have been shown to assist with the issues described
>>> in this document: 6to4 tunnel between MN and a Gateway, RAs over
>>> that tunnel and HA separated from the gateway. Just 6to4, ND and
>>> Mobile IPv6, no protocol modifications.
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Feb 2007 19:52:17 +0100

Jari Arkko wrote:
> George, others? I don't really like either the original formulation 
> and I hope what Alex suggested isn't true either. I'm sure there are 
> technical issues that you could talk about. Please suggest text -- 
> the draft is up for discussion in Thursday's IESG telechat so I would
>  like to see a better proposal before that.

YEs, please anybody else send a comment regarding the quoted paragraph 
in the DSMIP Problem Statement draft for section 4.5 IPv4 to IPv6 
Transition Mechanisms.

I also believe we can't simply write there wasn't enough time to deal
with all issues.

It may be that a way out of this is to _list_ the other IPv4-to-IPv6
transition mechanisms that this problem statement considered.  I'm sure
6to4 was considered by the authors.  I'm not sure whether STUN was
considered.  IKEv2 NAT traversal _was_ considered by authors.

For each of those we list, we can say why they're not adapted for DSMIP
problem.

For example: list 6to4, abstract what it does, how it offers IPv6
connectivity through the NAT, and then say that it may work with certain
NATs but not with others.  It won't work with NATs that only allow MIP6
through.

Also, list IKEv2 NAT traversal, say in short how it does it, then say
about IKEv2 being independent of running over IPv4 and IPv6 and that it
is necessary for MN-to-HA.  However, say that MIP4 NAT Traversal may be
better adapted for this task because many nodes already implement MIP4
NAT Traversal (as a reminiscent of their MIP4 implementation).

I believe many of these things were discussed at least publicly.

But this is more than one paragraph.

Alex

>>>> described in this document: 6to4 tunnel between MN and a 
>>>> Gateway, RAs over that tunnel and HA separated from the 
>>>> gateway. Just 6to4, ND and Mobile IPv6, no protocol 
>>>> modifications.
>>>> 
>>> The IETF has standardized a number of transition mechanisms to 
>>> allow networks and end nodes to gain IPv6 connectivity while the 
>>> Internet is migrating from IPv4 to IPv6.  However, while some 
>>> transition mechanisms could be combined with Mobile IPv6, it 
>>> takes too much time to analyze how they could work together, 
>>> hence the need to design from scratch a new extension to MIPv6.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 20 Feb 2007 11:06:25 -0800

I think what Alex is saying is somewhat true. It is feasible to use
other transition mechanisms with MIP6. However, those will be heavier
and less efficient. I think it is most straightforward to build the
transition into MIP6 for the purpose of mobility. Without this, for
instance, supporting IPv4-only access networks would mean that the MN
supports some of these other transition mechanisms, which is quite
painful. When there is already a transition mechanism used in the access
network, it is feasible to use that, but, given we are dealing with
mobile nodes and they can roam into any access network, that is not an
assumption we can make. 

Vidya

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Tuesday, February 20, 2007 7:53 AM
> To: Tsirtsis, George
> Cc: Mobile IPv6 Mailing List; Mobile IPv4 Mailing List; 
> Alexandru Petrescu
> Subject: Re: [Mip6] Re: FW: [Mip4] AD reviewof 
> draft-ietf-mip6-dsmip-problem-02.txt
> 
> formulation and I hope what Alex suggested isn't true either. 
> I'm sure there are technical issues that you could talk 
> about. Please suggest text -- the draft is up for discussion 
> in Thursday's IESG telechat so I would like to see a better 
> proposal before that.
> 
> Jari
>

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 20 Feb 2007 14:49:16 -0600

Hi Jari,

You can consider DS-MIP as yet another transition mechanism. And one that is
required or even essential for certain deployments even though we
acknowledge there are several transition mechanisms that have been developed
and can be used.
The fact is that Mobile IP is being deployed and it makes sense for such
deployments to use the Mobile IP infrastructure (i.e the HA in this case) as
a transition solution as well.

Hence this add-on capability/feature to Mobile IP is useful and needed.

-Raj

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 21 Feb 2007 09:05:44 +1100

> telechat so I would like to see a better proposal

=> Here is a suggestion:

The IETF has standardized a number of transition mechanisms to allow
networks and end nodes to gain IPv6 connectivity while the Internet
is migrating from IPv4 to IPv6. These transition mechanisms can be
categorised under two
main items: Tunnelling and Protocol Translation. Protocol Translation
mechanisms are not suitable for Mobile IP signalling as they break end to
end integrity. Tunnelling mechanisms, (both static and dynamic), when
suitable, add unnecessary overheads to the signalling and data between the
mobile node and the home agent. Furthermore, none of those mechanisms can
solve the scenario where IPv4 needs to be dynamically tunnelled in IPv6
(i.e. when a node uses an IPv4 home address in an IPv6 network). Due to
these reasons, there is a need for a new transition mechanism that utilises
the dynamic tunnelling capabilities of Mobile IP. 

Hesham

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Feb 2007 08:34:59 +0200

> the dynamic tunnelling capabilities of Mobile IP. 
Ok. This is closer to what I had in mind. Do people agree with this?

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Feb 2007 10:46:44 +0100

Hesham Soliman wrote:
>> and I hope what Alex suggested isn't true either. I'm sure there
>> are technical issues that you could talk about. Please suggest text
>> -- the draft is up for discussion in Thursday's IESG telechat so I
>> would like to see a better proposal before that.
> 
> => Here is a suggestion:
> 
> categorised under two main items: Tunnelling and Protocol
> Translation. Protocol Translation mechanisms are not suitable for
> Mobile IP signalling as they break end to end integrity. Tunnelling
> mechanisms, (both static and dynamic), when suitable, add unnecessary
> overheads to the signalling and data between the mobile node and the
> home agent. Furthermore, none of those mechanisms can solve the
> scenario where IPv4 needs to be dynamically tunnelled in IPv6 (i.e.
> when a node uses an IPv4 home address in an IPv6 network). Due to 
> these reasons, there is a need for a new transition mechanism that
> utilises the dynamic tunnelling capabilities of Mobile IP.

I agree with the way it is formulated and it makes sense overall.

I would like to insist on using specific protocol names with specific 
transitioning mechanisms and RFC numbers.  For example:

"Protocol Translation mechanisms (SIIT [xx]) are not suitable for Mobile
  IP signaling as they break end-to-end integrity."

"Tunnelling mechanisms (6to4 [xx], STUN [xx]), when suitable, add
  unnecessary overheads to the signalling and data between the mobile
  node and the home agent"

Alex

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Feb 2007 16:09:03 +0200

>> utilises the dynamic tunnelling capabilities of Mobile IP.

Isn't there also an issue with the two mobility protocol configurations,
credentials, etc., even if we have perfect IPv4 and IPv6 connectivity
everywhere through transition mechanisms?

Jari

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 22 Feb 2007 04:33:27 +1100

> everywhere through transition mechanisms?

=> Yes but this point is mentioned elsewhere. I was trying to solve the
issue of why current transition mechanisms are not sufficient. 

Hesham