[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt
Hi Phillip,
thanks for the review
I am trying to work on your comments but i havne't been able to actually
reflect any changes in the document so far... see below
Philip Matthews escribió:
Some comments on this draft, from the perspective of someone familiar
with the various BEHAVE documents.
* R6 lists TCP, UDP, ICMP, and TLS as protocols to be supported. I am
surprised that TLS is listed in addition to TCP, since full TCP
support would imply TLS.
is this so?
If yes, it seems that needs to be removed, should we?
I am also surprised that DTLS is not listed, if listing TLS is seen as
necessary. Any explanation for this?
* R7 lists the BEHAVE requirement documents for TCP and UDP. Is there
some reason for not listing the BEHAVE requirement document for ICMP?
well, behave req for tcp and udp are included to make sure that ICE works
do we need to comply with icmp reqs to make ice work?
is there other reasons why we should include icmp reqs?
* R8 talks about fragmented packets. Is there some reason to include
this specifically, given that the BEHAVE requirements cover
fragmentation in some detail?
do you think that we should simply refer to the behave document for this
and remove this req?
aren't the behave req v4 specific? i mean, do they apply to v6 fragments?
The BEHAVE requirements do not mention the 5 second stuff, but they
talk about out-of-order fragments which R8 does not mention.
the current version covers in order and out of order packets
* I6 and I7 talk about SCTP and DCCP support. Is it acceptable to
support these by transporting them over UDP?
don't know, do you think we need to be explicit about it? why?
* I8 talks about multicast. Should multicast support comply with the
BEHAVE requirement document for multicast?
don't know, what do you think?
* A (long) comment on R2.
There is a class of applications that work today through NAT44s. As a
general rule, these are applications that do not carry addresses
embedded inside protocol messages, and have communication initiated by
the host behind the NAT. Is this the same class of applications that
should be supported by the proposed translation mechanism?
well, i think it is a subset, cause we only require client server with
v4 clients. p2p communications are considered in I4, cause they require
host support
Code in a NAT that recognizes packets of a specific application
protocol and does special processing of that packet is known as an ALG
(Application Level Gateway). The BEHAVE group considers an FTP ALG to
be acceptable, because FTP was there before NATs, but other ALGs are
discouraged (= default off). Is this rule consistent with the proposed
transition mechanism? This rule is given in RFC 4787, which R7 says
the mechanism must comply with.
If so, is R2 an attempt to formalize all this in different words?
i don't think so, as i mention above, it seems more restricitive than that
Regards,marcelo
- Philip
On Tue, 13-May-08, at 19:30 , Internet-Drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IPv6 Operations Working Group of the
IETF.
Title : IPv4/IPv6 Coexistence and Transition:
Requirements for solutions
Author(s) : M. Bagnulo, et al.
Filename : draft-ietf-v6ops-nat64-pb-statement-req-00.txt
Pages : 17
Date : 2008-05-13
This note presents the problem statement, analysis and requirements
for solutions to IPv4/IPv6 coexistence and eventual transition in a
scenario in which dual stack operation is not the norm.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nat64-pb-statement-req-00.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<mime-attachment>