Subject: Re: [CDNi] CDNI Requirements I-D

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Feb 2011 08:56:19 -0800

> Folks,
>
> We've posted a "CDNI Requirements" I-D:
> https://datatracker.ietf.org/doc/draft-lefaucheur-cdni-requirements/
>
> Please, consider this as a first cut whose aim is to facilitate
> discussion and convergence on what are "urgent/important"
> requirements (that would have to be addressed in a potential initial
> WG charter) versus what are "less-urgent/less-important"
> requirements (that would be left for future rechartering or left out
> of scope altogether).
>
> Cheers,
>
> Francois, Mahesh, Grant & Yiu

In addition to your existing R4 requirement, the HTTP URI cannot contain
an IPv4 address literal.  This is necessary for NAT64 to work correctly,
and will be necessary for NAT46 to work correctly.  The use of IPv4 address
literals has been a problem in the wild, but is now mostly resolved.  
See http://groups.google.com/group/ipv4literals for gory details.

-d

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 1 Feb 2011 17:59:15 +0000

Agreed. So, do you suggest we change the R35 and R54 to FQDN instead?

On 2/1/11 11:56 AM, "Dan Wing" <[email-masked]> wrote:

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Feb 2011 10:27:12 -0800

> -----Original Message-----
> From: Lee, Yiu [mailto:[email-masked]]
> Sent: Tuesday, February 01, 2011 9:59 AM
> To: Dan Wing; [email-masked]
> Cc: [email-masked]
> Subject: Re: [CDNi] CDNI Requirements I-D
> 

If I understand those requirements correctly, those two requirements 
are related to how the CDN moves data amongst its own servers, rather than 
the URI presented to the client accessing the data.  I don't expect 
anyone will manage a CDN while they are behind a NAT64 or while
behind a NAT46, so IPv4 or IPv6 address literals should be fine 
with those requirements.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Feb 2011 10:38:30 -0800

> Not quite.
> Part of the response may contain "this is the URI I want you to return
> to the UA on my behalf which will redirect the UA to me".

thanks.

> I would propose adding a general requirement to the document stating
> "any
> URIs returned to User Agents MUST NOT contain IP address literals in
> the
> <authority> component of the URI" or similar text.

Works for me, and that's a nice contained requirement itself.  Thanks.

-d

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 1 Feb 2011 18:39:10 +0000

Hi Dan,

Since CDNi is about to federate CDN in a distributed environment. There
may be a case where CDN1 asks CDN2 to stream some contend to the CDN2's
user (U2). Let's say U2 is behind a NAT64. In this setup, when U2
generates a URL to the CDN1, the URL may contain the U2's IPv6 address as
the request client. This may create problem in CDN1. I have to take back
my FQDN suggestion because it won't work either.

I have to spend more time to think of this or we can simply declare this
is out-of-scope. Nonetheless, the requirement should be clear enough what
would be covered and what not.

Yiu

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 1 Feb 2011 18:56:46 +0000

Not quite.

Part of the response may contain "this is the URI I want you to return to
the UA on my behalf which will redirect the UA to me".

I would propose adding a general requirement to the document stating "any
URIs returned to User Agents MUST NOT contain IP address literals in the
<authority> component of the URI" or similar text.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 1 Feb 2011 18:58:45 +0000

> my FQDN suggestion because it won't work either.

U2 is behind NAT64 so CDN1 will see an IPv4 address for U2. That is not
the issue. The issue is that NAT64 relies on the NAT64 device synthesising
AAAA DNS responses as U2 only speaks DNSv6. But if U2 gets an v4 address
literal in the Content-Location header of a HTTP 302 it has no way to
communicate with that v4 address as it has no native v4 capability (or no
native v4 routing).

Using a FQDN (and avoiding v4 address literals) in the Content-Location
header would avoid the issue as you first suggested.

Ben