Subject: [BEHAVE] comments on draft-mrw-behave-nat66-00.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 04 Nov 2008 11:25:23 +0100

Hi Margaret,

I read the draft and i think it is a good starting point to work and 
disucss NAT66.

One thing that i think should also be included are some nat related 
features, such as how filtering, hairpining and the such are supported. 
Probably, as Remi suggested, going through the NAT requirements doen in 
behave and understand how each of these is achieved and how would be a 
good to be sure that all issues are covered.

Some more detailed comments below.

In section

   The use of separate
   internal and external address prefixes creates complexity for DNS
   deployment, due the desire for internal nodes to communicate with
   other internal nodes using internal addresses, while external nodes
   need to obtain external addresses to communicate with the same nodes.
   Typically, this results in the deployment of "split DNS", which has
   it's own set of architectural implications [Ref Needed].

This is true, indeed, but i guess you will support hairpinning, so, 
packet would be delivered, if you provide the external address, only 
that they will be routed through the nat box.

In section 3.  Motivations
 
   Some enterprises may choose to deploy
   IPv6 NAT to gain provider independent internal addressing or to
   simplify site multihoming.

I don't find it so straight forward to understand why multihoming is 
included here. Maybe soem text describing this would be good.

Later on, in section

   In its simplest form, a NAT66 device will be attached to two network
   links, one of which is an "internal" network link attached to a leaf
   network within a single administrative domain, and the other of which
   is an "external" network with connectivity to the global Internet.

Do we need to define an internal side and an external side? I mean, in 
nat44, this is the case, but i am not fully convinced that it is the 
case for nat66. I mean, i think nat66 is symetric and all operations can 
be performed in either direction.

LAter on you describe the 5.1.2.  Topology Hiding Option

I like this approach, cause it preserver the endpoint independence.
However, i wonder if this actually achieves all the goals that people 
are looking w.r.t. topology hiding. I mean, one "feature" of NAT is that 
if you establish multiple sessions, all come from the same IP address, 
so you don't know if it is one or multiple host establishing these 
communications and you cannot correlate the different communications of 
a single internal node. I understnad that this cannot be achieved even 
with the topology hidding option.
I think it would be important to describe what can and cannot be 
achieved with this option, so we can discuss whether this is enough or not.

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

---

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

On Nov 4, 2008, at 5:25 AM, marcelo bagnulo braun wrote:

> features, such as how filtering, hairpining and the such are  
> supported. Probably, as Remi suggested, going through the NAT  
> requirements doen in behave and understand how each of these is  
> achieved and how would be a good to be sure that all issues are  
> covered.

This is an excellent suggestion, and I will look at this.  Thanks to  
both you and Remi.

> that they will be routed through the nat box.

Yes, we should definitely requiring that hairpinning be supported by  
NAT66 devices.

> included here. Maybe soem text describing this would be good.

With NAT, you can assign one address prefix to the internal network  
and use more than one external prefix.  This simplifies internal  
configuration, because it isn't necessary to configure multiple  
prefixes on every router and configure multiple addresses for internal  
nodes in ACLs, etc.  NAT doesn't do anything to make the multihoming  
work, it just helps to simplify configuration when a site is  
multihomed.  I agree that my text is pretty unclear on that point, and  
I will fix it.

> Do we need to define an internal side and an external side? I mean,  
> in nat44, this is the case, but i am not fully convinced that it is  
> the case for nat66. I mean, i think nat66 is symetric and all  
> operations can be performed in either direction.

True.  We don't need to define internal/external for the default  
mapping.  If one chooses to use the topology hiding option, though, I  
think that one will have to pick an internal side (the hidden side)  
and an external side (the unhidden one).

> However, i wonder if this actually achieves all the goals that  
> people are looking w.r.t. topology hiding. I mean, one "feature" of  
> NAT is that if you establish multiple sessions, all come from the  
> same IP address, so you don't know if it is one or multiple host  
> establishing these communications and you cannot correlate the  
> different communications of a single internal node. I understnad  
> that this cannot be achieved even with the topology hidding option.

I think it makes sense to discuss what the actual requirements are for  
topology hiding.  This is not a requirement that has been shared with  
me directly by an enterprise administrator, I have simply read about  
it in RFC 4864, so I am not aware of exactly what the requirement is.

I was picturing the topology hiding NAT66 option as part of a solution  
that also included IPv6 privacy addresses, thus hiding the internal  
network structure and which node is involved in each connection.   
However, privacy addresses are not widely deployed or used, so maybe  
it is a mistake to rely on them?

In any case, you are correct that even the combination of NAT66  
topology hiding and privacy addresses would not make it look like all  
of the traffic came from a single node.  Of course, none of the  
solutions in RFC 4864 would make it look like that either...  In fact,  
I am not sure how you would get that effect without storing the  
demultiplexer in the transport layer header (AKA port mapping), which  
we are trying to avoid.

So, I think we need to better understand the requirements, so that we  
can produce a solution that meets them.

Margaret

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 04 Nov 2008 10:13:27 -0600

Margaret Wasserman escribió:
> and use more than one external prefix.
but still connections don't survive when you change the prefix being 
used, cause this is visible to the other end, right?
So, nat can help you with establishing new connections after a fialure 
but cannot help you to preserve established sessions, right?

> This simplifies internal configuration, because it isn't necessary to 
> configure multiple prefixes on every router and configure multiple 
> addresses for internal nodes in ACLs, etc.  NAT doesn't do anything to 
> make the multihoming work, it just helps to simplify configuration 
> when a site is multihomed.  I agree that my text is pretty unclear on 
> that point, and I will fix it.
>
>> Later on, in section
>>
right

>> are looking w.r.t. topology hiding. I mean, one "feature" of NAT is 
>> that if you establish multiple sessions, all come from the same IP 
>> address, so you don't know if it is one or multiple host establishing 
>> these communications and you cannot correlate the different 
>> communications of a single internal node. I understnad that this 
>> cannot be achieved even with the topology hidding option.
not sure, but i agree that usingt hese two togehter makes sense... btw i 
don't recall seeign privacy extensions on the draft... (just checked and 
at least they don't show up in the references... so it may be good to 
incldue those as part of the solution)

> can produce a solution that meets them.
right, but meanwhile that the requirements are not clear, we can 
describe the options and understnad the trade offs. that actually helps 
sometimes to define the requirements

Regards, marcelo