Subject: [v6ops] management and ipv6

From: Jari Arkko <[email-masked]>
Date: Thu, 16 Dec 2010 20:49:13 +0200

In the course of discussing draft-arkko-ipv6-transition-guidelines in 
the IESG, Dan and other IESG members brought up the need to talk about 
management in IPv6 networks. For instance, in IPv6-only networks all 
your management tools have to be capable of IPv6, both in dual stack and 
IPv6-only you want your data models to support IPv6, in dual stack you 
need to monitor reachability and errors not just in IPv4 but also in 
IPv6, and so on. They believe that there's quite a bit of work in this 
if you actually dig through all the details such as what MIB versions 
are required.

Draft-arkko will be moving forward as we close some other last issues, 
but would the V6OPS WG be willing to work on a separate document to talk 
about management of IPv6 networks? Or is there such a document already?

Jari

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 16 Dec 2010 14:17:00 -0500

> if you actually dig through all the details such as what MIB versions

yes. fully agree. I've been looking into this problem.

> Or is there such a document already?

not to my knowledge. I'm willing to work on one.

Marc.
>
> Jari
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN Implementation: http://postellation.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Dec 2010 11:31:32 -0800

On Dec 16, 2010, at 10:49 AM, Jari Arkko wrote:

> Draft-arkko will be moving forward as we close some other last issues, but would the V6OPS WG be willing to work on a separate document to talk about management of IPv6 networks? Or is there such a document already?

Speaking as one of the chairs, our charter (http://datatracker.ietf.org/wg/v6ops/charter/) doesn't comment on network management one way or the other. I the network management community wanted to propose a document, we would (as we do with all documents proposed to us) let them present it, discuss it, and poll the working group as to whether it wanted to work on it. The working group consensus would rule there.

Let me ask a question in context - what kind of discussion is desired?

If the IESG is looking for MIBs or YANG modules, I'll note that MIBs are usually developed by the working groups that developed the technology the MIB manages. RFC 4293, for example, was developed by the IPv6 Working Group. I'm not sure that there is YANG expertise outside netconf. IPv6 Operations' charter precludes it from developing technologies; it is chartered to develop requirements for technologies, which it hands off to other working groups. So the operational context doesn't seem like the right place for building those. I would try to get the network management community to work with subject matter experts in the working groups that develop technology.

If the IESG is looking for a requirements document, I'm at a loss to say what requirements an IPv6 network has that an IPv4 network doesn't, apart from details of address format and such.

Maybe the IESG is looking for something else...

I would suggest that the network management community propose a project.

---

From: Tina Tsou <[email-masked]>
Date: Thu, 16 Dec 2010 11:33:52 -0800

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marc Blanchet
Sent: Thursday, December 16, 2010 11:17 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [v6ops] management and ipv6

[Tina:
And some prior work could be taken into account.
Filename: draft-tsou-opsawg-network-configuration
Title: Problem Statement For the Configuration of Large-Scale IP Networks
I assume this is being adopted as OPSAWG WG item.

Filename: draft-schoenw-opsawg-nm-dhc-01
Title: Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for
Network Management Protocols

Filename: draft-schoenw-opsawg-nm-srv-01
Title: DNS SRV Resource Records for Network Management Protocols
]

Marc.

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Dec 2010 12:37:04 -0800

On Dec 16, 2010, at 11:57 AM, Romascanu, Dan (Dan) wrote:
> What I have in mind is the operational issues related to how keep the functionality of a network management system (application and devices) functional during the transition between IPv4 and IPv6 in the different scenarios. This includes (but is not limited to) how to keep connectivity between devices and applications in v6 only or v4/v6 networks and how data models need to be built to support transition and what needs to be changed during the transition. I think that such work would need inputs from operators and management applications experts. 

No doubt.

Speaking for myself, I suspect that there are two questions here:
1) do we have the right MIBs and YANG modules?
2) are they correctly transported?

So this calls for five audits.
a) do we have an IPv6-capable MIB/YANG for every IPv4-capable MIB/YANG?
b) Do the vendors implement them?
c) is there anything we might need to monitor or configure that we don't have IPv4 and/or IPv6-cable MIB/YANG for?
d) SNMP/*/IPv4 and Netconf/*/IPv4 are defined. Are the corresponding */*/IPv6 specifications defined?
e) Do the vendors implement them?

Do you have a volunteer to do the work?

---

From: Jari Arkko <[email-masked]>
Date: Thu, 16 Dec 2010 22:49:59 +0200

Fred,

> ask a question in context - what kind of discussion is desired?
>
> If the IESG is looking for MIBs or YANG modules, I'll note that MIBs are usually developed by the working groups that developed the technology the MIB manages. RFC 4293, for example, was developed by the IPv6 Working Group. I'm not sure that there is YANG expertise outside netconf. IPv6 Operations' charter precludes it from developing technologies; it is chartered to develop requirements for technologies, which it hands off to other working groups.
>   

No, I don't think the request was about developing new MIBs or similar.

> If the IESG is looking for a requirements document, I'm at a loss to say what requirements an IPv6 network has that an IPv4 network doesn't, apart from details of address format and such.

No, I don't think the request was about that either.

> Maybe the IESG is looking for something else...

The way that I heard the comment was that we need to have an operational 
document that tells me what management tools and features I should have 
so that I can manage my IPv6 network. For instance, perhaps an older 
version of a some MIB RFC only supports IPv4, I should check that my 
equipment supports a new version of the RFC. Or that if I'm on an 
IPv6-only network, my network management clients and elements obviously 
should support IPv6 transport. Again, maybe that means more RFCs or 
requirements from the RFCs for my equipment than what I currently have 
in my network. And so on.

But all this came from Dan, maybe he can put it in better words. I 
thought he explained it very well on the IESG meeting, and I'm just 
doing a poor job of communicating it to you... and I can see that he 
already did respond. Thanks, Dan.

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Dec 2010 11:50:33 +1300

Hi Jari,

Some gaps in management tools were reported in the survey that led to
RFC6036, although we didn't really split them out in the analysis.
However, I do emphasise *tools*. It isn't obvious that there's a gap
in IETF specifications. So I'd be interested in seeing more details
about the proposed scope of such a document.

Regards
   Brian

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 16 Dec 2010 20:57:22 +0100

Fred,

I personally did not think about development of MIB or YANG modules. We
have other WGs in the area and out of the area that do this. What I have
in mind is the operational issues related to how keep the functionality
of a network management system (application and devices) functional
during the transition between IPv4 and IPv6 in the different scenarios.
This includes (but is not limited to) how to keep connectivity between
devices and applications in v6 only or v4/v6 networks and how data
models need to be built to support transition and what needs to be
changed during the transition. I think that such work would need inputs
from operators and management applications experts. 

Dan

> From: Fred Baker [mailto:[email-masked]] 
> Sent: Thursday, December 16, 2010 9:32 PM
> To: Jari Arkko
> Cc: 'IPv6 Operations'; Romascanu, Dan (Dan)
> > Draft-arkko will be moving forward as we close some other 
> last issues, but would the V6OPS WG be willing to work on a 
> separate document to talk about management of IPv6 networks? 
> Or is there such a document already?
> 
> Speaking as one of the chairs, our charter 
> (http://datatracker.ietf.org/wg/v6ops/charter/) doesn't 
> comment on network management one way or the other. I the 
> network management community wanted to propose a document, we 
> would (as we do with all documents proposed to us) let them 
> present it, discuss it, and poll the working group as to 
> whether it wanted to work on it. The working group consensus 
> would rule there.
> 
> If the IESG is looking for MIBs or YANG modules, I'll note 
> that MIBs are usually developed by the working groups that 
> developed the technology the MIB manages. RFC 4293, for 
> example, was developed by the IPv6 Working Group. I'm not 
> sure that there is YANG expertise outside netconf. IPv6 
> Operations' charter precludes it from developing 
> technologies; it is chartered to develop requirements for 
> technologies, which it hands off to other working groups. So 
> the operational context doesn't seem like the right place for 
> building those. I would try to get the network management 
> community to work with subject matter experts in the working 
> groups that develop technology.
> 
> If the IESG is looking for a requirements document, I'm at a 
> loss to say what requirements an IPv6 network has that an 
> IPv4 network doesn't, apart from details of address format and such.
>

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Dec 2010 15:38:06 -0800

On Dec 16, 2010, at 11:17 AM, Marc Blanchet wrote:
>> would the V6OPS WG be willing to work on a separate document to talk about management of IPv6 networks?
> 
> I'm willing to work on one.

Marc:

Suggestion. How about you and Dan talk and come up with a proposed document? What I'm looking for is whatever Dan's looking for. Having an initial version to discuss in Prague would be interesting.

Fred

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 16 Dec 2010 18:45:21 -0500

> Suggestion. How about you and Dan talk and come up with a proposed document? What I'm looking for is whatever Dan's looking for. Having an initial version to discuss in Prague would be interesting.

will do.

(we had a discussion about this very topic as Dan was describing with a 
provider. looks simple on the surface, but the woods are much less clear 
when one dig more into it.)

Marc.

---

From: "Frank Bulk" <[email-masked]>
Date: Thu, 16 Dec 2010 21:28:21 -0600

It's of a more minor not, but what about the topic of how IPv6 addresses
should be logged in textual information (traps, syslog, logs, etc)?

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Romascanu, Dan (Dan)
Sent: Thursday, December 16, 2010 1:57 PM
To: Fred Baker; Jari Arkko
Cc: IPv6 Operations
Subject: Re: [v6ops] management and ipv6

Fred,

Dan

---

From: Randy Bush <[email-masked]>
Date: Fri, 17 Dec 2010 12:39:49 +0900

> It's of a more minor not, but what about the topic of how IPv6
> addresses should be logged in textual information (traps, syslog,
> logs, etc)?

draft-kawamura-ipv6-text-representation-04.txt

---

From: "Frank Bulk" <[email-masked]>
Date: Thu, 16 Dec 2010 22:25:58 -0600

Well, that's was easy. =)

I think there's value in making sure that draft is referenced by whatever
management draft is written.  I don't want to have a multi-line Perl snippet
to capture all the possible variations that a network vendor might use if
they're unenlightened.

Frank

---

From: Seiichi Kawamura <[email-masked]>
Date: Fri, 17 Dec 2010 13:38:46 +0900

I understand where you're coming from.
I've been through that pain.
The draft is now RFC5952.
I think its already referenced by
quite a few relevant RFCs and drafts.

Regards,
Seiichi

---

From: Randy Bush <[email-masked]>
Date: Fri, 17 Dec 2010 14:18:48 +0900

>> draft-kawamura-ipv6-text-representation-04.txt

and that is exactly why kawamucho, a local hero, wrote that draft.

randy

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 16 Dec 2010 21:31:40 -0800

On 12/16/10 10:49 AM, Jari Arkko wrote:
> IPv6, and so on.

what version of netflow you use is also germain for example.

> They believe that there's quite a bit of work in this

There's a corpus of work expressed as nanog presnetations among others
on how you manage ipv6 networks.

If some kind of gap analysis reveals protocol omissions or usability
issues with the management of ipv6 I could imagine  that fitting within
the v6ops scope.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 17 Dec 2010 10:12:30 +0200

Brian,

> about the proposed scope of such a document.

I do not expect to find many gaps in the IETF specifications in this 
area. If any.

My understanding was that the document would explain what operational 
tools I need for managing my IPv6 network. An important part of that 
might be the list of things my equipment needs to support.

Jari

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Fri, 17 Dec 2010 09:16:51 +0100

On 17.12.2010 5:38, Seiichi Kawamura wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Seichi,

That's good work, congrats on getting to RFC (did not know :) )

Jan Zorz
go6.si

---

From: Pekka Savola <[email-masked]>
Date: Fri, 17 Dec 2010 13:21:56 +0200 (EET)

On Fri, 17 Dec 2010, Jari Arkko wrote:
>>  Some gaps in management tools were reported in the survey that led
>>  to RFC6036, although we didn't really split them out in the
>>  analysis. However, I do emphasise *tools*. It isn't obvious that
>>  there's a gap in IETF specifications. So I'd be interested in
>>  seeing more details about the proposed scope of such a document.
>> 
>
> I do not expect to find many gaps in the IETF specifications in this area. If 
> any.

Unfortunately, the IETF has also recently approved protocols with 
known IPv6 deficiencies.  As an operational example, Flowspec routes 
don't support IPv6 (RFC5575).  These could be generated by a 
management station or by a customer.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "t.petch" <[email-masked]>
Date: Fri, 17 Dec 2010 12:42:51 +0100

----- Original Message -----
From: "Fred Baker" <[email-masked]>
To: "Jari Arkko" <[email-masked]>
Cc: "Romascanu, Dan (Dan)" <[email-masked]>; "'IPv6 Operations'"
<[email-masked]>
Sent: Thursday, December 16, 2010 8:31 PM
> > Draft-arkko will be moving forward as we close some other last issues, but
would the V6OPS WG be willing to work on a separate document to talk about
management of IPv6 networks? Or is there such a document already?
> Speaking as one of the chairs, our charter
(http://datatracker.ietf.org/wg/v6ops/charter/) doesn't comment on network
management one way or the other. I the network management community wanted to
propose a document, we would (as we do with all documents proposed to us) let
them present it, discuss it, and poll the working group as to whether it wanted
to work on it. The working group consensus would rule there.
> If the IESG is looking for MIBs or YANG modules, I'll note that MIBs are
usually developed by the working groups that developed the technology the MIB
manages. RFC 4293, for example, was developed by the IPv6 Working Group. I'm not
sure that there is YANG expertise outside netconf. IPv6 Operations' charter
precludes it from developing technologies; it is chartered to develop
requirements for technologies, which it hands off to other working groups. So
the operational context doesn't seem like the right place for building those. I
would try to get the network management community to work with subject matter
experts in the working groups that develop technology.
>
> If the IESG is looking for a requirements document, I'm at a loss to say what
requirements an IPv6 network has that an IPv4 network doesn't, apart from
details of address format and such.

I think that wrong, although it would probably take me longer than the Christmas
break to gather the hard data.  I am thinking of all the discussions, on this
and other lists, of the things that can - will!! - go wrong in an IPv6 network
that cannot happen in an IPv4 network because the functionality is not there.
I have assiduously followed this list, but lack the practical experience - IPv6
does not exist in the part of the world I am in - so have become aware of, oh, M
and O, address selection with multiple addresses on every interface,
configuration via DHCP v other means, this current ULA issue, tunnel problems
with a diverse return path, prefix lengths, ...

My sense is that IPv6 will be much harder to get working, because of poor
configuration, misconfiguration, poor implementation, misimplementation etc and
so the demands on management
will be much the greater; and will be unique to IPv6.

Tom Petch

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Dec 2010 05:12:12 -0800

On Dec 17, 2010, at 3:42 AM, t.petch wrote:

> My sense is that IPv6 will be much harder to get working, because of poor configuration, misconfiguration, poor implementation, misimplementation etc and so the demands on management will be much the greater; and will be unique to IPv6.

Well, let me put that question to the assembled masses. Operators that have already implemented IPv6, are there management requirements that you see in the IPv6 Internet that don't apply to IPv4? Do you have needs for tools that you don't have? Marc Blanchet has agreed to start pulling this document together, and will be collecting inputs.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 17 Dec 2010 18:28:40 +0200

Pekka,

> management station or by a customer.

Great. We need to stop doing that.

For some history, we did discuss at the time whether this document could 
go ahead without IPv6. I wrote in the tracker...

> 1) I have let go off my IPv6 discuss, on the basis that Danny McPherson
> has promised to write a document on this, and the RTG ADs agree that the
> work belongs in the charter and should be done.

However, its been a while and I still don't see a document about this in 
the working group. Is there one in development?

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Dec 2010 08:27:41 +1300

> what version of netflow you use is also germain for example.

I think you might mean ipfix, in the IETF context. Making sure that
ipfix is 100% ipv6-safe is important.

    Brian

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 17 Dec 2010 20:32:05 +0100

> ipfix is 100% ipv6-safe is important.

NetFlow v9 does IPv6, and IPFIX (NetFlow v10) does it in exactly the
same way, there is just a minor header difference in the packets.

That is the protocol though, if the tools actually understand it is a
different question, but by now I think most major tools have support for
IPv6 for both transport of IPFIX/NFv9 and the fields transported by it.

Now, getting physical gear that sends the exports transporting it using
IPv6 might be another thing though ;)

Greets,
 Jeroen

---

From: Merike Kaeo <[email-masked]>
Date: Sat, 18 Dec 2010 16:36:19 -0800

On Dec 16, 2010, at 3:45 PM, Marc Blanchet wrote:

> (we had a discussion about this very topic as Dan was describing with a provider. looks simple on the surface, but the woods are much less clear when one dig more into it.)

If you would like help, I would be willing to add to this.  I've been giving talks and looking at this issue for operational deployments the last 4-5 years....the biggest win was getting NTP over v6 transport finally out of the editors queue (the wg chair told me in Anaheim that she was at my NANOG talk where I mentioned being surprised that the standard wasn't yet 'done' and helped get it out of the queue at that moment :))

Suffice to say the management implementations are weak.  It's been on my todo list to see where the varying MIBs stand so as not to have poor vendor excuses for not having SNMP over v6 transport working.

I agree with statements that on the standard side things are probably fairly baked and exist.....shipping implementations - not so much.  All environments I've come across in last 5 years assumed v4 management with existing infrastructure.   This will change.

- merike

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 19 Dec 2010 11:36:41 -0500

Le 10-12-18 19:36, Merike Kaeo a écrit :
> If you would like help, I would be willing to add to this.

sure. let me start a document after holidays with what I have in mind. 
Then I'll pass around to you, Dan, and others who have said/contacted me 
to contribute.

Marc.

   I've been giving talks and looking at this issue for operational 
deployments the last 4-5 years....the biggest win was getting NTP over 
v6 transport finally out of the editors queue (the wg chair told me in 
Anaheim that she was at my NANOG talk where I mentioned being surprised 
that the standard wasn't yet 'done' and helped get it out of the queue 
at that moment :))

---

From: Pekka Savola <[email-masked]>
Date: Mon, 20 Dec 2010 09:09:46 +0200 (EET)

> same way, there is just a minor header difference in the packets.

FWIW, nfdump which is probably one of the most used recent OSSW tools 
in this area, does not currently support IPFIX (Netflow v6 is OK). 
There is a 3rd party patch to an earlier version so it might not be so 
far off the radar.

This is a bit annoying as a major router vendor has equipment which 
some support only Netflow v9, and others only IPFIX.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Dec 2010 10:45:40 +0100

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Friday, December 17, 2010 10:13 AM
> To: Brian E Carpenter
> I do not expect to find many gaps in the IETF specifications 
> in this area. If any.
> 

Yes, but operators do not use only IETF specifications. For example many
use proprietary MIB modules and while we have been careful to make sure
that any MIB document starting with RFC 4xxx or such uses the address
TCs that support both v4 and v6, enterprise MIB may have been slower to
have adopted these principles. You may say 'this is not IETF job' but
reality is that the vast majority of people using SNMP use it with a mix
of standard and proprietary MIB modules to manage vendors equipment.
Operators need guidance about how to check their proprietary stuff. 

This is one of the examples of hidden things that came to my mind in a
transition scenario. 

Dan

> My understanding was that the document would explain what 
> operational tools I need for managing my IPv6 network. An 
> important part of that might be the list of things my 
> equipment needs to support.
> 
> Jari
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Dec 2010 10:47:21 +0100

> Sent: Friday, December 17, 2010 1:38 AM
> To: Marc Blanchet
> Cc: [email-masked]; Romascanu, Dan (Dan)
> >> would the V6OPS WG be willing to work on a separate 
> document to talk about management of IPv6 networks?
> > 
> Suggestion. How about you and Dan talk and come up with a 
> proposed document? What I'm looking for is whatever Dan's 
> looking for. Having an initial version to discuss in Prague 
> would be interesting.

Having it earlier even better, taking into account that in many networks
transition happens now. 

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Dec 2010 10:51:58 +0100

> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Friday, December 17, 2010 9:28 PM
> To: Joel Jaeggli
> Cc: Jari Arkko; Romascanu, Dan (Dan); 'IPv6 Operations'
> >> In the course of discussing 
> draft-arkko-ipv6-transition-guidelines in 
> >> the IESG, Dan and other IESG members brought up the need to talk 
> >> about management in IPv6 networks. For instance, in IPv6-only 
> >> networks all your management tools have to be capable of 
> IPv6, both 
> >> in dual stack and IPv6-only you want your data models to support 
> >> IPv6, in dual stack you need to monitor reachability and 
> errors not 
> >> just in IPv4 but also in IPv6, and so on.
> > 
> I think you might mean ipfix, in the IETF context. Making 
> sure that ipfix is 100% ipv6-safe is important.
> 
>     Brian
>

I think it is. If somebody knows any deficiencies on this respect please
bring them to the attention of the IPFIX WG. 

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Dec 2010 10:54:37 +0100

> From: Marc Blanchet [mailto:[email-masked]] 

> Then I'll pass around to you, Dan, and others who have 
> said/contacted me to contribute.
> 
> Marc.
> 

Sounds like a (good) plan. 

Thanks for doing it. 

Dan