Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt]

From: Erik Nygren <[email-masked]>
Date: Wed, 24 Oct 2012 18:00:45 -0400

On Fri, Aug 31, 2012 at 3:14 AM, Brian E Carpenter
<[email-masked]> wrote:
> [...]
>
> Other changes were relatively minor, but there are several new points from
> Erik Nygren's extensive review (thanks, Erik!). Here are some detailed responses
> to Erik's suggestions:
>
> [...]
>
> We prefer to refer to RFC2616 where proxy behaviour is actually specified.
> RFC3040 is only a taxonomy document from a not-very-successful WG. (BC: I've also never
> understood the phrase "reverse proxy"; it's just a proxy that happens to be near the
> server instead of near the client, but what it actually does is the same. Also,
> "proxy" and "surrogate" mean the same thing in English.)

RFC2616 would indicate that what is labelled in the diagram in section
7 isn't strictly a proxy
(for example, proxies receive URLs in absolute form, and in many
typical contexts, clients
may be aware that they are communicating with a proxy or are
configured to use non-transparent
proxies, which is not the case here). In the common scenario that ICPs
are likely to deploy
(where the AAAA record  is handed out), the client is unaware that it
is talking to a surrogate/gateway
rather than to an origin.  A "gateway" as described in RFC2616 might
be a better but less frequently used term?

As a side-note, using a HTTP Proxy with IPv6 connectivity does turn
out to be a light-weight way
for content providers with clients who lack IPv6 connectivity to test
dual-stacked sites,
but that is a different scenario.  (For example, it can be useful to
setup a few proxies
on different ports with different behaviors: IPv4-only, IPv6-only,
dual-stack with IPv6-preferred,
alternate IPv4/IPv6, etc. It is easier for users to switch their proxy
settings between these ports
for testing out different scenarios than for the users to have to make
networking changes on their clients.)

>>  <section anchor="cdn" title="Content Delivery Networks">
>
> We didn't understand the reason for the changes suggested here, and we don't think the CDN
> topic should be embedded in the "complexity" section. It's basic for most ICPs, these days.

The specific points:

* Not all CDNs have an architecture which necessitate having dual
stack service at each POP
  or which require routing to be the same between IPv4 and IPv6.  For
a CDN using some
  DNS-based techniques, the AAAA records could be for different POP(s)
than the A records.
  Given that many ISPs have fairly different IPv4 and IPv6 routing and
peering, it's often not
  reasonable to assume that IPv6 routing can be handled exactly like
IPv4 routing.
  (There are some other CDN architectures where what is described in
that first paragraph
  may be accurate.)

* The note  "A related side effect is that copies of the same content
viewed at the
   same time via IPv4 and IPv6 may be different, due to latency in the
   underlying data synchronization process used by the CDN." isn't
just a CDN issue
   and applies much more broadly to ICPs with services distributed
across multiple POPs.
   Even outside of the dual-stack context it can be an issue with
clients as they move between
   origin POPs.    As such, I'd moved this text to the "Possible
Complexities" section.
   (Right now it looks like the same text is duplicated in both sections?)

* The quote in this section feels stylistically out-of-place from the
rest of the draft.
   (Perhaps it just seems odd to me to quote a particular vendor?)

>> + <section anchor="client" title="Client Software">
>>    <t>One important recommendation here is that all applications should use domain names, which are IP-version-independent,
>
> That isn't restricted to clients - it should apply everywhere. In any case we can't really
> tell ICPs to change their clients' software.

Perhaps there is a better place to put the recommendation, but
avoiding IPv4 literals is something
that ICPs will need to watch out for given that it doesn't play well
with DNS64.  (Some streaming
media servers used to hand out redirections to IPv4 addresses,
although I'm not sure if any
still do this.)  For example, in Cameron's list of Android software
that didn't play well with DNS64+NAT64,
at least some of it seemed to be client software under an ICP's
control that used IPv4 literals.

My apologies for not responding in a more timely manner.

Best regards,

      Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Oct 2012 08:04:21 +0100

Hi Erik,

> be a better but less frequently used term?

I'm not convinced, because "gateway" is an even more general term than "proxy".
Personally, I hate the term "transparent proxy", because it's a lie.

>   reasonable to assume that IPv6 routing can be handled exactly like

Agreed, which can lead to considerable complexity, especially when
diagnosing problems. The question is whether that is a situation
we can analyse in any useful way in this document.

>    and applies much more broadly to ICPs with services distributed

True, but this section is about CDNs.

>    (Right now it looks like the same text is duplicated in both sections?)

Yes; because the same point arises in more than one context. That's an
editorial choice we made.

> control that used IPv4 literals.

Yes, this is a general point that in fact may deserve its own draft,
which might be better placed in the Apps area. Most content providers
have no direct control over the apps layer code anyway.

> My apologies for not responding in a more timely manner.

We'll wait for direction from the WG Chairs.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Thu, 25 Oct 2012 01:54:20 -0700 (PDT)

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: Erik Nygren <[email-masked]>
> Cc: IPv6 Operations <[email-masked]>
> Sent: Thursday, 25 October 2012 6:04 PM
> Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt]
> 
> Hi Erik,
> 

I agree, I use the term "translucent proxy" because I think it is much
more accurate. If "transparent proxies" were truly transparent, it wouldn't be possible to
find them in the network by comparing the output of traditional traceroute
to a host with a tcptraceroute to a service residing on that same host.

Regards,
Mark.

---

From: Arturo Servin <[email-masked]>
Date: Thu, 25 Oct 2012 09:55:57 -0200

Although it may not be correct, "reverse-proxy" is the well known term
accepted by the technical community. I prefer this term (that IMHO
people is familiar with) rather than a new or not well known such as
"translucent proxy".

	I would suggest to add something like:

"for example by running what is operationally known as a reverse proxy
[REF] that handles IPv6 customers"

	And add the REF to [1] for example.

http://httpd.apache.org/docs/2.2/mod/mod_proxy.html

Just my humble 20 cents.
/as

On 25/10/2012 06:54, Mark Smith wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Oct 2012 14:11:17 +0100

But what is "reverse" about it? As far as I can see it's just
a proxy that happens to be near the server rather than near
the client.

Regards
   Brian

---

From: Arturo Servin <[email-masked]>
Date: Thu, 25 Oct 2012 11:23:28 -0200

Yes, basically. The difference in terms it is just for (I guess) to
differentiate a proxy (near the user) from a reverse-proxy (near the
server). It is "reverse" because the reference point is the user.

    I have no problem in using "proxy" alone or "reverse-proxy", just
not use something new or not very well defined as "translucent".

Regards,
as

---

From: SM <[email-masked]>
Date: Thu, 25 Oct 2012 23:02:27 -0700

Hi Brian,
>a proxy that happens to be near the server rather than near

draft-ietf-httpbis-p1-messaging-19 discusses about (http) 
proxies.  The "reverse proxy" acts like a http server instead of a http client.

Regards,
-sm

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Oct 2012 09:24:24 +0100

On 26/10/2012 07:02, SM wrote:
> draft-ietf-httpbis-p1-messaging-19 discusses about (http) proxies.  The
> "reverse proxy" acts like a http server instead of a http client.

It behaves like a client on one side and a server on the other side.

    Brian

---

From: SM <[email-masked]>
Date: Fri, 26 Oct 2012 02:35:03 -0700

Hi Brian,
>It behaves like a client on one side and a server on the other side.

Yes.  The short answer is that it is a well-known term [1].

Regards,
-sm

1. http://wiki.squid-cache.org/SquidFaq/ReverseProxy