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

[Brian E Carpenter <[e-mail]>]

Hi Erik,

On 24/10/2012 23:00, Erik Nygren wrote:
> On Fri, Aug 31, 2012 at 3:14 AM, Brian E Carpenter
> <[e-mail]> 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?

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.

> 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.

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.


>   (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.

True, but this section is about CDNs.

>    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?)

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

> 
> * 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.

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


> Best regards,
> 
>       Erik
>