Subject: Re: [nat66] Fwd: New Version Notification for draft-mrw-nat66-00

From: <[email-masked]>
Date: Thu, 21 Oct 2010 18:35:39 +0200

Not all tools are suitable for all cases.

Renumbering of enterprise network is quite a different case than few laptops and one ipad behind lightweight nat66 box that happens to have frequently changing /64 on its uplink and doesn't like to do checksum recalculation.. Well, usually ND Proxy is used in that case (and hosts renumber always when /64 changes). And if the box is mobile phone, its uplink's /64 may change often (e.g. Daily).

It would be better if NAT66 would not be used in such cases at all, but if that ought to happen anyway, it would be better done as efficienly as possible (at least for the entity spoiling party for others:)

Btw wasn't it so that due stateless nature of NAT66 no keep-alives whatsoever are needed?

Best regards,

Teemu

----- Original message -----
> Margaret Wasserman wrote:
> > On Oct 19, 2010, at 9:31 AM, <[email-masked]<mailto:[email-masked]>> wrote:
> > > Have you considered selection of ULA prefix(es) for internal network
> > > in such a manner that it/they can be translated to NAT uplink's /64
> > > prefix in checksum neutral fashion?
> > >
> > This is an interesting idea, however it undermines the purpose of
> > NAT66...  If the internal addresses are chosen to allow checksum
> > neutral translation to external addresses, then the internal addresses
> > will need to be changed whenever the site is renumbered by an ISP, or
> > when a site changes ISPs.
>
> Regardless of NAT I'd be interesting in seeing a working example where
> internal hosts renumber successfully for any reason, much less in
> response to external renumbering.  How would, for example, a persistent
> (internal-internal) database connection be renumbered securely?
>
> Used to be the IEFT required a reproducible working implementation
> before
> considering this sort of RFC.  Has that policy been discontinued?
>
> Roger Marquis
> _______________________________________________
> nat66 mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nat66
>

---

From: Roger Marquis <[email-masked]>
Date: Thu, 21 Oct 2010 10:28:41 -0700 (PDT)

> Not all tools are suitable for all cases.

True.  Working implementations should be required of all common cases.  I
am not, however, aware of any working implementations of stateful
internal connections being successfully renumbered.

> Renumbering of enterprise network is quite a different case than few
> laptops

Are you saying that NAT66 would not need to be extensible, to both
scenarios?

Roger Marquis

---

From: Chris Engel <[email-masked]>
Date: Thu, 21 Oct 2010 14:04:04 -0400

It's my general understanding that the principle behind NAT (of any flavor) is to abstract the internal architecture from the external advertisement of that architecture. Having a change to ones external architecture automatically cause a corresponding change to the internal architecture would seem to run counter to that principle, even ignoring feasability issues.

Christopher Engel
Network Infrastructure Manager
SponsorDirect
[email-masked]
www.SponsorDirect.com
p(914) 729-7218
f (914) 729-7201

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Roger Marquis
> Sent: Thursday, October 21, 2010 1:29 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [SPAM] - Re: [nat66] Fwd: New Version Notification
> for draft-mrw-nat66-00 - Email has different SMTP TO: and
> MIME TO: fields in the email addresses
>
>
> True.  Working implementations should be required of all
> common cases.  I am not, however, aware of any working
> implementations of stateful internal connections being
> successfully renumbered.
>
> Are you saying that NAT66 would not need to be extensible, to
> both scenarios?
>
> Roger Marquis
> [email-masked]

---

From: <[email-masked]>
Date: Thu, 21 Oct 2010 21:28:50 +0200

I'm only saying that maybe section 11 of draft-mrw-nat66-00 should mention possibility to "randomize" the ULA in checksum neutral manner if seen useful for the particular NAT66 implementation, and if administrator has not configured anything else either. 

In the uses cases I'm talking about, there rarely is such thing as stateful internal connection.. 

Best regards,

Teemu
________________________________________
From: ext Roger Marquis [[email-masked]]
Sent: Thursday, October 21, 2010 8:28 PM
To: Savolainen Teemu (Nokia-MS/Tampere)
Cc: [email-masked]
Subject: Re: [nat66] Fwd: New Version Notification for draft-mrw-nat66-00

Roger Marquis

---

From: Rémi Després <[email-masked]>
Date: Mon, 25 Oct 2010 09:46:24 +0200

Hi, Teemu,

> It would be better if NAT66 would not be used in such cases at all, but if that ought to happen anyway, it would be better done as efficienly as possible (at least for the entity spoiling party for…

It is still time, IMHO, to avoid that it "happens anyway", at least for those that read IETF explanations.
NAT66 does pollute IPv6 badly by the fact that hosts no longer know their global addresses (no e2e address preservation), which is incompatible with peer-to-peer in IPv6.
It's better to work on alternative approaches that address the same problems without breaking e2e address preservation.

Some don't like my repeating that there is such an approach with SAM (tools.ietf.org/html/draft-despres-softwire-sam-01).
However, based on automatic tunneling rather than translation, it is designed to solve the renumbering and multihoming problems without sacrificing e2e address preservation.  

Regards,
RD

> > > On Oct 19, 2010, at 9:31 AM, <[email-masked]> wrote: