Subject: RE: [BEHAVE] Comments on the NAT66 draft

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 

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!

---

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: "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: 

> 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
> - 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.)
>

---

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.

---

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.

---

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: 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

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

---

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).
> 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.
> 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.
>
> - 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.
>
> - 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.
>
> - 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 :-) .
>
> - 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:
> - 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: 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

---

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

---

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: 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: [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.

---

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.

---

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: "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<> 

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.

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.

G/

---

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

> 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... ]
>

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: Gert Doering <[email-masked]>
Date: Mon, 10 Nov 2008 16:19:15 +0100

Hi,

On Mon, Nov 10, 2008 at 08:16:04AM -0700, [email-masked] wrote:
> 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.

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:16:04 -0700

---

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.

---

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?

---

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: 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: 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.

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

---

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.

---

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: 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: 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