Subject: [pcp] External_AF

From: Stuart Cheshire <[email-masked]>
Date: Wed, 13 Apr 2011 22:58:20 -0700

I think I worked out what External_AF is for.

When used with NAT64, the client may have an IPv6 address, and think the remote peer has an IPv6 address, and therefore use a PEER6 request, but in fact the NAT64 will allocate an external address that is IPv4.

If this is true, then MAP requests may also need an External_AF field in the reply, to signify that the assigned external address is actually IPv4 when the NAT gateway is NAT64.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 14 Apr 2011 08:39:42 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stuart Cheshire
> Sent: Wednesday, April 13, 2011 10:58 PM
> To: [email-masked]
> Subject: [pcp] External_AF
> 
> When used with NAT64, the client may have an IPv6 address, and think
> the remote peer has an IPv6 address, and therefore use a PEER6 request,
> but in fact the NAT64 will allocate an external address that is IPv4.

Right.

> If this is true, then MAP requests may also need an External_AF field
> in the reply, to signify that the assigned external address is actually
> IPv4 when the NAT gateway is NAT64.

The MAP request itself requests if the external address is IPv6 (MAP6)
or IPv4 (MAP4).  So I don't see a need for MAP to have External_AF.

-d

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

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 14 Apr 2011 12:33:54 -0700

> or IPv4 (MAP4).  So I don't see a need for MAP to have External_AF.

How do we handle the case of an IPv6 client behind NAT64?

In this case, the client may end up being reachable both via native (untranslated) IPv6 and via a translated IPv4 address:port.

Should the client do two MAP requests, a MAP6 and a MAP4, to get both results to store in its rendezvous server?

If every client needs to do two MAP requests, maybe we should combine MAP6 and MAP4 into a single "MAP" operation, which returns *both* the external IPv4 address:port and the external IPv6 address:port?

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 14 Apr 2011 12:44:46 -0700

> From: Stuart Cheshire [mailto:[email-masked]]
> Sent: Thursday, April 14, 2011 12:34 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] External_AF
> 

If it wants an IPv4 mapping, it sends a MAP4.  If it wants an IPv6 mapping
(e.g., from its CPE which implements Simple CPE Security), it sends a MAP6.
In both cases, it sends the PCP message from its IPv6 interface.

> In this case, the client may end up being reachable both via native
> (untranslated) IPv6 and via a translated IPv4 address:port.
> 
> Should the client do two MAP requests, a MAP6 and a MAP4, to get both
> results to store in its rendezvous server?

Yes.

> If every client needs to do two MAP requests, maybe we should combine
> MAP6 and MAP4 into a single "MAP" operation, which returns *both* the
> external IPv4 address:port and the external IPv6 address:port?

But they might go to different places or be processed by different
components.  Seems trickier than necessary.  Perhaps something to optimize
with a new OpCode in a later document?
 
-d

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 14 Apr 2011 12:58:41 -0700

> In both cases, it sends the PCP message from its IPv6 interface.

The problem is that the client doesn't *want* a mapping; it *wants* connectivity.

Mappings are just a means to that end -- an unfortunate necessity in today's world.

A pure IPv6 client typically won't even know it's behind a NAT64. The only way it finds out is by asking for a MAP4 and seeing if it gets one.

So, in reality, every IPv6 client has to ask for both MAP4 and MAP6. Maybe that's not a problem -- I was just pointing out the issue.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 14 Apr 2011 16:12:42 -0400

> So, in reality, every IPv6 client has to ask for both MAP4 and MAP6. Maybe that's not a problem -- I was just pointing out the issue.

That's very similar to what ICE does. Every ICE client asks separately
for two TURN allocations: an IPv4 one and an IPv6 one. They both get
advertised to the peer through the rendez-vous server (SIP proxy).

I would envision an ICE client doing a similar procedure with PCP...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 14 Apr 2011 13:43:37 -0700

> Sent: Thursday, April 14, 2011 12:59 PM
> To: Dan Wing
> Cc: [email-masked]
> A pure IPv6 client typically won't even know it's behind a NAT64. The
> only way it finds out is by asking for a MAP4 and seeing if it gets
> one.
> 
> So, in reality, every IPv6 client has to ask for both MAP4 and MAP6.

If it needs to accept incoming connections from both IPv4 and IPv6, 
yes.  

Same with a dual-stack host, which (today) would need to send MAP4 (from 
its IPv4 interface) and MAP6 (from its IPv6 interface).

> Maybe that's not a problem -- I was just pointing out the issue.

I agree the two PCP requests could be optimized to one, in some
cases; but it also complicates situations where there is an IPv6
CPE doing Simple CPE Security, and a NAT64 in the ISP's network --
the CPE would need to proxy the new MAP-BOTH opcode towards the
NAT64, and then there are issues around possible differences
in maximum lifetime allowed by the IPv6 CPE versus the ISP's
NAT64.

-d