Ed Jankiewicz escribió:
3. Deemphasize dual stack. In para 2.1.1 the statement "the IETF strongly prefers and recommends [dual stack] as the operational matters are simplest" begs for a citation. RFC 4213 says dual stack is the most straightforward but does not include language recommending or preferring this solution. Also the impetus of this draft is that dual stack solves only the simplest part of the problem, and becomes very problematic when IPv4 addresses really get scarce (approaching rather than reaching exhaustion). Some have already stated (Alain Durand I recall saying something like) "a plan that requires all new end-nodes to be dual-stack and to have global IPv4 addresses is a non-starter." Also an emphasis on dual stack creates a "must carry" situation where the core network continues to route IPv4 indefinitely. While we say in para 2.2 that turning off IPv4 will be a business decision, the ISP can't make that choice without alienating customers that rely on dual stack. I can still plug in a 50 year old rotary dial phone and expect the local telco (in the USA at least) to make it work, even though DTMF has been the dominant method for nearly that long.not disagreeing with the recommendation - see Brian's comment and my response, also Remi's remarks relate. If we say "the IETF strongly prefers and recommends..." that needs to be justified with a citation. If there isn't a published statement to that effect, this draft can simply make the case, as you do in your comment.i understand that this was what the document was reccomendingBest option, native connectivity i.e. talk to v4 hosts using native v4 and talke to v6 hosts using native v6, hence dual stackSecond best option, tunnel. this keeps packet unchanged Third option, translation do you think this is the wrong reccomendation to make?This draft does focus on the translation case as a last resort where dual stack or tunneling do not solve the problem. Maybe we just need explicit statement of the applicability of each class of solution right up front in the introductory paragraphs.
I am a bit confused at this pointIt seems that we all agree that native is better and tunnel should be used if not possible and the last option should be nat.
This is what imho it is contained in the document and it succintly explains it
what changes do you think need to be made?
i will try to expand on how we can make requirements for the different scenarios.yes. my gut feeling is that solutions could be rather difficult if the deployment is restricted to "one foot firmly planted" in v6 versus v4, i.e. if the translator can assume everything on one side is restricted to v4 or v6 rather than an unrestricted topology. I have not studied all the solution space drafts (apbp and ds-lite) that may address some of the differences. It seems the unrestricted topology (in-network scenario c) starts to fall into the same traps as NAT-PT. not to reopen what might be settled - but it does seem like a generic "problem statement" draft that encompasses the taxonomy of approaches would still be useful, while a set of requirements drafts defining the solution space would be as well. To some extent we are reverse engineering the proposed solutions into a problem statement.4. tunnel versus dual NAT: in para 2.1.2 the statement that IETF recommends tunnels rather than dual NAT - that also would need a citation, unless this document is making the statement for the first time. Also, I believe if the two NATs know they are in a reflexive relationship, they can avoid at least some of the general NAT problems - i.e. they should not attempt to translate addresses in application data.5. translation network architecture: this may be beyond scope, but it seems to me that in para 2.1.3 there could be several sub-scenarios depending on the location of the translator a. translator coupled to IPv6 end-nodes (IPv6 on the LAN side, IPv4 on the WAN side) b. translator coupled to IPv4 end-nodes (IPv4 on the LAN side, IPv6 on the WAN side)c. in-network translation gateway (most like NAT-PT)There are some commercial products in development that fit these sub-scenarios, and each has its own strengths and weaknesses. Pulling the translator into an IPv6-only or IPv4-only edge network (a or b) avoids some issues and those developers made the choice to restrict deployment architecture to simplify their job. The different deployment architectures also have impact on the addressing concerns (para 3.3) and namespace (para 3.4).i don't understand the scenarios you mention aboveI mean, for me a would be mostly nat64 and b would be mostly nat46 and c is the sum of bothI am now considering having two different sets of requirements, one for nat64 and another for nat46, would that make sense to you?
but the problem is that it is not that the nat will do something in the flow that it shouldn't but rahter that it is important to expose somehow the fact that using a given address would result in translated connectivity tot he end host, so it can make an informed decision, that is why i don't think expressing it in the negative form fully captures what we want to dayjust a style point - I prefer that when introducing something new into an architecture, the new thing is explicitly forbidden to interfere with pre-existing functionality. The new thing has no positive requirement to enable that functionality but is required NOT to interfere with it. If the native flow bypasses the translator, it does nothing; if the native flow is through the translator it must be passed without modification, another flavor of "do nothing" or "first, do no harm."7. Requirement R3 would be better stated in the negative: Translation mechanism MUST NOT interfere with native connectivity...depending where the NAT64 is in the network it may be a pass-through, or it may not be involved at all in the native flow and thus do nothing but non-interference.right, so why is this not expressed in the current form
i will wait fo rthe text yo promised below... regards, marcelo
8. Requirement R4 is very broad. the essence of translating DNS in support of NAT64 is to map a query on one side to the equivalent query on the other, and do the same with the response. Of course that mapping of names and addresses is non-trivial. It might help to illustrate this mapping process as well as some of the bad behavior that must be avoided.so any suggestion how to rephrase it?I'll follow up with some language.true - the v6 addresses used in the mechanism should not require new routing table entries. I definitely agree on the badness of importing the v4 table.9. Requirement R5 seems to forbid any routing table update, but don't the addresses that the NAT64 is mapping have to be routable?no, i don't think it is what it means, I think the goal here is to preclude mechanisms that would for instance map each v4 prefix into a different v6 prefix and that for some reason cannot be aggregated. If such a mechanism would exist, then we would importing all the v4 routing table into v6, which would be a bad idea. But certainly the v6 addresses that are used to map v4 addresses need to be routable. I mean, think about the deprecated natpt, it does not requires additional global routing table entries, right?10. Requirement R6 lists a few protocols, but I'm sure others might be seen as highly desirable too. Are we avoiding ALG issues by not mentioning higher level protocols like FTP?No, the idea here was to mention the very basci protocols and go into the application level protocols. Do you think we should try to list all the application level protocols thta should be supported? that seems difficult to meagreeddefinitely cite RFC 4942, and I will try to come up with some language which can go in the Security Considerations section. The onus will be on the solutions developers to show how each solution at least does no harm.11. where does the interpretation in Requirement R7 that sees the IPv6 side being like the private side of an IPv4 NAT come from?This only applies to behave requirements I think this is the most stringent way of seeing this.I mean, take a look in endpoint independence. this makes sense if the v4 is the public address. If the v6 is the public address, then we are likely to easily satisfy this and we are likely to require more that just endpoint indepdence, but we are requiring a stable one to one association, between the v4 address and the v6 addres,s cause we can provide tha cause we have enough v6 addresses.So, all these requireemtns that are means to express difficult tradeoffs make sense when the v4 side is the public address. If the v6 is the publci address, we are likely to have much more stringent requirements than thosethe opposite could be reasonable too - i.e. if there is no NAT between the NAT64 and the v4-only nodes the v4-only nodes might be using private addresses, and the IPv6 side of the NAT64 is the public side. The way it is described in R7, the IPv6 addresses are like IPv4 private addresses, mapped to the global addresses on the public side.i am not sure what you would like to see here... could you provide some more explicit guidance?12. Requirement R9 is a noble statement but hardly a "testable" requirement; at least we should cite RFC 4942 as guidance, and analyze some of the security issues that arise in the different scenarios and architectures discussed in the draft.Regards, marcelo