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

[Tina TSOU <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Brian E Carpenter
> Sent: Thursday, June 21, 2012 2:02 AM
> To: Fred Baker
> Cc: IPv6 Operations
> Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-
> incremental-ipv6-00)
> 
> On 2012-06-18 12:14, Fred Baker wrote:
> > 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?
> 
> 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.
> 
> > Based on that analysis and viewpoint, would you support its
> > 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.
> >
> > On Jun 11, 2012, at 11:36 AM, 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.
> >>
> >> 1.  Are people interested? 2.  Should we let it die? 3.
> >> Should we pursue other avenues of publication?
> >>
> >> Lee
> >>
> >>> -----Original Message----- From: [e-mail]
> >>> [mailto:[e-mail]] 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" <[e-mail]>
> >>> 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 [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/v6ops
> >>>
> >>> _______________________________________________ v6ops
> >>> mailing list [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >>
> >> _______________________________________________ v6ops
> >> mailing list [e-mail]
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >
> > _______________________________________________ v6ops mailing
> > list [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops