Subject: (ngtrans) Re: draft-durand-ngtrans-nat64-nat46-00.txt

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Jun 2002 10:51:19 +0300 (EEST)

Hi,

A few comments (in addition to the private one: this looks quite a bit 
like SIIT).

General comment:

NAT46 applicability is very different from v4->v6 NAT-PT; I'm not sure is 
that is considered in enough detail (note: personally I think v4->v6 
NAT-PT is quite useless).

NAT46 must be deployed at connecting IPv4 user's domain; it cannot be 
deployed by someone providing IPv6 services who wants to enable IPv4 
access to those.  This is IMO significant difference which implies 
different usage scenarios.

1. Balkanization of the Internet.

==> please split this to a few paragraphs :-)

2. Problem statement.
   As the number of services that an IPv6 only node may require from the
   IPv4 Internet is potentially large, it will make sense to try to find
   a solution at the IP layer that will work for all services.

==> 'all services' is awfully ambitious.  Does IPv4 NAT work for all 
services?  For applications that work higher than IP layer require more 
than IP layer solutions.. :-)
 
   This memo is proposing a scalable layer 3 solution to enable
   communication initiated by any IPv6-only node to any unmodified
   IPv4-only node or the other way round with minimum configuration in
   the network and very minimum configuration (zero if possible) on the
   end nodes and without introducing any new security problems.

==> I hope you realize that the solution does not fulfull the 
requirement for no new security problems?

6. Security considerations

==> Please have a look at the mapped address section of:

ftp://ftp.itojun.org/pub/paper/draft-itojun-ipv6-transition-abuse-01.txt

==> In addition, using mapped address as a source hinders source address 
spoofing checks in the first (or next-) hop routers.

7. IANA Considerations
[...]
	Allocating a /8 prefix would enable 2^24 (about 16 millions)
      contexts.  Allocating a /16 prefix would enable 2^16 (about 65
      thousands) contexts.  Allocating a /24 prefix would enable 2^8
      (256) contexts.  Decision on the prefix length to allocate will be
      done in the NGtrans mailing list.

==> I'm not sure if it's correct to say the mailing list to decide which 
prefix length will be used.

In any case I think /24 would be best, as this "context" is local (this 
should be elaborated in the draft btw) in respect to IPv6 /64 prefix ad 
DNS mapper.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Alain Durand <[email-masked]>
Date: Thu, 27 Jun 2002 10:12:16 -0700

> A few comments (in addition to the private one: this looks quite a bit

  SIIT nodes use IPv4 mapped addresses as source address.
NAT64 nodes use 'regular' IPv6 addresses.

> General comment:

Thank you for your comments,

> NAT-PT is quite useless).

I agree.

> different usage scenarios.

I agree.

> ==> please split this to a few paragraphs :-)

I'll do that for next revision.

> than IP layer solutions.. :-)

You've got a point. This section needs clarification.

> requirement for no new security problems?

What new security problems do you see beyond the existing ones
in today's IPv4 + NAT? (see below)

> ftp://ftp.itojun.org/pub/paper/draft-itojun-ipv6-transition-abuse-01.txt

As it applies to Ipv6 only hosts, I do not see the problem.
Can you explain me where exactly you see the issue?

> spoofing checks in the first (or next-) hop routers.

mapped addresses are used as source only when the packet comes back
from the NAT64 box. Where is the problem?

> prefix length will be used.

This text is a place holder until the wg decide what is appropriate.
This will change in the final draft, of course.

> should be elaborated in the draft btw)

I agree, the NAT46 section needs to spell this out more clearly.

>  in respect to IPv6 /64 prefix ad
> DNS mapper.

The 'context' is local to the domain covered by the NAT46 box(es).
For small sites, /24 with 256 contexts should be plenty. If you want
to have a large network (like an IPv4 GPRS network)
behind a NAT46, that may not be enough...

One avenue I was exploring was to reserve 3 prefixes, as in RFC1918,
and have people choosing the one that is appropriate,

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 28 Jun 2002 10:56:07 +0300 (EEST)

> NAT64 nodes use 'regular' IPv6 addresses.

NAT64 translates responses so that the source address of an IPv4-only 
node is an IPv4 mapped address.  That means that nodes must accept mapped 
addresses on the wire.

> in today's IPv4 + NAT? (see below)

...

> Can you explain me where exactly you see the issue?

If we define IPv6-only as "node that has only IPv6 support, and does not 
have IPv4 addresses or even support IPv4 socket options", we're safe.

But we can't.

Practically "IPv6-only" can also mean, e.g.:

 1) Dual-stack nodes which have IPv4 addresses but don't want to use them 
(e.g. testbeds)
 2) Dual-stack nodes which support IPv4 but don't have IPv4 addresses (or 
global ones anyway)
 3) etc.

In the real world, we can't assume that a technology would be used in a 
very specific scenarios only; usually if an implementor decides to support 
NAT64/SIIT in as one mechanism, he may enable the processing of mapped 
addresses on the wire for dual-stack nodes too.  Hence the problems..
 
> from the NAT64 box. Where is the problem?

The node processing the packet does not know it originated from a NAT64 
box.  It could have come from anywhere in the Internet too.

(Still, the above might confuse stricter unicast RPF checks, but there are 
problems with those anyway.)

> and have people choosing the one that is appropriate,

I'm not sure if a small prefix is a problem; then you'd just need to add 
more (independent) NAT46 boxes.