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

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 18 Jul 2008 15:22:34 -0400

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.

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..."

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.

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).

6.  para 3.5 on market timing seems out of place as an 
implementation/deployment statement in a requirements draft

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.

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.

9.  Requirement R5 seems to forbid any routing table update, but don't 
the addresses that the NAT64 is mapping have to be routable?

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?

11.  where does the interpretation in Requirement R7 that sees the IPv6 
side being like the private side of an IPv4 NAT come from?   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.

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Jul 2008 15:26:53 +1200

Ed,

> e.g. coexistence scenarios, coexistence tools, etc.

Yes. As some of us having been saying for *many* years, in my case, since
RFC 1671.

> tunneling.  

I deny that. I personally have always expected many years of coexistence,
and I don't know where this "settled opinion" was to be found.

> Operationally, we now expect..."
> 
> this solution.  

That doesn't belong in that document. You're possibly correct that no
IETF document formally states the strong preference for dual stack as
the coexistence mechanism, but it's the implicit assumption throughout
pretty much everything NGTRANS and V6OPS have done. I don't think we
should rewrite history, and dual stack is still the best way we know
(for reasons stated in RFC 1671, which of course has absolutely no
authority whatever).

> Also the impetus of this draft is that dual stack solves
> and to have global IPv4 addresses is a non-starter."  

Correct, but that argues for more v4/v4 NAT, not against dual stack.

> Also an emphasis

Bingo. I'm sure ISPs will still be routing IPv4 for 15 years; not so
clear about 50.

> i.e. they should not attempt to translate addresses in application data.

If you mean by "reflexive" that the NAT mapping is reversed before delivery,
sure, that's invisible to the upper layer and is isomorphic with a tunnel.
But do such devices exist?

The IETF definitely recommends avoiding irreversible NAT when possible,
and therefore the statement that tunnels are preferred is definitely true.

   Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 19 Jul 2008 19:56:45 +0200

Hi Ed,

thanks for the feedback

some comments in line...

Ed Jankiewicz escribió:
> substantive comments (some admittedly half-baked) and discussion 
> points to raise on the draft.  I'm assuming there will be discussion 
> at IETF 72?
>
> 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...

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

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

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

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

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

Regards, marcelo

---

From: Rémi Després <[email-masked]>
Date: Mon, 21 Jul 2008 16:03:34 +0200

> Correct, but that argues for more v4/v4 NAT, not against dual stack.

Brian,

  The role of dual stack during the coexistence period might IMHO be
somewhat clarified, and also simplified, as follows:

- Host capabilities
  o DS (ASAP)
  o IPv6-only (eventually, but slow start)

- Router capabilities
   o DS (ASAP)
   o IPv6-only (eventually, but slow start)

- Interworking functions (at least before global IPv4 shortage)
   . Dual-stack lite carrier grade NATs (DSL-CGNs)
   . Dual-stack lite Public address servers (DSL-PASs)

  The former are those of draft-durand-dual-stack-lite-00. (In ISP
infrastructures, they involve carrier grade NAT44s. In IPv4/IPv6 tunnels
between customer sites and these NATs, packets contain private IPv4
addresses of customer sites.)

  The latter are those of draft-despres-v6ops-apbp-01, renamed here to
clarify their relationship with DSP-CGNs. (In ISP infrastructures, they
involve Public Address Servers, to which public IPv4 addresses can be
borrowed together with some limited ranges of ports. In IPv4/IPv6
tunnels between customer sites and these servers, packets contain public
IPv4 addresses that have been borrowed. If the CPE is a router, it
includes its NAT44; if it is a host, there is no NAT in the path.)

  IMHO, if CGNs are deployed, NAT64 and NAT46 are no longer necessary, 
but I understand that this is a subject for debate.

  This view is submitted as an exploratory contribution.

Regards.

Rémi

---

From: Ed Jankiewicz <[email-masked]>
Date: Mon, 21 Jul 2008 11:14:01 -0400

Thanks for the feedback, see comments in-line

> Yes. As some of us having been saying for *many* years, in my case, since
I can't recall who it was, recently I heard a songwriter say "I always 
been described as 'ahead of my time' but unfortunately, there is no line 
at the bank with that label..."  It seems like there is rough consensus 
that coexistence is the right term.
> and I don't know where this "settled opinion" was to be found.
Fair enough, no need to over-analyze the motivation since it is already 
agreed that this work needs to be done.  The "settled opinion" is more 
folkloric than historic.
> (for reasons stated in RFC 1671, which of course has absolutely no
agree.  either we justify the statement by citing authoritative source 
(apparently non-existent) or remove it.
> Correct, but that argues for more v4/v4 NAT, not against dual stack.
perhaps a v4/v4 NAT that includes v6 pass-through, if you mean 
dual-stack end-nodes with private v4 address space. 

What I meant by "dual stack solves only the simplest part of the 
problem" is that it permits coexistence of IPv4 and IPv6 nodes and 
simultaneous native IPv4 and IPv6 interactions, but it leaves the 
knottiest problems - how to facilitate interaction of IPv4-only nodes 
with IPv6-only nodes or applications.  While the former do and will 
dominate for some time, the latter are theoretical.  That is a bigger 
problem than just address mapping that a v4/v4 NAT could solve.  There 
is no one size fits all approach.  Dual stack and tunneling should cover 
the preponderance, address mapping much of the rest, leaving the 
residual to translation as a last resort. 

> and therefore the statement that tunnels are preferred is definitely true.
Translators definitely exist and I have had discussions with developers 
about that kind of deployment scenario - it has been considered but not 
implemented (that I know of) to add the intelligence to the translator 
to pair up like this.  Good point, it is effectively like tunneling with 
substitution of header rather than wrapping.  I can't see reflexive NAT 
having any advantage over tunneling, so it is more of an academic 
discussion.

as I said, some of my comments were half-baked:  reflexive NAT is not 
truly reversible, but could effectively be within a v4v6v4 scenario that 
carries the v4 address as part of the v6 mapping.

---

From: Ed Jankiewicz <[email-masked]>
Date: Mon, 21 Jul 2008 12:09:35 -0400

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 
ok, I agree that current opinion has accepted reality of long term 
coexistence.
>> 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 
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.
>> relationship, they can avoid at least some of the general NAT 
>> problems - i.e. they should not attempt to translate addresses in 
>> application data.
>>
>> it seems to me that in para 2.1.3 there could be several 
>> sub-scenarios depending on the location of the translator
>> 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 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.
> seems a pretty reasonable statement to me... 
no I don't object to keeping it, it is relevant to the topic.
>> 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."
>> 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 
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?
>>
> 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 
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.
> 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
> 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 
> 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
>> 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.
>>
>> 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.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Jul 2008 11:38:48 +0200

Ed Jankiewicz escribió:
>> Best option, native connectivity i.e. talk to v4 hosts using native 
>> v4 and talke to v6 hosts using native v6, hence dual stack
> 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.
>
> explicit statement of the applicability of each class of solution 
> right up front in the introductory paragraphs.

I am a bit confused at this point

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

>>> 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 
>>> different deployment architectures also have impact on the 
>>> addressing concerns (para 3.3) and namespace (para 3.4).
>>>
>> I mean, for me a would be mostly nat64 and b would be mostly nat46 
>> and c is the sum of both
>>
> 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.
i will try to expand on how we can make requirements for the different 
scenarios.

> 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."
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 day

i will wait fo rthe text yo promised below...

regards, marcelo

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