Re: [shara] Follow up on Layer2-Aware NAT (draft-miles-behave-l2nat-00)

Pierre,

Thanks for the support. The presentation of draft-nishitani-cgn-01
outlined a good way forward - here the Network Model was separated from
the core NAT Function. I think a L2-Aware NAT best belongs in a core
document like this.
In this way L2-Aware NAT could make up an optional component of the core
NAT Function (in the way it describes a Virtual NAT [tables] facility).
On top of this a variety of network models could be created and
documented - these could even come from other working groups (such as
Softwires).I believe a core NAT function (regardless of whether we
describe IPv4 or IPv6) fits well in BEHAVE. 

Applying the mechanisms in L2-Aware NAT to PRR makes a lot of sense as
well - I'm wondering if port-range solutions could be described (perhaps
poorly) as similar to a NAPT mapping function (outside-ip/port to
inside-ip/port) however in the case of PRR, the pairs are the
same/common - in effect a address/port translation does not occur. What
do you think of attempting to describe the PRR function like this?

If agreeable I would like to invite the authors of PRR/A+P and CGN
drafts to work within the bounds of a new draft that describes a core
NAT function (without drawing reference to size or scale) - introducing
elements of core NAT function (CGN/LSN) virtual NAPT tables (L2-Aware
NAT), and mappings tables where translation is not applied (PRR).

Best Regards,

-David

-----Original Message-----
From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] On Behalf
Of pierre.levis@orange-ftgroup.com
Sent: Thursday, March 26, 2009 6:17 AM
To: behave@ietf.org; shara@ietf.org
Subject: [shara] Follow up on Layer2-Aware NAT
(draft-miles-behave-l2nat-00)

The comment I had on the mike during behave session 2:

This kind of work is very valuable, it is worth not only for CGN but
also for Port Ranges solutions and for all IPv4 shortage solutions. 
As we presented it in the shara BoF all solutions basically:
1) Put a dedicated function in an ISP Box (CGN, PRR, whatever)
2) Use some sort of transport mechanism (tunneling, layer 2, whatever)
between customers and ISPBox, 
3) Are confronted with the same issues: how to force a route from
customers to ISPBox, how to route back from ISPBox to relevant customer,
how to identify the customer. 

This would advocate for seeing all work related to IPv4 shared addresses
host in the same place, under the same ombrella.

Regards

Pierre
_______________________________________________
shara mailing list
shara@ietf.org
https://www.ietf.org/mailman/listinfo/shara