[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ipv6-v6ops-nat64-pb-statement-req-00
some follow-up in line, also see my response to Brian's points not
repeated here.
marcelo bagnulo braun wrote:
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...
ok, I agree that current opinion has accepted reality of long term
coexistence.
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?
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.
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.
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?
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.
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...
no I don't object to keeping it, it is relevant to the topic.
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
just 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."
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.
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?
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.
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
agreed
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?
definitely 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.
Regards, marcelo
--
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research
Supporting DISA Standards Engineering Branch
732-389-1003 or ed.jankiewicz@sri.com