[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 initiated communication". 
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

regards, marcelo


edj

marcelo bagnulo braun wrote:

Thomas Narten escribió:
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.
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)
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?

regards, marcelo