Subject: [v4v6interim] Proposal for new BEHAVE charter

From: Magnus Westerlund <[email-masked]>
Date: Fri, 17 Oct 2008 10:58:05 +0200

Resending as some have reported issues with receiving the charter email
as an attachment. Please send any comments to BEHAVE.

/Magnus

Hi,

Together with the chairs I have drafted a new BEHAVE charter that is on
the agenda for next weeks IESG telechat for decision if it should go for
formal review. However, I like to share it with you already now so that
you can comment on it early. The goal is to have this charter in place
before Minneapolis so that the Translation work can go forward.
Therefore, resolving comments early reduced the risk in hiccups in this
process.

To make this possible we have so far excluded any specific work items on
port-borrowing or other solutions to the dual stack lite problem. BEHAVE
will be home for this discussion until it has become clear on what we
really need to do here. At that point we will make a new recharter
action to where that work would fit. It is after all likely that part of
that work belongs in other WGs.

So please provide your view on the draft charter!

Draft charter proposal submitted to IESG

The behavior of NATs varies from one implementation to
another. As a result it is very difficult for applications to predict
or discover the behavior of these devices. Predicting and/or
discovering the behavior of NATs is important for designing
application protocols and NAT traversal techniques that work reliably
in existing networks. This situation is especially problematic for end-
to-end applications where one or both end-points are behind a NAT, such
as multiuser games, interactive multimedia and P2P download.

The working group documents best current practices to enable NATs to
function in as deterministic a fashion as possible. The NAT
behavior practices will be application independent. This has already
completed for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP
and any additional protocol deemed necessary to handle. The WG has
documented approaches for characterizing and testing NAT devices.

BEHAVE will develop protocol-independent toolkits usable by application
protocols for NAT traversal. The WG has already produced an update of
the binding discovery protocol STUN. It will now produce a relay
protocol that focuses on security that is usable with both IPv4 and
IPv6, and capable of relaying between the two IP versions.

The goal of this work is to encourage migration to IPv6 and compliance
with the UNSAF [RFC 3424] considerations. To support deployments where
communicating hosts require using different address families (IPv4 or
IPv6), address family translation is needed to establish communication.
 BEHAVE will coordinate with the V6ops WG in this work.

The BEHAVE WG will design solutions for the following four translation
scenarios; other scenarios are out of scope:

1. MY IPv6 to IPv4 Internet, i.e. perform translation between IPv4 and
   IPv6 for packets in uni- or bi-directional flows that are
   initiated from an IPv6 host towards an IPv4 host. The
   translator function is intended to service a specific
   IPv6 network of arbitary size. Port translation is necessary on
   the IPv4 side for efficient IPv4 address usage.

2. IPv6 Internet to MY IPv4, i.e. perform translation between IPv4 and
   IPv6 for packets in uni- or bi-directional flows that are
   initiated from an IPv6 host towards an IPv4 host.  The translator
   function services is intended to service a specific IPv4 network
   using either private or public IPv4 addresses. Because this scenario
   has different constraints compared to (1), the WG should attempt to
   design a simpler solution with less impact on applications.

3. MY IPv4 to IPv6 Internet, i.e. perform translation between IPv4 and
   IPv6 for packets in uni- or bi-directional flows that are initiated
   from an IPv4 host towards an IPv6 host. The translator function is
   intended to service a specific IPv4 network using either public or
   private IPv4 address space.

4. IPv4 Internet to MY IPv6, i.e. perform translation between IPv4 and
   IPv6 for packets in uni- or bi-directional flows that are initiated
   from an IPv4 host towards an IPv6 host. The translator function is
   intended to service a specific IPv6 network where selected IPv6 hosts
   and services are to be reachable.

All translation solutions shall be capable of handling flows using TCP,
UDP, DCCP, and SCTP. The fundamental parts of ICMP are also required to
work. Additional protocols directly on top of IP may be supported.
Translation mechanisms must handle fragmentation.

The translators should support multicast traffic and its control traffic
(IGMP and MLD) across them, both Single Source Multicast (SSM) and Any
Source Multicast (ASM). However, the WG may determine that it becomes
too complex or too difficult to realize with maintained functionality,
for some or all cases of multicast functionality.

Translation mechanisms cannot transparently support protocols that embed
network addresses within their protocol messages without application
level gateways (ALGs). Because ALGs have security issues (like blocking
usage of TLS), are error prone and brittle, and hinder application
development, the usage of ALGs in the defined translators should be
avoided. Instead application developers will need to be aware and use
mechanisms that handle the address family translation. ALGs may be
considered only for the most crucial of legacy applications.

DNS is a crucial part in making a large number of applications work
across a translator. Thus the solution to the above translation cases
shall include recommendations for DNS. If additional DNS functionality
is needed, it may be developed. Any DNS extensions must be developed
together with the DNSEXT WG, including issuing a joint WG last call for
any documents.

The WG needs to determine the best method for providing address space to
a translator in the different deployment cases and documenting the pros
and cons of the suggested approaches. The WG is to seek input from the
Routing, Operations and Internet areas.

Solutions may solve more than one of the cases, however timely delivery
is more important than a unified solution.

Milestones:

Done	Submit BCP that defines unicast UDP behavioral requirements for
        NATs to IESG
Done	Submit a BCP that defines TCP behavioral requirements for NATs
        to IESG
Done	Submit a BCP that defines ICMP behavioral requirements for NATs
        to IESG
Done	Submit informational that discusses current NAT traversal
        techniques used by applications
Done	Submit BCP that defines multicast UDP
Done	Submit revision of RFC 3489 to IESG behavioral requirements for
        NATs to IESG
Done	Submit informational document for rfc3489bis test vectors
Done   	Submit experimental document that describes how an application
        can determine the type of NAT it is behind
Done	Submit BCP document for DCCP NAT behavior

Dec 08	Submit standards-track relay protocol to IESG

Dec 08	Submit BCP document for SCTP NAT behavior

Jan 09  Determine relative prioritization of the four translation cases.

Mar 09	Submit standards-track document for relaying of a TCP bytestream

Mar 09	Submit standard-track document of an IPv6 relay protocol to IESG

Mar 09  Determine what solutions(s) and components are needed to
        solve each of the four cases. Create new milestones for the
        solution(s) and the components.

Sep 09  Target for first solution to be submitted to IESG.

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

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

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 17 Oct 2008 10:34:13 -0400

I support this work, and I think the behave WG is the right place to  
do it.

I have  few comments in-line...

> IPv6, and capable of relaying between the two IP versions.

Is there a draft available on which this work will be based?  I'm not  
suggesting that you mention it in the charter, I'd just like to know  
which draft I should be reading for this item.

> BEHAVE will coordinate with the V6ops WG in this work.

I think it should be made clearer here whether the translation  
documents will be written in the v6ops WG or behave.  I _think_ this  
is intended to say that the documents will be written in behave, and  
that the behave WG will get input and review regarding operational   
requirements and deployability from the v6ops WG, but I'd like to see  
that made clearer.

> 1. MY IPv6 to IPv4 Internet, i.e. perform translation between IPv4 and

"MY" should be expanded or explained before it is first used.

>   and services are to be reachable.

I would also like to us write (at least) two NAT-related documents that
aren't listed here:

(1) A document that offers advice on how/when to deploy these  
translation
mechanisms vs. other choices.  I think this document would cover topics
such as:

	- If the infrastructure will support dual stack and you are running out
           of IPv4 addresses, NAT IPv4 and leave IPv6 alone.
	- The advantages of placing NATs closer to the edges of the network

(2) An explanation of how to do IPv6 <=> IPv6 NAT.  It am convinced that
there are some people who will choose to do this for the same reasons  
that
people with plenty of IPv4 addresses choose to use IPv4 <=> IPv4 NATs
today.  I think we could write a document that says something like:   
IPv6
<=> IPv6 NATs are not really necessary, don't provide any concrete  
advantages
that can't be obtained through less disruptive means, and are not  
recommended
by the IETF, but if you are planning to do this anyway, please do it  
right (don't
include port translation, use algorithmic address mapping if possible,  
instead
of state tables, etc.).

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 17 Oct 2008 15:42:34 -0700

Margaret Wasserman wrote:

...
> Is there a draft available on which this work will be based?  
> I'm not suggesting that you mention it in the charter, I'd just 
> like to know which draft I should be reading for this item.

Yes, they are:

  draft-ietf-behave-turn (nearing completion)
  draft-ietf-behave-turn-ipv6 (expired, but a new version is
                               being submitted shortly that 
                               aligns it with TURN)
  draft-ietf-behave-turn-tcp (will be discussed in Minneapolis)

...
> I would also like to us write (at least) two NAT-related 
> documents that aren't listed here:
> 
> translation mechanisms vs. other choices.  I think this document 
> would cover topics such as:
> 

Alain, Dave Thaler, Jari, and I are co-authoring a document
that will discuss when-to-translate and when-to-dual-stack-lite.

I don't know if such a document would belong in BEHAVE or
SOFTWIRES -- it spans between the two WGs.

> 	- The advantages of placing NATs closer to the edges of 

I don't believe anyone has submitted an I-D that delves into
those advantages or those disadvantages.  Certainly, there is
a lot of experience with NATs close to the edges -- those
are the NATs that Linksys/D-Link/Netgear/etc. have been 
selling for years.

> (2) An explanation of how to do IPv6 <=> IPv6 NAT.  It am 
> convinced that there are some people who will choose to do 
> this for the same reasons that people with plenty of IPv4 
> addresses choose to use IPv4 <=> IPv4 NATs today.  I think we 
> could write a document that says something like:   IPv6
> advantages that can't be obtained through less disruptive 
> means, and are not recommended by the IETF, but if you are 
> planning to do this anyway, please do it right (don't
> include port translation, use algorithmic address mapping if 
> possible, instead of state tables, etc.).

NAT44 has been a third rail (*) in the IETF for over a decade, 
and NAT64 and NAT46 have only recently emerged as a way forward 
to help with the eventual transition to IPv6.  

NAT66 is still a third rail.  I don't want to go there.

(*) <http://en.wikipedia.org/wiki/Political_third_rail>

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Oct 2008 09:45:18 +1300

...
> NAT66 is still a third rail.  I don't want to go there.

Yep. As Margaret well knows, RFC4864 was written to try to avoid
stepping on that rail, and includes a gap analysis of what's
needed to avoid it. I'd rather the IETF put effort into those
gaps.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 20 Oct 2008 12:37:05 +0200

> needed to avoid it. I'd rather the IETF put effort into those

I talked about IPv6 NAT a bit in the shim6 meeting in Philly:

http://www.ietf.org/proceedings/08mar/slides/shim6-2.pdf

However, I didn't get ANY feedback on that (nor the issue of next  
steps for shim6 which the presentation was about), same thing when I  
mentioned IPv6 NAT a few other times.

Interestingly, I did a small survey about whether people _expect_  
there to be NAT66 in the future and the majority said "yes".

On the one hand we can do nothing and if all goes well there will be  
no IPv6 NAT so we're all happy because not doing anything made the  
right thing happen. (Although I've used a NAT66 implementation myself  
some years back, so there is at least one out there.)

But if we do nothing, we run the risk that someone will do a quick  
search and replace on their NAT44 code and create a port overloading  
NAT66. The port overloading is 90% of the harmful stuff that NAT boxes  
do.

What we could do is come up with a stateless, transport-agnostic 1- 
to-1 NAT66 spec so we at least avoid the port overloading and nothing  
much breaks except referrals.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 20 Oct 2008 13:58:28 +0300

> much breaks except referrals.

I share your analysis that, _assuming_ we have NAT66, it should be 
transport-agnostic. IPv6 has a large enough address space, and we are 
painfully aware of the problems of transport-dependent NAT(44).

However, when I look at the reasons for deploying NAT:
1/ address space shortage
2/ inbound firewalling
3/ topology hiding
4/ prefix delegation "bypass"

(1) is a non-issue for IPv6. (2) is solved with stateful firewalling and does 
not require NAT. 1:1 NAT fails to solve (3) as it does hide the subnetting 
scheme, but fails to hide individual hosts. This leaves only (4). Did I miss 
anything?

I still believe we will see NAT66. Not because it's immediately useful. Rather 
because someone will figure out it's easy to adapt NAT44 code to do NAT66. 
For instance, much of the Linux Netfilter framework has become IP 
version-independent lately, with NAT being the only one big remaining 
IPv4-specific chunk.

I guess only time would tell whether a NAT66 1:1 spec would help prevent such 
the transport-dependent NAT66 being _deployed_. It cannot hurt to write that 
spec, I suppose. In any case, the abomination will be _implemented_ :-( It is 
too natural/easy/tempting.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 20 Oct 2008 13:06:38 +0200

> scheme, but fails to hide individual hosts. This leaves only (4). Did I miss 

I think one main reason would be provider independence (ie. no need to 
renumber)  for small sites that cannot afford to have thier own PI 
address block allocated

regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 20 Oct 2008 13:21:25 +0200

On 20 okt 2008, at 12:58, Rémi Denis-Courmont wrote:

> Did I miss anything?

The reason I brought up NAT66 in shim6 is that the right version of it  
could be implemented as a simple router rewrite not unlike what's been  
proposed in GSE/8+8 etc which would be very useful for shim6.

Stable internal addressing when external connectivity changes could  
also be useful.

> version-independent lately, with NAT being the only one big remaining

As I said, I already played around with such an implementation years  
ago. Of course it broke FTP, while FTP through NAT44 works because it  
normally uses passive and even if it doesn't the NAT that I used  
implements an FTP ALG.

> too natural/easy/tempting.

The IETF could exhibit some leadership by saying it will accommodate  
the pure address rewriting that would be caused by NAT66 by making  
applications that use referrals work through that, but not accommodate  
port overloading. That might be enough to keep a port overloading IPv6  
NAT from becoming widespread. (Or not. But it might.)

Of course the IETF could also come out and say that it will not  
accommodate any type of IPv6 NAT.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 20 Oct 2008 14:26:33 +0300

On Monday 20 October 2008 14:06:38 ext marcelo bagnulo braun, you wrote:
> > (1) is a non-issue for IPv6. (2) is solved with stateful firewalling and
> > does not require NAT. 1:1 NAT fails to solve (3) as it does hide the
> > subnetting scheme, but fails to hide individual hosts. This leaves only
> > (4). Did I miss anything?
>

That's prefix delegation/routing bypass.

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 20 Oct 2008 10:50:19 -0400

> scheme, but fails to hide individual hosts. This leaves only (4).  

There are many enterprise networks that have plenty of IPv4 address  
space available to them, but choose to use NAT44 as part of their  
network architecture.  The most common reason I've heard for using  
NAT44 in these cases is to separate an enterprise's internal address  
block from the IP address block provided by their ISP, which I think  
is akin to your option (4).  This allows their internal operations to  
remain stable across ISP renumbering or a decision to change ISP.

There is every reason to believe that these same enterprises will use  
NAT66 for exactly the same reason.  In fact, given that all IPv6  
addresses will be ISP-provided, I'd predict that more, not fewer,  
enterprises will choose to use NAT66 to gain provider independence.

I agree that it would be a good thing to provide a better alternative,  
but we have yet to do so.  I'm also unconvinced that we can convince  
everyone to try the "better" alternative before NAT66 becomes widely  
deployed.

I don't _want_ NAT66 to be deployed any more than the rest of you, but  
I believe it is inevitable.  We may have an opportunity to influence  
how it is implemented and used, but I don't think we can stop it from  
happening.

> too natural/easy/tempting.

After the encouraging response from Marcelo, I'm already working on a  
draft...  I should have something out by the -00 deadline, but I  
haven't figured out where to target it yet -- probably it makes more  
sense to propose it as a behave work item than as a v4v6translation  
item, since it doesn't involve any IPv4.  Suggestions are welcome,  
though.

Margaret

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 20 Oct 2008 16:52:04 +0200

Please see inline.

Margaret Wasserman skrev:

> I think it should be made clearer here whether the translation documents
> will be written in the v6ops WG or behave.  I _think_ this is intended
> to say that the documents will be written in behave, and that the behave
> WG will get input and review regarding operational  requirements and
> deployability from the v6ops WG, but I'd like to see that made clearer.

Yes, that is was intended.

> "MY" should be expanded or explained before it is first used.

Okay, do you think the following is good enough?

"My" IPv4 or IPv6 network in the descriptions below refer to a network
with a clearly identifiable administrative domain (e.g., an enterprise
campus network, a mobile operator's cellular network, a residential
subscriber network, etc.).

> (1) A document that offers advice on how/when to deploy these translation

There has been discussion around a framework document already and I
think that makes sense. I do want to know if anyone is disagreeing.

> there are some people who will choose to do this for the same reasons that
> today.  I think we could write a document that says something like:  IPv6

Considering the discussion so far I see some interest. But it seem to
not be a priority item. Lets get the important things going first before
using up a lot of resources in this discussion.

Cheers

Magnus Westerlund

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 20 Oct 2008 16:58:40 +0200

> item, since it doesn't involve any IPv4.  Suggestions are welcome, 
I would go for int area
actually the nice thing about nat66 is that it is really an IP layer 
mechanism, as opposed to any form of current NATs, that involve transports

regards, marcelo

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 20 Oct 2008 11:16:37 -0400

Hi Brian,

> needed to avoid it. I'd rather the IETF put effort into those

As I said in my last message, I don't _want_ people to deploy NAT66.   
I would be extremely pleased if we could find an architecturally  
cleaner solution to meet the provider-independence requirements  
described in RFC 4864 and get people to actually deploy that solution...

However, I've talked to many enterprise network administrators who are  
very happy with their NAT-based network architectures.  The IETF has  
yet to offer a more effective or easier-to-deploy solution for  
provider independence, and I haven't seen anything that would  
incentivize network administrators to move away from their current NAT- 
based architecture as they move from IPv4 to IPv6.  So, I believe that  
there will be widespread deployment of NAT66.  I wish it were  
otherwise, but wishing doesn't make it so.

So, I believe that it is important that we encourage people who plan  
to implement and deploy NAT66 to do it in ways that will be far less  
damaging to the IPv6 Internet than a direct port of their IPv4 NATs to  
IPv6.  Using 1:1 NAT, we should be able to eliminate the port mapping  
mess.  Also, by advocating the option of algorithmic mapping (of ISP / 
48s straight into ULA /48s, for example), we can help people to avoid  
the need for per-connection state, thus eliminating the brittleness  
that NAT introduces into the network.  We could try to get people to  
separate the concept of a NAT and a stateful firewall, making it  
easier for administrators to enable peer-to-peer applications if/when  
their business needs require such applications.  Even little things,  
like encouraging NAT vendors to build NATs that will generate a random  
ULA prefix for the customer if configured to so, may help to avoid  
some of the pitfalls we've suffered with NAT44 and redundant net 10  
addressing.

I understand that you might not be interested in working on a NAT66  
document, instead choosing to focus on developing better solutions to  
the problems described in RFC 4864.  But, don't you think there is  
some good that we could do with a NAT66 document in the meantime?

Margaret

---

From: "TJ" <[email-masked]>
Date: Mon, 20 Oct 2008 15:29:40 -0400

I am not entirely excited about this conversation, but WRT
	"3/ topology hiding"

NAT66 would accomplish something.  While it doesn't "hide" the specific host
_right now_, it does hide the underlying topology (no 1:1 correlation of
outside and inside addresses / network architecture) as well as hide the
specific host as time moves forward.

... hoping that if it does get defined it gets very little use ...
/TJ

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Rémi Denis-Courmont
>Sent: Monday, October 20, 2008 6:58 AM
>To: [email-masked]
>Cc: [email-masked]; 'Behave WG'
>Subject: Re: [v4v6interim] [46translation] [BEHAVE] Proposal for new BEHAVE
>charter
>
(4).
>Did I miss anything?
>
>I still believe we will see NAT66. Not because it's immediately useful.
>Rather because someone will figure out it's easy to adapt NAT44 code to do
>NAT66.
>For instance, much of the Linux Netfilter framework has become IP version-
>independent lately, with NAT being the only one big remaining IPv4-specific
>chunk.
>
>
>
>I guess only time would tell whether a NAT66 1:1 spec would help prevent
>such the transport-dependent NAT66 being _deployed_. It cannot hurt to
write
>that spec, I suppose. In any case, the abomination will be _implemented_
:-(
>It is too natural/easy/tempting.
>
>--
>Rémi Denis-Courmont

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Oct 2008 10:30:35 +1300

On 2008-10-21 00:26, Rémi Denis-Courmont wrote:
...
> That's prefix delegation/routing bypass.

Yes. It avoids renumbering, and allows multihoming. It's very hard
to stop this unless the RRG comes up with a miracle solution
in the near future. If the site uses a ULA prefix, it can even
avoid the address ambiguity problems of RFC1918, without ever
need to apply for PI space.

On 2008-10-21 04:16, Margaret Wasserman wrote:

> I understand that you might not be interested in working on a NAT66 document, instead choosing to focus on developing better solutions to the problems described in RFC 4864.  But, don't you think there is some good that we could do with a NAT66 document in the meantime?

Margaret, I fear that even an RFC saying "Don't ever do this,
but if you do, here's how" will be widely viewed as encouragement.
But the RRG miracle seems to be slow in coming. So I'll try to
bite my tongue ;-)

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Oct 2008 10:36:19 +1300

On 2008-10-21 03:52, Magnus Westerlund wrote:
...
> subscriber network, etc.).

I find the use of "My" frankly a bit silly in a charter.
My Computer is cluttered with silly things like My Network Places,
My Documents and My Pictures, and it's all a bit annoying...

s/My/A specific/ ?

   Brian

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Oct 2008 05:41:57 +0800

> accommodate any type of IPv6 NAT.

That will travel about one meter and nose-dive. Remember the IETF  
being deluded into thinking that if it didn't work on lawful intercept  
the problem would go away?

Good solutions help, like what RFC 4864 tries to be. Delusional  
thinking and rants about what we don't like don't help.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 20 Oct 2008 17:43:12 -0400

> I find the use of "My" frankly a bit silly in a charter.

I had the exact same concern but was shy to say it. now that someone did
it, I support 100%.

Marc.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca
Stun/Turn server: http://numb.viagenie.ca

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Oct 2008 06:43:08 +0800

Not even sure why it needs to be "a specific". We're going to ahve  
cross-domain issues, and if we don't think about them we will amke  
mistakes that will bite us later.

For my money, we are connecting "an IPv4 network" with "an IPv6  
network", and either might be public or private.

On Oct 21, 2008, at 6:33 AM, Dave Thaler wrote:

> Agree with Brian: s/MY/A specific/
>
> -Dave
>
>> From: [email-masked] [mailto:46translation-
>> [email-masked]] On Behalf Of Marc Blanchet
>> Sent: Monday, October 20, 2008 2:43 PM
>> To: Brian E Carpenter
>> Cc: [email-masked]; 46Translation; Behave WG
>> Subject: Re: [46translation] [v4v6interim] "My" [Re: [BEHAVE]  
>> Proposal
>> for new BEHAVE charter]
>>
>>>>>> 1. MY IPv6 to IPv4 Internet, i.e. perform translation between  
>>>>>> IPv4
>> and
>> 46translation mailing list
>> [email-masked]
>> https://www.employees.org/mailman/listinfo/46translation
>

---

From: Dave Thaler <[email-masked]>
Date: Mon, 20 Oct 2008 12:36:14 -0700

The real or perceived reasons to deploy NAT are covered in RFC 4864,
so yes there's more than were listed in below.

However the point of that RFC is to show that NAT is not the only
way to get those benefits.  It contains at least existence proofs
that benefits can be obtained with some other solution (not to
say that an example listed is necessarily the only or even the best
alternative).

-Dave

> [email-masked]] On Behalf Of TJ
> Sent: Monday, October 20, 2008 12:30 PM
> To: [email-masked]; [email-masked]; 'Behave WG'
> Subject: Re: [46translation] [v4v6interim] [BEHAVE] Proposal for new
> BEHAVE charter
>
>
> version-

---

From: Dave Thaler <[email-masked]>
Date: Mon, 20 Oct 2008 15:33:56 -0700

-Dave

> Subject: Re: [46translation] [v4v6interim] "My" [Re: [BEHAVE] Proposal
> for new BEHAVE charter]
>

---

From: Dave Thaler <[email-masked]>
Date: Mon, 20 Oct 2008 15:46:02 -0700

The "specific" network is the one deploying the box that performs
translation.  The term "MY" was used at the interim, although I
agree with Brian that "a specific" is more readable, and is also
consistent with the text that follows the "MY" sentence which already
uses "a specific".

-Dave

> From: Fred Baker [mailto:[email-masked]]
> Sent: Monday, October 20, 2008 3:43 PM
> To: Dave Thaler
> Cc: Marc Blanchet; Brian E Carpenter; [email-masked];
> 46Translation; Behave WG
> Subject: Re: [BEHAVE] [46translation] [v4v6interim] "My" [Re: Proposal
> for new BEHAVE charter]
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Oct 2008 08:29:36 +0200

Margaret Wasserman   (m/j/a) 10/20/08 4:50 PM:
> I believe it is inevitable. 
Although I also believe that IPv6 NATs will be deployed, there is IMO a 
competitive alternative, say SAM66, to implement purely local routing 
plans  in private sites.

It is an IPv6-IPv6 application of the Static Address Mapping approach 
(SAM) I presented in Montreal:
-  E2E IPv6 packets, where they  traverse private routing networks, are 
locally encapsulated (somewhat like for ISATAP, but IPv6 in IPv6).
-  Border routers of customer sites derive intra-site addresses from 
global addresses by substituting an intra-site header to an ISP site prefix.

Its advantages include:
- No interference with the DNS (global addresses are the only needed ones ).
- No interference with transport checksums.
- Stateless operation of border routers (scalability and resilience)
- Openness to site multi-homing with a unique intra-site routing plan 
(yet to be documented ).

Its main drawback is clearly that hosts have to be upgraded (very simple 
addition, yet a real one).  Also,  participation of DHCPv6 (or router 
advertisements?) is needed  to automate configuration. A possible 
consequence that  SAM66 and NAT66 will have to coexist.

Best regards,

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Oct 2008 08:41:32 +0200

> consistent with the text that follows the "MY" sentence which already
It seems to me that "an IPvX network" or "an IPvX domain",  as opposed 
to "the IPvY Internet" intuitively conveys the idea without a need for 
the word "specific".

The 4 scenarios are then:
- An IPv4 domain TO and FROM the IPv6 Internet.
- An IPv6 domain TO and FROM the IPv4 Internet.

Even better IMHO:
- A host in an IPvX domain TO and FROM a host on the IPvY Internet.

Regrards,

RD

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 21 Oct 2008 09:54:43 +0200

> being deluded into thinking that if it didn't work on lawful  
> intercept the problem would go away?

Didn't it? This is now "solved" outside the IETF AFAIK.

> thinking and rants about what we don't like don't help.

Please read carefully. What I said that the IETF could decide that it  
wouldn't _accommodate_ any type of IPv6 NAT. In the past, the IETF has  
come up with numerous protocols that can't work through NAT. These  
days, working through NAT is always a consideration for end-to-end  
protocols that run on top of IPv4. This is often a hard problem, and  
there are many backward compatibility issues with older protocols.

Although we won't be able to make a completely clean break with IPv6,  
we do have the ability to do better than we've done in the past with  
IPv4. I basically see three options for IPv6:

1. We come to the conclusion that port overloading NAT is now part of  
the IP architecture so if at all possible, all protocols must work  
that type of NAT.

2. Since there are alternative mechanisms to reach the same goals in  
IPv6 that people use NAT for in IPv4, the IETF will not address NAT in  
protocols that run on top of IPv6. If end-users implement NAT66  
anyway, they are solely responsible for implementing the workarounds  
necessary to make this work.

3. Because we expect NAT66 to happen anyway, but because the port  
overloading is the most harmful part that we can possibly avoid, we  
specify a stateless, transport-agnostic 1-to-1 NAT66 and make sure  
protocols that run on top of IPv6 can work through that. In case  
people decide to run a port overloading NAT66, see 2.

Also note that the ship has already sailed on unrestricted end-to-end  
connectivity in IPv6, not only in practice but also by IETF mandate  
when the recommendation to use a stateful firewall between IPv6 nodes  
and the internet reached rough consensus. So some level of middlebox  
awareness is already a requirement for IPv6. (And the NAT64 efforts  
add to this to some degree.) The only question is if we want to extend  
this or not.

In my opinion, it would be good if the IETF or IAB (I'll CC them just  
in case they're looking for work) could come to some kind of  
conclusion regarding the above so that we can formulate  
recommendations for transport and application protocol developers.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Oct 2008 17:50:57 +0800

> Didn't it? This is now "solved" outside the IETF AFAIK.

It's very much part of my world.

As to the rest of what you said, I'll agree with you that in a very  
real sense that ship has sailed, and I'll point out that we run the  
same protocols on IPv6 that we run on IPv4. If we have indeed made the  
protocols NAT-accepting for IPv4, I'll bet they are NAT-accepting on  
IPv6 as well.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 21 Oct 2008 12:34:19 +0200

On 21 okt 2008, at 11:50, Fred Baker wrote:

> same protocols on IPv6 that we run on IPv4. If we have indeed made  
> the protocols NAT-accepting for IPv4, I'll bet they are NAT- 
> accepting on IPv6 as well.

If only things were this simple.

Many apps that break with NAT do referrals by IP address. So they must  
be updated to work with IPv6, and gain significant additional logic to  
work in a dual stack world. Things like STUN and ICE and their  
proprietary counterparts thus need to be reinvented/implemented for v6  
to make referrals work, and/or the UPnP/NAT-PMP protocols that open up  
ports in NAT devices must be recreated for IPv6 if port overloading  
NAT66s happen.

Today the routing people are complaining that the IPv6 builders didn't  
fix routing. I wonder if in 10 years the apps people are going to  
complain that we didn't fix NAT but just let the same thing happen as  
in IPv4 which BEHAVE has been trying to clean up.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Ed Jankiewicz <[email-masked]>
Date: Tue, 21 Oct 2008 10:08:34 -0400

I think what we are trying to get at with "my network" or "a specific 
network" is some handy handle for the domain with address family 
restriction that has a vested interest in translation and coexistence.  
While Fred is right that it is generically "an IPv4 network" with "an 
IPv6 network", the differences in the 4 sub-cases MAY result in 
different solutions:

1.  if "my" network is the one with the minority address family, "I" 
would/could/should be interested in bearing the burden of 
interoperation, hence a solution that costs "me" in time and money is 
acceptable.  As already discussed, this burden shifts over time from 
early adopters to legacy maintainers.  The burden is either doing it 
yourself or paying your ISP to provide the service and the addresses 
required.
2.  if I am the "called" party (i.e. a server) I have a vested interest 
in making "my" network reachable by all "calling" parties, hence a 
distinction between IPv4->IPv6 versus IPv6->IPv4.
3.  more generalized solutions would be nice, but it is easy to fail 
trying to do everything (NAT-PT) or build something that the motivated 
party doesn't need (e.g. someone with lots of IPv4 sensors, etc. may be 
motivated to make them reachable from IPv6, but doesn't need them to 
"call" or be clients to anything on the IPv6 side). 
4.  premature optimization is counterproductive - several solutions that 
each solve part of a big problem well can be combined and simplified, 
but one big solution that does everything not so well (or nothing well) 
tends to get worse in the patching.

I'd say don't get hung up on having a one-word handle to hang on what we 
mean by "the network that is constrained to one address family when the 
rest of the world prefers the other" but I'm sure that can be stated in 
a precise and concise manner in the charter, the scenarios draft, and 
for introductory context for all the solutions.  "Perfect" nomenclature 
is not necessary, but a consistent use of whatever nomenclature is. 

If I had to pick one word it would be "constrained" as in "an 
IPv4-constrained network" meaning (for whatever reason) that the network 
interface to the rest of the world is constrained to sending and 
receiving ONLY IPv4 addressed packets.

Dave Thaler wrote:
>>>>>> "My" IPv4 or IPv6 network in the descriptions below refer to a
>>>>>>             
>>>> network
>>>>         
>>>>>> with a clearly identifiable administrative domain (e.g., an
>>>>>>             
>>>> enterprise
>>>>         
>>>>>> campus network, a mobile operator's cellular network, a
>>>>>>             
>> residential
>>     

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 22 Oct 2008 21:36:06 +0300

Folks,

We have quite a lot on our plate already. Lets not add NAT66 to it as well.

Jari

---

From: Mark Townsley <[email-masked]>
Date: Thu, 23 Oct 2008 16:00:18 +0200

>>> My Documents and My Pictures, and it's all a bit annoying...

The use of "My" started with slides I hacked up in the middle of the 
Montreal meeting to make an illustrative point. I too was a little 
surprised that the same term made it as far as the charter.

Since I started it as much as anyone, please know that "A specific" or 
some other more formal language is perfectly fine with me.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Thu, 23 Oct 2008 16:22:25 +0200

The point of "My" was to refer to someone's network, likely other than 
the whole of the IPv4 or IPv6 Internet. Someone will have to purchase, 
setup, and manage the translator understanding well what the demands on 
the translator will be based on the networks being connected. That is 
still understandably vague, but is about as far as we could get during 
the meeting in Montreal in terms of specifics.

At the start of the meeting, Jari and I tried to identify scenarios 
based on direct feedback from individuals which focused the problem a 
bit more... So, not just *any* type of network, but a rather specific 
one by comparison. Those that came to us with  scenarios were quite 
happy to see them portrayed, others that did not expressed either (1) 
confusion of what the scenario was, (2) doubt that the scenario was 
important, or (3) concern that it meant that their scenario, whether 
topologically similar or not, would not be considered by the IETF. So 
this tactic, frankly, didn't work all that well other than to teach us 
that constraining this problem space into specific types of networks is 
very difficult without losing a lot of consensus along the way.

Clearly, "translate all of IPv4 Internet to the IPv6 Internet in both 
directions" does not work. We were not able to get very specific in 
terms of prioritizing what types of networks should be able to be 
connected to others via translators either. What we ended up with was a 
compromise between the two, with some emphasis on being able to reach 
the IPv4 or IPv6 Internet.

- Mark

Ed Jankiewicz wrote:
> restriction that has a vested interest in translation and 
> coexistence.  While Fred is right that it is generically "an IPv4 
> network" with "an IPv6 network", the differences in the 4 sub-cases 
> MAY result in different solutions:
>
> 2.  if I am the "called" party (i.e. a server) I have a vested 
> interest in making "my" network reachable by all "calling" parties, 
> hence a distinction between IPv4->IPv6 versus IPv6->IPv4.
> party doesn't need (e.g. someone with lots of IPv4 sensors, etc. may 
> be motivated to make them reachable from IPv6, but doesn't need them 
> to "call" or be clients to anything on the IPv6 side). 4.  premature 
> optimization is counterproductive - several solutions that each solve 
> part of a big problem well can be combined and simplified, but one big 
> solution that does everything not so well (or nothing well) tends to 
> get worse in the patching.
>
> I'd say don't get hung up on having a one-word handle to hang on what 
> we mean by "the network that is constrained to one address family when 
> the rest of the world prefers the other" but I'm sure that can be 
> stated in a precise and concise manner in the charter, the scenarios 
> draft, and for introductory context for all the solutions.  "Perfect" 
> nomenclature is not necessary, but a consistent use of whatever 
> nomenclature is.
> IPv4-constrained network" meaning (for whatever reason) that the 
> network interface to the rest of the world is constrained to sending 
> and receiving ONLY IPv4 addressed packets.
>
> Dave Thaler wrote:
> ------------------------------------------------------------------------
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Oct 2008 16:34:54 +0200

Anyway,

Are anyone that thinks that NAT66 is so important that it takes
precedence over the NAT46 translator work? If not, can we postpone this
until we are ready to publish something on address family translators?

The reason I ask the above is that we will have enough work for all the
people in the translator work. Thus trying to avoid splitting the forces
to thinly.

Magnus

Iljitsch van Beijnum skrev:
> complain that we didn't fix NAT but just let the same thing happen as in
> IPv4 which BEHAVE has been trying to clean up.

-- 

Magnus Westerlund

---

From: Mark Townsley <[email-masked]>
Date: Thu, 23 Oct 2008 16:41:07 +0200

Iljitsch van Beijnum wrote:
>
> What we could do is come up with a stateless, transport-agnostic 
> 1-to-1 NAT66 spec so we at least avoid the port overloading and 
> nothing much breaks except referrals.
I agree that this, together with text touching on why port translation 
hurts, some of Dave Thaler's thoughts on topology hiding, etc. could be 
helpful to have waiting in the wings in the event that someone does 
decide they must do NAT66.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Thu, 23 Oct 2008 16:50:06 +0200

> people in the translator work. Thus trying to avoid splitting the forces
The NAT66 should be relatively straightforward, and could actually help 
highlight some of the reasons why 46 and 64 become problematic. NAT66 is 
a question that comes up again and again when talking about deploying 
IPv6, and I honestly think it would be useful to have a document to 
point to that brought light to and articulated some of the issues, gave 
strong warning where necessary, and described what was relatively safe 
and what not.

It doesn't really have to be part of behave though.  Magnus, I fully 
understand if you are looking at this new behave charter and can't 
imagine another thing on your plate. As Margaret and others mentioned, 
this can go through int-area, 6man, or some such.

- Mark

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Oct 2008 17:07:17 +0200

> this can go through int-area, 6man, or some such.

Yes, I think that is worth considering. It will still likely take some
energy from people involved in the translation work. But, as you write
it might have benefits also.

When it comes to the BEHAVE charter I think there will be additional
items added further down the road. However, I am trying at this stage
charter what we know and are certain that we like to work on. Then we
can do another recharter in a couple of months if necessary. I don't
think we have fully baked where the NAT66 work belongs and will
definitely leave it out now. I am trying to meet the goal of having the
translation work chartered before the meeting.

Cheers

Magnus Westerlund

---

From: Mark Townsley <[email-masked]>
Date: Thu, 23 Oct 2008 17:17:01 +0200

> translation work chartered before the meeting.
Thats fine with me, and in the mean time if someone is sitting on their 
hands with nothing to do, write up a good NAT66 document and we'll 
figure out where it should land.

- Mark

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 23 Oct 2008 11:28:11 -0400

I'm getting mixed messages here, but I have a proposal...

Perhaps I could finish the NAT66 draft I've already started, and  
submit it before the -00 cut-off (on Monday).

I think we all agree that NAT66 is not part of the 46translation  
effort and the chair of behave has indicated that it is not in scope  
for behave, so I'll stop cc:ing those groups on my messages about it.   
When the draft comes out, I will send a pointer to intarea and ask for  
feedback.

If Jari and Mark are willing to give me a slot, we could talk about  
the draft at the intarea meeting in Minneapolis.  If there is enough  
interest in NAT66 that it makes sense to continue working on the  
draft, I will.

Even if it takes a while for us to get the NAT66 document published as  
an RFC, we'll have a reasonably well-reviewed draft available in the  
meantime that may help people who start working on NAT66  
implementations to make good design choices.

Does that make sense?

Margaret

On Oct 23, 2008, at 10:50 AM, Mark Townsley wrote:

> The NAT66 should be relatively straightforward, and could actually  
> help highlight some of the reasons why 46 and 64 become problematic.  
> NAT66 is a question that comes up again and again when talking about  
> deploying IPv6, and I honestly think it would be useful to have a  
> document to point to that brought light to and articulated some of  
> the issues, gave strong warning where necessary, and described what  
> was relatively safe and what not.
>
> imagine another thing on your plate. As Margaret and others  
> mentioned, this can go through int-area, 6man, or some such.
>
> - Mark
>> Magnus
>>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 23 Oct 2008 09:30:52 -0600

I'm not worked up one way or the other about if we should specify  
NAT66 or not - however, if we do specify it, I am very concerned about  
how we do that. I see one good reason not to specify NAT66 and two  
good reasons to.

Reasons not to do NAT 66:
1) All the reasons explained in RFC 4864

Reason to do it:
1) Limitations of RFC 4864 as explained in 4864
2) Large vendors are building nat66 today and they are doing it in a  
way that breaks applications and leaves the application designers with  
no idea about what they can count on working and what they can't count  
on.

If #2 does not remind you of how we got into so much trouble nat44,  
well it should. Because of the impact on NAT66 on applications, if  
IETF does decide to do NAT66 specifications, I think it is very  
important that the specification is developed not only in the context  
of v6ops people but is also developed with input of folks from  
applications that need to use it. Today that would roughly mean behave.

Cullen

---

From: Mark Townsley <[email-masked]>
Date: Thu, 23 Oct 2008 17:47:23 +0200

> how we do that. I see one good reason not to specify NAT66 and two 

Since saying nothing and hoping folks will abstain doesn't work very 
well in practice, I'd rather we go in and describe safe NAT66 the best 
we can. I agree that we have to be careful to do a good job, as teaching 
bad NAT66 could be worse than not teaching it at all.

> applications that need to use it. Today that would roughly mean behave.
I think that something that operates only at the IP layer could stay in 
the int-area.

- Mark
>>>>> the

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 23 Oct 2008 10:06:52 -0600

On Oct 23, 2008, at 9:47 AM, Mark Townsley wrote:

>> NAT66 or not - however, if we do specify it, I am very concerned  
>> about how we do that. I see one good reason not to specify NAT66  
>> and two good reasons to.
>
> well in practice, I'd rather we go in and describe safe NAT66 the  
> best we can. I agree that we have to be careful to do a good job, as  
> teaching bad NAT66 could be worse than not teaching it at all.
>
>>
>> 2) Large vendors are building nat66 today and they are doing it in  
>> a way that breaks applications and leaves the application designers  
>> with no idea about what they can count on working and what they  
>> can't count on.
>>
>> important that the specification is developed not only in the  
>> context of v6ops people but is also developed with input of folks  
>> from applications that need to use it. Today that would roughly  
>> mean behave.
> I think that something that operates only at the IP layer could stay  
> in the int-area.

If the mapping was purely and 1:1 mapping between internal and  
external IPs I would agree with you but unfortunately, I worry that  
meeting the requirement that drive section 4.4 of 4864 (privacy and  
topology hiding) really complicate trying to do it with 1:1 mapping at  
IP level.

If you want to be able hide that two uncorrelated sessions are  
actually coming from the same internal host, well, I'm not sure I see  
how to do this with 1:1 mappings. One might argue that one should  
ignore these requirements but this is one of key areas where some  
people feel that 4864 has limitations that drive the deployment of  
NAT66. Two solutions I have seen for this are a) different external IP  
for every internal flow b) doing port address translation similar to  
NAPT in NAT44. Either of these choices has some pretty substantial  
impacts on how to make applications like VoIP work.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 23 Oct 2008 18:35:12 +0200

On 23 okt 2008, at 18:06, Cullen Jennings wrote:

> topology hiding) really complicate trying to do it with 1:1 mapping  
> at IP level.

But there is no reasonable way to make this work along with incoming  
sessions. Of course all the NAT traversal techniques also expose the  
information that is being hidden here. It's just not compatible with  
the IP model.

Wouldn't proxies be a more reasonable way to solve this than NAT?

About a NAT66 doc: before it's published, it must absolutely be  
reviewed in apps, behave, trans, int, v6ops and 6man.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Mark Townsley <[email-masked]>
Date: Thu, 23 Oct 2008 18:41:23 +0200

Cullen Jennings wrote:
>>> about how we do that. I see one good reason not to specify NAT66 and 
>>> two good reasons to.
>>
>>> way that breaks applications and leaves the application designers 
>>> from applications that need to use it. Today that would roughly mean 
>>> behave.
When I say 1:1, I mean one IP address on one side, one IP address on the 
other, with essentially a static mapping between the two.

- Mark

---

From: Alain Durand <[email-masked]>
Date: Thu, 23 Oct 2008 12:58:19 -0400

I'm going to jump into this and probably not make friends...

IPv6 is just like IPv4 with longer addresses. This is where deployment
reality trumps architectural purity.

What I've seen in the last 3 years is that it is much, much easier to deploy
IPv6 if you keep the exact same operational model as in IPv4. This is one
(among many) reason why we pushed for DHCPv6.

Many folks are considering NAT44 as a simple solution where they just have
to put a box in front of their network to make whatever problem they think
they have go away. I can easily see that the same people would like to do
the same thing with IPv6. Which exact problem they were solving is
irrelevant to this discussion, the point is about preserving the same
operational model.

That, and Cullen Jennings point #2 argue for defining NAT66 exactly the same
way as NAT44, ie with (optional) port translation. We have the opportunity
to explain why some choices are less worse than others in doing so and put
all the caveats in place. That is, make sure all the behave work done for
NAT44 is immediately integrated in NAT66, or in  other words, lets define
NAT66 in behave. Now, we may argue about the urgency of doing this... Ie
should this be done in parallel as NAT64 & NAT46 or after.

   - Alain.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 23 Oct 2008 10:35:46 -0700

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Margaret Wasserman
> Sent: Thursday, October 23, 2008 8:28 AM
> To: Mark Townsley
> Subject: Re: [v4v6interim] [BEHAVE] [46translation] Proposal 
> for new BEHAVEcharter
> 
> 

BEHAVE is being re-chartered, so if the community wants BEHAVE to
do NAT66, now is a good time to tell the IESG to include NAT66 in 
BEHAVE's charter.  (as you all know.)  The new charter, at this
time, does not include NAT66.

And I only stated my desire to avoid the 'third rail'; the IESG can 
certainly decide they want NAT66 standardized.  Based on my 
understanding of how NAT66 would work, it would belong in BEHAVE.

> When the draft comes out, I will send a pointer to intarea 
> and ask for feedback.
> 

Yes, makes sense.

-d

> >> precedence over the NAT46 translator work? If not, can we 
> postpone  
> >> this
> >> The reason I ask the above is that we will have enough 
> work for all  
> >> the
> >>>> protocols NAT-accepting for IPv4, I'll bet they are 
> NAT-accepting  
> >>>> on
> >>>> IPv6 as well.
> >>>>
> >>> Many apps that break with NAT do referrals by IP address. 
> So they  
> >>> must
> >>> complain that we didn't fix NAT but just let the same 
> thing happen  
> >>> as in

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 23 Oct 2008 13:39:05 -0400

> from applications that need to use it. Today that would roughly mean  

I agree with you that NAT66 could (and probably would) have impact on  
other layers, so this problem is not specific to any one area.  I also  
share your concerns about working on NAT66 within v6ops or any other  
IPv6-specific WG, because we may get a solution that has unknown or  
unacceptable impact on applications.

I agree that the behave WG would be the best forum for this work,  
which is why I have suggested adding NAT66 to the behave charter while  
it is currently in the process of being updated.  Several people  
expressed interest in this work, but Dan Wing, who is one of the  
behave chairs, indicated that he considers NAT66 to be a political  
"third rail" and that he doesn't want to go there.  Magnus, one of the  
transport ADs, said that he sees "some interest" interest in NAT66,  
but that it is not a priority item.  He wants to finish "the important  
things first" before using resources to discuss NAT66.

I consider NAT66 to be an important and timely topic. So, I'm trying  
to figure out a way that we can make some progress on a NAT66 document  
in some other forum.  I'd be happy to bring it to behave when the  
current work has been completed, but that's likely to take quite a  
while, and I'm hoping we can make some progress on NAT66 in the  
meantime.

Do you think it would be better to just wait until behave finishes its  
current work and is ready to recharter again?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 23 Oct 2008 13:41:24 -0400

> understanding of how NAT66 would work, it would belong in BEHAVE.

Thanks, Dan.  This is very reasonable.

So, what's the best way forward?  Perhaps I could write a draft, sent  
a pointer to behave, and we could have a discussion over the next  
couple of weeks about whether the community does/doesn't want to  
include this in the new behave charter?

Margaret

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 23 Oct 2008 10:47:06 -0700

> include this in the new behave charter?

Yes, that would be ideal.  Thanks!

-d

---

From: Mark Townsley <[email-masked]>
Date: Thu, 23 Oct 2008 19:49:08 +0200

> Yes, that would be ideal.  Thanks!
Works for me as well.

- Mark

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 23 Oct 2008 23:13:23 +0200

> reality trumps architectural purity.

Disagree. Two reasons:

1. The longer addresses don't just make a quantitative difference, but  
also a qualitative difference. Things like SEND, HIP and shim6 aren't  
possible with IPv4 because they put crypto stuff in spare address  
bits. Things like port overloading NAT aren't necessary in IPv6  
because there is abundant address space.

2. If we don't use the opportunity that IPv6 gives us to fix some of  
the brokennes of the current IPv4 internet, we're not going to get  
another chance any time soon. If we use IPv6 just like IPv4 we might  
as well stay with IPv4. We know that with enough NAT it actually is  
possible to squeeze blood from stones.

> IPv6 if you keep the exact same operational model as in IPv4.

But then we've gained nothing.

> irrelevant to this discussion, the point is about preserving the same

Let me try a more opportunistic argument on you: in IPv4, you can't be  
pedantic because then you're disconnected. With IPv6, you can not  
route, filter, break whatever you don't like and the offending party  
then falls back on IPv4 so you still have connectivity. For this  
reason, it's very likely that there will be a lot more operational  
hard ball with (perceived) architectural purity with IPv6. This means  
that the perfect storm of different kinds of users that all saw NAT as  
a solution to their problem and thus required application makers to  
work around NAT won't happen with IPv6, and the onus of implementing  
the workarounds will fall solely on the party implementing the NAT for  
a very long time to come. This is of course often impossible with a  
port overloading NAT so a lot of things that work with IPv4+NAT will  
fail with IPv6+NAT.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Fred Baker <[email-masked]>
Date: Fri, 24 Oct 2008 05:38:51 +0800

On Oct 23, 2008, at 10:50 PM, Mark Townsley wrote:

> It doesn't really have to be part of behave though.

I actually think i should be in behave; they have the expertise. But I  
would agree with Magnus that it is a next step, not the current step.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 24 Oct 2008 08:10:24 +0200

On 23 okt 2008, at 18:06, Cullen Jennings wrote:

> actually coming from the same internal host, well, I'm not sure I  
> see how to do this with 1:1 mappings.

Here's how:

For every new session, the NAT66 box creates a new 1-to-1 maping. So  
for every new session it must choose a new address from a pool map  
that address to the internal source address of the host in question.  
As long as the external addresses checksum to the same value as the  
internal address, the transports that use the normal checksum over the  
pseudo header are happy and don't have to be modified by the  
translator. In IPv6 sessions can of course be identified by the flow  
label so this will work for transports that the translator doesn't  
know. Since the mappings are 1-to-1, incoming sessions can still work  
with help from STUN. The translator does need to keep and time out  
state for translation mappings, though.

This will burn through very many addresses, but even with the checksum  
restriction this shouldn't be much of a problem if the translator  
"owns" a reasonable size prefix, i.e. the prefix is routed to the  
translator so no neighbor discovery is necessary. This kind of  
obfuscation would work really well with a very large prefix and very  
many hosts, such as a /48 for a large site, although in that case the  
state maintenance could be an issue.

There is still the issue that hosts can be recognized by the value  
that the addresses checksum to, but this can be solved by aggressively  
using RFC 3041 or by assigning all hosts checksum-equivalent addresses  
using DHCPv6.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 24 Oct 2008 12:10:45 +0300

On Thursday 23 October 2008 19:06:52 ext Cullen Jennings, you wrote:
> NAT66. Two solutions I have seen for this are
> a) different external IP for every internal flow

This is unlikely to be deployed. It breaks to many applications that work fine 
with NATs (e.g. many web apps tie their "session" to the client IP address).

> b) doing port address translation similar to 

I don't think there's a strong requirement to hide correlation (or rather, 
lack thereof) between VoIP sessions - human user being the bottleneck in how 
many VoIP sessions a system can have.

But most importantly, I doubt that people who are this paranoid about topology 
hiding would tolerate using STUN, or any other server-reflexive address 
learning for that matter. But hey, you must know the SIP privacy work better 
than I do :) IIRC, it's proxy-based (TURN).

Therefore I am not convinced that 1:1 mapping would be a problem.
However, and to answer Alain's point, yes, some vendors will ship NAT66 boxes 
that work exactly like NAT44. But these will be no more BEHAVE-compliant than 
the NAT44 boxes. So it's kind of a non-issue from a standardization 
perspective - I tend to think that there is no problem if there is no 
solution.

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 24 Oct 2008 12:16:06 +0300

> state for translation mappings, though.

Yes.

> This will burn through very many addresses,

Not necessarily. You only need as many addresses as you have hosts. A 
single /64 would be sufficient for any single NAT. You only need a large 
address space if you want STATELESS mappings.

> but even with the checksum 

I don't think it's an issue. This is still less state (one mapping per host) 
than contemporary NAT44 (one mapping per flow).

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 24 Oct 2008 11:34:44 +0200

Margaret Wasserman skrev:
> I agree that the behave WG would be the best forum for this work, which
> is why I have suggested adding NAT66 to the behave charter while it is
> currently in the process of being updated.  Several people expressed
> interest in this work, but Dan Wing, who is one of the behave chairs,
> indicated that he considers NAT66 to be a political "third rail" and
> that he doesn't want to go there.  Magnus, one of the transport ADs,
> said that he sees "some interest" interest in NAT66, but that it is not
> a priority item.  He wants to finish "the important things first" before
> using resources to discuss NAT66.
> 
> I consider NAT66 to be an important and timely topic. So, I'm trying to
> figure out a way that we can make some progress on a NAT66 document in
> some other forum.  I'd be happy to bring it to behave when the current
> work has been completed, but that's likely to take quite a while, and
> I'm hoping we can make some progress on NAT66 in the meantime.

Margaret,

I am pushing back a bit to see if there actually are sufficient interest
in this. I definitely think you should try to write up your document so
that the community have something to discuss around. So far we have a
couple of people that definitely have views on this.

In regards to BEHAVE charter, if we actually have come to good enough
conclusions about what NAT66 really should do within a week or so, then
I don't see a problem with adding it to BEHAVE charter. However, BEHAVE
may not be the right home depending on what is to be done. If we haven't
come to good enough conclusions, I still plan to go forward with the
current proposed re-charter. I have no issues to do a another recharter
in a month or two. We do have a few other components in the co-existence
puzzle that may land in BEHAVE. So I am expecting to do another
recharter within the next couple of months.

But please go forward and continue to discuss this topic on the BEHAVE
list.

Cheers

Magnus Westerlund

---

From: Mark Townsley <[email-masked]>
Date: Fri, 24 Oct 2008 11:56:41 +0200

Pekka Savola wrote:
> On Thu, 23 Oct 2008, Mark Townsley wrote:
>>> well
>>>  it should. Because of the impact on NAT66 on applications, if IETF 
>>> does
>>>  decide to do NAT66 specifications, I think it is very important 
>>> that the
>>>  specification is developed not only in the context of v6ops people 
>>> but is
>>>  also developed with input of folks from applications that need to 
>>> use it.
>>>  Today that would roughly mean behave.
>>
> But it doesn't; a 1:1 NAT66 would break every app (FTP, SIP, etc.) 
> that's broken today with NAT4 (with or without port translation) 
> unless the NAT has ALGs.  To implement such ALGs, NAT66 would need to 
> operate beyond the IP layer.
Of course, anything that IP does affects things above and below. By this 
argument we could collapse whole portions of int area into transport or 
vice-versa (which may be a fait accomplis anyhow, but I digress).

All of these translator things cross layer boundaries. My argument is, 
simply, that if any of it could land on the int area side, a strictly 
1:1 NAT might be the most likely candidate. Remember also, this was in 
response also to Magnus raising his arms overhead and looking for a 
liferaft amidst the new work behave already has. Honestly, if he is 
willing to take it on in behave, that's perfectly fine with me as long 
as it receives enough attention from int-area folks. I'm far less 
concerned about that last issue right now than I was, say, 6 months or 
so ago when we first started talking about bringing IPv6 translation 
into behave.

This discussion has already gotten ahead of itself though. Let's get the 
-00 out, discuss it where best we can find the time and cycles, and then 
decide where (and if) it should land as chartered work. Margaret asked 
for a slot in int-area, perhaps there will be time in behave as well, so 
for the moment some of you might see this discussed twice - as is the 
case often with work that is yet unchartered.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Fri, 24 Oct 2008 12:01:10 +0200

> But please go forward and continue to discuss this topic on the BEHAVE
No issue at all there, all NAT66 email discussion in one place, the 
behave list, is perfectly fine with me. Much better than chasing 
crossposts. I do hope that behave is seeing a lot of new membership from 
int-area folks these days though.

- Mark

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 24 Oct 2008 13:09:55 +0300

On Friday 24 October 2008 12:20:51 ext Pekka Savola, you wrote:
> >> well it should. Because of the impact on NAT66 on applications, if IETF
> >> does decide to do NAT66 specifications, I think it is very important
> >> that the specification is developed not only in the context of v6ops
> >> people but is also developed with input of folks from applications that
> >> need to use it. Today that would roughly mean behave.
> >

Not exactly. I know at least FTP/ESPV and RTSP would work as is through NAT66. 
I suspect many proprietary gaming protocol would end up there too. I'd like 
to know about CIFS and NFS.

FTP/EPRT is broken, also it could have been designed such that it would not 
have been (by making the remote address optional) :-( Also, for instance, SIP 
would be much easier to "fix" than with NAT44 + ICE, assuming you don't care 
about IPv4 at all.

I assume Margaret plans to scope her I-D clearly such that the limitations are 
clearly stated and the reader is pointed to potential NAT-free alternative 
solutions (and especially to reading the IPv6 security RFC). I think we all 
know that NATs suck. The points are: 1/ NAPT sucks harder than pure NAT, and 
2/ lets we IETFers not do the same mistake of ignoring NATs.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 24 Oct 2008 13:22:51 +0200

>> operate beyond the IP layer.

Or the clients must obtain their externally visible address and  
present that in referrals. This is much preferable to ALGs.

Note that the stateful firewalls that are mandated for home use with  
IPv6 also get in the way.

> have been (by making the remote address optional) :-(

That's what EPSV is for:

ftp> debug
Debugging on (debug=1).
ftp> ls
---> EPSV
229 Entering Extended Passive Mode (|||51239|)
---> LIST
150 Here comes the directory listing.

(Note that I was talking to the server over v4.)

> single /64 would be sufficient for any single NAT.

Our statements are not in opposition because a single /64 has very  
many addresses.  :-)

> You only need a large

Wouldn't every internal address map to a single external address in  
that case? That wouldn't use very many addresses. But if you need a  
new address for every source address / flow label combo, things start  
moving fast.

> than contemporary NAT44 (one mapping per flow).

No, in this case we also do a mapping per flow, but the difference is  
that we don't need to understand the transport to recognize flows  
because we have the flow label, and because we use a different source  
address per flow we don't need to recognize incoming packets by their  
port numbers so referrals work. We also avoid touching the port  
numbers and the checksums.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 24 Oct 2008 14:44:06 +0300

On Friday 24 October 2008 14:22:51 ext Iljitsch van Beijnum, you wrote:
> that case? That wouldn't use very many addresses.

For stateless mapping, unless you have some extra assumptions about the 
internal addresses (e.g. only SLAAC EUI-48 are used, no static address, no 
privacy addresses), you need as large an external prefix as the internal one.

> port numbers so referrals work.

NAT44 provide N:1 internal:external address mappings, not N:M. With N:M you 
will break applications that _do_ work with NAT44, including a very long tail 
of HTTP-based applications. Making NAT66 worse than NAT44 is unlikely to fly, 
even with those people who _do_ want to deploy NAT66.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 24 Oct 2008 13:51:58 +0200

> even with those people who _do_ want to deploy NAT66.

If the load balancers ignore the bottom 64 bits there is no issue.

So I suggest we tell those vendors to do exactly that when they build  
the IPv6 implementations of their products.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 24 Oct 2008 06:09:15 -0700

Iljitsch,

IPv6 has been implemented years back.

Many production network are dual stack today or even running just pure 
v6. So with this in mind what are you proposing to tell the vendors reg 
hints for their upcoming implementations ???

Cheers,
R.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 24 Oct 2008 15:23:36 +0200

> Many production network are dual stack today or even running just  
> pure v6. So with this in mind what are you proposing to tell the  
> vendors reg hints for their upcoming implementations ???

What's the alternative? Not telling them?

What I hear is that many large content outfits have trouble going to  
v6 because the vendors of their load balancers don't have an IPv6  
solution yet. (Although I'm sure part of that is just an easy way of  
shifting the blame, but I'm also fairly sure it's true in a good  
number of cases.)
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Pekka Savola <[email-masked]>
Date: Fri, 24 Oct 2008 12:20:51 +0300 (EEST)

On Thu, 23 Oct 2008, Mark Townsley wrote:
>>  If #2 does not remind you of how we got into so much trouble nat44, well
>>  it should. Because of the impact on NAT66 on applications, if IETF does
>>  decide to do NAT66 specifications, I think it is very important that the
>>  specification is developed not only in the context of v6ops people but is
>>  also developed with input of folks from applications that need to use it.
> I think that something that operates only at the IP layer could stay in the 
> int-area.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: "Bonness, Olaf" <[email-masked]>
Date: Fri, 24 Oct 2008 11:38:34 +0200

> perspective - I tend to think that there is no problem if there is no 
I agree with Remi.
Besides that I'm not realy sure if I buy the reasons why a NAT66 should be standardized. Only why some vendors will ship it? Only why some users are used to have NATs in their CPEs? Are there also stronger (more technical) reasons / problems a NAT66 would solve?
br
	olaf
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 24 Oct 2008 09:44:33 -0600

On Oct 24, 2008, at 3:20 AM, Pekka Savola wrote:

>> I think that something that operates only at the IP layer could  
>> stay in the int-area.
>
> unless the NAT has ALGs.  To implement such ALGs, NAT66 would need  
> to operate beyond the IP layer.

My SIP phone has worked fine behind a NAT with no SIP ALG for several  
years now and so do my FTP sessions. Let me reiterate that is a NAT  
with no SIP or FTP ALG.  Sure it was a nightmare, and continues to be  
a nightmare, for applications to be designed to work behind NATs but  
that is how applications are designed for today. I wish it was not  
this way but it is. The whole point of BEHAVE was to make that  
slightly better by providing guidance for NATs that allowed  
applications to make reasonable assumptions about what type of NAT  
environment they might have to work behind. 
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Fred Baker <[email-masked]>
Date: Fri, 24 Oct 2008 16:21:44 +0800

Very much agree.

On Oct 24, 2008, at 12:58 AM, Alain Durand wrote:

>> at

---

From: Fred Baker <[email-masked]>
Date: Fri, 24 Oct 2008 16:28:50 +0800

I think the best approach is to start work on it, but decouple it from  
4/6 NAT. There is, for example, no serious question of how to embed an  
IPv6 address into an IPv6 address.

I would recommend considering GSE as a basis - changing the prefix  
between two prefixes, such as a ULA and an operator prefix.

There will be issues with multiple subnet IDs; from a topology hiding  
model one wants them to go away, and in such a case there is a problem  
with host ID collisions. And if the "inside" and "outside" prefixes  
are of different lengths (ISP allocated a /56 but in my ULA I am using  
the equivalent of a /48 and embedding more than 2^8 prefixes in it)  
that also creates an issue. I would suggest a simple approach - tell  
the edge network operator that they need prefixes from the upstream  
LIRs that allow them to map subnets statelessly - that if they have  
2^9 subnets their upstreams need to give them a prefix no longer than  
64-9 bits, and they need to enumerate them so as to allow stateless  
translation.

On Oct 24, 2008, at 1:41 AM, Margaret Wasserman wrote:

> So, what's the best way forward?  Perhaps I could write a draft,  
> sent a pointer to behave, and we could have a discussion over the  
> next couple of weeks about whether the community does/doesn't want  
> to include this in the new behave charter?
>
> Margaret
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 25 Oct 2008 12:37:06 -0700

Brian E Carpenter wrote:
> in the near future.

Doesn't HIP solve this problem?

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Fred Baker <[email-masked]>
Date: Sun, 26 Oct 2008 05:15:09 +0800

no, at least I don't think so.

HIP tries to provide what RFC 1498 and 1753 call an "endpoint ID", but  
provides no way to associate locators with it. Hence, while from an  
application perspective it enables the application to ensure that the  
system or service it is talking with is the one it intends to, it  
doesn't enable the transport to select an address pair to use in  
routing - and yes, the choice of a source and a destination address  
has the effect of routing a session, as it determines important points  
that the datagram will transit.

Read all of RFCs 1483, 1753, 1992, http://ana.lcs.mit.edu/~jnc/tech/endpoints.txt 
, and http://tools.ietf.org/html/draft-irtf-nsrg-report for a complete  
discussion of the problem. Getting network folks and application folks  
to describe the problem is a little like describing the elephant -  
each only describes part.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Oct 2008 13:52:27 +1300

Fred,

I think you are spot on. A new session layer identifier namespace would
solve a lot of problems, but would require a new identifier mapping
system to link it back to the network layer and the routing system.
That's missing in HIP today (which is why we get a mishmash like
RFC 4843).

I suggest this line of discussion is closer to the RRG charter
than to BEHAVE.

    Brian

On 2008-10-26 10:15, Fred Baker wrote:
> doesn't enable the transport to select an address pair to use in routing
> - and yes, the choice of a source and a destination address has the
> effect of routing a session, as it determines important points that the
> datagram will transit.
> 
> Read all of RFCs 1483, 1753, 1992,
> http://ana.lcs.mit.edu/~jnc/tech/endpoints.txt, and
> http://tools.ietf.org/html/draft-irtf-nsrg-report for a complete
> to describe the problem is a little like describing the elephant - each
> only describes part.
>