Subject: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

From: Fred Baker <[email-masked]>
Date: Sun, 4 Aug 2013 11:00:03 -0700 (PDT)

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6.  Please read it now. If you find nits
(spelling errors, minor suggested wording changes, etc), comment to the
authors; if you find greater issues, such as disagreeing with a
statement or finding additional issues that need to be addressed,
please post your comments to the list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Aug 2013 10:34:43 +0900

> please post your comments to the list.

As stated at the mike, I think all mention of ULA+NPT66 should be removed,
because:

   1. AFAIK this is not a scenario that is specified in any RFC, and it is
   not appropriate to introduce it here in passing, since this document is
   only tangential to ULAs.
   2. This working group is also discussing this same question - with a
   fair amount of controversy - in the ULA usage draft. That discussion should
   be held in only one place and should not hold up this document.
   3. There is zero or near-zero experience of this deployment model. The
   authors did not appear to be aware of any deployments that actually used
   this model. Also, RFC6724-compliant hosts will always prefer IPv4 over ULA,
   so they will in effect never use them at all; the fact that this is not
   mentioned in the draft suggests that nobody has actually done this.

If ULAs are to be cited in the draft, then they should be mentioned in the
context of the only scenarios currently specified by the IETF, either in
networks that are completely isolated or in conjunction with global
addresses.

---

From: Erik Kline <[email-masked]>
Date: Mon, 5 Aug 2013 04:03:52 +0200

> As stated at the mike, I think all mention of ULA+NPT66 should be removed,

Agreed.

---

From: <[email-masked]>
Date: Mon, 5 Aug 2013 10:23:02 +0200

WG, 

I've read (and commented) this draft some time ago. This document is useful and I think it should move forward.

Regarding the ULA-related discussion, I don't think the document should simply ignore the potential use of such addresses, e.g., because our experience of providing IPv6 VPN service to our corporate customers since 2009 has shown that some of these customers ask for (and sometimes demand) a ULA-based addressing plan, mostly because these customers still think that private addressing provides some form of security. 

This is partly an educational matter which we usually address by organizing training sessions within the enterprise, but the reality is that we could never avoid the discussion about ULA usage with these customers. And there are indeed a few of them who have chosen to go for an ULA addressing plan, at least for the duration of field trials or even pilot deployments.

I would therefore expect the draft to mention ULA addresses. But I would also expect the draft to clearly discourage the use of such addresses, for the reasons mentioned by Lorenzo in his recent message. 

For the sake of readability, I would (1) remove the ULA-related text from Sections 2.4.2, 3.1 and 6.3, and (2) dedicate a specific "On ULA Addressing and Its Foreseen Implications" subsection in Section 2.6, which would better elaborate on the warnings highlighted in the aforementioned sections (e.g., Section 3.1's "use of PI space obviates the need for ULAs").

A few additional typos:

Section 2.1, page 7: "...after all initial *deployment* has been completed."
Section 2.2.2., page 9: s/recommend/recommended
Section 6.3, page 26: s/enterprise/university (second paragraph), s/campus enterprise/campus
Section 8, page 27: s/Jaquenet/Jacquenet 

Cheers,

Christian.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Fred Baker
Envoyé : dimanche 4 août 2013 20:00
À : [email-masked]
Objet : [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6.  Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 05 Aug 2013 10:20:23 -0400

On 2013-08-05 4:23 AM, "[email-masked]"
<[email-masked]> wrote:
>
>Regarding the ULA-related discussion, I don't think the document should
>simply ignore the potential use of such addresses, e.g., because our
>experience of providing IPv6 VPN service to our corporate customers since
>2009 has shown that some of these customers ask for (and sometimes
>demand) a ULA-based addressing plan, mostly because these customers still
>think that private addressing provides some form of security.

Agreed in principle.  I am not able to talk about my personal experiences
per NDA with customers.  I would say the the use of ULAs in a network is
not a secret and people are considering it.  Being mute on the subject may
result in incorrect analysis of ULA validity in the enterprise. Not
considering the good/bad, or the various aspects by which one needs to
factor it against - I.e. Security, Internet Reachability, inter-op with
other functions like Multicast etc).

> 
>
>This is partly an educational matter which we usually address by
>organizing training sessions within the enterprise,

Fair enough, but I am sure there may be some mis-informed folks
potentially advising some customers in the other direction (lets call them
rogue consultants).  My largest concern is that irrespective of any IETF
guidance (if it's negative or positive), ULAs will likely still show up.

>
>
>I would therefore expect the draft to mention ULA addresses. But I would
>also expect the draft to clearly discourage the use of such addresses,
>for the reasons mentioned by Lorenzo in his recent message.

I want to agree with this, but given we have little long term operational
experience with ULAs, discouraging it's use based on perceived downfalls
may be as bad as encouraging it.  If we are unable to provide guidance one
way or the other, then pointing to other works (which will continue this
debate I am sure), may be the most practical.

I think some mention of ULAs, in-line with the text is a good idea since
it's with the flow of the document (I.e address subject matters based on
document context). 

As an example, Section 2.4.2 discusses ULAs with respect to [perceived]
connections to RFC1918 and security.  It was the specific intent of the
draft to provide such security guidance in-line.  I think pulling out such
text would then leave the reading to guess whether ULAs play into the
security considerations during the assessment phase.

So in summary (my input):
(1) Mention ULAs, in-line within text per relevant topic area
(2) Don¹t encourage it's use, and provide due warning of potential issues
(again in-line)*
(3) Point to other works/drafts on usage cases and further information

* I think repetitive warnings throughout document, per subject area will
have a better deterrent affect vs. a single section with a "bad for your
health" warning.

Regards,

Victor Kuarsingh

>http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6.
>Please read it now. If you find nits (spelling errors, minor suggested
>wording changes, etc), comment to the authors; if you find greater
>issues, such as disagreeing with a statement or finding additional issues
>that need to be addressed, please post your comments to the list.
>
>__________________________________________________________________________
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 5 Aug 2013 16:37:53 +0000

A thought - tell me if this makes sense.

In IPv4 networks, it is pretty common to in some way advertise the address of an internal-only server and then block access to it at the firewall. If you want Cisco examples, try wwwin.cisco.com or irp-view13.cisco.com - dig them, ping them, and traceroute towards them. From my perspective, in IPv4 or in IPv6, the firewall rule makes little sense except as an additional defensive layer; one should not advertise the name to the great unwashed, and whether or not one does, one should give the system an address that is not advertised to the great unwashed. The next question, of course, is how to achieve that - does one only advertise half of their address space? Announce multiple prefixes? The ULA, whatever its other ills or uses may be, is an address that is not advertised upstream, and therefore a very logical address for an internal-only system in an IPv6 network.

I scratch my head a bit on the vehemence that seems to come across in discussions of the ULA. I understand that there is a strong distaste for NATs, and I share it in the stateful case. It sounds a bit like the baby is being discarded with the bathwater, though, in the case of a system that one doesn't want to have communicating with the great wide world.

Am I out to lunch? If so, in what way?

> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an importa…

	• Make things as simple as possible, but not simpler.
Albert Einstein

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 Aug 2013 18:56:22 +0000

Hi Fred,

See below for my comments:

Thanks - Fred
[email-masked]

1) Suggest going through the document and update any references that
   were once I-Ds but have since been published as RFCs (editorial).

2) Abstract - change: "and potentially an IPv6-only operating mode."
   to: "and eventually an IPv6-only operating mode." ?

3) Throughout the document, the use of "tunnels" seems to generically
   refer to tunnels used for IPv6/IPv4 transition purposes and is used
   in a somewhat negative light. However, IPv6 tunnels will be used in
   enterprises for the long term for other crucial functions.

   To disambiguate, suggest going through the document and change the
   word "tunnels" to "transition tunnels" where this is the intended
   meaning. Also add text similar to the following near the beginning
   of the document:

   "Tunnels used for IPv6/IPv4 transition are expected as near/mid-
    term mechanisms, while IPv6 tunneling will be used for many
    long-term operational purposes such as security, routing control,
    mobility, multi-homing, traffic engineering, etc. We refer to the
    former class of tunnels as "transition tunnels".

4) Section 4.3, end of third paragraph, add the sentence:

   "For example, mobility management functions will be needed to
    accommodate handovers between diverse access technologies."

5) Section 4.3, add a final paragraph such as:

   "Enterprise networks more and more include virtual networks where
    a single physical node may host many virtualized addressable devices.
    It is imperative that the addressing plans assigned to these virtual
    networks and devices be consistent and non-overlapping with the
    addresses assigned to real networks and nodes. For example, a
    virtual network established within an isolated lab environment
    may at a later time become attached to the production enterprise
    network." 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Fred Baker
> Sent: Sunday, August 04, 2013 11:00 AM
> To: [email-masked]
> Subject: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
> 
> http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-
> ipv6.  Please read it now. If you find nits

---

From: Ray Hunter <[email-masked]>
Date: Mon, 05 Aug 2013 21:33:15 +0200

Fred Baker (fred) wrote:
> In IPv4 networks, it is pretty common to in some way advertise the address of an internal-only server and then block access to it at the firewall.

This might be classified as a "leak" if they were 192.168/16 addresses.

But for GUA I see no harm advertising them, either in the namespace or
the routing space.

The information is invariant inside and outside: they're just not
reachable from everywhere.

>  If you want Cisco examples, try wwwin.cisco.com or irp-view13.cisco.com - dig them, ping them, and traceroute towards them. 

The examples you gave are equivalent of GUA, and Internet DNS.

> From my perspective, in IPv4 or in IPv6, the firewall rule makes little sense except as an additional defensive layer; one should not advertise the name to the great unwashed, and whether or not one does, one should give the system an address that is not advertised to the great unwashed.

Agreed. Agreed. It's not just security. It's to avoid confusion, cached
connections etc.

>  The next question, of course, is how to achieve that - does one only advertise half of their address space? 
Name space is the key here IMHO. Not just address space. You're into DNS
Bind "view" territory.

Especially when you have devices that wander regularly across the border
and that cache lots of information.

> Announce multiple prefixes? The ULA, whatever its other ills or uses may be, is an address that is not advertised upstream, and therefore a very logical address for an internal-only system in an IPv6 network.
True. But how does your machine know it is "internal only" or "external"
with VPN's, proxies, ALGs etc. etc.
And how long is that definition valid? When management gets outsourced
to supplier X?

> Am I out to lunch? If so, in what way?

It's the confusion equivalent to the .local namespace that bothers me more.

I've seen people configure a server x.foobar.com in DNS that is not only
a different IP address on the inside and outside, it's a completely
different machine.
Or it might not be a different machine, but it's one machine with a
different physical interface with completely different firewall rules.

If you then have a cached bzr: checkout over ssh on your mobile device,
you're going to get confused machines and users.

A URL should be universal. Especially in a world that is becoming
increasingly mobile.

Once you start using ULA + NPT, all URLs and DNS entries become
equivalent to .local namespace + RFC1918, depending on your current
connection point relative to the NPT and the server. i.e. you've got no
idea if the NPT is in path or not. NPT doesn't translate the DNS AAAA
records. And DNS replies are cached.

Then you end up with all sorts of horrible kludges in the OS and apps to
detect whether your device is "on net" or "off net".
And then you start to wonder what is the definition of "on net" and "off
net" when there's so many different ways of traversing the boundary.

You could be on-net via proxy bypass for one HTTP site. And off-net for
another HTTP site via a proxy (steered via a .pac file).
And then you could be on-net for SSH (no proxy) via an IP direct to a
trusted 3rd party partner hosted system connected via a private gateway.
But off-net to a cloud service via an Internet firewall (steered via
private backdoor routes).

I did a project where I ended up putting in hundreds of external DNS
entries into an internal self-rooted DNS, together with hundreds of
firewall rules, and a proxy.pac file as long as your arm for proxy
bypass (which is then promptly mis-interpreted or ignored by every
different version of browser ever written)

And those entries had to be kept in synch every time the external info
changes. And tested for every browser release.

There lies operational madness.

-- 
Regards,
RayH

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 5 Aug 2013 14:39:08 -0700 (PDT)

----- Original Message -----
> From: Fred Baker (fred) <[email-masked]>
> To: "[email-masked]" <[email-masked]>; Lorenzo Colitti <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Tuesday, 6 August 2013 2:37 AM
> Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
> 
> In IPv4 networks, it is pretty common to in some way advertise the address of an 
> internal-only server and then block access to it at the firewall. If you want 
> Cisco examples, try wwwin.cisco.com or irp-view13.cisco.com - dig them, ping 
> them, and traceroute towards them. From my perspective, in IPv4 or in IPv6, the 
> firewall rule makes little sense except as an additional defensive layer; one 
> should not advertise the name to the great unwashed, and whether or not one 
> does, one should give the system an address that is not advertised to the great 
> unwashed. The next question, of course, is how to achieve that - does one only 
> advertise half of their address space? Announce multiple prefixes? The ULA, 
> whatever its other ills or uses may be, is an address that is not advertised 
> upstream, and therefore a very logical address for an internal-only system in an 
> IPv6 network.
> 

Makes sense to me. I think ULAs would be better than globals with ACLs blocking access for these sorts of sites because ULAs aren't globally reachable, and even if they're accidentally leaked, their external reachability should be very limited. If the default unreachability of ULAs isn't good enough, ACLs blocking the fc00::/7 on the edge of the network would be further protection.

The nature of globals is that they're intended to provide global reachability by default. ULAs are not intended to provide global reachability, and even if leaked, probably won't provide global reachability reliably, which will also discourage their use for "global purposes". So if you don't want global reachability, it would seem to me that ULA is the better address space to use.

> I scratch my head a bit on the vehemence that seems to come across in 

> discussions of the ULA. I understand that there is a strong distaste for NATs, 
> and I share it in the stateful case. It sounds a bit like the baby is being 
> discarded with the bathwater, though, in the case of a system that one 
> doesn't want to have communicating with the great wide world.
> 

I don't really understand it either. The value I see in ULAs is that it is your own local address space, meaning that you're in complete charge of it, unlike the global address space you have been given by somebody else. It seems to me that one way to increase robustness is to reduce external dependencies. Using a local address space, that is used in preference to a global address space when there is a choice, in general should be more robust because you have absolute control over it.

>>  I've read (and commented) this draft some time ago. This document is 
> useful and I think it should move forward.
>> 
> simply ignore the potential use of such addresses, e.g., because our experience 
> of providing IPv6 VPN service to our corporate customers since 2009 has shown 
> that some of these customers ask for (and sometimes demand) a ULA-based 
> addressing plan, mostly because these customers still think that private 
> addressing provides some form of security. 
>> 
>>  This is partly an educational matter which we usually address by organizing 
> training sessions within the enterprise, but the reality is that we could never 
> avoid the discussion about ULA usage with these customers. And there are indeed 
> a few of them who have chosen to go for an ULA addressing plan, at least for the 
> duration of field trials or even pilot deployments.
>> 
> also expect the draft to clearly discourage the use of such addresses, for the 
> reasons mentioned by Lorenzo in his recent message. 
>> 
>>  For the sake of readability, I would (1) remove the ULA-related text from 
> Sections 2.4.2, 3.1 and 6.3, and (2) dedicate a specific "On ULA Addressing 
> and Its Foreseen Implications" subsection in Section 2.6, which would 
> better elaborate on the warnings highlighted in the aforementioned sections 
> (e.g., Section 3.1's "use of PI space obviates the need for 
> ULAs").
>> 
>>  A few additional typos:
>> 
> http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6.  Please 
> read it now. If you find nits (spelling errors, minor suggested wording changes, 
> etc), comment to the authors; if you find greater issues, such as disagreeing 
> with a statement or finding additional issues that need to be addressed, please 
> post your comments to the list.
>> 
>>  We are looking specifically for comments on the importance of the document 
> as well as its content. If you have read the document and believe it to be of 
> operational utility, that is also an important comment to make.
>>  pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
>>  a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 5 Aug 2013 14:49:15 -0700 (PDT)

----- Original Message -----
> From: Mark ZZZ Smith <[email-masked]>
> To: Fred Baker (fred) <[email-masked]>; "[email-masked]" <[email-masked]>; Lorenzo Colitti <[email-masked]>
> Sent: Tuesday, 6 August 2013 7:39 AM
>>  To: "[email-masked]" 
> <[email-masked]>; Lorenzo Colitti 
> <[email-masked]>
<snip>
>>  
> 
> I don't really understand it either. The value I see in ULAs is that it is 
> your own local address space, meaning that you're in complete charge of it, 
> unlike the global address space you have been given by somebody else. It seems 
> to me that one way to increase robustness is to reduce external dependencies. 
> Using a local address space, that is used in preference to a global address 
> space when there is a choice, in general should be more robust because you have 
> absolute control over it.
> 

Just to clarify though, I'm not for NAT in any form. I think NPT is a lot better, however I still think that because it hides the external identity of hosts from themselves that it creates constraints that are better to avoid. Through experience, I've come to the view point that global uniqueness of identity (through globally unique addresses) is a property that is nearly as important as global reachability for troubleshooting and security.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Aug 2013 07:15:05 +0900

On Tue, Aug 6, 2013 at 1:37 AM, Fred Baker (fred) <[email-masked]> wrote:

> discussions of the ULA. I understand that there is a strong distaste for
> NATs, and I share it in the stateful case.

NAT creates problems for applications not only in the stateful case, but in
the stateless case as well, because with NAT the client must be prepared
for a situation where it does not know its own address. This complicates
peer-to-peer networking applications such as video chat.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 5 Aug 2013 23:27:07 +0000

On Aug 5, 2013, at 3:15 PM, Lorenzo Colitti <[email-masked]> wrote:

> I scratch my head a bit on the vehemence that seems to come across in discussions of the ULA. I understand that there is a strong distaste for NATs, and I share it in the stateful case.
> 
> NAT creates problems for applications not only in the stateful case, but in the stateless case as well, because with NAT the client must be prepared for a situation where it does not know its own address. This complicates peer-to-peer networking applications such as video chat.

I'm not going to argue one way or the other. The substance of my comment related to an address that was not intended to be globally reachable. our thought there?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Aug 2013 12:20:31 +1200

On 06/08/2013 09:49, Mark ZZZ Smith wrote:
...
> Just to clarify though, I'm not for NAT in any form. I think NPT is a lot better, however I still think that because it hides the external identity of hosts from themselves that it creates constrai…

It seems to me that any IETF consensus document should make it clear
that ULAs are for internal use only, that GUAs should be used in parallel
for external access, and that NPTv6 is (if mentioned) only an experimental
specification.

Also note that draft-liu-v6ops-ula-usage-analysis and
draft-liu-v6ops-running-multiple-prefixes are around and cover
this topic.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Aug 2013 11:02:50 +0900

On Tue, Aug 6, 2013 at 8:27 AM, Fred Baker (fred) <[email-masked]> wrote:

> > NAT creates problems for applications not only in the stateful case, but
> in the stateless case as well, because with NAT the client must be prepared
> I'm not going to argue one way or the other. The substance of my comment
> related to an address that was not intended to be globally reachable. our
> thought there?

But if it's not indended to be globally reachable... then why is it behind
a NPTv6 box? I'd argue is that it *does* need to be globally reachable, but
"only for certain traffic". For example, "TCP/443 replies from the Windows
Update server".

The point is that when people say, "X will never do Y" sometimes it turns
out that "never" just means "in the next six months", and what ends up
happening is that they need to deal with additional complexity once Y
becomes a requirement.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Aug 2013 11:04:48 +0900

> for external access, and that NPTv6 is (if mentioned) only an experimental

Yes, yes, and yes.

> draft-liu-v6ops-running-multiple-prefixes are around and cover

Which is why that debate does not belong in this draft and the authors
would be wise to remove this text so this draft can advance while we
discuss those documents.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 6 Aug 2013 02:24:42 +0000

On Aug 5, 2013, at 7:02 PM, Lorenzo Colitti <[email-masked]>
 wrote:
> But if it's not indended to be globally reachable... then why is it behind a NPTv6 box? I'd argue is that it *does* need to be globally reachable, but "only for certain traffic". For example, "TCP/443 replies from the Windows Update server".

Where in *my* comment did I mention a NPTv6 box?

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 05 Aug 2013 22:33:48 -0400

Lorenzo,

For clarity, if the text remaining mentioned ULAs, but text removed
connecting it to NPT or NAT, would that meet your objections?  We then point
to drafts (draft-liu-v6ops-running-multiple-prefixes) and
(draft-liu-v6ops-running-multiple-prefixes) for use cases and further
considerations.  Of course, due warning on ULAs seems to be also warranted
(based on comments).

Regards,

Victor K

From:  Lorenzo Colitti <[email-masked]>
Date:  Tue, 6 Aug 2013 11:04:48 +0900
To:  Brian E Carpenter <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

Yes, yes, and yes.
 
> draft-liu-v6ops-running-multiple-prefixes are around and cover

Which is why that debate does not belong in this draft and the authors would
be wise to remove this text so this draft can advance while we discuss those
documents.
_______________________________________________ v6ops mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Aug 2013 11:36:27 +0900

On Tue, Aug 6, 2013 at 11:24 AM, Fred Baker (fred) <[email-masked]> wrote:

>  wrote:
> > But if it's not indended to be globally reachable... then why is it
> behind a NPTv6 box? I'd argue is that it *does* need to be globally
> reachable, but "only for certain traffic". For example, "TCP/443 replies
> from the Windows Update server".
>

Er... you you said "distaste for NATs", and talked about "the stateful
case". I assumed you meant stateful NAT66, which the IETF has not
standardized. I then noted that stateless NAT (by which I meant NPTv6) also
creates problems because the application does not know its own address.
Does that clarify? Did I misunderstand you?

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Aug 2013 11:44:31 +0900

On Tue, Aug 6, 2013 at 11:33 AM, Victor Kuarsingh <[email-masked]> wrote:

> connecting it to NPT or NAT, would that meet your objections?
>

If this draft describes the use of ULAs only in conjunction with global
addresses, and states that they cannot be used by themselves, noting that
this is different from IPv4, where a host can have only private addresses
and function properly, then that's likely to be non-controversial, because
it just repeating what's written in RFC 4193. Mentioning a use case where a
host only has ULAs, or suggesting the use of ULA+NPTv6, is likely going to
be controversial.

 We then point to drafts (draft-liu-v6ops-running-multiple-prefixes)
and (draft-liu-v6ops-running-multiple-prefixes)

I take it you mean "draft-liu-v6ops-running-multiple-prefixes" and
"draft-ietf-v6ops-ula-usage-recommendations"?

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 05 Aug 2013 22:53:27 -0400

Lorenzo

(in-line)

>If this draft describes the use of ULAs only in conjunction with global
addresses, and states that they cannot be used by themselves, noting >that this
is different from IPv4, where a host can have only private addresses and
function properly, then that's likely to be non->controversial, because it just
repeating what's written in RFC 4193. Mentioning a use case where a host only
has ULAs, or suggesting the >use of ULA+NPTv6, is likely going to be
controversial.

What about the use case of a host that has no global connectivity
requirements? I know of cases in the SP world where this is true, although
this draft is for Enterprise, but they may have similar cases (I.e. Closed
network environments, testing beds, etc).

Yes, my bad.  My cut/paste skills are poor this evening.

Regards,

Victor K

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Aug 2013 12:41:00 +0900

> network environments, testing beds, etc).

This case is neither as simple nor as clear-cut as it sounds.

If a host truly has no global connectivity requirements then it doesn't
matter what IP addresses it uses as long as they are globally unique. (They
still need to be globally unique because even though the host doesn't talk
to the outside world, it will talk to something that [talks to something
that...] talks to the outside world).

In that case, then that host can use any address that's globally unique,
including global unicast or ULA. Global addresses have the advantage that
they are unambiguously globally unique, whereas ULA addresses are only
probabilistically unique. This means that if you have enough ULA to cause a
collision then you will have problems, and if someone misconfigures their
machines with the ULA prefix that you picked, then you're sort of SOL. On
the other hand, ULA has an advantage over PI addresses because the latter
may need to be renumbered if you change ISPs.

There's also the point that when people say "will never talk to the outside
world", that's more often than not an oversimplification. :-)

Since these points are pretty subtle, they should be carefully worded. I
think the right place for that is in the ULA usage document. Why not simply
punt to that document?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Aug 2013 16:49:17 +1200

On a different topic, section 5 covers IPv6-only issues.
I'm a bit concerned that this might need a health warning:
deploying NAT64/DNS64 might cause pain and suffering.
Perhaps after this text:

>    Together, RFCs
>    6146 and RFC 6147 provide a viable method for an IPv6-only client to
>    initiate communications to an IPv4-only server.

we should add something like:

   At enterprise level, operating NAT64 and DNS64 services for
   heavy usage may have significant practical implications.

Also, the last paragraph of section 5:

>    It is worth noting that for IPv6-only access networks that use
>    technologies such as NAT64, the more content providers (and
>    enterprises) that make their content available over IPv6, the less
>    the requirement to apply NAT64 to traffic leaving the access network.

A reference to RFC 6883 would fit nicely there.

Regards
   Brian

---

From: Martin Millnert <[email-masked]>
Date: Tue, 6 Aug 2013 08:05:03 +0200

On 6 aug 2013, at 05:41, Lorenzo Colitti <[email-masked]> wrote:

> In that case, then that host can use any address that's globally unique, including global unicast or ULA. Global addresses have the advantage that they are unambiguously globally unique, whereas ULA addresses are only probabilistically unique. This means that if you have enough ULA to cause a collision then you will have problems, and if someone misconfigures their machines with the ULA prefix that you picked, then you're sort of SOL. On the other hand, ULA has an advantage over PI addresses because the latter may need to be renumbered if you change ISPs.
> 
> There's also the point that when people say "will never talk to the outside world", that's more often than not an oversimplification. :-)
> 
> Since these points are pretty subtle, they should be carefully worded. I think the right place for that is in the ULA usage document. Why not simply punt to that document?

Enterprises WILL configure addresses without using RIR-coordinated GUA, so just a summary of ULA and instead references to other RFCs, such as 4193 and mentioned drafts, is in order in this document IMO. 

/M

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 7 Aug 2013 13:07:46 +0000

In short, the debate is not so much about ULA per se (we all know that there are obvious cases - even if rare - where ULA is the obvious choice) but about NPTv6 ;-O What a surprise...

I dislike NAT (especially the n:1 stateful one) even more when it is assumed to add security (cough cough).

But, during my day job I talk to enterprise customers (from small SMB with 3 people - friends and acquaintance - to 1000 people) and to be honest ULA (and I am ashamed to add NPT6 to the mix) is really what they want and I can understand why:

-       Having the internal network up when DHCP-PD is failing because WAN link is down (at least they keep ULA and loose only their GUA), this should be mentioned in our I-D

-       Having a simple and cheap way to do multi-homing, search about multi-homing, load-balancing, ... for SMB and those boxes uses RFC 1918 inside + NAT towards two ISP or two links (xDSL & 4G)... Not all SMB will get a PI space and will run BGP.

In short, I am probably the only co-author, that do not want to hide the topic under the carpet of another I-D. We could mention the above points (and others) without taking decisions but referring to the ULA use case I-D. But, we should mention that there are use case where ULA _APPEARS_ as appealing.

-éric (and YES I dislike NAPT for breaking apps, and making security worse)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: mardi 6 août 2013 04:03
To: Fred Baker (fred)
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

The point is that when people say, "X will never do Y" sometimes it turns out that "never" just means "in the next six months", and what ends up happening is that they need to deal with additional complexity once Y becomes a requirement.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Aug 2013 23:19:30 +0900

On Wed, Aug 7, 2013 at 10:07 PM, Eric Vyncke (evyncke) <[email-masked]>wrote:

>  -       **Having the internal network up when DHCP-PD is failing because
> WAN link is down (at least they keep ULA and loose only their GUA), this
> should be mentioned in our I-D
>

I think we all agree that ULA + GUA is an accepted use case that should go
into this document as well. Are you saying that ULA-only should to into
this document as well? I don't think there is consensus on that.

-       **Having a simple and cheap way to do multi-homing, search about
> multi-homing, load-balancing, ... for SMB and those boxes uses RFC 1918
> inside + NAT towards two ISP or two links (xDSL & 4G)... Not all SMB will
> get a PI space and will run BGP.
>

That's why we're working on source+destination based routing, which is a
much better solution than anything involving translation. and since this is
an IETF document, I think it should document src+dst routing (which is
gaining consensus and has a lot of work going on around it in various
working groups) over ULA-only, whose only reason for existence is "it's
similar to what we do in IPv4, which we all hate".

> -éric (and YES I dislike NAPT for breaking apps, and making security worse)

NPTv6 breaks apps too. For example, it will break anything using libjingle
(e.g., Google video chat).

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 7 Aug 2013 14:24:27 +0000

Lorenzo

You have a very valid point about documenting the source-destination routing on the same 'foot' as NPT6.

And of course, we are in agreement on NPT6 breaking applications (probably less though than NAPT)

-éric

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: mercredi 7 août 2013 16:20
To: Eric Vyncke (evyncke)
Cc: Fred Baker (fred); [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

On Wed, Aug 7, 2013 at 10:07 PM, Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>> wrote:
-       Having the internal network up when DHCP-PD is failing because WAN link is down (at least they keep ULA and loose only their GUA), this should be mentioned in our I-D

I think we all agree that ULA + GUA is an accepted use case that should go into this document as well. Are you saying that ULA-only should to into this document as well? I don't think there is consensus on that.

That's why we're working on source+destination based routing, which is a much better solution than anything involving translation. and since this is an IETF document, I think it should document src+dst routing (which is gaining consensus and has a lot of work going on around it in various working groups) over ULA-only, whose only reason for existence is "it's similar to what we do in IPv4, which we all hate".

NPTv6 breaks apps too. For example, it will break anything using libjingle (e.g., Google video chat).

---

From: "cb.list6" <[email-masked]>
Date: Wed, 7 Aug 2013 21:08:28 -0700

>    heavy usage may have significant practical implications.

Can you be more specific? Pratical data?

CB

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Aug 2013 16:24:09 +1200

> Can you be more specific? Pratical data?

Not really, because I've never operated one in real life. It doesn't
strike me as the sort of service that most enterprise network
managers will be familiar with, and a v6-only site needing a normal
level of access to v4-land would end up sending most of its external
traffic via NAT64 and most of its external DNS queries via DNS64.
Therefore, these would become an important single point of failure
and a potential bottleneck. The text doesn't seem to point this out.

   Brian

---

From: joel jaeggli <[email-masked]>
Date: Thu, 08 Aug 2013 00:21:37 -0700

> and a potential bottleneck. The text doesn't seem to point this out.
imho the tools you employ to scale this are about the same as those
employed for for nat44 or service load balancing.

e.g. stateless hashing, horizontal tiers of translators, no state
replication, multiple clusters for different regions/pops/offices etc.

the solutions in the marketplace more or less follow along those lines.

There are implications for both fragmentation and pmtud for some of
those cases that have to be managed, but I don't expect that comes as a
surprise.

---

From: "cb.list6" <[email-masked]>
Date: Thu, 8 Aug 2013 05:45:32 -0700

On Aug 7, 2013 9:24 PM, "Brian E Carpenter" <[email-masked]>
wrote:
> > On Aug 5, 2013 9:49 PM, "Brian E Carpenter" <[email-masked]
>
> > wrote:

Agree with Joel, nat64 will be parity with common nat44 and firewalls in
terms of availability

Regarding majority of traffic, i believe the scales have tipped to show v6
is the majority for campus networks, which is the best proxy in the
available data

http://www.worldipv6launch.org/measurements/

These numbers also skew low since Apple has a non-deterministic happy
eyeballs

Given that enterprises and all users of IP are out of ipv4, so they need to
not use ipv4 yet have access to it, guidance against nat64 will frustrate
the issue.

Guidance should be given to make as many flow v6 e2e. Full stop.

CB

---

From: Erik Nygren <[email-masked]>
Date: Thu, 8 Aug 2013 09:37:20 -0400

It's also likely the case that at least some enterprises control portions
of
their environments well enough that mostly-IPv6 could potentially be much
more viable than a residential environment.  For example, a retail store
chain using
HTTP-based POS terminals and kiosks may have enough control over their
environment
that they could ideally deploy an IPv6-only environment and just use
NAT64/DNS64
to get to some of their supplier websites that still require IPv4.
It might also be attractive to some US Government agencies who control
the devices and clients within their network to use this approach as part
of meeting the OMB September 2014 mandate for IPv6 client support.
That could be simpler for those agencies than rolling out a dual-stack
environment.
(I'm very curious if either of these cases exists in production in the
field today...)

      Erik

On Thu, Aug 8, 2013 at 8:45 AM, cb.list6 <[email-masked]> wrote:

> Given that enterprises and all users of IP are out of ipv4, so they need
> to not use ipv4 yet have access to it, guidance against nat64 will
> frustrate the issue.
>

---

From: Ray Hunter <[email-masked]>
Date: Thu, 08 Aug 2013 18:31:33 +0200

Erik Nygren wrote:
> It's also likely the case that at least some enterprises control
> portions of
> more viable than a residential environment.  For example, a retail
> store chain using

Why would anyone in their right mind chose to deploy NAT64/DNS64 in a
commercial environment given the prices I've seen for that functionality?

I can't imagine them wanting something like that in operations either.

It's likely to be much cheaper to let legacy applications die off
naturally, run dual stack or even dual servers for some systems, and
deploy a combination of simple forward and reverse web proxies for the
rest (assuming web based apps).

AFAIK There's still stuff happily running Bisync (BSC) out there (over
IP tunnels) and support for that was deprecated in the 1970's in favour
of SNA. So I wouldn't hold your breathe waiting for 100% migration to
IPv6. It's going to be pretty easy to maintain a private IPv4 - IPv4
network over a GRE tunnel over an IPv6 Internet for a very long time yet.

>
> On Thu, Aug 8, 2013 at 8:45 AM, cb.list6 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     On Aug 7, 2013 9:24 PM, "Brian E Carpenter"
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>     >
>     > > On Aug 5, 2013 9:49 PM, "Brian E Carpenter"
>     <[email-masked] <mailto:[email-masked]>>
>     > > wrote:
>     Agree with Joel, nat64 will be parity with common nat44 and
>     firewalls in terms of availability
>
>     Regarding majority of traffic, i believe the scales have tipped to
>     show v6 is the majority for campus networks, which is the best
>     proxy in the available data
>
>     These numbers also skew low since Apple has a non-deterministic
>     happy eyeballs
>
>     Given that enterprises and all users of IP are out of ipv4, so
>     they need to not use ipv4 yet have access to it, guidance against
>     nat64 will frustrate the issue.
>
>     > >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
Regards,
RayH

---

From: "cb.list6" <[email-masked]>
Date: Thu, 8 Aug 2013 10:00:35 -0700

> commercial environment given the prices I've seen for that functionality?

If your situation is that you need a middlebox as part of an IPv4
exhaustion remediation, NAT44 and NAT64 are largely the same costs in
my experience.  YMMV.  For the particularly cost conscious and FOSS
friendly, there are FOSS options for both.

NAT64 is in-fact cheaper since only non-IPv6 flows need translation as
where NAT44 requires translation of all flows.

CB

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Aug 2013 19:05:33 +0200

Hi,

> commercial environment given the prices I've seen for that functionality?

To get rid of dual-stack operations, while still being able to benefit
from the large address space of IPv6 inside the enterprise?

Dual-stack is a major cost factor.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

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: Ray Hunter <[email-masked]>
Date: Thu, 08 Aug 2013 19:28:17 +0200

> Gert Doering <mailto:[email-masked]>
> 8 August 2013 19:05
> Hi,
>
Who has an IPv4 address shortage *inside* the enterprise?
And what are these benefits *inside* the enterprise?
LAN switches are written off over at least 10 years in the book keeping.

AFAICS the only thing most large enterprises are worried about right now
is the border, and Internet and outward facing systems (and rightly so).
They'll be able to run *private* IPv4 networks over MPLS or GRE or
something else for many many years to come, with all of their important
partners, and there'll be plenty of vendors wiling to support them on
old kit at cut prices.

If SNA or DECnet IV is any transition model to go by, it took about 20
years for them to die inside most enterprises, whilst they generally
died much quicker at the border. It went something like: native SNA or
native routed DECnet IV on original vendor equipment -> multi-protocol
routers -> tunnelled SNA or DECnet IV -> islands with gateways ->
islands -> switch off.

The final straw was making end users pay pro-rata for the support costs
of the shrinking infra. IMVHO Whilst there's still economies of scale,
there's simply no business case *inside* the enterprise except for
opportunistic switch on at standard scheduled lifecycle renewal. I've
been through this loop myself. But then again, why should the IETF care
what happens in that case if the border interface is clean and IPv6 only?
> Ray Hunter <mailto:[email-masked]>
> 8 August 2013 18:31
> Erik Nygren wrote:
> ------------------------------------------------------------------------

-- 
Regards,
RayH

---

From: Tore Anderson <[email-masked]>
Date: Thu, 08 Aug 2013 19:45:25 +0200

* Ray Hunter

> Who has an IPv4 address shortage *inside* the enterprise?

I do, as do many other. FWIW, these days all sorts of enterprises in the
RIPE region become LIRs just to get their hands on a measly /22 for
their own use.

> And what are these benefits *inside* the enterprise?

I'd love to be able to shut off IPv4 completely, as dual stack means
~dual complexity and ~dual operational overhead.

> LAN switches are written off over at least 10 years in the book keeping.

What does that have to with IPv4 shortage?

Tore

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Aug 2013 19:47:01 +0200

Hi,

> And what are these benefits *inside* the enterprise?

Well, I see lots of (even small) enterprises that have *collisions* on
IPv4 all over the place - mergers, VPNs to partners, etc. - and of course
workarounds are found, like "double NAT on VPN links", leading to extra
costs that people take for granted.

Add to that the usual problem of "how big do I size my subnet", which
is also needless annoyance from the past.

I don't think running IPv6-only inside an enterprise can be done today
(legacy applications being the largest obstacle, plus inertia on the
side of enterprise network admins), but I do see quite some benefit
in having IPv6 - and if I have that, I want to get rid of IPv4 as fast
as possible.

> LAN switches are written off over at least 10 years in the book keeping.

We started using IPv6 in 1997.  Your point being?

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Thu, 8 Aug 2013 10:54:53 -0700

> LAN switches are written off over at least 10 years in the book keeping.

Arguably, anyone using RFC-1918 space is suffering from an address
shortage inside their enterprise. Given the clear and obvious benefits
of eliminating NAT and having globally unique addresses for every
system which communicates with the internet, I wonder how you can
ask such a question with a straight face.

A 10 year depreciation on switches is absurd. Most enterprises I know of
use either a 3-year or 5-year depreciation schedule for network equipment
such as LAN switches and many end up retiring them faster than they
depreciate.

> partners, and there'll be plenty of vendors wiling to support them on

I think you are right about what most enterprises are worried about right
now (if they are even paying attention at all). However, enterprises are
not exactly known for paying attention to anything more than 3 months
away from now, so I don't think that's a great yardstick.

It will be interesting to see how this plays out. I think that the cost of
continuing to support IPv4 in the face of an ever-increasing proportion
of the internet not being IPv4 capable will lead enterprises to abandon
IPv4 for the most part much faster than is currently anticipated.

We saw this with the IPX->IP transition. Everyone thought we'd be
running IPX everywhere for 20-30 years, yet once IP gained critical
mass in the enterprise, IPX all but disappeared in less than 5 years.

> routers -> tunnelled SNA or DECnet IV -> islands with gateways ->

I think IPv4 will get to the islands with gateways much faster than DECNET
or SNA. I think that the IPX (and/or Appletalk) transition(s) to IP are a much
more informative model.

SNA, especially, was a very different networking model from IP and IBM
(as well as HDS and other IBM clones) were very very slow to support
TCP/IP other than through gateways. They still depended on SNA for
the vast majority of their peripherals, terminals, etc. It wasn't until most
3270/5250 terminals were replaced by PCs that the real move away
from SNA started in earnest. At that point, SNA mostly disappeared fairly
quickly. Much less than 20 years.

IPX and Appletalk, OTOH, provided very similar overall services on a very
similar conceptual model to IP. As a result, that transition was quite a bit
easier and the enterprise migration consequently happened quite rapidly.

I'm sure you can still point to islands of IPX or Appletalk running here and
there in a few enterprises, but what was once the flagship product of a
major player in the industry (IPX / Novelle) is now basically relegated
to history and the company is an also-ran at best.

> what happens in that case if the border interface is clean and IPv6 only?

The IETF probably shouldn't really care. However, this is  an informational
RFC intended to help enterprises get from A to B in an orderly manner. As
such, I think it is appropriate to document that process.

Further, I think you will see the escalating cost of IPv4 at the eyeball ISP as
the first driving factor for deprecating IPv4 and I think that will happen quite
a bit faster than most people expect.

As a general rule, once CGN starts to be widely deployed and ISPs start
having to charge extra to cover the escalating costs of CGN (especially
WRT the CALEA implications), you'll see consumers choosing IPv6 only
over paying extra for even more degraded IPv4 service.

Owen

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 8 Aug 2013 19:02:08 +0000

On Aug 8, 2013, at 9:31 AM, Ray Hunter <[email-masked]> wrote:

> Why would anyone in their right mind chose to deploy NAT64/DNS64 in a commercial environment given the prices I've seen for that functionality?

The place I generally see it called out is between an IPv6-only (portion of a) network and an IPv4-only (portion of a) network. This may be interesting reading - and in a few weeks I'll be seeking opinions on it.

http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience
  "NAT64 Operational Experiences", Gang Chen, Zhen Cao, Chongfeng Xie,
  David Binet, 2013-07-08

---

From: Ray Hunter <[email-masked]>
Date: Thu, 08 Aug 2013 22:40:47 +0200

> Owen DeLong <mailto:[email-masked]>
> 8 August 2013 19:54
But that pain has been solved 5 years ago in most places I work. There's
no burning platform.

How would introducing a new technology like NAT64/DNS64 make things
better in places where it hasn't been solved?
[the original point of the thread] it's yet another NAT box.
> over paying extra for even more degraded IPv4 service.
Actually I think your reasoning and reference to the IPX and Appletalk
phase out would suggest it's easier to make a bold call: move to IPv6
ASAP for critical systems via dual stack, and for the rest you draw a
box around it and call it legacy and run it on IPv4 until it dies a
natural death.

IMHO Going half way with NAT64/DNS64 just prolongs the pain and locks
you into a transition technology that is expensive and difficult to
operate for the life cycle of that box, and which has to remain in place
until the last app is migrated or switched off.

I've been in a fair number projects where you sometimes just have to
dare to cut the cord whilst maintaining a process to find out what has
broken. So one valid IPv6 only migration strategy might be: "If it's
important, they'll migrate before a flag day date. Otherwise they get
cut off."

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Aug 2013 09:00:48 +1200

>   "NAT64 Operational Experiences", Gang Chen, Zhen Cao, Chongfeng Xie,

And what I find lacking in the enterprise-incremental-ipv6 draft
is a sentence or two pointing out that there are practical issues
and tradeoffs - the current text is a rather abstract explanation
of the scenarios and standards, which is not generally enough for
a enterprise network manager. This discussion has shown that it isn't
a clear-cut matter, so some sort of practical guidance is needed.

    Brian

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Aug 2013 23:13:46 +0200

Hi,

> until the last app is migrated or switched off.

Maybe you are using the term NAT64/DNS64 in a different way than Cameron
and I do that.  When I speak about NAT64, it means "go to IPv6-only on
the inside, and only use NAT64 to talk to those outside hosts that have
no IPv6".

NAT64 is not a transition technology for your network, it's a transition
technology for "talking to legacy peers".

Gert Doering
        -- NetMaster

---

From: Tom Perrine <[email-masked]>
Date: Thu, 08 Aug 2013 14:43:32 -0700

On 8/8/13 1:40 PM, Ray Hunter wrote:
<<<<<<<<SNIP>>>>>>>>>>
> important, they'll migrate before a flag day date. Otherwise they get

I cannot agree enough with the "prolongs the pain" observation.

I'm planning to have no transition technologies in our internal (corporate) network. "Dual-stack or death!"

If something can't be dual-stacked, it goes into the legacy pit of doom and dies a slow painful death.

Consumer-facing is different, but I'm still expecting no transition technologies to be needed.

This is rather cold-blooded and (I freely admit) a bit of a pipe dream. But if I can make this work, I'll never have to
justify, pay for, create, debug, support, and then decommission any of the transition technologies.

---

From: "Arie Vayner (avayner)" <[email-masked]>
Date: Fri, 9 Aug 2013 05:21:10 +0000

Another loosely related point that I think could make sense in such a document would be the ways to accomplish multi-homing and how it is different than today's IPv4 implementations.

Many enterprises rely on NAT on the Internet edge as their multi-homing/traffic engineering mechanism with IPv4.

If we recommend against ULA+NPTv6 (or just NPTv6 for traffic engineering), then we need to highlight the symmetry requirement due to stateful security layers.
Traffic leaving from an Internet gateway site to the Internet has to come back through the same site, or the stateful firewalls would break the flow (well, has to hit the same stateful security layer)

Syncing upstream and downstream routing policies is not always an easy task (but could be relevant in some cases).
Linking the Internet gateway layer across sites (before hitting the stateful security layer) could be another solution.

Do you think a short discussion to raise awareness for this potential issue could be relevant in such a document?

Arie

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Vyncke (evyncke)
Sent: Wednesday, August 7, 2013 6:08 AM
To: Lorenzo Colitti; Fred Baker (fred)
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: mardi 6 août 2013 04:03
To: Fred Baker (fred)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

---

From: Ray Hunter <[email-masked]>
Date: Fri, 09 Aug 2013 08:59:36 +0200

> 8 August 2013 23:13
Right. But I still don't see a scenario for a hosting location of
"legacy peers" where large scale NAT64/DNS64 makes sense compared to any
number of alternatives that are already well-known within the enterprise
space.

If the legacy apps are located within the enterprise relative to their
users, there's really no visible cost to running dual stack today or in
the foreseeable future.

Show me an enterprise carrier or managed service provider or router
vendor who charges more for their MPLS solution or managed service or
device for IPv4 support. I can show you plenty where IPv6 is a "premium
service." Until IPv4 becomes a "premium service" there's simply no
business case.
That transition has happened on the public Internet: public IPv4 is
starting to cost more on the public Internet, and it's visible to consumers.

If the legacy apps are located on the Internet, there are already any
number of border solutions in place: proxies, gateways, VPN's, and
stepping stones that can be adapted to perform the translation at a
higher layer, or to tunnel the IPv4 traffic over IPv6, without resorting
to DNS64/NAT64. Bearing in mind that most enterprises anyway run split
DNS, and resolving Internet addresses by end hosts located within the
border is the exception rather than the norm (although that is changing),

If the legacy apps are located on trusted 3rd party sites, or hosted
provider sites (private-cloud) then IPv4 issues can be solved
commercially to ensure native IPv4 support is available for a fixed
support period, or by introducing IPv4 over IPv6 tunnels or private links.

I agree entirely that the border needs to adapt, and quickly, because
that's where the business risks are.
I also get why ISP's like DNS64/NAT64 in an "eyeballs network."

As to the point of going pure IPv6 only on the inside: that also
introduces a new merger and acquisition risk. If your take over target
has gone pure IPv6 only, and you are still running dual stack, or vice
versa, that's IMHO tougher to transition than if you are both still
running dual stack. I wouldn't want to be the guy who had to go to my
boss and say "we need to turn IPv4 back on and it's going to cost us X"
after having spent a fortune on going IPv6 only.

Specifically looking at the draft text.

"the long term enterprise network roadmap should include
   steps on gradually deprecating IPv4 from the dual-stack network"

Why gradually? As Owen points out, IPX and appletalk phase out was
disruptive and fast.

Depending on the enterprise's strategic plan, a flag day approach to
turning off IPv4 is equally valid IMHO.
Never mind the technical aspects, a cut off date concentrates people's
minds.

Equally, given the history of the SNA, DECnet phase out, a strategy of
declaring certain systems "legacy" and running them as-is using native
protocols on the long-term until they reach a natural end of life would
also seem a valid strategy . A network might never reach pure IPv6 only,
and that IMHO would not be a problem.

"However, in
   the current environment, given that IPv4 is the dominant protocol on
   the Internet, an IPv6-only node most likely needs to talk to an
   IPv4-only node on the Internet."

I question this statement. There are plenty of enterprises that do not
allow any direct IP level session from an end node within the enterprise
to a server located on the public Internet. The adaptation can then take
place in a border system e.g. proxy or ALG, and both end-user devices
see their own native protocols.

"It is therefore important to provide
   such nodes with a translation mechanism to ensure communication
   between nodes configured with different address families."

Why? That's just one of many options.

Proxies and ALGs are well-known practice in the enterprise, they are
already deployed and well-understood, and IMHO there's no need to
deviate from that solution just to obtain IPv6 support on the outside
interface of the border unless there are other benefits. So just adding
IPv6 to the outside interface of these services is a perfectly valid
long-term solution IMHO. That also means you have less touch-points in
your migration plan.

I also have a customer who has specifically stated "there shall be no
address family translation within the network transport service" and "we
shall transport native protocols only end-to-end between end user
systems" (tunnels are OK but they must terminate on network equipment,
not end nodes). There are no magic boxes to make the pain go away. And
they just don't want the complexity and costs in that layer.

> 8 August 2013 22:40

-- 
Regards,
RayH

---

From: Gert Doering <[email-masked]>
Date: Fri, 9 Aug 2013 09:02:44 +0200

Hi,

> service." Until IPv4 becomes a "premium service" there's simply no

Vendor costs are not the point.  The point is that operationally (OPEX),
a dual-stack network costs more than a single-stack network.

Maybe you should just try this for a while, so you know what it feels
to have to do every DNS change twice, maintain two sets of firewall
rules, etc...?

Gert Doering
        -- NetMaster

---

From: Ray Hunter <[email-masked]>
Date: Fri, 09 Aug 2013 09:45:35 +0200

> 9 August 2013 09:02
I hear you. But the OPEX seen by the key decision maker has not
increased at all (taking into account "vendor" includes managed service
provider)
> to have to do every DNS change twice, maintain two sets of firewall

At large enterprise level: someone else's problem. The outsourcing
contract has not gone up in price (yet).
And the service provider needs to improve their tooling to cope with
this as part of normal operational efficiency.

Use a complete life-cycle-cost business case to compare that operational
delta of dual stack operation (2 or 3 operational FTE) to the cost of a
green field roll out of all new kit for pure IPv6 (including converting
legacy gear that's only going to run for a pre-determined period), plus
associated transition project costs, and business downtime to get it all
running, and you'll find it's just noise.

Sorry to sound blunt, but that's pretty much current enterprise thinking
in my experience.

-- 
Regards,
RayH

---

From: Owen DeLong <[email-masked]>
Date: Fri, 9 Aug 2013 12:11:22 -0700

> [the original point of the thread] it's yet another NAT box.

The pain hasn't been solved, we've decided to live with it.

However, that aside, I'm not arguing for NAT64/DNS64. I'm saying that
eliminating NAT is obviously beneficial. NAT64 is jut another broken form
of NAT.

NAT is inherently problematic and breaks things. It causes pain.

Yes, I'm familiar with your argument of "if it doesn't work through NAT, then
I don't want it to work." I suppose that's one way to view the world, but I
would argue it's akin to insisting that your vehicle run on fossil fuels, even
if there were a viable truly cleaner sustainable alternative.

NAT is a form of toxic pollutant on the internet, whether the polluters see
that or not.

> box around it and call it legacy and run it on IPv4 until it dies a

That's certainly one approach. In my experience, that's not what happened
with most enterprises. Most enterprises ran both IPX and IP clients on their
workstations for a few years until they could kill off all the servers that were
inside those "legacy" boxes you drew.

> until the last app is migrated or switched off.

Nothing I said was intended to support or encourage NAT64. It's simply
awful. It might be a better alternative than CGN or certain other things
in SOME very limited circumstances, but NAT64 is usually just a worse
form of NAT than traditional NAT.

> important, they'll migrate before a flag day date. Otherwise they get

It might be, but it's one that most IT managers will be very uneasy about
implementing (at least in my experience).

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 9 Aug 2013 12:17:23 -0700

On Aug 8, 2013, at 22:21 , Arie Vayner (avayner) <[email-masked]> wrote:

> Another loosely related point that I think could make sense in such a document would be the ways to accomplish multi-homing and how it is different than today’s IPv4 implementations.
>  

Or stateful firewalls have to get better about sharing state. There are two things that can help with this...

1.	Put your firewalls as close to the end systems they protect as possible. Make your security zones relatively small and place the firewalls closer together at those narrower borders.
	This will often require more firewall units, but it helps in a number of ways:
	A.	Firewall policy tends to be much simpler (and as a result less error prone and more reliable)
	B.	The hardware demands on the firewall tend to be lower so you can buy cheaper units.
	C.	The simpler rulesets can be more easily tailored to meet business requirements as they evolve.

2.	Improve firewalls. Give the firewalls that all protect the same boundary a way to mesh-peer with each other and exchange information about the state tables such that triangle routing is no longer problematic.

> Linking the Internet gateway layer across sites (before hitting the stateful security layer) could be another solution.

If we make the changes above to the firewalls, this could be  a lot less relevant in most cases.

> Do you think a short discussion to raise awareness for this potential issue could be relevant in such a document?

It's certainly worth documenting. I'm not sure whether it belongs in this document or not.

Owen

---

From: "Arie Vayner (avayner)" <[email-masked]>
Date: Mon, 12 Aug 2013 05:27:42 +0000

Owen,

While the arguments about moving the firewalls closer to the users are valid they are often are not practical (or at least the customers I worked with would not implement this option).
Imagine an enterprise network with 300 spoke sites, but only 2 or 3 Internet gateway locations (with some private WAN in between).
Moving the firewalls to the spoke sites would increase the number of firewalls from ~3 to ~300 (I am ignoring redundancy and scale for a second)... This is a major CAPEX and OPEX impact...

Arie

From: Owen DeLong [mailto:[email-masked]]
Sent: Friday, August 9, 2013 12:17 PM
To: Arie Vayner (avayner)
Cc: Eric Vyncke (evyncke); Lorenzo Colitti; Fred Baker (fred); [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

On Aug 8, 2013, at 22:21 , Arie Vayner (avayner) <[email-masked]<mailto:[email-masked]>> wrote:

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 12 Aug 2013 14:34:41 +0900

On Fri, Aug 9, 2013 at 2:21 PM, Arie Vayner (avayner) <[email-masked]>wrote:

>  Many enterprises rely on NAT on the Internet edge as their
> multi-homing/traffic engineering mechanism with IPv4.
>
> ** **
>
> If we recommend against ULA+NPTv6 (or just NPTv6 for traffic engineering),
> then we need to highlight the symmetry requirement due to stateful security
> layers.****
>
> Traffic leaving from an Internet gateway site to the Internet has to come
> back through the same site, or the stateful firewalls would break the flow
> (well, has to hit the same stateful security layer)
>

By itself, NPTv6 doesn't protect against this problem because it's not
stateful. It only protects against this problem if each egress point is
only reachable using one prefix (which is not a requirement for doing NPTv6
- you could just as well do it by configuring all multiple exit points to
use the same prefix, or to use all prefixes from all exit points).

What does protect you against this is using source+destination routing,
which is what this draft should recommend instead of recommending NPTv6.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 12 Aug 2013 10:16:43 -0700

Not necessarily. You are thinking of moving them physically closer. I'm suggesting moving them topologically closer.

Imagine that the WN links are not private, but instead are public. Each site doesn't necessarily have a firewall, but it does need a VPN device (good practice anyway, since you can't trust your WAN links to be truly private[1]). These VPN gateways would have some level of mesh (ideally matching the phsyical topology relatively closely) to link the internal networks at all the sites over the WAN links. At that point, the firewalls may be physically at any or all of the internet gateway locations, but may serve different subsets of users or may be partitioned into virtual firewalls that are connected to different subsets of the internal network that travel through different VPNs, etc.

There are many ways to virtualize and abstract topology in order to enable this without necessarily increasing or moving physical hardware.

Owen

On Aug 11, 2013, at 22:27 , "Arie Vayner (avayner)" <[email-masked]> wrote:

> Moving the firewalls to the spoke sites would increase the number of firewalls from ~3 to ~300 (I am ignoring redundancy and scale for a second)… This is a major CAPEX and OPEX impact…
>  
> Arie
>

---

From: "Arie Vayner (avayner)" <[email-masked]>
Date: Mon, 12 Aug 2013 17:34:31 +0000

Actually, you can use NPTv6 to protect against it...
If I have an external pool per site, traffic egressing that site would get a source routed back only to that site... Am I missing something?

I agree there could be other ways to solve it, but this is how many enterprises solve it today with IPv4...

Arie

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Sunday, August 11, 2013 22:35 PM
To: Arie Vayner (avayner)
Cc: Eric Vyncke (evyncke); Fred Baker (fred); [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

On Fri, Aug 9, 2013 at 2:21 PM, Arie Vayner (avayner) <[email-masked]<mailto:[email-masked]>> wrote:
Many enterprises rely on NAT on the Internet edge as their multi-homing/traffic engineering mechanism with IPv4.

By itself, NPTv6 doesn't protect against this problem because it's not stateful. It only protects against this problem if each egress point is only reachable using one prefix (which is not a requirement for doing NPTv6 - you could just as well do it by configuring all multiple exit points to use the same prefix, or to use all prefixes from all exit points).

What does protect you against this is using source+destination routing, which is what this draft should recommend instead of recommending NPTv6.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Aug 2013 08:30:55 +1200

> Moving the firewalls to the spoke sites would increase the number of firewalls from ~3 to ~300 (I am ignoring redundancy and scale for a second)... This is a major CAPEX and OPEX impact...

Clearly DOS and scanning protection has to be done as close to the Internet
border routers as possible, and there your logic applies.

However, as Steve Bellovin pointed out many years ago, the best number of
firewalls for upper layer protection is one per host, which scales nicely
and has less CAPEX and OPEX than middlebox firewalls will ever have.

Not that I see any of this argument as relevant to the IP version number.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Aug 2013 12:34:17 +1000

In message <[email-masked]>, Brian E Carpenter writes:
> > While the arguments about moving the firewalls closer to the users are valid they are often are not practical (or at least the cus
> tomers I worked with would not implement this option).
> > Moving the firewalls to the spoke sites would increase the number of firewalls from ~3 to ~300 (I am ignoring redundancy and scale
>  for a second)... This is a major CAPEX and OPEX impact...
> 

IP version number brings with it a different set of minimums that
nodes / hosts have or should have if the manufacturers were paying
attention as we learnt how not to do thing in IPv4.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 13 Aug 2013 13:07:14 +0900

On Tue, Aug 13, 2013 at 2:34 AM, Arie Vayner (avayner) <[email-masked]>wrote:

>  Actually, you can use NPTv6 to protect against it… ****
>
> If I have an external pool per site, traffic egressing that site would get
> a source routed back only to that site… Am I missing something?
>
As I said, NPTv6 by itself doesn't protect against this problem.

It only protect against this problem if each egress point is only reachable
using one prefix, and all the prefixes are different. To people used to
deploying NAT44 networks, this will likely be the only deployment model
that comes to mind, and thus it will appear to them that NPTv6 does solve
this problem.

But in fact, NPTv6 was supposed to be deployed statelessly. The very first
words of RFC6296 are "This document describes a stateless [...] function
[...] preserving end-to-end reachability at the network layer.". In the
introduction, it then goes on to say it "this specification provides a
mechanism that has fewer architectural problems than merely implementing a
traditional stateful NAT". If you were to deploy it statelessly, you would
have this problem.

The interesting point here, really, is that when the IETF says "NPTv6"
people hear "NAT66", when in fact they are supposed to be different. Out of
curiosity: Fred, as the co-author of RFC 6296, were you anticipating that
people would do this? Or was the belief actually that people would
understand the difference?

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 12 Aug 2013 21:54:24 -0700 (PDT)

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: Arie Vayner (avayner) <[email-masked]>
> Sent: Tuesday, 13 August 2013 6:30 AM
>>  While the arguments about moving the firewalls closer to the users are 
> valid they are often are not practical (or at least the customers I worked with 
> would not implement this option).
>>  Imagine an enterprise network with 300 spoke sites, but only 2 or 3 
> Internet gateway locations (with some private WAN in between).
>>  Moving the firewalls to the spoke sites would increase the number of 
> firewalls from ~3 to ~300 (I am ignoring redundancy and scale for a second)... 
> This is a major CAPEX and OPEX impact...
> 

Host based firewalling by default has also pretty much been reality for most devices for the last 5+ years, if not much longer (Windows XP Service Pack 2 provided and enabled by default a host firewall in around 2004). I think the reality today is that vendors assume that if a device could be plugged directly into the Internet it probably will be, and therefore they provide and enable host based firewalls by default.

It seems common for the people who make the above argument to be the same people who are facilitating direct attachment of hosts to untrusted and uncontrolled networks by providing laptops instead of desktops, organising 3G/4G dongles for those laptops, and allowing rather than prohibiting people from taking those laptops home, to conferences, cafes and hotels. Fortunately their OS vendors have taken care of enabling host protection on their behalf.

> Not that I see any of this argument as relevant to the IP version number.

Agree.

>>  On Aug 8, 2013, at 22:21 , Arie Vayner (avayner) 
> <[email-masked]<mailto:[email-masked]>> wrote:
>> 
>> 
>>  Another loosely related point that I think could make sense in such a 
> document would be the ways to accomplish multi-homing and how it is different 
> than today's IPv4 implementations.
>> 
> layers.
>>  1.         Put your firewalls as close to the end systems they protect as 
> possible. Make your security zones relatively small and place the firewalls 
> closer together at those narrower borders.
>>              A.        Firewall policy tends to be much simpler (and as a 
> result less error prone and more reliable)
>>              C.        The simpler rulesets can be more easily tailored to 
> meet business requirements as they evolve.
>> 
>> 
>> 
>>  2.         Improve firewalls. Give the firewalls that all protect the same 
> boundary a way to mesh-peer with each other and exchange information about the 
> state tables such that triangle routing is no longer problematic.
>> 
>> 
>>  Linking the Internet gateway layer across sites (before hitting the 
> stateful security layer) could be another solution.
>>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 13 Aug 2013 14:37:03 +0000

While I agree with you about laptops & desktops, I am less sure about IoT and all IP webcam, Rasp PI and all other thermostats... but this is indeed the direction and this should be the underlying idea

OTOH, large enterprises do not want only to secure their employees' desktop, they also want to enforce a security policy... (data leakage, ...) where the end point cannot be also be trusted ;-)

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mark ZZZ Smith
> Sent: mardi 13 août 2013 06:54
> To: Brian E Carpenter; Arie Vayner (avayner)
> Cc: [email-masked]
> > valid they are often are not practical (or at least the customers I
> > worked with would not implement this option).
> > Clearly DOS and scanning protection has to be done as close to the
> > Internet border routers as possible, and there your logic applies.
> >
> > However, as Steve Bellovin pointed out many years ago, the best number
> > of firewalls for upper layer protection is one per host, which scales
> > nicely and has less CAPEX and OPEX than middlebox firewalls will ever
> have.
> >
> 
> Host based firewalling by default has also pretty much been reality for
> most devices for the last 5+ years, if not much longer (Windows XP Service
> Pack 2 provided and enabled by default a host firewall in around 2004). I
> think the reality today is that vendors assume that if a device could be
> plugged directly into the Internet it probably will be, and therefore they
> provide and enable host based firewalls by default.
> 
> It seems common for the people who make the above argument to be the same
> people who are facilitating direct attachment of hosts to untrusted and
> uncontrolled networks by providing laptops instead of desktops, organising
> 3G/4G dongles for those laptops, and allowing rather than prohibiting
> people from taking those laptops home, to conferences, cafes and hotels.
> Fortunately their OS vendors have taken care of enabling host protection
> on their behalf.
> 
> > document would be the ways to accomplish multi-homing and how it is
> > different than today's IPv4 implementations.
> >>
> > then we need to highlight the symmetry requirement due to stateful
> > security layers.
> > back through the same site, or the stateful firewalls would break the
> > flow (well, has to hit the same stateful security layer)
> >>
> >>  Or stateful firewalls have to get better about sharing state. There
> >> are two
> > things that can help with this...
> >>
> > possible. Make your security zones relatively small and place the
> > firewalls closer together at those narrower borders.
> >>              This will often require more firewall units, but it
> >> helps in a
> > number of ways:
> >>              B.        The hardware demands on the firewall tend to
> >> be lower
> > so you can buy cheaper units.
> > boundary a way to mesh-peer with each other and exchange information
> > about the state tables such that triangle routing is no longer
> problematic.
> >>
> >>
> >>  Syncing upstream and downstream routing policies is not always an
> >> easy task
> > (but could be relevant in some cases).
> >>  If we make the changes above to the firewalls, this could be  a lot
> >> less
> > relevant in most cases.
> >>
> >>
> >>  Do you think a short discussion to raise awareness for this
> >> potential issue
> > could be relevant in such a document?
> >>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 13 Aug 2013 15:20:39 +0000

Ray,

Reading you late (Summer time...)

I know several enterprises running out of RFC 1918 (WiFi, BYOD, VoIP, bad addressing plan, mergers & acquisitions)

Else, I agree with you: IPv4 will probably die on the Internet core first than in all enterprises. But, a lot of very big and very small enterprises will be IPv6-only first IMHO (reading my cheap crystal ball)

> Ray Hunter
> Sent: jeudi 8 août 2013 19:28
> To: Gert Doering
> Cc: [email-masked]
> Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-
> incremental-ipv6 WGLC]
> 
> partners, and there'll be plenty of vendors wiling to support them on old
> kit at cut prices.
> 
> years for them to die inside most enterprises, whilst they generally died
> much quicker at the border. It went something like: native SNA or native
> routed DECnet IV on original vendor equipment -> multi-protocol routers ->
> tunnelled SNA or DECnet IV -> islands with gateways -> islands -> switch
> off.
> 
> The final straw was making end users pay pro-rata for the support costs of
> the shrinking infra. IMVHO Whilst there's still economies of scale,
> opportunistic switch on at standard scheduled lifecycle renewal. I've been
> through this loop myself. But then again, why should the IETF care what
> happens in that case if the border interface is clean and IPv6 only?
> >
> >> portions of their environments well enough that mostly-IPv6 could
> >> potentially be much more viable than a residential environment.  For
> >> example, a retail store chain using HTTP-based POS terminals and
> >> kiosks may have enough control over their environment that they could
> >> ideally deploy an IPv6-only environment and just use
> >> NAT64/DNS64
> >> It might also be attractive to some US Government agencies who
> >> control the devices and clients within their network to use this
> >> approach as part of meeting the OMB September 2014 mandate for IPv6
> client support.
> >> That could be simpler for those agencies than rolling out a
> >> dual-stack environment.
> >> (I'm very curious if either of these cases exists in production in
> >> the field today...)
> >>
> >>       Erik
> >>
> >
> > IP tunnels) and support for that was deprecated in the 1970's in
> > favour of SNA. So I wouldn't hold your breathe waiting for 100%
> > migration to IPv6. It's going to be pretty easy to maintain a private
> > IPv4 - IPv4 network over a GRE tunnel over an IPv6 Internet for a very
> long time yet.
> >

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 13 Aug 2013 15:28:38 +0000

Lorenzo

I agree that source+destination routing solves it in an elegant way... but how many implementations are there beside the demo at the IETF?

This enterprise guidance should be practical. But, you are right we should mention at least that more work is currently being done at the IETF on this front.

-éric

Sent: lundi 12 août 2013 07:35

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 13 Aug 2013 15:49:37 +0000

On Aug 13, 2013, at 8:28 AM, "Eric Vyncke (evyncke)" <[email-masked]>
 wrote:

> how many implementations are there beside the demo at the IETF?

Well, we know of four: Ole and Lorenzo's SADR, Juliusz Chroboczek's Babel, Shu Yang's MTR OSPF-based implementation, and his implementation of my OSPF/IS-IS concepts. They are all prototypes as far as I know, but yes, they exist.

http://tools.ietf.org/html/draft-acee-ospfv3-lsa-extend
  "OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, Fred
  Baker, 2013-07-15

http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing
  "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 2013-02-17

http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing
  "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 2013-05-02

http://tools.ietf.org/html/draft-chroboczek-babel-extension-mechanism
  "Extension Mechanism for the Babel Routing Protocol", Juliusz
  Chroboczek, 2013-06-30

http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication
  "Babel HMAC Cryptographic Authentication", Denis Ovsienko, 2013-04-18

http://tools.ietf.org/html/draft-troan-homenet-sadr
  "IPv6 Multihoming with Source Address Dependent Routing (SADR)", Ole
  Troan, Lorenzo Colitti, 2013-02-18

http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing
  "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, Shu
  Yang, Jianping Wu, Dan Wang, 2013-02-18

http://tools.ietf.org/html/draft-xu-homenet-traffic-class
  "Traffic Class Routing Protocol in Home Networks", Mingwei Xu, Shu Yang,
  Jianping Wu, Fred Baker, 2013-07-15

---

From: Tom Perrine <[email-masked]>
Date: Wed, 21 Aug 2013 10:19:40 -0700

> and has less CAPEX and OPEX than middlebox firewalls will ever have.

SDSC.EDU ran a major HPC center without border firewalls for the 10 years I was there (1993-2003), and still does.

"Firewalls are for things too stupid to protect themselves" was the design principle I put in place then, and it can
still be valid today, if you have very good host management.

You can manage all of those on-host firewalls as a single large virtual firewall, whether it is Puppet/cfengine +
iptables, or your Windows host management tool of choice.

None of this is IPv6-specific, it just seems that people want to use "OMG firewalls!!!!!" as a reason to avoid moving to
IPv6.  Same arguments, different advancement they are trying to avoid, different decade.