Part 2 of my review.
Technical:
I wonder if the draft should say something more about MTU handling. In
particular, should it attempt to inform clients on its inner interface
of the real MTU so that fragmentation is not needed. Here's what RFC
5844 said in a very similar situation.
o The DHCPOFFER message [RFC2131] sent to the mobile node MUST
include the Interface MTU option [RFC2132]. The DHCP servers in
the Proxy Mobile IPv6 domain MUST be configured to include the
Interface MTU option. The MTU value SHOULD reflect the tunnel MTU
for the bidirectional tunnel between the mobile access gateway and
the local mobility anchor.
(Though I wonder if this text is right either, as presumably you have to
ask for options before handing them out...)
8.1. NAT pool
AFTRs MAY operate distinct, non overlapping NAT pools. Those NAT
pools do not have to be continuous.
This text is unclear. Are you talking about different AFTRs operating
with different sets of public address pools? Or one AFTR running for
some set of clients, using a number of different address pools? Or
assigning a public address for one client from different pools for
different connections? These are all different, and I think you mean the
second alternative but I'm not sure.
Please specify.
The AFTR should only perform a minimum number of ALG for the classic
applications such as FTP, RTSP/RTP, IPsec and PPTP VPN pass-through
and enable the users to use their own ALG on statically or
dynamically reserved ports instead.
First off, shouldn't this be written as "... should only implement a
minimum ..."
The more substantial comment is that the recommendation is very weak. I
do not know if the application list above is complete or if I am
expected to implement additional ALGs. Secondly, are there RFCs that we
can point to for these ALGs? Finally, I do not know how to provide the
use-own-alg functionality. But I'm reading on, maybe its described later
in the document.
There is an important operational difference if those N ports are
pre-allocated in a cookie-cutter fashion versus allocated on demand
by incoming connections. This is a difference between an average of
N ports and a maximum of N ports. Several service providers have
reported an average number of connections per customer in the single
digits. At the opposite end, thousands or tens of thousands of ports
could be use in a peak by any single customer browsing a number of
AJAX/Web 2.0 sites.
Is your argument assuming a traditional web browsing usage model, i.e..,
that users actively use an application and that the computer sits idle
at other times? I am not sure this the model we have going forward. Many
popular applications are starting to update content and perform various
actions even when the browser sits idle, for instance. I think there
will still be a difference between average and maximum, though it is
perhaps not as pronounced over the time dimension but could still be
very visible between users.
In order to achieve higher address space reduction ratios, it is
recommended that service provider do not use this cookie-cutter
approach, and, on the contrary, allocate ports as dynamically as
possible, just like on a regular NAT.
Given the above, perhaps the text should warn that in order for this
trick to work at all, there really has to be a difference either in the
between-users or the time dimension, and that trends in networking may
easily reduce either one.
When dynamic port assignment is used to maximize the number of
subscribers sharing the AFTR global IPv4 addresses, the AFTR should
implement checks to avoid DOS attack through exhaustion of available
ports.
How?
Editorial:
In broadband home networks, sometime devices are directly connected
Sometimes? Some devices?
Under this scenario, the customer device is a dual-stack capable host
that is only provisioned by the service provider only with IPv6.
Would this be better: "... is provisioned by the service provider only
with IPv6"?
Jari
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
