[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D Action:draft-bagnulo-v6ops-6man-nat64-pb-statement-01.txt
On 2008/03/10, at 4:58, Rémi Després wrote:
Marcelo,
Sorry to comment so late: I was very busy these days and wanted to
comment in details. The draft is important.
On many points my views are slightly different,or even substantially
different, but as you said the goal was to promote discussion :-) .
Detailed comments follow.
Rémi
marcelo bagnulo wrote :
the goal of the draft is to promote discussion and in particular tune
the requirements
comments are very welcome, in particular, feedback from people
exploring solutions would be great
3.5 Market timing considerations
I agree that adequate NAT mechanisms are needed in router-CPEs so that
the need to add new functions in host stacks can be delayed.
Agree.
FYI.
In many japanese office, they use the terminals for 5 years or more
once they
were installed. Ordinary personal users are also.
But I also believe that host stacks should have more mechanisms to
satisfy transition requirements when they are not behind router-CPEs.
Once these mechanisms are agreed on, they should IMHO be implemented
as
early as feasible, by patch or otherwise, in PCs and other portable
devices.
Yes, I also want to ask users or vendors to update their device asap.
But we may have exception. Following case should be considered well too.
# I had some opportunity to talk with home appliance vendor.
# They said "please don't expect us to upgrade the firmware once it
has shipped."
4. and 5. Requirements that MUST be and SHOULD be supported.
This is the most useful part of the document.
R1
Ambiguous wording (see 2. above).
But agreement that, v4-only servers should not be required to change.
Agreement also that hosts MAY need transition mechanisms (they even
SHOULD, to operate at v6-only addresses that are not behind router-
CPEs).
R2
Yes for outgoing and incoming connections of v4 applications in hosts
without permanent v4-addresses .
No for "v6 initiated" connections
R3
Yes on the preference for v6 when there is the choice.
R4
Could be part of R1 ?
R5
Yes if it means that no DNS-ALG should be needed.
R6
Yes on the non propagation of routing-prefix proliferation from v4
to v6.
R7
Yes for the support of TCP and UDP (and any protocol above)
IMHO a stronger requirement is possible, namely that transition
mechanisms that depend on v6 deal with only with address-port couples,
with no specific ALG.
(Note that v4 FTP ALGs are not v6 related; they belong to v4 and will
have to remain for long.)
I agree that FTP ALG is very useful.
And most of people would like to use it.
But I agree on not mentioning on specific application protocol as
a basic requirement of Marcelo's document.
Now various applications are working over IP and this document
attempt to focus on them.
IMHO. FTP ALG should be an optional.
thanks,
...miyata
R8
Yes for the need to specify timeout requirements of proposed
solutions.
R9
No on the need to support fragmentation (costly over-killing IMHO)
R10
Yes to say that connections that don't use transition specific
mechanisms should not have less security with the deployment of
transition specific mechanisms.
I1
DNS sec could be covered in a modified R7
I2
No (see 3.2)
I3
Yes on the need to support auto-configuration in CPEs using DHCP.
Central management seems to me ambiguous.
I4
No. See R9.
I5
Yes on the need to support applications that handle both remote and
local address-port couples.
I6
Could MIPv6 be covered in a modified R7 ? (I am not sure).
I7
SCTP could be covered in a modified R7
I8
DCCP could be covered in a modified R7
I9
There should be no more constraint related to multicast than in the
case
of v4 NATs.
Whether this can be said "not to prevent multicast" is unclear to me.
4.3 Non Goals
Yes, IPsec (which is not a protocol using address-port couples) should
be kept off-scope.