Subject: [Mip6] More comments on draft-ietf-mip6-nemo-v4traversal-00.txt

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Oct 2005 16:40:20 +0200

Hello to authors of draft-ietf-mip6-nemo-v4traversal-00.txt,

Thanks for providing this draft.  I understand it is the result of the
mip6trans DT and wanted to say thanks to the team as a whole.

I have some comments.

> The current Mobile IPv6 specification and [NEMO] do not allow mobile
>  nodes to use an IPv4 home address or prefix, respectively.

That is largely true.  Note though that recently there is a personal
draft on NEMO for IPv4 home prefix that uses MIP4 and no MIP6.

> Mobile IPv6 offers a number of improvements over Mobile IPv4, mainly
>  due to capabilities inherited from IPv6. For instance, route 
> optimization and Dynamic home agent discovery can only be achieved 
> with Mobile IPv6.

Maybe exemplify MIP6 superiority on MIP4 by something else than DHAAD,
itself being questioned by the dhaad-harmful discussions, and
acknowledged by this draft's section 2.1.

I mean, on one hand the draft says DHAAD is an advantage of MIP6 over
MIP4 and on antoher hand same draft says HA Discovery is not really
specified.

RO is another case.  There are no widely deployed RO-enabled CNs while
IPv4 non-RO CNs are plenty, so one can't really claim MIP6 is superior
to MIP4 because it has RO.

> We also assume that the Home Agent is always reachable through a 
> globally unique IPv4 address.

I would like a DSMIPv6 solution to assume that the HAv6 is only
reachable by its v6 address.  That would help widespread adoption of
IPv6 by offering one less dependency on IPv4.

In case the MN has v4-only applications on it, and needs to continuously
accessed IPv4 Home Address then I suggest porting these applications to
IPv6.  In this case MIP6 is used as an advantage of IPv6: if an
application is ported from IPv4 to IPv6 then it gets ability to run
uninterrupted and use a permanent Home Address, and does not need MIP4.

> For DNS lookup by service, the SRV record defined in [BOOT] is 
> reused.  For instance, if the service name is "mip6ha" and the 
> protocol name is "ipv6" for the SRV record, the mobile node SHOULD 
> send a DNS request with the QNAME set to "mip6ha.ipv6.example.com". 
> The response should contain the home agent's FQDN(s) and may have the
>  corresponding 'AAAA' and 'A' records enclosed as well.

This is another discussion, but I just mention it here.  This method for
HAD does not specify a means for the HAs to co-operate with each other
to establish their preferences.  With DNS-based it is left entirely to
the MN to choose among the HAs addresses.

> 2.3.1 Foreign network supports IPv6

This scenario is not described in the initial list of scenarios at 1.2
"Scenarios considered by this specification".  Section 1.2 only lists
access networks as IPv4.

> 4.1. NAT detection and traversal

This section is very important for proper working of NAT detection and
traversal.  However, it has some issues right now.

> The binding acknowledgement, and all future packets are then
> encapsulated in UDP and IPv4. The source address in the IPv4 header
> is the IPv4 address of the home agent. The destination address is the
> IPv4 address received in the IPv4 header encapsulating the binding
> update (this address will be different from the IPv4 care-of address
> if a NAT were present in the path).
> 
> Upon receiving the binding acknowledgement with the NAT detection 
> option, the mobile node sets the tunnel to the home agent to UDP 
> encapsulation.

Actually there is more to happen between the two paragraphs.  Current
implemented NATs have no idea about this draft, so they don't currently
implement it.

A NAT needs to know a way for forwarding the BAck from the HA to MN.
The v4 dst address in that UDPv4-encapsulated BAck is the NAT address
itself.  In order for NAT to forward the packet to MN (and re-write the
IPv4 dst address) it sometimes uses port numbers.  That's why UDP.  Or,
there's no mention of UDP numbers in this section.

And, when port numbers are used to facilitate ip address rewriting by
NAT, they are not fixed, they're dynamically changing.  Which would
demand more enhancement to this section.

> "Dual Stack Mobile IPv6 (DSMIPv6)"

The title may not be very adapted.  It makes one somehow think about
Dual-Stack MIP4 and MIP6, since 'dual-stack' is usually 'IPv4 stack and
IPv6 stack'.  Or, the mechanism proposed is more about enhancing MIP6
with some v4 features.  Maybe "v4-enhanced MIP6" would be better.

Alex

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

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 24 Oct 2005 17:57:13 +0200

Hi Alexandru,

on 2005-10-24 16:40 Alexandru Petrescu said the following:
[...]
> draft on NEMO for IPv4 home prefix that uses MIP4 and no MIP6.

Right.  But that isn't in the current spec, which is the base for what
this draft is attempting to expand.  We should check the draft you
refer to (name?) to make sure good ideas are incorporated in the
v4traversal work, though.

> acknowledged by this draft's section 2.1.

Humm?  The draft says "Dynamic home agent discovery", not DHAAD.  We've
been keeping up with what's being proposed in the bootstrapping work.

> to MIP4 because it has RO.

No?  So the future potential of RO is of no interest?

> IPv6 by offering one less dependency on IPv4.

If we're trying to solve the problem of providing MIPv6 functionality
for a MN / MR which only has IPv4 access, it is not a solution to say
that the HA only is reachable through a IPv6 address...

Or have I misunderstood the drift of your comment??

> uninterrupted and use a permanent Home Address, and does not need MIP4.

I think this still does not in any way solve the problem of a MIPv6
MN/MR which finds itself in a visited network with only IPv4 access...

> the MN to choose among the HAs addresses.

No.  Look at the SRV specification again.  It provides for priorities
between multiple choices, and fallback to backup hosts if the preferred
ones are down.

> "Scenarios considered by this specification".  Section 1.2 only lists

Should be fixed.

> implemented NATs have no idea about this draft, so they don't currently

No NAT should ever implement this draft.  I think there's some mis-
understanding here.

> there's no mention of UDP numbers in this section.

??  You can't have UDP encapsulation without UDP numbers.  I don't
understand...

> demand more enhancement to this section.

Hmm.  I don't see that.  MIPv4 NAT traversal (RFC 3519) definitely works,
and the protocol as described here uses the same basic mechanism.

Could you suggest some text?

> with some v4 features.  Maybe "v4-enhanced MIP6" would be better.

Agreed.  That should be fixed in the next revision.

	Henrik

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Oct 2005 20:16:43 +0200

> v4traversal work, though.

The draft I'm referring to proposes a message extension to MIP4
Registration Request and Reply such as to carry Mobile Network Prefixes,
or home prefixes.  The name of the draft is
http://www.ietf.org/internet-drafts/draft-leung-nemov4-base-00.txt

> been keeping up with what's being proposed in the bootstrapping work.

Oh, sorry terminology error on my part.  "Dynamic home agent discovery"
sounds so much like DHAAD of RFC3775 so I may have mis-interpreted.  If
so, it still looks a bit uncomfortable to claim MIP6 is better than MIP4
because it does "Dynamic home agent discovery", an operation not yet
standardized.

But I agree I may have a different way of expecting the future than
others, so I'd avoid speculating further.

> No?  So the future potential of RO is of no interest?

It is.  What I've learned is that when IPv6 CNs get deployed they'll
most likely be RO-enabled, which would make MIP6 superiority statements
necessarily weighted by 'when IPv6 gets deployed'.

> Or have I misunderstood the drift of your comment??

Sorry, I'm not trying to drift.  The problem was initially to make a v6
MN capable to do MIP6 even if connected to a v4-only access network,
eventually through NAT.  The essential mechanism proposed in the draft
(v4 address in BU) was the original motivator.

That problem had no requirement to give v4 Home Address to a MIP6-only
MN.  To develop a solution for that initial problem, there is no need
for HA to have a public v4 address.  Requiring the HA to have a public
v4 address is further enhancing the problem.

Once a v4 and a v6 public addresses are required for HA, it leads (IMHO)
to MN to run both MIP4 and MIP6.  Running both MIP4 and MIP6 being
inefficient is questionable.

There exist no widely-deployed IPv6-only access network.  If it existed,
then it would have generated a need for MNs that run MIP6 and need a v4
Home Address to connect to a v4 HA.

> MN/MR which finds itself in a visited network with only IPv4 access...

Well, I think it does.  If all user applications on that MN are
IPv6-enabled then the MN would use only pppd/dhcpcd to get an IPv4 "CoA"
and some UDPv4 tunnelling software and a an IPv6 default route towards
the tunnel interface, and send BU through it.  Then user launches IPv6
html browser (or whatever other IPv6-enabled user application) and
continuous access to the v6 Home Address is ok.

> between multiple choices, and fallback to backup hosts if the preferred

Thanks, I have to re-check that.  I think I meant to say that the DNS
method would still require the HAs to co-ordinate amongst themselves to
tell DNS what those priorities are.  I think MIP6 doesn't say how to do
that, today.

>>"Scenarios considered by this specification".  Section 1.2 only lists

I was thinking to suggest to fix it by leaving the 'Scenarios' section
as is, because there exist no widely deployed IPv6-only access networks.

> No NAT should ever implement this draft.  I think there's some mis-

I think I've just written it as a statement and I don't suggest this
draft to modify the NATs.  I think I am in agreement with you by saying
that this draft does not modify the NATs.

> ??  You can't have UDP encapsulation without UDP numbers.  I don't

Sorry, I think I meant to say that the HA should exchange the port
numbers received in the UDP-encapsulated BU and use them to fill the
port numbers for the UDP-encapsulated BAck (src becomes dst and
viceversa).  But this may be seen as natural UDP processing...

> and the protocol as described here uses the same basic mechanism.

Oh well, I see, thanks for pointing to RFC 3519.

First, the draft has no mention of RFC 3519, so it should.  For example,
RFC 3519 has a relatively deep discussion on what happens when the
mapping is lost at NAT, a thing which should happen in this draft too.
Up to the authors to refer to the RFC or re-describe here the mechanism
to use BU/BAck as 'heartbeat' or 'keepalive'.

Second, I think RFC 3519 describes no means for MN to discover what UDP
port numbers are open at NAT.  The worst NAT I've experimented with has
very few of them; and it's not 25 nor 80, it's 1755.  My knowledge of
RFC 3519 may be not very good, please indicate if I'm wrong.

IMHO, what is needed is for both MN and HA to gain dynamic knowledge of
both the IPv4 public address of NAT _and_ the UDP port numbers that are
open at NAT.  Without that MN and HA can't communicate.

Third, RFC 3519 does describe a means to re-establish NAT state (or
mapping) when the HA does not reply.  However, it does not - and
probably can not - provide a means for NAT to explicitely indicate MN
that its state has changed.  This may have an unfortunate effect on MN,
because all it sees is that its HA does not reply back.  Or, with NEMOv6
DHAAD - again DHAAD :-) - the MN may take this lack of BAck from HA as a
need to switch to another HA.

> Could you suggest some text?

Too early for me to suggest text since what I've said above is just
recognizing some particular NAT behaviour that makes RFC 3519 not work
in all NAT cases, IMHO.

Probably the best thing I could suggest is the draft to refer to RFC
3519, in a first phase.

> Agreed.  That should be fixed in the next revision.

Thanks for noting.

Alex

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 24 Oct 2005 21:14:45 +0200

Hi Alexandru,

> http://www.ietf.org/internet-drafts/draft-leung-nemov4-base-00.txt

Right.  I know about this one.

[...]
> necessarily weighted by 'when IPv6 gets deployed'.

Ok.  (Oh, by the way, over the last 6 months the AAAA DNS queries to my
server has increased from a very low level till currently 20-25% of
the A queries, indicating that more and more IPv6 enabled boxes are
coming online.  That doesn't necessarily mean they have IPv6 connectivity,
but it's still encouraging.)

> v4 address is further enhancing the problem.

No.  Here we seem to radically disagree.  If my MN/MR has only IPv4
connectivity, the only way I can reach the HA is through a public
IPv4 address.

> continuous access to the v6 Home Address is ok.

Oh, but then you assume that there is an IPv6 tunnel interface
available, which is fine, of course, if that actually happens to be the
case in every visited network you roam into, which I strongly doubt...

So we seem to disagree on the need for this solution, not on the details
of the actual proposed solution.

> tell DNS what those priorities are.  I think MIP6 doesn't say how to do

The SRV specification permits the DNS lookup to bring back preference
information.  If the HAs want to adjust that information dynamically, on
the fly, I'm sure it can be done.  Possibly with dynamic DNS updates,
but I haven't looked into that.  I don't see that MIPv6 needs to add
anything MIPv6 specific to this.

[...]
> that this draft does not modify the NATs.

Ok, cool.

> viceversa).  But this may be seen as natural UDP processing...

Yes.

> to use BU/BAck as 'heartbeat' or 'keepalive'.

Yes, I think we will expand this section.

> RFC 3519 may be not very good, please indicate if I'm wrong.

No that's right.  Although I'd see that as a Firewall function, rather
than a NAT, but that's quibbling about words.

> open at NAT.  Without that MN and HA can't communicate.

Well, the HA expects connections at a fixed port number anyway - if you
can't connect to that, you'll have to fall back to something which
strongly resembles port-scanning; and then have a HA which listens
on all ports for your special signature, and responds to that.  Such
a mechanism would be possible, of course, but should probably be
separately specified (if at all) ...

> need to switch to another HA.

Something such as this seems close to what MIDCOM is working at; but I
haven't checked it out specifically.

> recognizing some particular NAT behaviour that makes RFC 3519 not work

Mmm.  I've not seen many failures of 3519; there are some corner
cases which will be fixed in an upcoming revision, but nothing relevant
to this.  The problem you describe comes more under Firewall traversal
than NAT traversal; especially if you have to scan to find port 1755,
and then configure your server to listen to that port...  I don't think
we should go there, as part of mip6-nemo-v4traversal.

> Probably the best thing I could suggest is the draft to refer to RFC

Oh, we will, I'm sure.

>> Agreed.  That should be fixed in the next revision.

Sure.

Regards,

	Henrik

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Oct 2005 11:25:05 +0200

Henrik Levkowetz wrote:
>>>>> We also assume that the Home Agent is always reachable 
>>>>> through a globally unique IPv4 address.
>>>> 
>>>>  reachable by its v6 address.  That would help widespread 
>>>> adoption of IPv6 by offering one less dependency on IPv4.
>>> 
>>> If we're trying to solve the problem of providing MIPv6 
>>> functionality for a MN / MR which only has IPv4 access, it is not
>>>  a solution to say that the HA only is reachable through a IPv6 
>>> address...
>>> 
>> Sorry, I'm not trying to drift.  The problem was initially to make
>>  a v6 MN capable to do MIP6 even if connected to a v4-only access 
>> network, eventually through NAT.  The essential mechanism proposed
>>  in the draft (v4 address in BU) was the original motivator.
>> 
>> That problem had no requirement to give v4 Home Address to a 
>> MIP6-only MN.  To develop a solution for that initial problem, 
>> there is no need for HA to have a public v4 address.  Requiring the
>>  HA to have a public v4 address is further enhancing the problem.
> 

It sounds logical that when needs MN to reach the de-capsulating Gateway
that latter needs a v4 address.  Remark though that that Gateway that
strips out the the inner IPv6 packet of its UDPv4 header does not need
to be the IPv6 HA.  Which gives the possibility for the HA to be a box
different than the Gateway, and thus the HA to run IPv6 exclusively.  It
is a good thing to have the v6 HA separated from the de-capsulating Gateway.

If we require the HA to run both IPv4 and IPv6 it means that the HA can
not be placed in an IPv6-exclusively network.

>> IPv6-enabled then the MN would use only pppd/dhcpcd to get an IPv4
>>  "CoA" and some UDPv4 tunnelling software and a an IPv6 default 
>> route towards the tunnel interface, and send BU through it.  Then 
>> user launches IPv6 html browser (or whatever other IPv6-enabled 
>> user application) and continuous access to the v6 Home Address is 
>> ok.
> 
> available, which is fine, of course, if that actually happens to be 
> the case in every visited network you roam into, which I strongly 
> doubt...

I am assuming that an IPv6-in-UDPv4 tunnel interface is possible in the
MN, whenver MN connects to a v4-exclusively network.  When the MN
connects to a network that is v6-capable that tunnel is not put up.

I doubt it's impossible to have a IPv6-in-UDPv4 tunnel interface that MN
uses whenever connecting to a v4-only network.  The MN can even receive
RAs on that interface that are sent by the Gateway (the Gateway
maintains the other IPv6-in-UDPv4 tunnel interface).

> So we seem to disagree on the need for this solution, not on the 
> details of the actual proposed solution.

We seem to disagree on the possibility/impossibility to have double
encapsulation IPv6-in-IPv6-in-UDPv4 performed by MN.  We haven't yet
discussed advantages/disavdntages of using IPv6-in-UDPv4.

>  information.  If the HAs want to adjust that information 
> dynamically, on the fly, I'm sure it can be done.  Possibly with 
> dynamic DNS updates, but I haven't looked into that.  I don't see 
> that MIPv6 needs to add anything MIPv6 specific to this.

Yes, HAs could do DNS updating to update that information at the DNS
servers, but what is not specified is how the HAs achieve that
co-ordination amongst themselves.  MIP6 does not specify a way for the
HAs to decide priorities amongst them; it does however offer a tool to
exchange info with the H bit in the RAs.

>> Second, I think RFC 3519 describes no means for MN to discover what
>>  UDP port numbers are open at NAT.  The worst NAT I've experimented
>>  with has very few of them; and it's not 25 nor 80, it's 1755.  My
>>  knowledge of RFC 3519 may be not very good, please indicate if I'm
>>  wrong.
> 
> 
> No that's right.  Although I'd see that as a Firewall function, 
> rather than a NAT, but that's quibbling about words.

Right, I think it is obvious that most deployed NATs in commercial
networks employ firewall filtering as well.

>> IMHO, what is needed is for both MN and HA to gain dynamic 
>> knowledge of both the IPv4 public address of NAT _and_ the UDP port
>>  numbers that are open at NAT.  Without that MN and HA can't 
>> communicate.
> 
> 
> Well, the HA expects connections at a fixed port number anyway - if 
> you can't connect to that, you'll have to fall back to something 
> which strongly resembles port-scanning;

I'd name that "UDP path discovery" or "dynamic tunnel setup" instead of
"port-scanning" which has a negative reasonance (port-scanning is what
an outside attacker does to find open ports and exploit buffer overflows).

> and then have a HA which listens on all ports for your special 
> signature, and responds to that.  Such a mechanism would be possible,
>  of course, but should probably be separately specified (if at all) 
> ...

Well, I think without it the NAT traversal alone is less applicable.

>> probably can not - provide a means for NAT to explicitely indicate
>>  MN that its state has changed.  This may have an unfortunate
>> effect on MN, because all it sees is that its HA does not reply
>> back. Or, with NEMOv6 DHAAD - again DHAAD :-) - the MN may take
>> this lack of BAck from HA as a need to switch to another HA.
> 
> 
> Something such as this seems close to what MIDCOM is working at; but
>  I haven't checked it out specifically.

I think so.  NAT explicitely instructing MN about state change is
probably better dealt with by MIDCOM.  Here we may want to make sure
that NAT discovery does not interfere with BU/BAck error processing.

>>  recognizing some particular NAT behaviour that makes RFC 3519 not
>>  work in all NAT cases, IMHO.
> 
> 
> cases which will be fixed in an upcoming revision, but nothing 
> relevant to this.  The problem you describe comes more under Firewall
>  traversal than NAT traversal; especially if you have to scan to find
>  port 1755, and then configure your server to listen to that port...
>  I don't think we should go there, as part of mip6-nemo-v4traversal.

I understand the oppinion, it's good to conceptually separate.

Personally, I'm for stripping out other parts from mip6-nemo-v4traversal
(e.g. strip out  v4 access to MN, to LFN, connect to a v6-network) and
concentrate more on the connect to v4-only network case, with more
NAT/FW traversal features - that's what deployments with the largest
number of wireless mobile nodes do.

Let me exemplify those here for sake of completeness:

All providers of Internet access to wireless mobile nodes (WiFi, GPRS,
UMTS) I've tried do one the following:

-offer a v4 address that is private behind NAT, or offer a public v4
 address.  But in both cases, the address is subject to change whenever
 either a re-connection is made (pppd or dhcpd) by the user or the
 connection is lost due to wireless changes.  The access to wireless
 mobile nodes I've tried does not have the ability to provide a
 permanent v4 address (like the ISP at home may provide).  However, in
 the GPRS and UMTS cases the address is stable with respect to changing
 Base Stations.
-use firewalls between MN and Internet, with various ports blocked.

Alex

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 25 Oct 2005 11:39:11 +0200

Hi Alexandru,

[...]
> not be placed in an IPv6-exclusively network.

Yes.  Which is why we write that the HA must be reachable through
an IPv4 address, instead of writing that the HA must have and IPv4
address on an interface.

> maintains the other IPv6-in-UDPv4 tunnel interface).

Hmm.  Now you have a new animal here, a IPv6-in-UDPv4 tunnel.  I think
at this point it is appropriate to check whether you have read
draft-larsson-v6ops-mip-scenarios-01?  I think we cover a lot of
ground there that we seem bound to go over again here if you
haven't read it...

> discussed advantages/disavdntages of using IPv6-in-UDPv4.

Well, I'll disagree on your statement here - I don't think this is
our disagreement :-)

> exchange info with the H bit in the RAs.

Agreed.

> networks employ firewall filtering as well.

Yes.  But calling it a NAT problem confuses the issue, when it is
a Firewall problem.

> an outside attacker does to find open ports and exploit buffer overflows).

Ok.

> Well, I think without it the NAT traversal alone is less applicable.

Marginally.

> that NAT discovery does not interfere with BU/BAck error processing.

NAT discovery and NAT keepalives are separate things.  I agree that
NAT keepalives are needed, with sufficient frequency and some
adaptability.

> I understand the oppinion, it's good to conceptually separate.

Ok.

>  the GPRS and UMTS cases the address is stable with respect to changing

This scenario we can handle with MIP and NAT traversal.

> -use firewalls between MN and Internet, with various ports blocked.

This is harder, and the best is probably to vote with your feet - i.e.,
choose providers which don't do such silliness, as far as possible.

	Henrik

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Oct 2005 12:21:55 +0200

Henrik Levkowetz wrote:
>> If we require the HA to run both IPv4 and IPv6 it means that the HA
>> can not be placed in an IPv6-exclusively network.
> 
> Yes.  Which is why we write that the HA must be reachable through an
> IPv4 address, instead of writing that the HA must have and IPv4 
> address on an interface.

I am surprised by the formulation?!

Ok, so the HA must be reachable through a v4 address, not necessarily
have an IPv4 address on an interface, I agree.

[...]
>>> available, which is fine, of course, if that actually happens to
>>> be the case in every visited network you roam into, which I
>>> strongly doubt...
>> 
>> I am assuming that an IPv6-in-UDPv4 tunnel interface is possible in
>> the MN, whenver MN connects to a v4-exclusively network.  When the
>> MN connects to a network that is v6-capable that tunnel is not put
>> up.
>> 
>> I doubt it's impossible to have a IPv6-in-UDPv4 tunnel interface
>> that MN uses whenever connecting to a v4-only network.  The MN can
>> even receive RAs on that interface that are sent by the Gateway
>> (the Gateway maintains the other IPv6-in-UDPv4 tunnel interface).
> 
> Hmm.  Now you have a new animal here, a IPv6-in-UDPv4 tunnel.  I
> think at this point it is appropriate to check whether you have read 
> ground there that we seem bound to go over again here if you haven't
> read it...

Ok, I quickly skimmed through it.  Nice work.  It includes discussion of
various way of encapsulating v6 in v4.  Should I understand that I'm
directed to this draft for its evaluation of IPv6-in-UDPv4 has higher
transport overhead, which is an inefficiency?

I am not sure I understand what - other than the claimed inefficiency -
are the disadvantages of using IPv6-in-UDPv4 tunnel interface.

I could explain further what I mean by IPv6-in-UDPv4.  The MN maintains
a virtual interface called u0, the Gateway too.  This interface is IPv4
and IPv6 enabled.  All packets MN sends to its u0 will be encapsulated
by tunnelling software into UDPv4 and sent to the Gateway, which
decapsulates.  The tunnelling software on Gateway dynamically puts up
its u0 and parametered with the local/remote IP addresses and port
numbers.  Same on the MN.  Additionally the Gateway sends IPv6 RAs on
that interface, so the MN can auto-configure a CoA and do MIP6 mobility
unmodified.  I don't see anything wrong with that.

>>  encapsulation IPv6-in-IPv6-in-UDPv4 performed by MN.  We haven't
>> yet discussed advantages/disavdntages of using IPv6-in-UDPv4.
> 

So what is our disagreement?

> Yes.  But calling it a NAT problem confuses the issue, when it is a
> Firewall problem.

Ok, I'll call it a Firewall problem and suggest to be dealt with in this
document.

>>> signature, and responds to that.  Such a mechanism would be
>>> possible, of course, but should probably be separately specified
>>> (if at all) ...
>> 

Ok, let me put it other way: this document is useless without Firewall
traversal.

Ok.

>> Personally, I'm for stripping out other parts from
>> mip6-nemo-v4traversal (e.g. strip out  v4 access to MN, to LFN,
>> connect to a v6-network) and concentrate more on the connect to
>> v4-only network case, with more NAT/FW traversal features - that's
>> what deployments with the largest number of wireless mobile nodes
>> do.
>> 
>> All providers of Internet access to wireless mobile nodes (WiFi,
>> GPRS, UMTS) I've tried do one the following:
>> 
>> -offer a v4 address that is private behind NAT, or offer a public
>> v4 address.  But in both cases, the address is subject to change
>> whenever either a re-connection is made (pppd or dhcpd) by the user
>> or the connection is lost due to wireless changes.  The access to
>> wireless mobile nodes I've tried does not have the ability to
>> provide a permanent v4 address (like the ISP at home may provide).
>> However, in the GPRS and UMTS cases the address is stable with
>> respect to changing Base Stations.
> 
> 

I agree, but I wanted to say that MN's v4 public address is more subject
to change than when the v4 address is private (the NAT public v4 address
is more stable).  Which in the context of IPv6-IPv6-in-UDPv4 tunnel
means some dynamic adaptation.  But I think we don't agree about
IPv6-in-IPv6-in-UDPv4 in the first place.

> This is harder, and the best is probably to vote with your feet -
> i.e., choose providers which don't do such silliness, as far as
> possible.

Well I often do what my bank allows me to do, and the cheaper cell
wireless subscriptions are the ones that are most firewalled.  The most
expensive subscriptions are the ones where I could have my own Firewall
rules.  The cheapest subscriptions are the ones used by the largest
number of people, so potential wider deployment for this solution if it
addresses the Firewall aspects.

Alex

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 25 Oct 2005 13:04:35 +0200

Hi,

[...]
> are the disadvantages of using IPv6-in-UDPv4 tunnel interface.

Personally I think it's the overhead both in tunnelling and setup.
There may be complexity and deployment issues, too, but those have
had less scrutiny.

> unmodified.  I don't see anything wrong with that.

This sounds very close to Pascal Thubert's Doors proposal, which has
been discussed in the design team, without the team settling on one
proposed solution yet.

> So what is our disagreement?

The need for a different solution than the MIPv6-integrated 
IPv6-in-UDPv4 solution proposed in the current draft.

> Ok, I'll call it a Firewall problem and suggest to be dealt with in this

Right.  I believe that this problem is both large and complex, and
would delay the current document for a year or more.  I'd rather
see this as a separate activity.

> Ok, let me put it other way: this document is useless without Firewall

Useless?  Hmm.  Disagreement.

[...]
> is more stable).

Agreed.

> Which in the context of IPv6-IPv6-in-UDPv4 tunnel

Agreed.  But consider this:  If you're talking about cellular services,
rather than in general, it's not even a classic firewall issue, as
some (most?) cellular operators will open and close ports dynamically
dependent on what other services you are using at the time.  So the
only ports found open in that case will probably be the ones you are
already using for a service, and thus not necessarily available for
another service, or with more than one server...

	Henrik

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Oct 2005 14:10:22 +0200

Hello Henrik,

Henrik Levkowetz wrote:
>> I am not sure I understand what - other than the claimed
>> inefficiency - are the disadvantages of using IPv6-in-UDPv4 tunnel
>> interface.
> 

Ok.

>> I could explain further what I mean by IPv6-in-UDPv4.  The MN
>> maintains a virtual interface called u0, the Gateway too.  This
>> interface is IPv4 and IPv6 enabled.  All packets MN sends to its u0
>> will be encapsulated by tunnelling software into UDPv4 and sent to
>> the Gateway, which decapsulates.  The tunnelling software on
>> Gateway dynamically puts up its u0 and parametered with the
>> local/remote IP addresses and port numbers.  Same on the MN.
>> Additionally the Gateway sends IPv6 RAs on that interface, so the
>> MN can auto-configure a CoA and do MIP6 mobility unmodified.  I
>> don't see anything wrong with that.
> 

Yes, it is very close to Pascal's proposal.

>>>>> So we seem to disagree on the need for this solution, not on
>>>>> the details of the actual proposed solution.
>>>> 
>>>> We seem to disagree on the possibility/impossibility to have
>>>> double encapsulation IPv6-in-IPv6-in-UDPv4 performed by MN.  We
>>>> haven't yet discussed advantages/disavdntages of using
>>>> IPv6-in-UDPv4.
>>> 
>>> Well, I'll disagree on your statement here - I don't think this
>>> is our disagreement :-)
>> 

Right, we don't agree on the need for a different solution than the one
presented in the draft.  We haven't discussed the security of it either.

>>>>> No that's right.  Although I'd see that as a Firewall
>>>>> function, rather than a NAT, but that's quibbling about
>>>>> words.
>>>> 
>>>> Right, I think it is obvious that most deployed NATs in
>>>> commercial networks employ firewall filtering as well.
>>> 
>> Ok, I'll call it a Firewall problem and suggest to be dealt with in
>> this document.
> 
> would delay the current document for a year or more.  I'd rather see
> this as a separate activity.

Ok, UDP path discovery through arbitrary Firewalls may be large and
complex and may take too long time to specify.  And if the users of this
document are satisfied with it without UDP path discovery - I'm fine.

>>>>> and then have a HA which listens on all ports for your
>>>>> special signature, and responds to that.  Such a mechanism
>>>>> would be possible, of course, but should probably be
>> Ok, let me put it other way: this document is useless without
>> Firewall traversal.
> 

Probably 'useless' was too strong a word.

It is important to identify who are the potential users of the solution
described in this draft.

>> wireless subscriptions are the ones that are most firewalled.  The
>> most expensive subscriptions are the ones where I could have my own
>> Firewall rules.  The cheapest subscriptions are the ones used by
>> the largest number of people, so potential wider deployment for
>> this solution if it addresses the Firewall aspects.
> 
> 
> Agreed.  But consider this:  If you're talking about cellular
> services, rather than in general, it's not even a classic firewall
> issue, as some (most?) cellular operators will open and close ports
> dynamically dependent on what other services you are using at the
> time.  So the only ports found open in that case will probably be the
> ones you are already using for a service, and thus not necessarily
> available for another service, or with more than one server...

Even in that case, the dynamic behaviour of the Firewalls could be
discovered dynamically by the MN, at least in theory, and in some
manually-helped automatic practical cases.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Oct 2005 19:40:04 +0200

Henrik Levkowetz wrote:
>>> No.  Here we seem to radically disagree.  If my MN/MR has only
>>> IPv4 connectivity, the only way I can reach the HA is through a
>>> public IPv4 address.
>> 
>> It sounds logical that when needs MN to reach the de-capsulating
>> Gateway that latter needs a v4 address.  Remark though that that
>> Gateway that strips out the the inner IPv6 packet of its UDPv4
>> header does not need to be the IPv6 HA.  Which gives the
>> possibility for the HA to be a box different than the Gateway, and
>> thus the HA to run IPv6 exclusively.  It is a good thing to have
>> the v6 HA separated from the de-capsulating Gateway.
>> 

The draft also says that the MN sends packets to the HA IPv4 address in
section 4.2 "Mobile node operation":
> - The destination address in the IPv4 header is the home agent's IPv4
> address.

What I am trying to suggest is that a v6 HA does not need to be
connected directly on a v6 network.  Moreover, there exist v6-only
infrastructure networks and they're supposed to grow, and the v6 HAs may
very well live there.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Oct 2005 19:54:43 +0200

Alexandru Petrescu wrote:

>>> possibility for the HA to be a box different than the Gateway,
>>> and thus the HA to run IPv6 exclusively.  It is a good thing to
>>> have the v6 HA separated from the de-capsulating Gateway.
>>> 
>>> If we require the HA to run both IPv4 and IPv6 it means that the
>>> HA can not be placed in an IPv6-exclusively network.
>> 
>> 
> The draft also says that the MN sends packets to the HA IPv4 address
> in section 4.2 "Mobile node operation":
> 
>> - The destination address in the IPv4 header is the home agent's
>> IPv4 address.
> 
> 
> connected directly on a v6 network.
                          ^^^
Sorry I meant v4, "a v6 HA does not need to be connected directly on a
                   v4 network".

> Moreover, there exist v6-only infrastructure networks and they're
> supposed to grow, and the v6 HAs may very well live there.

Alex

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 25 Oct 2005 20:28:29 +0200

Hi,

[...]
>> - The destination address in the IPv4 header is the home agent's IPv4

Right, needs fixing.

> infrastructure networks and they're supposed to grow, and the v6 HAs may

No-one's disagreeing, as far as I know.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 25 Oct 2005 20:29:42 +0200

on 2005-10-25 19:54 Alexandru Petrescu said the following:
[...]
> Sorry I meant v4, "a v6 HA does not need to be connected directly on a

Well, no-one's disagreeing with this either, as far as I know :-)

	Henrik