Subject: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-00)

From: "Lee Howard" <[email-masked]>
Date: Mon, 11 Jun 2012 14:36:31 -0400

When discussed in Taipei, it seemed there was real interest in updating
guidance for 
enterprise networks.  From lack of list discussion, it now appears there's
no interest in 
the WG.  

1.  Are people interested?
2.  Should we let it die?
3.  Should we pursue other avenues of publication?

Lee

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Victor
> Kuarsingh
> Sent: Monday, March 26, 2012 7:42 AM
> To: IPv6 Operations
> Subject: Re: [v6ops] draft-chkpvc-enterprise-incremental-ipv6-00
> 
> IPv6 WG,
> 
> I would like to kick off some comments on this draft for other group
members to comment.
> 
> I do think (Bias noted) that this material is useful for Enterprises who
need to being and/or
> move their IPv6 deployments.  Many (of those I have worked with thus far)
are bogged
> down with personnel who are overwhelmed with what it may take to get IPv6
moving on
> their networks.
> 
> The draft breaks the challenge down by areas of focus (rolled into
> "Phases") which can help put this large challenge into bite size chunks
for them. The draft
> also provides some valid contextual information around
> IPv6 and highlights areas which should be looked at.
> 
> Given the good momentum we now have in the operator space, it would be
good to see this
> move forward into the Enterprise space.  I think such documents can help
many of those still
> waffling (too many to count) to start acting.
> 
> Regards,
> 
> Victor K
> 
> 
> On 12-03-22 8:02 AM, "Tim Chown" <[email-masked]> wrote:
> 
> >Hi,
> >
> >Due to a typo in the draft name, this draft didn't hit Fred's automated
> >WG tools, so the authors would like to raise the draft on the list now
> >with a view to securing a slot in Paris to discuss its value and content.
> >
> >In Taipei there was a comment in the WG session that there is no
> >up-to-date v6ops guidance on enterprise networks, while other scenarios
> >do have such texts.  So at the mic I invited people to join an effort
> >to put something together.  There is a good breadth of experience
> >across the people who stepped forward, and the result is available as
> >
> >http://www.ietf.org/id/draft-chkpvc-enterprise-incremental-ipv6-00.txt
> >
> >Does the WG think the subject matter of this draft is one we should
> >pursue in the WG?  If so, is the structure and content appropriate?  We
> >need some positive feedback and comments in order for Fred to schedule
> >us time in Paris.
> >
> >We have had a couple of people contact us off-list offering to help
> >develop the content.  But we'd like some feedback from the WG before
> >investing more time in doing so.  The -00 text is somewhat "rough", but
> >we feel it could be polished into something quite useful for the
> >community.
> >
> >Tim
> >
> >_______________________________________________
> >v6ops mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ray Hunter <[email-masked]>
Date: Wed, 13 Jun 2012 17:28:08 +0200

Regardless of whether this draft is the vehicle or not, one thing that I 
think is missing is that large enterprises currently almost universally 
use some sort of centralized gateway or proxy to access the Internet, 
coupled with "split DNS" (whether the IETF likes that or not).

Many enterprises have expressed a desire to become "Internet Centric" 
whatever that is. They're also moving very rapidly to cloud services for 
generic applications. However, they'll still need private enterprise 
networks with SLAs for many other business critical services ad interim, 
at least until the generic Internet supports an equivalent of Diffserv. 
Multiple IPv6 addresses per node, with a combination of PI space for the 
enterprise network and PA space fromlocal providers, is making direct 
proxy-free nat-free local Internet breakout potentially possible 
(together with MIF and appropriate address selection). DNSSEC is also 
potentially attractive to facilitate/ restore a basic end to end trust 
model.

So I think we know where we're starting, and I think we know where we 
end up, but is there any operational advice available on the steps that 
would be required to e.g. "unsplit DNS" (and remove proxies) when 
introducing IPv6?

In other words, how do we restore the end to end model without breaking 
stuff on the way?

regards,
RayH

Lee Howard wrote:
>> On 12-03-22 8:02 AM, "Tim Chown"<[email-masked]>  wrote:
>>
>>> Hi,
>>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Jun 2012 09:20:27 -0700

Hi Lee,

If you do decide to pursue this further, here are two
documents that fit this space:

https://datatracker.ietf.org/doc/draft-templin-v6ops-isops/
https://datatracker.ietf.org/doc/rfc5214/

Fred
[email-masked]

> Lee Howard
> Sent: Monday, June 11, 2012 11:37 AM
> To: 'Victor Kuarsingh'; 'IPv6 Operations'
> Subject: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-
> incremental-ipv6-00)
>

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 13 Jun 2012 14:32:03 -0400

Ray,

How would you propose we work this concept in?  These are good points
overall, but would we expect a document focused IPv6 in the enterprise to
also tackle fallout of architectural enhancements possible with IPv6?

I would think that such a document/concept would be best managed in a
separate document which  was focused on that subject.

I may have missed your point, but these are my initial thoughts.

Regards,

Victor K

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 13 Jun 2012 14:43:47 -0400

Fred,

I would (personally) tend to agree.  Given the details from
"draft-templin-v6ops-ispos", would a reference to that document fit the
bill?  

Regards,

Victor K

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Jun 2012 11:46:36 -0700

Hi Victor,

> From: Victor Kuarsingh [mailto:[email-masked]]
> Sent: Wednesday, June 13, 2012 11:44 AM
> To: Templin, Fred L; Lee Howard; 'IPv6 Operations'
> Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-
> incremental-ipv6-00)
> 
> Fred,
> 

Assuming the authors decide to pursue this work further, then
a reference to "draft-templin-v6ops-isops" would be fine.

Thanks - Fred

> >> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of
> >> Victor
> >> > Kuarsingh

---

From: "Lee Howard" <[email-masked]>
Date: Thu, 14 Jun 2012 11:01:38 -0400

> From: Ray Hunter [mailto:[email-masked]]
> Sent: Wednesday, June 13, 2012 11:28 AM
> To: Lee Howard
> Cc: 'Victor Kuarsingh'; 'IPv6 Operations'
> Subject: Re: [v6ops] Enterprise Guidance on IPv6
(draft-chkpvc-enterprise-incremental-
> ipv6-00)
think is missing is that
> large enterprises currently almost universally use some sort of
centralized gateway or proxy
> to access the Internet, coupled with "split DNS" (whether the IETF likes
that or not).

"Split DNS" meaning that different responses are returned depending on
whether the query 
comes from within the enterprise or from outside?  
For instance, an employee can reach ACCOUNTING.EXAMPLE.COM internally,
because the
name server returns a net 10 address, but a query from outside receives
NXDOMAIN?

> whatever that is. They're also moving very rapidly to cloud services for
generic applications.
> However, they'll still need private enterprise networks with SLAs for many
other business
> critical services ad interim, at least until the generic Internet supports
an equivalent of
> Diffserv.
enterprise network
> and PA space fromlocal providers, is making direct proxy-free nat-free
local Internet
> breakout potentially possible (together with MIF and appropriate address
selection).
> DNSSEC is also potentially attractive to facilitate/ restore a basic end
to end trust model.
> 
> So I think we know where we're starting, and I think we know where we end
up, but is there
> any operational advice available on the steps that would be required to
e.g. "unsplit DNS"
> (and remove proxies) when introducing IPv6?

What changes?  You can still return NXDOMAIN if you don't like the querier.
Or you can
respond with a AAAA and rely on your security to protect your accounting
system.

stuff on the way?

I may be misunderstanding you, though, since I'm not sure how the end-to-end
principle
applies to this DNS setup.  
Yes, GUA addressing makes it possible to eliminate NAT, but whether
enterprises eliminate
proxies depends on their policy reasons for implementing them in the first
place.

What should we say about all this?

Lee

> 
> regards,
> RayH
> 
> Lee Howard wrote:
> > When discussed in Taipei, it seemed there was real interest in
> > updating guidance for enterprise networks.  From lack of list
> > discussion, it now appears there's no interest in the WG.
> >
> >> Behalf Of
> >>> Due to a typo in the draft name, this draft didn't hit Fred's
> >>> automated WG tools, so the authors would like to raise the draft on
> >>> the list now with a view to securing a slot in Paris to discuss its
value and content.
> >>> up-to-date v6ops guidance on enterprise networks, while other
> >>> scenarios do have such texts.  So at the mic I invited people to
> >>> join an effort to put something together.  There is a good breadth
> >>> of experience across the people who stepped forward, and the result
> >>> is available as
> >>>
> >>> pursue in the WG?  If so, is the structure and content appropriate?
> >>> We need some positive feedback and comments in order for Fred to
> >>> schedule us time in Paris.
> >>>
> >>> investing more time in doing so.  The -00 text is somewhat "rough",
> >>> but we feel it could be polished into something quite useful for the
> >>> community.
> >>>
> >>> Tim
> >>>

---

From: Ray Hunter <[email-masked]>
Date: Thu, 14 Jun 2012 19:06:04 +0200

inline
> Lee Howard <mailto:[email-masked]>
> 14 June 2012 17:01
>> Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-
>> ipv6-00)
>>
>> Regardless of whether this draft is the vehicle or not, one thing that I think is missing is that
>> large enterprises currently almost universally use some sort of centralized gateway or proxy
>> to access the Internet, coupled with "split DNS" (whether the IETF likes that or not
>
I believe "Split DNS" can mean several things, which is why I placed it 
in quotes.

I don't think Split DNS was ever acknowledged as a standard. But it is 
widely deployed in enterprises AFAIK. One reason was to mitigate against 
cache poisoning. Another was to be able to use DNS with RFC1918 
addresses before this was supported on common implementations. Another 
was just so that internal name and address space was completely private 
in manufacturing environments. Another was for test & development 
environments. Another was so that dynamically updated names in AD could 
remain relatively secure from external interference.

So the namespace can be split, or the transport, or both.

I believe I've seen:

1) internal hidden servers that serve different zones internally as the 
external servers. These internal hidden masters may be used to source 
zone transfers to sacrificial external slave servers that serve a subset 
of the namespace. So ext.example.com may be served externally, but 
int.example.com may be restricted to the internal servers (simply by not 
having the secondary zone configured on the external server). The 
internal servers may or may not be able to resolve Internet names 
(sometimes via a proxy DNS setup) Here we have a split namespace, and 
potentially a split transport (depending on how internal hosts resolve 
external addresses)

2) A single set of DNS servers that serve different answers based on 
some parameter from the query e.g. a single DNS server using BIND 
"views" to provide an answer for accounting.example.com based on the 
source address of the query matching an on-enterprise-net pattern, that 
is not resolvable for off-enterprise-net addresses. Here we're clearly 
talking about split namespace, but contiguous transport.

3) Completely separate internal and external servers serving the same 
logical zone but with different content and sometimes managed completely 
separately e.g. www.example.com hosted externally at a hosting provider 
for a corporate website for public consumption, and a separate 
employee's version of the same website iww.example.com hosted internally 
by the IT department. The external DNS servers may have an Internet 
hints file and a be managed by the hosting provider. The internal DNS 
servers may have a (fake) master root zone and be managed by the IT 
department. Internal hosts normally will not be able to resolve 
www.external.com or www.example.com and are pointed to an appropriate 
web proxy via a proxy pac file. Here we're talking about split namespace 
and split transport. Sometimes there may even be conflicting or 
overlapping namespace.

4) Completely fictitious internal A record entries for trusted 3rd party 
companies where there is a private link between the two companies 
together with a contractual agreement defining responsibilities e.g. for 
B2B transactions or for managing outsourced systems, or providing 
outsourced services to example.com. This is just a horrible kludge.

5) Equivalent of a .local namespace for dev, test & production. So 
there'd be overlapping address space for hostname-x.dev.company.com 
hostname-x.test.company.com hostname-x.production.company.com. As 
software moved from one environment to the next, all that was changed 
was the DNS default search domain (no machine renumbering needed in 
order to avoid problems with high availability scripts having to be 
edited). Some people even used identical setups for all 3 environments 
(identical names, addresses & domains) to avoid changing anything as 
solutions were transported between environments (via hard media).

6) Manufacturing environments that were meant to be completely isolated 
(yes I know) that use private RFC1918 IP space.

Don't shoot the messenger.
> respond with a AAAA and rely on your security to protect your accounting
You're assuming that the transport has always been contiguous between 
internal and external hosts and DNS servers,  and that there is a single 
consistent set of authoritative name servers for a common Worldwide 
namespace. That is rarely the case AFAIK.
> What should we say about all this?
It's relatively easily to define a flexible PI based IPv6 addressing 
plan so that return routes can be de-aggregated as necessary (based on 
Internet latency) as the number of direct Internet gateways grows. That 
might be a useful hint for enterprises as they remove proxies and 
increase local breakout.

But I really don't know at the moment what's the best roadmap for 
migrating the DNS and the namespace to being "Internet centric", which 
is why I asked the WG ;)

It could get very complex because you can learn or leak IPv4 information 
(e.g. RFC1918 addresses, private namespace, or conflicting namespace) 
over an IPv6 transport connection (which will be end-to-end 
transparent), but which would not be transported over an IPv4 connection 
(the IPv4 transport either never existed, was DNS forwarded or proxied, 
or was NATted). Then add caching and mobile end nodes into the mix.

I suspect it will be quite easy for enterprises to paint themselves into 
a corner, if they haven't already. And if they already have, what do 
they do?

regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 Jun 2012 10:29:02 +0100

Re split DNS, someone pointed me at this interesting draft:
http://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-view

Not a popular topic in DNS land, of course.

Regards
   Brian

On 2012-06-14 18:06, Ray Hunter wrote:
>>> end

---

From: Fred Baker <[email-masked]>
Date: Mon, 18 Jun 2012 04:07:45 -0700

> Not a popular topic in DNS land, of course.

You're correct that DNS-land hasn't liked it. I think the point being made here is that, with or without help from namedroppers@, something akin to what Ray described is an operational reality. It's not unusual for a company to have an internal and external set of names, the latter much smaller. Servers that are externally-accessible don't translate names that the company doesn't authorize for external access, even if they have global addresses, and even for names that are so advertised, they might be internally read/write while externally read-only, and in fact be instantiated as separate servers, the read/write one periodically over-writing the read-only one.

Speaking for myself, I would rather have a frank discussion of a bad idea that is an operational reality than to play pretend (see my draft on firewalls, which has the same logic underlying it), because discussion may improve it or may convince people it is in fact a bad idea - or may demonstrate that it's a good idea that is unpopular.

---

From: Fred Baker <[email-masked]>
Date: Mon, 18 Jun 2012 04:14:12 -0700

Let me put a straight question to the working group. The topic is:

http://tools.ietf.org/html/draft-chkpvc-enterprise-incremental-ipv6
  "Enterprise Incremental IPv6", Lee Howard, Tim Chown, KK Chittimaneni,
  Yanick Pouffary, Eric Vyncke, Victor Kuarsingh, 27-Feb-12

Read the v6ops charter (http://datatracker.ietf.org/wg/v6ops/charter/). Do you feel that this document is within the charter? If so, do you feel that the document and its recommendations represent useful advice concerning operational practice in an enterprise (e.g., edge network that is large enough to provide its own IT services as opposed to contracting those) IPv6 network?

Based on that analysis and viewpoint, would you support its adoption as a working group draft?

I am of course interested in views across the working group. In this particular case, however, I would find especially interesting the commentary of enterprise network operators.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jun 2012 10:01:38 +0100

On 2012-06-18 12:14, Fred Baker wrote:
>  "Enterprise Incremental IPv6", Lee Howard, Tim Chown, KK
> Chittimaneni, Yanick Pouffary, Eric Vyncke, Victor Kuarsingh,
> 27-Feb-12
> 
> Read the v6ops charter
> (http://datatracker.ietf.org/wg/v6ops/charter/). Do you feel
> that this document is within the charter? 

Yes, under goal 1 (operational issues).

> If so, do you feel
> that the document and its recommendations represent useful
> advice concerning operational practice in an enterprise
> (e.g., edge network that is large enough to provide its own
> IT services as opposed to contracting those) IPv6 network?

The aims of the document are admirable and the range of topics
seems about right. However, I'd have expected to see separate
sections on major topics like DNS, DHCPv6, choice of routing
protocol (it's a bit facile to say "if using OSPF, use OSPF"),
address management tools, ops and management tools, firewalls,
load balancers, etc. I would also expect discussion of the
approach to transition tools.

This is really a book-length topic. That's one reason why we bit
off a smaller problem for draft-ietf-v6ops-icp-guidance-01.txt.

> adoption as a working group draft?

My concern is whether the document is too ambitious. If it is to
be detailed enough to be useful, maybe it needs to be split into
a number of separate documents.

    Brian

> 
> I am of course interested in views across the working group.
> In this particular case, however, I would find especially
> interesting the commentary of enterprise network operators.
> 
>> When discussed in Taipei, it seemed there was real interest
>> in updating guidance for enterprise networks.  From lack of
>> list discussion, it now appears there's no interest in the
>> WG.
>> 
>> 1.  Are people interested? 2.  Should we let it die? 3.
>> Should we pursue other avenues of publication?
>> 
>> Lee
>> 
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of
>> Victor
>>> Kuarsingh Sent: Monday, March 26, 2012 7:42 AM To: IPv6
>>> Operations Subject: Re: [v6ops]
>>> draft-chkpvc-enterprise-incremental-ipv6-00
>>> 
>>> IPv6 WG,
>>> 
>>> The draft breaks the challenge down by areas of focus
>>> (rolled into "Phases") which can help put this large
>>> challenge into bite size chunks
>> for them. The draft
>>>> Due to a typo in the draft name, this draft didn't hit
>>>> Fred's automated WG tools, so the authors would like to
>>>> raise the draft on the list now with a view to securing
>>>> a slot in Paris to discuss its value and content.
>>>> 
>>>> In Taipei there was a comment in the WG session that
>>>> there is no up-to-date v6ops guidance on enterprise
>>>> networks, while other scenarios do have such texts.  So
>>>> at the mic I invited people to join an effort to put
>>>> something together.  There is a good breadth of
>>>> experience across the people who stepped forward, and
>>>> the result is available as
>>>> 
>>>> Does the WG think the subject matter of this draft is
>>>> one we should pursue in the WG?  If so, is the
>>>> structure and content appropriate?  We need some
>>>> positive feedback and comments in order for Fred to
>>>> We have had a couple of people contact us off-list
>>>> offering to help develop the content.  But we'd like
>>>> some feedback from the WG before investing more time in
>>>> doing so.  The -00 text is somewhat "rough", but we
>>>> feel it could be polished into something quite useful
>>>> for the community.
>>>> 
>>>> Tim
>>>> 
>>>> _______________________________________________ v6ops
>>>> mailing list [email-masked] 
>>> _______________________________________________ v6ops
>>> mailing list [email-masked] 
>> _______________________________________________ v6ops
>> mailing list [email-masked] 
> _______________________________________________ v6ops mailing
> list [email-masked]

---

From: Tina TSOU <[email-masked]>
Date: Mon, 25 Jun 2012 17:40:01 +0000

In the assumptions, it is mentioned to provide native IP wherever possible. If the native IP is IPv6, it contradicts the sentence "want to minimize level of disruption". If native IPv6 is to be provided in the enterprise network, the devices have to be upgraded to support IPv6. Only devices which has are already support IPv6 would not have to be upgraded, what about the rest of the devices? Should their software be upgraded or should NAT64/transition be used at first and then slowly the entire network migrated to native IPv6.

In the phased approach, the two statements for implementation of IPv6 in the internal network does not provide strong reasons for deploying IPv6 internally. The statements about deployment of IPv6 in the internal enterprise should indicate the increasing need of the number of IP address internally in a company. As IPv6 is enabled by default in all operating systems, deploying IPv6 internally would not be a very difficult task. The priority always goes to external network first and simultaneously should be implemented in the internal networks. Else if it is not simultaneously done, again transition technologies need to be configured in the edge routers for communication between the external and internal networks.

In analyzing the network infrastructure stage, more than just IPv6 capable, the device should be checked for support of the applications required by the enterprise. There are routers that do not support MPLS VPN over IPv6, but are ipv6 capable. Thus, only being IPv6 capable is not enough, unless it is ensured its firmware supports the required applications over IPv6.

Address plan: Specifying change in A DNS records to quad A records is also important. So that when DNS query is made, appropriate DNS reply is ensured. 

Tools and assessment: Not only the monitoring tools should be checked for IPv6 enable, the devices running these tools should also be checked for memory. IPv6 applications will need more memory to store 128 bit addresses. The processing logic might also demand more processor memory.

"will likely time time "-----Page 13, second last para ( some correction)

While using PI for advertising routes, the routes when advertised to two upstream providers should have route filters to distribute traffic in the two paths according to business requirements. 

Provider may introduce challenges since traffic utilizing a given PA
assign block would be expected to flow tears the assigning provider
for entry to the Internet. (Excepted to flow tears)?  Didn't get the meaning of the line.

In the planning stage of deployment of IPv6, as far as possible native IPv6 should be employed. Transition technologies should be used only in impossible cases. Transition technologies poses security threat and complexity, and thus does not serve the true purpose of IPv6 deployment in the network. 

Tina
@ 2001:db8:1:ffff:e8e2:7822:9d12:e12e

> Brian E Carpenter
> Sent: Thursday, June 21, 2012 2:02 AM
> To: Fred Baker
> Cc: IPv6 Operations