Subject: Re: [BEHAVE] I-D Action:draft-mrw-behave-nat66-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Nov 2008 16:11:02 +1300

Gritting my teeth...

> 4.  NAT66 Overview
...
>    All of the hosts on the internal network will use addresses from a
>    single, locally-routed prefix, ...

I don't see why there's any need for this restriction, which violates
my understanding of IPv6 addressing architecture. If you'd written
the following, I'd have been happy:

   All of the hosts on the internal network that communicate with a
   given instance of NAT66 will use addresses from a single locally-
   routed prefix. As in any IPv6 network, they may simultaneously
   have other addresses from other prefixes.

(This would also allow a site to have multiple instances of NAT66
translating different prefixes. There's no reason why not.)

> 6.  Prefixes for Internal Addressing
> 
>    IPv6 includes a form of local addressing called Unique Local
>    Addresses (ULAs) [RFC4193], and it is RECOMMENDED that ULAs be used
>    to address network nodes that are located on an internal network
>    serviced by a NAT66 device.

Why is that RECOMMENDED? I can't see any reason whatever why there's
any rule other than the local network MUST use a valid prefix.
Using a ULA prefix as a default solution is fine, of course.

On a related point, what is wrong with a configuration where
a site uses a PA prefix from ISP #1, with a standard (non-NAT66)
connection to ISP #1, and uses a NAT66 connection to ISP #2, to
get multihoming without polluting BGP4?

Bottom line: let's not constrain NAT66 addresses just yet.

> 8.  Security Considerations

How about citing RFC4864 again here, as a source of security
suggestions - most of them apply to a NAT66 site.

One general suggestion - how about adding a health warning
section, listing residual bad side effects of NAT that
NAT66 does not avoid.

     Brian
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 4 Nov 2008 10:42:31 -0500

Hi Brian,

> Gritting my teeth...

Hey, I was holding my nose the whole time I wrote the draft, which  
made typing a bit tricky... :-)
> translating different prefixes. There's no reason why not.)

I realized, from some other feedback I received, that giving only the  
one "simplest" example was leading people to think that this was the  
only way NAT66 was designed to work.  I've added a few additional  
examples in the -01 version (with ASCII art TBD), but I didn't think  
to add one where nodes have other addresses.  I agree, though, that  
this makes sense and would work.  I will add an example along these  
lines after Minneapolis if there is consensus before/during  
Minneapolis is that we should go forward with this work.

> Bottom line: let's not constrain NAT66 addresses just yet.

Okay.  Your example makes sense.  The thing I was trying to recommend  
_against_ was using global unicast address prefixes internally that  
don't (permanently) belong to the enterprise.  For example, an  
enterprise shouldn't just run with their current provider-allocated  
prefixes and NAT using that prefix as the internal prefix when they  
change providers, because later that prefix may be reallocated to  
someone else.  We should reword this section to encompass your  
example, though.

> suggestions - most of them apply to a NAT66 site.

Will do.

> section, listing residual bad side effects of NAT that

I do have a paragraph along those lines, but I could elaborate on it  
in a section.  One issue with this type of section, though, is that we  
(the IETF) don't seem to have a good, widely accepted reference for  
what problems are caused by NAT44.  So, it is hard to be sure we are  
documenting an exhaustive list.

Margaret

---

From: Rémi Després <[email-masked]>
Date: Tue, 04 Nov 2008 17:34:17 +0100

> someone else.  We should reword this section to encompass your 
This configuration is very close to that in section 4.2.3 of the new 
draft on SAM (draft-despres-sam-01).

The difference is that, with SAM,  ISP #2 can be accessed via an 
automatic tunnel rather than via a NAT66 if it uses a source address 
with a PA prefix of ISP #2. This makes it possible to use SCTP, IMO 
something important for the future.

In my proposal, the host may also require NAT66 traversal, by using a 
privacy address as source address. I would  appreciate reactions on 
this, and an opportunity to discuss it in Minneapolis.

Regards,
RD