[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: v6ops-nat64-pb-statement-req: Scoping and title
Ed Jankiewicz escribió:
commenting to foster discussion in particular about the title and
scope of the problem statement/requirement draft. this has come up in
other comments as well, in particular Rémi on 7/23.
It seems to me the problem statement needs to be general: need for
translation at some point in the network; the current title includes
NAT64, which already makes some assumptions about solution approach.
I would rather see the problem statement (and title) generalized. I
like Rémi's suggestion of "IPv4/IPv6 Coexistence Scenarios -
Requirements for Translation Mechanisms."
will do then
On the other hand, the requirements section of this draft would be a
good place to start distinguishing among the solution approaches.
Rather than spinning off separate documents (which we could always do
at some future point) a sub-section for NAT64 specific requirements
and another for NAT46 (at least) would be appropriate, and avoid
duplication of general requirements that apply to both.
i will do a proposal for this in the ml and see what people think
As it is there are already a lot of solution drafts circulating, and
being discussed in too many places (behave, v6ops and intarea) to keep
up. I'm not complaining about the attention it is finally getting,
because I strongly believe v4-v6 coexistence tools is a really big
hurdle we need to clear, but I would like us to maintain focus on
defining the problem and general requirements, and this draft seems to
be the right place to do that.
I am assuming that NAT64=="v6 initiated communication" and NAT46=="v4
mmm, i think the term has evolved
initially, i think that nat64 meant a new version of natpt but now we
make a distinction between nat64 and nat46 as you say
we could expliclty state it this way in the document if you think so
However a translator is built, it would have to be cognizant of
particular requirements depending on which side initiates.
Restricting it to one or the other simplifies the problem, but this
draft would not rule out an implementation that meets both. I think
Thomas's point that one set of requirements would need a lot of
scoping language (do X if v6 initiated but X' if v4...) which would be
easier to handle in two separate lists tailored to each. Vertical
rather than horizontal slicing...
ok, let me try to come up with something
marcelo bagnulo braun wrote:
Thomas Narten escribió:
my take is that this is possible to achieve for v6 initiated
communications (i.e. when AAAA RR are synthesized)
I don't think that it is achievable for v4 initiated communications
(i.e. when A RR are synthesized)
it is not so trivial for the v4 case though (actually i think it is
not possible for the v4 case, hence the question mark)
In other words, the MUST needs some serious scoping. If it makes
sense at all.
I'm still not sure this requirement is acheivable in practice.
I am lately thinking that we need two different lists of requirements
one for v4 initiated communications and another one for v6 initiated
communications especially for dealing with dns requirements. In v4
initiated communications the state in the nat box has close
relationship with the RR synthesis, while in v6 initiated
communication they are completely decoupled, which makes possible to
satisfy most of the dns requirements.
so, what do you think?