Subject: [v6ops] comments on draft-gont-v6ops-ipv6-ehs-in-real-world-00

From: 神明達哉 <[email-masked]>
Date: Fri, 8 Aug 2014 09:41:08 -0700

I've read the draft and have a few comments on it:

Section 4: for the probing measurement you should have sent packets
without the extension headers in question to identify the point where
the packets are dropped and make it more likely that it's dropped
because of that extension header.  It may be easily inferred from the
context, but I think it's helpful to note that explicitly.  As I read
the rest of the draft I found it would probably just suffice to refer
to Appendix A.1 from this section.

Section 4
   Packets dropped by the destination AS are less of a
   concern, since they can be assumed to be the result of an explicit
   policy of the organization to which the packets are destined (who can
   make its own decision regarding what kind of traffic is
   "acceptable").
I agree with the sense of this sentence, but I think the "since"
clause is a bit too strong.  For cases like ordinary household users
connected to ISPs, the situation shouldn't be so different from the
case where the packet is dropped in a transit AS in practice.

Section 4: the numbers in tables 1 and 2 are confusing to me.  For
example, in the following cell of table 1:

   +--------------+-----------------+
   |   Dataset    |       DO8       |
   +--------------+-----------------+
   |     Web      |      11.88%     |
   |              | (17.60%-20.80%) |
   +--------------+-----------------+

What exactly do these numbers represent?  I guess '11.88%' is the
percentage of the dropped packets against the total number or probe
packets.  The meaning of the "range" values were explained in the
draft, but it's still not clear enough to me...is 17.60% the
percentage of...what, for example?

Editorial nits:

- Section 3.1: s/patch/path/ ?
   Processing a large amounts of traffic in the slow patch may cause the

- Section 3.2: s/same same/same/
   for the RA-Guard case, but same same techniques can be employed for

- Section 4: s/list/list)/
   o  Mail servers (MX -> AAAA of such list

- Section 4: s/A.2/A.2)/ (?)
   to which a specific router belongs (see Appendix A.2, our

- Section 5.2: s/forged an/forged/
   sending a forged an ICMPv6 Packet Too Big [RFC4443] error message to

- A.1: s/dropping/dropped/ (?)
   Let us assume that we find that IPv6 EHs are dropping on their way to

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Aug 2014 08:17:08 +1200

Hi,

On 09/08/2014 04:41, 神明達哉 wrote:
...
> I agree with the sense of this sentence, 

Actually, I disagree. You cannot assume that the network managers have
taken a conscious decision; the only safe assumption is that they have
accepted the vendor default of their firewall or load balancer product.
(Which is why I for one care a lot about the recommendations in
draft-gont-opsec-ipv6-eh-filtering.)

> but I think the "since"

Indeed; the user is a victim of ISP policy.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 08 Aug 2014 16:50:54 -0400

Ji, Jinmei,

Thanks so much for your feedback! -- Please find my comments in-line...

On 08/08/2014 12:41 PM, 神明達哉 wrote:
> because of that extension header.

Yes, that's exactly what we did.

> It may be easily inferred from the

Will do.

> case where the packet is dropped in a transit AS in practice.

Agreed. Although in this case we were testing servers, as opposed to
clients.

> What exactly do these numbers represent? 

11.88% is the packet drop rate when using IPv6 D08. i.e., for 11.88% of
destinations, communications fail if you employ DO8.

What's withing parenthesis is the rate of packet drops occurring in
different ASes. That is, when packet drops do occur, between 17.60% and
20% of such drops occur in a different AS (the reason for the "range" is
explained in the appendix).

You're not the first to be confused by this table, though :-(. Any ideas
on how to make this more clear?  Maybe add a paragraph explaining one of
the cells?  (inclufing "mean and varince" wouldn't be much of an
improvement in terms of clarity, I think)

> I guess '11.88%' is the

17.60% is the percentage of the aforementioned packet drops that
occurred in a different AS than the destination AS (failing on the side
of "we assume the drop occurs in the dest AS" when in doubt). 20.80%
represents the same value, but assuming "the drop occurs in the dest AS"
when in doubt.

>    Processing a large amounts of traffic in the slow patch may cause the

Yep. Thanks!

>    Let us assume that we find that IPv6 EHs are dropping on their way to

You're right about all of these. We will fix them in the next revision.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Fri, 08 Aug 2014 17:01:38 -0400

Hi, Brian,

On 08/08/2014 04:17 PM, Brian E Carpenter wrote:
> Actually, I disagree.

Some rationale: When we presented our initial results showing just the
packet drop-rate, some folks kind of noted that 'well, that may not be
that bad if the drops occur at the destination as..'. So you might argue
that, to some extent, we tried to be optimistic here.

If you ask me, the fact that they are dropped by anyone other than the
very destination *system* (rather than AS) should be taken as an
indication that there's a problem with usability of IPv6 EHs...

> You cannot assume that the network managers have

Yes. We should have just said something along the lines of "this is the
best-case scenario, since at least the packet drops are under the
control of the same org as the destination system". --- although this is
still tricky.. you may have a VPS, or rack and it is the ISP the one
dropping the packets.  i.e., even if dest AS == dropping AS, the org
running the server may be different than that dropping the packets.

> draft-gont-opsec-ipv6-eh-filtering.)

Agreed.

> Indeed; the user is a victim of ISP policy.

Some preliminar data seems to indicate that there's also an issue with
buggy (?) CPEs that drop packets with IPv6 EHs. Hopefully we will have
more data available soon.

Thanks!

Cheers,

---

From: 神明達哉 <[email-masked]>
Date: Mon, 11 Aug 2014 09:27:11 -0700

At Sat, 09 Aug 2014 08:17:08 +1200,

> draft-gont-opsec-ipv6-eh-filtering.)

I guess I was just not clear enough.  The "sense" I saw in the draft
text is that there can be a noticeable difference between packets
dropped in the middle and packets dropped in the destination AS (and
it makes some sense to measure the packet drop rate for these cases
separately): in the latter case it's *possible* that the same
organization manages the entire AS including the packet's final
destination and dropping the packet is actually the intended behavior
of the administrator.  I noted that it's still not *always* the case in
the "but" below, and in that sense I think we are actually on the same
page.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Mon, 11 Aug 2014 10:04:44 -0700

At Fri, 08 Aug 2014 16:50:54 -0400,

> Agreed. Although in this case we were testing servers, as opposed to

I thought these sentences (more specifically, "Packets dropped by
the intended destination...are dropped by a transit AS.") talk about
a general observation, rather than something very specific to the
measurement.  Besides, I believe my comment also applies to "servers"
in that the admin of the destination AS may not always be the admin of
the destination server.

> destinations, communications fail if you employ DO8.

This one is pretty clear to me, and I interpreted it that way.  The
confusing part is the numbers in the parentheses.

> explained in the appendix).

So, for example, if you sent out 10,000 packets with IPv6 DO8:

- 1188 packets were dropped
- Out of these 1188 dropped packets, 209 to 237 packets seem to have
  been dropped in an different AS

?  It would be very difficult to reach this understanding just from
the text and the table, at least to me:-)

> improvement in terms of clarity, I think)

One easy improvement that would have worked for me is to add more
description to the tables, e.g. "Table 1: WIPv6LD dataset: Packet drop
rate for different destination types (upper) and estimated percentage
of dropped packets that were deemed to be dropped in a different AS
(lower, in parentheses)".

This explanation was also hard to understand to me:

   Since there is some ambiguity when identifying the autonomous system
   to which a specific router belongs (see Appendix A.2), our
   measurements result in a percentage *range*: the lowest percentage
   value represents the "best case scenario" (where, when in doubt, we
   assume the packet drops occur in the same AS as the destination AS),
   and the highest percentage value represents the "worst case scenario"
   (where, when in doubt, we assume the packet drops occur at different
   AS than the destination AS).

(added a missing closing parenthesis for readability).  One possible
reason for this is that the explanation of the best/worst scenarios is
too technical and a reader could easily get lost.  Maybe we can just
give a higher level semantics here:

   Since there is some ambiguity when identifying the autonomous system
   to which a specific router belongs, our measurements result in a
   percentage *range* (see Appendix A.2).  In the following tables,
   the values shown in the parentheses represent the estimated range
   of possibility that when a packet is dropped it happens in a
   different AS.

and leave all other details to the Appendix.

But, now that I understand what it actually means, I'm not in a good
position of proposing a good suggestion anymore; it's already
impossible for me to see how it works for first-time readers.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Mon, 11 Aug 2014 14:47:22 -0400

> in that the admin of the destination AS may not always be the admin of

Agreed. We will not this in the next rev of the document.

> ?  

Yes.

> It would be very difficult to reach this understanding just from

Ok. Do you think it might help clarify things if we "split" each table
into two tables: one with the drop rate, and another with the "rate of
packet drops by different AS"?

> and leave all other details to the Appendix.

OK, I will keep this option in mind, and also discuss this with my
co-authors such that we find a way to improve the readabiily of this part.

Thanks so much!

---

From: 神明達哉 <[email-masked]>
Date: Tue, 12 Aug 2014 11:46:55 -0700

At Mon, 11 Aug 2014 14:47:22 -0400,

> packet drops by different AS"?

Maybe.  But I think the most important point is to clearly describe
the meaning of these range numbers *in some way*.  Separating tables
seems to be a minor detail to me in that sense.

--
JINMEI, Tatuya