Subject: [Mip6] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt

From: Basavaraj Patil <[email-masked]>
Date: Mon, 06 Aug 2007 17:14:07 -0500

Hello,

This is a joint working group last call between  for I-D:
Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)
<draft-ietf-mip6-nemo-v4traversal-05.txt>

URL:
http://ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-05.txt

This I-D is a standards track document and is a joint MIP6/NEMO WG I-D.

Please review the ID and submit your comments to the MIP6 and NEMO WG
mailing lists by August 22nd, 07.

-Raj

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Aug 2007 12:26:10 +0200

I think the current DS-MIPv6 doc supports a very limited scope of 
deployment/applicability and, within its class of goals, has competitors 
more advanced technologically and with wider deployments 
(IPv6-transition-mechanisms, STUN, ICE).

Alex

> mailing lists by August 22nd, 07.

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

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 13 Aug 2007 11:25:18 -0400

Hi Raj,
   I have gone through the latest version of this draft. I think this 
draft is very useful and I believe that the draft is ready to advance to 
the IESG.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 13 Aug 2007 11:27:19 -0400

Hi Alex,
   I think the IPv6 transition mechanisms are complementary to DSMIPv6 
and not necessarily competitors. DSMIPv6 allows for some scenarios which 
the IPv6 transition mechanisms cannot support. e.g. Which IPv6 mechanism 
you mentioned would allow you to have a IPv4 home address over MIPv6 
signaling?

Cheers
Suresh

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 13 Aug 2007 23:51:50 -0500

I agree with Suresh. I believe we have discussed this topic before. There
are many transition mechanisms that have been defined. For MIP6 deployment
the WG believes this is an optimal solution since it requires only
additional capability in the MN and HA. Hence there is no reason to debate
or compare the pros/cons of DS-MIP6 with other transition mechanisms.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 14 Aug 2007 09:46:16 +0200

Suresh Krishnan wrote:
> Hi Alex, I think the IPv6 transition mechanisms are complementary to 
> DSMIPv6 and not necessarily competitors.

Would DS-MIPv6 work with IPv4-over-IPv6 rfc2473?  It doesn't cite it.

> DSMIPv6 allows for some scenarios which the IPv6 transition 
> mechanisms cannot support. e.g. Which IPv6 mechanism you mentioned 
> would allow you to have a IPv4 home address over MIPv6 signaling?

Not sure what you're asking... are you asking "which other protocol is
DS-MIPv6"?

Otherwise, if genuinely interested on how to transport IPv4 over IPv6
then one would look at rfc2473, the same RFC which offers IPv6 over IPv6
for MIPv6.  It is cited by rfc3775 but ignored by
draft-ietf-mip6-nemo-v4traversal-05.txt.

> DSMIPv6 allows for some scenarios which the IPv6 transition 
> mechanisms cannot support...

I think they are very limited.  Networks that support only native IPv6
are very rare and are most often _core_ networks, not access networks.

(In this respect, if I remember correctly, DS-MIPv6 does not allow the
  HA to be native IPv6; it forces the HA to be IPv4 addressable.  Or,
  it's most probably the HA to be deployed on a IPv6-only network.)

What I'm trying to say is that DS-MIPv6 is not addressing some important
deployment scenarios (its NAT traversal doesn't support
dst-port-changing NATs, doesn't traverse HTTP proxy gateways, doesn't
negotiate the traversal mechanism) and it addresses some scenarios which
  are limited in scope.

Look at it this way: deploy a DS-MIPv6 HA and take a MN running DS-MIPv6
and go to a publicly deployed wifi hotspot: most probably it won't work.
  Most probably because of the typical NAT/firewall/httpproxy being in 
place.

Now take a recent VoIP MN with the most recent traversal software and go
to the same wifi hotspot and chances are one is reachable at his/her
permanent identifier.

If DS-MIPv6 offered traversal mechanisms as powerful as VoIP's then I'd
be very happy with it.

Alex

> Cheers Suresh
>> deployment/applicability and, within its class of goals, has 
>> competitors more advanced technologically and with wider 
>> deployments (IPv6-transition-mechanisms, STUN, ICE).
>> 
>> Alex
>> 
>> Basavaraj Patil wrote:
>>> Hello,
>>> 
>>> This is a joint working group last call between  for I-D: Mobile 
>>> IPv6 support for dual stack Hosts and Routers (DSMIPv6) 
>>> Please review the ID and submit your comments to the MIP6 and 
>>> NEMO WG mailing lists by August 22nd, 07.
>>> 
>>> -Raj
>>> 
>>> 
>>> 
>> 
>> 
>>  This email has been scanned by the MessageLabs Email Security 
>> System. For more information please visit 
>> http://www.messagelabs.com/email 
>> _______________________________________________ Mip6 mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 14 Aug 2007 09:54:55 +0200

Basavaraj Patil wrote:
> I agree with Suresh. I believe we have discussed this topic before. 
> There are many transition mechanisms that have been defined. For MIP6
>  deployment the WG believes this is an optimal solution since it 
> requires only additional capability in the MN and HA. Hence there is 
> no reason to debate or compare the pros/cons of DS-MIP6 with other 
> transition mechanisms.

Raj, right, we've discussed these in the past.  I'm not looking at
debating and comparing.  Just take the best from both.

ds-mipv6 would benefit from citing a ipv4-over-ipv6 or a ipv6-over-ipv6
document.  Because it actually uses it.  Without it it won't work.  Why
don't you want to refer this?  Do you have other-than-rfc2473 in mind?

ds-mipv6 would benefit from more powerful nat/firewall/httpproxy
standard traversal mechanisms.  Why don't you want to refer this?  Do
you have other-than-stun-ice in mind?  Non-standard traversal ala skype?

Ignoring these is leaving place for possibly bad interpretations.

Alex

> 
> -Raj
> 
> 
> On 8/13/07 10:27 AM, "ext Suresh Krishnan" 
> <[email-masked]> wrote:
> 
>> Hi Alex, I think the IPv6 transition mechanisms are complementary 
>> to DSMIPv6 and not necessarily competitors. DSMIPv6 allows for some
>>  scenarios which the IPv6 transition mechanisms cannot support.
>> e.g. Which IPv6 mechanism you mentioned would allow you to have a
>> IPv4 home address over MIPv6 signaling?
>> 
>> Cheers Suresh
>>

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 14 Aug 2007 20:58:14 +1000

> Would DS-MIPv6 work with IPv4-over-IPv6 rfc2473?  It doesn't cite it.

=> Of course it does, that's generic tunnelling in IPv6. We can cite it, I'm
taking that as a comment not a suggestion for an applicability statement. 

 >   HA to be native IPv6; it forces the HA to be IPv4 addressable.  

=> You raised this point several times and several people told you that this
is incorrect. 
An IPv6 only HA would obviously work for an IPv6 only deployment. It's not
that DSMIP mandates a
dual stack HA, the requirements come from deployments, if they want a dual
stack network then we accomodate that.  

 > dst-port-changing NATs, 

=> Again, Henrik answered this point many times before. You're the only one
who talks about NATs that randomly change port numbers. No one else with NAT
experience has mentioned that. If there is a public independent pointer to
such NATs then please send it to the list, otherwise we won't consider this
issue.

 doesn't traverse HTTP proxy gateways, 

=> Huh? 

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 14 Aug 2007 14:11:27 +0200

Hesham Soliman wrote:
> => Of course it does, that's generic tunnelling in IPv6. We can cite
>  it, I'm taking that as a comment not a suggestion for an 
> applicability statement.

Thanks Hesham, yes please cite it, take it as a comment.

>> (In this respect, if I remember correctly, DS-MIPv6 does not allow
>>  the HA to be native IPv6; it forces the HA to be IPv4 addressable.
>> 
>> 
> 
> => You raised this point several times and several people told you 
> that this is incorrect. An IPv6 only HA would obviously work for an 
> IPv6 only deployment. It's not that DSMIP mandates a dual stack HA, 
> the requirements come from deployments, if they want a dual stack 
> network then we accomodate that.

Sorry, I don't think I've made myself clear enough.

Some deployments do require that the HA stays IPv6-only and its MNs
attach to IPv4-only access networks.

A HA that must be dual-stacked in order for its MNs to access IPv4-only
networks (what DS-MIPv6 does) has its applicability too, but more limited.

>> What I'm trying to say is that DS-MIPv6 is not addressing some 
>> important deployment scenarios (its NAT traversal doesn't support 
>> dst-port-changing NATs,
> 
> => Again, Henrik answered this point many times before. You're the 
> only one who talks about NATs that randomly change port numbers. No 
> one else with NAT experience has mentioned that. If there is a public
>  independent pointer to such NATs then please send it to the list, 
> otherwise we won't consider this issue.

I don't have a public independent pointer.

It's NAT randomly changing UDP dst port numbers of outgoing packets, not
all port numbers.  Every 5min (corresponding to a typical 5min voice
call, or to a TCP typical connection rfcnumber here).

>> doesn't traverse HTTP proxy gateways,

Not sure how to take your question mark, but let me just signal that
when one goes to _any_ deployed wifi hotspot one has to deal with http
proxy gateways at least as first step of accepting the sales conditions.

And then there are the http authenticating proxy gateways that won't let
out of network anything but http/s.  Widely deployed.

DS-MIPv6 doesn't deal with any of these, so it has limited
applicability, IMHO.  Some STUN/ICE do, so they have larger applicability.

Alex

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 14 Aug 2007 22:23:14 +1000

> networks (what DS-MIPv6 does) has its applicability too, but 

=> I think you're referring to the case that Pascal suggested earlier about
splitting the IPv4 stack away from the HA. We discussed this and we didn't
think it was worth solving. We haven't heard anyone from the operational
areas or from the operator community complaining about the lack of support
for this scenario. Every solution is limited to subset of almost infinite
scenarios, it's a question of solving the ones that people deploying
networks need. We also agreed that if there is a clear need for extensions
this can be done separately at a later stage.

 > I don't have a public independent pointer.

=> Ok. I'm afraid, in the absence of any support for this behaviour we can't
really consider it. 

 > applicability, IMHO.  Some STUN/ICE do, so they have larger 

=> You're comparing apples and oranges of course. We're not going to go
around admins demands to show people how to hack networks. If they chose not
to let anything other than HTTP through then they're aware of what they
don't want. We're not going to tunnel MIPv6 in HTTP! 
For the record, I used hotspots in at least a dozen different countries and
not one spot asked me to use an HTTP proxy. Seems like a silly thing to do
in a public network. 

Hesham

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 14 Aug 2007 08:58:22 -0400

Hi Alex,

> Would DS-MIPv6 work with IPv4-over-IPv6 rfc2473?  It doesn't cite it.

The question is, does it need to? My reading of the charter says the 
solution needs to handle dual stacked nodes (I guess RFC4213). I have no 
opinions for or against citing other transition mechanisms.

> negotiate the traversal mechanism) and it addresses some scenarios which

This is a totally different ballgame. The scenarios addressed by this 
draft are listed in section 1.2. I would consider this section to be 
analogous to an applicability statement. I am perfectly happy if these 
scenarios (and only these) are well covered by the draft. Are you saying 
that this list scenarios of scenarios is incomplete? I think it would be 
difficult to add to these at this point.

> If DS-MIPv6 offered traversal mechanisms as powerful as VoIP's then I'd

Perhaps a generic "IPv6 over 
IPv4+NAT+firewall+authenticating_http_proxy+other_obstacles" draft would 
be a better way of addressing this.

Cheers
Suresh

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 14 Aug 2007 15:44:14 +0200

Hesham Soliman wrote:
>> A HA that must be dual-stacked in order for its MNs to access 
>> IPv4-only networks (what DS-MIPv6 does) has its applicability too,
>>  but more limited.
> 
> => I think you're referring to the case that Pascal suggested earlier
>  about splitting the IPv4 stack away from the HA. We discussed this 
> and we didn't think it was worth solving. We haven't heard anyone 
> from the operational areas or from the operator community complaining
>  about the lack of support for this scenario. Every solution is 
> limited to subset of almost infinite scenarios, it's a question of 
> solving the ones that people deploying networks need. We also agreed
>  that if there is a clear need for extensions this can be done 
> separately at a later stage.

Ok, let's see later.

> => Ok. I'm afraid, in the absence of any support for this behaviour 
> we can't really consider it.

Ok, what if I ask: Please point me to a public independent
pointer ceritfiying at least one NAT implementation complying with
rfc4787 "NAT UDP Unicast Requirements", this latter saying that the 5min
mapping timer shouldn't expire when no traffic.

Absent that proof I don't see why assuming it. (you do).

Then have a look at rfc2993 which says that the port mapping for a
connection shouldn't change at least during 4 minutes, it explains why.
Then it goes on saying why this requirement is a burden on NAT
implementers, especially those who must accommodate large number of users:

rfc2993 "Architectural Implications of NAT"
> For address-and-port translators to comply with this requirement, 
> they similarly must refrain from assigning the same host/port pair 
> until 2*MSL has elapsed since the end of its first use.  While these
>  requirements are simple to state, they can place a great deal of 
> pressure on the NAT, because they temporarily reduce the pool of 
> available addresses and ports.  Consequently, it will be tempting or
>  NAT implementers to ignore or shorten the TCP_TIME_WAIT
> requirements, at the cost of some of TCP's strong reliability.  Note
> that in the case where the strong reliability is in fact compromised
> by the appearance of an old packet, the failure can manifest itself
> as the receiver accepting incorrect data.

I don't have any other proof than the two rfcs and noted implementation
of deployed systems.

What kind of proof do you have about how you assume the NAT behaviour 
not changing the src port number of outgoing udp connections?

>> Not sure how to take your question mark, but let me just signal 
>> that when one goes to _any_ deployed wifi hotspot one has to deal 
>> with http proxy gateways at least as first step of accepting the 
>> sales conditions.
>> 
>> And then there are the http authenticating proxy gateways that 
>> won't let out of network anything but http/s.  Widely deployed.
>> 
> => You're comparing apples and oranges of course. We're not going to
>  go around admins demands to show people how to hack networks.

Rhetorics...

You want handovers between deployed IPv4 networks.

> If they chose not to let anything other than HTTP through then 
> they're aware of what they don't want. We're not going to tunnel 
> MIPv6 in HTTP!

Too bad, because other people tunnel other things in http when
necessary, and are happy with it, because it offers the opportunity to 
connect to a wider set of access networks.  Isn't this one of the holy 
grails of MIP, to connect to everywhere?

> For the record, I used hotspots in at least a dozen different
> countries and not one spot asked me to use an HTTP proxy. Seems like
> a silly thing to do in a public network.

Didn't these hotspots ask you to first accept some commercial conditions 
on a web page before opening the filters?  I can't imagine MIP going 
through these systems without first accepting these http things.

Are we talking the same kind of deployment?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 14 Aug 2007 15:55:51 +0200

> opinions for or against citing other transition mechanisms.

I think we say the same thing actually.

I am happy if you don't oppose citing rfc2473 by DS-MIPv6.

> difficult to add to these at this point.

I am happy with that section listing 4 scenarios DS-MIPv6 addresses.

Scenario 2 - MN behind NAT - is deceivingly simple compared to what IPv4 
access networks are deployed out there.

That makes the applicability statement very thin IMHO.

> be a better way of addressing this.

:-)

Alex

---

From: <[email-masked]>
Date: Thu, 16 Aug 2007 09:49:27 +0200

Hi,

I agree that Alexandru has a point on the NAT traversal issue in that
NAT keep alives
may not keep the NAT mapping active.

If we compare with IP Sec NAT traversal (RFC 4306 and RFC 3948) 
the issue is there sought mitigated by allowing "seamless" 
replacement of the NAT address, i.e., (section 2.23) 

      "There are cases where a NAT box decides to remove mappings that
      are still alive (for example, the keepalive interval is too long,
      or the NAT box is rebooted).  To recover in these cases, hosts
      that are not behind a NAT SHOULD send all packets (including
      retransmission packets) to the IP address and port from the last
      valid authenticated packet from the other end (i.e., dynamically
      update the address).  A host behind a NAT SHOULD NOT do this
      because it opens a DoS attack possibility.  Any authenticated IKE
      packet or any authenticated UDP-encapsulated ESP packet can be
      used to detect that the IP address or the port has changed."

The fact that the packets are authenticated does not protect the NAT
assigned address,
but it assures that the NAT assigned address in IKE and IP Sec SAs 
only can be manipulated when high jacking the packets. And if an
attacker can highjack all packets,
well then :-)

The corresponding issue for DSMIP is what to do with respect to MIP
bindings and
UDP tunnel addresses when the NAT binding expires and the exterior NAT
address allocated for the next 
out-going packet from the MN thus is a new one.

When IPSec is used on the tunnel, RFC 3948, the issue is handled one
way.
I.e., in accordance with what is said above,
the old address should be replaced with the new one automatically.

But what would happen when IP Sec is not deployed ? 
Presumably the HA will discard the 
encapsulated packet, at least this seems 
the best way to ensure compliance with RFC 3775, section 10.4.5.

It would thus be up to the mobile node to detect that the tunnel is no
longer 
working and resend a BU.

Letting the HA send binding refresh 
requests in this situation does not work due to DoS.

I agree that it could be good to add some lines discussing this.

An altogether different comment:

Section 4.2, second paragraph:

When the home agent receives the encapsulated binding update it
   compares the IPv4 address of the source address field in the IPv4
   header with the IPv4 address in the source address of the IPv6
header. 
 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Replace by : the Ipv4 Care of address option.

BR, Karen
       
> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Tuesday, August 14, 2007 3:44 PM
> To: Hesham Soliman
> Cc: 'Mobile IPv6 Mailing List'
> Subject: Re: [Mip6] Re: [nemo] WG LC: 
> draft-ietf-mip6-nemo-v4traversal-05.txt
> 
> Hesham Soliman wrote:
> >

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 16 Aug 2007 18:43:50 +1000

I don't think you and Alex are talking about the same thing. Alex seemed to
be referring to NATs that simply disregard any timeouts and randomly change
outgoing ports, he can explain himself better if I misunderstood. What
you're describing below is a failure situation due to an unusual case like a
reboot. We briefly discussed this when we were discussing issue 93.

 > out-going packet from the MN thus is a new one.

=> If the NAT binding expired then we assume that either:
A. The MN didn't refresh the binding, or, 
B. An unusual event like a reboot took place.

 > the best way to ensure compliance with RFC 3775, section 10.4.5.

=> Yes.

 > It would thus be up to the mobile node to detect that the 

=> Correct. In the same way that the mobile node is expected to do that when
the HA crashes. RFC 3775 doesn't talk about detecting that, but somehow, an
implementation can have the intelligence to resend the BU as a diagnostic
measure for instance. 

 > I agree that it could be good to add some lines discussing this.

=> That's fine with me. But I think you're raising a new issue, which can be
addressed as part of this LC.

Hesham

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 16 Aug 2007 18:51:03 +1000

> Absent that proof I don't see why assuming it. (you do).

=> I assume it because it is the assumption that most people go by,
including those building and operating NATs. And because I haven't seen the
behaviour you talk about anywhere, hence my questions for public docs.

 > I don't have any other proof than the two rfcs and noted 

=> Do those deployed systems have a name? a spec? a vendor who can back your
claims? Are they widely deployed or limited to ten people?

 > grails of MIP, to connect to everywhere?

=> No, not through HTTP tunnels, I don't remember reading that requirement
anywhere. 

 > through these systems without first accepting these http things.

=> This is nonsense really. HTTP redirect for authentication has nothing to
do with mandating HTTP only traffic and HTTP ALGs. Two completely unrelated
issues. Of course MIP will work fine after the filters are opened. 

 > Are we talking the same kind of deployment?

=> I don't think so.

Hesham

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 17 Aug 2007 06:12:58 +0900

Hi

First of all,  I am fine with the latest DSMIP doc.
Thanks Hesham for updating doc.

HTTP proxy isn't scope of this document.
As Hesham said, most  of deployed http proxy in access networks
is for authentication to open filters.
After opening filters, DSMIP should work fine.

DT discussed the NAT box reboot/crash scenarios at some conf-call.
Someone raised this problem, but we concluded that these are not  
usual cases.
In these scenarios, MN should take the first action to recover from  
these failures,
because HA cannot reach to the MN after NAT states are erased.
Therefore, the use of binding update sounds very reasonable to me.
In addition, MN can configure the shorter binding lifetime at the NAT  
scenarios
in order to recover from these events and to keep NAT states.

regards,
ryuji

ps. Alex, if you want to skip http-proxy auth, try DNS tunnel. It  
sometime works fine;-)

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 17 Aug 2007 19:57:28 +0200

Hesham Soliman wrote:
> I don't think you and Alex are talking about the same thing. Alex 
> seemed to be referring to NATs that simply disregard any timeouts and
>  randomly change outgoing ports, he can explain himself better if I 
> misunderstood.

Hesham, I've explained NAT-forced-change-of-outgoing-src-port-number
several times and I seem to fall on deaf ears here; except Karen now
seems to acknowledge this may be an issue with IPsec.

I agree with Karen that there is an issue with IPsec too when the port
numbers change.

I know I can't convince you, and thus all I can say is that DS-MIPv6 has
a limited applicability scope as it is now.  And I also support 
advancement of this document as I said several times too.

> What you're describing below is a failure situation due to an unusual
>  case like a reboot. We briefly discussed this when we were
> discussing issue 93.
> 
>>  bindings and UDP tunnel addresses when the NAT binding expires and
>>  the exterior NAT address allocated for the next out-going packet 
>> from the MN thus is a new one.
> 
> => If the NAT binding expired then we assume that either: A. The MN 
> didn't refresh the binding, or, B. An unusual event like a reboot 
> took place.
> 
>> 
>> When IPSec is used on the tunnel, RFC 3948, the issue is handled 
>> one way. I.e., in accordance with what is said above, the old 
>> address should be replaced with the new one automatically.
>> 
>> But what would happen when IP Sec is not deployed ? Presumably the 
>> HA will discard the encapsulated packet, at least this seems the 
>> best way to ensure compliance with RFC 3775, section 10.4.5.
> 
> => Yes.
> 
>> 
>> It would thus be up to the mobile node to detect that the tunnel is
>>  no longer working and resend a BU.
> 
> => Correct. In the same way that the mobile node is expected to do 
> that when the HA crashes. RFC 3775 doesn't talk about detecting that,
>  but somehow, an implementation can have the intelligence to resend 
> the BU as a diagnostic measure for instance.
> 
> => That's fine with me. But I think you're raising a new issue, which
>  can be addressed as part of this LC.

I agree.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 17 Aug 2007 20:09:01 +0200

RYUJI WAKIKAWA wrote:
> Hi
> 
> First of all,  I am fine with the latest DSMIP doc. Thanks Hesham for
> updating doc.
> 
> HTTP proxy isn't scope of this document. As Hesham said, most  of
> deployed http proxy in access networks is for authentication to open
> filters. After opening filters, DSMIP should work fine.

Absolutely agree DSMIP would work after the filters are open.  But one
can't imagine a user authenticating the http proxy with a mouse click
and then starting DS-MIPv6 each time s/he accesses a new wifi network...
this is clearly a burden.

> Someone raised this problem, but we concluded that these are not

The case of NAT changing the the outgoing src port number every 5
minutes is _not_ a NAT-reboot issue.  I've measured this behaviour
during hours and it happens so.  One can't imagine that the NAT box
reboots every 5 minutes.

Also, a normal user of that NAT (doing http queries or other similar
behaviour) won't notice anything.  Only a ftp/streaming user will notice.

> these failures, because HA cannot reach to the MN after NAT states
> are erased.

Yes.

> Therefore, the use of binding update sounds very reasonable to me. In
> addition, MN can configure the shorter binding lifetime at the NAT 
> scenarios in order to recover from these events and to keep NAT
> states.

Imagine MN sends a BU every 2minutes, to fill the 5min NAT changes.  But 
then imagine that CN streams the first packet to MN at a moment when the 
NAT src port number has just changed.  The HA will have to wait at least 
2min for CN to be able to reach MN.

And you also need the HA to be specified to memorize the state related 
to MN to something more than just the quadruple 
(ipsrc,ipdst,portsrc,portdst), and that can only be a new id in packet...

Alex

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Sat, 18 Aug 2007 15:27:06 +0900

Alex,

> this is clearly a burden.

are you suggesting that DSMIP should open the port through http-proxy  
somehow??
If so, I disagree.
ex. If the web page ask you to fill the credit card number, will  
DSMIP carry the card information:-p

> during hours and it happens so.  One can't imagine that the NAT box

Your problem is the suggested default value in the DSMIP?
I think this value was suggested by MIPv4 traversal deployment?!

>> In these scenarios, MN should take the first action to recover  
>> from these failures, because HA cannot reach to the MN after NAT  
>> states
>> are erased.
>
> Yes.
>
> Imagine MN sends a BU every 2minutes, to fill the 5min NAT  
> changes.  But then imagine that CN streams the first packet to MN  
> at a moment when the NAT src port number has just changed.  The HA  
> will have to wait at least 2min for CN to be able to reach MN.

The use of BU to keep NAT state was discussed and agreed (consensus)  
in WGs before.

If 2 min absence is problem, how fast do you want MN to recover from  
the NAT state changes? 1msec, 10msec, 1 sec, 5sec, 10sec??
Even we use explicit signaling (like ping) to check NAT, it takes  
some time to recover the NAT state.

> And you also need the HA to be specified to memorize the state  
> related to MN to something more than just the quadruple  

why?? MN binding is not erased on HA unless the lifetime is expired.
Do you suggest to buffer the CN's packets during NAT reboot/crash?
This is not belong to the DSMIP goal.  No additional specification is  
required in DSMIP.

regards,
ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 20 Aug 2007 11:36:44 +0200

RYUJI WAKIKAWA wrote:
>>> Hi First of all,  I am fine with the latest DSMIP doc. Thanks 
>>> Hesham for updating doc. HTTP proxy isn't scope of this document.
>>> is for authentication to open filters. After opening filters, 
>>> DSMIP should work fine.
>> 
>> Absolutely agree DSMIP would work after the filters are open.  But 
>> one can't imagine a user authenticating the http proxy with a mouse
>> click and then starting DS-MIPv6 each time s/he accesses a new wifi
>> network... this is clearly a burden.
> 
>  somehow?? If so, I disagree. ex. If the web page ask you to fill the
>  credit card number, will DSMIP carry the card information:-p

I think this is a matter of requirements discussion.  I don't mean to
modify DSMIP solution right now.

(I think it should be possible for DS-MIPv6 to be able to identify the
  environment in which it is working (firewalls, traversal method
  necessary, etc) and adapt to it.  How that is done is a solution
  space.)

But I think the applicability statements of DS-MIPv6 could be modified
to say that the current DS-MIPv6 is not running through public IPv4
hotspots that demand user intervention on html pages prior to connection
opening, or credit card as you say.

>>> DT discussed the NAT box reboot/crash scenarios at some 
>>> conf-call. Someone raised this problem, but we concluded that 
>>> these are not usual cases.
>> 
>>  during hours and it happens so.  One can't imagine that the NAT
>> box reboots every 5 minutes.
> 
> Your problem is the suggested default value in the DSMIP? I think 
> this value was suggested by MIPv4 traversal deployment?!

Ok.

>> Also, a normal user of that NAT (doing http queries or other 
>> similar behaviour) won't notice anything.  Only a ftp/streaming 
>> user will notice.
>> 
>>> states are erased.
>>> Therefore, the use of binding update sounds very reasonable to 
>>> me. In addition, MN can configure the shorter binding lifetime at
>>>  the NAT scenarios in order to recover from these events and to 
>>> keep NAT states.
>> 
>> Imagine MN sends a BU every 2minutes, to fill the 5min NAT changes.
>>  But then imagine that CN streams the first packet to MN at a 
>> moment when the NAT src port number has just changed.  The HA will 
>> have to wait at least 2min for CN to be able to reach MN.
> 

I'm not sure what you call consensus...  There exist a number of NATs
that will _not_ keep state bindings (ipsrc/dst, portsrc/dst) even if
ongoing traffic go through it continuously.

> the NAT state changes? 1msec, 10msec, 1 sec, 5sec, 10sec?? Even we 
> use explicit signaling (like ping) to check NAT, it takes some time 
> to recover the NAT state.

This is again solution space.  And it's not now the time to modify the
DS-MIPv6 solution.

I want the MN to send heartbeats through NAT with a variable frequency
that (1) depends on a particular NAT frequenct changing the state of a
connection and (2) makes sure HA has that state reflected in a delay of
maximum 50ms.

As you see this looks more as a requirement.  There are several
possible solutions satisfying that requirement.

> why?? MN binding is not erased on HA unless the lifetime is expired.

I don't mean MIP binding, but UDP addr/port state.  The DSMIP binding
doesn't contain port numbers but these are essential for NAT traversal
with UDP, especially when dynamically changing.

> This is not belong to the DSMIP goal.  No additional specification is

No, I don't  suggest HA buffers packets.  I agree not a relevant goal
for HA.

Alex

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 22 Aug 2007 13:58:21 +0200

Hi Raj

I hope you're doing well. Here are my comments on the draft. I think
some of them were already pointed out some time ago, but I prefer to
list them all.

Page 5: 

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

   - Mobile nodes should be able to use an IPv4 and IPv6 home or care-of
   address simultaneously and update their home agents accordingly.

This is true for the home address which are used in parallel, but not
for the CoA are used exclusively. Either v6 if there is one or V4 if
that's all what's available.
----------------------

Page 7: 

----------------------
	
Effectively, the
   mobile node establishes two different tunnels, one for its IPv4
   traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6)
   with a single binding update.

Not necessarily two different tunnels. A tunnel is just another
interface for the router and with this spec, we support both IP
protocols on that interface.
----------------------

Page 8:
----------------------

   The routing header in the binding update MUST include the mobile
   node's IPv6 home address as specified in [MIPv6].

In fact we do not need the routing header and it should be omitted. This
applies to the BA format detailed page 18 as well. Also, the routing
header is present in BA, not BU.
----------------------

Page 9:
----------------------
					All entries MUST point to the
mobile
   node's IPv4 care-of address included in the source address of the
   IPv6 packet and represented as an IPv4-mapped IPv6 address.

I'll miss the mapped address ;) In any case, the CoA that the HA cares
for is the source of the IPv4 packet, not the address in the CoA option
so this text was doubly wrong. In the spec we call both addresses (the
private and the natted) the IPv4 CoA, which ends up with this kind of
trouble.

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

Page 9 also:
----------------------
				The inner IPv6 packet will contain the
home
   agent's IPv6 address as a source address and the mobile node's IPv6
   home address in the destination address field.

I think that this text should be moved earlier, in 2.3.2. It is common
to all IPv4 encaps cases.
The text could also mention that UDP is always used for the BU/BA flow,
with the destination port for BU set to a well-known value (TBD) defined
in section 8.

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

Page 10:
----------------------
   P                    A flag indicating, when set, that the mobile
                        node requests a mobile network prefix. This flag
                        is only relevant for new requests, and must be
                        ignored for binding refreshes.

I'd drop this field and the whole prefix delegation support from this
spec and move it to: 
draft-ietf-nemo-prefix-delegation-* . Applies also on page 13 for the
Pref field.
TJ and I will submit a refresh and if Hesham wishes to join and help,
this could be done swiftly.

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

Page 16:
----------------------

Then again, now it is the CoA option. 
----------------------

Page 17:
----------------------

	The source port in the packet is the home agent's
   source port.

The source port in the packet is the well-known port TBD allocated by
IANA in section 8 for this specification

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

Page 17:
----------------------

unless the home agent forces UDP encapsulation using the F flag. 

- >unless the home agent or the mobile node forces UDP encapsulation
using the F flag. 
The same happens page 20.

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

Page 17:
----------------------

   A mobile node MUST always tunnel binding updates in UDP when located
   in an IPv4-only network. Essentially, this process allows for
   perpetual NAT detection. 

More precisely, this enables the BU / BA flow to complete whether there
is a NAT or not, which might be hard to guess when the MN gets a new
CoA.

---------------------- 
Page 17:
----------------------
					Similarly, the home agent MUST
encapsulate
   binding acknowledgements in a UDP header whenever the binding update
   is encapsulated in UDP.

This means always; this is why I suggest to move that discussion in
2.3.2.

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

Page 18:
----------------------
   B. Binding acknowledgement sent by the home agent:
              IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
                  UDP header
                   IPv6 header (src=HAADDR, dst=V6HOA)
                      Route HDR Type 2
                          V6HOA (IPv6 home address)
                      Mobility header
                          BA ([IPv4 ACK], NAT DET)

RH2 should be omitted
----------------------- 

Page 19:
----------------------
   - The IPv6 packet is encapsulated in the vanilla UDP encapsulation
     format.

I'd add that the destination port is set to the well-known port TBD
defined section 8.
----------------------

Page 19:
----------------------

     node did not have a static home address it MAY include the
     unspecified IPv4 address, which acts as a request for a dynamic
     IPv4 home address. Alternatively, one or more IPv4 home address

I'm not sure whether the unspecified IPv4 address is specified anywhere?
For IPv6 people it makes all the sense in the world, but may we could 
stick to all zeroes unless it's actually defined in a reference - that I
missed?

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

Page 19:
----------------------

				Alternatively, one or more IPv4 home
address
     options may be included with requests for IPv4 prefixes (i.e. with
     the P flag set.).

As I proposed, let's move this to the NEMO prefix delegation spec.

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

Page 20:
----------------------
   Where the UDP header is only used if a NAT were detected between the
   mobile node and the home agent, or if the home agent forced UDP
   encapsulation.

or if the home agent or the MN forced the encapsulation.
----------------------

I hope this helps...

Pascal

>From: Basavaraj Patil [mailto:[email-masked]]
>Sent: Tuesday, August 07, 2007 12:14 AM
>To: Mobile IPv6 Mailing List; [email-masked]
>Cc: Gopal Dommety (gdommety); [email-masked]; Basavaraj Patil;
[email-masked]
>Subject: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt
>
>
>Hello,
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Aug 2007 18:02:16 +0200

Pascal Thubert (pthubert) wrote:
[...]
> Page 10:

I agree with this suggestion to move all assignment of prefixes to 
draft-ietf-nemo-prefix-delegation draft (away from ds-mipv6).

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 22 Aug 2007 09:41:56 -0700 (PDT)

I've reviewed the earlier version of this document and
I think it should be advanced to the next stage.

We have a normative dependency on this draft for our
PMIP6 IPv4 support document. I hope this will be
cleared in the timely manner.

If there are concerns on the approach this document
takes w.r.t not adopting a generic transition solution,
future work can define alternate solutions based on
generic transition solutions, IMO. That should not stop
this work, My 2c.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 22 Aug 2007 12:00:31 -0500

I have reviewed the latest draft and I believe it is in a good shape.

However, as I mentioned to Hesham earlier, the new proposed mechanism
for addressing the IPv4 CoA using a separate option, requires the use of
the MN IPv6 HoA as a source address for the IPv6 header. This is a new
functionality on the HA and if we all ok with that, then there is no
issue.

Thanks.

Regards,
Ahmad

> Sent: Monday, August 06, 2007 5:14 PM
> Cc: Gopal Dommety; [email-masked]; Basavaraj Patil; 
> [email-masked]
> Subject: [Mip6] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt
> 
> 
> Hello,
> 
> Mobile IPv6 support for dual stack Hosts and Routers 
> (DSMIPv6) <draft-ietf-mip6-nemo-v4traversal-05.txt>
> 
> URL:

---

From: Keiichi SHIMA <[email-masked]>
Date: Mon, 27 Aug 2007 20:30:14 +0900

Hello,

I've read draft-ietf-mip6-nemo-v4traversal-05.  The draft seems good  
to me basically.

Here are some (maybe minor) comments for the draft.  Since many other  
people have already reviewed the draft, some comments are duplicated  
or have already been pointed out previously.  Because it is difficult  
to check which comments are duplicated, I just send all my comments  
here.

----
page 3, 2nd paragraph:

"Using this specification, mobile nodes would only need Mobile IPv6  
and [NEMO] to manage mobility"

=> "Using this specification, mobile nodes would only need [MIPv6]  
and [NEMO] to manage mobility"

----
page 6, 3rd paragraph:

"In case the home agents are behind a NAT box, there are two options,  
1)configure a public IPv4 address for each home agent on the NAT box,  
2) configure one public address and make the home agents share the  
public address."

=> I don't understand the case 2).  Why can we share one public IP  
address between multiple HAs behind a NAT box?  Maybe some more  
description is needed?

----
page 7, Section 2.3.1, first paragraph:

"Effectively, the mobile node establishes two different tunnels, one  
for its IPv4 traffic (IPv4 in IPv6) and one for its IPv6 traffic  
(IPv6 in IPv6) with a single binding update."

=> I'm not sure the wording 'the mobile node establishes two  
different tunnels' is good, although I understand what the author  
wants to say.  In my sense, the tunnel is only one (the IPvX in IPv6  
tunnel when in the IPv6 Internet, or the IPvX in IPv4 tunnel when in  
the IPv4 Internet).

----
page 8, Section 2.3.2:

"A mobile node SHOULD NOT assume that its IPv4 address is globally  
unique if a NAT device was not detected."

=> Do we need to mention this in this draft?  It seems to me that the  
above fact doesn't have anything to do with the DSMIPv6 draft.

----
page 8, Section 2.3.2.1, 1st paragraph:

"The binding update will contain the mobile node's IPv6 home address."

=> "The binding update will contain the mobile node's IPv6 home  
address in the source address field of the inner header."

----
page 9, 1st paragraph:

"The binding update is encapsulated to the IPv4 care-of address"

=> "The binding acknowledgment is encapsulated to the IPv4 care-of  
address"

----
page 9, 1st paragraph:

"(represented as an IPv4-mapped IPv6 address in the binding update)"

=> "(represented as an IPv4 source address encapsulating the binding  
update)"

----
page 9, Section 2.3.2.2, 3rd paragraph:

"All entries MUST point to the mobile node's IPv4 care-of address  
included in the source address of the IPv6 packet and represented as  
an IPv4-mapped IPv6 address."

=> "All entries MUST point to the mobile node's IPv4 care-of address  
included in the IPv4 Care-of Address option in the binding update."

----
page 9, Section 2.3.2.2, 3rd paragraph:

"that includes the home agent's IPv4 address in the source address  
field and the mobile node's IPv4 careof address in the destination  
address field."

=> "that includes the home agent's IPv4 address in the source address  
field and the global address of the NAT box to which the mobile node  
is attached."

----
page 10, Section 2.3, 2nd paragraph:

"That is, traffic addressed to the mobile node's IPv4 home address."

=> incomplete sentence?

----
page 14, in the description of the 'Refresh time':

"If set to zero, it is ignored."

=> What does this mean?  Does it mean a mobile node has to decide the  
refresh time based on its local policy?  If so, it would be better to  
explicitly mention so.

----
page 16, about the TVL type field:

=> What is the type 3 (IPsec)?  I don't understand what it is for.   
(UDP-ESP tunnel?)

----
page 16, last paragraph:

"it compares the IPv4 address of the source address field in the IPv4  
header with the IPv4 address in the source address of the IPv6 header."

=> "it compares the IPv4 address of the source address field in the  
IPv4 header with the IPv4 address in the IPv4 Care-of Address option."

----
page 17, in the figure of the BU message format:

"BU [IPv4 HAO]
   IPv4 CoA option"

=> Shouldn't it be written as "BU [IPv4 HAO, IPv4 CoA]"? to be  
consistent with the figure B.

----
page 18, in the figure of the BA message format:

=> The ESP header is missing between 'Route HDR' and 'Mobility header'.

----
page 20, 2nd paragraph:

"- If no IPv4 address acknowledgement option were present, and an  
IPv4 home address option was present in the binding update, the  
mobile node MUST only create one binding update list entry for its  
IPv6 home address. The mobile node MAY include the IPv4 home address  
option in future binding updates."

=> This text is conflicting with the text in page 7 (see below).

"If this option is not included in the binding acknowledgement and  
the IPv4 home address option was included in the binding update, the  
mobile node MUST assume that the home agent does not support the IPv4  
home address option and therefore SHOULD NOT include the option in  
future binding updates to that home agent address."

----
page 21, Section 4.5, 3rd paragraph:

"In order to comply with this specification, the home agent MUST be  
able to find the IPv4 home address of a mobile node when given the  
IPv6 home address. That is, given an IPv6 home address, the home  
agent MUST store the corresponding IPv4 home address if a static one  
is present. If a dynamic address were requested by the mobile node,  
the home agent MUST store that address (associated with the IPv6 home  
address) after it's allocated to the mobile node."

=> When I first read this paragraph, I could not understand what it  
meant.  Once I completed reading the Security Consideration section,  
I finally understood that the paragraph was talking about security  
binding between the IPv6 HoA and IPv4 HoA.  If the draft has some  
more text in this paragraph, it would be better.

----
page 22, last paragraph:

"When sending IPv4 packets to When mobile nodes in an IPv6 network,  
the home agent must encapsulate the IPv4 packets in IPv6."

=> broken sentence?

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
WIDE Project <[email-masked]>