Subject: RE: [Mip6] RE: [nemo] carrying IPv4 traffic using MIP6/NEMO

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 9 Aug 2005 11:39:38 -0400

> >>> => We're not doing anything with MIPv4 in the DT. We're trying to
 > >>>  allow the MN (that includes MR), using MIPv6, to be able to use
 > >>> an IPv4 or IPv6 home address in any access network that it
 > >> might be in.
 > >>> I think this summarizes the problem that the DT is addressing.
 > >> 
 > >> I think some of the things that are addressed by the mip6trans DT
 > >> could be addressed outside the mip6trans DT.  More 
 > specifically the
 > >> v4 MR stuff.
 > > 
 > > => So let me explain it again: We're *not* doing "v4 MR 
 > stuff". We're
 > > allowing the MR to have a v4 HoA/P. There is no difference between
 > > that and allowing a host to have a v4 HoA..
 > 
 > Yes there is.  We've both just said it may become tricky.

=> You're confusing two separate issues. I said it's tricky to 
have multiple instances of the HAO. For example today we're not 
allowed to have multiple HAOs for an IPv6 address...
This has nothing to do with whether you can support an IPv4 prefix.
There are lots of tricky issues in mobility and it doesn't mean
we can't do it. 

 > 
 > Why is the DT looking into the complexity (that was previously named
 > "tricky") to allow the MR to have a v4 HoA/P?  Isn't the DT facing
 > enough complexity in allowing MH to have a permanent v6 Home Address
 > when connected to a v4 network?  To me, at least the NAT 
 > traversal part
 > gives enough headache.

=> When you see the solution you can assess whether it's complex or not. 
For now I was referring to an update to draft-soliman. The DT hasn't
decided what the solution is based on, so I was referring to draft-soliman
as an example of how this is done, whether it is the final solution or not
is not up to me obviously. 

Hesham

 > Alex

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 09 Aug 2005 18:27:01 +0200

Soliman, Hesham wrote:

> 
>>>>> => We're not doing anything with MIPv4 in the DT. We're 
>>>>> trying to allow the MN (that includes MR), using MIPv6, to be
>>>>>  able to use an IPv4 or IPv6 home address in any access 
>>>>> network that it
>>>> might be in.
>>>> I think some of the things that are addressed by the mip6trans
>>>>  DT could be addressed outside the mip6trans DT.  More
>> specifically the
>>>> v4 MR stuff.
>>> 
>>> allowing the MR to have a v4 HoA/P. There is no difference 
>>> between that and allowing a host to have a v4 HoA..
>> 
> => You're confusing two separate issues. I said it's tricky to have 
> multiple instances of the HAO. For example today we're not allowed to
>  have multiple HAOs for an IPv6 address...

I see, you're right.

Having a v6-mapped v4 address in the HAO would probably lead to sending
two BUs: one for v4, one for v6.  But then draft-dsmip-problem would be
failing too because dsmip suddenly does double signalling.

> There are lots of tricky issues in mobility and it doesn't mean we 
> can't do it.

That sounds like overconfidence to me, IMHO.  Or I may be confused, as
you say.

>> Why is the DT looking into the complexity (that was previously 
>> named "tricky") to allow the MR to have a v4 HoA/P?  Isn't the DT 
>> facing enough complexity in allowing MH to have a permanent v6 Home
>>  Address when connected to a v4 network?  To me, at least the NAT 
>> traversal part gives enough headache.
> 

When I see arguments adding a prefixlen field is 5 minutes work I tend
to believe complexity is still hidden.

> decided what the solution is based on, so I was referring to 
> draft-soliman as an example of how this is done, whether it is the 
> final solution or not is not up to me obviously.

Ok, so we'd probably be more productive on feeding back about the Vijay
Paris slides, about which requirements and scenarios are needed
immediately, rather than pitting documents one against another.

Paris slides:
> Connect an IPv6 mobile node to its IPv6 Home Agent and services from
> an IPv4-only access network

> 1 Support NAT traversal, NAT detection and the ability to turn offthe
> NAT traversal mechanism when not required

> 2 Support the scenario where the Home Agent is behind a NAT and not
> accessible through a public address

> 3 Support dynamic discovery of the HA’s IPv4 address

> 4 Enable IPsec protection for the mip6trans tunnel. The Home Agentand
> the mobile node must be able to negotiate tunnel security
> associations for the mip6trans tunnel

> 5 Enable the mobile node to use its IPv4 Home Address for IPv4
> sessions over the mip6trans tunnel

> 6 Support dynamic allocation of the IPv4 Home Address

I'm for 1 and 4 and not for 2, 3, 5, 6.  And I'd like to add requirement
0: support IPv6 session continuity at a permanent publicly-routable v6
Home Address when the MH connects to a v4-exclusively network.

The requirements 2, 3, 5 and 6 are interesting - ok - but may represent
too much work.

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 10 Aug 2005 21:48:52 +0900

Hi Alex and Hesham

> failing too because dsmip suddenly does double signalling.

We are not discussing a solution yet. So it is irrelevant  to discuss  
such details.

> The requirements 2, 3, 5 and 6 are interesting - ok - but may  

Alex, I disagree on your proposition.
I don't know how do you line between 1,4 and 2,3,5,6.
The requirements listed here were from the DT consensus.

On the other hand, one thing where keiichi pointed out is
whether we should include IPv4 MNP in No.5. And Hesham agreed.

Then, the next question was that should we split documents for v4  
traversal
and v4 session continuity.

regards,
ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Aug 2005 15:54:17 +0200

Vijay Paris slides and Ryuji Wakikawa wrote:
>>> 1 Support NAT traversal, NAT detection and the ability to turn 
>>> offthe NAT traversal mechanism when not required
>> 
>>> 2 Support the scenario where the Home Agent is behind a NAT and 
>>> not accessible through a public address
>> 
>>> 4 Enable IPsec protection for the mip6trans tunnel. The Home 
>>> Agentand the mobile node must be able to negotiate tunnel 
>>> security associations for the mip6trans tunnel
>> 
>> I'm for 1 and 4 and not for 2, 3, 5, 6.  And I'd like to add 
>> requirement 0: support IPv6 session continuity at a permanent 
>> publicly-routable v6 Home Address when the MH connects to a 
>> v4-exclusively network.
>> 
>> The requirements 2, 3, 5 and 6 are interesting - ok - but may 
>> represent too much work.
> 
> Alex, I disagree on your proposition. I don't know how do you line 
> between 1,4 and 2,3,5,6.

I draw the line like this.  2 (Support HA behind NAT) has no potential
solution as far as I know.  3 (DHAADv4) is an unknown protocol.  5 (v4
Home Address for MH) was out of scope initially, the scope was enable v6
Home Address for MH.  6 (dynamic allocation for v4 Home Address) is
something that DHCP can do.

Otherwise, do you agree with inserting a requirement number 0 that says
"give IPv6 Home Address for session continuity and reachability to a MH
that connects to an IPv4 access network"?

Another requirement that was agreeingly proposed on the MIP6 mailing
list was to support v6 HA that has no v4 connectivity.  Do you agree
with this requirement?

> The requirements listed here were from the DT consensus.

I acknowledge that. That's the way they were presented to the WG meeting.

> On the other hand, one thing where keiichi pointed out is whether we
>  should include IPv4 MNP in No.5. And Hesham agreed.

I agree they may have agreed on that point.

> traversal and v4 session continuity.

Let me try to understand.  Do you mean splitting DT documents?
Initially the DT was supposed to produce 1 scenario/reqs draft and 1
solution draft.  Do you mean that instead of the one solution draft
there'd be two complimentary solution drafts?

I understand draft-soliman and draft-dsmip are not DT output.

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 10 Aug 2005 23:07:34 +0900

Hi Alex

On 2005/08/10, at 22:54, Alexandru Petrescu wrote:

> solution as far as I know.

There were some comments to support this scenario.

> 3 (DHAADv4) is an unknown protocol.

we never say DHAADv4:-)

> 5 (v4
> Home Address for MH.

OK

> 6 (dynamic allocation for v4 Home Address) is

We may give just guideline how to acquire the address with existing  
solutions.
Nobody knows yet.

> that connects to an IPv4 access network"?

this is the base requirement.

> list was to support v6 HA that has no v4 connectivity.  Do you agree

No, I personally don't.
> there'd be two complimentary solution drafts?

Sorry, it was not so clear. I refer the comment of Keiichi.
What i thought  was that DT produce a base spec for v4 traversal  
(maybe tunnel establishment) and
define additional document how to bind v4 HoA/MNP to the tunnel (MIP  
tunnel/v4 traversal tunnel, whatever).
This is just personal idea and hopefully catch the intention of keiichi.

ryuji

---

From: Keiichi SHIMA <[email-masked]>
Date: Tue, 16 Aug 2005 17:52:02 +0900 (JST)

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 10 Aug 2005 23:07:34 +0900

> This is just personal idea and hopefully catch the intention of keiichi.

Yes, the above comment catches my intention.

I think providing an IPv4 HoA and (multiple) IPv4 home networks to a
mobile router is an important feature.  The question is whether the
specification must be discussed with traversal mechanisms or not.

I personally think these ideas (the mechanism for v4traversal and the
mechanism to provide v4 access) can be documented separately.  The v4
traversal document specifies the mechanism to provide an IPv4 address
as a CoA.  The v4 access document will provide the mechanism to put
additional identifiers (a v4 HoA and v4 MNPs).

I don't think these two mechanisms depend each other tightly.
(or, does it?)

Both specifications may be produced inside the DT or may not.  It
depends on the decision of the DT members.  (BTW, I personally think v4
access mechanisms are out of scope of the DT for v4traversal, though)

But, at least splitting orthogonal (it looks so to me) ideas are a
good way to keep specs simple..

Regards,
---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>