Subject: [Pana] pana-framework dual-stack issue

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 06 Jun 2005 18:02:59 -0400

I compiled the issues on dual-stack PRPA/POPA in pana-framework as
follows.

Comments are appreciated.

---
Issue: When there are both IPv4 and IPv6 addresses are available as
Pre-PANA address (PRPA), which address the PaC should use, an IPv4
PRPA or an IPv6 PRPA (resulting in a single PANA run), or both
(resulting in two PANA runs)?

  IMO, a single PANA run should be always sufficient.  Running two
  PANA runs for IPv4 and IPv6 should be avoided as much as possible.

Issue: When there are both IPv4 and IPv6 addresses are available as
PRPA and there is only one PANA run, which PRPA should be used?

  I think it should use IPv6 PRPA unless it is it is configured to use
  IPv4 PRPA.  On the other hand, both the PAA and PaC must be able to
  run PANA using either one of the IPv4 or IPv6 PRPAs.  When the PaC
  (the PAA) initiates a PANA run, the PAA (the PaC) must use the same
  IP version as the peer when responding.  To avoid race condition,
  when both entities simultaneously initiate a PANA run, the IP
  version used by the PAA should be used for the PANA run.

Issue: When there are both IPv4 and IPv6 addresses are available as
PRPA and IPsec bootstrapping is needed, which IP version should be used
for running IKEv2?

  The simplest rule would be using the same IP version as the PANA
  run.

Issue: When there are both IPv4 and IPv6 Post-PANA Addresses (POPA)
need to be configured, what the PANA protocol should do?

  I think the PAA should explicitly inform the PaC of the need for the
  configuration of both types of POPAs.  Specifically, we can define
  two types of Post-PANA-Address-Configuration (PPAC) AVPs, i.e.,
  IPv6-PPAC AVP and IPv6-PPAC AVP for that purpose.
---

Yoshihiro Ohba

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Alper Yegin <[email-masked]>
Date: Tue, 14 Jun 2005 14:09:25 -0700

Hi Yoshi,

Thanks for driving this issue.

My comments are below.

>   PANA runs for IPv4 and IPv6 should be avoided as much as possible.

I agree.

>   version used by the PAA should be used for the PANA run.

I think the simplest would be to:
- expect the dual-stack implementation to bind to PANA port on both the
IPv4 and IPv6.
- let the deployment/implementation decide which one to use when both
are available.

I think this ensures interoperability.

As for the race condition, I think it is better for the dual-stack PAA
to respond to the PDI from the PaC using whatever version of IP used by
the PaC.

>   The simplest rule would be using the same IP version as the PANA

Good idea.

>   IPv6-PPAC AVP and IPv6-PPAC AVP for that purpose.

Instead of two AVPs, can we use only one PPAC AVP and say:
- N bit is only for IPv4 (because only for IPv4 we may need
re-configuration. There is no need to replace an IPv6 PRPA with a POPA.)
- Split D into two separate bits: one for DHCPv4 and one for DHCPv6.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 14 Jun 2005 18:27:51 -0400

> >   PANA runs for IPv4 and IPv6 should be avoided as much as possible.

OK.

> I think this ensures interoperability.

I agree, that would be simplest.

> to respond to the PDI from the PaC using whatever version of IP used by

An issue is that when the simultaneous PANA initiation occurs, the PAA
does not respond to the PDI, as described in section 4.2:

"
   It is possible that both the PAA and the PaC initiate the discovery
   and handshake procedure at the same time, i.e., the PAA sends a PANA-
   Start-Request message while the PaC sends a PANA-PAA-Discover
   message.  To resolve the race condition, the PAA SHOULD silently
   discard the PANA-PAA-Discover message received from the PaC after it
   has sent a PANA-Start-Request message with creating a state (i.e., no
   Cookie AVP is included in the message) for the PaC.  
"

> >   The simplest rule would be using the same IP version as the PANA

OK.

> - Split D into two separate bits: one for DHCPv4 and one for DHCPv6.

That is also good.  In that case, we might need to also split
I(IKEv2)-bit into two separate bits to indicate the PaC to send a
Configuration Payload request with an appropriate set of configuration
attribute types to configure IPv4 and/or IPv6 POPA(s) using IKEv2.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Tue, 14 Jun 2005 17:56:44 -0700

> does not respond to the PDI, as described in section 4.2:

I see, you are right. 

I was suggesting that since I assumed PAA didn't know what IP stacks are
supported on the PaC (so, it was better for PAA to stick with the one
PaC used). But now that I'm thinking, if PAA is sending an unsolicited
PSR (the reason for the race condition), it must already know at least
one valid IP address of the PaC (hence at least one supported IP stack
on the PaC). So, it should be fine to discard an incoming PDI when there
is an outstanding PSR. We should not have to change the race condition
handling. 

Coming back to your statement above (at the very beginning), we don't
need any special explanation. PAA discards the PDI, PaC is expected to
respond to the PSR. Hence, PANA executes over whatever IP version PAA
used in sending the PSR.

> attribute types to configure IPv4 and/or IPv6 POPA(s) using IKEv2.

If IKEv2 is used for address configuration, it should be used for both
IPv4 and IPv6 addresses. Since we cannot use IKEv2 for one address type,
and another mechanism for another address type, I'm not sure we need to
have two separate flags. 

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 14 Jun 2005 20:12:34 -0400

OK.

> and another mechanism for another address type, I'm not sure we need to

When we use two addresses in IKEv2, the PaC would need to know whether
both IPv4 and IPv6 addresses or one of those addresses are available
as IPsec-TIA, because the IKEv2 responder will not provide the two
addresses unless each version of address is explicitly requested by
the IKEv2 requestor.  Or the PaC would always need to request both
IPv4 and IPv6 POPA in IKEv2 when it has both IPv4 and IPv6 PRPAs, and
let the EP assigns either both or one of IPv4 and IPv6 IPsec-TIAs it
can provide.

(Of course it was not my intention to use IKEv2 for one address type
and another mechanism for another address type.)

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Wed, 15 Jun 2005 10:14:04 +0300

>  PANA runs for IPv4 and IPv6 should be avoided as much as possible.

Agreed.

>  version used by the PAA should be used for the PANA run.
Agreed.

>  The simplest rule would be using the same IP version as the PANA
Agreed.

>  IPv6-PPAC AVP and IPv6-PPAC AVP for that purpose.
Yes, or other types of carrying the same information, as discussed in
further e-mails from Alper and you.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 15 Jun 2005 10:50:51 +0300

Yoshihiro Ohba wrote:

>>>>re-configuration. There is no need to replace an IPv6 PRPA with a
>>>>        
>>>>
>>POPA.)
>>    
>>
Hmm... thinking some more about this. It seems that the decision on
the use of IPv6 is mostly on the client side; either you want to do it or
not; the role of the network is to provide the requested data.

The case we have for IKEv2 usage in PANA does not appear any
different from a regular VPN usage scenario. Even there, the client
needs to figure out if it wants an IPv4, IPv6, or both addresses.

Based on this, it would probably be best if the client could just
request the addresses it wants from IKEv2 GW, and get the
ones that are really available. However, I'm not 100% certain
what IKEv2 protocol does if you try to ask multiple address
types. I've read the spec but it didn't spell it out.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 15 Jun 2005 08:46:53 -0400

On Wed, Jun 15, 2005 at 10:50:51AM +0300, Jari Arkko wrote:
> ones that are really available. 

I think it is a good justification for not splitting the I-bit in PPAC
AVP, I agree.

> However, I'm not 100% certain

So it appears that once we decide on not splitting the I-bit in PPAC
AVP, the rest of the operation for POPA acquisition is up to IKEv2
specification.

Yoshihiro Ohba