Subject: Re: [v6ops] I-D Action:draft-chown-v6ops-call-to-arms-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Mar 2011 11:40:37 +1300

I like.

> 3.2.  Network flow records
> 
>    Where available, sites should seek to deploy network flow records for
>    traffic, to maximise opportunities to analyse traffic patterns after
>    the event, or in the case of reports of specific problems.  Netflow
>    v9 supports IPv6.  Open source IPv6-capable Netflow collectors also
>    exist, e.g. nfsen, from http://nfsen.sourceforge.net.

Can you also mention the situation for IPFIX, which should be starting to
take over from Netflow?

> 6.  Security Considerations
> 
>    There are no extra security consideration for this document.

duh

At least point out the requirement to run an IPv6-capable firewall
on June 8th...

   Brian

---

From: Fred Baker <[email-masked]>
Date: Mon, 21 Mar 2011 09:18:12 -0700

I suspect that was a slip of the pen; netflow version 9 is ipfix. Unless I'm mistaken, these are ipfix capable.

On Mar 20, 2011, at 3:40 PM, Brian E Carpenter wrote:

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

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 21 Mar 2011 18:07:42 +0000

> I suspect that was a slip of the pen; netflow version 9 is ipfix. Unless I'm mistaken, these are ipfix capable.

ipfix is netflow version 10.

Not many exporters / collectors support ipfix format just yet, even if lots 
of them are using ipfix identifiers.

Nick

-- 
Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 6169698
3 Westland Square    | INEX - Internet Neutral | Fax: +353 1 6041981
Dublin 2, Ireland    | Exchange Association    | Email: [email-masked]

---

From: Tore Anderson <[email-masked]>
Date: Tue, 22 Mar 2011 12:03:30 +0100

* Brian E Carpenter

> I like.

Agreed, thanks to the authors for creating this document.

* I-D.chown-v6ops-call-to-arms

> June 8th [...] some enterprise sites may choose to enable IPv6 in 
> user/client subnets, in which case the performance of those systems 
> and the applications they run will be of paramount interest.

I'd urge operator of end-user networks (both ISPs and enterprises) to be
very careful about enabling IPv6 precisely on the 8th of June. One of
the primary motivations for the event is for content providers to be
able answer the question: «Is the IPv6 internet sufficiently reliable
for us to permanently deploy AAAA records?»

I'm sure that most of you, like me, will hope that the answer to that
quistion will turn out to be «yes». However, if many end-user networks
will use the day to perform pilot/test-quality deployments of IPv6 to
their eyeballs, it will likely negatively affect the dual-stack
reliability as observed from the content providers' point of view, which
would be counter-productive.

While I applaud all efforts to bring IPv6 capability to end users ahead
of the 8th of June, just please don't turn it on exactly the 8th of June
00:00 UTC and hope for the best...

> A bigger problem exists if the application or OS tries IPv6 first and
> then does not fall back to IPv4.  A bug in versions of Opera prior to
> 10.5 caused such behaviour, which was obviously a big issue for Opera
> users trying to access dual-stack web sites with broken IPv6
> connectivity.

I believe this was actually Opera 10.50, not 10.5. Furthermore, the
problem was that it tried IPv6 unconditionally before IPv4, crappy
Teredo- and 6to4-based connectivity included. That was a huge problem on
Windows platforms, as Teredo and 6to4 is enabled by default there. It
*would* fail over to IPv4 after Windows' standard 21-second connection
timeout, but of course, that is an eternity for HTTP.

> (Regarding avoiding 6to4 rogue RA problems) However not all
> operating systems implement RFC 3484 yet, in particular MacOS X.

While true, it is worth noting that Mac OS X since version 10.6.5 have
implemented functionality that de-prefers IPv6 completely if any
interface has a 6to4-derived IPv6 address configured. This means that
recent OS X is more resilient than most other operating systems in
situations where rogue 6to4 RAs are present alongside «native» RAs;
while the other RFC 3484-implementing operating systems will get the
source/destination address selection right, they could still end up
selecting the rogue 6to4 router as the next-hop, something which usually
will lead to an IPv6 blackhole.

Finally I'd like to draw your attention to a page I've been maintaining
in the ARIN Wiki that details the most common known causes for end-user
brokenness and their fixes/workarounds, where applicable:

http://getipv6.info/index.php/Customer_problems_that_could_occur

I believe it contains useful information, especially for help desk staff
working on the 8th of June. Perhaps you could add a reference?

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27