Re: comments on draft-ipv6-v6ops-nat64-pb-statement-req-00

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi Ed,

thanks for the feedback

some comments in line...

Ed Jankiewicz escribió:
> in addition to some editorial comments I sent to Marcelo, I have a few 
> substantive comments (some admittedly half-baked) and discussion 
> points to raise on the draft.  I'm assuming there will be discussion 
> at IETF 72?
>
> 1.  transition versus coexistence:  recognizing that the period of 
> coexistence is likely to be longer, I would rather see consistent use 
> of the term coexistence rather than transition throughout the 
> document, e.g. coexistence scenarios, coexistence tools, etc.
right, i will make this change, if nobody opposes

> 2.  add a sentence in front of the Problem Statement to explicitly 
> state this motivation, e.g.  "Settled opinion on the transition from 
> an IPv4-dominant network to an IPv6-dominant network was that the 
> period of coexistence would be brief, and could be accommodated by 
> dual-stack and tunneling.  Operationally, we now expect..."
I don't think this was an assumption... at least for a long period now...

> 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.
i understand that this was what the document was reccomending

Best option, native connectivity i.e. talk to v4 hosts using native v4 
and talke to v6 hosts using native v6, hence dual stack
Second best option, tunnel. this keeps packet unchanged
Third option, translation

do you think this is the wrong reccomendation to make?

> 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 above

I mean, for me a would be mostly nat64 and b would be mostly nat46 and c 
is the sum of both

I am now considering having two different sets of requirements, one for 
nat64 and another for nat46, would that make sense to you?

> 6.  para 3.5 on market timing seems out of place as an 
> implementation/deployment statement in a requirements draft
don't know, you want to remove it?
seems a pretty reasonable statement to me...

> 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?

> 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?

> 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 me

> 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 those
>    the 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.
>
> 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.
i am not sure what you would like to see here... could you provide some 
more explicit guidance?

Regards, marcelo


>