Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6

["George, Wes" <[e-mail]>]

This is a useful draft.

I've been doing some IPv6-only testing of websites listed in the world v6 launch participants, and found a lot of supposedly IPv6-capable sites that aren't fully functional over IPv6-only because some portion of them are still reliant on IPv4-only content/CDNs for images, CSS, subdomains, etc. Worse, I've found sites that simply aren't working over IPv6 anymore, and the operator of the site is unaware. This would be quite obvious if the site maintainers were completing their unit testing and monitoring over single-stack IPv6, but may well be masked by happy eyeballs if done dual-stack, so this draft will help to publicize this problem.

A few comments on the draft itself:

Section 2.1 and 6- an explicit recommendation to vendors that they SHOULD support use of IPv6 for all transport (RFC 6540) of monitoring, provisioning, and management data might be useful here. This is an area where vendors often lag because they've been focused on enabling support for IPv6 through the box, but it's becoming increasingly important for operators trying to conserve IPv4 addresses for end-customer use.

For completeness, you may want to briefly discuss NTP, Syslog, ssh, and other OAM-type traffic somewhere in section 2.

There is also a draft in progress in MPLS dealing with IPv6-only operation of MPLS networks (draft-george-mpls-ipv6-only-gap) that may contain some things relevant to this draft since it covers some of the aspects of OAM for MPLS networks.

Another consideration for this draft might be a recommendation to transition to single-stack (IPv6) as rapidly as possible for any tools that do not need to explicitly verify IPv4 operation. In other words, things like flow data transport, SSH, etc might be able to operate only over IPv6, while SNMP polls, HTTP tests, etc would need to remain dual stack so that they can verify IPv4 is working properly. Since dual-stack support means duplicating a lot of operations complexity (filters, troubleshooting path problems, monitoring configuration, etc), eliminating the need to support both IPv4 and IPv6 for as much management traffic as possible potentially allows for simplification of configuration, reclamation of addresses, etc.

Thanks,

Wes George

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Arturo Servin
> Sent: Saturday, July 13, 2013 9:46 AM
> To: [e-mail]
> Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6
>
> Hi,
>
>     We have sent this draft about considerations and recommendations to
> monitor IPv6 and dual-stack networks and services. We have been talking
> with people deploying IPv6 and we have found that not all monitor their
> networks and not many monitor them properly. We also found some
> challenges in monitor implementations that not fully support IPv6
> monitoring technologies (snmp, netflow, ipfix, ipv6 transport). Even
> though monitoring v6 networks is as critical as doing it in v4, we have
> not found many documents explaining how that has to be done (at least
> guides with free access or up to date).
>
>     There are also some misconceptions about monitoring IPv6, for
> example SNMPv3 != SNMP+IPv6, or that you cannot collect IPv6 data and
> send them on IPv4 that we wanted to clarify.
>
>      We collected some recommendations from informal conversations with
> people during some training and NOGs meeting during this year but we
> need some more input. We will be sharing this draft with other forums to
> get more inputs but we wanted to share it here first.
>
> Best wishes,
> Arturo and Mariela
>
> On 7/13/13 9:45 AM, [e-mail] wrote:
> > A new draft has been posted, at http://tools.ietf.org/html/draft-
> servin-v6ops-monitor-ds-ipv6. Please take a look at it and comment.

Anything below this line has been added by my company's mail server, I have no control over it.
-----------------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.