Subject: [BEHAVE] Comments on the NAT66 draft

From: Rémi Després <[email-masked]>
Date: Wed, 05 Nov 2008 16:21:11 +0100

Hi Margaret,

Sorry for so late an answer (I was too busy preparing my own draft
before the deadline).

Here are my comments, section per section.

Sec. 3 - Motivation)

a. I _FULLY
SUPPORT_ that IETF should
standardize some ways to keep, in IPv6, appreciated benefits of NAT44s
(and to avoid as much as possible their drawbacks).

b. In your list of NAT44 appreciated services (i.e. provider
independent addressing, simplified site multihoming, topology hiding),
"host privacy" should IMHO be added. This is the impossibility, from
the outside, to see that several consecutive connections were initiated
by the same host.

c. Concerning multihoming, a more detailed analysis of what NATs do,
and don't do, would be a useful clarification. (In particular, they
are incompatible with multihoming of both Shim6 and SCTP. These the
protocols, to take advantage of multihoming, exchange address
information in payloads, protected by strong checksums.)

Sec. 4 - NAT66 overview

a. Since your proposed mechanism is only based on stateless and
reversible  _mappings_, calling it a NAT leads, IMHO, to
confusion: NATs are generally understood, and used, as NAPTs. They do
stateful and  non-reversible 1:n  _translations_.

b. With a different name than NAT for such a proposal, IETF could advertise that it _does not endorse NATs in IPv6_. This would IMHO
increase  (or restore?) confidence in IPv6. "Mapping" instead of
"translation"would be a logical word in such a name.

Sec. 5 - NAT66 Address Mapping Mechanisms

- Topology hiding is in fact possible without losing reversibility of
the mapping. Cf the comment on 5.1.2.

Sec. 5.1 - Checksum-Neutral Mapping

- IMHO, it would be useful to make it clear in this section (like in
the introduction) that the proposed mapping does not apply to addresses
that are transmitted in
payloads.  ALGs could be be added to convert
addresses in TCP payloads TCP, as it is done in some NAT44s.  But it
cannot be done not in SCTP payloads because of the stronger checksum
algorithm.

Sec. 5.1.1 - Two-way Algorithmic Address Mapping

- The proposed limitation to /48 internal and external prefixes is
stronger than necessary.

- A sufficient limitation is that external prefixes are not longer than
internal ones. (If  the external prefix is shorter, a few 0 bits can be
added to it, up to the  length to the internal one.) For
example a /56 external with a /60 internal should be permitted.

Sec. 5.1.2 - Topology hiding Option

- For outgoing UDP and TCP connections, it is in fact possible to hide
the internal topology without losing  reversibility of the mapping:
the
algorithmic mapping is, for this, applied jointly to the subnet
identifier AND to port
bits (excluding port-bits 0 and 1 that must remain constant in dynamic
ports).
UDP and TCP checksums are then incrementally adjusted (like IP
checksums).

- In addition to topology hiding, this mechanism provides _host
privacy_ , as defined in the comment on sec. 3 :-) .

Sec 6. - Prefixes for Port Mapping

- I don't see the need for this section in this document. The mapping
applies to internal and external  prefixes, independently of how they
can be configured.

Sec 7 - A note on Port Mapping

- Agreed: address amplification should not be needed in IPv6. Agreed
also: some transport layers that encrypt data are incompatible with
port mapping. But this is not sufficient to abandon port
mapping all-over. (See the comment on 5.1.2.)

Sec 8 - Security Considerations

- In TCP, DCCP, SCTP, packets that initiate connection establishments
can be individually
recognized (SYN without ack in the case of TCP). Incoming connections
can therefore be blocked with
stateless operation, but this is not the case for UDP (per-connection
stateful operation is needed). Whether blocking UDP incoming
connections is
worth it, in global to local IPv6 gateways, is  therefore uncertain
(hosts must anyway have their own blocking of undesirable incoming
connections).

In summary:

- the document  introduces IMO a *very useful subject*.

- Before freezing any recommendation,  its relationship with other
layers, in particular with other stateless address mappings, should be
further studied.

Best regards,

RD

Margaret Wasserman   (1-12/1-31/200x) 10/27/08 7:59 PM:

I have posted a NAT66 draft, so that we can
have a better-grounded discussion of whether it makes sense to include
NAT66 as a work item in the behave charter.  The draft can be found at
the following URL:

http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-00.txt

Feedback would be greatly appreciated!

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

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 5 Nov 2008 11:31:43 -0500

I understand that NAT66 work on the details is being done in the BEHAVE Working Group - but shouldn't we also include a discussion at v6ops on whether NAT66 should be standardized?  After all, they're more privy to the discussions that created the Local Network Protection RFC...
 
- Wes

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rémi Després
Sent: Wednesday, November 05, 2008 10:21 AM
To: Margaret Wasserman
Cc: Behave WG
Subject: [BEHAVE] Comments on the NAT66 draft

Hi Margaret, 

Sorry for so late an answer (I was too busy preparing my own draft before the deadline). 
Here are my comments, section per section. 

Sec. 3 - Motivation)
a. I _FULLY SUPPORT_ that IETF should standardize some ways to keep, in IPv6, appreciated benefits of NAT44s (and to avoid as much as possible their drawbacks). 
b. In your list of NAT44 appreciated services (i.e. provider independent addressing, simplified site multihoming, topology hiding), "host privacy" should IMHO be added. This is the impossibility, from the outside, to see that several consecutive connections were initiated by the same host. 
c. Concerning multihoming, a more detailed analysis of what NATs do, and don't do, would be a useful clarification. (In particular, they  are incompatible with multihoming of both Shim6 and SCTP. These the protocols, to take advantage of multihoming, exchange address information in payloads, protected by strong checksums.) 

Sec. 4 - NAT66 overview
a. Since your proposed mechanism is only based on stateless and reversible  _mappings_, calling it a NAT leads, IMHO, to confusion: NATs are generally understood, and used, as NAPTs. They do  stateful and  non-reversible 1:n  _translations_. 
b. With a different name than NAT for such a proposal, IETF could advertise that it _does not endorse NATs in IPv6_. This would IMHO increase  (or restore?) confidence in IPv6. "Mapping" instead of "translation"would be a logical word in such a name.

Sec. 5 - NAT66 Address Mapping Mechanisms 
- Topology hiding is in fact possible without losing reversibility of the mapping. Cf the comment on 5.1.2. 

Sec. 5.1 - Checksum-Neutral Mapping 
- IMHO, it would be useful to make it clear in this section (like in the introduction) that the proposed mapping does not apply to addresses that are transmitted in payloads.  ALGs could be be added to convert addresses in TCP payloads TCP, as it is done in some NAT44s.  But it cannot be done not in SCTP payloads because of the stronger checksum algorithm. 

Sec. 5.1.1 - Two-way Algorithmic Address Mapping 
- The proposed limitation to /48 internal and external prefixes is stronger than necessary. 
- A sufficient limitation is that external prefixes are not longer than internal ones. (If  the external prefix is shorter, a few 0 bits can be added to it, up to the  length to the internal one.) For example a /56 external with a /60 internal should be permitted. 

Sec. 5.1.2 - Topology hiding Option 
- For outgoing UDP and TCP connections, it is in fact possible to hide the internal topology without losing  reversibility of the mapping:  the algorithmic mapping is, for this, applied jointly to the subnet identifier AND to port bits (excluding port-bits 0 and 1 that must remain constant in dynamic ports). UDP and TCP checksums are then incrementally adjusted (like IP checksums). 
- In addition to topology hiding, this mechanism provides _host privacy_ , as defined in the comment on sec. 3 :-) . 

Sec 6. - Prefixes for Port Mapping 
- I don't see the need for this section in this document. The mapping applies to internal and external  prefixes, independently of how they can be configured. 

Sec 7 - A note on Port Mapping
- Agreed: address amplification should not be needed in IPv6. Agreed also: some transport layers that encrypt data are incompatible with port mapping. But this is not sufficient to abandon port mapping all-over. (See the comment on 5.1.2.) 

Sec 8 - Security Considerations 
- In TCP, DCCP, SCTP, packets that initiate connection establishments  can be individually recognized (SYN without ack in the case of TCP). Incoming connections  can therefore be blocked with stateless operation, but this is not the case for UDP (per-connection stateful operation is needed). Whether blocking UDP incoming connections is worth it, in global to local IPv6 gateways, is  therefore uncertain (hosts must anyway have their own blocking of undesirable incoming connections). 

In summary: 
- the document  introduces IMO a *very useful subject*. 
- Before freezing any recommendation,  its relationship with other layers, in particular with other stateless address mappings, should be further studied. 

Best regards, 

RD 

	I have posted a NAT66 draft, so that we can have a better-grounded discussion of whether it makes sense to include NAT66 as a work item in the behave charter.  The draft can be found at the following URL:

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Nov 2008 08:58:27 +1300

On 2008-11-06 04:21, Rémi Després wrote:
...
> b. With a different name than NAT for such a proposal, IETF could advertise that 
> it _does not endorse *NATs in IPv6*_. This would IMHO increase  (or restore?) 
> confidence in IPv6. "Mapping" instead of "translation"would be a logical word in 
> such a name.

This may seem like cosmetics, but I tend to agree. (Side note: I wanted
RFC4864 to be called NAP, intentionally to resonate with NAT, but that
was changed during the document review.) How about MAT66 (mapped address
translation)? Yes, it *will* be confused on the telephone, and that's
a feature, not a bug.

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Nov 2008 21:26:54 +0100

On 5 nov 2008, at 20:58, Brian E Carpenter wrote:

>> it _does not endorse *NATs in IPv6*_.

> This may seem like cosmetics, but I tend to agree.

Actually using the term NAT would be a feature. If people want "NAT  
for IPv6" we'll give them "NAT for IPv6". If we create a new name  
we'll end up with namespace squatters providing something called "NAT"  
which will be something we won't like.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Després <[email-masked]>
Date: Thu, 06 Nov 2008 12:36:49 +0100

> which will be something we won't like.
IMU, what people want is  renumbering avoidance + topology hiding + host 
privacy when needed + efficient multihoming.
So far they see NAT66 as the only known way to have more or less all of 
this (not "all" of that because NATs per se (be they 44, 46, 64, or 66)  
deliver neither efficient multihoming for incoming connections nor load 
sharing).

If in the v6-v6 case, and thanks to the large IPv6 address space, we can 
deliver all of that this  without NATs (and in particular without their  
DNS implications for inbound connections, and without their ALGs) , it 
is worth being well known. It should be expressed clearly, not obscurely 
because of some  clever idea of fooling people.

Also, it would be consistent with the past reluctance to standardize NAT44s.

Personally, I believe that what Margaret has started to describe in the 
v6-v6 case would advantageously become a feature of the more  generic 
Stateless Address Mapping architecture (SAM) .  Then SAM66 would be a 
nice acronym, but I do understand that SAM is too new for a very short 
term consensus.

For the time being, NAT 66 avoidance  seems to be the subject (NAT66A?). :
- IPv6 address mappings are endorsed by IETF for the useful functions 
they provide, some of which require NATs when v4 is involved (NAT44s, 
NAT64, NAT46s).
- There is no plan to endorse the non reversible address translations of 
NAT66s as long as no clear need that is not satisfied in a cleaner 
manner has been identified.

RD

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Thu, 6 Nov 2008 08:59:01 -0500

As we move to IPv6, NAT44, NAT64, and NAT46 will eventually go away.  The problem with helping NAT66 (even when that is not your intent) is that once it catches on, it'll be in the Internet forever and will never go away.

"NATs necessary for IPv6, says IETF chair"
http://www.networkworld.com/news/2008/072109-nat-housley-qna.html

Once NAT66 gets out, I can imagine even more damaging headlines (which conveniently miss all the subtleties of the message in section 3 of http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-00.txt): "IETF Standardizes IPv6-to-IPv6 NAT".

- Wes 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 06, 2008 5:59 AM
To: Wes Beebee (wbeebee)
Cc: Rémi Després; Margaret Wasserman; Behave WG; [email-masked]
Subject: Re: Comments on the NAT66 draft

Personally I am scared of anything that seems to make NAT suggestions for v6. 

That said, I think that section 3 could use a little more meat to explain some of the problems with NAT in terms of breaking connections etc rather than just pointing towards RFC 4864 as I am not sure that people will go and look at the cross reference. 

I would encourage discussion on this to see if there is a consensus for proceeding with giving hints or help to a concept that "IETF does not recommend" 

Eric 

Wes Beebee (wbeebee) writes: 

> port mapping. But this is not sufficient to abandon port mapping 
> all-over. (See the comment on 5.1.2.)
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 6 Nov 2008 15:14:37 +0100

On 6 nov 2008, at 14:59, Wes Beebee (wbeebee) wrote:

> As we move to IPv6, NAT44, NAT64, and NAT46 will eventually go  
> away.  The problem with helping NAT66 (even when that is not your  
> intent) is that once it catches on, it'll be in the Internet forever  
> and will never go away.

> Once NAT66 gets out, I can imagine even more damaging headlines  
> (which conveniently miss all the subtleties of the message in  
> section 3 of http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-00.txt) 
> : "IETF Standardizes IPv6-to-IPv6 NAT".

Well, if that's what we want to avoid, we shouldn't be coy and come  
out and say that IPv6 NAT won't be accommodated in IETF protocols.

What seems to be happening today is that we all look the other way and  
pretend the issue doesn't exist, because we either assume that of  
course there won't be any IPv6 NAT or of course there will. So we are  
on our way ending up with the same situation that we encountered with  
IPv4: suddenly, it's no longer realistically possible to deploy a  
protocol that isn't NAT-friendly, but there are so many different NATs  
that it's impossible to be friendly to them all, and many of them  
operate is very suboptimal ways that could have been avoided with some  
forethought.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Després <[email-masked]>
Date: Thu, 06 Nov 2008 15:38:25 +0100

Wes Beebee (wbeebee)   (1-12/1-31/200x) 11/6/08 2:59 PM:

There will indeed be NAT64s, and possibly NAT46s: they are necessary to
satisfy some specific requirements. This justifies the chair's message.

But this does not imply that NAT66s are ALSO necessary: provided
appropriate mapping based solutions are
deployed for v6-v6, there are only negative effects to be expected from
real NAT66s.

This is precisely what can be avoided by using a more appropriate
terminology: in Margaret's document, "mapping" appears 46 times;
"translation"
appears 4 times (3 times to define NAT66, and 1 time where mapping
could have  been used as well).

Regards,

RD

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 06, 2008 5:59 AM
To: Wes Beebee (wbeebee)
Cc: Rémi Després; Margaret Wasserman; Behave WG; [email-masked]
Subject: Re: Comments on the NAT66 draft

Eric

- Wes

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Rémi Després
Sent: Wednesday, November 05, 2008 10:21 AM
To: Margaret Wasserman
Cc: Behave WG
Subject: [BEHAVE] Comments on the NAT66 draft

Hi Margaret,

Sec. 3 - Motivation)

Sec. 4 - NAT66 overview

In summary:

Best regards,

RD

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Thu, 6 Nov 2008 09:40:34 -0500

I guess RFC 4864 doesn't go quite far enough - it says (paraphrasing): 
You shouldn't need NAT66 because there are other ways to accomplish your
goals which may be existing or under development at IETF.  

Are we prepared to make a stronger statement here?  Are we prepared to
say: 
If you use NAT66, then be prepared for interoperability problems with
IETF specifications because we WILL NOT design around your box, and,
furthermore, that all the reasons you would want such a box have been
fully accomodated through other means which are all in a good enough
state for you to deploy today.

- Wes

-----Original Message-----
From: Iljitsch van Beijnum [mailto:[email-masked]] 
Sent: Thursday, November 06, 2008 9:15 AM
To: Wes Beebee (wbeebee)
Cc: [email-masked]; Margaret Wasserman; [email-masked];
Behave WG
Subject: Re: [BEHAVE] Comments on the NAT66 draft

On 6 nov 2008, at 14:59, Wes Beebee (wbeebee) wrote:

> As we move to IPv6, NAT44, NAT64, and NAT46 will eventually go away.  
> The problem with helping NAT66 (even when that is not your

> Once NAT66 gets out, I can imagine even more damaging headlines (which

> conveniently miss all the subtleties of the message in section 3 of 
> http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-00.txt)

Well, if that's what we want to avoid, we shouldn't be coy and come out
and say that IPv6 NAT won't be accommodated in IETF protocols.

What seems to be happening today is that we all look the other way and
pretend the issue doesn't exist, because we either assume that of course
there won't be any IPv6 NAT or of course there will. So we are on our
way ending up with the same situation that we encountered with
IPv4: suddenly, it's no longer realistically possible to deploy a
protocol that isn't NAT-friendly, but there are so many different NATs
that it's impossible to be friendly to them all, and many of them
operate is very suboptimal ways that could have been avoided with some
forethought.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: [email-masked]
Date: Thu, 06 Nov 2008 03:59:21 -0700

Personally I am scared of anything that seems to make NAT suggestions for 
v6. 

That said, I think that section 3 could use a little more meat to explain 
some of the problems with NAT in terms of breaking connections etc rather 
than just pointing towards RFC 4864 as I am not sure that people will go and 
look at the cross reference. 

I would encourage discussion on this to see if there is a consensus for 
proceeding with giving hints or help to a concept that "IETF does not 
recommend" 

Eric

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Nov 2008 09:24:44 +1300

Wes,

> goals which may be existing or under development at IETF.  

And the weakness in that is that although we have the gap analysis
in 4864, we do *not* have an adequate work plan to fill those gaps.
(ADs: I hope you are reading this.) Until we do, the emperor is
missing a few vital items of clothing.

> state for you to deploy today.

I think it's unrealistic to say that. We can put strong health warnings
in the draft, but we can't assert that other means exist for everything
until that becomes true (see above). We know very well that we can't
make that 'WILL NOT' assertion, because that isn't how our industry,
or the IETF, works. I'm unhappy about this but we have to be realistic.

MAT66 works for me because it makes it clear that this is not NAPT66.

   Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 6 Nov 2008 15:38:02 -0500

Hi Wes,

Hosting this discussion on the behave WG mailing list is certainly not  
an attempt to avoid folks in v6ops having feedback on the work, it is  
just that behave seems like the right place to work on the actual  
specification.  With all of the v4v6 translation discussion happening  
in behave, I think we've been hoping that the v6 folks will show up in  
behave and have this discussion, and do this work, there.

I'm sure that the v6ops chairs are aware of this work -- my co-author  
Fred Baker is one of them.  If they think that it would be useful to  
discuss NAT66 in v6ops, I'd certainly be happy to come to the v6ops  
meeting and talk about it.

Personally, though, I'd rather that we discuss this in one forum  
(behave) and that interested people bring their thoughts, opinions and  
feedback to that forum.

Margaret

On Nov 5, 2008, at 11:31 AM, Wes Beebee (wbeebee) wrote:

> I understand that NAT66 work on the details is being done in the  
> BEHAVE Working Group - but shouldn't we also include a discussion at  
> v6ops on whether NAT66 should be standardized?  After all, they're  
> more privy to the discussions that created the Local Network  
> Protection RFC...
>
> - Wes
>
> a. I _FULLY SUPPORT_ that IETF should standardize some ways to keep,  
> in IPv6, appreciated benefits of NAT44s (and to avoid as much as  
> possible their drawbacks).
> independent addressing, simplified site multihoming, topology  
> hiding), "host privacy" should IMHO be added. This is the  
> impossibility, from the outside, to see that several consecutive  
> connections were initiated by the same host.
> reversible  _mappings_, calling it a NAT leads, IMHO, to confusion:  
> NATs are generally understood, and used, as NAPTs. They do  stateful  
> and  non-reversible 1:n  _translations_.
> b. With a different name than NAT for such a proposal, IETF could  
> advertise that it _does not endorse NATs in IPv6_. This would IMHO  
> the introduction) that the proposed mapping does not apply to  
> addresses that are transmitted in payloads.  ALGs could be be added  
> to convert addresses in TCP payloads TCP, as it is done in some  
> NAT44s.  But it cannot be done not in SCTP payloads because of the  
> stronger checksum algorithm.
>
> - A sufficient limitation is that external prefixes are not longer  
> than internal ones. (If  the external prefix is shorter, a few 0  
> bits can be added to it, up to the  length to the internal one.) For  
> - For outgoing UDP and TCP connections, it is in fact possible to  
> hide the internal topology without losing  reversibility of the  
> mapping:  the algorithmic mapping is, for this, applied jointly to  
> the subnet identifier AND to port bits (excluding port-bits 0 and 1  
> that must remain constant in dynamic ports). UDP and TCP checksums  
> are then incrementally adjusted (like IP checksums).
> - I don't see the need for this section in this document. The  
> mapping applies to internal and external  prefixes, independently of  
> how they can be configured.
>
> port mapping. But this is not sufficient to abandon port mapping all- 
> over. (See the comment on 5.1.2.)
>
> - In TCP, DCCP, SCTP, packets that initiate connection  
> establishments  can be individually recognized (SYN without ack in  
> the case of TCP). Incoming connections  can therefore be blocked  
> with stateless operation, but this is not the case for UDP (per- 
> connection stateful operation is needed). Whether blocking UDP  
> incoming connections is worth it, in global to local IPv6 gateways,  
> is  therefore uncertain (hosts must anyway have their own blocking  
> of undesirable incoming connections).
>
> In summary:
> layers, in particular with other stateless address mappings, should  
> be further studied.
>
> Best regards,
>
> RD
>
>
>> I have posted a NAT66 draft, so that we can have a better-grounded  
>> discussion of whether it makes sense to include NAT66 as a work  
>> item in the behave charter.  The draft can be found at the  
>> following URL:
>>

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 6 Nov 2008 16:22:22 -0500

On Nov 5, 2008, at 2:58 PM, Brian E Carpenter wrote:

>> advertise that

If this is the consensus view, then obviously I will go along, but I  
see some problems with this...

Rather than trying to spin all of this and pretend that we're not  
_really_ talking about IPv6 NAT (by calling it IPv6 MAT instead?), I  
think we should simply accept that we were mistaken in our reasoning  
that lead us to believe that network administrators/operators wouldn't  
choose to use NATs in IPv6.  (I also think it is important to remember  
that it is the enterprise administrators/operators who will _choose_  
what to deploy on their networks, not us).

At first, we were pretty naive about NAT.  We thought it was used  
(only? primarily?) to amplify IPv4 address space, and we thought that  
people wouldn't need IPv6 NAT, because there wouldn't be address  
shortages in IPv6.  We also heard a lot about the "security" benefits  
of NAT, which we dismissed, perhaps a bit too quickly.  We spent a lot  
of time telling people that IPv6 networks would be better than IPv4  
networks, because they had built-in IPsec and wouldn't need NAT.

When we really looked into why people use IPv4 NATs, though, we  
discovered that people use NATs to solve several problems other than  
address space shortage.  In fact, NATs are often used on enterprise  
networks that have plenty of address space available, both to provide  
a certain type of protection for their internal nodes and to separate  
internal and external address space.  NAT is a fairly good solution to  
these problems, perhaps no worse than any other solutions we've  
considered, and it is widely accepted and adopted in the marketplace.

We do  not (yet?) have practical solutions to address these problems  
that don't involve NAT.  In fact, we may never find solutions to some  
of these problems that will be preferable to NAT in the eyes of people  
who actually design and deploy networks (the network administrators/ 
operators who actually get to decide what they use).  So, people will  
continue to use NAT to solve these problems in IPv6, perhaps for a  
long time.  IMO, calling it MAT won't change that, it will just  
confuse things and make it harder to reach the people we actually want  
to reach with the NAT66 message -- the vendors who are building IPv6  
NATs for their customers.

Would it really be so bad to admit that we were wrong, and that  
network administrators/operators _will_ choose to deploy NAT in IPv6  
networks?  If we can accept that, then it will quickly become clear,  
IMO, that we can do significant good in the world by helping vendors  
to build better, more consistent, IPv6 NAT devices than they might  
have built without us.  Right?

Margaret

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 6 Nov 2008 22:53:34 +0100

On 6 nov 2008, at 22:22, Margaret Wasserman wrote:

> we should simply accept that we were mistaken in our reasoning that  
> lead us to believe that network administrators/operators wouldn't  
> choose to use NATs in IPv6.  (I also think it is important to  
> remember that it is the enterprise administrators/operators who will  
> _choose_ what to deploy on their networks, not us).

How is this not a truism? As I'm fond of saying: in an infinite  
universe, everything that's possible exists. And the internet is  
pretty much an infinite universe now. There is no doubt that for every  
bad operational idea that we can think of (and plenty that we can't  
think of) there will be a few people implementing that idea. That in  
and of itself doesn't mean the IETF has to accommodate those bad ideas.

With NAT44 we ended up in the situation that it's so widely deployed  
that arguments against it became completely academic: if you want your  
protocol to work between random hosts, you better make it client/ 
server or think about NAT traversal.

With IPv6 there isn't enough deployment yet to let deployment guide  
us. The most important reason to run port overloading NAT is also  
gone, and we can accommodate most other reasons to want to have NAT66  
using different means. So at this point, it's extremely hard to  
determine whether the desire to run NAT in IPv6 (which so far is  
mostly expected and not encountered in the real world) are just lazy  
IPv4 thinking or reasonable. And we certainly don't have the data to  
decide whether the benefits of NAT in IPv6 outweigh the downsides.  
Much as I hate to say it, in IPv4 the benfits probably do outweigh the  
enormous costs: with NAT44, I wouldn't be able to connect multiple  
computers to the internet at home.

Notwithstanding all of the above, pretty much everyone I talk to  
_expects_ there to be some sort of NAT66 in the future, whether they  
think this is a good thing or not.

> address space shortage.

Give people a hammer and they'll start banging on everything that  
sticks out...

> have built without us.  Right?

Believe it or not, but large parts of the operational community look  
at the IETF for technical leadership. So let's provide some of that.  
Please.

Once again, the choices:

- an architecture where IP addresses are immutable in transit
- an architecture where IP addresses can change in transit, but not  
the IP payload (= transport protocols)
- an archtecture where IP and TCP/UDP headers are subject to change in  
transit and all non-TCP protocols are tunneled over UDP
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Nov 2008 14:44:13 +1300

On 2008-11-07 10:22, Margaret Wasserman wrote:
...
> Would it really be so bad to admit that we were wrong, and that network
> administrators/operators _will_ choose to deploy NAT in IPv6 networks? 
> If we can accept that, then it will quickly become clear, IMO, that we
> can do significant good in the world by helping vendors to build better,
> more consistent, IPv6 NAT devices than they might have built without
> us.  Right?

I think that's reality, but I also think our industry is mature enough
to cope with a minor name change that makes it clear that there is
a difference. Hence, I think that NAT->MAT is about right. NAT for IPv4,
MAT for IPv6, is that so hard?

   Brian

---

From: Rémi Després <[email-masked]>
Date: Fri, 07 Nov 2008 16:49:30 +0100

Brian E Carpenter   (1-12/1-31/200x) 11/6/08 9:24 PM:

Wes,

Full agreement on the need for a short term gap filling plan.

IMHO, a combination of the best of my SAM proposal, of Margaret's NAT66
proposal (renamed to avoid the word NAT, I hope), and of DHCP based
port range assignments of Boucadair's and Bajko's drafts, could be an
adequate gap filling solution.

Regards,

RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 07 Nov 2008 16:54:50 +0100

> (behave) and that interested people bring their thoughts, opinions and 
Same opinion.
RD

---

From: [email-masked]
Date: Fri, 07 Nov 2008 11:18:51 -0700

Iljitsch, 

This is why we have RFC 4864, and the comment that the IETF does not support 
NAT in IPv6. We need to find a way to make it crystal clear that NAT is not 
part of v6 and using it will be non-standard. 

And this is why I think this draft will cause more harm than good.
Eric 

Iljitsch van Beijnum writes:
> there won't be any IPv6 NAT or of course there will. So we are  on our way 
> ending up with the same situation that we encountered with  IPv4: 
> suddenly, it's no longer realistically possible to deploy a  protocol that 
> isn't NAT-friendly, but there are so many different NATs  that it's 
> impossible to be friendly to them all, and many of them  operate is very 
> suboptimal ways that could have been avoided with some  forethought.

---

From: [email-masked]
Date: Fri, 07 Nov 2008 11:23:39 -0700

> MAT66 works for me because it makes it clear that this is not NAPT66. 

I agree with Brian, MAT would work as it breaks from the NAT mentality and 
may be more manageable in the future.
Eric
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: james woodyatt <[email-masked]>
Date: Fri, 7 Nov 2008 10:34:46 -0800

concerned--

An additional motivation for deploying NAT66, which I have bleated  
about occasionally in the V6OPS working group (but not for many  
months), is to facilitate the operation of application layer helpers  
for stateful packet filtering middlebox/firewalls.

In this deployment scenario, the NAT66 box is used to redirect flows  
passing through the firewall to an application layer helper that A)  
transparently and bidirectionally proxies the application protocol and  
B) controls the filtering rules in the firewall to allow/deny  
transport layer flows accordingly.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 7 Nov 2008 13:55:04 -0500

However, it's entirely possible to do stateful packet filtering with
application layer helpers without rewriting addresses.  That would be a
stateful firewall specification - not NAT66.

What we need to understand very clearly is:
What problem are we trying to solve through NAT66?
What compelling deployment scenario mandates the use of NAT66?

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of james woodyatt
Sent: Friday, November 07, 2008 1:35 PM
To: Behave WG; Margaret Wasserman
Subject: Re: [BEHAVE] Comments on the NAT66 draft

concerned--

An additional motivation for deploying NAT66, which I have bleated about
occasionally in the V6OPS working group (but not for many months), is to
facilitate the operation of application layer helpers for stateful
packet filtering middlebox/firewalls.

In this deployment scenario, the NAT66 box is used to redirect flows
passing through the firewall to an application layer helper that A)
transparently and bidirectionally proxies the application protocol and
B) controls the filtering rules in the firewall to allow/deny transport
layer flows accordingly.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 7 Nov 2008 14:24:27 -0500

Hi James,

I'm not sure that I understand what you are concerned about...  Do you  
believe that the NAT66 described in my draft would interfere with this  
type of function?  Or just that it doesn't provide it?

Margaret

On Nov 7, 2008, at 1:34 PM, james woodyatt wrote:

> transparently and bidirectionally proxies the application protocol  
> and B) controls the filtering rules in the firewall to allow/deny

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 7 Nov 2008 14:32:39 -0500

One way forward would be to provide an operational, BUSINESS case for
NAT66 to v6ops,
then get v6ops WG consensus that that is an important problem to solve
and that NAT66 is the right tool to solve it.  Then, we can hash out all
the details of the NAT66 solution in BEHAVE.

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Wes Beebee (wbeebee)
Sent: Friday, November 07, 2008 1:55 PM
To: james woodyatt; Behave WG; Margaret Wasserman
Subject: Re: [BEHAVE] Comments on the NAT66 draft

- Wes

-----Original Message-----

concerned--

---

From: james woodyatt <[email-masked]>
Date: Fri, 7 Nov 2008 14:05:28 -0800

On Nov 7, 2008, at 11:24, Margaret Wasserman wrote:
>
> I'm not sure that I understand what you are concerned about...  Do  
> you believe that the NAT66 described in my draft would interfere  
> with this type of function?  Or just that it doesn't provide it?

Quite the opposite.  I believe NAT66 is necessary in facilitating the  
development of transparent application helpers for stateful packet  
filtering middlebox/firewalls.  If we are to have adequately scalable  
and transparent firewalls for applications that require helpers, then  
we will need NAT66 to redirect flows into the transparent proxy  
daemons running on middleboxes.

Your draft leaves out this motivation for developing NAT66.  In my  
view, this is the only compelling reason to deploy NAT66, as I think  
all the other motivations are adequately addressed in RFC 4864.

Shorter james woodyatt: if end-to-end integrity is a *problem* (rather  
than a solution), then you're going to need NAT66 to insert your  
middleboxes into application flows transparently.

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 7 Nov 2008 15:11:02 -0800

This document is confused at best, and a waste of time any way you cut it.
It claims to not want nat66, but defines it anyway. It claims that address
independence is a goal, but that exists through the use of ULA without this,
and for those that really 'need it', there are mechanisms to acquire space
directly from an RIR to have independent public space. It claims that
encryption is not impacted, but when the certificates include addresses it
absolutely does. It talks all about topology hiding, but is so focused on
the single subnet case that it can't deal with the complexity of real
topologies that would be the ones that need hiding. 

The -only- reason for something like this document is to placate those that
do not want to learn how to deal with multiple addresses per interface.
There will always be LL and something else, so they need to get over that
anyway. Once there is more than one addresses on the interface, the address
independence argument goes away because ULA provides the stable value for
internal -independent use- in case others change. Topology hiding is about
making the device appear to exist at the edge of the network, and 4864 shows
how that can be done without mangling the header.

The word braindead comes to mind when reading this. By choosing a short
prefix, topology hiding is automatically off the table. With a well-known
algorithm it would not take much work to figure out the possible set of ULA
prefixes being used when nodes from different parts of an organization are
connecting to someone that you are trying to hide the topology from (after
all, they know you will be using hierarchal routing internally), then over
time that list could be cut to one. Add to that the absurd assumption that
the external side can use bits 49-64 as 0 without any conflict in the IID is
insane. There will be mappings of internal subnets and IIDs that result in
the same 80 bits through this map-to-zero approach, but since the base
assumption in the document is a single subnet it misses this point. It hints
at this lack of uniqueness, but simply setting the u bit is not going to cut
it, and the document completely ignores the case where it was already set
for something like a 3041 or 3971 iid. 

In short, it has all of the flaws of GSE, plus through its oversights it
adds a few new ones. If this were easy to fix, it would have been done to
GSE a decade ago. It is absurd that we keep revisiting this nonsense with
the insane hope that the outcome will be different. 

Now we return to your regularly scheduled political rally featuring hope and
promise, while completely overlooking reality ...

Tony

---

From: Gert Doering <[email-masked]>
Date: Sat, 8 Nov 2008 10:30:45 +0100

Hi,

On Fri, Nov 07, 2008 at 11:18:51AM -0700, [email-masked] wrote:
> This is why we have RFC 4864, and the comment that the IETF does not 
> support NAT in IPv6. We need to find a way to make it crystal clear that 
> NAT is not part of v6 and using it will be non-standard. 

We have seen in IPv4 how well that approach works "close our eyes and
pretend that NAT is not going to happen".

I agree with those posts that said "NAT66 will appear, and the IETF should
make sure that it's done in a way that will have predictible effects on
applications".

As for the specifics: having 1:1 NAT without port rewriting, maybe even
just swapping the first /64 bits, is what should serve the purpose of
"I want to be able to change providers, on a whim, without renumbering
my internal network", while at the same time having fairly little impact
on applications.  

Regarding the "topology hiding" argument - well, people can use privacy 
extentions on their hosts, no?

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Sat, 8 Nov 2008 12:10:24 +0200

> extentions on their hosts, no?

That hides _identity_ not _topology_. Topology hiding is "messing up" your 
subnet prefixes.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: [email-masked]
Date: Sat, 08 Nov 2008 04:20:42 -0700

Gert, 

4 years ago we had this discussion on the v6OPS and in spite of the various 
arguments Site Local addresses were depreciated, and RFC4864 -  Local 
Network Protection for IPv6 was approved. 

Back then I proposed that we just allocate 0::(RFC 1918 address) as a 
necessary fix to the perceived need for NAT. After much debate and 
discussion I joined the team writing RFC 4864 on why NAT was not needed and 
thus was not part of v6. 

Unlike the historical development of 1918, here the WG took a serious look 
and made a preemptive decision about NAT addresses and thus should not need 
to back fill to fit a solution that will be industry dictated due to lack of 
available addresses. 

I have yet to hear one serious reason why we need NAT in v6 given that all 
of the requirements that lead to it and have kept it alive for years in v4 
do not exist in v6 and in some cases using it will break v6 functionality. I 
agree that NAT64 and NAT46 are needed during the transition period, but why 
break v6 as it is being adopted to meet some outdated technical and 
extensive marketing related requirements? 

> make sure that it's done in a way that will have predictible effects on
Yes I anticipate that people will try to find a loophole to get the 
perceived benefits of NAT in v6, and yes I am sure that some vendors will be 
willing to put marketing over good engineering. But I think we need to make 
a clear statement that v6 NAT IS NOT supported and WILL cause unpredictable 
problems that can lead to loss of connectivity or failure of services, 
otherwise v6 is just v6 on steroids and loosed most of the end-to-end 
connectivity and security features that will make it useful for the next 
generation of applications. 

> my internal network", while at the same time having fairly little impact

This is why they have DHCPv6, one small change on the DHCP server and the 
whole network should renumbered. 

> extentions on their hosts, no? 

Yes, and it does away with one of the myths that NAT is needed for security. 

Eric

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 8 Nov 2008 07:19:44 -0500

Hi Tony,

Let me respond to your points in line...

On Nov 7, 2008, at 6:11 PM, Tony Hain wrote:
> It claims to not want nat66, but defines it anyway.

The intent is to say:  (1) We do not recommend deploying NAT66.  (2)  
If you are thinking about doing so, read RFC 4864 first.  However, (3)  
we understand that there are some reasons why people deploy NAT44 that  
continue to exist in IPv6 networks, so we believe that some people  
will choose to request NAT66 products from their vendors and to deploy  
NAT66 in their networks.  (4) If you are implementing a NAT66 product,  
please do it _this_ way, as NAT66 will cause fewer problems if it does  
not modify transport-layer headers and is implemented consistently.

> It claims that address

If you believe that address independence is provided by ULAs without  
translation, then perhaps you and I are not talking about the same  
thing when we say "address independence".

ULAs can be used for local communication within an administrative  
domain, but they cannot be used to communicate on the global  
Internet.  So, without some way to translate ULAs to global unicast  
addresses (such as NAT66), all hosts that want to communicate on the  
global Internet will need to be configured with global unicast  
addresses (perhaps in addition to ULAs).  To make this happen, a  
network administrator needs to configure global unicast addresses and  
address prefixes throughout his network (in routers, application  
servers, perhaps local DNS, perhaps DHCPv6, etc.).  If the ISP changes  
the global unicast address prefix assigned to the administrative  
domain, the local network administrator needs to change the global  
unicast address prefix in all of those places.  In most cases (where  
all or most of the local hosts need to access the global Internet),  
the effort of renumbering the global unicast address prefix is not  
simplified by the existence of ULAs at all.

In the NAT66 case, renumbering the global unicast prefix can be  
accomplished by reconfiguring the NAT66 device(s).  Period.

> directly from an RIR to have independent public space.

s/really 'need it'/really 'need it', and can justify their need for it  
to an RIR, and can afford it

I'd argue that most small office and home networks really "need"  
address independence, but they are unlikely to be able to convince an  
RIR of that need or justify the cost of getting their own public  
space.  So, they will go shopping for an IPv6 NAT box, instead.

> It claims that
> absolutely does.

True.  We've already incorporated some feedback on the security  
implications of NAT66, and we'll add a mention of certificates in the  
next revision.  NAT66 does not fix or avoid the inherent problems  
associated with changing IP addresses/headers in the network.

> It talks all about topology hiding, but is so focused on

Actually, the mechanism described is not focused on the single subnet  
case at all.  All of the subnets within a site are mapped to addresses  
in a single subnet to hide the topology, but the internal network is  
expected to be a multi-subnet network.  AFAIK, the concept of topology  
hiding is moot in a single-subnet network.  If you can explain to us  
why you think that the topology hiding mechanism is focused on the  
single subnet case, we will try to fix the text to make this clearer.

> do not want to learn how to deal with multiple addresses per  

Actually, one of the reasons why people may choose to deployed NAT66  
is that they do not want to deal with the configuration complexity of  
configuring multiple addresses per interface.  I actually don't expect  
that most of the people who _deploy_ NAT66 will read this draft at all  
(just as I'd guess that most people who deploy NAT44 have never read  
any RFC).  This draft is aimed at _vendors_ who are planning to  
_implement_ NAT66, and is intended to help them do it in a more  
consistent and less harmful way.

Since none of your arguments offer any reason to believe that vendors  
will not implement NAT66, it is unclear how your arguments relate to  
our need for this draft.

> anyway.

There is no configuration complexity with link-local addresses, and  
they aren't really used for anything, so most network administrators  
won't care if they are there or not.

> Once there is more than one addresses on the interface, the address
> internal -independent use- in case others change.

That's fine, if the only thing you care about is communicating  
internally.  That isn't true of most Internet-connected networks; they  
want to have a stable configuration for communicating with the global  
Internet, as well.

> Topology hiding is about

RFC 4864 mentions one way to achieve topology hiding without NAT,  
using a "Topology Hiding Router".  IMO, as I said at the time, I think  
that the concept of a "Topology Hiding Router" is under-documented in  
RFC 4864.  Also, the "Toplogy Hiding Router" solution would work just  
as well in IPv4 as in IPv6, and it has not been widely preferred over  
NAT for IPv4 networks, as far as I know.   Could you point to a vendor  
that offers a "Topology Hiding Router" (for IPv4 or IPv6) as a product  
today?  Or is the network administrator expected to build one him/ 
herself?

There are network-wide implication of the "Topology Hiding Router"  
solution that are not explored in RFC 4864.  For example, you could  
not use IPv6 Address Autoconfiguration for the global unicast  
addresses on the network behind the "Topology Hiding Router", because  
addresses would not be allocated on a prefix-per-subnet basis.  So you  
would need another mechanism to configure the global unicast addresses  
on each of the internal hosts (probably DHCPv6 with IP addresses  
assigned based on the MAC address of each host?).  Also, every router  
in the network (not just the "Topology Hiding Router") would need to  
have a full set of host routes for the global unicast addresses of  
every host in the site, and there is no explanation in RFC 4864 about  
how these host routes would be configured and propagated.  If you want  
vendors to consider implementing the "Topology Hiding Router" solution  
instead of implementing NAT66, I think you need to write an RFC that  
actually describes it.

I don't think that most network administrators will prefer the  
"Toplogy Hiding Router" solution to NAT, though, because it further  
complicates the renumbering problem.  When you are done deploying the  
"Topology Hiding Router" solution, you will have global unicast  
addresses (not just address prefixes, but actual host addresses)  
configured in all of your routers and your DHCP server. These would  
all need to be reconfigured if you change ISPs or if your ISP  
renumbers and changes your address allocation.

It seems to me that NAT66 is a much simpler solution to topology  
hiding problem that also offers an address independence benefit, and  
some network administrators are going to select a NAT-based solution  
over the "Topology Hiding Router" solution, whether we write a  
specification for NAT66 or not.

> By choosing a short
> time that list could be cut to one.

I don't understand what you are trying to say here.  Could you  
elaborate?  Perhaps give an example?

> Add to that the absurd assumption that
> assumption in the document is a single subnet it misses this point.

As I indicated above, the is no base assumption in the document about  
neworks being a single subnet.

In the topology hiding case, we do clear the "u" bit in the IID,  
indicating that the IID is no longer "universally scoped", but if I  
understand correctly, you are concerned that topology hiding mechanism  
described in the document could result in situation where the external  
128-bit IPv6 address is the same for two internal nodes?  I think you  
may have a good point there, and we'll have to think about that.   
Since the NAT66 device needs to maintain state for the inbound  
translation in the topology hiding case, anyway, there may be some  
obvious ways to fix this if it is a problem. We will need to do some  
work to figure out whether it is a problem or not, and fix it if it  
is.  Thank you for pointing this out.

> It hints

If it is already cleared (indicating a non-universally-scoped IID), we  
don't change it.  What is wrong with that?

> the insane hope that the outcome will be different.

It is true that there are a number of parallels between NAT66 and GSE,  
which Fred and I both consider one of the promising aspects of this  
approach.

There are certainly problems with _any_ solution that modifies packets  
in the network, and the NAT66 mechanism exhibits those problems.   
However, network administrators have consistently shown their  
preference for dealing with those problems vs. dealing with the  
configuration complexity and other issues inherent in other solutions  
to meet their address independence and topology hiding requirements.    
Why do you think that they will make different choices in IPv6?

Earlier in your feedback, you referred to parts of the NAT66 document,  
or perhaps to the general concept of NAT66, as "insane".  One  
definition of insanity is to keep doing the same thing while expecting  
different results.  We tried telling network administrators that they  
didn't need and shouldn't use NAT in IPv4, and they chose to use it  
anyway, because it solved their problems in a way that was more  
acceptable _to them_ than other solutions.  What makes you think that  
they will choose differently when they deploy IPv6?

Margaret

---

From: Gert Doering <[email-masked]>
Date: Sat, 8 Nov 2008 14:45:00 +0100

Hi,

On Sat, Nov 08, 2008 at 04:20:42AM -0700, [email-masked] wrote:
> do not exist in v6 and in some cases using it will break v6 functionality. 

Well, the thing that I keep hearing is "we want to be able to change
providers at our whim and not renumber" (not from "SOHO" customers, but
from "a bit larger networks").

Two possible answers

  - IPv6 PI space ("everybody's routing table gets hit")
  - ULA space inside, NAT66 outside

so what's the smaller evil?  I can't say.

(Regarding the "renumbering" bit: I didn't write "we can't renumber" - 
but for a largish network, renumbering can incur much much higher costs
than just finding a vendor that provides a NAT66 box... and as soon as
enterprise customers are going to ask vendors about it, one of them will
build one.  Well, I think you could already do that today with BSD 
pf(4)...)

From an ISP point of view, I'd actually prefer NAT66 before IPv6 PI.  

Of course "everyone of our customers will stay there forever, so there's
no need to ever renumber" would be much preferred, but I think this is
about as unrealistic as assuming that there won't be NAT66 boxes.

Gert Doering
        -- NetMaster

---

From: Rémi Després <[email-masked]>
Date: Sat, 08 Nov 2008 18:07:09 +0100

[email-masked]   (1-12/1-31/200x) 11/7/08 7:23 PM:
> I agree with Brian, MAT would work as it breaks from the NAT mentality 
> and may be more manageable in the future.
About the choice of an acronym that differs from NAT:
- MAT (mapped address translation) does not suggest that no (non 
reversible) translation is applied. It also suggests that mapping and 
translation can be simultaneous, rather than having  distinct properties.
- SAM66 (stateless address mapping), which I like,  may be problematic 
because of all the new technical contents that goes with SAM.

==> What about, at least for the time being, NAM66 (network address 
mapping), or NAC66 (network address conversion).

RD

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 08 Nov 2008 19:16:22 +0100

Hi Tony,

I would like to address a specific topic that you mention where is have 
some work in the past.
(not sure if behave is the right place for this, if not, please chairs 
let me know)

> do not want to learn how to deal with multiple addresses per interface.
Actually, i think this is a very valid reason why NAT66 is useful
what is more, i disagree with you that people don't _want_ to deal with 
multiple addresses, it is just that in order to do so, we end up with 
other issues that are far from being minor.

Let's consider the case of a multihomed site with two PA blocks, one per 
ISP.
Let's assume that both ISPs are doing ingress filtering.
Let's consider  host H within the multihomed site that in order to e 
able to send a receive packet through both ISPs it needs to configure 
two addresses, one per ISP. Let's call those IPA and IPB.
Now suppose the host H wants to initiate a communication to an external 
host.
suppose that following RFC3484 it picks IPA to use a source address. 
Now, it is possible that the packet is routed through ISPA and will be 
delivered. But it is also possible that it is routed through ISPB and 
will be drop due to ingress filtering.

This is the current situation. If a site becomes multihomed using 
multiple PA bocks today, it will experience packet loss even when there 
is no failure. Actually, becoming multihomed will result in worse 
connectivity tha being single homed.

Now, this has been described a long time ago and solutions have been 
proposed.  (see http://tools.ietf.org/html/draft-huitema-multi6-hosts-03 
for instance)

However, in any case, this relies on doing some form of Source Address 
Dependent (SAD) routing in the multihomed site (in the intra site 
routing system)
Now, this  seems to be incompatible with current routing practices. (As 
someone with quite a lot of operational experience told me once about 
this topic... "your SAD routing is really sad indeed" )

So, coming back to your comment, i would say that  is not that people 
don't want to use multiple addresses, it is simply that there doesn't 
seem to be a reasonable solution to deal with them that is compatible 
with  operational practice.

NAT66 is one way to deal with this.
I hope there would be others. I don't believe we can say to people use 
SAD routing. I think people would rahter do nat66 than doing SAD routing.
So, if we are really serious about supporting multiple addresses, we 
should tackle this problem. But i don't think it is easy, and we 
probably need new ideas, cause old ideas seem to fail to fly.

Regards, marcelo

---

From: [email-masked]
Date: Sat, 08 Nov 2008 23:31:47 -0700

> mapping), or NAC66 (network address conversion).

I can live with anything that is not NAT.

---

From: [email-masked]
Date: Sat, 08 Nov 2008 23:40:46 -0700

Gert Doering writes: 

On Sat, Nov 08, 2008 at 04:20:42AM -0700, [email-masked] wrote:
>> I have yet to hear one serious reason why we need NAT in v6 given that >> all of the requirements that lead to it and have kept it alive for years >> in v4 do not exist in v6 and in some cases using it will break v6 
>> functionality. 
> 

Having worked for 2 telecom operators and supported multiple ISPs I have 
never heard this request from customer. Renumbering has always been a 
problem and all of the DHCP solutions to fix it still exist. 

What I am guessing that they are saying is "I don't want to be tied to a 
specific ISP forever so I want an easy way to reconfigure when I change". 
And for the occasional change (maximum of what 1 time per year?) I do not 
think that breaking end-to-end links is the answer. 

If this is what they want then lets bring back site locals (I am sure that 
some people will implement them and not notice that they were depreciated 
anyway). This at least is a straight forward fix that will not require 
bringing back NAT into v6. 

> build one.  Well, I think you could already do that today with BSD 

I disagree, if it is understood that using "a NAT66 box" means that VoIP, 
Video, PTP, and firewalls will not work as expected then the cost will be 
much higher than reassigning numbers in the DHCP pool. 

> about as unrealistic as assuming that there won't be NAT66 boxes.

As I said above, Site locals are preferable to NAT or IPv6 PI, don't break 
the end to end connectivity and don't undermine the security benefits of a 
consistent address through out the link. 
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 9 Nov 2008 23:30:58 +0100

On 7 nov 2008, at 19:18, [email-masked] wrote:

> support NAT in IPv6. We need to find a way to make it crystal clear  
> that NAT is not part of v6 and using it will be non-standard.

I don't think RFC 4864 is clear enough.

If the IETF is serious about avoiding IPv6 NAT, it needs to send out a  
warning to operators that they WILL have problems if they deploy it.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 9 Nov 2008 23:32:23 +0100

> for stateful packet filtering middlebox/firewalls.

Aren't ALGs supposed to be avoided as per BEHAVE consensus, because  
they are not always succesful in helping dumb applications but do tend  
to get in the way of smart ones?
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 9 Nov 2008 23:41:05 +0100

On 9 nov 2008, at 23:32, Iljitsch van Beijnum wrote:

> they are not always succesful in helping dumb applications but do  
> tend to get in the way of smart ones?

Also, James, you mention redirecting flows/sessions. The mechanism in  
the NAT66 draft does 1-to-1 address mappings, which is incompatible  
with performing session-specific operations.

---

From: [email-masked]
Date: Mon, 10 Nov 2008 01:47:20 -0700

> warning to operators that they WILL have problems if they deploy it.

Agreed. 

Now the problem will be getting consensus across the various WGs that seem 
to have taken up beyond what v6OPS did and agree to make such a statement. I 
am sure that we now have Behave and Softwires DHCPv6 (and others?) looking 
into NAT as there is still a perception that NAT is needed even after Site 
Locals were depreciated in RFC 3879 which became an RFC back in September 
2004. 

Given the fact that 3879 "formally deprecates them, but the deprecation does 
not prevent their continued use until a replacement has been standardized 
and implemented" - I am sure that they will be implemented by some networks 
anyway. (from the abstract of RFC 3879) 

Eric

---

From: Tim Chown <[email-masked]>
Date: Mon, 10 Nov 2008 12:09:29 +0000

On Mon, Nov 10, 2008 at 11:16:29AM +0100, Gunter Van de Velde (gvandeve) wrote:
> 
> Also, each enterprise customer I speak to of reasonable size does not
> want to be tied with the address space of the service provider. The cost
> of moving in addition to the downtime due to network transition is on
> top of their minds when they are speaking on v6. 
> 
> RFC4864 does provide alternatives for NAT in some cases, however there
> are gaps. As Brian mentioned in an earlier response, these GAPS could be
> solved in different ways, and while NAT66 may be one of them, there
> could be other solutions out there not being investigated. My prefered
> way of moving fwd is to first understand the actual problem that needs
> to be solved (problem space), then understand the solution space. Now,
> it seems the other way around, which makes little sense.

I think that's a very good point Gunter, but no matter how deep and thorough
the analysis of scenarios and proposals of solutions from the IETF that 
remove the technical need for NAT66, there's still a huge install base of 
users and sites that use IPv4 NAT today, and no doubt that some of those 
will want IPv6 NAT.  While many end users don't use NAT by choice, many -
perhaps larger - sites do.

If the IETF doesn't define IPv6 NAT, vendors will build solutions to meet
demand, and we'll probably end up with a variety of subtley different NATs 
like we do today for IPv4.

So I think there is a use in defining NAT66; it should buy some predictability
in the behaviour of 'NAT' for IPv6 networks.   But the uncomfortable fact is
that the only way that can be done is by the IETF implictly 'approving' IPv6
NAT, by defining it in an RFC.  

We will certainly see NAT for IPv4-IPv6 interoperability for a significant
time to come, so NAT isn't going away.   I think it is similarly important 
that NAT46 or NAT64 is defined in a way that maximises robust and predictable
behaviour (as much as that is possible).

Whether you call IPv6 NAT something else, be it SAM, NAM, or whatever, it'll 
still walk and quack like a duck, but at least just one variety of duck.

While I'm surprising myself by suggesting that defining NAT66 has value,
I think it is still important that we continue to show how applications and
networks are simpler to build, deploy and support without any form of IPv6 
NAT in use.   We should promote scenarios where IPv6 NAT is not required
where IPv4 NAT is used today, like SOHO networks.  Hopefully then the 
carrot is there for those users/developers/sites/ISPs that want to take 
advantage of that.   

-- 
Tim

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 10 Nov 2008 09:07:05 -0500

On Nov 9, 2008, at 1:40 AM, [email-masked] wrote:
>  And for the occasional change (maximum of what 1 time per year?) I  
> do not think that breaking end-to-end links is the answer.
> If this is what they want then lets bring back site locals (I am  
> sure that some people will implement them and not notice that they  
> were depreciated anyway). This at least is a straight forward fix  
> that will not require bringing back NAT into v6.
[...Clip...]
>
> As I said above, Site locals are preferable to NAT or IPv6 PI, don't  
> break the end to end connectivity and don't undermine the security  
> benefits of a consistent address through out the link.

In what way would site locals resolve the renumbering problem?  How  
are they better than IPv4 RFC 1918  addresses for this purpose?  What  
difference do you see between IPv6 site local addresses and IPv6 ULAs  
that would make a difference here?

Margaret

---

From: Gert Doering <[email-masked]>
Date: Mon, 10 Nov 2008 15:32:43 +0100

Hi,

On Mon, Nov 10, 2008 at 01:47:20AM -0700, [email-masked] wrote:
> to have taken up beyond what v6OPS did and agree to make such a statement. 
> I am sure that we now have Behave and Softwires DHCPv6 (and others?) 
> looking into NAT as there is still a perception that NAT is needed even 
> after Site Locals were depreciated in RFC 3879 which became an RFC back in 
> September 2004. 

I'm not sure I understand why NAT and the depreciation of site-locals 
have any deeper relationship?

ULAs exist.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Mon, 10 Nov 2008 15:39:22 +0100

Hi,

On Mon, Nov 10, 2008 at 11:16:29AM +0100, Gunter Van de Velde (gvandeve) wrote:
>  [ DHCPv6 makes renumbering easy, but... ]
>
> For end-systems statefull addressing could aid, however what about BGP
> sessions, addressing of network elements, access-lists, firewalls,
> etc... These will require manual handling and if realizing some networks
> count +10k network devices the operational overhead involved is not to
> be deminished.

Full agreement.  This is the sort of issues I had in mind where renumbering
might not be *that* easy.

(Just to avoid confusion.  When I mentioned customers asking for IPv6 PI
or NAT66 "solutions", this wasn't speaking about purely consumer-style
end users.  For those, I see no benefit in either approaches)

Gert Doering
        -- NetMaster

---

From: [email-masked]
Date: Mon, 10 Nov 2008 08:16:04 -0700

> it seems the other way around, which makes little sense.

This makes sense to me, lets first identify the problems we want to solve 
and then see how to fix them rather than assigning NAT as a solution to 
problems that are not clearly defined.
Eric

---

From: Gert Doering <[email-masked]>
Date: Mon, 10 Nov 2008 16:19:15 +0100

Hi,

> problems that are not clearly defined.

Well, the main unsolved problem I see is

 - (small to medium) enterprise customers that want to change their ISP 
   without renumbering their internal network

For larger enterprises, I see "acquiring their own IPv6 address space"
(either by means of becoming a member of their local RIR and grabbing
a "provider" allocation, or by means of IPv6 PI space) "and using BGP"
as the answer to that problem.

Gert Doering
        -- NetMaster

---

From: [email-masked]
Date: Mon, 10 Nov 2008 08:22:26 -0700

Margaret Wasserman writes: 

> 
> In what way would site locals resolve the renumbering problem?  How  are 
> they better than IPv4 RFC 1918  addresses for this purpose?  What  
Perception of what they are for and how they work is different. Otherwise 
they are just as bad as NAT - this is why they were created and then 
depreciated. 

We need a better understanding of the real needs (not just those of "I have 
v4 NAT and want v6 NAT") and then see what the solution is to the actual 
need. Otherwise we are taking a solution and looking for a problem.

---

From: [email-masked]
Date: Mon, 10 Nov 2008 08:26:25 -0700

> have any deeper relationship? 

Site Locals addresses were very similar in functionality to RFC 1918 
addresses, that was apparently why they were created. Now people are trying 
to revive the patch known as NAT into v6 when it is still not clear why they 
are needed beyond "that is how we always did it" solutions. 

If RFC 3879 and RFC 4864 are not detailed enough as to why local only 
addresses are not part of v6 lets do a proper need and gap analysis and then 
design a solution to what is really needed. 
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: [email-masked]
Date: Mon, 10 Nov 2008 08:52:51 -0700

>    without renumbering their internal network

Ok, this is a problem that needs a solution - is NAT the only solution? 

> as the answer to that problem.

This is a solution which can be handled via the RIR policies and has no 
bearing on NAT. What is the problem this solution is aimed at? Is it the 
same renumbering as above?
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Gert Doering <[email-masked]>
Date: Mon, 10 Nov 2008 17:06:31 +0100

Hi,

> Ok, this is a problem that needs a solution - is NAT the only solution? 

So far, I have seen 2 (.5) solution approaches:

  - NAT66
  - IPv6 PI plus "have provider announce and route it" (or do BGP)
 [- Map-and-Encaps schemes like LISP] 

> same renumbering as above?

This was not meant as a data point in the same problem space - this is
the differenciation between "smaller enterprises do not necessarily need
to go the IPv6 PI / RIR space / BGP route" and "larger enterprises will
very likely do this anyway".

Larger enterprises (just picking a random example: "cisco", "microsoft")
typically want multiple upstream providers and full control over their
routing.  Which today seems to mean BGP.

Actually this is a different problem space:

 - multihoming to different providers with full control over routing,
   and no renumbering on adding/removing providers

Gert Doering
        -- NetMaster

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 10 Nov 2008 11:16:29 +0100

<>start snip<>
> As for the specifics: having 1:1 NAT without port rewriting, maybe 
> even just swapping the first /64 bits, is what should serve the 
> purpose of "I want to be able to change providers, on a whim, without 
> renumbering my internal network", while at the same time having fairly
little impact
> on applications.   

This is why they have DHCPv6, one small change on the DHCP server and
the whole network should renumbered. 

<>end snip<> 

G/

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Nov 2008 19:10:17 +0100

Gert Doering   (1-12/1-31/200x) 11/10/08 4:19 PM:

Hi,

The Stateless Address Mapping of draft-despres-sam-01 is intended to
provide clean solutions to:

- SMEs that change ISPs

- Large entreprises that have multiple links to several ISPs.

The price to be paid is some complement if host stacks (backward
compatibles for incremental deployment, but not available today). It is
therefore not a solution for tomorrow morning, but it should not take
that many years.

An experimental implementation should soon be planned, initially with
Linux and  modified
Linksys boxes,  and hopefully also with Wi-fi mobile phones and other
hosts.

Pending availability of the solution in mainstream hosts, native IPv6
across IPv4 clouds, and IPv4 with its NATs and NAT cascades, should be
sufficient.

I have native IPv6 today at home, thanks to the 6rd deployment by Free
Telecom, with no plan to ever need NAT66s to do renumbering and
efficient multihoming.

Regards,

RD

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 10 Nov 2008 13:19:00 -0800

Margaret Wasserman wrote:
> If you are thinking about doing so, read RFC 4864 first.  

As you say later, the people deploying are not reading the RFCs, so what is
the point of those statements??? 

> However, (3)
> NAT66 in their networks.  

Document them. There is absolutely no reason to perpetuate the nat drug
unless you can document a use case that is not covered by the base IPv6
design, and the configuration examples shown in 4864. Effectively this
document is saying that people are so addicted to nat that we have to give
them an IPv6 one, despite the fact that they don't need it because their
goals can be met with designed in features.

> (4) If you are implementing a NAT66 product,

So rather than have the market produce a confused array of products that
might not sell well, the IETF is going to perpetuate an unnecessary
complexity that makes application development and deployment more difficult.
This show an extreme bias toward routing issues, at much greater expense to
the application side of the problem space. Application developers should not
need to know or learn about topology warts and dynamic changes about which
wart is in use at the moment, yet to pacify the one person that might have
to reconfigure a router on an ISP change, this effort is forcing exactly
that outcome.

> simplified by the existence of ULAs at all.

ULAs allow internal communications to persist unaffected by changes in the
external global prefix set. Any change in the external prefix set is going
to cause a disruption of the routing complex. The issue becomes is there a
smooth make-before-break overlap using RAs and lifetimes to minimize impact
to applications, or is there a flash-cut break-all-connections approach to
simplify the network manager's viewpoint of one address at a time? In this
document you are arguing that a flash-cut is more stable simply because the
numbers on the hosts don't change, where I am arguing that the numbers don't
matter it is the user experience of continuous application use that is more
stable. 

> accomplished by reconfiguring the NAT66 device(s).  Period.

Rather than make the network manager stop taking the nat drug, you prefer
that the application developers and end users continue to bear the cost of
dealing with network warts.

> to an RIR, and can afford it

If they can't justify it, they don't really need it, they simply want. In
IPv4 it was painful and difficult to justify space due to resource
limitations. The address space limitation goes away, so the only reason
everyone can't get a PI prefix is to minimize the impact to the routing
system resource. This means that GSE+, 66nat, whatever you want to call it
is about the core network, not the edge network manager preferences like
this document claims.

Mangling headers has a very high cost at the edge, and given that there are
many, many, many more edge systems than core systems, the overall cost to
the system is much higher with these approaches. 

> space.  So, they will go shopping for an IPv6 NAT box, instead.

If you are so convinced, demonstrate the need by documenting what it is they
can't do. The only thing that comes to mind as a simplifier would be Matt
Crawford's router-renumbering solution, which would make much more sense for
the IETF to spend its time on than perpetuating the nat drug.

> single subnet case, we will try to fix the text to make this clearer.

The mechanism completely ignores the case where multiple subnet/iid
combinations will result in the same public side address, and that is
compounded by only flipping the 'u' bit in some cases. The only way to
resolve the multiple-subnet/iid problem is for the device to be limited to a
single subnet, but even then it will fail for the case where the 'u' bit
overlaps. The document is compressing 80 bits to 63, but it is not a
loss-less compression, so it is ignoring reality.  

> consistent and less harmful way.

I have no problem with consistency, but this is not less harmful. 

> will not implement NAT66, it is unclear how your arguments relate to

This document does more harm than good by leading people to believe that it
is possible to build a 66nat that solves some mysterious problem. All it is
doing is perpetuating the nat drug without any valid justification for what
is not possible using approaches that do not break applications and raise
overall system costs. I have no doubt that the drug dealers will continue to
supply their customers, but I also see no reason for us to design a drug
that claims to be 'less harmful' when we know better.

> won't care if they are there or not.

Arguing that a lack of education is justification for perpetuating a known
problem doesn't cut it in the real world, so why should it work in the IETF?

> want to have a stable configuration for communicating with the global

And that stability goes away as soon as the network manager reconfigures the
external interface and breaks every active connection. The only way to have
a stable end user experience is to overlap the prefixes so that the
application gets to close existing connections gracefully and open new ones
against the new prefix. Having the same address on the host is not something
the end users care about. 

> today?  Or is the network administrator expected to build one him/

Any router that supports vlan's will work, because we specifically added
that use case based on your input. Any router that supports an IGP will work
because the first use case is host routes. Any router that supports a mIPv6
home agent will work for that use case. While the first two of those are
possible in IPv4, the only one that gets real use is the vlan in a DMZ
configuration. It does not get wider use, because the amount of space
available in IPv4 is limited.

> addresses would not be allocated on a prefix-per-subnet basis.  

Yes you can in the mIPv6 and vlan deployment scenarios. 

> So you
> how these host routes would be configured and propagated. 

Yes there is, it is the first use case and distribution is called an IGP.

> If you want

Read 4864 again.

> renumbers and changes your address allocation.

No it doesn't complicate the renumbering as you say, but I won't argue that
lack of education will lead many to look for the nat66 drug. Other than the
vlan scenario, it is likely that DHCP will be involved, but that can be
changed through whatever existing tools allow changing the subnet prefix
today. There is absolutely no need to configure host addresses into routers,
because they can and should announce themselves into the IGP when that
approach is used.

> specification for NAT66 or not.

Simpler for who? It perpetuates the nat drug false perspective about being a
security tool, but other than that it complicates the development and
deployment requirements for the applications and end users. 

> elaborate?  Perhaps give an example?

This algorithm claims topology hiding by using two unknowns (from the
external perspective) to create the exposed value. The external site knows
the algorithm, and assumes that hierarchal routing will be used, so with
enough samples you the attacker can reverse the algorithm to cull out the
set of subnet prefixes that make sense. If there is a nomadic node that hits
them regularly their data gets better, and if it has a cookie, the attacker
can over time really nail down which subnets it is coming in from. 

Rather than create the false pretense that this mechanism solves topology
hiding, we need to kill it.

> neworks being a single subnet.

The only way the algorithm comes anywhere near working is for the single
subnet case.

> 128-bit IPv6 address is the same for two internal nodes?

It will be more than 2, as this is an 80 -> 63 bit compression will loss.

>  I think you

That is the core of why this document needs to be killed off. Solving the
problem requires a loss-less 80 -> 63 bit compression scheme that can't be
reversed. 

> don't change it.  What is wrong with that?

By itself that guarantees a duplicate. 

> they will choose differently when they deploy IPv6?

Persisting on the GSE path and expecting a different outcome is the insane
part. We are not in the business of telling anyone what to deploy, just how
to make things that interoperate. NAT AND TOPOLOGY-UNAWARE APPLICATIONS
don't interoperate. Claiming that we need to persist with nat drug simply to
satisfy the addicts is wrong, and counter to our mission of defining
interoperability. 

At the end of the day the thing that matters is the application experience,
and making that more complex in the name of simplifying the configuration of
an edge device is just wrong.

Tony

---

From: james woodyatt <[email-masked]>
Date: Mon, 10 Nov 2008 14:24:20 -0800

On Nov 10, 2008, at 07:26, [email-masked] wrote:
>
> [...] Now people are trying to revive the patch known as NAT into v6  
> when it is still not clear why they are needed beyond "that is how  
> we always did it" solutions.  If RFC 3879 and RFC 4864 are not  
> detailed enough as to why local only addresses are not part of v6  
> lets do a proper need and gap analysis and then design a solution to  
> what is really needed.

As I have periodically tried to remind everyone, there is a usage  
scenario for NAT in IPv4 that is not addressed by RFC 3879 or RFC  
4864, and it remains in my view the one compelling reason for  
specifying how NAT66 should work.  That scenario is the one where  
stateful packet filtering for application flows is transparently  
inserted on paths into and out from enterprise networks using an  
address translation to redirect flows at border routers to the  
application-filtering middleboxes.

You can imagine doing that without address translation, i.e. with  
tunnels and redirects, but that raises practical issues with path MTU,  
and it just moves the address translation from the insertion point to  
the application helper.  You've still got the translation and the  
potential for transparency loss that comes with it.  It's important to  
remember that people deploying systems like this tend to view end-to- 
end integrity as a bug rather than a feature, and the introduction of  
potential for transparency loss is the whole point of the exercise.   
If doing it with NAT66 instead of tunnels and redirects makes  
practical sense to enterprise network operators, and I think it does,  
then I assure you... that's how it will be done.

As much as I would like to believe that enterprises will stop feeling  
the need to deploy this kind of nonsense, I'm very skeptical that IETF  
will be able to change their minds.  If we're going to have  
middleboxes that intercept and process IPv6 application flows, then I  
don't see how NAT66 or something like it can be avoided.

That said, I'm not impressed by the arguments put forward by the  
opponents of RFC 4864 local network protection who, in my view, are  
greatly exaggerating the seriousness of the network renumbering  
problem.   My response to that concern is that any organization too  
small to win a PI allocation and too poor to bear the almost  
negligible expense of renumbering an IPv6 network [much smaller than  
renumbering an IPv4 network] is an organization with more serious  
problems than its difficulty in changing its Internet service  
provider.  I don't see why such organizations should have much  
standing here, and I think we should ignore them while we have more  
important problems to solve, e.g. IPv4-IPv6 coexistence matters.

---

From: james woodyatt <[email-masked]>
Date: Mon, 10 Nov 2008 14:44:26 -0800

> tend to get in the way of smart ones?

p1. We're calling them "helpers" now because they're not really  
gateways because they don't translate addresses inside the application  
flows [though, they do everything else].

p2. I don't believe the BEHAVE consensus on application helpers will  
be adopted by industry.  In fact, I'm skeptical that industry will  
even be *aware* of the BEHAVE consensus when they start looking for  
solutions to the problems they create for themselves by refusing to  
adopt the RFC 4864 approach to local network protection.

> [...] which is incompatible with performing session-specific  
> operations.

Hmmm.  I would more-or-less agree with you.  I regard this as a  
deficiency in the NAT66 specification, which I now think is basically  
a technical solution for a problem that only arises out of  
misperceptions about issues relating to RFC 4864 local network  
protection.

If we're going to recognize that we need NAT for IPv6, then I say we  
should eat the whole apple.  If we want to keep NAT for IPv6 from  
becoming a problem, then we're going to need to go to war against all  
middleboxes period full stop.  I don't think IETF has the stomach for  
the latter-- and, while the former may seem distasteful now, look on  
the bright side: it's likely to mean full-employment for Internet  
engineers for the rest of our natural lives.

---

From: Gert Doering <[email-masked]>
Date: Tue, 11 Nov 2008 08:52:43 +0100

Hi,

On Mon, Nov 10, 2008 at 02:24:20PM -0800, james woodyatt wrote:
> My response to that concern is that any organization too  
> small to win a PI allocation [..]

Just to clarify this: the problem with PI is not that it's hard to get
- the problem with PI in its current form (i.e.: "BGP routed, non -
aggregateable") is that it puts a burden on all ISP routers out there.

In IPv6, "address space wastage" is much less of a problem than in IPv4 -
but "routing table slots" could be a much more serious issue.

Gert Doering
        -- NetMaster

---

From: [email-masked]
Date: Tue, 11 Nov 2008 01:03:38 -0700

> but "routing table slots" could be a much more serious issue.

This has been a problem ever since we broke class full addresses, routing 
tables are bound to get very large as there are more multi-national and 
multi-carrier organizations out there. This is what justifies Cisco, 
Juniper, etc. in selling larger more powerful core and edge routers to the 
carriers and ISPs. 

But as I understand it, problems with BGP are out of scope for both the 
groups holding this discussion.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Gert Doering <[email-masked]>
Date: Tue, 11 Nov 2008 09:12:12 +0100

Hi,

> Juniper, etc. in selling larger more powerful core and edge routers to the 

I understand how the market works :-)

The point is: IPv6 PI is considered one solution for the "I want to be
able to change providers without renumbering" problem space - and there
are a fair number of affected parties (namely: ISPs having to buy bigger
and bigger routers) that think that this is a non-scalable approach.

Gert Doering
        -- NetMaster

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 11 Nov 2008 14:32:30 +0100

> gateways because they don't translate addresses inside the  
> application flows [though, they do everything else].

Right. I suppose a "helper" that opens up a port in a firewall so RTSP  
can work but doesn't meddle with the data in the RTSP packets wouldn't  
be harmful.

> adopt the RFC 4864 approach to local network protection.

And this argument supports which action that we should/shouldn't  
take...?

Unawareness elsewhere of what the IETF is doing doesn't help the IETF  
in deciding what it should be doing...

> deficiency in the NAT66 specification,

Well, the whole point of the NAT66 draft is to avoid all the issues  
that arise from doing stuff at the transport layer in NAT44.

> should eat the whole apple.

No, I'd say we avoid the part where the worm resides...

> If we want to keep NAT for IPv6 from becoming a problem, then we're  
> going to need to go to war against all middleboxes period full  
> stop.  I don't think IETF has the stomach for the latter-- and,  
> while the former may seem distasteful now, look on the bright side:  
> it's likely to mean full-employment for Internet engineers for the  
> rest of our natural lives.

Our architecture doesn't support middleboxes. So I guess that means we  
need a new architecture.

Our architecture also doesn't support changing addresses in transit.  
This is something that's easier to change, so we could simply decide  
to make that architectural change. But the current situation where we  
have an architecture that doesn't support it, but a network that  
requires this support, is not a good thing. I don't need a job that  
badly.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Nov 2008 16:29:32 +1300

On 2008-11-11 11:24, james woodyatt wrote:
...
> problem.   

James, and anyone else who is still able to focus on this thread:

Please read draft-carpenter-renum-needs-work-00.txt and send
comments and suggestions to its authors.

    Brian

---

From: james woodyatt <[email-masked]>
Date: Mon, 17 Nov 2008 23:22:14 -0600

> comments and suggestions to its authors.

I'm delighted to read this draft.  I remain unconvinced by arguments  
that the network renumbering problem is a compelling argument for the  
need to insert thirty gazillion PI routes into the DFZ.

----

Some thoughts on section 2.2, Existing Host-related Mechanisms => PPP...

For IPv4, PPP endpoints acquire (during IPCP negotiation) both their  
own address and the address of their peer, which may be assumed to be  
the default router if no routing protocol is operating.  Renumbering  
events arise when IPCP negotiation is restarted on an existing link,  
when LCP is terminated and restarted, or when the point-to-point  
medium is reconnected.  (I can't remember right now whether NCP must  
be renegotiated if an authentication protocol is restarted while NCP  
is up.)  Peers may propose either the local or remote address or  
require the other peer to do so.  Negotiation is complete when both  
peers are in agreement.  In practice, if no routing protocol is used,  
then the provider proposes both addresses and requires the subscriber  
either to accept the connection or abort.

For IPv6, PPP endpoints acquire both local and remote addresses during  
IP6CP negotiation in much the same way as for IPv4, but the addresses  
are link-local scope only.  In practice, each side can propose its own  
address and renegotiation is only necessary when there is a  
collision.  Once link-local addresses are assigned and IP6CP is  
complete, automatic assignment of global scope addresses is performed  
by the same methods as with multipoint links, i.e. either SLAAC or  
DHCP6, which are described in the subsequent sections of the draft.

----

Also: section 2.5 about DNS... this section really, really, really  
ought to at least think about mentioning DNS-SD (for which the  
relevant Internet Drafts-- for reasons that continue to plague the  
twilight of my waking dreams-- are categorized as Informational, and  
not Standards Track).

If you've never heard of DNS-SD before, then please look at...

	<http://www.dns-sd.org/>

...and follow the links from there.  The executive summary is that not  
only can we dynamically update the DNS with host address records, we  
can even do it with *service* instances too, which are pointers to  
service records that reference host records.  It works pretty well.   
Really.  I renumber some of my networks *dozens* *of* *times* *per*  
*DAY*.  Some of these are *virtual* networks.  It's not even remotely  
painful until I start trying to do it a few dozen times per *hour*.   
That's pretty good!

Yes, DNS-SD and DNSSEC are quite compatible.  Really.  Come join us in  
the Future™.  It's nice here.  Stuff just works.

-----

The M&O bits.  I'm one of those who thinks that ICMP6 is the protocol  
that ought to be used for control and management of the Internet.  I  
think that DHCP (with DHCP6, it's 2nd-system-effect offspring) is a  
monster that slipped its leash a long time, and we're all poorer for  
it now.  So, it should not be a surprise that I favor resolving the so- 
called "M&O ambiguity" by clarifying the specification to say that  
starting the DHCP6 client is *always* OPTIONAL and that nodes *always*  
MAY self-assign a global scope address after receiving any RA  
containing a PIO with A=1.

I recognize that my preferred approach poses some problems (many of  
which are the subject of ongoing work in the SAVI and V6OPS working  
groups), but I contend that we will all be better off if *those* are  
the problems we choose to make for ourselves and we proceed now to set  
our minds to solving them.  The other problems we invite for ourselves  
resolving the M&O ambiguity by different means are more troubling, I  
say.  We might as well just get rid of SLAAC altogether and require  
DHCP6 everywhere.  I know that would make some people happy, but not  
me.  I rather like zero configuration networking.

-----

On section 4.1.2, Transport Layer Issues... let me just say that SCTP  
is made of the purest elegance and beauty.  We should deprecate TCP  
over IPv6 in favor of SCTP, it's so good.  Oh wait... worse is  
better.  I keep forgetting.

So, if we *can't* migrate to SCTP, and we MUST find a way to live with  
TCP and UDP, then we're just going to have to lump it when renumbering  
causes failurage on TCP/UDP flows.  But that shouldn't be so bad,  
really.  You want SCTP-style multihoming with your TCP transports?   
Then you can implement it in your session^H^H^H^H^H^H^H application  
layer.  (If I wanted to be especially curmudgeonly, I'd suggest a BEEP  
tuning profile for the TCP transport mapping, but I'll go easy on that  
for now.)

-----

On section 4.1.4, Application Layer Issues... the following quote is  
the understatement literally of the decade:
> The sensitivity depends on whether the implementation stores IP  
> addresses in such a way that it may refer back to them later,  
> without allowing for the fact that they may no longer be valid.
                             
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This, in my view, is the main reason why IPv6 renumbering should be  
regarded as "still needs some work" instead of "why are we worrying  
about this?"  But the work in question isn't IETF work, I contend.   
It's just mundane code-wrangling work.

I've highlighted what I regard as the crucial phrase.  We're talking  
about software bugs.  We're talking about software bugs of a general  
class, i.e. cache coherency failures, that cannot really be mitigated  
by sacrificing fundamental principles of the Internet architecture to  
make the renumbering events that expose them less frequent.  There are  
so many other ways, which have nothing to do with network renumbering  
events, that bugs of this class can make expensive software failures  
happen.  I'd prefer we find ways to build better coders, than we were  
to expend any effort trying to take Internet address renumbering off  
the long list of interesting ways that incoherent caches can break  
software.

My employers have a developer technote on their website that speaks to  
this general class of software problem in networked applications.  The  
tenth anniversary [!] of its original composition came and went a few  
days ago.  The document is here:

	<http://developer.apple.com/technotes/tn/tn1145.html>

Seriously.  Check it out.  Application layer issues with renumbering  
events would not be expensive if the platform-independent lessons of  
that technical note were more widely applied.

I am so *so* tired of making excuses for bad code.  Just once, I'd  
like to be able to say, "I see your coders thought it would be a good  
idea to store IP addresses in a persistent store without any cache  
coherency protocol, and now you can't renumber your network without  
eating the time and expense of qualifying a radical new implementation  
of your hugely business-critical software application.  You know  
what?  That's your own fault.  Not ours.  p.s. I bet you'll read that  
tech-note next time, right?"

---

From: Gert Doering <[email-masked]>
Date: Tue, 18 Nov 2008 23:01:37 +0100

Hi,

> tech-note next time, right?"

OK, I bite.  What answer do you give to folks that need to renumber
things like site-to-site VPN endpoints, which affects lots of configuration 
to be changed by *other* folks (their VPN peers)?

This happens to be the one of the main issues being brought forward by
people that want stable addresses.

(I'll go through the draft itself some time tomorrow)

Gert Doering
        -- NetMaster

---

From: james woodyatt <[email-masked]>
Date: Tue, 18 Nov 2008 18:29:54 -0600

> to be changed by *other* folks (their VPN peers)?

Please, help me understand why solving this problem requires storing  
IP addresses in persistent storage without a coherent caching  
protocol.  I'm not seeing it-- probably because I'm not sure I  
understand the nature and scope of the problem very well.

For the sake of argument, I'll accept that reasonable people currently  
perceive it to be necessary.  My hunch is that those folks should  
probably be using DNS-SD instead of the fragile cruftiness they're  
struggling against now.  Maybe if I understood the problem better, I  
could suggest a more detailed alternative to their current solution.

---

From: Gert Doering <[email-masked]>
Date: Wed, 19 Nov 2008 10:22:01 +0100

Hi,

> understand the nature and scope of the problem very well.

Uh, well, people usually configure their VPN endpoints (site-to-site, 
not roadwarrior-to-home) with IP addresses.

> could suggest a more detailed alternative to their current solution.

Well.  Yes.  I've spent some time after my e-mail yesterday to think about
this, and actually using DNS (plus some sort of "not completely braindead
IPSEC implementation") might just work, provided one can get old+new 
addresses working for long enough to DNS to propagate.  

Which is not instantaneous, as soon as it leaves the local domain.

Now *this* aspect reduces itself to "educated people that DNS is good"
and "educate firewall vendors to write useful IPSEC code".

Another thing that is regularily mentioned regarding "why renumbering is 
hard" is access-lists (aka "firewall rules").  DNS as well?

Gert Doering
        -- NetMaster

---

From: james woodyatt <[email-masked]>
Date: Wed, 19 Nov 2008 18:57:52 -0600

On Nov 19, 2008, at 03:22, Gert Doering wrote:
>> Please, help me understand why solving this problem requires  
>> storing IP addresses in persistent storage without a coherent  
>> caching protocol.  I'm not seeing it-- probably because I'm not  
>> sure I understand the nature and scope of the problem very well.
>

Ah.  I've given this more thought now, and I'm going to assume that  
we're talking about L3 VPN's and not L2VPN's (but I'm not sure that's  
warranted here).

> and "educate firewall vendors to write useful IPSEC code".

Now that I've had a chance to think about this more carefully, I'm  
reminded of the old, old days when I used to work in an enterprise  
that managed its routing table by copying static routes around with / 
usr/bin/rcp.  This eventually became painful enough that some bright  
soul noticed that networked computers can executed distributed route- 
computation algorithms, e.g. Bellman-Ford, link-state, etc.

I suspect that large enterprise sites with massive collections of  
static VPN tunnel configurations, which need their tunnel endpoint  
addresses renumbered when adding or dropping a PA allocation, would do  
well to think about how such distributed algorithms could be used to  
ease the pain of renumbering.

I would imagine that enterprises with this problem would have an  
incentive to develop a standard protocol for automatically managing  
the routes for complicated VPN topologies.  (I'll even go so far to  
say that something like BGP might be easily adapted to serve in this  
capacity, but I'm not sure.)  I do feel pretty certain about this  
point: before we set about systematically dismantling the utility of  
the provider aggregated addressing architecture in IPv6 as it relates  
to our problems maintaining the scalability of the default-free zone,  
I'd like to see an explanation for why enterprises view automating VPN  
tunnel management as a non-viable alternative solution.

> hard" is access-lists (aka "firewall rules").  DNS as well?

Sigh.  It's probably a good idea for large sites to use network  
operations and management systems that recognize the distinction  
between the network prefix and the host identifier parts of IPv6  
address.

I recognize that not all IPv6 addresses have such a distinction, but  
enterprises worried about this could conceivably choose IPv6  
deployments where the distinction is significant-- because they can  
use [or build] tools that easily allow access-lists to be composed  
automagickally by combining the host identifiers (don't need  
renumbering) with network identifiers (do need renumbering) without  
requiring a human person to have to sweat all that tedious arithmetic  
and typing.

I anticipate a rebuttal to my arguments above along the lines of this:  
"That's nice, James... but those routing protocols and network  
management tools don't exist today, and we need them!"  My response is  
quite simple: "True, but those are problems worth solving, and I don't  
see how it's a good idea to *avoid* the work of solving them at the  
cost of A) introducing NAT66 into the Internet architecture and/or B)  
exploding the routing tables in the default-free zone."

I could be wrong about that, but I remain unconvinced.

---

From: [email-masked]
Date: Thu, 20 Nov 2008 02:42:19 +0000

"I do feel pretty certain about this point: before we set about systematically dismantling the utility of the provider aggregated addressing architecture in IPv6 as it relates to our problems maintaining the scalability of the default-free zone,  I'd like to see an explanation for why enterprises view automating VPN  tunnel management as a non-viable alternative solution."

Completely agree, with more conversation needed for 'dynamic, (ideally) hitless' VPN endpoint renumbering (and discovery of those endpoints, possibly as a separate item?)

/TJ ... in Post-Plenary-recovery mode ...
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: james woodyatt <[email-masked]>

Date: Wed, 19 Nov 2008 18:57:52 
To: Gert Doering<[email-masked]>
Cc: IPv6 Operations<[email-masked]>; Behave WG<[email-masked]>
Subject: Re: [BEHAVE] The renumbering problem [Re: Comments on the NAT66
	draft]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 25 Nov 2008 18:14:00 +0100

On 19 nov 2008, at 1:29, james woodyatt wrote:

> My hunch is that those folks should probably be using DNS-SD instead  
> of the fragile cruftiness they're struggling against now.

Can DNS service discovery be secured with DNSSEC?

What if there are unsigned delegations in the delegation hiearchy?

If I'm going to base my firewalling rules or VPN setup on the DNS then  
the DNS info must be protected against poisoning and other attacks.

Iljitsch

---

From: james woodyatt <[email-masked]>
Date: Tue, 25 Nov 2008 10:00:46 -0800

> Can DNS service discovery be secured with DNSSEC?

Yes.

> What if there are unsigned delegations in the delegation hiearchy?

Don't let that happen.  There are additional problems.  See below.

> If I'm going to base my firewalling rules or VPN setup on the DNS  
> then the DNS info must be protected against poisoning and other  
> attacks.

See my earlier message where I thought more carefully about this  
problem and suggested that a routing protocol might be more  
appropriate.  I suppose it could still be done with DNSSEC, but until  
the global root and the major TLD's all get signed, and various NAT  
gateways start supporting EDNS0 and recursive proxies become security  
aware, I think that's not going to work very well.  Hence, the routing  
protocol idea.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 26 Nov 2008 10:04:07 +0100

> appropriate.

I must have missed that one. But it seems to me that that would be  
extremely hard to deploy between different organizations.

> I suppose it could still be done with DNSSEC, but until the global  
> root and the major TLD's all get signed,

What if I'm an enterprise and I want to let some users and/or  
suppliers in into my network, I just put CAs for their keys in my  
system, then I don't have to depend on a trusted delegation hierarchy.

> and various NAT gateways start supporting EDNS0 and recursive  
> proxies become security aware

All of this is enterprise stuff, they can afford the good stuff that  
lets the DNS protocol through unmolested.

(What idiot thought it was a good idea to make home gateways DNS  
proxies, and therefore make the DNS unupgradable, anyway?)

---

From: james woodyatt <[email-masked]>
Date: Wed, 26 Nov 2008 11:23:32 -0800

> proxies, and therefore make the DNS unupgradable, anyway?)

The same idiots who thought that when the DHCP/PPPoE client used on  
the WAN interface finds a new list of recursive DNS proxy servers,  
maybe because it changed networks or maybe just because the network  
changed the server addresses, the hosts on the LAN/wireless interfaces  
ought not to lose their DNS service.  ("Oh HAI!  Your Intarwebs Was  
BROKED, So I Fixxed THEM.")

These are also the same idiots who thought it would be a good idea to  
have a DNS server that could at least respond almost sensibly for  
reverse queries about the private subnet addresses even when the WAN  
interface is down or service is interrupted.

The problem arises because service providers won't give a DHCP lease  
or a PPPoE session to every device on the LAN that asks for one, and  
there isn't a reliable way for a DHCP server in CPE gateway to tell a  
client that its DNS server list needs to be updated, because, well, we  
don't have a good way for a DHCP server to modify/revoke an existing  
lease held by a client, because, well, just imagine the security hell  
*that* might cause.  Once again, we are staring into an abyss of our  
own making because we insisted on using DHCP where instead we should  
be using something sensibly designed from the ground up as a network  
authentication/access protocol, e.g. EAPOL.

I know I know.  I sound like a broken record.

There's also the minor detail that a lot of DNS resolvers are too  
stupid to randomize the ports from which they send queries, and having  
a proxy do that for them improves their security.  This was a well- 
known problem long before the Kaminsky bug.

p.s. It could be scarier.  Imagine residential CPE gateways with *non- 
forwarding* recursive DNS proxy servers.